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

Donald,

I think I agree with most of your comments, with one big exception.

I am not able to see the difference between "dropping a BPDU" or
"ignoring a BPDU".

IMO there are two possibilities:
1) we drop BPDUs
2) we process BPDUs

If we do 2), we can:
2.1) process BPDU using STP/RSTP
2.2) do other processing on the BPDU, not STP/RSTP related

If we don't want to do 2.1), let's just say it.
If we need to do 2.2), it is better we spell it out clearly, and not
hide it behind the word "ignore BPDUs".

This is such a crucial point to achieve:
a) Interoperability
b) A robust implementation

that we don't want to be vaguely defined.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, November 05, 2006 3:22 PM
> To: rbridge at postel.org
> Subject: Re: [rbridge] WG last call
>
commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-
> reqs-00.txt
> 
> 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
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge