[rbridge] Use of 802.1ah Encaps
Don Fedyk
dwfedyk at nortel.com
Fri Dec 15 09:37:11 PST 2006
Hi Guillermo
See Inline.
> -----Original Message-----
> From: Guillermo Ibáñez [mailto:gibanez at it.uc3m.es]
>
>
> My previous message perhaps was not too clear. Please bear
> with me and
> my english :-)
> - 802.1ah assumes no legacy bridges in the middle.
This is false. 802.1ah is backwards compatible with legacy bridges. However I think it would be safe to say this is not a plug and play option. 802.1ah would need to be configured to know the legacy bridges capabilities. But 802.1ah header is compatible with 802.1Q header for forwarding. The same trick that a TRILL RBridge uses.
> - AFAK, 802.1ah does not assume routing between nodes. If so,
> it would
> likely require TTL field.
802.1ah bridges from ingress to egress PBB nodes. Whether the service is IP or Ethernet on the ingress/egress PBB is a box question not outside the scope of 802.1ah architecture.
> - TRILL does assume legacy bridges between Rbridges
> - TRILL is not a subset of 802.1ah, it is different thing
I don't think people ever said TRILL was a subset of 802.1ah.
What I said was certain versions of the TRILL header look remarkably like the 802.1ah header. Following this logic I then said start from 802.1ah. This has not yielded any results because the part that looks like 802.1ah is hop by hop part and 802.1ah does not have a hop by hop DA part.
> - 802.1ah is not a example of simplicity.
I don't think this type of generalization adds any value. We are talking headers and every field in 802.1ah has a purpose and good value for the bits.
> - It is too late to question TRILL basic assumptions and try to merge
> 802.1ah with TRILL encapsulation.
If you asked me if I see value in merging right now I would say no since the point to point header is not mainstream TRILL.
> - If the whole TRILL approach is questioned (I assume it is not the
> case), 802.1ah does not seem the way to go regarding simplicity in
> campus networks.
No one suggested you put a provider backbone bridge in place of an Rbridge. The comment was could you use the same Frame format for the packet encaps and related functions? And that is not looking promising.
Regards,
Don
> Guillermo
>
> Guillermo Ibáñez escribió:
> > Just a side comment.
> > I think the ongoing discussion is not about encapsulation
> but about the
> > fundamentals of RBridges approach versus 802.1ah's. So,
> while agreeing
> > on the great sinergies of a common encapsulation, lack of
> TTL is an
> > essential point that reflects the essential difference in
> the deployment
> > fields assumed.
> > If we assume a deployment field as for 802.1ah, encapsulations and
> > proposals much simpler than 802.1ah are possible (one is
> described in my
> > ABridges draft). If this is the case we should restart WG
> discussion
> > from the beguinning.
> > Encapsulation for RBridges is not simple, and 802.1ah isn't simple
> > either, specially considering the campus networks of
> moderate sizes that
> > are the target for RBridges.
> > Guillermo
> >
> >
> > Gray, Eric escribió:
> >> Don,
> >>
> >> I think you've garbled the discussion, somewhat.
> >>
> >> Please see below...
> >>
> >> --
> >> Eric
> >>
> >>
> >>> -----Original Message-----
> >>> From: Don Fedyk [mailto:dwfedyk at nortel.com]
> >>> Sent: Wednesday, December 13, 2006 1:19 PM
> >>> To: Gray, Eric
> >>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali
> >>> Sajassi (sajassi); Silvano Gai
> >>> Subject: RE: [rbridge] Use of 802.1ah Encaps
> >>>
> >>> Hi Eric
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> >>>>
> >>>> Don,
> >>>>
> >>>> I don't follow your reasoning.
> >>>>
> >>> That's OK I cant follow you sometimes either ;-)
> >>>
> >>>
> >>>> I certainly am not saying that using "ANY standard header"
> >>>> is a bad idea.
> >>>>
> >>> Then why not start from ah? The bit that Silvano said was we
> >>> could use ah and you said it is a bad idea.
> >>>
> >> I don't think I am quoting too much out of context, when I quote
> >> the following from Silvano's reply to Joe Touch:
> >>
> >> SILVANO > My comment is that IEEE 802.1ah has no space for both
> >> SILVANO > the ultimate source/dest and the next hop source/dest.
> >>
> >> SILVANO > IEEE 802.1ah is designed for multiple enterprises to
> >> SILVANO > share a common metro backbone. It does a fine job in
> >> SILVANO > that area. It does not support well an arbitrary
> >> SILVANO > intermixing of Bridges and Rbridges.
> >>
> >> SILVANO > In contrast Trill does a fine job in supporting
> >> SILVANO > arbitrary topologies and mixing of RBridges and
> >> SILVANO > Bridges thanks to the availability of both the
> >> SILVANO > ultimate source/dest and the next hop source/dest.
> >>
> >> SILVANO > In TRILL the network between the "ingress" and
> >> SILVANO > "egress" RBridge isn't a single Ethernet (like in
> >> SILVANO > 802.1ah), but rather a sequence of RBridges that
> >> SILVANO > may be connected by Ethernets.
> >>
> >> SILVANO > Things look similar, but are substantially different.
> >>
> >> Given that this is what (I believe, at least) Silvano said
> >> about using 802.1ah, where do you get the impression that
> >> Silvano has said that "we could use ah"?
> >>
> >>
> >>> Please describe "BAD idea" then.
> >>>
> >> In this, I think quite a few of us are now in agreement.
> >>
> >> It is rarely a good idea to use a header format just because
> >> most of the bits look similar to one proposal that has all
> >> of the information you require.
> >>
> >> Suppose you started to think that using 802.1ah - because it
> >> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC
> >> - was an example of one of the rare instances in which this
> >> might be a good idea. Wouldn't you suspect that the need to
> >> consider potentially adding a TTL field to the header might
> >> be an indication that you are probably wrong?
> >>
> >> So, to answer your question, a "BAD idea" is one that takes
> >> valuable resources to explore and offers no believable cause
> >> to suspect that it will work better than other ideas already
> >> on the table.
> >>
> >> In this case, we have reason to believe (MAC+SHIM)-in-MAC
> >> will work and no reason to believe that 802.1ah will work
> >> better - even assuming we went down that rat-hole.
> >>
> >>
> >>>> As for "creating a new forwarding paradigm" - yes, we're
> >>>> doing a little bit of that. Ideally, we'll be doing as little
> >>>> of that as we can get away with. The "little bit" we have to
> >>>> do is to use some additional header information to:
> >>>>
> >>>> 1) forward frames on the shortest path between RBridges,
> >>>> and
> >>>> 2) reduce or eliminate potential looping of frames during
> >>>> a perturbation of the shortest path.
> >>>>
> >>> You have so far chosen to do this in a mode that
> optimizes for mixed
> >>> bridges at the cost of ignoring the effciencies you could
> get between
> >>> directly connected Rbridges. 802.1ah opimizes forwarding
> for connected
> >>> Provider Backbone Bridges and interworks with legacy at a common
> >>> denominator.
> >>>
> >> Right, and 802.1ah assumes either a green-field deployment, or a
> >> firmware modifiable deployment of PBB-(enabled/compatible) bridges.
> >>
> >> This is not consistent with our goals.
> >>
> >>
> >>>> This may be somewhat of a simplification, but that's fair in
> >>>> light of the general trend for casual observers to do the
> >>>> opposite.
> >>>>
> >>>> Currently, we define a SHIM to carry this information and
> >>>> we expect to use one or more "standard headers" to encapsulate
> >>>> frames being forwarded between RBridges.
> >>>>
> >>>> Does this make things clearer?
> >>>>
> >>> Eric I understand what is proposed but I still question
> if a greater
> >>> synergy cannot be achieved between encapsulating headers.
> A shim is a
> >>> not a typical solution but encapsulations are.
> >>>
> >> Greater synergy is always demonstrably possible if you're willing
> >> to wait long enough.
> >>
> >> That's - for example - why we only have one link-state routing
> >> protocol, and why Ethernet was the one and only MAC-like format
> >> for L2 frames ever to have been used.
> >>
> >> What planet are we on? :-)
> >>
> >>
> >>> Regards,
> >>> Don
> >>>
> >>>
> >>>
> >>>> --
> >>>> Eric
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Don Fedyk [mailto:dwfedyk at nortel.com]
> >>>>> Sent: Wednesday, December 13, 2006 12:18 PM
> >>>>> To: Gray, Eric; Silvano Gai
> >>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali
> >>>>> Sajassi (sajassi)
> >>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
> >>>>>
> >>>>> Hi Eric
> >>>>>
> >>>>> This argument says if you use ANY standard header then it
> >>>>>
> >>>> would be a bad
> >>>>
> >>>>> idea.
> >>>>>
> >>>>> So you are creating a new forwarding paradigm and the down
> >>>>>
> >>>> side of that
> >>>>
> >>>>> as Ali pointed out is now you have to create most of the
> >>>>>
> >>>> other things
> >>>>
> >>>>> that go along with new forwarding paradigm.
> >>>>>
> >>>>> Don
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> >>>>>> Sent: Tuesday, December 12, 2006 4:29 PM
> >>>>>>
> >>>>>> Silvano,
> >>>>>>
> >>>>>> IFF we were going to use 802.1ah, it could allow us to
> >>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the
> >>>>>> "customer" DA/SA for egress/ingress RBridges. But that would
> >>>>>> be using it in a way that is not consistent with the intended
> >>>>>> use of 802.1ah - simply because that usage would make use of
> >>>>>> the fields in a way that matches the way that your proposed
> >>>>>> "short-hand" SHIM header would use them.
> >>>>>>
> >>>>>> If you did that, there would be room for using the B-tag
> >>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags.
> >>>>>>
> >>>>>> I think this is a VERY BAD idea.
> >>>>>>
> >>>>>> --
> >>>>>> Eric
> >>>>>>
> >>>>> <snip>
> >>>>>
> >>>>>
> >> _______________________________________________
> >> 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
> >
>
>
More information about the rbridge
mailing list