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

Any wording that clarify which among these possible cases TRILL
implements:

1) drop BPDUs
2) receive BPDU, examine them to acquire information, but not pass them
to STP
3) in addition of 2) also generate some BPDU's behaving as STP
4) run STP

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Monday, November 06, 2006 10:49 AM
> To: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
> Subject: RE: [rbridge] WG last call
>
commentsto:http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-
> reqs-00.txt
> 
> Silvano,
> 
> 	Let's not be stubborn about wording.  You don't like the phrase
> "drop BPDUs."  I think it's fair to observe that "process BPDUs" is
> not quite accurate either.
> 
> 	The intention is that implementations MAY examine BPDUs in an
> effort to maintain awareness of network conditions, but they are not
> to "process" them in the usual sense of STP (or RSTP, or MSTP).
> 
> 	What wording would you like to see?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> --> Sent: Monday, November 06, 2006 1:16 AM
> --> To: Eastlake III Donald-LDE008; rbridge at postel.org
> --> Subject: Re: [rbridge] WG last call
> --> commentsto:http://www.ietf.org/internet-drafts/draft-ietf-tr
> --> ill-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-tr
> --> ill-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-rout
> --> ing-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
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> rbridge at postel.org
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->