RE: iFCP: FC-BB exists, why invent something new?

["Murali Rajagopal" <muralir@lightsand.com>]

Wayland:

One correction to your analysis.
The BSW switches do not have to run a dynamic protocol such as
FSPF-backbone.
In reality, any proprietary protocol or even static configurations will
work in the backbone especially when the number of ARs is small.
Also, my reading is that Switch vendors are not quite there with a
hierarchial
implementations. But it will come in time ...

Yes, FC-BB2 is postioned to carry the FC-SAN island connectivity to the next
step.
FC-BB2 has decided to align itself with FCIP Model.

-Murali

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Wayland Jeong
Sent: Friday, December 15, 2000 10:17 AM
To: 'Matt Wakeley'; IPS Reflector
Subject: RE: iFCP: FC-BB exists, why invent something new?


I wish I had a hat to take-off ;-)

> Wayland Jeong wrote:
>
>> The
>> salient difference here which, in my mind makes the two proposals (iFCP
and
>> FCIP) difficult to reconcile, is the fact that iFCP does not require
FC-BB.
>> The devices on each side of the gateway are completely isolated from one
>> another in the FC sense.
>
> Ok, so iFCP is going to connect FCP devices.  FC-BB already exists to
"bridge"
> FC islands. FCIP appears to provide the FC-BB functionality (and is not
> restricted to FCP). What does iFCP bring to the table that FC-BB does not
> already provide?
>
I guess my comment here was a little misleading. FCIP does not require FC-BB
since FC-BB as defined encompasses SONET and ATM specifically. I was
referring to the requirement that an FCIP distributed SAN would utilize the
SW-2 concepts of Autonomous Regions (AR's) and Border Switches (BSW's). In
FCIP, the interconnection of BSW's requires the use of the FSPF-backbone
routing algorithms for resolving paths created by the virtual ISL's between
FCIP devices. As currently defined, an FCIP implementation would need to
have some static tables to describe which logical ISL's actually exist. This
logical network through the IP cloud would represent an AR-0 network in the
SW-2 sense.

Now, that's all fine and good, but the thing that iFCP gives you is the
ability to present a "non-transparent" interface to the IP network. This
"non-transparent" gateway has some distinct advantages in my mind. For one,
it allows "implementations" to isolate domain assignment between SAN
islands. In an FCIP connected network, when you slammed two SAN's together,
conflicting domain's would become isolated. In an iFCP connected network,
since the labeling of remote physical devices is maintained locally and
resolved through a DNS-like structure, remote SAN's are much less tightly
coupled.

The other thing that makes me squirm a bit is FCIP's reliance on SW-2
concepts that, I don't believe, are entirely wrung out yet. In reading SW-2,
the whole notion of BSW's and backbones seems a bit vague to me and I am not
aware of any real implementations (I know Gadzoox had what they called an
Area Switch, but that was a while ago). If my memory serves me correctly,
the whole notion of AR's and BSW's came out of the fact that FC could not
settle on a routing protocol. There was Brocade's FSPF and there was OSPF
which was used by everyone else. The AR's and BSW's allowed one to connect
FC SAN island's comprised of switches from different vendors.

Now, I know that ANSI is starting a BB-2 project which will address more
than SONET and ATM and maybe something viable for connecting SAN's through
IP will emerge.

My 2 cents anyway.

> -Matt
>
-Wayland