Subject: [rbridge] RBridge Link-State Protocol comments

From: Venkata.Naidu at Marconi.com (Naidu, Venkata)
Date: Fri May 7 15:44:26 2004

-> 2.1  Link State Protocol
->
-> Running a link state protocol among RBridges is straightforward. It
-> is the same as running a level 1 routing protocol in an area. IS-IS
-> is a more appropriate choice than OSPF in this case because it is
-> easy in IS-IS to define new TLVs for carrying new information.
-> However, the instance of IS-IS that RBridges will implement will be
-> separate from any routing protocol that IP routers will implement,
-> just as the spanning tree messages are not implemented by IP routers.
->
-> To keep the instances separate, RBridge routing messages should be
-> sent to a different layer 2 multicast address than IS-IS routing
-> messages.  Alternatively, they can be differentiated by having a
-> different "area address", where, in order to keep RBridges
-> configuration-free, the RBridge area address would be a constant for
-> all RBridges, and would not be one that would ever appear as a real
-> IS-IS area address.

  Here are few comments w.r.t reuse of IGPs for RBridges:

  1. If we plan to augment ISIS by adding new TLVs, why there is a
     need to assign a different layer 2 multicast address. We could
     as well use draft-ietf-isis-wg-multi-topology extensions
     to achieve the same goal.

  2. It seems we are trying to reuse the existing IGPs, because, they 
     are stable, proven and 99% of the features what Rbridges wants 
     comes for free from link-state IGPs. By putting some restrictions
     on area addresses and assigning new multicast addresses would 
     make it look like a new protocol. In such a case, it is better 
     to write a new protocol, (let it look almost same as ISIS)
     But, it is still distinguishable because it solve a different
     problem/purpose.

  Can't we make make RBridge-ISIS work with out above new requirements?

Venkata.