[rbridge] WG last call comments to:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

Hi Silvano,

I think I agree with most of your comments but see a few notes at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Silvano Gai
Sent: Sunday, October 29, 2006 12:23 PM
To: rbridge at postel.org
Subject: [rbridge] WG last call comments
to:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.
txt

Comments inline marked "sgai n>"

-- Silvano

--------------------------------------------------------

... snip ...

1. Introduction 

   The current dominant approach to segregating network traffic relies
   on a hierarchical arrangement of bridges and routers.  Hierarchy is
   further extended - both within routing protocols (such as IS-IS and
   OSPF) and between routing protocols (for example, between IGPs and
   BGP).  At least part of the current network structure is based on a 
   determined trade-off between limitations of IP routing and similar 
   disadvantages of 802 bridging.

   Bridging Limitations

   For example, bridged networks consist of single broadcast/flooding
   domains.  Ethernet/802 encapsulation (on which bridging is based) 
   does not provide mechanisms for reducing the impact of looping data 
   traffic that may result from a transient change in network topology
   and the existence of multiple paths.

   The impact of looping traffic is far worse with flooded or broadcast 
   traffic as this results in exponentially increasing traffic load.  
   Consideration of the impacts of looping data lead to the use of 
   STP/RSTP to establish a connected - loop free - tree by disabling 
   forwarding on a subset of links that might create a loop.  This has
   also the effect of eliminating redundant paths.

@@@ Also generally lowers aggregate throughput and increases latency
through the net due to frames following suboptimal paths.

   Because of the potential for severe impact from looping traffic, 
   many (if not most) current bridge implementations stop forwarding of 
   traffic frames following a topology change event and restart only 
   after STP/RSTP is complete.

Sgai 1> In STP there is no way of knowing when the convergence has been
achieved; a bridge does not know or care about the timers of other
bridges. The state machines on the ports are run independently. If you
refer to the Topology Change Notification Flag, its purpose is to reduce
the filtering database ageing time, not to signal if STP/RSTP is
complete.

   As a result, the process of eliminating potential loops in existing 
   bridging deployments:

     1) Results in inefficient use of inter-bridge connections 
        and
     2) Causes delays in forwarding traffic as a result of 
        changes in the network topology.

Sgai 2> 2) is not true in the RSTP case; as a matter of fact RSTP is the
fastest converging protocol available today. 

@@@ I'm not sure why this and other documents put the emphasis they do
on STP/RSTP convergence. Of course it depends some on just how STP/RSTP
is implemented and how other algorithms are implemented. Perhaps it
stems from, as was pointed out early in the Rbridge effort, that the
replacement of bridges with Rbrides typically divides what would have
been one large spanning tree domain into a number of smaller ones
interconnected by Rbridges. The STP/RSTP protocol within these small
spanning tree domains will typically converge for them all in parallel
more rapidly than the pre-existing larger single spanning tree STP/RSTP
convergence.

   The combined effect of broadcast/flooding traffic, and the use of 
   spanning trees for loop avoidance, sets practical limits on bridged 
   network size in the network hierarchy and results in inefficient 
   bandwidth use of inter-bridge connections. Inefficient inter-bridge 
   connection usage similarly limits the usefulness of bridging with 
   high-speed (and consequently high cost) interfaces.







Gray                      Expires March, 2007                 [Page 3]

Internet-Draft        TRILL Routing Requirements       September, 2006


   IP Routing Issues

   For IP routed networks, any link (or subnet) must have at least one 
   unique prefix. This means that a node that moves from one IP subnet

sgai 3> in the case of IP instead of "node" is better to speak of
"interface". It is the interface that has an address, not the node.
 
   to another must change its IP address. Also, nodes with multiple IP
   subnet attachments must have multiple IP addresses.  In IP routed
   networks, there are frequent trade-off considerations between using 
   smaller subnets (longer prefix length) to minimize wasted IP address 
   space (as a result of unused addresses in the fixed address range 
   defined by the prefix and length) and using larger subnets (shorter
   prefix length) to minimize the need for (changes in) configuration.

   In any case - with current IP routing technology - subnets must be 
   configured for each routed interface.

   Proposed Solution

   Using a hybrid of routing and bridging - an RBridge - we hope to
   gain the benefits of both technologies, in particular, gaining the
   bandwidth advantages of shortest path routing while retaning the
   simplified configuration associated with bridging.

1.1. Terminology

   The following terms are used in this document in the way that
   they are defined in "TRILL RBridge Architecture" [TARCH]:

     ARP (Address Resolution Protocol)
     Bridge Learning
     Broadcast Domain 
     Broadcast Traffic
     Cooperating RBridges
     Egress RBridge
     Ethernet
     Flooded Traffic
     Flooding
     Frame 
     IGP (Interior Gateway Protocol)
     Ingress RBridge
     Ingress RBridge Tree
     IS-IS (Intermediate System to Intermediate System)
     ND (Neighbor Discovery)
     OSPF (Open Shortest Path First)
     Packet 

Sgai 4> in the case of layer 2 networks is more appropriate to use the
term frame, instead of packet.

