Subject: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 1 Nov 2006 18:19:28 -0800

Eric,

In the spirit of making progress the compromise I can accept is: 
"Ethernet: In this document the term "Ethernet" is used to represent
both IEEE 802.3 and its bridging component as described in IEEE 802.1D
and IEEE 802.1Q"

I am also OK if you want to say something like: "any IEEE 802 Local Area
Network that provides an Ethernet service will automatically be able to
take advantage of and be usable by TRILL"

Fell free to improve my English.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Wednesday, November 01, 2006 9:46 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	I think that there may be a compromise we can arrive at here.
> 
> 	I propose changing the defintion of "Ethernet" to read:
> 
> 'Ethernet: In this document the term "Ethernet" is used to represent
>  Ethernet-like and/or Ethernet-equivalent technologies - explicitly
>  including 802.3 [802.3 ref], 802.1Q [802.Q ref] and other closely
>  related LAN technologies, and NOT explicitly excluding any other
>  Ethernet-like and/or Ethernet-equivalent technology that exists, or
>  may be developed in the future.'
> 
> 	Using this definition should clarify that I am not necessarily
> using the term in the way that some people may feel it should be used,
> while clearly stating what I am using the term to mean.  This should
> also reduce your concern that I am apprently equating Ethernet and
> 802 in general.  It also satisfies my intention to be inclusive.
> 
> 	How does this sound?
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> Sent: Wednesday, November 01, 2006 1:21 AM
> --> To: Gray, Eric
> --> Cc: rbridge at postel.org
> --> Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> -->
> --> Eric,
> -->
> --> I disagree.
> -->
> --> I don't think it is wise for TRILL to redefine the term Ethernet.
> --> Ethernet is a term that has a well known meaning in the industry.
> --> The original definition is:
> --> Digital Equipment Corporation, Intel, Xerox, The Ethernet,
> --> Version 2.0,
> --> November 1982.
> --> Which has been then standardized by IEEE 802.3.
> -->
> --> To speak about other IEEE 802 standards that are alive and
> --> used, IEEE
> --> 802.11 (Wireless LAN) and IEEE 802.17 (Resilient Packet
> --> Ring Working)
> --> have nothing to do with Ethernet.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> --> > Sent: Tuesday, October 31, 2006 2:44 PM
> --> > To: Silvano Gai
> --> > Cc: rbridge at postel.org
> --> > Subject: RE: [rbridge] Comments on:
http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> >
> --> > Silvano,
> --> >
> --> > 	To be perfectly frank, I am unaware of any reason not to
> include
> --> > token ring or any other obsolete form of "Ethernet equivalent
> --> technology"
> --> > - this is one of the reason to focus on the SHIM as
> --> separate from any
> --> > specific encapsulation above or below the SHIM.
> --> >
> --> > 	If you want to check it against all 802 activities,
that's
> fine.
> --> > I would suggest, however, that even though people are
> --> realistically
> --> not
> --> > going to implement most of the hairy/scary versions in an
> --> RBridge, I
> --> do
> --> > not know of a good reason to exclude them at this point.
> --> In abstract,
> --> > it is certainly possible that people will be able to work out
> --> specifics
> --> > of implementation - if and when they decide to do so.
> --> >
> --> > 	After all, we (the industry) have been building
translation
> --> bridges
> --> > for these technologies for decades.
> --> >
> --> > 	However, I am open to scoping the architecture to apply
only
> to
> --> a
> --> > limited subset of 802 technologies, if that is what would
> --> make people
> --> > happy...
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> > --> Sent: Tuesday, October 31, 2006 5:34 PM
> --> > --> To: Gray, Eric
> --> > --> Cc: rbridge at postel.org
> --> > --> Subject: RE: [rbridge] Comments on:
> --> > --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> > --> -arch-01.txt
> --> > -->
> --> > -->
> --> > --> Eric,
> --> > -->
> --> > --> A quick reply:
> --> > --> Are you telling me that the term Ethernet includes Token
Ring,
> --> Token
> --> > --> Bus, DQDB?
> --> > -->
> --> > --> This is what you are doing when you say that Ethernet
> --> is IEEE 802
> --> > --> instead of IEEE 802.3.
> --> > -->
> --> > --> This is NOT a terminology issue. If the term Ethernet means
> --> > --> 802 I need
> --> > --> to check the operation of TRILL against all the 802
> --> technologies.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> --> > --> > Sent: Tuesday, October 31, 2006 1:46 PM
> --> > --> > To: Silvano Gai
> --> > --> > Cc: rbridge at postel.org
> --> > --> > Subject: RE: [rbridge] Comments on:
> --> http://www.ietf.org/internet-
> --> > --> > drafts/draft-ietf-trill-rbridge-arch-01.txt
> --> > --> >
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 4> an RBridge must be also able to send
> --> two copies of a
> --> > --> > --> unicast/multicast/broadcast packet on the same
> --> port when it
> --> > --> > --> acts as a designated RBridge (one copy is
> --> encapsulated, the
> --> > --> > --> other not).
> --> > --> > -->
> --> > --> >
> --> > --> > This, I think, refers to the immediately preceding
> --> text in the
> --> > --> > architecture:
> --> > --> >
> --> > --> >         Forwarding information is derived from the
> --> combination
> --> of
> --> > --> >         attached MAC address learning, snooping of
> --> > --> multicast-related
> --> > --> >         protocols (e.g. - IGMP), and routing
> --> > --> advertisements and path
> --> > --> >         computations using the link-state routing
protocol.
> --> > --> >
> --> > --> > While your comment is a reasonable one - although
> --> potentially
> --> > --> > implementation specific - it does not appear to
> --> have any bearing
> --> > --> > on this text.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > --> Sgai 5> here there is some confusion between
> --> 802 and 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > This  refers (I believe) to the immeditately preceding
text:
> --> > --> >
> --> > --> >         The following terminology is defined in
> --> other documents.
> --> A
> --> > --> brief
> --> > --> >         definition is included in this section for
> --> > --> convenience and -
> --> > --> in
> --> > --> >         some cases - to remove any ambiguity in how the
> --> > --> term may be
> --> > --> used
> --> > --> >         in this document, as well as derivative documents
> --> > --> intended to
> --> > --> >         specify components, protocol, behavior and
> --> encapsulation
> --> > --> >         relative to the architecture specified in
> --> this document.
> --> > --> >
> --> > --> >         o  802: IEEE Specification for the Ethernet
> --> architecture,
> --> > --> i.e.,
> --> > --> >            including hubs and bridges.
> --> > --> >
> --> > --> > In this text, I explicitly state that these terms
> --> are defined
> --> > --> elsewhere.
> --> > --> > I am also trying to use the most generic definition
> --> of Ethernet
> --> > --> possible.
> --> > --> >
> --> > --> > The reason for this is that the problem statement does
> --> > --> not restrict
> --> > --> the
> --> > --> > solution to 802.3.
> --> > --> >
> --> > --> > There is some confusion in referring to 802.3 in
> --> any case: we
> --> > --> explicitly
> --> > --> > want to include 802.1Q - as well as all of its
> --> variations and
> --> > --> extensions.
> --> > --> >
> --> > --> > Consequently, we define the term Ethernet in the broadest
> --> possible
> --> > --> sense.
> --> > --> >
> --> > --> >
> --> > --> > -- [snip] --
> --> > --> > -->
> --> > --> > -->        o  Bridge Spanning Tree (BST): an Ethernet (L2,
> --> 802.1D)
> --> > --> > -->           forwarding protocol based on the topology
> --> > --> of a spanning
> --> > --> > tree.
> --> > --> > -->
> --> > --> > --> Sgai 6> I have never seen the acronym BST,
> --> everyone use STP.
> --> > --> > -->
> --> > --> >
> --> > --> > I do not know if this term is used in any of the other
> --> documents,
> --> > --> > but it is not used in this one.  Unless someone
> --> objects, I am
> --> only
> --> > --> > too happy to remove it from this document.
> --> > --> >
> --> > --> > From a historical perspective, this was defined this way
> --> > --> originally
> --> > --> > because we were re-using the term spanning tree instead
> --> > --> of IRT.  It
> --> > --> > was causing amazing communication difficulties, so
> --> we came up
> --> with
> --> > --> > the term IRT.  Now we don't need to differentiate BST.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 7> for Ethernet is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Hub: an Ethernet (L2, 802) device with
> --> > --> multiple ports
> --> > --> which
> --> > --> > -->
> --> > --> > --> sgai 8> for Hub is better to reference 802.3
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (Sgai 5) above.  By the
> --> > --> definition we
> --> > --> > provide in this document, Ethernet is defined
> --> broadly to include
> --> > --> > 802 technologies.  This is reasonable, because the term
was
> --> stolen
> --> > --> > by IEEE from a technology stolen from a satellite
> --> communication
> --> > --> > protocol.  Ironic that 802.3 does not include wireless,
all
> --> things
> --> > --> > considered.  Certainly the term "Ethernet" should...
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Node: a device with an L2 (MAC) address
> --> > --> that sources
> --> > --> and/or
> --> > --> > -->            sinks L2 frames.
> --> > --> > -->
> --> > --> > --> Sgai 9> The IEEE term is "station".
> --> > --> > -->
> --> > --> >
> --> > --> > However, we in the IETF are more familiar with the
> --> term "node."
> --> > --> >
> --> > --> > This is hardly a significant issue.  if people agree that
> --> > --> we should
> --> > --> > use the term "station" as opposed to "node", then I will
> --> > --> change it.
> --> > --> >
> --> > --> > Note that we should be consistent in this usage, if we
> --> > --> decide to do
> --> > --> > yet another terminology evolution.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Segment: an Ethernet link, either a single
> --> physical
> --> > --> link or
> --> > --> > -->            emulation thereof (e.g., via hubs) or a
> --> > --> logical link or
> --> > --> > -->            emulation thereof (e.g., via bridges).
> --> > --> > -->
> --> > --> > --> Sgai 10> IEEE uses the term "LAN segment"
> --> > --> > -->
> --> > --> >
> --> > --> > I agree, however this is the definition we agreed on here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Subnet, Ethernet: a single segment,
> --> or a set of
> --> > --> segments
> --> > --> > -->            interconnected by a CRED (see
> --> section 2.2); in
> --> the
> --> > --> latter
> --> > --> > -->
> --> > --> > --> sgai 11> There is no concept of subnet in IEEE.
> --> Subnet is
> --> > --> typically
> --> > --> > --> an IP subnet, and, even if it is common to have
> --> one subnet
> --> per
> --> > --> LAN,
> --> > --> > --> this is not the only possibility. Pragmatically
> --> IP subnets
> --> and
> --> > --> > --> Ethernet LAN are unrelated concepts.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, we are defining this term for use in this
> --> > --> document.  Does its
> --> > --> > use (not its definition) cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            case, the subnet may or may not be
> --> equivalent to
> --> a
> --> > --> single
> --> > --> > -->            segment. Also a subnet may be
> --> referred to as a
> --> > --> broadcast
> --> > --> > -->            domain or LAN. By definition, all
> --> nodes within an
> --> > --> Ethernet
> --> > --> > -->            Subnet (broadcast domain or LAN) must have
L2
> --> > --> connectivity
> --> > --> > -->            with all other nodes in the same
> --> Ethernet subnet.
> --> > --> > -->
> --> > --> > -->         o  TRILL: Transparent Interconnect over Lots
> --> > --> of Links -
> --> > --> the
> --> > --> > -->            working group and working name for the
> --> > --> problem domain
> --> > --> to be
> --> > --> > -->            addressed in this document.
> --> > --> > -->
> --> > --> > -->         o  Unicast Forwarding: forwarding methods
> --> > --> that apply to
> --> > --> frames
> --> > --> > -->            with unicast destination MAC addresses.
> --> > --> > -->
> --> > --> > -->         o  Unknown Destination - a destination
> --> for which a
> --> > --> receiving
> --> > --> > -->            device has no filtering database entry.
> --> > --> Destination
> --> > --> (layer
> --> > --> > -->
> --> > --> > --> sgai 12> the stations receive the unknown
> --> unicast and have
> --> > --> filtering
> --> > --> > --> information, only the bridges don't. I propose to
> --> > --> replace device
> --> > --> with
> --> > --> > --> bridge.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, it is the intention to provide as broad a
> --> definition as
> --> > --> possible
> --> > --> > without introducing confusion or ambiguity.  An end node
> --> > --> (or station)
> --> > --> > has - in a sense - a filtering database (it's mine, or
> --> > --> it's for the
> --> > --> bit
> --> > --> > bucket).
> --> > --> >
> --> > --> > We need to explicitly include 802.1D forwarding devices
> --> > --> and RBridges.
> --> > --> >
> --> > --> > However, the definition should specify "forwarding
> --> device" - as
> --> > --> opposed
> --> > --> > to just "receiving device."
> --> > --> >
> --> > --> > I will change that.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            2) addresses are typically "learned"
> --> by (layer 2)
> --> > --> > forwarding
> --> > --> > -->            devices via a process commonly referred to
> --> > --> as "bridge
> --> > --> > learning".
> --> > --> > -->
> --> > --> > --> Sgai 13> in IEEE, the term used is "learning" instead
> --> > --> of "bridge
> --> > --> > learning"
> --> > --> > -->
> --> > --> >
> --> > --> > However, the term defined in this document is
> --> "bridge learning."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  VLAN: Virtual Local Area Network. VLANs in
> --> > --> general fall
> --> > --> > into
> --> > --> > -->            two categories: link (or port)
> --> specific VLANs and
> --> > --> tagged
> --> > --> > -->            VLANs. In the former case, all frames
> --> > --> forwarded and all
> --> > --> > -->            directly connected nodes are assumed to be
> --> > --> part of a
> --> > --> single
> --> > --> > -->            VLAN.  In the latter case, VLAN tagged
> --> > --> frames are used
> --> > --> to
> --> > --> > -->            distinguish which VLAN each frame is
intended
> --> for.
> --> > --> > -->
> --> > --> > --> Sgai 14> This definition is not completely correct, I
> --> prefer:
> --> > --> > -->
> --> > --> > --> VLAN technology introduces the following three
> --> basic types
> --> of
> --> > --> frame:
> --> > --> > --> a) Untagged frames;
> --> > --> > --> b) Priority-tagged frames; and
> --> > --> > --> c) VLAN-tagged frames.
> --> > --> > -->
> --> > --> > --> An untagged frame or a priority-tagged frame does not
> --> > --> carry any
> --> > --> > --> identification of the VLAN to which it belongs. Such
> --> > --> frames are
> --> > --> > --> classified as belonging to a particular VLAN based on
> --> > --> parameters
> --> > --> > --> associated with the receiving Port, or, through
> --> proprietary
> --> > --> extensions
> --> > --> > --> to IEEE 802.1Q standard, based on the data content of
> --> > --> the frame
> --> > --> (e.g.,
> --> > --> > --> MAC Address, layer 3 protocol ID, etc.).
> --> > --> > -->
> --> > --> > --> A VLAN-tagged frame carries an explicit
> --> > --> identification of the VLAN
> --> > --> to
> --> > --> > --> which it belongs; i.e., it carries a tag header
> --> that carries
> --> a
> --> > --> non-
> --> > --> > null
> --> > --> > --> VID. Such a frame is classified as belonging to a
> --> > --> particular VLAN
> --> > --> > based
> --> > --> > --> on the value of the VID that is included in the tag
> --> > --> header. The
> --> > --> > presence
> --> > --> > --> of the tag header carrying a non-null VID means that
> --> > --> some other
> --> > --> > device,
> --> > --> > --> either the originator of the frame or a
> --> VLAN-aware Bridge,
> --> has
> --> > --> mapped
> --> > --> > --> this frame into a VLAN and has inserted the
> --> appropriate VID.
> --> > --> > -->
> --> > --> >
> --> > --> > So, you're getting into the details of the
> --> technology and - in
> --> > --> particular
> --> > --> > the encapsulation.  I will expand the definition to
> --> include a
> --> > --> possibility
> --> > --> > that other criteria may be used to define a "VLAN port" -
> --> although
> --> > --> this is
> --> > --> > isomorphic to a logical model in which a device
> --> > --> implementation uses
> --> > --> some
> --> > --> > criteria to decide that a subset of the traffic received
> --> > --> on a specific
> --> > --> > physical port is to be forwarded as if received on a
> --> > --> specific logical
> --> > --> > port.
> --> > --> >
> --> > --> > The key point in this definition is that a VLAN is a
> --> > --> "Virtual LAN" -
> --> > --> > meaning
> --> > --> > it consists of a subset of the physical and L2
connectivity
> --> > --> corresponding
> --> > --> > to
> --> > --> > a "logical LAN."  The intent is to "rise above" the
> --> technological
> --> > --> > approaches
> --> > --> > and encapsulations to establish a generic definition that
> --> > --> is loosely
> --> > --> tied
> --> > --> > to
> --> > --> >
> --> > --> > ways that this generic definition is actually implemented.
> --> > --> >
> --> > --> > Again, bearing in mind the way that the term is
> --> defined, does
> --> the
> --> > --> usage of
> --> > --> > the term cause confusion or ambiguity?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Forwarding Table (CFT): the per-hop
> --> forwarding
> --> > --> table
> --> > --> > -->            populated by the RBridge Routing Protocol;
> --> > --> forwarding
> --> > --> > within
> --> > --> > -->            the CRED is based on a lookup of the
> --> CRED Transit
> --> > --> Header
> --> > --> > -->            (CTH) encapsulated within the
> --> outermost received
> --> L2
> --> > --> header.
> --> > --> > -->            The outermost L2 encapsulation in this
> --> > --> case includes
> --> > --> the
> --> > --> > -->            source MAC address of the immediate
> --> > --> upstream RBridge
> --> > --> > -->            transmitting the frame and destination MAC
> --> > --> address of
> --> > --> the
> --> > --> > -->            receiving RBridge for use in the unicast
> --> forwarding
> --> > --> case.
> --> > --> > -->
> --> > --> > --> Sgai 15> In section 7 of
> --> > --> > -->
> --> > -->
> --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-
> --> > --> > 00.txt
> --> > --> > --> we proposed that when two rbridges are
> --> connected by a point
> --> to
> --> > --> point
> --> > --> > --> link the outer MAC addresses may be set to a
> --> > --> predefined value in
> --> > --> > --> transmission and ignored in reception.
> --> > --> > -->
> --> > --> >
> --> > --> > I'm not sure how your proposal intends to determine that
> --> > --> a link is in
> --> > --> > fact point-to-point and does not just look that way.
> --> > --> >
> --> > --> > I prefer to use the same encapsulation in all cases where
it
> --> will
> --> > --> work.
> --> > --> >
> --> > --> > The optimization associated with using some form of
> --> > --> null-encapsulation
> --> > --> > is of dubious value, given that it may not be possible to
> --> > --> be certain a
> --> > --> > point-to-point link is - and will remain - in fact a
> --> > --> point-to-point
> --> > --> > link.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CFT-IRT: a forwarding table used for
> --> propagation
> --> of
> --> > --> > -->            broadcast, multicast or flooded
> --> frames along the
> --> > --> Ingress
> --> > --> > -->            RBridge Tree (IRT).
> --> > --> > -->
> --> > --> > --> Sgai 16> is it a forwarding table or is it a
> --> > --> filtering database.
> --> > --> Since
> --> > --> > --> the "miss" behavior is to flood, I see it as a
> --> > --> filtering database.
> --> > --> > -->
> --> > --> >
> --> > --> > What state was "miss" behavior from - Hawaii?  :-)
> --> > --> >
> --> > --> > It is analogous to a filtering database entry, but it is
not
> --> that.
> --> > --> >
> --> > --> > Clearly there are more things in this world than can be
> --> classified
> --> > --> > in this taxonomy.  However, given these choices, it is a
> --> > --> forwarding
> --> > --> > table.
> --> > --> >
> --> > --> > This is not a misbehavior, in that the same "base" tree
> --> > --> is used for
> --> > --> > broadcast and multicast traffic as well as flooded
> --> > --> traffic.  It may
> --> > --> > be arguable that flooding is a misbehavior, but I
> --> seem to recall
> --> > --> > that people still see it as a necessary evil.
> --> > --> >
> --> > --> > It is also not "miss" behavior (as in "cache miss") in
> --> > --> the multicast
> --> > --> > and broadcast case, either.
> --> > --> >
> --> > --> > I believe the definition is quite correct and easy to
> --> understand,
> --> > --> > provided you're not reading it with preconceived
> --> misconceptions
> --> > --> > about its meaning.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Header (CTH): a 'shim'
> --> header that
> --> > --> > encapsulates
> --> > --> > -->            the ingress L2 frame and persists
> --> throughout the
> --> > --> transit of
> --> > --> > a
> --> > --> >
> --> > --> > -->            CRED, which is further encapsulated within
> --> > --> a hop-by-hop
> --> > --> L2
> --> > --> > -->            header (and trailer). The hop-by-hop L2
> --> > --> encapsulation
> --> > --> in
> --> > --> > this
> --> > --> >
> --> > --> > -->            case includes the source MAC address of
> --> > --> the immediate
> --> > --> > -->            upstream RBridge transmitting the frame
> --> > --> and destination
> --> > --> MAC
> --> > --> > -->            address of the receiving RBridge -
> --> at least in
> --> the
> --> > --> unicast
> --> > --> > -->            forwarding case.
> --> > --> > -->
> --> > --> > --> Sgai 17> is this true also for unknown unicast?
> --> > --> > -->
> --> > --> >
> --> > --> > That is something that will be (may be already)
> --> decided in the
> --> > --> protocol
> --> > --> > specification.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  CRED Transit Table (CTT): a table that maps
> --> ingress
> --> > --> frame
> --> > --> > L2
> --> > --> > -->            destinations to egress RBridge
> --> addresses, used to
> --> > --> determine
> --> > --> > -->            encapsulation of ingress frames for
> --> transit of
> --> the
> --> > --> CRED.
> --> > --> > -->
> --> > --> > -->         o  Cooperating RBridges - those RBridges
> --> > --> within a single
> --> > --> > -->            Ethernet Subnet (broadcast domain or LAN)
> --> > --> not having
> --> > --> been
> --> > --> > -->            configured to ignore each other. By
> --> default, all
> --> > --> RBridges
> --> > --> > -->            within a single Ethernet subnet will
> --> cooperate
> --> with
> --> > --> each
> --> > --> > -->            other. It is possible for implementations
> --> > --> to allow for
> --> > --> > -->            configuration that will restrict
> --> > --> "cooperation" between
> --> > --> an
> --> > --> > -->            RBridge and an apparent neighboring
> --> RBridge.  One
> --> > --> reason
> --> > --> > why
> --> > --> > -->            this might occur is if the trust model
> --> > --> that applies in
> --> > --> a
> --> > --> > -->            particular deployment imposes a need for
> --> > --> configuration
> --> > --> of
> --> > --> > -->            security information.  By default no such
> --> > --> configuration
> --> > --> is
> --> > --> > -->            required however - should it be used in
> --> > --> any specific
> --> > --> > scenario
> --> > --> > -->
> --> > --> > -->            - it is possible (either deliberately or
> --> > --> inadvertently)
> --> > --> to
> --> > --> > -->            configure neighboring RBridges so
> --> that they do
> --> not
> --> > --> > cooperate.
> --> > --> > -->
> --> > --> > -->            In the remainder of this document,
> --> all RBridges
> --> are
> --> > --> assumed
> --> > --> > -->            to be in a cooperating (default)
> --> configuration.
> --> > --> > -->
> --> > --> > --> Sgai 18> can RBridges cooperate in groups, e.g. four
> --> Rbridges
> --> > --> > connected
> --> > --> > --> to a LAN cooperating two and two?
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.  There may be reasons why this might be done
> --> deliberately,
> --> > --> however
> --> > --> > - even in the absence of any "proof of concept"
> --> > --> justification - it is
> --> > --> a
> --> > --> > really good idea to design the protocol to be robust in
> --> > --> cases where a
> --> > --> > set of RBridges may be (mis)configured in such a way as
> --> > --> to be unable
> --> > --> to
> --> > --> > discover each other.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  Ingress RBridge Tree: a tree
> --> computed for each
> --> edge
> --> > --> RBridge
> --> > --> > -->            and potentially for each VLAN in which that
> --> RBridge
> --> > --> > -->
> --> > --> > --> sgai 19> why for each VLAN? I got the
> --> impression that there
> --> > --> > --> was a single tree that was pruned differently for
> --> > --> different VLANs.
> --> > --> > -->
> --> > --> >
> --> > --> > Pruning may also take place at the ingress, if - for
> --> > --> example - it has
> --> > --> a
> --> > --> > subset of interfaces that are not connected to any
> --> egress for
> --> > --> particular
> --> > --> > VLANs.  It is a small point but, in such cases, there is
in
> --> effect
> --> > --> more
> --> > --> > than one IRT even at the ingress.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->            participates - for delivery of broadcast,
> --> > --> multicast and
> --> > --> > -->            flooded frames from that RBridge to all
> --> > --> relevant egress
> --> > --> > -->            RBridges. This is the point-to-multipoint
> --> > --> delivery tree
> --> > --> > used
> --> > --> > -->            by an ingress RBridge to deliver
> --> > --> multicast, broadcast
> --> > --> or
> --> > --> > -->            flooded traffic.
> --> > --> > -->
> --> > --> > --> Sgai 20> the current version of the proposal
> --> speaks about a
> --> > --> multicast
> --> > --> > --> address, not point-to-point.
> --> > --> > -->
> --> > --> >
> --> > --> > I did not say "point-to-point" (look again).
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->         o  LPT: Learned Port Table. See
> --> Filtering Database.
> --> > --> > -->
> --> > --> > --> Sgai 21> not proper terminology, I would use
> --> > --> "filtering database"
> --> > --> > --> everywhere.
> --> > --> > -->
> --> > --> >
> --> > --> > I am happy to remove this if there is no objection
> --> to my doing
> --> so.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a
> --> > --> > --> wireless port is not Ethernet, it is IEEE 802.11.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 8) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 23> they learn because STP guarantees
> --> > --> symmetrical forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > This (apparently) refers to the immeditately preceding
text:
> --> > --> >
> --> > --> >         Conventional bridges contain a learned port table
> --> > --> (LPT), or
> --> > --> >         filtering database, and a spanning tree table
> --> > --> (STT). The LPT
> --> > --> >         allows a bridge to avoid flooding all received
> --> > --> frames, as is
> --> > --> >         typical for a hub or repeater. The bridge learns
> --> > --> which nodes
> --> > --> are
> --> > --> >         accessible from a particular port by assuming
> --> > --> bi-directional
> --> > --> >         consistency:
> --> > --> >
> --> > --> > I'm not sure how picking at the peculiarities of
> --> STP behavior is
> --> > --> > relevant to this description.  STP results in a
> --> single spanning
> --> > --> > tree where each link is bi-directional.  This
> --> ensures that the
> --> > --> > MAC frames are forwarded in a bi-directionally consistent
> --> fashion.
> --> > --> >
> --> > --> > To replace this text with yours is to provide less
> --> information.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 24> active ports -> forwarding ports
> --> > --> > -->
> --> > --> >
> --> > --> > "Active ports" was the exact wording suggested to me.  In
> --> > --> context for
> --> > --> > this working group "active ports" is more meaningful than
> --> > --> "forwarding
> --> > --> > ports."  For people not used to STP-speak, "forwarding
> --> > --> port" might be
> --> > --> > used to discriminate from a "code port."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 25> there is no STT, there is a state associated
> --> > --> with each
> --> > --> port
> --> > --> > --> that can be: disabled, blocking, listening,
> --> learning, and
> --> > --> forwarding
> --> > --> > -->
> --> > --> >
> --> > --> > Other than the issue with terminology, is this text
> --> wrong?  I am
> --> > --> fairly
> --> > --> > sure that different implementations handle the "port
state"
> --> > --> information
> --> > --> > in different ways, and I am also reasonably sure that a
> --> > --> "table" such
> --> > --> as
> --> > --> > the one described here is one of the ways it might be
done.
> --> > --> >
> --> > --> > However, I agree with your assertion that this is the way
> --> > --> that it is
> --> > --> > usually talked about in an IEEE context, so -
> --> unless there are
> --> > --> specific
> --> > --> > objections - I can change the wording to be consistent
> --> > --> with what you
> --> > --> > suggest.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 26> disabled -> blocking
> --> > --> > -->
> --> > --> >
> --> > --> > I can make this change as well.  However, from the
> --> > --> perspective of what
> --> > --> > we are trying to do, "disabled" is potentially a more
> --> > --> correct term.
> --> > --> It
> --> > --> > is certainly more intuitively correct, outside of a
> --> > --> strictly IEEE/STP
> --> > --> > context.
> --> > --> >
> --> > --> > Symmetry is maintained in STP by blocking ports/links
> --> > --> bi-directionally.
> --> > --> > In such cases, a port is effectively disabled for bridges
> --> > --> at either
> --> > --> end
> --> > --> > of the link for which a port is blocked, is it not?
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 27> I repeat a comment that I have made to other
> --> > --> documents: "
> --> > --> > --> 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."
> --> > --> > --> Here I think we are talking about outer VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > I responded to this in separate mail.  I wait to hear
> --> > --> other opinions
> --> > --> on
> --> > --> > this subject.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 28> IMO all RBridges must be ingress RBridges,
> --> > --> at least to
> --> > --> > support
> --> > --> > --> inband management, e.g. SNMP.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > In order to ensure symmetry with RBridges not
> --> > --> participating in STP,
> --> > --> there
> --> > --> > MUST be a designated RBridge that does all of the
> --> sending and
> --> > --> receiving
> --> > --> > of native encapsulated frames on a LAN segment.
> --> > --> >
> --> > --> > Any RBridge the loses the "Designated RBridge"
> --> election cannot
> --> be
> --> > --> either
> --> > --> > an ingress or an egress for that LAN segment.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 29> same as above
> --> > --> > -->
> --> > --> >
> --> > --> > Same as above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 30> I think the previous definition is not
needed.
> --> > --> > -->
> --> > --> >
> --> > --> > This appears to refer to:
> --> > --> >
> --> > --> >         o  Local RBridge - the RBridge that forms and
> --> > --> maintains the
> --> > --> CFT-
> --> > --> >            IRT entry (or entries) under discussion. The
> --> > --> local RBridge
> --> > --> >            may be an Ingress RBridge, or an egress
> --> RBridge with
> --> > --> respect
> --> > --> >            to any set of entries in the CFT-IRT.
> --> > --> >
> --> > --> > This defintion is needed.  It is subsequently used
> --> in at least 4
> --> > --> places.
> --> > --> > When discussing the behavior of a specific RBridge
> --> > --> relative to a peer,
> --> > --> > it is convenient to define the term "local RBridge."
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 31> why is it zero or more, if an RBridge
> --> exists, it
> --> must
> --> > --> have
> --> > --> > --> a an IRT, I haven't seen any discussion to support
> --> > --> multiple IRTs.
> --> > --> > -->
> --> > --> >
> --> > --> > This was answered previously on the mailing list.
> --> > --> Briefly, zero or
> --> > --> > more is correct, given that an RBridge may not have
> --> > --> forwarding entries
> --> > --> > for frames it has received.  In these cases, a frame is
> --> > --> not forwarded.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 32> I don't understand this. Since the current
> --> > --> proposal uses
> --> > --> a
> --> > --> > --> multicast MAC address, what is needed is a bit map
> --> > --> for each IRT
> --> > --> that
> --> > --> > --> says which ports are blocking and which are
> --> > --> forwarding. You are
> --> > --> > --> basically building a ST using ISIS.
> --> > --> > -->
> --> > --> >
> --> > --> > This might be the case for a specific implementation.
> --> > --> Whether it is
> --> > --> > implemented as a "bit-mask" with "non-blocking"
> --> > --> (forwarding) ports, or
> --> > --> > is implemented as a full-blown table is largely dependent
on
> --> what
> --> > --> other
> --> > --> > information the local device requires in order to
> --> > --> properly forwad the
> --> > --> > frame.  If - for example - a device has multiple
> --> > --> different port types,
> --> > --> > it may need to have more information for each port (or
that
> --> > --> information
> --> > --> > may be added later on).
> --> > --> >
> --> > --> > All of these are implementation choices that are
> --> > --> logically represented
> --> > --> > by the table described here.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 33> I don't get the pair.
> --> > --> > -->
> --> > --> >
> --> > --> > Since this immediately follows:
> --> > --> >
> --> > --> >         Each entry would contain an indication of
> --> which single
> --> > --> interface
> --> > --> >         a broadcast, multicast or flooded frame would be
> --> > --> forwarded for
> --> > --> >         each (ingress RBridge, egress RBridge) pair.
> --> > --> >
> --> > --> > I don't get what you don't get.
> --> > --> >
> --> > --> > The pair refers to the tuple "(ingress RBridge, egress
> --> RBridge)."
> --> > --> >
> --> > --> > This might be the point at which your earlier point (Sgai
4)
> --> would
> --> > --> make
> --> > --> > sense to insert.  I had logically modeled this in my own
> --> > --> mind as two
> --> > --> > distinct "interfaces" (the reason I use this term, rather
> --> > --> thhan port),
> --> > --> > but I should clarify this.
> --> > --> >
> --> > --> > In any case, the entries are keyed by both ingress and
> --> > --> egress RBridge.
> --> > --> > While there will be entries for only those egress
> --> > --> RBridges where this
> --> > --> > local RBridge is on the shortest path (between the given
> --> > --> ingress and
> --> > --> > egress pair), there will be at most one entry per
> --> any ingress
> --> and
> --> > --> > egress pair.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 34> as a matter of fact each interface is
> --> > --> basically a set of
> --> > --> two
> --> > --> > --> interfaces, a regular one and a tunnel one, and the
> --> > --> > forwarding/blocking
> --> > --> > --> state may be different for the two.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > As per my response to your point (Sgai 28) above, not
> --> > --> every RBridge
> --> > --> has a
> --> > --> > "regular one" as you describe here.
> --> > --> >
> --> > --> > The forwarding/blocking state is not applicable as
> --> > --> RBridges don't do
> --> > --> STP.
> --> > --> >
> --> > --> > For the native interface, fowarding/blocking state is
> --> > --> analogous to the
> --> > --> > "Designated RBridge" election process.
> --> > --> >
> --> > --> > Since this point evidently applies to -
> --> > --> >
> --> > --> >
Entries
> --> would
> --> > --> also
> --> > --> >         contain any required encapsulation information,
> --> > --> etc. required
> --> > --> >         for forwarding on a given interface, and toward a
> --> > --> corresponding
> --> > --> >         specific egress RBridge.
> --> > --> >
> --> > --> > - your point, and my response, are related to the point
> --> > --> (and response)
> --> > --> > above (Sgai 33), and I will try to clarify this
> --> part as well.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 35> this protocol must be designed to avoid
> --> > --> transient loops,
> --> > --> > since
> --> > --> > --> transient loops of multicast/broadcast cause
> --> > --> broadcast storm that
> --> > --> are
> --> > --> > --> highly undesirable.
> --> > --> > -->
> --> > --> >
> --> > --> > No.
> --> > --> >
> --> > --> > The protocol needs to include a provision to prevent
> --> > --> _use_ of links
> --> > --> that
> --> > --> > may connect to transient loops.  Using a link-state
> --> > --> routing protocol
> --> > --> has
> --> > --> > clearly been demostrated to produce transient loops, but
> --> > --> the problem
> --> > --> you
> --> > --> > want to address has to do with using those links.
> --> > --> >
> --> > --> > A state-machine driven mechanism similar to STP might be
> --> > --> the approach
> --> > --> to
> --> > --> > use.
> --> > --> >
> --> > --> > Because we're incorporating TTL in the SHIM, however this
> --> > --> would need
> --> > --> to
> --> > --> > apply only to IRT traffic.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > -->
> --> > --> > --> Sgai 36> see my previous comment about VLANs
> --> > --> > -->
> --> > --> >
> --> > --> > See my previous responses.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> sgai 37> disabled -> blocking.
> --> > --> > -->
> --> > --> >
> --> > --> > See my response to your point (sgai 26) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 38> for multicast/broadcast we also need to
> --> > --> avoid transient
> --> > --> > loops.
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 39> but RBridge discovery and STP are ongoing
> --> > --> processes, why
> --> > --> do
> --> > --> > we
> --> > --> > --> want to couple their timers?
> --> > --> > -->
> --> > --> >
> --> > --> > I am not suggesting "coupling their timers."  I am
> --> saying that
> --> the
> --> > --> value
> --> > --> > chosen for a timer (if one is used) to determine when it
> --> > --> is reasonable
> --> > --> to
> --> > --> > start RBridge peer discovery should take into
> --> account the time
> --> it
> --> > --> takes
> --> > --> > for the local spanning tree resolution.
> --> > --> >
> --> > --> > I feel the reason for this is self-evident but, just to
> --> > --> clarify, think
> --> > --> > about the process we're planning to use to determine
RBridge
> --> > --> nick-names.
> --> > --> > If we start this too early, we will be re-starting it
> --> > --> many times as we
> --> > --> > "hear from" new RBridge peers when the connecting links go
> --> active
> --> > --> after
> --> > --> > local bridges go to the forwarding state.  This would
> --> > --> apply only at
> --> > --> the
> --> > --> > system start up as - after that - you are quite correct
> --> > --> in asserting
> --> > --> it
> --> > --> > would be an ongoing process.
> --> > --> >
> --> > --> > Perhaps I should add some words to indicate that a delay
> --> > --> would not be
> --> > --> > necessary if the protocol mechanisms do not introduce
> --> > --> instability as a
> --> > --> > new peer is discovered.  So far, I have not seen any
> --> > --> indication that a
> --> > --> > "race-free" solution to accomplish this has been designed
> --> > --> - or talked
> --> > --> > about.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 40> there is also a requirement to time-out
learnt
> --> > --> information to
> --> > --> > --> maintain the filtering databases.
> --> > --> > -->
> --> > --> >
> --> > --> > There would be, if we were doing that.  Instead,
> --> we're adopting
> --> a
> --> > --> > link-state routing protocol and they tend to have
> --> that covered.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 41> periodically or on demand
> --> > --> > -->
> --> > --> >
> --> > --> > See the response to your point (Sgai 40) above.
> --> > --> >
> --> > --> > -- [snip --
> --> > --> > -->
> --> > --> > --> Sgai 42> potentially there is an unencapsulated
> --> > --> interface for each
> --> > --> > --> physical interface of the RBridge. It is true that
> --> > --> you can model
> --> > --> all
> --> > --> > --> of them as a single separate logical interface, but
> --> > --> then we need
> --> > --> to
> --> > --> > --> replicate the frame according to a bitmask that tells
on
> --> which
> --> > --> > physical
> --> > --> > --> interface the RBridge is designated.
> --> > --> > -->
> --> > --> >
> --> > --> > Again, your use of a "bitmask" is an implementation
> --> > --> choice as opposed
> --> > --> > to a logical model.
> --> > --> >
> --> > --> > As you observe, I do "model all of them as a single
> --> > --> separate logical
> --> > --> > interface" and if you want to "replicate the frame
> --> according to
> --> a
> --> > --> > bitmask that tells on which physical interface the
> --> RBridge is
> --> > --> > designated" - you're absolutely free to do so.
> --> > --> >
> --> > --> > Personally, I think this is far too much implementation
> --> > --> stuff for a
> --> > --> > protocol specification, let alone an architecture
document.
> --> > --> >
> --> > --> > -->
> --> > --> > --> Sgai 43> can we clarify that this means "drop BPDUs".
> --> > --> > -->
> --> > --> >
> --> > --> > Yes.
> --> > --> >
> --> > --> > -- [snip --
> --> > -->
> -->