[rbridge] Use of 802.1ah Encaps

[Joe Touch]

Silvano Gai wrote:
> Joe,
> 
> Inline:
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:touch at ISI.EDU]
>> Sent: Friday, December 08, 2006 7:29 AM
>> To: Silvano Gai
>> Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; Gray,
> Eric;
>> Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Use of 802.1ah Encaps
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> TRILL will never scale if you mandate to keep the forwarding table
> for
>>> the inner addresses on all RBridges, especially in a IEEE 802.1ah
>>> environment!!!
>> Sorry; let me backup:
>>
>> Here's where we were at the last IETF:
>>
>> - the shim indicates the source (ingress) and dest (egress)
>>   (originally this was just dest for unicast, source for mcast
>>   but we agreed in San Diego to include both)
>> 	i.e., agreed with the point above; those are the
>> 	addresses on which packets are forwarded
>>
>>   the ultimate source is indicated in the shim already
>>
>> - the outer header already indicates the previous/next-hop rbridge
>>
>> What's the reason for needing any further information?
> 
> We don't.
> 
> My comment is that IEEE 802.1ah has no space for both the ultimate
> source/dest and the next hop source/dest.
> 
> IEEE 802.1ah is designed for multiple enterprises to share a common
> metro backbone. It does a fine job in that area. It does not support
> well an arbitrary intermixing of Bridges and Rbridges.
> 
> In contrast Trill does a fine job in supporting arbitrary topologies and
> mixing of RBridges and Bridges thanks to the availability of both the
> ultimate source/dest and the next hop source/dest.
> 
> In TRILL the network between the "ingress" and "egress" RBridge isn't a
> single Ethernet (like in 802.1ah), but rather a sequence of RBridges
> that may be connected by Ethernets.
> 
> Things look similar, but are substantially different.

Agreed!

Joe

> -- Silvano
> 
> 
>> As per below, if R1 (current rbridge) wants to pick from among
> multiple
>> next-hops R2 and R3, it does so with the outermost ethernet header. If
>> they're logical (R2/R3 both on the same NIC), then just assign
> separate
>> ethernet addresses to the same interface.
>>
>> What's left?
>>
>> Joe
>>
>>
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:touch at ISI.EDU]
>>>> Sent: Thursday, December 07, 2006 11:00 PM
>>>> To: Radia.Perlman at sun.com
>>>> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
>>> Developing
>>>> a hybrid router/bridge.
>>>> Subject: Re: [rbridge] Use of 802.1ah Encaps
>>>>
>>>>
>>>>
>>>> Radia.Perlman at sun.com wrote:
>>>>> 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.
>>>> 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.
>>>>
>>>>> 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.
>>>> Why doesn't the source ethernet address indicate this already?
>>>>
>>>> Joe
> 

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- 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/20061208/dfd98e79/signature-0001.bin