Subject: [rbridge] Encapsulation of RBridge IS-IS routing messages

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 12 May 2006 11:28:17 -0400

Russ,

	I don't think we've collectively made a decision as to how we
would distinguish IS-IS messages from RBridge-IS-IS messages (as is
necessary to avoid confusion complexity if - for example - someone
were building an RBridge co-located with an IS-IS router).

	Radia has earlier made several suggestions, one of which was 
to use a distinct MAC mlticast address for RBridges.

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White
--> Sent: Friday, May 12, 2006 8:26 AM
--> To: Dino Farinacci
--> Cc: rbridge at postel.org; Radia.Perlman at sun.com
--> Subject: Re: [rbridge] Encapsulation of RBridge IS-IS 
--> routing messages
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> >>> Dino...I think what you're proposing is a special 
--> multicast address for 
--> >>> use only by IS-IS for RBridges.
--> > 
--> >     Yes, that is correct.
--> > 
--> >>> We don't need the shim header since we don't need TTL 
--> (IS-IS will not 
--> >>> flood the same pkt twice), or
--> > 
--> >     Since the IS-IS messages are link-local in the core 
--> RBridges I agree. But
--> >     what about the instance that runs at the edges where 
--> the core forwards
--> >     them like they would for any other packet?
--> 
--> Wouldn't this be to the original IS-IS MAC address, and thus treated
--> like any other layer 2 multicast?
--> 
--> >>> Outer header of IS-IS pkt would be:
--> >>> destination=new multicast address just for IS-IS RBridges
--> >>> source=transmitting RBridge
--> >>> Ethertype=I dunno...probably the one assigned for 
--> "encapsulated RBridge pkt"
--> > 
--> >     Can we use the same format as IS-IS uses today. The 
--> only difference is
--> >     the DA is different? That will reduce the changes to 
--> the existing
--> >     implementations.
--> 
--> This is the route I would prefer, as well.
--> 
--> >>> After the outer header, just VLAN tag
--> >>>
--> >>> After that, the IS-IS pkt.
--> > 
--> >     To to be more precise you are proposing IS-IS packets 
--> in .1q? Why? Will
--> >     the core switches do an IS-IS instance per VLAN? As I 
--> mentioned at the
--> >     last IETF, this is a tradeoff between fault isolation 
--> and scalability.
--> > 
--> >     It would be nice for someone to make a final call on this.
--> 
--> I don't see why we would want a process per vlan, unless 
--> we're worried
--> about a process failing (as opposed to a device). IS-IS already does
--> constrained SPF for various reasons (traffic engineering, 
--> fast reroute,
--> and others...), so I don't see a big deal in doing a single 
--> process with
--> constrained SPF for each vlan.
--> 
--> :-)
--> 
--> Russ
--> 
--> - --
--> riw at cisco.com CCIE <>< Grace Alone
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.2.2 (MingW32)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFEZH7AER27sUhU9OQRAl/GAJ4w/AuqNFkTdktPS7ppajJVCCY7CgCcDjon
--> ig0/ImC+JvFBLnLhJoEPd/Q=
--> =ZdT0
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->