[rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt
Gray, Eric
Eric.Gray at marconi.com
Tue Oct 31 14:43:46 PST 2006
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 --
-->
More information about the rbridge
mailing list