[rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Silvano Gai
sgai at nuovasystems.com
Tue Oct 31 14:34:21 PST 2006
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