[rbridge] Use of 802.1ah Encaps

[Joe Touch]

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?

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
> 

-------------- 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/8858692d/signature.bin