@@@ Frame appears earlier in this list and I believe that both are
properly defined in the architecture document.

     RBridge
     SPF (Shortest Path First)
     STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree Protocol)
     TRILL (TRansport Interconnect over Lots of Links)
     Unknown Destination
     VLAN (Virtual Local Area Network)


Gray                      Expires March, 2007                 [Page 4]

Internet-Draft        TRILL Routing Requirements       September, 2006



1.2. Specific TRILL Goals

   (Near) Zero Configuration

   It is a TRILL requirement that it must be possible to deploy RBridges
   in at least a nominal set of potential deployment scenarios without a
   need to perform any configuration at each RBridge.  It is possible to
   meet this goal for a sub-set of all possible deployment scenarios by
   making realistic restrictions on deployment - such as restricting the
   deployment scenarios to exclude those involving a "trust model" that
   imposes a need for configuration of some form of "shared secret" or 
   other configuration required to restrict access to "trusted" devices.

   It is also conceivable that a minimal configuration may be required
   for deployment of an initial (set of) device(s) - with subsequently
   deployed devices deriving that configuration information during the
   process of - for example - peer discovery.  This would constitute a
   mechanism for "near zero configuration".

   Efficient Unicast Bandwidth Usage

   For unicast, non-flooded traffic, RBridges are intended to merge the
   efficient bandwidth use of IP routing with the simplicity of Ethernet
   (or 802.1) bridging for networks possibly larger - and with greater 
   forwarding capacity - than is the case with these networks presently.
 
   The approach that we will use in accomplishing this is based on the
   idea of extending (one or more) link state routing protocol(s) to
   include distribution of Ethernet/802 reachability information between
   RBridge instances.  

Sgai 5> "RBridge instances" is not defined.

@@@ For a document at this level, perhaps it could just say "RBridges".

   In addition, there may be specific requirements
   imposed on the interactions between these extensions and the Spanning
   Tree Protocol (STP) and between RBridge instances and (potentially
   co-located) IP routing instances.

   Potentially More Efficient Multicast and Broadcast Usage

   There are clear advantages to incorporating mechanisms for improved
   efficiency in forwarding (layer 2) multicast frames and - possibly
   in reducing the amount of broadcast traffic as well.  To the extent
   that these efficiency improvements may be considered "optimizations"
   and may be defined orthogonally to the process of specifying basic
   RBridge functionality, the potential to include these optimizations
   is (highly) desirable, but not mandatory.

   Examples of this type of optimization include use of any intrinsic 
   multicast routing capabilities and optimizations of ARP/ND.





Gray                      Expires March, 2007                 [Page 5]

Internet-Draft        TRILL Routing Requirements       September, 2006



   Backward Compatibility

   RBridges must be fully compatible with current bridges, IPv4 and
   IPv6 routers and endnodes.  They should be invisible to current IP
   routers (just as bridges are), and like routers, they terminate a
   bridged spanning tree.  

Sgai 6> the concept of terminating a bridged spanning tree is to vague,
see also sgai 10.

@@@ I think that concept is generally understood to mean that they do
not pass BPDUs. Perhaps "by not passing BPDUs" could be appended above.

   Unlike Routers, RBridges do not terminate
   a broadcast domain.


2. General Requirements Potentially Affecting Routing

   Candidate IGP Routing protocols - IS-IS or OSPF - must be evaluated
   for compatibility with the above goals.

   For example, since IS-IS requires a unique System ID for each IS-IS
   instance (at least within a "scoped" deployment), a requirement for 
   "(near) zero configuration" implies a need for mechanisms that allow
   auto-configuration and/or negotiation of these (scoped) unique IDs.

   Similar requirement must apply for OSPF as well, if selected.

   In addition, forwarding of protocol messages must be compatible with
   (or reasonably adaptable to) use of forwarding at layer 2, or there
   must be a means for deriving suitable higher layer addresses for the
   purpose of protocol exchanges - without imposing the need to manually
   configure higher-layer addresses.


3. Link State Protocol Specific Requirements

   Assuming that link state routing protocols meet above requirements,
   running a link state protocol among RBridges is straightforward.  It 
   is the same as running a level 1 routing protocol in an area.  This 
   would be theoretically true for either IS-IS or OSPF, assuming that
   both of these meet the general requiremenst above. 

   From the perspective of simply extending existing routing protocols,
   IS-IS is a more appropriate choice than OSPF because it is easy in 
   IS-IS to define new TLVs for use in carrying a new information type.

   This document, however, does not mandate a specific link-state, IGP,
   routing protocol.  Instead, it sets forth the requirements that will
   apply to any link-state routing protocol that may be used.

   For implementations providing co-located Router/RBridge function,
   it is necessary to have mechanisms for distinguishing any protocol 
   interactions in Routing instances from protocol interactions in the
   co-located RBridge instance.  Specific mechanisms we will use are
   very likely to be determined by the Link State Routing Protocol that



Gray                      Expires March, 2007                 [Page 6]

