[rbridge] Use of 802.1ah Encaps
Ali Sajassi (sajassi)
sajassi at cisco.com
Mon Dec 11 01:18:03 PST 2006
> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Sunday, December 10, 2006 10:56 PM
> To: Ali Sajassi (sajassi)
> Cc: Silvano Gai; Radia.Perlman at sun.com; Don Fedyk; Gray,
> Eric; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> Ali Sajassi (sajassi) wrote:
> >> -----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?
> >> 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?
> > If the outer Ethernet addresses represent the link Ether
> addresses for
> > the current/next-hop rbriges and the shim header represent the
> > source/dest rbridge addresses, then why not just do IP encap using
> > L2TPv3/GRE and be done with !!
> Can you please describe the header you're considering an
> alternative, e.g, where the current one is:
> [outer ether [6-byte shim] [inner ether [payload]]]
[outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim]
[inner Ether [payload]]
The draw back is the additional 20 bytes of IP header but the advantage
is that you can use the IGP as is :-)
> The above adds 20 bytes (14 outer ether + 6 byte shim), and
> allows TTL management inside the rbridge without affecting
> the payload TTL (required for correct operation).
> I'm not exactly sure what you mean you L2TPv3/GRE, but I'm
> wondering if that comes out to 42 bytes of header, and
> whether it provides an L2 solution.
It is an L2 solution. I did a draft on it long time ago in context of
More information about the rbridge