Subject: [rbridge] Use of 802.1ah Encaps

From: sajassi at cisco.com (Ali Sajassi (sajassi))
Date: Mon, 11 Dec 2006 01:18:03 -0800

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 12 Dec 2006 09:10:15 -0800

Ali Sajassi (sajassi) wrote:
>...

That's a fairly large drawback.

Also, how might this affect an IP protocol running on links over which
rbridge nodes communicate? I.e., don't you have to de-conflict the IP
addresses and possibly also the IGP to avoid interference between the two?

Our system has a shim just inside the outer ether, i.e., using a
different ethertype; that effectively forces non-rbridge systems to
ignore the packets.

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/20061212/6e7e22b6/signature.bin