Subject: [rbridge] Use of 802.1ah Encaps

From: Radia.Perlman at sun.com ([email-masked])
Date: Fri, 08 Dec 2006 10:56:01 +0500

Travelling again, so extremely limited access to email (as in, about 10 minutes here and there
on a SLOW connection).  Anyway, I'll answer some of these:

a) why "next hop" and "previous hop" in addition to "ultimate" source and destination

At least one of the reasons is that if there are three RBridges on the same link, R1, R2, and R3,
it is useful for R1 to choose which of R2 or R3 should receive the packet. It isn't obvious from
the destination address because it could be that either R2 or R3 would be logical, and R1 is
load splitting. Also, it helps focus traffic on the link, and ensure it doesn't get filtered, if
the bridges on the link only need to learn R1, R2, and R3, especially since traffic from outside
RBridges might arrive from different entry points onto the link.

b) congestion management was explained to us, and it was what convinced us we needed "ultimate
source RBridge" in order to know where to send the congestion notification. If you could explain the
other things, we could see if there is a problem, but if they are similar to congestion notification, then
having the ingress RBridge will accommodate them.

Sorry for ignoring all the other messages for now, but I only had a chance to read and respond to
one message.

Radia

----- Original Message -----
From: "Ali Sajassi (sajassi)" <sajassi at cisco.com>
Date: Friday, December 8, 2006 10:53 am
Subject: Re: [rbridge] Use of 802.1ah Encaps

> 
> Silvano, 
> 
> > -----Original Message-----
> > From: Silvano Gai [sgai at nuovasystems.com] 
> > Sent: Thursday, December 07, 2006 5:36 PM
> > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.; Joe Touch
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > 
> > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
> > There are advantages and disadvantages.
> > 
> > The disadvantages are:
> > 1) Lack of Next-Hop addresses. We discussed this at length 
> > during the last meeting and we didn't reach consensus on a 
> > way to eliminate them.
> 
> Can you refresh my memory for why we need a next-hop address when the
> header carries both source and destination PE addresses and when these
> addresses are learned in control plane ?
> 
> > 2) Lack of a TTL field (it may be added, but it is not there today).
> 
> Can probably be accommodated.
> 
> > 3) Many unneeded fields and therefore larger frame overhead.
> > 
> 
> Such as ?
> 
> > The advantages are:
> > 1) Larger addressable market for TRILL
> > 
> > IMO if we stick with the WG charter the disadvantages clearly 
> > outweigh the advantages.
> > 
> > The WG can be re-chartered, but if we consider the Enterprise 
> > and Data Center market, IEEE 802.1ah is an overkill.
> > 
> 
> If by overkill you mean a bit bigger header, then I agree but look at
> all the other advantages that you get from using standard IEEE header
> and shim including:
> 	- security Mgmt:  MACSec/KeySec 
> 	- Congestion Mgmt 
> 	- Connectivity Fault Mgmt
> 
> Has it been considered how these are going to work with TRILL shim
> header or are these outside of WG charter :-)
> 
> -Ali
> 
> 
> > -- Silvano
> > 
> > 
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org]
> > On
> > > Behalf Of Don Fedyk
> > > Sent: Thursday, December 07, 2006 9:21 AM
> > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi Eric
> > > 
> > > > -----Original Message-----
> > > > From: Gray, Eric [Eric.Gray at marconi.com]
> > > >
> > > > Don,
> > > >
> > > > 	And yet, someone (Ali Sajassi) asserted (in his message 
> > dated Wed 
> > > > 12/6/2006 at 2:16 PM EST) that there were no issues or 
> additional 
> > > > complications with using 802.1ah in enterprises for plug-and-
> play 
> > > > applicability.
> > > >
> > > > 	Perhaps Ali can answer my question then.
> > > >
> > > > 	But, to more directly address your earlier comments:
> > > >
> > > > 	The TRILL WG has NOT come up with an encapsulation that 
> "looks 
> > > > like" 802.1ah - unless someone squints really hard and tries 
> to 
> > > > pretend that two separate Ethernet encapsulations - 
> > separated by a 
> > > > SHIM header - are one single encapsulation.
> > > 
> > > To be fair Point to Point header that was discussed without 
> > one of the 
> > > shims was very close "functionally" (colloquial looks like) to
> > 802.1ah.
> > > My opinion is still we don't need several variations of 
> > headers doing 
> > > similar things.
> > > 
> > > This was the slide that looked a lot like what I posted.
> > > 
> > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > 
> > > Regards,
> > > Don
> > > >
> > > > 	That is not to say that the WG has done anything that 
> > could be said 
> > > > to disallow the use of 802.1ah encapsulation.
> > > > It is just not obviously consistent with all of the WG 
> > goals to use 
> > > > _only_ 802.1ah encapsulation.
> > > >
> > > > --
> > > > Eric
> > > >
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > rbridge at postel.org
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 07 Dec 2006 22:59:39 -0800

> RBridges might arrive from different entry points onto the link.

The ultimate destination (and source, for that matter) should be
sufficiently indicated by the inner ethernet packet. The outer header is
already hop-by-hop inside the rbridge anyway. What additional
information is required?

The next/previous hop information sounds like a source route with
record-route option. While that's useful for debugging, it doesn't seem
necessary.

> having the ingress RBridge will accommodate them.

Why doesn't the source ethernet address indicate this already?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061207/79d12213/signature.bin