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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 15 May 2006 08:45:06 -0400

Radia,

	Please see below.

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Sunday, May 14, 2006 12:24 PM
--> To: Russ White
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Encapsulation of RBridge IS-IS 
--> routing messages
--> 
--> We need to make sure that the per-VLAN IS-IS instance carrying endnode 
--> information is forwardable just like any other packet to be flooded 
--> throughout the VLAN (e.g., unknown destination, multicast destination 
--> not derived from IP multicast), but still recognizable by the egress 
--> RBridges attached to that VLAN as an IS-IS message. Including the
special 
--> "default VLAN" that has no tag, that would carry endnode information for

--> links without VLAN tags.
-->

I can't parse this, and I don't think it's me.  :-)

When you say "per-VLAN IS-IS instance carrying endnode information", do
you mean "IS-IS message"?  Is the "endnode information" MAC related for
RBridges, or are these IS-IS messsages that are meant to be transported
transparently, VLAN-wide, by the RBridge campus - between IS-IS routers?

In the last sentence, what does the second "that" ("that would carry...")
refer to?  In other words, what is it that you are saying would carry
endnode information for links without VLAN tags?

--> 
--> We need the core IS-IS instance that carries RBridge-RBridge 
--> reachability information to be easily trappable and processed by 
--> every RBridge. (this is not the same as the default VLAN endnode 
--> instance, which only has to be processed by RBridges that have 
--> attached endnodes on links without VLAN tags).
-->

Same problem here.

If you mean "IS-IS message", then it seems that you are saying that 
the IS-IS messages specific to RBridge protocol would need to be
handled at each RBridge.  This would allow non-RBridge IS-IS message
exchanges to be ignored by RBridges.

However, how does this relate to Russ' question/comment?

As long as RBridge IS-IS instances do not share MAC addresses with
IS-IS routing instances, the distinction between RBridge and Routing
protocols exchanges would happen quite naturally.

If you want to distinguish the messages such that protocol instances
ignore the inappropriate protocol messages independent of addressing,
then you need to use different protocol indentifiers.

Which approach are you advocating?

--> 
--> It might be nice not to have lots of extraneous padding where it's not 
--> necessary. So I'd like the implementers to say what's most convenient 
--> for their implementations.
-->

At what point does either approach result in extraneous padding?

Or am I not understanding your point at all?  If not, could you
try re-phrasing?

Thanks in advance...

--
Eric

--> 
--> Radia
--> 
--> 
--> Russ White wrote:
--> 
--> >-----BEGIN PGP SIGNED MESSAGE-----
--> >Hash: SHA1
--> >
--> >
--> >  
--> >
--> >>>>I was thinking that the IS-IS used by routers would be on one l2
--> >>>>address, and the "local" IS-IS process would be on a 
--> different one.
--> >>>>        
--> >>>>
--> >>    Yep, that is the point I am (not successfully) trying to make.
--> >>    
--> >>
--> >
--> >The cat's out of the bag! Maybe we could get a call for 
--> consensus on
--> >this point? Perhaps we need to go back to Radia's original 
--> email, and
--> >try to have a list of all the options, and what their 
--> pro's and con's are?
--> >
--> >:-)
--> >
--> >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
--> >
--> >iD8DBQFEZzxvER27sUhU9OQRAj3TAJ9VLLCOWL8VJAuYHMdboA8CYb7b2ACgnoYg
--> >HMR/8UxLCbmKBpSEtKn7V2s=
--> >=nNjE
--> >-----END PGP SIGNATURE-----
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->