Subject: [rbridge] Use of 802.1ah Encaps

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 12 Dec 2006 16:51:37 -0500

Joe,

	It's a huge drawback, and it requires configuration of
at least IP addresses - possibly per-interface.  That is not
going to work very well as a plug-and-play solution.

	In addition, as you hint at, you're effectively now a
part of the routing L3 network - as opposed to part of the 
bridging L2 network.  It would make little sense - at that
point - to try to differentiate RBridges from routers as it
is already established that routers can be built and used 
in real networks.

	If you're building a box that acts like a router, then
build a router.  Nothing much for us to do in that case.

--
Eric

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Tuesday, December 12, 2006 12:10 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:
> >...
> >> 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 :-)
> 
> 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
> 
>

---

From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro)
Date: Wed, 13 Dec 2006 16:34:48 +0000

Hello,

  Sorry to intrude, I just wanted to play devil's advocate here.. ;-)

> going to work very well as a plug-and-play solution.

  An IP based data plane does not imply that you need configuration, not
even IP addresses on interfaces.  Think of IP adhoc protocols
(AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or
simply generate a random IP.

> is already established that routers can be built and used 

  There is still some advantage: normal routers need configuration,
RBridges don't.  But at the same time you can reuse existing IP
forwarding blocks of routers.

  But if you are really looking for arguments against IP data plane:
   1. Larger header size;
   2. Larger (32-bits) addresses (vs. 16-bits of rbridge nick names);
   3. Obfuscation, e.g. some fields are there but not used by RBridges
(like fragmentation control).

  Regards,

-- 
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 13 Dec 2006 09:14:53 -0800

> simply generate a random IP.

That works only if there is NO other IP traffic on that plane. We don't
know that rbridges will talk to each other over dedicated paths that
don't involve non-rbridge to non-rbridge traffic.

In that case, the IP addresses sent on certain link addresses - notably
multicast and broadcast - could interfere between rbridge use of those
addresses and non-rbridge use of those addresses.

-- 
----------------------------------------
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/20061213/c292cfd8/signature.bin

---

From: gjc at inescporto.pt (Gustavo J. A. M. Carneiro)
Date: Wed, 13 Dec 2006 17:57:03 +0000

> addresses and non-rbridge use of those addresses.

  Also not a problem: RBridges could use an IP data plane, but using a
different EtherType, different from the usual 0x0800.