Internet-Draft        TRILL Routing Requirements       September, 2006



   we select.  Potential distinguishing mechanisms include use of a new
   well-known Ethernet/802 multicast address, higher-layer protocol ID
   or other - routing protocol specific - approaches.

   The mechanism chosen should be consistent with the TRILL goals.  If, 
   for example, a routing protocol specific approach required use of a
   unique "area" identifier, the RBridge area identifier should be a 
   constant, well-known, value for all RBridges, and would not be one 
   that would ever appear as a real routing area identifer - in order 
   to allow for a potential for configuration-free operation. 

   Information that RBridge link state information will carry includes: 

   o  layer 2 addresses of nodes within the domain which have 
      transmitted frames but have not transmitted ARP or ND replies  

   o  layer 3, layer 2 addresses of IP nodes within the domain.  For 
      data compression, perhaps only the portion of the address 
      following the domain-wide prefix need be carried.  This will be 
      more of an issue for IPv6 than for IPv4. 

   o  VLANs directly connected to this RBridge 


Sgai 7> The discussion about VLAN needs to be much more extensive. It is
clear from the mailing list discussion that VLANs can be used inside the
packet or in the Ethernet encapsulation of TRILL. These are two
different kinds of VLANs and their requirement need to be stated
separately. Q in Q needs also to be discussed. I propose to define inner
and outer VLANs (with reference to the position of the tag in the frame.

@@@ Based on the discussions that have been going on, I feel a bit
clearer about VLANs than I used to. It seems hard to make a simple,
brief, definiteive statement about Rbridges and VLANs, except that all
the VLAN stuff needs to be configured, because there are so many
different scenarios. I agree that a fairly extensive discussion of VLANs
should appear somewhere but I don't think this is the right document for
that. The requirement on the Rbridge routing expressed here is that it
needs, one way or the other, to be able to handle station identification
not just as a MAC address but as a VLAN tag and MAC address.

   Endnode information need only be delivered to RBridges supporting
   the VLAN in which the endnode resides. 

Sgai 8> endnode -> station

   So, for instance, if endnode
   E is discovered through a VLAN A frame, then E's location need only
   be delivered to other RBridges that are attached to VLAN A links. 

   Given that RBridges must support delivery only to links within a VLAN

   (for multicast or unknown frames marked with the VLAN's tag), this 
   mechanism can be used to advertise endnode information solely to the
   RBridges "within" a VLAN (i.e. - having connectivity or configuration
   that assoicates them with a VLAN). 

   Although a separate instance of 
   the link state protocol could be run for this purpose, the topology 
   is so restricted (just a single broadcast domain), that it may be 
   preferable to define special case mechanisms whereby each DR 

sgai 9> DR? Designated RBridge???

@@@ Yes, I think it should be spelled out.

   advertises attached endnodes, and receives explicit acknolegments
   from other RBridges. 


4. Potential Issues 

4.1. Interactions with Spanning Tree Forwarding and Bridge Learning 

   Spanning tree forwarding applies within parts of the RBridge domain,
   where two or more RBridges are connected by a link that includes
   multiple 802.1 bridges.




Gray                      Expires March, 2007                 [Page 7]

Internet-Draft        TRILL Routing Requirements       September, 2006



   In order to simplify the interactions between RBridges and bridges -
   in particular, relative to spanning tree forwarding - RBridges do not
   actively participate in spanning tree protocol with 802.1 bridges.

Sgai 10> "do not participate actively" can mean two different things:
1) they drop the BPDU
2) they propagate the BPDUs as regular multicast frames

can you clarify?

@@@ They block BPDUs but might do something based on their receipt.
Another way to look at it is that an Rbridge with N interfaces, each
connected to bridged links, looks like N different leaf nodes to the
STP/RSTP running on those bridged links. (Could be N different spanning
trees or less than that if some of these links are connected or bridged
to each other.)

   Hence, from the Link State Routing protocol perspective, the protocol
   will be able to treat spanning tree links as indistinguishable from
   any other Ethernet/802.1 link, in the same way that routing protocols
   do today.

   However, support for multi-pathing is potentially problematic and is 
   assumed - in this document - to be a non-goal.  Multi-path forwarding
   has the potential to confound the bridge learning process.

Sgai 11> multi-pathing a non-goal? This seems to be in contradiction
with what said before. Is it because of the designated RBridge?

Sgai 12> the requirement for a designated RBridge is not really
discussed here. In particular there is no discussion of the property of
the election algorithm, which must avoid broadcast storms.

@@@ Seems like the ideal thing would be to state the requirements that
having a Designated Rbridge meets rather then the mechanism of having a
Designated Rbridge.

@@@ Some general statement about convergence and an acceptably low level
of overhead traffic for all of the mechanisms associated with the
routing protocol might be reasonable.


4.2. Computing Routes

   RBridges must calculate an L2 "route table" consisting of Next Hop 
   information for each known L2 unicast destination address within a 
   (possibly VLAN scoped) broadcast domain. This is computed using a
   routing protocol's SPF algorithm and based on destination layer 2
   address reachability advertisements.

Sgai 13> from the previous sentence it seems that we are computing the
topology among all the MAC addresses. What we really do is compute the
topology among RBridges and then tag it with reachable MAC addresses.
>From the SPF perspective, it is a much easier problem.

... snip ...


@@@ Thanks,
@@@ Donald