[rbridge] Use of 802.1ah Encaps

[Ali Sajassi (sajassi)]

> -----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
L2VPN:

http://ietfreport.isoc.org/idref/draft-sajassi-mvpls/


-Ali

> 
> Joe
> 
> 
>