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: Tue, 31 Oct 2006 22:20:53 -0800

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 --
> -->

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 22:20:53 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 35968

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:[email-masked]]
> Sent: Tuesday, October 31, 2006 2:44 PM
> To: Silvano Gai
> Cc: [email-masked]
> 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:[email-masked]]
> --> Sent: Tuesday, October 31, 2006 5:34 PM
> --> To: Gray, Eric
> --> Cc: [email-masked]
> --> 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:[email-masked]]
> --> > Sent: Tuesday, October 31, 2006 1:46 PM
> --> > To: Silvano Gai
> --> > Cc: [email-masked]
> --> > 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 --
> -->

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 22:08:09 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 1056

Eric,

The charter says:
"load-splitting among multiple paths"
The pragmatic way to achieve this is to implement Layer 2 ECMP

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 9:25 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	See below...
> 
> --
> Eric
> 
> -- [snip] --
> -->
> --> Sgai 2> I think we should explicitly mention layer 2 multipath.
> -->
> -- [snip] --
> -->
> 
> What do you mean by layer 2 multipath?
> 
> Do you mean "link bundling" or something else?
> 
> Are we trying now to apply ECMP to routing advertisements for layer
> two reachability?  That's a big step, particularly when we need to
> retain compatibility with existing 802.1 bridges.
> 
> I don't recall seeing anything about this in the problem statement
> document, so I don't know of any reason why we should include it in
> the architecture.
> 
> --
> Eric

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 22:05:57 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 3149

IRTs have two problems.

1) They limit the number of Rbridges in a CRED, since each switch needs
to run a copy of Djikstra for each IRT.

2) they don't support load balancing of traffic across multiple links.
The charter says: "Load-splitting among multiple paths", it does not say
"only for unicast". TRILL needs to provide a set of trees in the CRED
(what I call shared trees) and let each ingress RBridge balance the
traffic on a subset of them.

In a network with 1000 RBridges, 1000 IRTs are computationally difficult
and don't provide load-splitting among multiple paths, 8 shared trees
are easy to compute and provide load-splitting among multiple paths.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 9:19 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	 See comments below...
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Monday, October 30, 2006 12:13 PM
> --> To: [email-masked]
> --> Subject: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> -->
> --> Comments inline marked "sgai n>"
> -->
> --> Sgai 1> This documents assumes that all multicast traffic must be
> --> propagated through the IRT (Ingress Rbridge Tree) and therefore
> --> denies any possibility for shared trees.
> 
> 
> I don't follow this comment.  Or perhaps I simply don't understand
> why this is our problem.
> 
> By creating ingress RBridge trees (as the concatenation of shortest
> path routes from an ingress to all egresses), we establish a "tree"
> which will deliver to all destinations in the broadcast domain.  If
> we then "prune" the tree for specific VLANs and multicast interest
> groups, we create "virtual trees" per-VLAN and for multicast groups.
> 
> In doing this, we are perhaps doing better than 802.1<whatever>, but
> we are still only trying to deliver broadcast, flooded and multicast
> frames to the destinations that 1) would receive them in an Ethernet
> network and 2) should receive them if optimizing an Ethernet network
> for IP multicast.
> 
> Frankly the intent to support optimization of IP multicast is a bit
> of a fragile compromise within the working group, but it is AFAIK
> what we are trying to do.
> 
> So, what I am trying to figure out is how what we're doing with the
> IRT differs from "shared tree" support with existing 802.1<whatever>
> bridges.
> 
> Are you saying that you would like RBridges to support the "shared
> tree" concept even though 802.1<whatever> bridges may or may not
> support it?
> 
> Or are you saying that there is something about the design of the
> ingress rbridge trees that get in the way of support for "shared
> trees" that might be provided in today's Ethernet bridges?
> 
> 
> -->
> --> -- Silvano
> -->
> --> --------------------------------------------------------
> -->
> --> ... snip ...

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 21:55:16 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] VLANs
Status: RO
Content-Length: 4974

Eric,

I disagree and let me give you concrete examples why:

draft-ietf-trill-rbridge-protocol-00.txt says:

"each RBridge R1 
   will run a "core" instance of IS-IS for the core RBridge information,

   and an instance per VLAN that R1 is attached to, for the endnode 
   information for those VLANs."

If we are speaking of OVLAN, IMO an RBridge runs a core instance per
each OVLAN and on that instance it propagates the endnode information
for the IVLANs."

" The endnode information for VLAN A, which is carried in the VLAN A 
   IS-IS instance injected by R1, contains:"

This clearly refers to IVLAN.

draft-ietf-trill-prob-01.txt says:

It may alternately support 
   direct VLAN support, e.g., by the use of separate TRILL routing 
   protocol instances to separate traffic for each VLAN traversing a 
   TRILL solution.  

Is this an IVLAN or an OVLAN?

draft-ietf-trill-rbridge-arch-01.txt says

Ingress RBridge Tree: a tree computed for each edge RBridge - 
           and potentially for each VLAN in which that RBridge 
           participates

I assume this is an OVLAN, I don't think TRILL computes an IRT for each
IVLAN; it can prune an IRT for each VLAN.

In an email to Dinesh you wrote:

"Dinesh,

	We're making semantic distinctions here.  I can easily define a
VLAN consisting of a group of RBridges that corresponds to the same
semantics as the FTAG.  "

Were you referring to an IVLAN or an OVLAN?

Also you claim that 16 bits are not sufficient for the RBridge ID.
Is the RBridge ID space replicated per each OVLAN or is it shared?
Does an RBridge have the same RBridge ID on all OVLANs?

I think we need to explicitly introduce the IVLAN and OVLAN concepts and
use them consistently. We don't want to hide complexity due to the lack
of nomenclature.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 9:04 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] VLANs
> 
> Silvano,
> 
> 	Actually, both "types" of VLANs are the same - applying at
> different layers, but defined using the same terminology.  Logic,
> semantics and applicability are the same.
> 
> 	For historic reasons, we are trying to avoid the terms you
> propose.  In fact, similar terms have been used previously and
> removed as confusing.  Without constant reminders, "inner" and
> "outer" will be taken in some instances as placement in the frame
> (as you are suggesting) or position relative to the CRED (a usage
> issue with the terms "ingress" and "egress" meaning "way in" and
> "way out" respectively).
> 
> 	Hence you are suggesting replacement with one potential
> are of confusion with another one we've earlier discarded.
> 
> 	The architecture document defines the term VLAN and - I am
> reasonably sure - uses that definition consistently.  Moreover,
> the architecture document tries to be agnostic about the use of
> VLANs - particularly with respect to VLAN tagged encapsulation
> and port-based VLANs, and where these things might apply.  The
> reason for this is simply that one aim of protocol development -
> especially at the architectural level - should be to avoid placing
> constraints on implementation beyond those explicitly required
> to ensure interoperability.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Monday, October 30, 2006 12:29 PM
> --> To: [email-masked]
> --> Subject: [rbridge] VLANs
> -->
> -->
> --> The second biggest issue I have with the four documents
> --> (first one being
> --> broadcast/multicast storm) is the definition of VLANs.
> -->
> --> I don't think the term VLAN is used consistently in the documents.
> -->
> --> 1) Sometimes VLAN refers to the VLANs present on the
> --> untagged frames,
> --> which must be propagated by ISIS, VLAN pruning must be
> --> performed and so
> --> on. They all share the same core instance of ISIS.
> -->
> --> 2) Sometimes VLANs refers to the fact that a CRED can be
> --> encapsulated
> --> into a VLAN (present as a 1Q tag in the outer header) and
> --> therefore ISIS
> --> will run per VLAN, i.e. there will be a core instance of
> --> ISIS per each
> --> VLAN. This seems to be the case in some part of the architectural
> --> document.
> -->
> --> I propose to name the former IVLAN (inner VLAN) and the latter
OVLAN
> --> (Outer VLAN), with reference to the position of the 1Q tag
> --> in the frame.
> -->
> --> This is also very relevant for the discussion that we need
> --> to complete
> --> on the FTAG: it is my understanding that some folks think
> --> that the FTAG
> --> is not needed, since there may be an OVLAN.
> -->
> --> Comments?
> -->
> --> -- Silvano
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 21:09:51 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 4781

Eric,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Gray, Eric
> Sent: Tuesday, October 31, 2006 8:48 AM
> To: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] New shim header proposal---without F-tag field
> 
> Radia,
> 
> 	I don't think there is consensus yet that we only need 16 bits
> for RBridge IDs.

With 16 bits, using 1 bit to indicate unicast, we can have 32K switches.
According to the current definition of TRILL, there is the need to run
Djikstra on a database with 32K records, one time for the core instance
and 32K times for the IRTs. This is clearly out of reach even for the
most powerful CPU. 

There is no point in having more bits, if the TRILL design can use them.
The current design cannot.

-- Silvano

> 
> 	I personally disagree with the part of the proposal below that
> builds in the assumption that 16 bits is sufficient.
> 
> 	My reasoning is that 16 bits may not be large enough if the
> future where some implementations may use more than one RBridge ID
> for the same device.  Some reasons for doing this are to support per
> interface (or per VLAN) IF-IF instances.
> 
> 	16 bits may get used up much more rapidly than you think if
> implementations are not explicitly forbidden to do this (which is
> not a good idea, given that there is very little that can be done
> to enforce such a prohibition - beyond deliberately choosing to use
> an "ID-space" too small to accommodate it).
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Radia Perlman
> --> Sent: Monday, October 30, 2006 9:50 PM
> --> To: [email-masked]
> --> Subject: [rbridge] New shim header proposal---without F-tag field
> -->
> --> After talking to Silvano and Dinesh to get them to explain to me
why
> --> the use of F-tag didn't multiply the number of trees that RBridges
> --> needed to compute by the number of F-tag values, they were able to
> --> explain to me why they wanted the F-tag. Here is a proposal to
> --> get the functionality they want without the use of F-tag.
> -->
> --> ***********************
> -->
> --> Motivation for F-tag
> -->
> --> They want to be able to do multipathing on multicast. We can
already
> --> do multipathing on unicast by having an RBridge keep multiple
equal
> --> cost (or near equal cost) paths to destination D, and split
traffic
> --> however it wants. But if we have a single tree for all multicast
> --> with ingress RBridge R1, then all multicast traffic has to use
> --> the same links. The original proposal was to use F-tag as a
selector
> --> for a tree. But the modified proposal is to use the "egress
RBridge"
> --> field, which wasn't all that useful for multicast, as a
> --> "tree selector".
> -->
> --> ******************************
> -->
> --> So the proposal is:
> -->
> --> In the shim header will only be:
> --> 1) 16-bit ingress RBridge
> --> 2) 16-bit egress RBridge
> --> 3) TTL
> -->
> -->
> --> How these fields will be used in order to do multipathing:
> -->
> --> a) RBridges calculate a single tree for each ingress RBridge
> -->
> --> b) For unicast, an RBridge can calculate multiple equal-cost
> --> paths to the destination (or near-equal cost), and split
> --> traffic. That
> --> is how
> --> we'd get multipathing for unicast. If S7 has two ways to get to
> --> destination D,
> --> it can send some of its traffic one way, some of it the
> --> other. This is
> --> solely
> --> S7's choice and doesn't need to be coordinated with any
> --> other switches.
> -->
> --> c) For multicast, we can provide multipathing by letting
> --> the ingress RBridge
> --> choose the distribution tree.
> --> The tree used will be indicated by the "egress RBridge"
> --> field. So, if S3 receives a multicast packet from an
> --> endnode, it puts
> --> "S3" as "ingress RBridge", but selects a tree by whatever means it
> --> wants, and puts, say, "S1" into "egress RBridge". That way
> --> the packet
> --> will be forwarded based on the tree calculated using S1 as the
root.
> -->
> --> With this proposal, we get multipathing for multicast
> --> without configuration.
> --> The same space used for RBridge nicknames can be used for
> --> choosing the
> --> tree for multicast packets. The number of trees to be
> --> calculated does
> --> not change---it is still per ingress RBridge.
> -->
> --> Radia
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 17:43:46 -0500
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 33356

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:[email-masked]] 
--> Sent: Tuesday, October 31, 2006 5:34 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> 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:[email-masked]]
--> > Sent: Tuesday, October 31, 2006 1:46 PM
--> > To: Silvano Gai
--> > Cc: [email-masked]
--> > 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 --
--> 

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 14:35:50 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 1201

Eric,

Inline

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 9:43 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	Please see below...
> 
> --
> Eric
> 
> -- [snip] --
> -->
> --> Sgai 3> It is very important to say that this protocol must
provide a
> --> loop free topology for multicast/broadcast under any condition,
> including
> --> transient loops, to prevent multicast/broadcast storm.
> -- [snip] --
> 
> I think I know what you're trying to say here, but "topology" is not
> the right word.  This is probably a point of confusion - based on the
> way STP works - that you're bringing up and I may need to fix.  I do
> not recall using "topology" in this specific context, however (L2 link
> topology refers to "physical topology" and specifically to discovery).
> 
> What I think you're trying to say is that it is important to say that
> the protocol must ensure loop free delivery - particularly in regard
> to multicast, broadcast and flooded frames.
> 

AGREED

-- Silvano

> -- [snip --

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 14:34:21 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 27792

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:[email-masked]]
> Sent: Tuesday, October 31, 2006 1:46 PM
> To: Silvano Gai
> Cc: [email-masked]
> 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 --

From: "Gray, Eric" <[email-masked]>
To: "'Eastlake III Donald-LDE008'" <[email-masked]>
Date: Tue, 31 Oct 2006 17:33:00 -0500
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 11614

Donald,

	Sorry, I hit "Alt-S" instead of "Ctrl-S".

	I was going to finish this by asking how this relates to Radia's
question or Russ' answer, but I was starting to understand and wanted
to think about it some more.

	Apparently, what you mean by "this" is Radia's proposal to use
the egress RBridge ID as a "tree selector."   That was not obvious -
even with your response - until I was in the process of re-formatting
Radia's original suggestion and found the bit she buried at the end
of one of her paragraphs (the part that basically captures her actual
proposal).

	I had read her proposal as a suggested encapsulation without
FTAG as opposed to a way to use something else instead of FTAG.

	To your point, then, it would not be optional to support the
use she proposes as it would be necessary to compute trees at each
RBridge hop, corresponding to each alternate path.  To do this, an
intermediate RBridge has to be aware that such alternate paths are
possible and what each such alternate path is identified by.

	Personally, I think that equal cost multipathing of multicast,
broadcast and flooded frames is inherently dangerous.  Of course, we
could look forward to seeing yet another "considered dangerous" RFC
in a year or so...  :-)

--
Eric

--> -----Original Message-----
--> From: Gray, Eric 
--> Sent: Tuesday, October 31, 2006 5:22 PM
--> To: Eastlake III Donald-LDE008
--> Cc: [email-masked]
--> Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> Donald,
--> 
--> 	WRT 1)
--> 	======
--> 
--> 	With the previous (current?) SHIM, the only RBridge ID in
--> the SHIM would be the ingress RBridge in the multicast, broadcast
--> and flooded (IRT) case.  So I don't understand how the "shim 
--> 'ingress' and 'egress' rbridges are the same" in this case.
--> 
--> 	Even in the new (proposed?) SHIM, only the ingress RBridge
--> ID is meaningful until - at best - you get to a point where the
--> specific egress for an IRT is unambiguous.  Note that this may
--> not occur even at the egress RBridge's penultimate hop (if - for
--> example - the penultimate hop is connected to more than one such
--> egress by a shared Ethernet segment).  Consequently, the field 
--> intended for egress RBridge may not - in the IRT case - have any
--> meaningful value in it at any point in the CRED.
--> 
--> 	WRT 2) and 3)
--> 	=============
--> 
--> 	Any ingress RBridge is necessarily on the IRT for an egress
--> to which it is expected to deliver multicast, broadcast or flooded
--> frames.  It is an "Ingress" RBridge Tree precisely because each of
--> these is rooted at an ingress, and there is at least one for every
--> ingress RBridge providing a delivery path for all egresses - with
--> the qualification that some egress RBridges may be pruned as early
--> as at the ingress, if the two are not connecting any common VLAN
--> including the default (or null) VLAN.
--> 
--> 	Over-all
--> 	========
--> 
--> 	How does this relate to the 
--> 
--> --> -----Original Message-----
--> --> From: Eastlake III Donald-LDE008 
--> --> [mailto:[email-masked]] 
--> --> Sent: Tuesday, October 31, 2006 2:36 PM
--> --> To: Gray, Eric; [email-masked]
--> --> Subject: RE: [rbridge] New shim header proposal---without 
--> --> F-tag field
--> --> 
--> --> Being able to send the frame on the (pruned) ingress 
--> rbridge tree
--> --> determined by the "egress" rbridge field of the shim 
--> header for a
--> --> multicast frame, rather than the "ingress" rbridge field of 
--> --> that shim
--> --> header.
--> --> 
--> --> I suppose there are actually three cases for multicast frames:
--> --> 
--> --> 1) The shim ingress and "egress" rbridges are the same. 
--> --> This is the same
--> --> case as the current specification.
--> --> 
--> --> 2) They are different but the ingress rbridge, which 
--> constructs this
--> --> encapsulation, is on the IRT of the selected "egress" 
--> (actually IRT
--> --> root) rbridge. Seems like you just need to add the 
--> usual bridge logic
--> --> to distinguish frames heading towards/away from the root.
--> --> 
--> --> 3) I'm not sure if this case is needed but you could 
--> have a case where
--> --> the ingress rbridge which constructs the encapsulation 
--> is not on the 
--> --> IRT for the designated "egress" rbridge. If this case 
--> can occur, while 
--> --> I could imagine much more complex and optimal things to 
--> do, it seems
--> --> adequate to just use the "unicast" forwarding towards 
--> the "egress"
--> --> rbridge until you first hit an rbridge which is on the 
--> IRT rooted at
--> --> the "egress" rbridge at which point the case 2 logic 
--> can take over.
--> --> 
--> --> Donald 
--> --> 
--> --> -----Original Message-----
--> --> From: Gray, Eric [mailto:[email-masked]] 
--> --> Sent: Tuesday, October 31, 2006 2:21 PM
--> --> To: Eastlake III Donald-LDE008; [email-masked]
--> --> Subject: RE: [rbridge] New shim header proposal---without 
--> --> F-tag field
--> --> 
--> --> Donald,
--> --> 
--> --> 	Sorry, I am confused by your response: when you 
--> say "very little
--> --> additional logic is required to support this" - what is 
--> "this"...
--> --> 
--> --> --
--> --> Eric
--> --> 
--> --> --> -----Original Message-----
--> --> --> From: [email-masked]
--> --> --> [mailto:[email-masked]] On Behalf Of 
--> Eastlake III 
--> --> --> Donald-LDE008
--> --> --> Sent: Tuesday, October 31, 2006 2:03 PM
--> --> --> To: [email-masked]
--> --> --> Subject: Re: [rbridge] New shim header 
--> proposal---without F-tag 
--> --> --> field
--> --> --> 
--> --> --> Speaking as a WG member: Since rbridges need to be 
--> able to compute 
--> --> --> an ingress rbridge based tree for various other 
--> rbridges, it seems 
--> --> --> to me that very little additional logic is needed 
--> to support this.
--> --> --> Implementation would be relatively easy and would 
--> have to be 
--> --> --> mandatory to assure proper frame delivery. If it 
--> was optional, you 
--> --> --> have different nodes using different trees and it 
--> is trivial to come 
--> --> --> up with cases where a frame is delivered zero times 
--> or twice when it 
--> --> --> should be delivered once. Depending on 
--> implementation, it is also 
--> --> --> possible to create permanent loops if this is optional.
--> --> --> 
--> --> --> Donald
--> --> --> 
--> --> --> -----Original Message-----
--> --> --> From: [email-masked]
--> --> --> [mailto:[email-masked]] On Behalf Of Russ White
--> --> --> Sent: Tuesday, October 31, 2006 9:19 AM
--> --> --> To: Radia Perlman
--> --> --> Cc: [email-masked]
--> --> --> Subject: Re: [rbridge] New shim header 
--> proposal---without F-tag 
--> --> --> field
--> --> --> 
--> --> --> -----BEGIN PGP SIGNED MESSAGE-----
--> --> --> Hash: SHA1
--> --> --> 
--> --> --> 
--> --> --> This sounds fine to me, as it also means that 
--> implementations that 
--> --> --> don't want to support this won't suffer from the 
--> additional space 
--> --> --> and work involved in the F-Tag. My primary question 
--> would be--what 
--> --> --> will happen if two implementations, one supporting, 
--> the other not, 
--> --> --> are used in the same network?
--> --> --> 
--> --> --> :-)
--> --> --> 
--> --> --> Russ
--> --> --> 
--> --> --> Radia Perlman wrote:
--> --> --> > After talking to Silvano and Dinesh to get them 
--> to explain to me why
--> --> --> > the use of F-tag didn't multiply the number of 
--> trees that RBridges
--> --> --> > needed to compute by the number of F-tag values, 
--> they were able to
--> --> --> > explain to me why they wanted the F-tag. Here is 
--> a proposal to get the 
--> --> --> > functionality they want without the use of F-tag.
--> --> --> > 
--> --> --> > ***********************
--> --> --> > 
--> --> --> > Motivation for F-tag
--> --> --> > 
--> --> --> > They want to be able to do multipathing on 
--> multicast. We can already
--> --> --> > do multipathing on unicast by having an RBridge 
--> keep multiple equal
--> --> --> > cost (or near equal cost) paths to destination D, 
--> and split traffic
--> --> --> > however it wants. But if we have a single tree 
--> for all multicast with
--> --> --> > ingress RBridge R1, then all multicast traffic 
--> has to use the same
--> --> --> > links. The original proposal was to use F-tag as 
--> a selector for a 
--> --> --> > tree. But the modified proposal is to use the 
--> "egress RBridge"
--> --> --> > field, which wasn't all that useful for 
--> multicast, as a "tree selector".
--> --> --> > 
--> --> --> > ******************************
--> --> --> > 
--> --> --> > So the proposal is:
--> --> --> > 
--> --> --> > In the shim header will only be:
--> --> --> > 1) 16-bit ingress RBridge
--> --> --> > 2) 16-bit egress RBridge
--> --> --> > 3) TTL
--> --> --> > 
--> --> --> > 
--> --> --> > How these fields will be used in order to do multipathing:
--> --> --> > 
--> --> --> > a) RBridges calculate a single tree for each 
--> ingress RBridge
--> --> --> > 
--> --> --> > b) For unicast, an RBridge can calculate multiple 
--> equal-cost paths to
--> --> --> > the destination (or near-equal cost), and split 
--> traffic.  That is how
--> --> --> > we'd get multipathing for unicast. If S7 has two 
--> ways to get to 
--> --> --> > destination D, it can send some of its traffic 
--> one way, some of it the
--> --> --> > other. This is solely S7's choice and doesn't 
--> need to be coordinated
--> --> --> > with any other switches.
--> --> --> > 
--> --> --> > c) For multicast, we can provide multipathing by 
--> letting the ingress
--> --> --> > RBridge choose the distribution tree.
--> --> --> > The tree used will be indicated by the "egress 
--> RBridge" field/
--> --> --> > field. So, if S3 receives a multicast packet from an 
--> --> --> endnode, it puts
--> --> --> > "S3" as "ingress RBridge", but selects a tree by whatever
--> --> --> means it
--> --> --> > wants, and puts, say, "S1" into "egress RBridge". That
--> --> --> way the packet
--> --> --> > will be forwarded based on the tree calculated using S1
--> --> --> as the root.
--> --> --> > 
--> --> --> > With this proposal, we get multipathing for 
--> multicast without
--> --> --> configuration.
--> --> --> > The same space used for RBridge nicknames can be used for
--> --> --> choosing the
--> --> --> 
--> --> --> > tree for multicast packets. The number of trees to be
--> --> --> calculated does
--> --> --> > not change---it is still per ingress RBridge.
--> --> --> > 
--> --> --> > Radia
--> --> --> > 
--> --> --> > _______________________________________________
--> --> --> > rbridge mailing list
--> --> --> > [email-masked]
--> --> --> > http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> -----BEGIN PGP SIGNATURE-----
--> --> --> Version: GnuPG v1.4.3 (Darwin)
--> --> --> Comment: Using GnuPG with Mozilla - 
--> http://enigmail.mozdev.org
--> --> --> 
--> --> --> 
--> iD8DBQFFR1tGER27sUhU9OQRApFbAKCeoYIxA/FpF2hCXNwmE+1m42twsQCfWDXy
--> --> --> 75f9f5LHU5Pacuh2vwdIK3c=
--> --> --> =4sIq
--> --> --> -----END PGP SIGNATURE-----
--> --> --> _______________________________________________
--> --> --> rbridge mailing list
--> --> --> [email-masked]
--> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> 
--> --> --> _______________________________________________
--> --> --> rbridge mailing list
--> --> --> [email-masked]
--> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> 
--> --> 
--> 

From: "Gray, Eric" <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Date: Tue, 31 Oct 2006 17:22:20 -0500
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 8979

Donald,

	WRT 1)
	======

	With the previous (current?) SHIM, the only RBridge ID in
the SHIM would be the ingress RBridge in the multicast, broadcast
and flooded (IRT) case.  So I don't understand how the "shim 
'ingress' and 'egress' rbridges are the same" in this case.

	Even in the new (proposed?) SHIM, only the ingress RBridge
ID is meaningful until - at best - you get to a point where the
specific egress for an IRT is unambiguous.  Note that this may
not occur even at the egress RBridge's penultimate hop (if - for
example - the penultimate hop is connected to more than one such
egress by a shared Ethernet segment).  Consequently, the field 
intended for egress RBridge may not - in the IRT case - have any
meaningful value in it at any point in the CRED.

	WRT 2) and 3)
	=============

	Any ingress RBridge is necessarily on the IRT for an egress
to which it is expected to deliver multicast, broadcast or flooded
frames.  It is an "Ingress" RBridge Tree precisely because each of
these is rooted at an ingress, and there is at least one for every
ingress RBridge providing a delivery path for all egresses - with
the qualification that some egress RBridges may be pruned as early
as at the ingress, if the two are not connecting any common VLAN
including the default (or null) VLAN.

	Over-all
	========

	How does this relate to the 

--> -----Original Message-----
--> From: Eastlake III Donald-LDE008 
--> [mailto:[email-masked]] 
--> Sent: Tuesday, October 31, 2006 2:36 PM
--> To: Gray, Eric; [email-masked]
--> Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> Being able to send the frame on the (pruned) ingress rbridge tree
--> determined by the "egress" rbridge field of the shim header for a
--> multicast frame, rather than the "ingress" rbridge field of 
--> that shim
--> header.
--> 
--> I suppose there are actually three cases for multicast frames:
--> 
--> 1) The shim ingress and "egress" rbridges are the same. 
--> This is the same
--> case as the current specification.
--> 
--> 2) They are different but the ingress rbridge, which constructs this
--> encapsulation, is on the IRT of the selected "egress" (actually IRT
--> root) rbridge. Seems like you just need to add the usual bridge logic
--> to distinguish frames heading towards/away from the root.
--> 
--> 3) I'm not sure if this case is needed but you could have a case where
--> the ingress rbridge which constructs the encapsulation is not on the 
--> IRT for the designated "egress" rbridge. If this case can occur, while 
--> I could imagine much more complex and optimal things to do, it seems
--> adequate to just use the "unicast" forwarding towards the "egress"
--> rbridge until you first hit an rbridge which is on the IRT rooted at
--> the "egress" rbridge at which point the case 2 logic can take over.
--> 
--> Donald 
--> 
--> -----Original Message-----
--> From: Gray, Eric [mailto:[email-masked]] 
--> Sent: Tuesday, October 31, 2006 2:21 PM
--> To: Eastlake III Donald-LDE008; [email-masked]
--> Subject: RE: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> Donald,
--> 
--> 	Sorry, I am confused by your response: when you say "very little
--> additional logic is required to support this" - what is "this"...
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: [email-masked]
--> --> [mailto:[email-masked]] On Behalf Of Eastlake III 
--> --> Donald-LDE008
--> --> Sent: Tuesday, October 31, 2006 2:03 PM
--> --> To: [email-masked]
--> --> Subject: Re: [rbridge] New shim header proposal---without F-tag 
--> --> field
--> --> 
--> --> Speaking as a WG member: Since rbridges need to be able to compute 
--> --> an ingress rbridge based tree for various other rbridges, it seems 
--> --> to me that very little additional logic is needed to support this.
--> --> Implementation would be relatively easy and would have to be 
--> --> mandatory to assure proper frame delivery. If it was optional, you 
--> --> have different nodes using different trees and it is trivial to come

--> --> up with cases where a frame is delivered zero times or twice when it

--> --> should be delivered once. Depending on implementation, it is also 
--> --> possible to create permanent loops if this is optional.
--> --> 
--> --> Donald
--> --> 
--> --> -----Original Message-----
--> --> From: [email-masked]
--> --> [mailto:[email-masked]] On Behalf Of Russ White
--> --> Sent: Tuesday, October 31, 2006 9:19 AM
--> --> To: Radia Perlman
--> --> Cc: [email-masked]
--> --> Subject: Re: [rbridge] New shim header proposal---without F-tag 
--> --> field
--> --> 
--> --> -----BEGIN PGP SIGNED MESSAGE-----
--> --> Hash: SHA1
--> --> 
--> --> 
--> --> This sounds fine to me, as it also means that implementations that 
--> --> don't want to support this won't suffer from the additional space 
--> --> and work involved in the F-Tag. My primary question would be--what 
--> --> will happen if two implementations, one supporting, the other not, 
--> --> are used in the same network?
--> --> 
--> --> :-)
--> --> 
--> --> Russ
--> --> 
--> --> Radia Perlman wrote:
--> --> > After talking to Silvano and Dinesh to get them to explain to me
why
--> --> > the use of F-tag didn't multiply the number of trees that RBridges
--> --> > needed to compute by the number of F-tag values, they were able to
--> --> > explain to me why they wanted the F-tag. Here is a proposal to get
the 
--> --> > functionality they want without the use of F-tag.
--> --> > 
--> --> > ***********************
--> --> > 
--> --> > Motivation for F-tag
--> --> > 
--> --> > They want to be able to do multipathing on multicast. We can
already
--> --> > do multipathing on unicast by having an RBridge keep multiple
equal
--> --> > cost (or near equal cost) paths to destination D, and split
traffic
--> --> > however it wants. But if we have a single tree for all multicast
with
--> --> > ingress RBridge R1, then all multicast traffic has to use the same
--> --> > links. The original proposal was to use F-tag as a selector for a 
--> --> > tree. But the modified proposal is to use the "egress RBridge"
--> --> > field, which wasn't all that useful for multicast, as a "tree
selector".
--> --> > 
--> --> > ******************************
--> --> > 
--> --> > So the proposal is:
--> --> > 
--> --> > In the shim header will only be:
--> --> > 1) 16-bit ingress RBridge
--> --> > 2) 16-bit egress RBridge
--> --> > 3) TTL
--> --> > 
--> --> > 
--> --> > How these fields will be used in order to do multipathing:
--> --> > 
--> --> > a) RBridges calculate a single tree for each ingress RBridge
--> --> > 
--> --> > b) For unicast, an RBridge can calculate multiple equal-cost paths
to
--> --> > the destination (or near-equal cost), and split traffic.  That is
how
--> --> > we'd get multipathing for unicast. If S7 has two ways to get to 
--> --> > destination D, it can send some of its traffic one way, some of it
the
--> --> > other. This is solely S7's choice and doesn't need to be
coordinated
--> --> > with any other switches.
--> --> > 
--> --> > c) For multicast, we can provide multipathing by letting the
ingress
--> --> > RBridge choose the distribution tree.
--> --> > The tree used will be indicated by the "egress RBridge" field/
--> --> > field. So, if S3 receives a multicast packet from an 
--> --> endnode, it puts
--> --> > "S3" as "ingress RBridge", but selects a tree by whatever
--> --> means it
--> --> > wants, and puts, say, "S1" into "egress RBridge". That
--> --> way the packet
--> --> > will be forwarded based on the tree calculated using S1
--> --> as the root.
--> --> > 
--> --> > With this proposal, we get multipathing for multicast without
--> --> configuration.
--> --> > The same space used for RBridge nicknames can be used for
--> --> choosing the
--> --> 
--> --> > tree for multicast packets. The number of trees to be
--> --> calculated does
--> --> > not change---it is still per ingress RBridge.
--> --> > 
--> --> > Radia
--> --> > 
--> --> > _______________________________________________
--> --> > rbridge mailing list
--> --> > [email-masked]
--> --> > http://mailman.postel.org/mailman/listinfo/rbridge
--> --> -----BEGIN PGP SIGNATURE-----
--> --> Version: GnuPG v1.4.3 (Darwin)
--> --> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> --> 
--> --> iD8DBQFFR1tGER27sUhU9OQRApFbAKCeoYIxA/FpF2hCXNwmE+1m42twsQCfWDXy
--> --> 75f9f5LHU5Pacuh2vwdIK3c=
--> --> =4sIq
--> --> -----END PGP SIGNATURE-----
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> 
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> 
--> 

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>, "Gray, Eric" <[email-masked]>
Date: Tue, 31 Oct 2006 17:00:08 -0500
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 2978

Radia,

	If we keep it, then the specification needs to say that the 
value is copied from the corresponding bit in a native encapsulated
frame at the ingress RBBridge and that (should anyone discover it 
is not) any frame where that is not the case whould be treated as 
a corrupted frame when received by any egress RBridge.

	As it is now, there are too many ways to over-load such a 
bit and that is practically guaranteed to produce interoperability
issues.

--
Eric

--> -----Original Message-----
--> From: Radia Perlman [mailto:[email-masked]] 
--> Sent: Tuesday, October 31, 2006 4:49 PM
--> To: Gray, Eric
--> Cc: Dinesh G Dutt; [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> Re: Eric Gray asked: Why a multicast bit:
--> 
--> I'm not sure we do need it, now that you mention it. Let's
--> work through the cases.
--> 
--> There is a field in the shim indicating what we've been 
--> calling "egress 
--> RBridge".  Let's say
--> the value of that field is "X".
--> An RBridge has to know whether
--> to forward via unicast to X, or to forward
--> along the bidirectional tree rooted at X.
--> 
--> The ingress RBridge will fill in the field as:
--> a) the nickname of the egress RBridge, if the destination 
--> is unicast and 
--> the location is known
--> b) the nickname of the root of the selected tree (usually 
--> itself) in the 
--> case of multicast
--> c) some reserved value (probably "0") in the case of 
--> unicast where the 
--> destination is unknown. (I'm
--> assuming nobody wants to multipath *these* types of packets 
--> to select a 
--> different tree than the
--> one rooted at the ingress RBridge).
--> 
--> With a multicast bit, that would determine in. But suppose 
--> there wasn't 
--> a multicast bit?
--> 
--> If the destination address in the original frame is multicast, then 
--> forward along the bidirectional tree rooted at X.
--> 
--> Otherwise, if "X"=0, then forward along the tree rooted at "ingress 
--> RBridge". Otherwise, forward
--> unicast towards X.
--> 
--> And if an RBridge R in the middle was ambitious, and knew 
--> where D was, 
--> it could replace "0"
--> with the egress RBridge.
--> 
--> Ordinarily I don't like seeing multiple ways of specifying 
--> something in 
--> a header, because then
--> you have to say what happens if they disagree. But if having the 
--> multicast bit makes forwarding
--> much simpler (since RBridges wouldn't have to look inside at the 
--> original frame), then maybe
--> people would prefer it.
--> 
--> So technically, I think ERic is right and it's not needed. 
--> But does it 
--> make things a lot more convenient?
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Why do you need/want a multicast bit?
--> >
--> >If we're going to have both RBridge IDs in the SHIM, we don't
--> >need to consume a bit for multicast/unicast discrimination...
--> >
--> >--
--> >Eric
--> >
--> >  
--> >
--> 

Date: Tue, 31 Oct 2006 13:48:40 -0800
From: Radia Perlman <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 1924

Re: Eric Gray asked: Why a multicast bit:

I'm not sure we do need it, now that you mention it. Let's
work through the cases.

There is a field in the shim indicating what we've been calling "egress 
RBridge".  Let's say
the value of that field is "X".
An RBridge has to know whether
to forward via unicast to X, or to forward
along the bidirectional tree rooted at X.

The ingress RBridge will fill in the field as:
a) the nickname of the egress RBridge, if the destination is unicast and 
the location is known
b) the nickname of the root of the selected tree (usually itself) in the 
case of multicast
c) some reserved value (probably "0") in the case of unicast where the 
destination is unknown. (I'm
assuming nobody wants to multipath *these* types of packets to select a 
different tree than the
one rooted at the ingress RBridge).

With a multicast bit, that would determine in. But suppose there wasn't 
a multicast bit?

If the destination address in the original frame is multicast, then 
forward along the bidirectional tree rooted at X.

Otherwise, if "X"=0, then forward along the tree rooted at "ingress 
RBridge". Otherwise, forward
unicast towards X.

And if an RBridge R in the middle was ambitious, and knew where D was, 
it could replace "0"
with the egress RBridge.

Ordinarily I don't like seeing multiple ways of specifying something in 
a header, because then
you have to say what happens if they disagree. But if having the 
multicast bit makes forwarding
much simpler (since RBridges wouldn't have to look inside at the 
original frame), then maybe
people would prefer it.

So technically, I think ERic is right and it's not needed. But does it 
make things a lot more convenient?

Radia

Gray, Eric wrote:

>Why do you need/want a multicast bit?
>
>If we're going to have both RBridge IDs in the SHIM, we don't
>need to consume a bit for multicast/unicast discrimination...
>
>--
>Eric
>
>  
>

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 16:46:27 -0500
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 26002

-- [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 --

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 14:36:19 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 6712

Being able to send the frame on the (pruned) ingress rbridge tree
determined by the "egress" rbridge field of the shim header for a
multicast frame, rather than the "ingress" rbridge field of that shim
header.

I suppose there are actually three cases for multicast frames:

1) The shim ingress and "egress" rbridges are the same. This is the same
case as the current specification.

2) They are different but the ingress rbridge, which constructs this
encapsulation, is on the IRT of the selected "egress" (actually IRT
root) rbridge. Seems like you just need to add the usual bridge logic to
distinguish frames heading towards/away from the root.

3) I'm not sure if this case is needed but you could have a case where
the ingress rbridge which constructs the encapsulation is not on the IRT
for the designated "egress" rbridge. If this case can occur, while I
could imagine much more complex and optimal things to do, it seems
adequate to just use the "unicast" forwarding towards the "egress"
rbridge until you first hit an rbridge which is on the IRT rooted at the
"egress" rbridge at which point the case 2 logic can take over.

Donald 

-----Original Message-----
From: Gray, Eric [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2006 2:21 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] New shim header proposal---without F-tag field

Donald,

	Sorry, I am confused by your response: when you say "very little
additional logic is required to support this" - what is "this"...

--
Eric

--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]] On Behalf Of Eastlake III 
--> Donald-LDE008
--> Sent: Tuesday, October 31, 2006 2:03 PM
--> To: [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without F-tag 
--> field
--> 
--> Speaking as a WG member: Since rbridges need to be able to compute 
--> an ingress rbridge based tree for various other rbridges, it seems 
--> to me that very little additional logic is needed to support this.
--> Implementation would be relatively easy and would have to be 
--> mandatory to assure proper frame delivery. If it was optional, you 
--> have different nodes using different trees and it is trivial to come

--> up with cases where a frame is delivered zero times or twice when it

--> should be delivered once. Depending on implementation, it is also 
--> possible to create permanent loops if this is optional.
--> 
--> Donald
--> 
--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]] On Behalf Of Russ White
--> Sent: Tuesday, October 31, 2006 9:19 AM
--> To: Radia Perlman
--> Cc: [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without F-tag 
--> field
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> This sounds fine to me, as it also means that implementations that 
--> don't want to support this won't suffer from the additional space 
--> and work involved in the F-Tag. My primary question would be--what 
--> will happen if two implementations, one supporting, the other not, 
--> are used in the same network?
--> 
--> :-)
--> 
--> Russ
--> 
--> Radia Perlman wrote:
--> > After talking to Silvano and Dinesh to get them to
--> explain to me why
--> > the use of F-tag didn't multiply the number of trees that
--> RBridges
--> > needed to compute by the number of F-tag values, they
--> were able to
--> > explain to me why they wanted the F-tag. Here is a
--> proposal to get the
--> 
--> > functionality they want without the use of F-tag.
--> > 
--> > ***********************
--> > 
--> > Motivation for F-tag
--> > 
--> > They want to be able to do multipathing on multicast. We
--> can already
--> > do multipathing on unicast by having an RBridge keep
--> multiple equal
--> > cost (or near equal cost) paths to destination D, and
--> split traffic
--> > however it wants. But if we have a single tree for all
--> multicast with
--> > ingress RBridge R1, then all multicast traffic has to use
--> the same
--> > links. The original proposal was to use F-tag as a selector for a 
--> > tree. But the modified proposal is to use the "egress RBridge"
--> > field, which wasn't all that useful for multicast, as a "tree
--> selector".
--> > 
--> > ******************************
--> > 
--> > So the proposal is:
--> > 
--> > In the shim header will only be:
--> > 1) 16-bit ingress RBridge
--> > 2) 16-bit egress RBridge
--> > 3) TTL
--> > 
--> > 
--> > How these fields will be used in order to do multipathing:
--> > 
--> > a) RBridges calculate a single tree for each ingress RBridge
--> > 
--> > b) For unicast, an RBridge can calculate multiple
--> equal-cost paths to
--> > the destination (or near-equal cost), and split traffic. 
--> That is how
--> > we'd get multipathing for unicast. If S7 has two ways to get to 
--> > destination D, it can send some of its traffic one way,
--> some of it the
--> 
--> > other. This is solely S7's choice and doesn't need to be
--> coordinated
--> > with any other switches.
--> > 
--> > c) For multicast, we can provide multipathing by letting
--> the ingress
--> > RBridge choose the distribution tree.
--> > The tree used will be indicated by the "egress RBridge"
--> > field. So, if S3 receives a multicast packet from an
--> endnode, it puts
--> > "S3" as "ingress RBridge", but selects a tree by whatever
--> means it
--> > wants, and puts, say, "S1" into "egress RBridge". That
--> way the packet
--> > will be forwarded based on the tree calculated using S1
--> as the root.
--> > 
--> > With this proposal, we get multipathing for multicast without
--> configuration.
--> > The same space used for RBridge nicknames can be used for
--> choosing the
--> 
--> > tree for multicast packets. The number of trees to be
--> calculated does
--> > not change---it is still per ingress RBridge.
--> > 
--> > Radia
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.3 (Darwin)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFFR1tGER27sUhU9OQRApFbAKCeoYIxA/FpF2hCXNwmE+1m42twsQCfWDXy
--> 75f9f5LHU5Pacuh2vwdIK3c=
--> =4sIq
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>, [email-masked]
Date: Tue, 31 Oct 2006 14:21:19 -0500
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 5394

Donald,

	Sorry, I am confused by your response: when you say "very little
additional logic is required to support this" - what is "this"...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Tuesday, October 31, 2006 2:03 PM
--> To: [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> Speaking as a WG member: Since rbridges need to be able to 
--> compute an
--> ingress rbridge based tree for various other rbridges, it 
--> seems to me
--> that very little additional logic is needed to support this.
--> Implementation would be relatively easy and would have to 
--> be mandatory
--> to assure proper frame delivery. If it was optional, you 
--> have different
--> nodes using different trees and it is trivial to come up with cases
--> where a frame is delivered zero times or twice when it should be
--> delivered once. Depending on implementation, it is also possible to
--> create permanent loops if this is optional.
--> 
--> Donald
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Russ White
--> Sent: Tuesday, October 31, 2006 9:19 AM
--> To: Radia Perlman
--> Cc: [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> This sounds fine to me, as it also means that 
--> implementations that don't
--> want to support this won't suffer from the additional space and work
--> involved in the F-Tag. My primary question would be--what 
--> will happen if
--> two implementations, one supporting, the other not, are 
--> used in the same
--> network?
--> 
--> :-)
--> 
--> Russ
--> 
--> Radia Perlman wrote:
--> > After talking to Silvano and Dinesh to get them to 
--> explain to me why 
--> > the use of F-tag didn't multiply the number of trees that 
--> RBridges 
--> > needed to compute by the number of F-tag values, they 
--> were able to 
--> > explain to me why they wanted the F-tag. Here is a 
--> proposal to get the
--> 
--> > functionality they want without the use of F-tag.
--> > 
--> > ***********************
--> > 
--> > Motivation for F-tag
--> > 
--> > They want to be able to do multipathing on multicast. We 
--> can already 
--> > do multipathing on unicast by having an RBridge keep 
--> multiple equal 
--> > cost (or near equal cost) paths to destination D, and 
--> split traffic 
--> > however it wants. But if we have a single tree for all 
--> multicast with 
--> > ingress RBridge R1, then all multicast traffic has to use 
--> the same 
--> > links. The original proposal was to use F-tag as a selector for a 
--> > tree. But the modified proposal is to use the "egress RBridge"
--> > field, which wasn't all that useful for multicast, as a "tree
--> selector".
--> > 
--> > ******************************
--> > 
--> > So the proposal is:
--> > 
--> > In the shim header will only be:
--> > 1) 16-bit ingress RBridge
--> > 2) 16-bit egress RBridge
--> > 3) TTL
--> > 
--> > 
--> > How these fields will be used in order to do multipathing:
--> > 
--> > a) RBridges calculate a single tree for each ingress RBridge
--> > 
--> > b) For unicast, an RBridge can calculate multiple 
--> equal-cost paths to 
--> > the destination (or near-equal cost), and split traffic. 
--> That is how 
--> > we'd get multipathing for unicast. If S7 has two ways to get to 
--> > destination D, it can send some of its traffic one way, 
--> some of it the
--> 
--> > other. This is solely S7's choice and doesn't need to be 
--> coordinated 
--> > with any other switches.
--> > 
--> > c) For multicast, we can provide multipathing by letting 
--> the ingress 
--> > RBridge choose the distribution tree.
--> > The tree used will be indicated by the "egress RBridge"
--> > field. So, if S3 receives a multicast packet from an 
--> endnode, it puts 
--> > "S3" as "ingress RBridge", but selects a tree by whatever 
--> means it 
--> > wants, and puts, say, "S1" into "egress RBridge". That 
--> way the packet 
--> > will be forwarded based on the tree calculated using S1 
--> as the root.
--> > 
--> > With this proposal, we get multipathing for multicast without
--> configuration.
--> > The same space used for RBridge nicknames can be used for 
--> choosing the
--> 
--> > tree for multicast packets. The number of trees to be 
--> calculated does 
--> > not change---it is still per ingress RBridge.
--> > 
--> > Radia
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.3 (Darwin)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFFR1tGER27sUhU9OQRApFbAKCeoYIxA/FpF2hCXNwmE+1m42twsQCfWDXy
--> 75f9f5LHU5Pacuh2vwdIK3c=
--> =4sIq
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 14:02:31 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 4181

Speaking as a WG member: Since rbridges need to be able to compute an
ingress rbridge based tree for various other rbridges, it seems to me
that very little additional logic is needed to support this.
Implementation would be relatively easy and would have to be mandatory
to assure proper frame delivery. If it was optional, you have different
nodes using different trees and it is trivial to come up with cases
where a frame is delivered zero times or twice when it should be
delivered once. Depending on implementation, it is also possible to
create permanent loops if this is optional.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ White
Sent: Tuesday, October 31, 2006 9:19 AM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field

This sounds fine to me, as it also means that implementations that don't
want to support this won't suffer from the additional space and work
involved in the F-Tag. My primary question would be--what will happen if
two implementations, one supporting, the other not, are used in the same
network?

:-)

Russ

Radia Perlman wrote:
> After talking to Silvano and Dinesh to get them to explain to me why 
> the use of F-tag didn't multiply the number of trees that RBridges 
> needed to compute by the number of F-tag values, they were able to 
> explain to me why they wanted the F-tag. Here is a proposal to get the

> functionality they want without the use of F-tag.
> 
> ***********************
> 
> Motivation for F-tag
> 
> They want to be able to do multipathing on multicast. We can already 
> do multipathing on unicast by having an RBridge keep multiple equal 
> cost (or near equal cost) paths to destination D, and split traffic 
> however it wants. But if we have a single tree for all multicast with 
> ingress RBridge R1, then all multicast traffic has to use the same 
> links. The original proposal was to use F-tag as a selector for a 
> tree. But the modified proposal is to use the "egress RBridge"
> field, which wasn't all that useful for multicast, as a "tree
selector".
> 
> ******************************
> 
> So the proposal is:
> 
> In the shim header will only be:
> 1) 16-bit ingress RBridge
> 2) 16-bit egress RBridge
> 3) TTL
> 
> 
> How these fields will be used in order to do multipathing:
> 
> a) RBridges calculate a single tree for each ingress RBridge
> 
> b) For unicast, an RBridge can calculate multiple equal-cost paths to 
> the destination (or near-equal cost), and split traffic. That is how 
> we'd get multipathing for unicast. If S7 has two ways to get to 
> destination D, it can send some of its traffic one way, some of it the

> other. This is solely S7's choice and doesn't need to be coordinated 
> with any other switches.
> 
> c) For multicast, we can provide multipathing by letting the ingress 
> RBridge choose the distribution tree.
> The tree used will be indicated by the "egress RBridge"
> field. So, if S3 receives a multicast packet from an endnode, it puts 
> "S3" as "ingress RBridge", but selects a tree by whatever means it 
> wants, and puts, say, "S1" into "egress RBridge". That way the packet 
> will be forwarded based on the tree calculated using S1 as the root.
> 
> With this proposal, we get multipathing for multicast without
configuration.
> The same space used for RBridge nicknames can be used for choosing the

> tree for multicast packets. The number of trees to be calculated does 
> not change---it is still per ingress RBridge.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>, Dinesh G Dutt <[email-masked]>
Date: Tue, 31 Oct 2006 14:03:38 -0500
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 4126

Why do you need/want a multicast bit?

If we're going to have both RBridge IDs in the SHIM, we don't
need to consume a bit for multicast/unicast discrimination...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Tuesday, October 31, 2006 1:06 PM
--> To: Dinesh G Dutt
--> Cc: [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> No. I just forgot that bit.
--> 
--> So, we need
--> a) ingress RBridge
--> b) egress RBridge
--> (where both above fields are the same size)
--> c) TTL (6 bits ought to be enough)
--> d) multicast flag (just a single bit)
--> 
--> Anything else?
--> 
--> Radia
--> 
--> 
--> 
--> Dinesh G Dutt wrote:
--> 
--> > I hit "send" too soon. We talked about an additional bit 
--> in the header 
--> > to identify a multicast frame. Did you see no need for that ?
--> >
--> > Dinesh
--> > Radia Perlman wrote:
--> >
--> >> After talking to Silvano and Dinesh to get them to 
--> explain to me why
--> >> the use of F-tag didn't multiply the number of trees 
--> that RBridges
--> >> needed to compute by the number of F-tag values, they 
--> were able to
--> >> explain to me why they wanted the F-tag. Here is a proposal to
--> >> get the functionality they want without the use of F-tag.
--> >>
--> >> ***********************
--> >>
--> >> Motivation for F-tag
--> >>
--> >> They want to be able to do multipathing on multicast. We 
--> can already
--> >> do multipathing on unicast by having an RBridge keep 
--> multiple equal
--> >> cost (or near equal cost) paths to destination D, and 
--> split traffic
--> >> however it wants. But if we have a single tree for all multicast
--> >> with ingress RBridge R1, then all multicast traffic has to use
--> >> the same links. The original proposal was to use F-tag 
--> as a selector
--> >> for a tree. But the modified proposal is to use the 
--> "egress RBridge"
--> >> field, which wasn't all that useful for multicast, as a 
--> "tree selector".
--> >>
--> >> ******************************
--> >>
--> >> So the proposal is:
--> >>
--> >> In the shim header will only be:
--> >> 1) 16-bit ingress RBridge
--> >> 2) 16-bit egress RBridge
--> >> 3) TTL
--> >>
--> >>
--> >> How these fields will be used in order to do multipathing:
--> >>
--> >> a) RBridges calculate a single tree for each ingress RBridge
--> >>
--> >> b) For unicast, an RBridge can calculate multiple equal-cost
--> >> paths to the destination (or near-equal cost), and split 
--> traffic. 
--> >> That is how
--> >> we'd get multipathing for unicast. If S7 has two ways to get to 
--> >> destination D,
--> >> it can send some of its traffic one way, some of it the 
--> other. This 
--> >> is solely
--> >> S7's choice and doesn't need to be coordinated with any 
--> other switches.
--> >>
--> >> c) For multicast, we can provide multipathing by letting 
--> the ingress 
--> >> RBridge
--> >> choose the distribution tree.
--> >> The tree used will be indicated by the "egress RBridge"
--> >> field. So, if S3 receives a multicast packet from an 
--> endnode, it puts
--> >> "S3" as "ingress RBridge", but selects a tree by 
--> whatever means it
--> >> wants, and puts, say, "S1" into "egress RBridge". That 
--> way the packet
--> >> will be forwarded based on the tree calculated using S1 
--> as the root.
--> >>
--> >> With this proposal, we get multipathing for multicast without 
--> >> configuration.
--> >> The same space used for RBridge nicknames can be used 
--> for choosing the
--> >> tree for multicast packets. The number of trees to be 
--> calculated does
--> >> not change---it is still per ingress RBridge.
--> >>
--> >> Radia
--> >>
--> >> _______________________________________________
--> >> rbridge mailing list
--> >> [email-masked]
--> >> http://mailman.postel.org/mailman/listinfo/rbridge
--> >>
--> >>   
--> >
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Tue, 31 Oct 2006 10:05:57 -0800
From: Radia Perlman <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 3016

No. I just forgot that bit.

So, we need
a) ingress RBridge
b) egress RBridge
(where both above fields are the same size)
c) TTL (6 bits ought to be enough)
d) multicast flag (just a single bit)

Anything else?

Radia

Dinesh G Dutt wrote:

> I hit "send" too soon. We talked about an additional bit in the header 
> to identify a multicast frame. Did you see no need for that ?
>
> Dinesh
> Radia Perlman wrote:
>
>> After talking to Silvano and Dinesh to get them to explain to me why
>> the use of F-tag didn't multiply the number of trees that RBridges
>> needed to compute by the number of F-tag values, they were able to
>> explain to me why they wanted the F-tag. Here is a proposal to
>> get the functionality they want without the use of F-tag.
>>
>> ***********************
>>
>> Motivation for F-tag
>>
>> They want to be able to do multipathing on multicast. We can already
>> do multipathing on unicast by having an RBridge keep multiple equal
>> cost (or near equal cost) paths to destination D, and split traffic
>> however it wants. But if we have a single tree for all multicast
>> with ingress RBridge R1, then all multicast traffic has to use
>> the same links. The original proposal was to use F-tag as a selector
>> for a tree. But the modified proposal is to use the "egress RBridge"
>> field, which wasn't all that useful for multicast, as a "tree selector".
>>
>> ******************************
>>
>> So the proposal is:
>>
>> In the shim header will only be:
>> 1) 16-bit ingress RBridge
>> 2) 16-bit egress RBridge
>> 3) TTL
>>
>>
>> How these fields will be used in order to do multipathing:
>>
>> a) RBridges calculate a single tree for each ingress RBridge
>>
>> b) For unicast, an RBridge can calculate multiple equal-cost
>> paths to the destination (or near-equal cost), and split traffic. 
>> That is how
>> we'd get multipathing for unicast. If S7 has two ways to get to 
>> destination D,
>> it can send some of its traffic one way, some of it the other. This 
>> is solely
>> S7's choice and doesn't need to be coordinated with any other switches.
>>
>> c) For multicast, we can provide multipathing by letting the ingress 
>> RBridge
>> choose the distribution tree.
>> The tree used will be indicated by the "egress RBridge"
>> field. So, if S3 receives a multicast packet from an endnode, it puts
>> "S3" as "ingress RBridge", but selects a tree by whatever means it
>> wants, and puts, say, "S1" into "egress RBridge". That way the packet
>> will be forwarded based on the tree calculated using S1 as the root.
>>
>> With this proposal, we get multipathing for multicast without 
>> configuration.
>> The same space used for RBridge nicknames can be used for choosing the
>> tree for multicast packets. The number of trees to be calculated does
>> not change---it is still per ingress RBridge.
>>
>> Radia
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>   
>
>

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 12:42:38 -0500
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 1700

Silvano,

	Please see below...

--
Eric

-- [snip] -- 
--> 
--> Sgai 3> It is very important to say that this protocol must provide a
--> loop free topology for multicast/broadcast under any condition,
including 
--> transient loops, to prevent multicast/broadcast storm.
-- [snip] --

I think I know what you're trying to say here, but "topology" is not
the right word.  This is probably a point of confusion - based on the
way STP works - that you're bringing up and I may need to fix.  I do
not recall using "topology" in this specific context, however (L2 link
topology refers to "physical topology" and specifically to discovery).

What I think you're trying to say is that it is important to say that
the protocol must ensure loop free delivery - particularly in regard
to multicast, broadcast and flooded frames.

I already have agreed that we need to be more explicit about that, and
I will figure out a way to clarify the architecture in this respect.

This cannot go in the section where you point it out, however, as that
section identifies what we plan to use a link-state routing protocol
to accomplish.  Clearly, the "blocking" behavior discussed previously
has nothing much to do with link-state routing.

One question I have to you is: does it make sense to talk about a
"topology change state" in an architecture document where we don't
specifically define a state machine?  I believe that we need to 
make the simple point that protocol specifications need to address
this concern.

Another question I have for you is: does this apply to unicast as
well?  I was under the impression that you agreed that TTL is good
enough for unicast forwarding to known destinations.

-- [snip --

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 12:24:58 -0500
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 583

Silvano,
 
	See below...

--
Eric

-- [snip] -- 
--> 
--> Sgai 2> I think we should explicitly mention layer 2 multipath.
--> 
-- [snip] -- 
--> 

What do you mean by layer 2 multipath?

Do you mean "link bundling" or something else?

Are we trying now to apply ECMP to routing advertisements for layer
two reachability?  That's a big step, particularly when we need to
retain compatibility with existing 802.1 bridges.

I don't recall seeing anything about this in the problem statement
document, so I don't know of any reason why we should include it in
the architecture.

--
Eric

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 12:18:54 -0500
Cc: [email-masked]
Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr	aft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 2088

Silvano,

	 See comments below...

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Monday, October 30, 2006 12:13 PM
--> To: [email-masked]
--> Subject: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> Comments inline marked "sgai n>"
--> 
--> Sgai 1> This documents assumes that all multicast traffic must be
--> propagated through the IRT (Ingress Rbridge Tree) and therefore 
--> denies any possibility for shared trees.

I don't follow this comment.  Or perhaps I simply don't understand
why this is our problem.

By creating ingress RBridge trees (as the concatenation of shortest
path routes from an ingress to all egresses), we establish a "tree"
which will deliver to all destinations in the broadcast domain.  If
we then "prune" the tree for specific VLANs and multicast interest
groups, we create "virtual trees" per-VLAN and for multicast groups.

In doing this, we are perhaps doing better than 802.1<whatever>, but
we are still only trying to deliver broadcast, flooded and multicast
frames to the destinations that 1) would receive them in an Ethernet
network and 2) should receive them if optimizing an Ethernet network
for IP multicast.

Frankly the intent to support optimization of IP multicast is a bit
of a fragile compromise within the working group, but it is AFAIK 
what we are trying to do.

So, what I am trying to figure out is how what we're doing with the
IRT differs from "shared tree" support with existing 802.1<whatever>
bridges.  

Are you saying that you would like RBridges to support the "shared 
tree" concept even though 802.1<whatever> bridges may or may not 
support it?  

Or are you saying that there is something about the design of the 
ingress rbridge trees that get in the way of support for "shared 
trees" that might be provided in today's Ethernet bridges?

--> 
--> -- Silvano
--> 
--> --------------------------------------------------------
--> 
--> ... snip ...

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 12:03:34 -0500
Cc: [email-masked]
Subject: Re: [rbridge] VLANs
Status: RO
Content-Length: 2849

Silvano,

	Actually, both "types" of VLANs are the same - applying at 
different layers, but defined using the same terminology.  Logic,
semantics and applicability are the same.

	For historic reasons, we are trying to avoid the terms you
propose.  In fact, similar terms have been used previously and 
removed as confusing.  Without constant reminders, "inner" and 
"outer" will be taken in some instances as placement in the frame 
(as you are suggesting) or position relative to the CRED (a usage
issue with the terms "ingress" and "egress" meaning "way in" and
"way out" respectively).

	Hence you are suggesting replacement with one potential 
are of confusion with another one we've earlier discarded.

	The architecture document defines the term VLAN and - I am
reasonably sure - uses that definition consistently.  Moreover,
the architecture document tries to be agnostic about the use of 
VLANs - particularly with respect to VLAN tagged encapsulation
and port-based VLANs, and where these things might apply.  The
reason for this is simply that one aim of protocol development - 
especially at the architectural level - should be to avoid placing
constraints on implementation beyond those explicitly required 
to ensure interoperability.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Monday, October 30, 2006 12:29 PM
--> To: [email-masked]
--> Subject: [rbridge] VLANs
--> 
--> 
--> The second biggest issue I have with the four documents 
--> (first one being
--> broadcast/multicast storm) is the definition of VLANs.
--> 
--> I don't think the term VLAN is used consistently in the documents.
--> 
--> 1) Sometimes VLAN refers to the VLANs present on the 
--> untagged frames,
--> which must be propagated by ISIS, VLAN pruning must be 
--> performed and so
--> on. They all share the same core instance of ISIS.
--> 
--> 2) Sometimes VLANs refers to the fact that a CRED can be 
--> encapsulated
--> into a VLAN (present as a 1Q tag in the outer header) and 
--> therefore ISIS
--> will run per VLAN, i.e. there will be a core instance of 
--> ISIS per each
--> VLAN. This seems to be the case in some part of the architectural
--> document.
--> 
--> I propose to name the former IVLAN (inner VLAN) and the latter OVLAN
--> (Outer VLAN), with reference to the position of the 1Q tag 
--> in the frame.
--> 
--> This is also very relevant for the discussion that we need 
--> to complete
--> on the FTAG: it is my understanding that some folks think 
--> that the FTAG
--> is not needed, since there may be an OVLAN.
--> 
--> Comments?
--> 
--> -- Silvano
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 09:02:22 -0800
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 5810

Eric,
I was just replying to Dinesh about where to put the bit that says if
the frame is a multicast.

The proposal is put it into the table.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 8:37 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] New shim header proposal---without F-tag field
> 
> Silvano,
> 
> 	You do not need to send a message to the mailing list
> to do this, as this is not currently a WG document and you
> are one of its authors.
> 
> 	If you're asking if the draft would be more acceptable
> if this change were made, then that is what you should say.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Tuesday, October 31, 2006 11:02 AM
> --> To: Dinesh G Dutt; Radia Perlman
> --> Cc: [email-masked]
> --> Subject: Re: [rbridge] New shim header proposal---without
> --> F-tag field
> -->
> -->
> --> I propose that we replace Figure 3 in
> --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-
> --> encap-00.txt
> -->
> --> with:
> -->
> --> 0xxxxxxxxxxxxxxx	Unicast
> --> 100rrrffffffffff	Unicast floooding
> --> 101rrrffffffffff	Registered multicast
> --> 110rrrffffffffff	Non-registered multicast
> --> 111rrrffffffffff	VLAN Broadcast
> -->
> --> Where:
> --> xxxxxxxxxxxxxxx is the RBridge ID
> --> ffffffffff is the FTAG
> --> r is reserved
> -->
> --> -- Silvano
> -->
> -->
> -->
> --> > -----Original Message-----
> --> > From: [email-masked]
> --> [mailto:[email-masked]]
> --> On
> --> > Behalf Of Dinesh G Dutt
> --> > Sent: Tuesday, October 31, 2006 7:25 AM
> --> > To: Radia Perlman
> --> > Cc: [email-masked]
> --> > Subject: Re: [rbridge] New shim header proposal---without
> --> F-tag field
> --> >
> --> > I hit "send" too soon. We talked about an additional bit
> --> in the header
> --> > to identify a multicast frame. Did you see no need for that ?
> --> >
> --> > Dinesh
> --> > Radia Perlman wrote:
> --> > > After talking to Silvano and Dinesh to get them to
> --> explain to me why
> --> > > the use of F-tag didn't multiply the number of trees
> --> that RBridges
> --> > > needed to compute by the number of F-tag values, they
> --> were able to
> --> > > explain to me why they wanted the F-tag. Here is a proposal to
> --> > > get the functionality they want without the use of F-tag.
> --> > >
> --> > > ***********************
> --> > >
> --> > > Motivation for F-tag
> --> > >
> --> > > They want to be able to do multipathing on multicast.
> --> We can already
> --> > > do multipathing on unicast by having an RBridge keep
> --> multiple equal
> --> > > cost (or near equal cost) paths to destination D, and
> --> split traffic
> --> > > however it wants. But if we have a single tree for all
multicast
> --> > > with ingress RBridge R1, then all multicast traffic has to use
> --> > > the same links. The original proposal was to use F-tag
> --> as a selector
> --> > > for a tree. But the modified proposal is to use the
> --> "egress RBridge"
> --> > > field, which wasn't all that useful for multicast, as a "tree
> --> selector".
> --> > >
> --> > > ******************************
> --> > >
> --> > > So the proposal is:
> --> > >
> --> > > In the shim header will only be:
> --> > > 1) 16-bit ingress RBridge
> --> > > 2) 16-bit egress RBridge
> --> > > 3) TTL
> --> > >
> --> > >
> --> > > How these fields will be used in order to do multipathing:
> --> > >
> --> > > a) RBridges calculate a single tree for each ingress RBridge
> --> > >
> --> > > b) For unicast, an RBridge can calculate multiple equal-cost
> --> > > paths to the destination (or near-equal cost), and
> --> split traffic.
> --> That
> --> > > is how
> --> > > we'd get multipathing for unicast. If S7 has two ways to get
to
> --> > > destination D,
> --> > > it can send some of its traffic one way, some of it the
> --> other. This
> --> is
> --> > > solely
> --> > > S7's choice and doesn't need to be coordinated with any other
> --> switches.
> --> > >
> --> > > c) For multicast, we can provide multipathing by
> --> letting the ingress
> --> > RBridge
> --> > > choose the distribution tree.
> --> > > The tree used will be indicated by the "egress RBridge"
> --> > > field. So, if S3 receives a multicast packet from an endnode,
it
> --> puts
> --> > > "S3" as "ingress RBridge", but selects a tree by
> --> whatever means it
> --> > > wants, and puts, say, "S1" into "egress RBridge". That way the
> --> packet
> --> > > will be forwarded based on the tree calculated using S1
> --> as the root.
> --> > >
> --> > > With this proposal, we get multipathing for multicast without
> --> > configuration.
> --> > > The same space used for RBridge nicknames can be used
> --> for choosing
> --> the
> --> > > tree for multicast packets. The number of trees to be
calculated
> --> does
> --> > > not change---it is still per ingress RBridge.
> --> > >
> --> > > Radia
> --> > >
> --> > > _______________________________________________
> --> > > rbridge mailing list
> --> > > [email-masked]
> --> > > http://mailman.postel.org/mailman/listinfo/rbridge
> --> > >
> --> > >
> --> >
> --> > --
> --> > We make our world significant by the courage of our
> --> questions and by
> --> > the depth of our answers.                               -
> --> Carl Sagan
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [email-masked]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>, [email-masked]
Date: Tue, 31 Oct 2006 11:47:41 -0500
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 3752

Radia,

	I don't think there is consensus yet that we only need 16 bits
for RBridge IDs.

	I personally disagree with the part of the proposal below that
builds in the assumption that 16 bits is sufficient.

	My reasoning is that 16 bits may not be large enough if the
future where some implementations may use more than one RBridge ID
for the same device.  Some reasons for doing this are to support per
interface (or per VLAN) IF-IF instances.

	16 bits may get used up much more rapidly than you think if 
implementations are not explicitly forbidden to do this (which is 
not a good idea, given that there is very little that can be done
to enforce such a prohibition - beyond deliberately choosing to use
an "ID-space" too small to accommodate it).

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Monday, October 30, 2006 9:50 PM
--> To: [email-masked]
--> Subject: [rbridge] New shim header proposal---without F-tag field
--> 
--> After talking to Silvano and Dinesh to get them to explain to me why
--> the use of F-tag didn't multiply the number of trees that RBridges
--> needed to compute by the number of F-tag values, they were able to
--> explain to me why they wanted the F-tag. Here is a proposal to
--> get the functionality they want without the use of F-tag.
--> 
--> ***********************
--> 
--> Motivation for F-tag
--> 
--> They want to be able to do multipathing on multicast. We can already
--> do multipathing on unicast by having an RBridge keep multiple equal
--> cost (or near equal cost) paths to destination D, and split traffic
--> however it wants. But if we have a single tree for all multicast
--> with ingress RBridge R1, then all multicast traffic has to use
--> the same links. The original proposal was to use F-tag as a selector
--> for a tree. But the modified proposal is to use the "egress RBridge"
--> field, which wasn't all that useful for multicast, as a 
--> "tree selector".
--> 
--> ******************************
--> 
--> So the proposal is:
--> 
--> In the shim header will only be:
--> 1) 16-bit ingress RBridge
--> 2) 16-bit egress RBridge
--> 3) TTL
--> 
--> 
--> How these fields will be used in order to do multipathing:
--> 
--> a) RBridges calculate a single tree for each ingress RBridge
--> 
--> b) For unicast, an RBridge can calculate multiple equal-cost
--> paths to the destination (or near-equal cost), and split 
--> traffic. That 
--> is how
--> we'd get multipathing for unicast. If S7 has two ways to get to 
--> destination D,
--> it can send some of its traffic one way, some of it the 
--> other. This is 
--> solely
--> S7's choice and doesn't need to be coordinated with any 
--> other switches.
--> 
--> c) For multicast, we can provide multipathing by letting 
--> the ingress RBridge
--> choose the distribution tree.
--> The tree used will be indicated by the "egress RBridge"
--> field. So, if S3 receives a multicast packet from an 
--> endnode, it puts
--> "S3" as "ingress RBridge", but selects a tree by whatever means it
--> wants, and puts, say, "S1" into "egress RBridge". That way 
--> the packet
--> will be forwarded based on the tree calculated using S1 as the root.
--> 
--> With this proposal, we get multipathing for multicast 
--> without configuration.
--> The same space used for RBridge nicknames can be used for 
--> choosing the
--> tree for multicast packets. The number of trees to be 
--> calculated does
--> not change---it is still per ingress RBridge.
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 31 Oct 2006 11:37:27 -0500
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 5125

Silvano,

	You do not need to send a message to the mailing list
to do this, as this is not currently a WG document and you
are one of its authors.

	If you're asking if the draft would be more acceptable
if this change were made, then that is what you should say.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Tuesday, October 31, 2006 11:02 AM
--> To: Dinesh G Dutt; Radia Perlman
--> Cc: [email-masked]
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 
--> I propose that we replace Figure 3 in
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-
--> encap-00.txt
--> 
--> with:
--> 
--> 0xxxxxxxxxxxxxxx	Unicast
--> 100rrrffffffffff	Unicast floooding
--> 101rrrffffffffff	Registered multicast
--> 110rrrffffffffff	Non-registered multicast
--> 111rrrffffffffff	VLAN Broadcast
--> 
--> Where:
--> xxxxxxxxxxxxxxx is the RBridge ID
--> ffffffffff is the FTAG
--> r is reserved
--> 
--> -- Silvano
--> 
--> 
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]
--> On
--> > Behalf Of Dinesh G Dutt
--> > Sent: Tuesday, October 31, 2006 7:25 AM
--> > To: Radia Perlman
--> > Cc: [email-masked]
--> > Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> > 
--> > I hit "send" too soon. We talked about an additional bit 
--> in the header
--> > to identify a multicast frame. Did you see no need for that ?
--> > 
--> > Dinesh
--> > Radia Perlman wrote:
--> > > After talking to Silvano and Dinesh to get them to 
--> explain to me why
--> > > the use of F-tag didn't multiply the number of trees 
--> that RBridges
--> > > needed to compute by the number of F-tag values, they 
--> were able to
--> > > explain to me why they wanted the F-tag. Here is a proposal to
--> > > get the functionality they want without the use of F-tag.
--> > >
--> > > ***********************
--> > >
--> > > Motivation for F-tag
--> > >
--> > > They want to be able to do multipathing on multicast. 
--> We can already
--> > > do multipathing on unicast by having an RBridge keep 
--> multiple equal
--> > > cost (or near equal cost) paths to destination D, and 
--> split traffic
--> > > however it wants. But if we have a single tree for all multicast
--> > > with ingress RBridge R1, then all multicast traffic has to use
--> > > the same links. The original proposal was to use F-tag 
--> as a selector
--> > > for a tree. But the modified proposal is to use the 
--> "egress RBridge"
--> > > field, which wasn't all that useful for multicast, as a "tree
--> selector".
--> > >
--> > > ******************************
--> > >
--> > > So the proposal is:
--> > >
--> > > In the shim header will only be:
--> > > 1) 16-bit ingress RBridge
--> > > 2) 16-bit egress RBridge
--> > > 3) TTL
--> > >
--> > >
--> > > How these fields will be used in order to do multipathing:
--> > >
--> > > a) RBridges calculate a single tree for each ingress RBridge
--> > >
--> > > b) For unicast, an RBridge can calculate multiple equal-cost
--> > > paths to the destination (or near-equal cost), and 
--> split traffic.
--> That
--> > > is how
--> > > we'd get multipathing for unicast. If S7 has two ways to get to
--> > > destination D,
--> > > it can send some of its traffic one way, some of it the 
--> other. This
--> is
--> > > solely
--> > > S7's choice and doesn't need to be coordinated with any other
--> switches.
--> > >
--> > > c) For multicast, we can provide multipathing by 
--> letting the ingress
--> > RBridge
--> > > choose the distribution tree.
--> > > The tree used will be indicated by the "egress RBridge"
--> > > field. So, if S3 receives a multicast packet from an endnode, it
--> puts
--> > > "S3" as "ingress RBridge", but selects a tree by 
--> whatever means it
--> > > wants, and puts, say, "S1" into "egress RBridge". That way the
--> packet
--> > > will be forwarded based on the tree calculated using S1 
--> as the root.
--> > >
--> > > With this proposal, we get multipathing for multicast without
--> > configuration.
--> > > The same space used for RBridge nicknames can be used 
--> for choosing
--> the
--> > > tree for multicast packets. The number of trees to be calculated
--> does
--> > > not change---it is still per ingress RBridge.
--> > >
--> > > Radia
--> > >
--> > > _______________________________________________
--> > > rbridge mailing list
--> > > [email-masked]
--> > > http://mailman.postel.org/mailman/listinfo/rbridge
--> > >
--> > >
--> > 
--> > --
--> > We make our world significant by the courage of our 
--> questions and by
--> > the depth of our answers.                               - 
--> Carl Sagan
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Tue, 31 Oct 2006 08:01:58 -0800
From: "Silvano Gai" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 3794

I propose that we replace Figure 3 in
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt

with:

0xxxxxxxxxxxxxxx	Unicast
100rrrffffffffff	Unicast floooding
101rrrffffffffff	Registered multicast
110rrrffffffffff	Non-registered multicast
111rrrffffffffff	VLAN Broadcast

Where:
xxxxxxxxxxxxxxx is the RBridge ID
ffffffffff is the FTAG
r is reserved

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dinesh G Dutt
> Sent: Tuesday, October 31, 2006 7:25 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] New shim header proposal---without F-tag field
> 
> I hit "send" too soon. We talked about an additional bit in the header
> to identify a multicast frame. Did you see no need for that ?
> 
> Dinesh
> Radia Perlman wrote:
> > After talking to Silvano and Dinesh to get them to explain to me why
> > the use of F-tag didn't multiply the number of trees that RBridges
> > needed to compute by the number of F-tag values, they were able to
> > explain to me why they wanted the F-tag. Here is a proposal to
> > get the functionality they want without the use of F-tag.
> >
> > ***********************
> >
> > Motivation for F-tag
> >
> > They want to be able to do multipathing on multicast. We can already
> > do multipathing on unicast by having an RBridge keep multiple equal
> > cost (or near equal cost) paths to destination D, and split traffic
> > however it wants. But if we have a single tree for all multicast
> > with ingress RBridge R1, then all multicast traffic has to use
> > the same links. The original proposal was to use F-tag as a selector
> > for a tree. But the modified proposal is to use the "egress RBridge"
> > field, which wasn't all that useful for multicast, as a "tree
selector".
> >
> > ******************************
> >
> > So the proposal is:
> >
> > In the shim header will only be:
> > 1) 16-bit ingress RBridge
> > 2) 16-bit egress RBridge
> > 3) TTL
> >
> >
> > How these fields will be used in order to do multipathing:
> >
> > a) RBridges calculate a single tree for each ingress RBridge
> >
> > b) For unicast, an RBridge can calculate multiple equal-cost
> > paths to the destination (or near-equal cost), and split traffic.
That
> > is how
> > we'd get multipathing for unicast. If S7 has two ways to get to
> > destination D,
> > it can send some of its traffic one way, some of it the other. This
is
> > solely
> > S7's choice and doesn't need to be coordinated with any other
switches.
> >
> > c) For multicast, we can provide multipathing by letting the ingress
> RBridge
> > choose the distribution tree.
> > The tree used will be indicated by the "egress RBridge"
> > field. So, if S3 receives a multicast packet from an endnode, it
puts
> > "S3" as "ingress RBridge", but selects a tree by whatever means it
> > wants, and puts, say, "S1" into "egress RBridge". That way the
packet
> > will be forwarded based on the tree calculated using S1 as the root.
> >
> > With this proposal, we get multipathing for multicast without
> configuration.
> > The same space used for RBridge nicknames can be used for choosing
the
> > tree for multicast packets. The number of trees to be calculated
does
> > not change---it is still per ingress RBridge.
> >
> > Radia
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
> 
> --
> We make our world significant by the courage of our questions and by
> the depth of our answers.                               - Carl Sagan
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Tue, 31 Oct 2006 07:25:03 -0800
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 2830

I hit "send" too soon. We talked about an additional bit in the header 
to identify a multicast frame. Did you see no need for that ?

Dinesh
Radia Perlman wrote:
> After talking to Silvano and Dinesh to get them to explain to me why
> the use of F-tag didn't multiply the number of trees that RBridges
> needed to compute by the number of F-tag values, they were able to
> explain to me why they wanted the F-tag. Here is a proposal to
> get the functionality they want without the use of F-tag.
>
> ***********************
>
> Motivation for F-tag
>
> They want to be able to do multipathing on multicast. We can already
> do multipathing on unicast by having an RBridge keep multiple equal
> cost (or near equal cost) paths to destination D, and split traffic
> however it wants. But if we have a single tree for all multicast
> with ingress RBridge R1, then all multicast traffic has to use
> the same links. The original proposal was to use F-tag as a selector
> for a tree. But the modified proposal is to use the "egress RBridge"
> field, which wasn't all that useful for multicast, as a "tree selector".
>
> ******************************
>
> So the proposal is:
>
> In the shim header will only be:
> 1) 16-bit ingress RBridge
> 2) 16-bit egress RBridge
> 3) TTL
>
>
> How these fields will be used in order to do multipathing:
>
> a) RBridges calculate a single tree for each ingress RBridge
>
> b) For unicast, an RBridge can calculate multiple equal-cost
> paths to the destination (or near-equal cost), and split traffic. That 
> is how
> we'd get multipathing for unicast. If S7 has two ways to get to 
> destination D,
> it can send some of its traffic one way, some of it the other. This is 
> solely
> S7's choice and doesn't need to be coordinated with any other switches.
>
> c) For multicast, we can provide multipathing by letting the ingress RBridge
> choose the distribution tree.
> The tree used will be indicated by the "egress RBridge"
> field. So, if S3 receives a multicast packet from an endnode, it puts
> "S3" as "ingress RBridge", but selects a tree by whatever means it
> wants, and puts, say, "S1" into "egress RBridge". That way the packet
> will be forwarded based on the tree calculated using S1 as the root.
>
> With this proposal, we get multipathing for multicast without configuration.
> The same space used for RBridge nicknames can be used for choosing the
> tree for multicast packets. The number of trees to be calculated does
> not change---it is still per ingress RBridge.
>
> Radia
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Tue, 31 Oct 2006 07:22:52 -0800
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 2765

I'm fine with this proposal, Radia. Thanks for working through this,

Dinesh
Radia Perlman wrote:
> After talking to Silvano and Dinesh to get them to explain to me why
> the use of F-tag didn't multiply the number of trees that RBridges
> needed to compute by the number of F-tag values, they were able to
> explain to me why they wanted the F-tag. Here is a proposal to
> get the functionality they want without the use of F-tag.
>
> ***********************
>
> Motivation for F-tag
>
> They want to be able to do multipathing on multicast. We can already
> do multipathing on unicast by having an RBridge keep multiple equal
> cost (or near equal cost) paths to destination D, and split traffic
> however it wants. But if we have a single tree for all multicast
> with ingress RBridge R1, then all multicast traffic has to use
> the same links. The original proposal was to use F-tag as a selector
> for a tree. But the modified proposal is to use the "egress RBridge"
> field, which wasn't all that useful for multicast, as a "tree selector".
>
> ******************************
>
> So the proposal is:
>
> In the shim header will only be:
> 1) 16-bit ingress RBridge
> 2) 16-bit egress RBridge
> 3) TTL
>
>
> How these fields will be used in order to do multipathing:
>
> a) RBridges calculate a single tree for each ingress RBridge
>
> b) For unicast, an RBridge can calculate multiple equal-cost
> paths to the destination (or near-equal cost), and split traffic. That 
> is how
> we'd get multipathing for unicast. If S7 has two ways to get to 
> destination D,
> it can send some of its traffic one way, some of it the other. This is 
> solely
> S7's choice and doesn't need to be coordinated with any other switches.
>
> c) For multicast, we can provide multipathing by letting the ingress RBridge
> choose the distribution tree.
> The tree used will be indicated by the "egress RBridge"
> field. So, if S3 receives a multicast packet from an endnode, it puts
> "S3" as "ingress RBridge", but selects a tree by whatever means it
> wants, and puts, say, "S1" into "egress RBridge". That way the packet
> will be forwarded based on the tree calculated using S1 as the root.
>
> With this proposal, we get multipathing for multicast without configuration.
> The same space used for RBridge nicknames can be used for choosing the
> tree for multicast packets. The number of trees to be calculated does
> not change---it is still per ingress RBridge.
>
> Radia
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Tue, 31 Oct 2006 09:18:46 -0500
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 3157

This sounds fine to me, as it also means that implementations that don't
want to support this won't suffer from the additional space and work
involved in the F-Tag. My primary question would be--what will happen if
two implementations, one supporting, the other not, are used in the same
network?

:-)

Russ

Radia Perlman wrote:
> After talking to Silvano and Dinesh to get them to explain to me why
> the use of F-tag didn't multiply the number of trees that RBridges
> needed to compute by the number of F-tag values, they were able to
> explain to me why they wanted the F-tag. Here is a proposal to
> get the functionality they want without the use of F-tag.
> 
> ***********************
> 
> Motivation for F-tag
> 
> They want to be able to do multipathing on multicast. We can already
> do multipathing on unicast by having an RBridge keep multiple equal
> cost (or near equal cost) paths to destination D, and split traffic
> however it wants. But if we have a single tree for all multicast
> with ingress RBridge R1, then all multicast traffic has to use
> the same links. The original proposal was to use F-tag as a selector
> for a tree. But the modified proposal is to use the "egress RBridge"
> field, which wasn't all that useful for multicast, as a "tree selector".
> 
> ******************************
> 
> So the proposal is:
> 
> In the shim header will only be:
> 1) 16-bit ingress RBridge
> 2) 16-bit egress RBridge
> 3) TTL
> 
> 
> How these fields will be used in order to do multipathing:
> 
> a) RBridges calculate a single tree for each ingress RBridge
> 
> b) For unicast, an RBridge can calculate multiple equal-cost
> paths to the destination (or near-equal cost), and split traffic. That 
> is how
> we'd get multipathing for unicast. If S7 has two ways to get to 
> destination D,
> it can send some of its traffic one way, some of it the other. This is 
> solely
> S7's choice and doesn't need to be coordinated with any other switches.
> 
> c) For multicast, we can provide multipathing by letting the ingress RBridge
> choose the distribution tree.
> The tree used will be indicated by the "egress RBridge"
> field. So, if S3 receives a multicast packet from an endnode, it puts
> "S3" as "ingress RBridge", but selects a tree by whatever means it
> wants, and puts, say, "S1" into "egress RBridge". That way the packet
> will be forwarded based on the tree calculated using S1 as the root.
> 
> With this proposal, we get multipathing for multicast without configuration.
> The same space used for RBridge nicknames can be used for choosing the
> tree for multicast packets. The number of trees to be calculated does
> not change---it is still per ingress RBridge.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Mon, 30 Oct 2006 19:32:30 -0800
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 2883

Radia,

Thank you for improving our proposal,
Of course, I am in favor

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Monday, October 30, 2006 6:50 PM
> To: [email-masked]
> Subject: [rbridge] New shim header proposal---without F-tag field
> 
> After talking to Silvano and Dinesh to get them to explain to me why
> the use of F-tag didn't multiply the number of trees that RBridges
> needed to compute by the number of F-tag values, they were able to
> explain to me why they wanted the F-tag. Here is a proposal to
> get the functionality they want without the use of F-tag.
> 
> ***********************
> 
> Motivation for F-tag
> 
> They want to be able to do multipathing on multicast. We can already
> do multipathing on unicast by having an RBridge keep multiple equal
> cost (or near equal cost) paths to destination D, and split traffic
> however it wants. But if we have a single tree for all multicast
> with ingress RBridge R1, then all multicast traffic has to use
> the same links. The original proposal was to use F-tag as a selector
> for a tree. But the modified proposal is to use the "egress RBridge"
> field, which wasn't all that useful for multicast, as a "tree
selector".
> 
> ******************************
> 
> So the proposal is:
> 
> In the shim header will only be:
> 1) 16-bit ingress RBridge
> 2) 16-bit egress RBridge
> 3) TTL
> 
> 
> How these fields will be used in order to do multipathing:
> 
> a) RBridges calculate a single tree for each ingress RBridge
> 
> b) For unicast, an RBridge can calculate multiple equal-cost
> paths to the destination (or near-equal cost), and split traffic. That
> is how
> we'd get multipathing for unicast. If S7 has two ways to get to
> destination D,
> it can send some of its traffic one way, some of it the other. This is
> solely
> S7's choice and doesn't need to be coordinated with any other
switches.
> 
> c) For multicast, we can provide multipathing by letting the ingress
> RBridge
> choose the distribution tree.
> The tree used will be indicated by the "egress RBridge"
> field. So, if S3 receives a multicast packet from an endnode, it puts
> "S3" as "ingress RBridge", but selects a tree by whatever means it
> wants, and puts, say, "S1" into "egress RBridge". That way the packet
> will be forwarded based on the tree calculated using S1 as the root.
> 
> With this proposal, we get multipathing for multicast without
> configuration.
> The same space used for RBridge nicknames can be used for choosing the
> tree for multicast packets. The number of trees to be calculated does
> not change---it is still per ingress RBridge.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Mon, 30 Oct 2006 18:49:52 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] New shim header proposal---without F-tag field
Status: RO
Content-Length: 2269

After talking to Silvano and Dinesh to get them to explain to me why
the use of F-tag didn't multiply the number of trees that RBridges
needed to compute by the number of F-tag values, they were able to
explain to me why they wanted the F-tag. Here is a proposal to
get the functionality they want without the use of F-tag.

***********************

Motivation for F-tag

They want to be able to do multipathing on multicast. We can already
do multipathing on unicast by having an RBridge keep multiple equal
cost (or near equal cost) paths to destination D, and split traffic
however it wants. But if we have a single tree for all multicast
with ingress RBridge R1, then all multicast traffic has to use
the same links. The original proposal was to use F-tag as a selector
for a tree. But the modified proposal is to use the "egress RBridge"
field, which wasn't all that useful for multicast, as a "tree selector".

******************************

So the proposal is:

In the shim header will only be:
1) 16-bit ingress RBridge
2) 16-bit egress RBridge
3) TTL

How these fields will be used in order to do multipathing:

a) RBridges calculate a single tree for each ingress RBridge

b) For unicast, an RBridge can calculate multiple equal-cost
paths to the destination (or near-equal cost), and split traffic. That 
is how
we'd get multipathing for unicast. If S7 has two ways to get to 
destination D,
it can send some of its traffic one way, some of it the other. This is 
solely
S7's choice and doesn't need to be coordinated with any other switches.

c) For multicast, we can provide multipathing by letting the ingress RBridge
choose the distribution tree.
The tree used will be indicated by the "egress RBridge"
field. So, if S3 receives a multicast packet from an endnode, it puts
"S3" as "ingress RBridge", but selects a tree by whatever means it
wants, and puts, say, "S1" into "egress RBridge". That way the packet
will be forwarded based on the tree calculated using S1 as the root.

With this proposal, we get multipathing for multicast without configuration.
The same space used for RBridge nicknames can be used for choosing the
tree for multicast packets. The number of trees to be calculated does
not change---it is still per ingress RBridge.

Radia

Content-class: urn:content-classes:message
Date: Mon, 30 Oct 2006 13:10:05 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] A question onhttp://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Status: RO
Content-Length: 8927

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6FC4E.A10508F2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Silvano,
=20
A mantra of the original proposal was "RBridges look like routers to
bridges and look like bridges to routers" so RBridges would drop BPDUs
and, from the point of view of a router an arbitrary mesh of hosts,
bridges, and RBridges looks like one logical link.
=20
According to the current proposal, on an RBridge interface, you can
connect other RBridges, bridges, and hosts, assuming the hardware nature
of the interface and physical link allow mutiple access.
=20
Donald

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Silvano Gai
Sent: Saturday, October 28, 2006 10:47 AM
To: [email-masked]
Subject: [rbridge] A question
onhttp://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.t
xt

=20

Eric,

=20

When you say:

"   In order to simplify the interactions between RBridges and bridges -
   in particular, relative to spanning tree forwarding - RBridges do not
   actively participate in spanning tree protocol with 802.1 bridges.=20

"

=20

Do you mean:

1)       RBridges propagate BPDUs as normal multicast frames

2)       RBridges drop BPDUs=20

=20

Also:

On the same RBridge interface, can I connect other RBridges and also
hosts?

=20

Thank You

=20

-- Silvano

------_=_NextPart_001_01C6FC4E.A10508F2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt =
72.0pt 90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0pt
}
UL {
	MARGIN-BOTTOM: 0pt
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Silvano,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>A mantra of the original proposal was "RBridges =
look like=20
routers to bridges and look like bridges to routers" so RBridges would =
drop=20
BPDUs and, from the point of view of a router an arbitrary mesh of =
hosts,=20
bridges, and RBridges looks like one logical link.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>According to the current proposal, on an =
RBridge interface,=20
you can connect other RBridges, bridges, and hosts, assuming the =
hardware nature=20
of the interface and physical link allow mutiple =
access.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D776110820-28102006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Donald</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Silvano=20
Gai<BR><B>Sent:</B> Saturday, October 28, 2006 10:47 AM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> [rbridge] A question=20
onhttp://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.tx=
t<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Eric,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">When you=20
say:<o:p></o:p></SPAN></FONT></P><PRE><FONT face=3DArial size=3D2><SPAN =
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&#8220;</SPAN></FONT>&nbsp;&nbsp; In order to simplify the =
interactions between RBridges and bridges -<o:p></o:p></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp; in particular, relative to spanning tree forwarding - =
RBridges do not<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; actively =
participate in spanning tree protocol with 802.1 bridges. =
<o:p></o:p></SPAN></FONT></PRE>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&#8220;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Do you=20
mean:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">1)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">RBridges propagate BPDUs =
as normal=20
multicast frames<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">2)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">RBridges drop BPDUs=20
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Also:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">On the same RBridge =
interface, can I=20
connect other RBridges and also hosts?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thank=20
You<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">--=20
Silvano<o:p></o:p></SPAN></FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C6FC4E.A10508F2--

Content-class: urn:content-classes:message
Date: Mon, 30 Oct 2006 09:28:55 -0800
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] VLANs
Status: RO
Content-Length: 1037

The second biggest issue I have with the four documents (first one being
broadcast/multicast storm) is the definition of VLANs.

I don't think the term VLAN is used consistently in the documents.

1) Sometimes VLAN refers to the VLANs present on the untagged frames,
which must be propagated by ISIS, VLAN pruning must be performed and so
on. They all share the same core instance of ISIS.

2) Sometimes VLANs refers to the fact that a CRED can be encapsulated
into a VLAN (present as a 1Q tag in the outer header) and therefore ISIS
will run per VLAN, i.e. there will be a core instance of ISIS per each
VLAN. This seems to be the case in some part of the architectural
document.

I propose to name the former IVLAN (inner VLAN) and the latter OVLAN
(Outer VLAN), with reference to the position of the 1Q tag in the frame.

This is also very relevant for the discussion that we need to complete
on the FTAG: it is my understanding that some folks think that the FTAG
is not needed, since there may be an OVLAN.

Comments?

-- Silvano

Content-class: urn:content-classes:message
Date: Mon, 30 Oct 2006 09:18:20 -0800
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Broadcsat/Multicast storm
Status: RO
Content-Length: 509

After having spent many hours reading all four documents in detail, the
biggest issue that I have is with Broadcsat/Multicast storms.

I haven't read a clear requirement to mandatory avoid transient loops
for multicast/broadcast traffic, since transient loops create
broadcast/multicast storms.

I haven't seen this topic clearly addressed by the architecture of the
RBridge or by the initial protocol specification.

If this issue is not solved, I don't think the RBridge will be
deployable.

-- Silvano

Content-class: urn:content-classes:message
Date: Mon, 30 Oct 2006 09:12:49 -0800
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 72072

Comments inline marked "sgai n>"

Sgai 1> This documents assumes that all multicast traffic must be
propagated through the IRT (Ingress Rbridge Tree) and therefore denies
any possibility for shared trees.

-- Silvano

--------------------------------------------------------

... snip ...

     1. Introduction 

        This document describes an architecture that addresses the TRILL

        problem and applicability statement [2]. This architecture is 
        composed of a set of devices called RBridges that cooperate 
        together within an Ethernet network to provide a layer two 
        delivery service that makes efficient use of available links 
        using a link state routing protocol. The service provided is 
        analogous to creation of a single, virtual device composed of an

        overlay of tunnels, constructed between RBridge devices, using 
        link state routing. RBridges thus support increased RBridge to 
        RBridge bandwidth and fault tolerance, when compared to 
        conventional Ethernet bridges (which forward frames via a 
        spanning tree), while still being compatible with bridges and 
        hubs. 

        The principal objectives of this architecture is to provide an 
        overview of the use of these RBridges in meeting the following 
        goals: 

          1) Provide a form of optimized layer two delivery service. 

          2) Use existing technology as much as possible. 

          3) Allow for configuration free deployment. 

        In providing a (optimized) layer two (L2) service, key factors 
        we want to maintain are: transparency to higher layer (layer 3 
        and above) delivery services and mechanisms, and use of location

        independent addressing. Optimization of the L2 delivery service 
        consists of: use of an optimized subset of all available paths 
        and support for pruning of multicast traffic delivery paths. 

Sgai 2> I think we should explicitly mention layer 2 multipath.

        To accomplish the goal of using existing technologies as much as

        possible, we intend to specify minimal extensions (if required) 
        to one or more existing link-state routing protocols, as well as

        defining the specific sub-set of existing bridging technologies 
        this architecture makes use of.  

        The extent to which routing protocol extensions may be required 
        depends on the closeness of the "fit" of any chosen routing 
        protocol to RBridge protocol requirements. See [6] for further 
        information on these requirements. The use of a specific routing

        protocol - along with appropriate extensions and enhancements - 
        will be defined in corresponding RBridge protocol specifications

        (see [3] for example). 

     Gray                     Expires April, 2007               [Page 4]

     Internet-Draft           RBridge Architecture          October 2006

        Specific protocol specifications will also describe the details 
        of interactions between the RBridge protocol and specific L2 
        technologies - i.e. - Virtual Local Area Networking (VLAN), L2 
        Multicast, etc. 

        As an overview, however, the intention is to use a link-state 
        routing protocol to accomplish the following: 

          1) Discover RBridge peers. 

          2) Determine RBridge link topology. 

          3) Advertise L2 reachability information. 

          4) Establish L2 delivery using shortest path (verses STP). 

Sgai 3> It is very important to say that this protocol must provide a
loop free topology for multicast/broadcast under any condition,
including transient loops, to prevent multicast/broadcast storm.

        There are additional RBridge protocol requirements - above and 
        beyond those addressed by any existing routing protocol - that 
        are identified in this document and need to be addressed in 
        corresponding RBridge protocol specifications. 

        To allow for configuration free deployment, specific protocol 
        specifications need to explicitly define the conditions under 
        which RBridges may - and may not - be deployed as-is (plug and 
        play), and the mechanisms that are required to allow this. For 
        example, the first requirement any RBridge protocol must meet is

        to derive information required by link-state routing protocol(s)

        for protocol start-up and communications between peers - such as

        higher-layer addressing and/or identifiers, encapsulation header

        information, etc. 

        At the abstract level, RBridges need to maintain the following 
        information: 

          1) Peer information, 

          2) Topology information, 

          3) Forwarding information -  

               a. unicast,  

               b. flooded, and  

               c. multicast. 

      
     Gray                     Expires April, 2007               [Page 5]

     Internet-Draft           RBridge Architecture          October 2006

        Peer information may be acquired via the routing protocol, or 
        may be discovered as a result of RBridge-specific peer discovery

        mechanisms.  Topology information is expected to be acquired via

        the link-state routing protocol. 

        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. 

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).

        The remainder of this document outlines the TRILL architecture 
        of an RBridge-based solution and describes RBridge components, 
        interactions and functions. Note that this document is not 
        intended to represent the only solution to the TRILL problem 
        statement, nor does it specify the protocols that instantiate 
        this architecture - or that only one such set of protocols is 
        prescribed. The former may be contained in other architecture 
        documents and the latter would be contained in separate 
        specification documents (see - e.g. - [3]). 

     2. Background 

        This architecture is based on the RBridge system described in an

        Infocom paper [1]. That paper describes the RBridge system as a 
        specific instance; this document abstracts architectural 
        features only. The remainder of this section describes the 
        terminology of this document, which may differ from that of the 
        original paper. 

     2.1. Existing Terminology 

        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. 

Sgai 5> here there is some confusion between 802 and 802.3

        o  802.1D: IEEE Specification for bridged Ethernet, including 
           the BPDUs used in spanning tree protocol (STP) [5]. 

      
     Gray                     Expires April, 2007               [Page 6]

     Internet-Draft           RBridge Architecture          October 2006

        o  ARP: Address Resolution Protocol - a protocol used to find an

           address of form X, given a corresponding address of form Y. 
           In this document, ARP refers to the well-known protocol used 
           to resolve L2 (MAC) addresses, using a given L3 (IP) address.

           See [10] for further information on IP ARP. 

        o  Bridge: an Ethernet (L2, 802.1D) device with multiple ports 
           that receives incoming frames on a port and transmits them on

           zero or more of the other ports; bridges support both bridge 
           learning and STP. Transparent bridges do not modify the L2 
           PDU being forwarded. 

        o  Bridge Learning: process by which a bridge determines on 
           which single outgoing port to transmit (forward or copy) an 
           incoming unicast frame. This process depends on consistent 
           forwarding as "learning" uses the source MAC address of 
           frames received on each interface. Layer 2 (L2) forwarding 
           devices "learn" the location of L2 destinations by peeking at

           layer 2 source addresses during frame forwarding, and store 
           the association of source address and receiving interface.  
           L2 forwarding devices use this information to create 
           "filtering database" entries and - gradually - eliminate the 
           need for flooding. 

        o  Bridge Protocol Data Unit (BPDU): the frame type associated 
           with bridge control functions (for example: STP/RSTP). 

        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.

        o  Broadcast Domain: the set of (layer 2) devices that must be 
           reached (or reachable) by (layer 2) broadcast traffic 
           injected into the domain. 

        o  Broadcast Traffic: traffic intended for receipt by all 
           devices in a broadcast domain.  

        o  Ethernet: See "802" above. 

Sgai 7> for Ethernet is better to reference 802.3

        o  Filtering Database - database containing association 
           information of (source layer 2 address, arrival interface).  
           The interface that is associated with a specific layer 2 
           source address, is the same interface which is used to 
           forward frames having that address as a destination.  When a 
           layer 2 forwarding device has no entry for the destination 
           layer 2 address of any frame it receives, the frame is 
           "flooded". 

     Gray                     Expires April, 2007               [Page 7]

     Internet-Draft           RBridge Architecture          October 2006

        o  Flooded Traffic - traffic forwarded on all interfaces, except

           those on which it was received, within the same broadcast 
           domain. Flooding is the mechanism by which traffic is 
           delivered to a destination that is currently "unknown" (i.e. 
           - either not yet "learned", or aged out of the "filtering 
           database"). 

        o  Flooding - the process of forwarding traffic to ensure that 
           frames reach all possible destinations when the destination 
           location is not known.  In "flooding", an 802.1D forwarding 
           device forwards a frame for any destination not "known" (i.e.

           - not in the filtering database) on every active interface 
           except that one on which it was received. See also VLAN 
           flooding. 

        o  Frame: in this document, frame refers to an Ethernet (L2) 
           unit of transmission (PDU), including header, data, and 
           trailer (or payload and envelope). 

        o  Hub: an Ethernet (L2, 802) device with multiple ports which

sgai 8> for Hub is better to reference 802.3
 
           transparently transmits frames arriving on any port to all 
           other ports.  This is a functional definition, as there are 
           devices that combine this function with certain bridge-like 
           functions that may - under certain conditions - be referred 
           to as "hubs". 

        o  IGP: Interior Gateway Protocol - any of the potential (link-
           state) routing protocols candidates considered as potentially

           useful RBridge routing protocols. 

        o  IS-IS: Intermediate System to Intermediate System routing 
           protocol. See [8] for further information on IS-IS. 

        o  LAN: Local Area Network. A LAN is an L2 forwarding domain. 
           This term is synonymous with Ethernet Subnet in the context 
           of this document. 

        o  MAC: Media Access Control - mechanisms and addressing for L2 
           frame forwarding.  

        o  Multicast Forwarding: forwarding methods that apply to frames

           with broadcast or multicast destination MAC addresses. 

        o  Node: a device with an L2 (MAC) address that sources and/or 
           sinks L2 frames. 

Sgai 9> The IEEE term is "station".

      
     Gray                     Expires April, 2007               [Page 8]

     Internet-Draft           RBridge Architecture          October 2006

        o  OSPF: Open Shortest Path First routing protocol. See [7] and 
           [9] for further information on OSPF. 

        o  Packet: in this document, packet refers to L3 (or above) data

           transmission units (PDU - e.g. - an IP Packet (RFC791 [4]), 
           including header and data. 

        o  PDU: Protocol Data Unit - unit of data to be transmitted by a

           protocol. To distinguish L2 and L3 PDUs, we refer to L2 PDUs 
           as "frames" and L3 PDUs as "packets" in this (and related) 
           document(s). 

        o  Router: a device that performs IP (L3) forwarding (the 
           "routing function"); RBridges typically do not span routers 
           (i.e. - provide a connection from one router interface to 
           another router interface on the same router). 

        o  Routing Function: in this document, the "routing function" 
           consists of forwarding IP packets between L2 broadcast 
           domains, based on L3 addressing and forwarding information. 
           In the process of performing the "routing function", devices 
           (typically routers) usually forward packets from one L2 
           broadcast domain to another (one, or more in the IP multicast

           case) - distinct - L2 broadcast domain(s). RBridges cannot 
           span the routing function. 

        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"  

        o  Spanning Tree Protocol (STP): an Ethernet (802.1D) protocol 
           for establishing and maintaining a single spanning tree among

           all the bridges on a local Ethernet segment. Also, Rapid 
           Spanning Tree Protocol (RSTP). In this document, STP and RSTP

           are considered to be the same. 

        o  Spanning Tree Table (STT): a table containing port activation

           status information as determined during STP. 

        o  SPF: Shortest Path First - an algorithm name associated with 
           routing, used to determine a shortest path graph traversal. 

      
     Gray                     Expires April, 2007               [Page 9]

     Internet-Draft           RBridge Architecture          October 2006

        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.
 
           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. 
 
           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"

        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.

        o  VLAN Flooding: flooding as described previously, except that 
           frames are only forwarded on those interfaces configured for 
           participation in the applicable VLAN. 

     2.2. RBridge Terminology 

        The following terms are defined in this document and intended 
        for use in derivative documents intended to specify components, 
        protocol, behavior and encapsulation relative to the 
        architecture specified in this document. 

        o  CRED: Cooperating RBridges and Encapsulation Tunnels - a 
           topological construct consisting of a set of cooperating 
           RBridges, and the forwarding tunnels connecting them.  

      
     Gray                     Expires April, 2007              [Page 10]

     Internet-Draft           RBridge Architecture          October 2006

        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.  

        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.

        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?

        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?

      
     Gray                     Expires April, 2007              [Page 11]

     Internet-Draft           RBridge Architecture          October 2006

        o  Designated RBridge (DR): the RBridge associated with ingress 
           and egress traffic to a particular Ethernet link having 
           shared access among multiple RBridges; that RBridge is such a

           link's "Designated RBridge". The Designated RBridge is 
           determined by an election process among those RBridges having

           shared access via a single Segment. 

        o  Edge RBridge (edge of a CRED): describes RBridges that serve 
           to ingress frames into the CRED and egress frames from the 
           CRED. L2 frames transiting an RBridge CRED enter, and leave, 
           it via an edge RBridge. 

        o  Egress RBridge: for any specific frame, the RBridge through 
           which that frame leaves the CRED. For frames transiting a 
           CRED, the egress RBridge is an edge RBridge where RBridge 
           encapsulation is removed from the transit frames prior to 
           exiting the CRED. 

        o  Forwarding Tunnels: in this document, CRED Forwarding Tunnels

           (or Forwarding Tunnels) is used to refer to the paths for 
           forwarding transit frames, encapsulated at an RBridge ingress

           and decapsulated at an RBridge egress. 

        o  Ingress RBridge: for any specific frame, the RBridge through 
           which that frame enters the CRED. For frames transiting a 
           CRED, the ingress RBridge is the edge RBridge where RBridge 
           encapsulation is added to the transit traffic entering the 
           CRED. 

        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.

           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.

The tree consists of a set of one or more 
           next-hops to be used when the ingress RBridge receives a 
           multicast or broadcast frame (frame with a multicast or 
           broadcast destination address), or frame with unknown 
           destination addresses.  If forwarding frames hop-by-hop, next

           hop RBridges will, in turn, have a similar set of one or more

           next-hops to be used for forwarding these frames - when 
           received from an upstream, or ingress, RBridge.  This 
           progression continues until frames arrive at egress RBridges.

        o  LPT: Learned Port Table. See Filtering Database. 

Sgai 21> not proper terminology, I would use "filtering database"
everywhere.

     Gray                     Expires April, 2007              [Page 12]

     Internet-Draft           RBridge Architecture          October 2006

        o  RBridge: a logical device as specified in this document, 
           which incorporate both routing and bridging features, thus 
           allowing for the achievement of TRILL Architecture goals. A 
           single RBridge device which can aggregate with other RBridge 
           devices to create a CRED. 

     3. Components 

        A CRED is composed of RBridge devices and the forwarding tunnels

        that connect them; all other Ethernet link subnet devices, such 
        as bridges, hubs, and nodes, operate conventionally in the 
        presence of an RBridge. 

     3.1. RBridge Device 

        An RBridge is a bridge-like device that forwards frames on an 
        Ethernet link segment. It has one or more Ethernet ports which 
        may be wired or wireless;

sgai 22> I wired port is Ehernet, i.e. IEEE 802.3, a wireless port is
not Ethernet, it is IEEE 802.11.

 the particular physical layer is not 
        relevant. An RBridge is defined more by its behavior than its 
        structure, although it contains three tables which distinguish 
        it from conventional bridges. 

        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: 

sgai 23> they learn because STP guarantees symmetrical forwarding

the source addresses of incoming frames indicate 
        that the incoming port is to be used as output for frames 
        destined to that address. Incoming frames are checked against 
        the LPT and forwarded to the particular port if a match occurs, 
        otherwise they are flooded out all active ports (except the 
        incoming port). 

Sgai 24> active ports -> forwarding ports

        The STT indicates the ports used in the spanning tree. 

Sgai 25> there is no STT, there is a state associated with each port
that can be: disabled, blocking, listening, learning, and forwarding

Details 
        of STP operation are out of scope for this document, however the

        result of STP is to disable ports 

sgai 26> disabled -> blocking

which would otherwise result 
        in more than one path traversal of the spanning tree. 

        RBridges, by comparison, have a CRED Forwarding Table (CFT - 
        used for unicast forwarding of RBridge encapsulated frames 
        across the CRED), CFT-IRT (used for flooding, broadcast or 
        multicast forwarding of RBridge encapsulated frames across the 
        CRED) and a CRED Transit Table (CTT - used by the ingress 
        RBridge to determine what encapsulation to use for frames 
        received as un-encapsulated from non-RBridge devices), described

        in the following sections. 

     Gray                     Expires April, 2007              [Page 13]

     Internet-Draft           RBridge Architecture          October 2006

     3.2. RBridge Data Model 

        The following tables represent the logical model of the data 
        required by RBridges in forwarding unicast and multicast data 
        across a CRED. 

     3.2.1. CFT 

        The CFT is a forwarding table for unicast traffic within the 
        CRED, allowing tunneled traffic to transit the CRED from ingress

        to egress. The size of a fully populated CFT at each RBridge is 
        maximally bounded by the product of the number of directly 
        connected RBridge peers (where "directly connected" in this 
        context refers to RBridges connected to each other without 
        transiting one or more additional RBridges) and VLANs. RBridges 
        may have separate CFTs for each VLAN, if this is supported by 
        configuration. The CFT is continually maintained by RBridge 
        routing protocol (see Section 4.7). 

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

        The CFT contains data specific to RBridge forwarding for unicast

        traffic. The specific fields contained in this table are to be 
        defined in RBridge protocol specifications. In the abstract, 
        however, the table should contain forwarding direction and 
        encapsulation associated with an RBridge encapsulated frame 
        received - determined by the "shim" header destination and VLAN 
        (if applicable). 

     3.2.2. CFT-IRT 

        The CFT-IRT consists of a set of forwarding entries used for 
        support of Ingress RBridge Trees (IRT). CFT-IRT entries are 
        distinct from typical CFT entries because there may be zero or 
        more of them that match for any incoming frame.  

        The CFT-IRT may be part of the CFT, or instantiated as a 
        separate table, in implementations. 

        In discussing entries to be included in the CFT-IRT, the 
        following entities are temporarily defined, or further 
        qualified: 

        o  Ingress RBridge - the RBridge that is the head end of an IRT.

           All RBridges within a CRED are potential ingress RBridges. 

Sgai 28> IMO all RBridges must be ingress RBridges, at least to support
inband management, e.g. SNMP.

      
     Gray                     Expires April, 2007              [Page 14]

     Internet-Draft           RBridge Architecture          October 2006

        o  Egress RBridge - an RBridge that is the tail end of a path 
           corresponding to a specific CFT-IRT entry. All RBridges 
           within a CRED are potential egress RBridges. 

Sgai 29> same as above

Not all RBridges 
           within a CRED will be on the shortest path between any 
           ingress RBridge and any other egress RBridge. 

        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. 

Sgai 30> I think the previous definition is not needed.

        o  RBridge CRED Egress Interface - an interface on any RBridge 
           where a transit RBridge encapsulated frame would be 
           decapsulated prior to forwarding. With respect to such an 
           interface, the local RBridge is the egress RBridge. 

        Each local RBridge will maintain a set of entries for at least 
        the following - corresponding to a subset of all possible 
        forwarding paths: 

        o  Zero or more entries grouped for each ingress RBridge

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.

 - keyed 
           by the ingress RBridge identifier - used to determine 
           downstream forwarding of broadcast, multicast, and flooded 
           frames originally RBridge encapsulated by that ingress within

           the CRED. 

        o  Corresponding to each of these entry groups, one entry for 
           each of zero or more egress RBridge - where the local RBridge

           is on the shortest path toward that egress RBridge. 

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.

        o  Corresponding to each of these entry groups, one entry for 
           each of zero or more CRED egress interfaces. 

        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.  

Sgai 33> I don't get the pair.

Entries would also 
        contain any required encapsulation information, etc. required 
        for forwarding on a given interface, and toward a corresponding 
        specific egress RBridge. 

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.

        A local RBridge could maintain a full set of entries from every 
        RBridge to every other RBridge, however - depending on topology 
        - only a subset of these entries would ever be used.  In 
        addition, a topology change that changed selection of shortest 
        paths would also very likely change other elements of the 
        entries, negating possible benefits from having pre-computed 
        CFT-IRT entries. 

     Gray                     Expires April, 2007              [Page 15]

     Internet-Draft           RBridge Architecture          October 2006

        CFT-IRT entries should also include VLAN identification 
        information relative to each set of ingress RBridge, to allow 
        scoping of broadcast, multicast and flooding forwarding by 
        configured VLANs. 

        CFT-IRT entries should also include Multicast-Group Address 
        specific information relative to each egress RBridge that is a 
        member of a given well-known multicast group, to allow scoping 
        of multicast forwarding by multicast group. 

        Implicit in this data model is the assumption that the "shim" 
        header encapsulation will contain information that explicitly 
        identifies the CRED ingress RBridge for any broadcast, multicast

        or flooded frame. 

        How the CFT-IRT is maintained will be defined in appropriate 
        protocol specifications used to instantiate this architecture. 
        The protocol specification needs to include mechanisms and 
        procedures required to establish and maintain the CFT-IRT in 
        consideration of potential SPF recomputations resulting from 
        network topology changes.

Sgai 35> this protocol must be designed to avoid transient loops, since
transient loops of multicast/broadcast cause broadcast storm that are
highly undesirable.

     3.2.3. CTT 

        The CTT determines how arriving traffic will be encapsulated, 
        for forwarding to the egress RBridge, via the CRED. The CTT can 
        be considered a version of the LPT that treats the CRED, as a 
        whole, as another port. It becomes configured in much the same 
        way as the LPT: by snooping incoming traffic, and assuming bi-
        directional consistency.  The information is learned at the 
        egress RBridge and propagated to all other RBridges in the CRED 
        via the RBridge routing protocol. The CTT may be as large as the

        number of nodes on the Ethernet subnet, across all VLANs. 
        RBridges may have separate CTTs for each VLAN, if separate VLANs

        are supported by configuration. 

Sgai 36> see my previous comment about VLANs

        The CTT essentially determines the tunnel encapsulation used to 
        transport each specific frame across the CRED. 

     4. Functional Description 

        The RBridge Architecture is largely defined by RBridge behavior;

        the logical components are minimal, as outlined in Section 3.  

      
     Gray                     Expires April, 2007              [Page 16]

     Internet-Draft           RBridge Architecture          October 2006

     4.1. CRED Auto-configuration 

        Cooperating RBridges self-organize to compose a single CRED 
        system. Consider first a set of bridges on a single Ethernet 
        link subnet (Figure 1). Here bridges are shown as 'b', hubs as 
        'h', and nodes as 'N'; bridges and hubs are numbered. Note that 
        the figure does not distinguish between types of nodes, i.e., 
        hosts and routers; both are end nodes at the link layer, and are

        otherwise indistinguishable to L2 forwarding devices. Bridges in

        this topology organize into a single spanning tree, as shown by 
        double lines ('=', '||', and '//') in the figure. 

                                  N       N---b3---N             
                                  |           ||                        
                                  |           ||                     
                             N---h1--b4===b5==h2==b6  
                                     |   //   |   ||                
                                     |  //    N   ||                 
                                     | //         ||                    
                                 N---b7====b8-----b9-----N             
                                           |      |\                  
                                           |      | \                
                                           N      N  N               

              Figure 1 Conventionally bridged Ethernet link subnet 

        It is useful to note that hubs are relatively transparent to 
        bridges, both for traffic from nodes to bridges (h1) and for 
        traffic between bridges (h2). Also note that the same hub can 
        support traffic between bridges and from a host to a bridge 
        (h2), but that the spanning tree is exclusively between bridges.

        Bridges are thus compatible with hubs, both as transits and 
        ingress/egress. 

        A CRED operates similarly, and can be viewed as a variant of the

        way bridges self-organize. Figure 2 shows the same topology 
        where some of the bridges are replaced by RBridges (shown as 'r'

        in the figure). In this figure, stars ('*') represent the paths 
        the RBridge is capable of utilizing, due to the use of link 
        state routing. RBridges can tunnel directly to each other (r4-
        r5), or through hubs (h2) or bridges (b8). 

        Note that the former b8-b9 path, which is b8-r9 in Figure 2 and 
        had been disable by the hypothetical spanning tree in Figure 1,

sgai 37> disabled -> blocking.
 
        is now usable. 

      
     Gray                     Expires April, 2007              [Page 17]

     Internet-Draft           RBridge Architecture          October 2006

                                  N       N---b3---N             
                                  |           ||

                                  |           ||                      
                             N---h1--r4***r5**h2**r6  
                                     *   *    |   *                 
                                     *  *     N   *                  
                                     * *          *                     
                                 N---r7****b8*****r9-----N             
                                           |      |\                  
                                           |      | \                
                                           N      N  N               

                     Figure 2 RBridged Ethernet link subnet 

        Every node in a CRED is considered to have a primary point of 
        attachment to the CRED, as defined by the Designated RBridge. 
        Each Ethernet link segment attached to a CRED has a single 
        Designated RBridge; that RBridge is where all traffic that 
        transits the CRED enters and exits. In Figure 2, it is easy to 
        see that the nodes off of h1 must attach at r4; the nodes off of

        b3, however, attach at either r5 or r6, depending on which is 
        the Designated RBridge. 

        Without loss of generality, an RBridge topology can be 
        reorganized (ignoring link length) such that all nodes, hubs, 
        and bridges are arranged around the periphery, and all RBridges 
        are considered directly connected by their tunnels (Figure 3). 
        Note that this view ignores the ways in which hubs and bridges 
        may serve both on the ingress/egress and for transit, hence this

        view is not useful for traffic analysis. Using this view, it is 
        easy to distinguish between RBridge to RBridge traffic and other

        traffic on shared devices, such as h2 and b8, because RBridge to

        RBridge traffic content is hidden from non RBridge devices by 
        the RBridge encapsulation. 

      
     Gray                     Expires April, 2007              [Page 18]

     Internet-Draft           RBridge Architecture          October 2006

                                  N       N---b3---N             
                                  |           ||

                                  |           ||  
                                  |           h2 
                                  |          /| \ 
                                  |         / N  \ 
                                  |        /      \               
                             N---h1--r4***r5******r6  
                                     *   *        *                 
                                     *  *         *                  
                                     * *          *                     
                                 N---r7***********r9-----N             
                                      \          /|\                  
                                       \        / | \                
                                        \      /  N  N   
                                         \    / 
                                          \  / 
                                           b8   
                                           | 
                                           N 
         
               Figure 3 Reorganized RBridge Ethernet link subnet 

     4.2. RBridge Peer Discovery 

        Proper operation of the TRILL solution using RBridges depends on

        the existence of a mechanism for discovering peer RBridges and 
        the RBridge topology. An accurate determination of RBridge 
        topology is required in order to determine how traffic frames 
        will flow in the topology and thus avoid the establishment of 
        persistent loops in frame forwarding. 

Sgai 38> for multicast/broadcast we also need to avoid transient loops.

        The discovery mechanisms must use protocol messages which will 
        be propagated throughout a LAN (or broadcast domain) until they 
        are consumed by another RBridge.  This must happen in order to 
        ensure that RBridges in the same broadcast domain are discovered

        by their peers as required to allow for accurate determination 
        of RBridge topology. 

        These protocol messages should be distinguished in a manner that

        is consistent with the chosen RBridge routing protocol, or any 
        other discovery mechanism used. It is very likely that peer 
        discovery will actually be done as part of the RBridge routing 
        protocol's peer discovery; however this is to be determined by 
        specific RBridge protocol specification(s). 

      
     Gray                     Expires April, 2007              [Page 19]

     Internet-Draft           RBridge Architecture          October 2006

        An RBridge intercepts protocol messages that it recognizes as 
        being of this type (peer discovery), performs any processing 
        required and forwards these messages as required by the 
        discovery protocol. For example, a receiving RBridge may first 
        determine if it has seen this message before and insert itself 
        in a list of RBridges traversed by this message prior to 
        forwarding the message on at least all interfaces other than the

        one on which it was received. 

        Note that forwarding the modified message on all interfaces in 
        the example above is safe, if somewhat wasteful. 

        RBridges must forward all other protocol messages in a manner 
        consistent with L2 addressing and forwarding - as would be done 
        by a typical 802.1D bridge. This includes any frames of the same

        type that are - for one reason or another - not recognized by 
        the receiving RBridge. 

        It is necessary for RBridges to forward unrecognized RBridge 
        control frames in the same way as they would other broadcast, 
        multicast or unknown unicast (flooded) frames, in order to 
        minimize the potential for interoperability problems with: 

        o  future RBridge versions, using the same or similar control 
           frames 

        o  non-cooperating RBridge implementations - i.e. - RBridges 
           that may be configured with different security information.  

        Note that forwarding unrecognized messages - even when of the 
        same (RBridge control frame) type - has the effect of providing 
        some degree of robustness in the solution against configuration 
        errors and against future variations of the discovery protocol. 

        Handling of 802.1D BPDUs is as determined in section 4.8.  

     4.3. Tunneling 

        RBridges pass encapsulated frame traffic to each other 
        effectively using tunnels. These tunnels use an Ethernet link 
        layer header, together with a shim header. 

        Specifics of encapsulation are to be defined in appropriate 
        protocol/encapsulation specifications.  

        It is the combination of the encapsulation that distinguishes 
        RBridge to RBridge traffic from other traffic. The link header 

     Gray                     Expires April, 2007              [Page 20]

     Internet-Draft           RBridge Architecture          October 2006

        includes source and destination addresses, which typically 
        identify the ingress and egress RBridges. For incoming multicast

        and broadcast traffic, one of these addresses may represent the 
        multicast group or broadcast address. Additionally, these 
        addresses may be VLAN-specific, i.e., such that each ingress and

        egress address have per-VLAN addresses. 

        The additional shim header is required to support loop mediation

        for traffic within the CRED; traffic loops in forwarding between

        RBridges and non-RBridge nodes, as well as across non-RBridge 
        devices between RBridges, is limited by loop mediation and/or 
        prevention mechanisms that are beyond the scope of this document

        (but may include a TTL-like mechanism, mechanisms to establish a

        loop free topology - such as STP/RSP - or both) on the 
        applicable LAN segments.  

        The shim header and encapsulation: 

        o  must clearly identify the traffic as RBridge traffic - the 
           outer Ethernet header may, for instance, use an Ethertype 
           number unique to RBridges;  

        o  should also identify a specific (egress) RBridge - the shim 
           header may, for example, include an identifier unique to the 
           egress RBridge; 

        o  should include the RBridge transit route, a hopcount, or a 
           timestamp to prevent indefinite looping of a frame. 

     4.4. RBridge General Operation 

        Operations that apply to all RBridges include peer and topology 
        discovery (which may include negotiation of RBridge 
        identifiers), Designated RBridge election, link-state routing, 
        SPF computation and advertising reach-ability for specific L2 
        (MAC Ethernet destination) addresses within a broadcast domain. 

        In addition, all RBridges will compute Ingress RBridge Trees for

        delivery of (potentially VLAN scoped) broadcast, multicast and 
        flooded frames to each peer RBridge. Setting up these trees 
        early is important as there is otherwise no means for frame 
        delivery across the CRED during the learning phase. Because it 
        is very likely to be impossible (at an early stage) for RBridges

        to determine which RBridges are edge RBridges, it is preferable 
        that each RBridge compute these trees for all RBridges as early 
        as possible - even if some entries will not be used. 

     Gray                     Expires April, 2007              [Page 21]

     Internet-Draft           RBridge Architecture          October 2006

        The initial phase is the peer and topology discovery phase. This

        should continue for a sufficient amount of time to reduce the 
        amount of re-negotiation (Designated RBridge and - possibly - 
        identifiers) and re-computation that will be triggered by 
        discovery of new peers. The timer values selected for delaying 
        the next phase should take into account the time required for 
        local STP and availability of segment connectivity between 
        RBridge peers. 

Sgai 39> but RBridge discovery and STP are ongoing processes, why do we
want to couple their timers?

        The next phase is election of Designated RBridges for all shared

        access segments. This phase cannot complete before completion of

        peer and topology discovery. In parallel, RBridge routing 
        protocol should begin the process of building the link-state 
        information - assuming this was not done during the peer and 
        topology discovery phase. 

        At about this time, RBridges should establish ingress RBridge 
        trees.  

        Once RBridges have established Ingress RBridge Trees, the 
        learning and forwarding phase may begin. In this phase, RBridges

        initially forward frames by flooding them via Ingress RBridge 
        Tree(s). Also during this phase, RBridges begin "learning" MAC 
        address locations from local segments and propagating L2 reach-
        ability information via the RBridge routing protocol to all 
        other RBridges.  Gradually, the CFT will be built up for all 
        RBridges, and fewer frames will require flooding via the Ingress

        RBridge Tree(s).  

        The learning phase typically does not complete as new MAC 
        attachment information continues to be learned and old 
        information may be timed out and discarded. Consequently, the 
        learning phase is also the operational phase. During the 
        combined learning and operational phase, all RBridges maintain 
        both Ingress RBridge Trees and a CFT. RBridges not elected as 
        Designated RBridge may be required to become one in the event 
        that the DR goes off-line. 

     4.5. Ingress/Egress Operations 

        Operation specific to edge RBridges involves RBridge learning, 
        advertisement, encapsulation (at ingress RBridges) and 
        decapsulation (at egress RBridges). 

        As described elsewhere, RBridge learning is similar to typical 
        bridge learning - i.e. - all RBridges listen promiscuously to L2

      
     Gray                     Expires April, 2007              [Page 22]

     Internet-Draft           RBridge Architecture          October 2006

        Frames on a local LAN segment and acquire location information 
        associated with source MAC addresses in L2 frames they observe. 

        By convention, a Designated RBridge election always occurs. In 
        the degenerate case - where only one RBridge is connected to a 
        specific Ethernet segment - obviously that RBridge will "win" 
        the election and become the designated RBridge. 

        With this convention, only the Designated RBridge performs 
        RBridge learning for interface(s) connected to that segment. 

        As each RBridge learns segment-local MAC source addresses, it 
        creates an entry in its LPT that associates that MAC source 
        address with the interface on which it was learned.  

Sgai 40> there is also a requirement to time-out learnt information to
maintain the filtering databases.
 
        Periodically, 

Sgai 41> periodically or on demand

as determined by the RBridge routing protocol, 
        each RBridge advertises this learned information to its RBridge 
        peers. 

        These advertisements propagate to all edge RBridges (as 
        potentially scoped by associated VLAN information for each 
        advertisement). Each edge RBridge incorporates this information 
        in the form of a CFT entry.  

        RBridges also discover that they are an edge RBridge as a result

        of receiving un-encapsulated frames that require forwarding. If 
        an RBridge is the Designated RBridge for a segment, and it has 
        not previously learned that the MAC destination for a frame is 
        local (this will be the case - for instance - for the very first

        frame it observes), then the RBridge would be required to 
        forward (or flood) the frame via the CRED to all other RBridges 
        (potentially within a VLAN scope).  

        The RBridge in this case would flood the frame unless it has 
        already created a unicast CFT entry for the frame's MAC 
        destination address.  If it has a corresponding CFT, then it 
        would use that.  This RBridge would be an ingress RBridge with 
        respect to the frame being forwarded. 

        The encapsulation used by this ingress RBridge would be 
        determined by the CFT - if one exists -  or the CFT-equivalent 
        entry for the Ingress RBridge Tree. The encapsulation - as 
        discussed elsewhere - should include (in the shim header) 
        information to identify the egress RBridge (for example, the 
        RBridge identifier negotiated previously during the peer and 
        topology discovery phase). 

     Gray                     Expires April, 2007              [Page 23]

     Internet-Draft           RBridge Architecture          October 2006

        When the encapsulated frame arrives at egress RBridge(s), it is 
        decapsulated and forwarded via the egress interface(s) onto the 
        local segment. 

        Note that an egress RBridge will be the Designated RBridge on 
        the local segment accessed via its egress interface(s). If the 
        received frame does not correspond to a learned MAC destination 
        address at an egress interface, it will forward the frame on all

        interfaces for which it is either the designated - or only - 
        RBridge. If the received frame does correspond to a learned MAC 
        destination address at an egress interface, the RBridge will 
        forward the frame via that interface only. 

     4.6. Transit Forwarding Operations 

        There two models for transit forwarding within a CRED: unicast 
        frame forwarding for known destinations, and everything else.  
        The difference between the two is in how the encapsulation is 
        determined. Exactly one of these models will be selected - in 
        any instantiation of this architecture- for each of the 
        following forwarding modes: 

        o  Unicast frame forwarding 
        o  Forwarding of non-unicast frames 
           o  Broadcast frame forwarding 
           o  Multicast frame forwarding 
           o  Frame flooding 

     4.6.1. Unicast 

        In unicast forwarding, the shim header is specific to the egress

        RBridge and MAC destination in the outer Ethernet encapsulation 
        is specific to the next hop RBridge.  

        As the frame is prepared for transmission at each RBridge, the 
        next hop MAC destination information is determined at that local

        RBridge using a corresponding CFT entry based on the "shim" 
        header.  

     4.6.2. Broadcast, Multicast and Flooding 

        Ingress RBridge Trees are used for forwarding of broadcast, 
        multicast and unknown destination frames across the CRED. In a 
        simple implementation, it is possible to use the CFT-IRT entries

        for all frames of these types.  

      
     Gray                     Expires April, 2007              [Page 24]

     Internet-Draft           RBridge Architecture          October 2006

        However, this approach results in potentially extreme 
        inefficiencies in the multicast and unknown destination flooding

        cases. 

        As a consequence, instantiations of this architecture should 
        allow for local optimizations on a hop by hop basis. 

        Examples of such optimizations are included in the sections 
        below. 

     4.6.2.1. Broadcast 

        The path followed in transit forwarding of broadcast frames will

        have been established through actions initiated by each RBridge 
        (as any RBridge is eligible to subsequently become an ingress 
        RBridge) in the process of computing CFT-IRT entries. Each 
        RBridge assumes that it may be a transit as well as an ingress 
        and egress RBridge and will establish forwarding information 
        relative to itself and each of its peer RBridges, and stored in 
        the CFT-IRT. CFT-IRT entries are computed at each RBridge for 
        paths going toward all other RBridges - at least in cases where 
        the RBridge performing CFT-IRT computations is on the shortest 
        path.  

        Forwarding information is in two forms: transit encapsulation 
        information for interfaces over which the RBridge will forward a

        broadcast frame to one or more peer RBridges and a decapsulation

        indication for each interface over which the RBridge may egress 
        frames from the CRED. In each case, the CFT-IRT includes some 
        identification of the interface on which a frame is forwarded 
        toward any specific egress RBridge for frames received from any 
        specific ingress RBridge. 

        Note that an interface over which an RBridge may egress frames 
        is any interface for which the RBridge is a Designated RBridge. 
        RBridges must not wait to determine that one (or more) non-
        RBridge Ethernet nodes is present in an interface before 
        deciding to forward decapsulated broadcast frames on that 
        interface. 

        Forwarding information is selected for each broadcast frame 
        received by any RBridge (based on identifying the ingress 
        RBridge for the frame) for all corresponding CFT-IRT entries. 
        Each RBridge is thus required to replicate one RBridge 
        encapsulated broadcast frame for each interface that is 
        determined from CFT-IRT entries corresponding to the frame's 

     Gray                     Expires April, 2007              [Page 25]

     Internet-Draft           RBridge Architecture          October 2006

        ingress RBridge. This includes decapsulated broadcast frames for

        each interface for which it is the designated RBridge. 

        Note that frame replication and forwarding should be scoped by 
        VLAN if VLAN support is provided. Also note that a Designated 
        RBridge (DR) may be required to transmit a decapsulated frame on

        the interface on which it received the RBridge encapsulated 
        frame.  

        This approach for broadcast forwarding might be considered to 
        add complexity because replication occurs at all RBridges along 
        the ingress RBridge tree, potentially for both RBridge 
        encapsulated and decapsulated broadcast frames. However, the 
        replication process is similar to replication of broadcast 
        traffic in 802.1D bridges with the exception that additional 
        replication may be required at each interface for egress from 
        the CRED. 

        Note that the additional replication associated with CRED egress

        may be made to exactly conform to 802.1D bridge broadcast 
        replication in implementations that model a CRED egress as a 
        separate logical interface. 

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.

        Using this approach results in one and only one copy of the 
        broadcast frame being delivered to each egress RBridge. 

     4.6.2.2. Multicast 

        Multicast forwarding is reducible to broadcast forwarding in the

        simplest (default) case. However implementations may choose - 
        using mechanisms that are out of scope for this document - to 
        optimize multicast forwarding. In order for this to work 
        effectively, however, support for awareness of multicast 
        "interest" is required for all RBridges. 

        Without optimization, multicast frames are injected by the 
        ingress RBridge onto an IRT by - for instance - encapsulating 
        the frame with a MAC destination multicast address, and 
        forwarding it according to its local CFT-IRT. Again, without 
        optimization, each RBridge along the path toward all egress 
        RBridges will similarly forward the frame according to their 
        local CFT-IRT. 

        Using this approach results in one and only one copy of the 
        multicast frame being delivered to appropriate egress RBridges. 
        However, using this approach, multicast delivery is identical to

        broadcast delivery - hence very inefficient. 

     Gray                     Expires April, 2007              [Page 26]

     Internet-Draft           RBridge Architecture          October 2006

        In any optimization approach, RBridge encapsulated multicast 
        frames will use either a broadcast or a group MAC destination 
        address. In either case, the recognizably distinct destination 
        addressing allows a frame forwarding decision to be made at each

        RBridge hop. RBridges may thus be able to take advantage of 
        local knowledge of multicast distribution requirements to 
        eliminate the forwarding requirement on interfaces for which 
        there is no recipient interested in receiving frames associated 
        with any specific group address. 

        As stated earlier, in order for RBridges to be able to implement

        multicast optimization, distribution of learned multicast group 
        "interest" information must be provided - and propagated - by 
        all RBridges.  Mechanisms for learning and propagating multicast

        group participation by RBridges is out of scope in this document

        but may be defined in RBridge protocol specification(s). 

        Note that, because the multicast optimization would - in 
        principle - further scope and reduce broadcast traffic, two 
        things may be said: 

        o  It is not necessary that all implementations in a deployment 
           implement the optimization (though all must support the data 
           required to implement it in RBridge peers) in order for any 
           local multicast optimization (consistent with the above 
           description) to work; 
        o  Introduction of a multicast optimization will not result in 
           potential forwarding loops where broadcast forwarding would 
           not do so. 

        In the simplest case, the ingress RBridge for a given multicast 
        frame will re-use the MAC destination group address of a 
        received multicast frame.  However this may not be required as 
        it is possible that the mechanisms specified to support 
        multicast will require examination of the decapsulated MAC 
        destination group address at each RBridge that implements the 
        optimization. 

     4.6.2.3. Flooding 

        Flooding is similarly reducible to broadcast forwarding in the 
        simplest (default) case - with the exception that a frame being 
        flooded across the CRED is typically a unicast frame for which 
        no CFT exists at the ingress RBridge. This is not a minor 
        distinction, however, because it impacts the way that addressing

        may be used to accomplish flooding within the CRED. 

     Gray                     Expires April, 2007              [Page 27]

     Internet-Draft           RBridge Architecture          October 2006

        An ingress RBridge that does not have a CFT entry for a received

        frame MAC destination address, will inject the frame onto the 
        ingress RBridge Tree by - for instance - encapsulating the frame

        with a MAC destination broadcast address, and forwarding it 
        according to its local CFT-IRT. Without optimization, each 
        RBridge along the path toward all egress RBridges will similarly

        forward the frame according to their local CFT-IRT. 

        Using this approach results in one and only one copy of the 
        flooded frame being delivered to all egress RBridges. 

        However implementations may choose to optimize flooding. A 
        Flooding optimization will only work at any specific RBridge if 
        that RBridge re-evaluates the original (decapsulated) unicast 
        frame.  

        Any flooding optimization would operate similarly to the 
        multicast optimization described above, except that - instead of

        requiring local information about multicast distribution - each 
        RBridge implementing the optimization will need only to lookup 
        the MAC destination address of the original (decapsulated) frame

        in its local CFT. If an entry is found, the frame could then be 
        forwarded only if the specific RBridge is on the shortest path 
        between the originating ingress RBridge and the appropriate 
        egress RBridge.  This could be implemented - for example - as a 
        specialized CFT-IRT entry. 

        Note that, because the flooding optimization would - in 
        principle - further scope and reduce flooded traffic, two things

        may be said: 

        o  It is not necessary that all implementations in a deployment 
           support the optimization in order for any local flooding 
           optimization (consistent with the above description) to work 
           (hence such an optimization is optional);  
        o  Introduction of the flooding optimization will not result in 
           potential forwarding loops where flooded forwarding would not

           do so. 

        Because a forwarding decision can be made at each hop, it is 
        possible to terminate flooding early if a CFT for the original 
        MAC destination was in the process of being propagated when 
        flooding for the frame was started.  It is therefore possible to

        reduce the amount of flooding to some degree in this case.  

      
     Gray                     Expires April, 2007              [Page 28]

     Internet-Draft           RBridge Architecture          October 2006

     4.7. Routing Protocol Operation 

        The details of routing protocol operation can be determined once

        a specific routing protocol has been selected.  These details 
        would be defined in appropriate protocol specification(s). 

        Protocol specifications should identify means for determining 
        the content of the CFT, CFT-IRT and CTT.  

     4.8. Other Bridging and Ethernet Protocol Operations 

        In defining this architecture, several interaction models have 
        been considered for protocol interaction between RBridges and 
        other L2 forwarding devices - in particular, 802.1D bridges. 
        Whatever model we adopt for these interactions must allow for 
        the possibility of other types of L2 forwarding devices. Hence, 
        a minimal participation model is most likely to be successful 
        over the long term, assuming that RBridges are used in a L2 
        topology that would be functional if RBridges were replaced by 
        other types of L2 forwarding devices. 

        Toward this end, RBridges - and the CRED as a whole - could (in 
        theory) participate in Ethernet link protocols, notably the 
        spanning tree protocol (STP) on the ingress/egress links using 
        exactly one of the following interaction models: 

        o  Transparent Participation (Transparent-STP) 
        o  Active Participation (Participate-STP) 
        o  Blocking Participation (Block-STP) 

        Only one of these variants would be supported by an instance of 
        this architecture. All RBridges within a single CRED must use 
        the same model for interacting with non-RBridge protocols. 
        Furthermore, it is the explicit intent that only one of these 
        models is ultimately supported - at least as a default mode of 
        compliant implementations. 

        This architecture assumes RBridges block STP. 

Sgai 43> can we clarify that this means "drop BPDUs".

... snip ...

Content-class: urn:content-classes:message
Date: Sun, 29 Oct 2006 09:23:03 -0800
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] WG last call comments to: http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Status: RO
Content-Length: 15139

Comments inline marked "sgai n>"

-- Silvano

--------------------------------------------------------

... snip ...

1. Introduction 

   The current dominant approach to segregating network traffic relies
   on a hierarchical arrangement of bridges and routers.  Hierarchy is
   further extended - both within routing protocols (such as IS-IS and
   OSPF) and between routing protocols (for example, between IGPs and
   BGP).  At least part of the current network structure is based on a 
   determined trade-off between limitations of IP routing and similar 
   disadvantages of 802 bridging.

   Bridging Limitations

   For example, bridged networks consist of single broadcast/flooding
   domains.  Ethernet/802 encapsulation (on which bridging is based) 
   does not provide mechanisms for reducing the impact of looping data 
   traffic that may result from a transient change in network topology
   and the existence of multiple paths.

   The impact of looping traffic is far worse with flooded or broadcast 
   traffic as this results in exponentially increasing traffic load.  
   Consideration of the impacts of looping data lead to the use of 
   STP/RSTP to establish a connected - loop free - tree by disabling 
   forwarding on a subset of links that might create a loop.  This has
   also the effect of eliminating redundant paths.

   Because of the potential for severe impact from looping traffic, 
   many (if not most) current bridge implementations stop forwarding of 
   traffic frames following a topology change event and restart only 
   after STP/RSTP is complete.

Sgai 1> In STP there is no way of knowing when the convergence has been
achieved; a bridge does not know or care about the timers of other
bridges. The state machines on the ports are run independently. If you
refer to the Topology Change Notification Flag, its purpose is to reduce
the filtering database ageing time, not to signal if STP/RSTP is
complete.

   As a result, the process of eliminating potential loops in existing 
   bridging deployments:

     1) Results in inefficient use of inter-bridge connections 
        and
     2) Causes delays in forwarding traffic as a result of 
        changes in the network topology.

Sgai 2> 2) is not true in the RSTP case; as a matter of fact RSTP is the
fastest converging protocol available today. 

   The combined effect of broadcast/flooding traffic, and the use of 
   spanning trees for loop avoidance, sets practical limits on bridged 
   network size in the network hierarchy and results in inefficient 
   bandwidth use of inter-bridge connections. Inefficient inter-bridge 
   connection usage similarly limits the usefulness of bridging with 
   high-speed (and consequently high cost) interfaces.

Gray                      Expires March, 2007                 [Page 3]

Internet-Draft        TRILL Routing Requirements       September, 2006

   IP Routing Issues

   For IP routed networks, any link (or subnet) must have at least one 
   unique prefix. This means that a node that moves from one IP subnet

sgai 3> in the case of IP instead of "node" is better to speak of
"interface". It is the interface that has an address, not the node.
 
   to another must change its IP address. Also, nodes with multiple IP
   subnet attachments must have multiple IP addresses.  In IP routed
   networks, there are frequent trade-off considerations between using 
   smaller subnets (longer prefix length) to minimize wasted IP address 
   space (as a result of unused addresses in the fixed address range 
   defined by the prefix and length) and using larger subnets (shorter
   prefix length) to minimize the need for (changes in) configuration.

   In any case - with current IP routing technology - subnets must be 
   configured for each routed interface.

   Proposed Solution

   Using a hybrid of routing and bridging - an RBridge - we hope to
   gain the benefits of both technologies, in particular, gaining the
   bandwidth advantages of shortest path routing while retaning the
   simplified configuration associated with bridging.

1.1. Terminology

   The following terms are used in this document in the way that
   they are defined in "TRILL RBridge Architecture" [TARCH]:

     ARP (Address Resolution Protocol)
     Bridge Learning
     Broadcast Domain 
     Broadcast Traffic
     Cooperating RBridges
     Egress RBridge
     Ethernet
     Flooded Traffic
     Flooding
     Frame 
     IGP (Interior Gateway Protocol)
     Ingress RBridge
     Ingress RBridge Tree
     IS-IS (Intermediate System to Intermediate System)
     ND (Neighbor Discovery)
     OSPF (Open Shortest Path First)
     Packet 

Sgai 4> in the case of layer 2 networks is more appropriate to use the
term frame, instead of packet.

     RBridge
     SPF (Shortest Path First)
     STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree Protocol)
     TRILL (TRansport Interconnect over Lots of Links)
     Unknown Destination
     VLAN (Virtual Local Area Network)

Gray                      Expires March, 2007                 [Page 4]

Internet-Draft        TRILL Routing Requirements       September, 2006

1.2. Specific TRILL Goals

   (Near) Zero Configuration

   It is a TRILL requirement that it must be possible to deploy RBridges
   in at least a nominal set of potential deployment scenarios without a
   need to perform any configuration at each RBridge.  It is possible to
   meet this goal for a sub-set of all possible deployment scenarios by
   making realistic restrictions on deployment - such as restricting the
   deployment scenarios to exclude those involving a "trust model" that
   imposes a need for configuration of some form of "shared secret" or 
   other configuration required to restrict access to "trusted" devices.

   It is also conceivable that a minimal configuration may be required
   for deployment of an initial (set of) device(s) - with subsequently
   deployed devices deriving that configuration information during the
   process of - for example - peer discovery.  This would constitute a
   mechanism for "near zero configuration".

   Efficient Unicast Bandwidth Usage

   For unicast, non-flooded traffic, RBridges are intended to merge the
   efficient bandwidth use of IP routing with the simplicity of Ethernet
   (or 802.1) bridging for networks possibly larger - and with greater 
   forwarding capacity - than is the case with these networks presently.
 
   The approach that we will use in accomplishing this is based on the
   idea of extending (one or more) link state routing protocol(s) to
   include distribution of Ethernet/802 reachability information between
   RBridge instances.  

Sgai 5> "RBridge instances" is not defined.

In addition, there may be specific requirements
   imposed on the interactions between these extensions and the Spanning
   Tree Protocol (STP) and between RBridge instances and (potentially
   co-located) IP routing instances.

   Potentially More Efficient Multicast and Broadcast Usage

   There are clear advantages to incorporating mechanisms for improved
   efficiency in forwarding (layer 2) multicast frames and - possibly
   in reducing the amount of broadcast traffic as well.  To the extent
   that these efficiency improvements may be considered "optimizations"
   and may be defined orthogonally to the process of specifying basic
   RBridge functionality, the potential to include these optimizations
   is (highly) desirable, but not mandatory.

   Examples of this type of optimization include use of any intrinsic 
   multicast routing capabilities and optimizations of ARP/ND.

Gray                      Expires March, 2007                 [Page 5]

Internet-Draft        TRILL Routing Requirements       September, 2006

   Backward Compatibility

   RBridges must be fully compatible with current bridges, IPv4 and
   IPv6 routers and endnodes.  They should be invisible to current IP
   routers (just as bridges are), and like routers, they terminate a
   bridged spanning tree.  

Sgai 6> the concept of terminating a bridged spanning tree is to vague,
see also sgai 10.

Unlike Routers, RBridges do not terminate
   a broadcast domain.

2. General Requirements Potentially Affecting Routing

   Candidate IGP Routing protocols - IS-IS or OSPF - must be evaluated
   for compatibility with the above goals.

   For example, since IS-IS requires a unique System ID for each IS-IS
   instance (at least within a "scoped" deployment), a requirement for 
   "(near) zero configuration" implies a need for mechanisms that allow
   auto-configuration and/or negotiation of these (scoped) unique IDs.

   Similar requirement must apply for OSPF as well, if selected.

   In addition, forwarding of protocol messages must be compatible with
   (or reasonably adaptable to) use of forwarding at layer 2, or there
   must be a means for deriving suitable higher layer addresses for the
   purpose of protocol exchanges - without imposing the need to manually

   configure higher-layer addresses.

3. Link State Protocol Specific Requirements

   Assuming that link state routing protocols meet above requirements,
   running a link state protocol among RBridges is straightforward.  It 
   is the same as running a level 1 routing protocol in an area.  This 
   would be theoretically true for either IS-IS or OSPF, assuming that
   both of these meet the general requiremenst above. 

   From the perspective of simply extending existing routing protocols,
   IS-IS is a more appropriate choice than OSPF because it is easy in 
   IS-IS to define new TLVs for use in carrying a new information type.

   This document, however, does not mandate a specific link-state, IGP,
   routing protocol.  Instead, it sets forth the requirements that will
   apply to any link-state routing protocol that may be used.

   For implementations providing co-located Router/RBridge function,
   it is necessary to have mechanisms for distinguishing any protocol 
   interactions in Routing instances from protocol interactions in the
   co-located RBridge instance.  Specific mechanisms we will use are
   very likely to be determined by the Link State Routing Protocol that

Gray                      Expires March, 2007                 [Page 6]

Internet-Draft        TRILL Routing Requirements       September, 2006

   we select.  Potential distinguishing mechanisms include use of a new
   well-known Ethernet/802 multicast address, higher-layer protocol ID
   or other - routing protocol specific - approaches.

   The mechanism chosen should be consistent with the TRILL goals.  If, 
   for example, a routing protocol specific approach required use of a
   unique "area" identifier, the RBridge area identifier should be a 
   constant, well-known, value for all RBridges, and would not be one 
   that would ever appear as a real routing area identifer - in order 
   to allow for a potential for configuration-free operation. 

   Information that RBridge link state information will carry includes: 

   o  layer 2 addresses of nodes within the domain which have 
      transmitted frames but have not transmitted ARP or ND replies  

   o  layer 3, layer 2 addresses of IP nodes within the domain.  For 
      data compression, perhaps only the portion of the address 
      following the domain-wide prefix need be carried.  This will be 
      more of an issue for IPv6 than for IPv4. 

   o  VLANs directly connected to this RBridge 

Sgai 7> The discussion about VLAN needs to be much more extensive. It is
clear from the mailing list discussion that VLANs can be used inside the
packet or in the Ethernet encapsulation of TRILL. These are two
different kinds of VLANs and their requirement need to be stated
separately. Q in Q needs also to be discussed. I propose to define inner
and outer VLANs (with reference to the position of the tag in the frame.

   Endnode information need only be delivered to RBridges supporting
   the VLAN in which the endnode resides. 

Sgai 8> endnode -> station

So, for instance, if endnode
   E is discovered through a VLAN A frame, then E's location need only
   be delivered to other RBridges that are attached to VLAN A links. 

   Given that RBridges must support delivery only to links within a VLAN

   (for multicast or unknown frames marked with the VLAN's tag), this 
   mechanism can be used to advertise endnode information solely to the
   RBridges "within" a VLAN (i.e. - having connectivity or configuration
   that assoicates them with a VLAN). 

Although a separate instance of 
   the link state protocol could be run for this purpose, the topology 
   is so restricted (just a single broadcast domain), that it may be 
   preferable to define special case mechanisms whereby each DR 

sgai 9> DR? Designated RBridge???

   advertises attached endnodes, and receives explicit acknolegments
   from other RBridges. 

4. Potential Issues 

4.1. Interactions with Spanning Tree Forwarding and Bridge Learning 

   Spanning tree forwarding applies within parts of the RBridge domain,
   where two or more RBridges are connected by a link that includes
   multiple 802.1 bridges.

Gray                      Expires March, 2007                 [Page 7]

Internet-Draft        TRILL Routing Requirements       September, 2006

   In order to simplify the interactions between RBridges and bridges -
   in particular, relative to spanning tree forwarding - RBridges do not
   actively participate in spanning tree protocol with 802.1 bridges.

Sgai 10> "do not participate actively" can mean two different things:
1) they drop the BPDU
2) they propagate the BPDUs as regular multicast frames

can you clarify?

   Hence, from the Link State Routing protocol perspective, the protocol

   will be able to treat spanning tree links as indistinguishable from
   any other Ethernet/802.1 link, in the same way that routing protocols
   do today.

   However, support for multi-pathing is potentially problematic and is 
   assumed - in this document - to be a non-goal.  Multi-path forwarding
   has the potential to confound the bridge learning process.

Sgai 11> multi-pathing a non-goal? This seems to be in contradiction
with what said before. Is it because of the designated RBridge?

Sgai 12> the requirement for a designated RBridge is not really
discussed here. In particular there is no discussion of the property of
the election algorithm, which must avoid broadcast storms.

4.2. Computing Routes

   RBridges must calculate an L2 "route table" consisting of Next Hop 
   information for each known L2 unicast destination address within a 
   (possibly VLAN scoped) broadcast domain. This is computed using a
   routing protocol's SPF algorithm and based on destination layer 2
   address reachability advertisements.

Sgai 13> from the previous sentence it seems that we are computing the
topology among all the MAC addresses. What we really do is compute the
topology among RBridges and then tag it with reachable MAC addresses.
>From the SPF perspective, it is a much easier problem.

... snip ...

Content-class: urn:content-classes:message
Date: Sat, 28 Oct 2006 23:01:37 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Tentative agenda uploaded
Status: RO
Content-Length: 194

A tentative agenda for the San Diego TRILL meeting has been uploaded.
See the meeting materials page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
.

Thanks,
Donald

Date: Sat, 28 Oct 2006 19:02:45 -0700
From: Radia Perlman <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] A question on	http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Status: RO
Content-Length: 760

RBridges drop BPDUs.

Radia

Silvano Gai wrote:

> Eric,
>
> When you say:
>
>?   In order to simplify the interactions between RBridges and bridges -
>
>   in particular, relative to spanning tree forwarding - RBridges do not
>
>   actively participate in spanning tree protocol with 802.1 bridges. 
>
> ?
>
> Do you mean:
>
> 1) RBridges propagate BPDUs as normal multicast frames
>
> 2) RBridges drop BPDUs
>
> Also:
>
> On the same RBridge interface, can I connect other RBridges and also 
> hosts?
>
> Thank You
>
> -- Silvano
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Sat, 28 Oct 2006 18:07:00 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 1289

Gray, Eric wrote:
> Caitlin,
> 
> 	Have we moved into the realm of _requiring_ support for
> BCN in all RBridges?
> 
> 	We can assume the "core RBridge" is BCN capable if it
> has triggered a BCN event, but we cannot assume that the
> ingress is likewise BCN capable unless we're going to require
> BCN support in every RBridge.
> 

Consider the following scenario: Host A is 802.1au compliant
(it will respond to BCNs), and 802.1au capable Bridge C is
part of its path to the end destination D.

At this time if C generates a BCN to A, A will receive it
and adjust its sending rate in compliance with 802.1au,
without dropping frames.

If we place an 802.1au-ignorant RBridge B is injected
between A and C then congestion domain has to shrink,
and C has to act as an edge to the congestion domain.
C has no method of regulating the flow from A to D
other than dropping frames.

If RBridge B is nominally 802.1au compliant, but will
not act as a proxy to relay BCNs then it effectively
becomes the edge of the congestion domain. That means
that B must regulate the flow from A to D by dropping
frames.

The only way an RBridge can avoid impairing 802.1au
congestion avoidance is for it to fully proxy 802.1au
functionality when interacting with an 802.1au bridge
that is not an rbridge.

Content-class: urn:content-classes:message
Date: Sat, 28 Oct 2006 08:28:32 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 2890

Radia,

Today the largest layer 2 networks have 100,000 stations. This number is
still increasing and we may see 1 million stations. Using 256 port
switches, it requires 4,000 switches, to build a fat tree kind of
topology you need to multiply approximately by 2, so you are at 8,000.

16 bits works, but I am OK with the format proposed by Eric, i.e.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                Egress                 |  CoS  |       TTL     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|               Ingress                 |         Rerved        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

IF the reserved bits can be used by the outcome of the ongoing FTAG
discussion (I still don't like the alignment :-).

Can we assume that we have agreed on the Ingress RBridge address, focus
on the FTAG and try to close?

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Friday, October 27, 2006 11:21 AM
> To: Gray, Eric
> Cc: [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge address and BCN
> 
> Summary of below---asking how many RBridges anyone would ever expect
to
> need in a single campus.
> 
> Gray, Eric wrote:
> 
> >Radia,
> >
> >	I don't know where the idea that we only need a 2-byte
> >nick-name comes from.  When did we change from the idea of using
> >an MPLS (or MPLS-like) SHIM with 19 bits to represent specific
> >RBridges to using a completely different SHIM and only requiring
> >16-bits of RBridge identification?
> >
> The number 19-bits was chosen just because the MPLS label field was 20
> bits,
> and we were stealing one to indicate whether the field was "ingress"
or
> "egress".
> There was no science behind 19-bits other than it happened to be
there,
> and
> seemed uncontroversially way more than we'd actually need, so would
> clearly be big enough.
> 
> If we weren't using an MPLS-like header, then we can actually think
about
> what size field we'd need. We wouldn't want the nickname space to be
> too densely used, so 16 bits would support, say, 30,000 RBridges.
> 
> So the question is---how many RBridges would anyone need? Remember,
this
> is for
> your "LAN"---it's not intended to replace layer 3. What size bridged
> networks
> are people building today? More than 1000 bridges?
> 
> So if nobody is building anything more than 1000 bridges, say, then 16
> bits is
> safe. If 16 bits isn't safe, then sure, we can pick a different size
> field.
> 
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Sat, 28 Oct 2006 08:16:00 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Larry Kreeger \(kreeger\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 6764

Eric,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Gray, Eric
> Sent: Friday, October 27, 2006 3:20 PM
> To: Larry Kreeger (kreeger)
> Cc: [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> 
> Larry,
> 
> 	A slower look up may be okay for exception processing.

The BCN closed loop control algorithm requires timely replies done in
HW. We can ask BCN experts which is the amount of delay that can be
tolerate, but if I remember correctly the stability analysis, it was not
much.

-- Silvano

> 
> 	BCNs should be required far less often than frames are being
> forwarded.
> 
> 	Having a transit RBridge "look inside [at?] the inner MAC"
> is not what is effectively happening - as I understand it - when
> a "core RBridge" is generating a BCN.  BCN-capable core RBridges
> would presumably copy the header information from some subset of
> the frames on a minimally-congested link, strip the tunneling
> encapsulation and originate a new frame containing a Notification
> (BCN) message.
> 
> 	This must be a new frame, as opposed to a reflection of the
> original frame, so it is interesting that people assume this is a
> trivial operation in hardware in the first place.
> 
> 	Since the BCN-capable RBridge has to "flip" the MAC SA into
> a MAC DA in a BCN anyway, it MUST look at that part of the frame
> in every case before it can generate a BCN.
> 
> 	In effect, the frame is (partially) copied, the copied
> information is locally terminated and used to originate a new
> message.  This message would then be sent - presumably using
> the usual means for message origination - by encapsulating it
> in RBridge tunnel encapsulation and forwarding it to (at least)
> the ingress RBridge from which it was introduced.
> 
> 	That is not nearly as much of a confusion of layers as it
> is to 1) assume that the frame is munged in hardware and turned
> around and 2) normal processing of originated local messages is
> bypassed in an attempt to optimize BCN sending at the cost of
> including additional information in _every_ frame.
> 
> 	Oh, and, apparently I can blame you for trying... :-)
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Larry Kreeger (kreeger) [mailto:[email-masked]]
> --> Sent: Friday, October 27, 2006 5:26 PM
> --> To: Gray, Eric
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
> -->
> --> Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:
> -->
> --> > Larry,
> --> >
> --> > 	Separating these issues...
> --> >
> --> > -- [SNIP] --
> --> > -->
> --> > --> Please correct me if I incorrectly summarize the above.
> --> > -->
> --> > --> 1) Scaling the number of fowarding entries in the
> --> core is not a
> --> > --> problem that TRILL needs to solve.
> --> >
> --> > While this is a possible intrepretation, it is not an accurate
> --> > characterization of what I said.
> --> >
> --> > I'll try again, starting with what you have said.
> --> >
> --> > Scaling of the number of forwarding entries in the core is not a
> --> > problem that the TRILL working group has decided to solve.
> --> >
> --> > Hence, you might conclude that the TRILL working group
> --> has passively
> --> > decided that this is not a problem that TRILL needs to solve.
> --> >
> --> > One reason why this might be the case is that people
> --> could not decide
> --> > the "by how much" question.
> --> >
> --> > Never-the-less, an implicit requirement that the solution
> --> should not
> --> > prevent more scalable implementations, enables people who
> --> might not
> --> > be able to agree in public (as to what factor of increased
> --> > scalability should apply) to produce and deploy solutions
> --> that are in
> --> > fact more scalable, by at least some amount.
> --> >
> --> > --> 2) Link utilization is a problem and TRILL needs to
> --> be concerned
> --> > --> with it.
> --> >
> --> > Certainly.
> --> >
> --> > -->
> --> > --> If this is correct, it leads me to believe that you
> --> would advocate
> --> > --> for
> --> > --> 1) Remove the destination RBridge from the shim, and
> --> just lookup
> --> > the
> --> > --> destination MAC directly
> --> >
> --> > How do you arrive at this conclusion?  There are
> --> scenarios where this
> --> > might be done, but clearly the use of a smaller field for
> --> a look-up
> --> > is traditionally viewed as likely to be quicker.
> -->
> --> I appologize for trying to put words in you mouth, but I am
> --> trying to
> --> understand what you are arguing for...and after reading the above,
I
> --> still don't know.  Maybe it is because I am confusing what you are
> --> personally saying versus what you are echoing from others
> --> in the group.
> --> Do you believe we need the RBridge Id in the shim or not?
> --> If you do,
> --> then why?  For a quicker lookup?  If so, then why would a
> --> slower lookup
> --> to generate the source RBridge for BCN be acceptable?
> -->
> --> >
> --> > --> 2) Eliminate the need for the outer MAC header between two
> --> > RBridges
> --> > --> if the link is point to point (quite likely in my opinion).
> --> >
> --> > Ultimately, point-to-point is very likely, but we have to
> --> deal with
> --> > the step-by-step deployment scenarios.
> --> >
> --> > In any case, I do not advocate special-casing
> --> encapsulation based on
> --> > link types in general - beyond that already required by
> --> the specific
> --> > link.  As I thought would be obvious by now, I advocate
functional
> --> > separation - which works better if you don't build in a
> --> lot of layer
> --> > dependencies.
> -->
> --> I agree with you about building in a lot of layer
> --> dependencies.  Having
> --> transit RBridges look inside the inner MAC seems like a
> --> layer dependency
> --> to me.  Not encapsulating with an extra 14 to 18 bytes on
> --> point to point
> --> link seems like it would be well worth it if you are
> --> concerned with link
> --> overhead.  I would gladly trade 14/18 bytes of overhead for
> --> another 2
> --> bytes of source RBridge which will help with BCN as well as
> --> help with
> --> network troubleshooting.
> -->
> --> >
> --> > -->
> --> > --> Again, I apologize for not keeping up with the latest
> --> discussions,
> --> > --> but have these ideas been discussed already?  If so, could
you
> --> > --> summarize the outcome?
> --> >
> --> > This is not a reasonable request.
> -->
> --> Oh well, cant' blame me for trying can you? ;-)
> -->
> --> >
> --> > -- [SNIP] --
> -->
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Sat, 28 Oct 2006 07:59:24 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
Status: RO
Content-Length: 4470

Per Eric request, this is the terminology changes I propose, to align
these documents with a layer two terminology:

Packet -> frame
In IEEE 802.1D the term packet means something at higher level (IP and
above)

Autolearning -> learning

Cache -> filtering database
The term filtering database is consistently used to indicate that a hit
on the database limit the frame propagation, while a miss causes
flooding (this is a different behavior from a forwarding database, where
a miss causes a drop).

I am not sure about the term "Port autolearning" used in the draft, can
you clarify the meaning?

IEEE speaks about stations, this may be the most controversial change,
but we need to settle on a single term.
Node -> station
Endnode -> station
Host -> station

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 10:59 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] Last Call comment on:
http://www.ietf.org/internet-
> drafts/draft-ietf-trill-prob-01.txt
> 
> Silvano, et al,
> 
> 	 Please see below.
> 
> -- [SNIP] --
> --> I don't think it is acceptable to have temporary loop for
broadcast
> --> multicast, even if they are mitigated by TTL. An interlock
mechanism
> --> similar to ST must be used for multicast/broadcast.
> -->
> --> I ask for a strong requirement that says: "TRILL MUST avoid
> --> multicast/broadcast storms"
> 
> I completely agree with this and I have been assuming an "interlock"
> function would be applied - especially for non-unicast or unknown
> frames.
> 
> In retrospect, it is obvious that this should be explicitly spelled
> out.
> 
> -->
> --> Sgai 2> ST provides symmetrical forwarding, i.e. the path from A
to B
> is
> --> the reverse of the path from B to A. Is this a requirement for
TRILL?
> 
> I believe this has certainly been assumed in discussions, but it
> might not have been deemed necessary to explicitly include this
> as a "requirement" in the PA&S document.  It is a behavior that
> applies to existing 802.1D bridges and we are required to be
> compatible with 802.1D bridges.
> 
> -->
> --> Sgai 3> the terminology used in this draft is not the one used in
IEEE
> --> standards. This makes it difficult to understand what certain
> sentences
> --> really mean. Concepts like autolearning and caches are not IEEE
> concepts.
> 
> This observation has been made before.  Can you make specific
> proposals for textual changes (replace "XYZ" with "LMNOP")?
> 
> -->
> --> Sgai 4> There is no mention of the applicability of other
important
> IEEE
> --> standards/WG/Study Groups, e.g.
> --> - 802.3ad-2000, Link Aggregation.
> --> - 802.1ah - Provider Backbone Bridges
> --> - 802.1aq - Shortest Path Bridging
> --> - 802.1au - Congestion Notification
> --> - 802.1ad - Provider Bridges
> --> - 802.1AE - MAC Security
> --> - 802.3ar - Congestion Management Task Force.
> --> - 802.3as - Frame Expansion Task Force.
> --> I think this document needs to clearly state the position of the
WG
> with
> --> respect to these projects.
> -->
> --> Sgai 5> I also think there need to be a mention of the
applicability
> of
> --> important industrial efforts:
> --> - NIC Teaming
> --> - uplinkfast
> --> - split-MLT
> --> - Q in Q
> --> All these are widely deployed in all datacenters/enterprises. I
think
> --> this document needs to clearly state the position of the WG with
> respect
> --> to these de fact standards.
> 
> Why?  Is it not sufficient to say that the solution must be compatible
> with existing technologies without listing them all?
> 
> -->
> --> Sgai 6> Many customers look at TRILL as a backbone network. They
would
> --> like to connect their current switches to the TRILL backbone using
> --> Etherchannel  and connecting the member links on different
RBridges
> for
> --> High availability. Is this a requirement? In general which is the
> --> relation between Etherchannel and TRILL?
> 
> These are good questions, touching on at least one of the issues that
> has been brought up previously (the "wiring closet problem").
> 
> I am not sure that the WG has reached consensus on this.  At present,
> there appears to be a distinct "lean" toward simply listing the set
> of existing deployment scenarios that may not be directly supported
> using RBridges in a partial-deployment scenario.
> 
> -->
> --> Sgai 7> Does TRILL work properly if Ethernet is deployed with
Pause
> --> enabled?
> -- [SNIP] --

Content-class: urn:content-classes:message
Date: Sat, 28 Oct 2006 07:47:12 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] A question on http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt
Status: RO
Content-Length: 6289

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6FA9F.F565C6E6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

Eric,

=20

When you say:

"   In order to simplify the interactions between RBridges and bridges -
   in particular, relative to spanning tree forwarding - RBridges do not
   actively participate in spanning tree protocol with 802.1 bridges.=20

"

=20

Do you mean:

1)       RBridges propagate BPDUs as normal multicast frames

2)       RBridges drop BPDUs=20

=20

Also:

On the same RBridge interface, can I connect other RBridges and also
hosts?

=20

Thank You

=20

-- Silvano

------_=_NextPart_001_01C6FA9F.F565C6E6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1491677437;
	mso-list-type:hybrid;
	mso-list-template-ids:-682869432 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0pt;}
ul
	{margin-bottom:0pt;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Eric,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>When you say:<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&#8220;</span></font>&nbsp;&=
nbsp; In order to simplify the interactions between RBridges and bridges =
-<o:p></o:p></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; in particular, relative to =
spanning tree forwarding - RBridges do =
not<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; actively participate in spanning =
tree protocol with 802.1 bridges. <o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&#8220;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Do you mean:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>RBridges
propagate BPDUs as normal multicast frames<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>RBridges drop
BPDUs <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Also:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>On the same RBridge interface, can I connect other =
RBridges and
also hosts?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thank You<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-- Silvano<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6FA9F.F565C6E6--

Date: Fri, 27 Oct 2006 19:42:57 -0700
From: "Alia Atlas" <[email-masked]>
To: "Sanjay Sane (sanjays)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] How many trees, and per what
Status: RO
Content-Length: 1381

Sanjay,

On 10/27/06, Sanjay Sane (sanjays) <[email-masked]> wrote:
> Also, instead of adding F-tag "values" to the context of the Rbridge-id,
> why not treat "F-tag" as the Forwarding topology identifier. (quote from
> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
> --> "The Forwarding Tag (FTag) identifies the forwarding topology
> assigned to a given frame").
>
> In the tree usage case (unknowns/multicast/broadcast), it's the tree
> identifier. If flood/unknown packets are best sent using ingress-rbridge
> tree, use the F-tag of the tree rooted at that ingress rbridge. If
> multicast packets are best sent using shared-multicast trees, use the
> F-tag of the (load-balanced) shared tree.
>
> Again, which tree/topology the packet is to be put onto, is the decision
> made at the source/ingress rbridge. But once the tree is chosen, and the
> F-tag is put on the packet, other rbridges honor the F-tag and forward
> accordingly.

Why have a separate additional field for this purpose?  The only
meaning of the ingress rbridge nickname in the shim header is, I
believe, to indicate the intended multicast tree.   Could the shared
multicast trees be given a nickname from the same space?  This would
avoid the need for the additional overhead and change in the header.
Are there scalability considerations that would make this a problem?

Alia

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 17:41:13 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Russ White" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] How many trees, and per what
Status: RO
Content-Length: 2457

Russ, Radia, et. al.

Having a per-ingress rbridge tree, and using it for multicast delivery
has many issues
-- no scope for multicast multi-pathing/load-balancing
-- for an IP multicast that is only going to links with registered
receivers, we now need to build a state with 
# of ingress rbridges * # of groups. This is heavy on computation &
memory. 

Using shared multicast trees for multicast delivery avoids both above,
and the forwarding state is # of shared trees * # of groups. 

Also, instead of adding F-tag "values" to the context of the Rbridge-id,
why not treat "F-tag" as the Forwarding topology identifier. (quote from
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
--> "The Forwarding Tag (FTag) identifies the forwarding topology
assigned to a given frame"). 

In the tree usage case (unknowns/multicast/broadcast), it's the tree
identifier. If flood/unknown packets are best sent using ingress-rbridge
tree, use the F-tag of the tree rooted at that ingress rbridge. If
multicast packets are best sent using shared-multicast trees, use the
F-tag of the (load-balanced) shared tree. 

Again, which tree/topology the packet is to be put onto, is the decision
made at the source/ingress rbridge. But once the tree is chosen, and the
F-tag is put on the packet, other rbridges honor the F-tag and forward
accordingly.  

-Sanjay

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 3:02 PM
To: [email-masked]
Cc: Sanjay Sane (sanjays); [email-masked]
Subject: Re: [rbridge] How many trees, and per what

> So the question is whether we should multiply the number of trees by 
> the number of F-tag values. And if so, how many F-tag values are
really needed.

I seem to be lost in the F-tag discussion, someplace.... Time warp,
anyone? :-)

My original impression was one tree per device per vlan throughout the
entire cloud, with some consideration for multicast still be taken in. I
don't really understand why we'd want one pre f-tag, maybe someone
should explain what we'd hope to gain through this?

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>, "Gray, Eric" <[email-masked]>
Date: Fri, 27 Oct 2006 20:03:38 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
Status: RO
Content-Length: 5009

Larry,

	There are other reasons for using a SHIM than RBridge e2e
tunneling.

	Interestingly enough, if we omitted the SHIM, we would be
using simple MAC-in-MAC encapsulation, and we might be able to
further abbreviate that by using tag-stacking.  But that's a
discussion for another forum...

--
Eric 

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 7:55 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 3:48 PM:
--> 
--> > Larry,
--> > 
--> > 	We are in synch on what I mean by "802.1X"
--> > 
--> > 	The issue was - you asked (paraphrasing) why use tunneling if
--> the
--> > RBridges themselves might have to retain all MAC reachability. 
--> > 
--> > 	I answered that this is useful if you have to deal with 802.1X
--> > bridges between RBridges. 
--> > 
--> > 	You replied that you thought that was done by (paraphrasing,
--> > again) using an "additional MAC header between the two RBridges."
--> > 
--> > 	To me this _might_ be a terminology issue if - for example - in
--> your
--> > lexicon, there is a difference between "using tunneling" and and
--> > using an "additional MAC header between the two RBridges."  
--> 
--> Yes, this is the disconnect.  I am assuming that the shim with the
--> egress RBridge that is carried from ingress RBridge to 
--> egress RBridge is
--> the tunnel.  I guess you are referring to the outer MAC 
--> which changes at
--> each hop as the tunnel (or a series of interconnected tunnels).  It
--> seems that if we don't care about scaling, we could remove 
--> the end to
--> end tunnel (dest RBridge), but still retain the additional 
--> MAC header
--> for transiting 802.1Q networks (although I'd like to remove 
--> it for point
--> to point links).
--> 
--> > In any
--> > other case, it must be the case that you are addressing some issue
--> > other than the one that is obviously intended for this thread.    
--> > 
--> > --> -----Original Message-----
--> > --> From: Larry Kreeger (kreeger) [mailto:[email-masked]]
--> > --> Sent: Friday, October 27, 2006 5:51 PM
--> > --> To: Gray, Eric
--> > --> Cc: [email-masked]
--> > --> Subject: RE: [rbridge] Ingress Rbridge address and 
--> BCN - 3rd Issue
--> > -->
--> > --> Gray, Eric wrote on Friday, October 27, 2006 11:52 AM:
--> > -->
--> > --> > -- [SNIP] --
--> > --> >
--> > --> > --> > 3rd Issue - why use tunneling if RBridges 
--> typically may be
--> > --> > --> > required to retain all MAC reachability information?
--> > --> > --> > ==========================================
--> > --> > --> >
--> > --> > --> > 	There are several reasons to do this, 
--> independent of any
--> > --> desire
--> > --> > --> > to reduce memory requirements of RBridges.
--> > --> > --> >
--> > --> > --> > 	One is that 802.1X bridges on 
--> intermediate links are
--> > --> shielded
--> > --> > --> > from exposure to MAC addresses on separate bridged LAN
--> > --> > segements.
--> > --> > -->
--> > --> > --> I thought that was accomplished by adding the 
--> additional MAC
--> > --> > header
--> > --> > --> between the two RBridges carrying their MACs.  The
--> > --> 802.1X bridges
--> > --> > --> connecting them will only learn these two RBridges
--> > --> MACs regardless
--> > --> > --> of whether there is a destination RBridge in the shim.
--> > --> >
--> > --> > Look, again, at the definition of the "3rd Issue" above.
--> > --> >
--> > --> > From you comment, it seems you missed that...
--> > -->
--> > --> Ok, I looked again, but I don't get it.  Maybe we have a
--> > terminology 
--> > --> mismatch.  When you say 802.1X I assume you mean 802.1D or
--> > 802.1Q. I 
--> > --> assume you are talking about the case where one of 
--> these bridges
--> > is 
--> > --> providing transport between two RBridges.  If we are 
--> in sync with
--> > --> that, then I am missing your point.
--> > -->
--> > --> > --> >
--> > --> > --> > 	Another is that the forwarding entries 
--> in RBridges are
--> > --> based on
--> > --> > --> > use of RBridge MAC addresses - which reduces 
--> the number of
--> > --> > entries
--> > --> > --> > that will typically be used for forwarding by an
--> > --> intermediate
--> > --> > RBridge.
--> > --> > -->
--> > --> > --> I'm missing the destinction between what you call the
--> > "memory 
--> > --> > requirements
--> > --> > --> RBridges", and "the number of entries that will
--> > --> typeically be used
--> > --> > --> for forwarding".  I was assuming these were the 
--> same thing.
--> > --> >
--> > --> > They are separable in a number of different ways.  Trying
--> > --> to state it
--> > --> > at a high level, it is certainly possible to optimize your
--> > look-up 
--> > --> > algorithms for a subset of frequently used entries.
--> > --> Caching comes to
--> > --> > mind, for example.
--> > --> >
--> > --> > -->
--> > -->
--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 20:00:18 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 2313

Larry,

	This may be a moot point.  Your observation is about a method
of implementation.  Logically, what you're doing is an isomorphism of
having a stubbed receiver/sender function where the receiver strips
off the SHIM, passing information to the sender function and the 
sender function constructs a new frame, and adds a new SHIM.  Where 
the difference comes up is in how the information is derived for the 
new SHIM - is it a function of having been provided in the original 
SHIM, or is it a look-up function (as would typically be the case in 
originating a new frame).

	If it is provided in the original SHIM, and there is no reason
to believe a look-up function would provide different information, 
then it is naturally a reasonable optimization to use the provided
information.  What's in question is whether or not it is worth this
optimization to always include the information in the original SHIM.

	Note that - if, for any reason, it is possible that a properly
performed look-up might result in a different SHIM entry - then a
look-up MUST be performed.  Currently, I know of only one reason why
this might be the case - if the topology changed immediately after
receiving the triggering frame - and I cannot say exactly how likely
this is to occur.  I imagine it is very unlikely, and the consequences
of ignoring the change in the rare case where such a change occurs
would be no more pathological than if a change were slightly delayed
for some other reason.

	Where it might be a problem is if another frame were being
originated by a "natural" process (such as responding to management
activity) to the same destination, the look-up for that frame led
to the use of a different egress RBridge and the frames were sent
in a peculiarly pathological order - leading to confusion of 802.1
bridges in the local LAN segment.

	Also, it is conceivable that there might be other cases...

-- [SNIP] --

--> 
--> > and 2) normal processing of originated local messages is bypassed in
--> > an attempt to optimize BCN sending at the cost of including additional
--> > information in _every_ frame.    
--> 
--> Here I disagree.  Since the BCN is a new frame built using info from the
--> sampled frame, I see no problem in building the shim based on the info
--> in the sampled shim.

-- [SNIP] --

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 16:54:52 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
Status: RO
Content-Length: 3947

Gray, Eric wrote on Friday, October 27, 2006 3:48 PM:

> Larry,
> 
> 	We are in synch on what I mean by "802.1X"
> 
> 	The issue was - you asked (paraphrasing) why use tunneling if
the
> RBridges themselves might have to retain all MAC reachability. 
> 
> 	I answered that this is useful if you have to deal with 802.1X
> bridges between RBridges. 
> 
> 	You replied that you thought that was done by (paraphrasing,
> again) using an "additional MAC header between the two RBridges."
> 
> 	To me this _might_ be a terminology issue if - for example - in
your
> lexicon, there is a difference between "using tunneling" and and
> using an "additional MAC header between the two RBridges."  

Yes, this is the disconnect.  I am assuming that the shim with the
egress RBridge that is carried from ingress RBridge to egress RBridge is
the tunnel.  I guess you are referring to the outer MAC which changes at
each hop as the tunnel (or a series of interconnected tunnels).  It
seems that if we don't care about scaling, we could remove the end to
end tunnel (dest RBridge), but still retain the additional MAC header
for transiting 802.1Q networks (although I'd like to remove it for point
to point links).

> In any
> other case, it must be the case that you are addressing some issue
> other than the one that is obviously intended for this thread.    
> 
> --> -----Original Message-----
> --> From: Larry Kreeger (kreeger) [mailto:[email-masked]]
> --> Sent: Friday, October 27, 2006 5:51 PM
> --> To: Gray, Eric
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
> -->
> --> Gray, Eric wrote on Friday, October 27, 2006 11:52 AM:
> -->
> --> > -- [SNIP] --
> --> >
> --> > --> > 3rd Issue - why use tunneling if RBridges typically may be
> --> > --> > required to retain all MAC reachability information?
> --> > --> > ==========================================
> --> > --> >
> --> > --> > 	There are several reasons to do this, independent of any
> --> desire
> --> > --> > to reduce memory requirements of RBridges.
> --> > --> >
> --> > --> > 	One is that 802.1X bridges on intermediate links are
> --> shielded
> --> > --> > from exposure to MAC addresses on separate bridged LAN
> --> > segements.
> --> > -->
> --> > --> I thought that was accomplished by adding the additional MAC
> --> > header
> --> > --> between the two RBridges carrying their MACs.  The
> --> 802.1X bridges
> --> > --> connecting them will only learn these two RBridges
> --> MACs regardless
> --> > --> of whether there is a destination RBridge in the shim.
> --> >
> --> > Look, again, at the definition of the "3rd Issue" above.
> --> >
> --> > From you comment, it seems you missed that...
> -->
> --> Ok, I looked again, but I don't get it.  Maybe we have a
> terminology 
> --> mismatch.  When you say 802.1X I assume you mean 802.1D or
> 802.1Q. I 
> --> assume you are talking about the case where one of these bridges
> is 
> --> providing transport between two RBridges.  If we are in sync with
> --> that, then I am missing your point.
> -->
> --> > --> >
> --> > --> > 	Another is that the forwarding entries in RBridges are
> --> based on
> --> > --> > use of RBridge MAC addresses - which reduces the number of
> --> > entries
> --> > --> > that will typically be used for forwarding by an
> --> intermediate
> --> > RBridge.
> --> > -->
> --> > --> I'm missing the destinction between what you call the
> "memory 
> --> > requirements
> --> > --> RBridges", and "the number of entries that will
> --> typeically be used
> --> > --> for forwarding".  I was assuming these were the same thing.
> --> >
> --> > They are separable in a number of different ways.  Trying
> --> to state it
> --> > at a high level, it is certainly possible to optimize your
> look-up 
> --> > algorithms for a subset of frequently used entries.
> --> Caching comes to
> --> > mind, for example.
> --> >
> --> > -->
> -->

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 16:38:58 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 2203

Gray, Eric wrote on Friday, October 27, 2006 3:20 PM:

> Larry,
> 
> 	A slower look up may be okay for exception processing.

It depends on how much slower.  Low latency of BCN is very important to
the stability of the feedback loop.

> 
> 	BCNs should be required far less often than frames are being
> forwarded. 

Agreed.

> 	Having a transit RBridge "look inside [at?] the inner MAC"
> is not what is effectively happening - as I understand it - when a
> "core RBridge" is generating a BCN.  BCN-capable core RBridges would
> presumably copy the header information from some subset of the frames
> on a minimally-congested link, strip the tunneling encapsulation and
> originate a new frame containing a Notification (BCN) message.   
> 
> 	This must be a new frame, as opposed to a reflection of the
original
> frame, so it is interesting that people assume this is a trivial
> operation in hardware in the first place.  
> 
> 	Since the BCN-capable RBridge has to "flip" the MAC SA into a
MAC DA
> in a BCN anyway, it MUST look at that part of the frame in every case
> before it can generate a BCN.

You are right, the RBridge would have to parse to inner SA to build the
BCN.

> 
> 	In effect, the frame is (partially) copied, the copied
information
> is locally terminated and used to originate a new message.  This
> message would then be sent - presumably using the usual means for
> message origination - by encapsulating it in RBridge tunnel
> encapsulation and forwarding it to (at least) the ingress RBridge
> from which it was introduced.     
> 
> 	That is not nearly as much of a confusion of layers as it is to
1)
> assume that the frame is munged in hardware and turned around 

Yep, it isn't a munged frame, it is a brand new frame built using info
from the sampled frame.

> and 2) normal processing of originated local messages is bypassed in
an
> attempt to optimize BCN sending at the cost of including additional
> information in _every_ frame.    

Here I disagree.  Since the BCN is a new frame built using info from the
sampled frame, I see no problem in building the shim based on the info
in the sampled shim.

> 
> 	Oh, and, apparently I can blame you for trying... :-)

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 19:34:13 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 1101

Larry,  

	This is an area in which it is possible for reasonable people 
to disagree.  I'm not absolutely sure I do, but I lean toward doing
so.

	The reason why I lean toward disagreeing with your statement
below is that a "core bridge" would certainly be expected to "need 
to populate a MAC table just in case [it needs] to generate a BCN."
This would be true because - in strictly 802.1 networks - there is
no convenient delegate for this task.

	Since we are not trying to solve problems that are not solved 
for 802.1 LANs - except as specifically stated in the charter - we
are not necessarily going to excuse "core RBridges" from requirements 
that would apply to "core bridges" in 802.1X extensions.

--
Eric

-- [SNIP] --
--> 
--> I agree with you (I think).  Core RBridges should not need to populate a
--> MAC table just in case they need to generate a BCN.  Given that, we have
--> two choices.  Either flood the BCN (which I don't like at all), or add
--> the source RBridge so it can be simply copied to the destination RBridge
--> of the BCN (which I do like).
--> 
-->  - Larry
--> 

From: "Gray, Eric" <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Date: Fri, 27 Oct 2006 19:22:40 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 3092

Caitlin,

	Have we moved into the realm of _requiring_ support for BCN
in all RBridges?

	We can assume the "core RBridge" is BCN capable if it has
triggered a BCN event, but we cannot assume that the ingress is
likewise BCN capable unless we're going to require BCN support 
in every RBridge.

	Also, I cannot parse your last paragraph because I cannot 
identify who is doing what to whom.  See specifics below...

--
Eric 

--> -----Original Message-----
--> From: Caitlin Bestler [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 6:57 PM
--> To: Gray, Eric; Larry Kreeger (kreeger)
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
--> 
--> Gray, Eric wrote:
--> > Caitlin,
--> > 
--> > 	At this point I have completely lost the thread of what
--> > you're talking about.  Are you assuming that it is okay for a
--> > "core Rbridge" to literally return the frame that triggers a
--> > BCN to the ingress RBridge that introduced it, and that this
--> > RBridge is then responsible for generating a BCN and acting as an
--> > egress for the BCN? 
--> > 
--> > 	As I understand it, that's asking an awful lot of the
--> > ingress RBridge.
--> 
--> But that functionality would clearly be required for an 802.1au
--> compliant RBridge, because it could receive a BCN from an
--> 802.1au [non-R]bridge.
--> 
--> Clearly it would be undesirable for the 802.1au rbridge to act
--> as the edge of the congestion domain -- it SHOULD (perhaps MUST)
--> forward the BCN to the true source. The rbridge itself is not
--> well suited to adjust the source in a dropless fashion.

Breaking this up, which 802.1au RBridge are you talking about as
acting as the "edge of the congestion domain"?

As I understand it, a BCN looks to most transit devices just like
any other frame that is addressed to someone else.  So which "it"
are you referring to in "it SHOULD (perhaps MUST) forward the BCN
to the true source"?

Which RBridge is not suited to "adjust the source in a dropless
fashion"?

In the model we are currently free to assume (assuming I was not 
asleep when we all agreed that RBridges must ubiquitously support
BCN), the fact that a "core RBridge" has a BCN-triggering event,
indicates that it is a BCN-capable RBridge.  That is all we are
free to assume.  Hence, since it may be the _only_ BCN capable
RBridge, it MUST generate a BCN if there is one to be generated.

I do find the notion of creating a BCN and sending it back to 
the RBridge the BCN-triggering frame came from intriguing.  It
is possible (however unlikely) that the receiving RBridge is 
also a "core RBridge" - so this may be "pushing the bubble down
in one place only to have it pop up in another" - but it may be
demonstrable that this approach has a high probability of being
a "work saving" approach.  At the very least, it doubles the 
probability that a entry will be found for the BCN's destination
MAC address - either in the BCN-capable "core RBridge" or in its
neighboring victim (that may, or may not, be a "core RBridge" as
well).

--
Eric

--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>, Caitlin Bestler <[email-masked]>, "Gray, Eric" <[email-masked]>
Date: Fri, 27 Oct 2006 18:58:07 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 2740

Larry,

	It is not simply a case of flipping the SHIM, the MAC header
of the original (BCN triggering) frame has to be flipped as well -
i.e. the "core Rbridge" has to move the MAC SA of the original frame
to the MAC DA of the BCN, insert its own MAC as the MAC SA, insert
appropriate values in some other fields, and perform an required
"frame maintenance" activities that may be required (length, FCS, 
etc.).

	If all of that is done, then I agree with your contention
that having the ingress RBridge ID in the SHIM would help to get
the newly originated frame to the appropriate (now) egress RBridge.
This is a non-trivial "if."

--
Eric

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 6:06 PM
--> To: Caitlin Bestler; Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
--> 
--> 
--> Caitlin Bestler wrote on Friday, October 27, 2006 2:55 PM:
--> 
--> > Larry Kreeger, responding to Eric Gray, wrote:
--> >>> 
--> >>> 1) Flooding will only occur when a specific RBridge has 
--> removed (due
--> >>> to aging, for example), or failed to retain, an entry it
--> >>> subsequently needs. This kind of flooding could occur 
--> in any case
--> >>> (although it might involve a smaller subset of the 
--> entire network).
--> >> 
--> >> I understand that this will occur when an edge RBridge 
--> does not have
--> >> an entry, but I assume that this will be a fairly rare condition.
--> >> Also, I am expecting the number of flows through an edge 
--> RBridge to
--> >> be much less than throught a core RBridge, such that the 
--> number of
--> >> MAC addresses entries needed would be much less at an 
--> edge RBridge. 
--> >> If a core RBridge did not have a larger table, then it could get
--> >> easily filled which would require flooding of the BCNs much more
--> >> than would occur naturally at an edge RBridge.
--> >> 
--> > More fundamentally, the egress rbridge will in most case also
--> > encapsulate the reverse-bound frames, and so will have 
--> had a reason
--> > to note the mac->rbridge mapping in the first place. A 
--> "core rbridge"
--> > would not have forgotten the mapping, it would have never 
--> looked for
--> > it in the first place. Table size is irrelevant.   
--> 
--> Caitlin,
--> 
--> I agree with you (I think).  Core RBridges should not need 
--> to populate a
--> MAC table just in case they need to generate a BCN.  Given 
--> that, we have
--> two choices.  Either flood the BCN (which I don't like at 
--> all), or add
--> the source RBridge so it can be simply copied to the 
--> destination RBridge
--> of the BCN (which I do like).
--> 
-->  - Larry
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 15:56:55 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Larry Kreeger (kreeger)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 846

Gray, Eric wrote:
> Caitlin,
> 
> 	At this point I have completely lost the thread of what
> you're talking about.  Are you assuming that it is okay for a
> "core Rbridge" to literally return the frame that triggers a
> BCN to the ingress RBridge that introduced it, and that this
> RBridge is then responsible for generating a BCN and acting as an
> egress for the BCN? 
> 
> 	As I understand it, that's asking an awful lot of the
> ingress RBridge.

But that functionality would clearly be required for an 802.1au
compliant RBridge, because it could receive a BCN from an
802.1au [non-R]bridge.

Clearly it would be undesirable for the 802.1au rbridge to act
as the edge of the congestion domain -- it SHOULD (perhaps MUST)
forward the BCN to the true source. The rbridge itself is not
well suited to adjust the source in a dropless fashion.

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 15:53:19 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Larry Kreeger (kreeger)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 2163

[email-masked] wrote:
> Larry,
> 
> 	A slower look up may be okay for exception processing.
> 
> 	BCNs should be required far less often than frames are
> being forwarded.
> 
> 	Having a transit RBridge "look inside [at?] the inner MAC"
> is not what is effectively happening - as I understand it -
> when a "core RBridge" is generating a BCN.  BCN-capable core
> RBridges would presumably copy the header information from
> some subset of the frames on a minimally-congested link,
> strip the tunneling encapsulation and originate a new frame
> containing a Notification (BCN) message.
> 
> 	This must be a new frame, as opposed to a reflection of
> the original frame, so it is interesting that people assume
> this is a trivial operation in hardware in the first place.
> 
> 	Since the BCN-capable RBridge has to "flip" the MAC SA
> into a MAC DA in a BCN anyway, it MUST look at that part of
> the frame in every case before it can generate a BCN.
> 
> 	In effect, the frame is (partially) copied, the copied
> information is locally terminated and used to originate a new
> message.  This message would then be sent - presumably using
> the usual means for message origination - by encapsulating it
> in RBridge tunnel encapsulation and forwarding it to (at
> least) the ingress RBridge from which it was introduced.
> 

When the RBridge generating the BCN is a core rbridge, i.e.
neither the ingress or egress rbridge for the instigating
frame, it is highly likely that this will be the first
unencapsulated frame for this destination in some time.

Unless a special accomodation is made in the shim header
it will not know the ingress RBridge, only the *prior*
RBridge. While that will *probably* be the ingress RBridge
there is certainly no guarantee of that.

If you forward the BCN to the *prior* rbridge, and that
rbridge also has no idea where the ultimate destination
of the BCN is, it will ultimately be forced to do
rbridge encapsultion for an unknown destination, which
means that the BCN could end up being flooded.

This is obviously undesirable. The real debate is whether
this is a minor statistical nuisance or a major problem.

From: "Gray, Eric" <[email-masked]>
To: Caitlin Bestler <[email-masked]>, "Larry Kreeger (kreeger)" <[email-masked]>, "Gray, Eric" <[email-masked]>
Date: Fri, 27 Oct 2006 18:52:28 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 2007

Caitlin,

	At this point I have completely lost the thread of what 
you're talking about.  Are you assuming that it is okay for a
"core Rbridge" to literally return the frame that triggers a
BCN to the ingress RBridge that introduced it, and that this
RBridge is then responsible for generating a BCN and acting as
an egress for the BCN?

	As I understand it, that's asking an awful lot of the 
ingress RBridge.

--
Eric

--> -----Original Message-----
--> From: Caitlin Bestler [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 5:55 PM
--> To: Larry Kreeger (kreeger); Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
--> 
--> Larry Kreeger, responding to Eric Gray, wrote:
--> >> 
--> >> 1) Flooding will only occur when a specific RBridge has 
--> removed (due
--> >> to aging, for example), or failed to retain, an entry it
--> >> subsequently needs. This kind of flooding could occur in any case
--> >> (although it might involve a smaller subset of the 
--> entire network).
--> > 
--> > I understand that this will occur when an edge RBridge does
--> > not have an entry, but I assume that this will be a fairly
--> > rare condition.  Also, I am expecting the number of flows
--> > through an edge RBridge to be much less than throught a core
--> > RBridge, such that the number of MAC addresses entries needed
--> > would be much less at an edge RBridge.  If a core RBridge did
--> > not have a larger table, then it could get easily filled
--> > which would require flooding of the BCNs much more than would
--> > occur naturally at an edge RBridge.
--> > 
--> More fundamentally, the egress rbridge will in most case also
--> encapsulate the reverse-bound frames, and so will have had a 
--> reason to note the mac->rbridge mapping in the first place.
--> A "core rbridge" would not have forgotten the mapping, it would
--> have never looked for it in the first place. Table size is 
--> irrelevant.
--> 
--> 
--> 
--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 18:48:27 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
Status: RO
Content-Length: 3216

Larry,

	We are in synch on what I mean by "802.1X"

	The issue was - you asked (paraphrasing) why use tunneling if 
the RBridges themselves might have to retain all MAC reachability.

	I answered that this is useful if you have to deal with 802.1X
bridges between RBridges.

	You replied that you thought that was done by (paraphrasing,
again) using an "additional MAC header between the two RBridges."

	To me this _might_ be a terminology issue if - for example -
in your lexicon, there is a difference between "using tunneling" and
and using an "additional MAC header between the two RBridges."  In
any other case, it must be the case that you are addressing some 
issue other than the one that is obviously intended for this thread.

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 5:51 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 11:52 AM:
--> 
--> > -- [SNIP] --
--> > 
--> > --> > 3rd Issue - why use tunneling if RBridges typically may be
--> > --> > required to retain all MAC reachability information?
--> > --> > ==========================================
--> > --> >
--> > --> > 	There are several reasons to do this, independent of any
--> desire
--> > --> > to reduce memory requirements of RBridges.
--> > --> >
--> > --> > 	One is that 802.1X bridges on intermediate links are
--> shielded
--> > --> > from exposure to MAC addresses on separate bridged LAN
--> > segements. 
--> > -->
--> > --> I thought that was accomplished by adding the additional MAC
--> > header 
--> > --> between the two RBridges carrying their MACs.  The 
--> 802.1X bridges
--> > --> connecting them will only learn these two RBridges 
--> MACs regardless
--> > --> of whether there is a destination RBridge in the shim.
--> > 
--> > Look, again, at the definition of the "3rd Issue" above.
--> > 
--> > From you comment, it seems you missed that...
--> 
--> Ok, I looked again, but I don't get it.  Maybe we have a terminology
--> mismatch.  When you say 802.1X I assume you mean 802.1D or 802.1Q. I
--> assume you are talking about the case where one of these bridges is
--> providing transport between two RBridges.  If we are in 
--> sync with that,
--> then I am missing your point.
--> 
--> > --> >
--> > --> > 	Another is that the forwarding entries in RBridges are
--> based on
--> > --> > use of RBridge MAC addresses - which reduces the number of
--> > entries 
--> > --> > that will typically be used for forwarding by an 
--> intermediate
--> > RBridge. 
--> > -->
--> > --> I'm missing the destinction between what you call the "memory
--> > requirements
--> > --> RBridges", and "the number of entries that will 
--> typeically be used
--> > --> for forwarding".  I was assuming these were the same thing.
--> > 
--> > They are separable in a number of different ways.  Trying 
--> to state it
--> > at a high level, it is certainly possible to optimize your look-up
--> > algorithms for a subset of frequently used entries.  
--> Caching comes to
--> > mind, for example.   
--> > 
--> > -->
--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 18:39:26 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 6701

Larry,

	I am no more likely to have the time to fix everything that is
broken than I am to have the time to create summaries for people who
apprently don't have time to read.  :-)

	I am not criticizing the group that came up with the protocol,
I am criticizing the protocol as you described it.  Generating a lot
of traffic during congested conditions is a pathological behavior, in
almost every case. 

	I assume that - if the BCN approach is supposed to work at all
- that it actually starts sending BCN messages well before the links
involved are experiencing true congestion.  I would imagine that this
might be based on some well-known or configurable threshold.

	The reason why I assume that, is based on a previously stated
goal for BCN - loss-less congestion notification.  If you wait until 
you are actually experiencing congestion to send BCNs, then you are
sending BCNs _instead_ of traffic.  That will quickly result in more
BCNs and you're already well on the way to a "melt-down."  That hardly 
seems like a sane "loss-less congestion notification" strategy

	I also assume that BCNs are not sent for every frame when the
links approach a congested state (by whatever definition the protocol
uses for "congested state") because that leads to another type of bad
behavior - i.e. that experienced using TCP combined with certain
undesirable forms to packet discard.

	Consequently, at the level of microseconds of turn-around time,
BCN _should_ not depend on "instantaneous frame turn around" nor is
it likely that flooding frames for a relatively scarce event will be
that much more of a burden than simply sending them to the ingress.

	Since you can have a choice - either build in slightly more
memory so that you can retain information you need, or operate at a
slightly lower threshold of "relative congestion" - it seems to me
that BCN implementers can knob this one out without help from TRILL.

--
Eric 

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 5:43 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 11:46 AM:
--> 
--> > -- [SNIP] --
--> > 
--> > --> >
--> > --> > 2nd Issue - what is the importance of "optimizing" 
--> support for
--> > BCN? 
--> > --> >
--> > 
--> ================================================================== 
--> > --> >
--> > --> > 	BCN is likely to be important for a number of
--> applications that
--> > --> > we care about.  But is it important enough that we 
--> should design
--> > --> > an
--> > RBridge
--> > --> > solution that is optimized for it, or is it 
--> sufficient that our
--> > solution
--> > --> > is not significantly sub-optimal for these applications?
--> > --> >
--> > --> > 	As Radia has already pointed out, an RBridge that finds
--> itself
--> > --> > with a frame it must deliver, and no corresponding 
--> forwarding
--> > --> > entry, will forward that frame on the ingress RBridge tree
--> > --> > (corresponding to
--> > delivery
--> > --> > of unknown MAC destination "flooding").  This is 
--> sub-optimal,
--> > but 
--> > --> > the choice that leads to an RBridge finding it 
--> needs to do this
--> > in 
--> > --> > the BCN
--> > 
--> > --> > case is (as I've said before) entirely an 
--> implementation choice.
--> > --> > Presumably, the implementer may choose to discard even BCN
--> > related 
--> > --> > MAC
--> > 
--> > --> > reachability if - as a trade-off decision - they 
--> believe that
--> > conservative
--> > --> > retention of MAC reachability is desirable over 
--> optimal support
--> > of 
--> > BCN.
--> > --> >
--> > --> > 	I personally favor the idea of forwarding BCN
--> notifications on
--> > --> > the Ingress RBridge Tree - for those 
--> implementations that do not
--> > --> > keep the appropriate MAC reachability information.  I favor
--> > this because: 
--> > --> >
--> > --> > 	1) it is consistent with how bridges work now, therefore
--> it is
--> > --> > 	not a departure from "the devil we know,"
--> > -->
--> > --> Last time looked at the BCN proposal, there could be 
--> a significant
--> > amount
--> > --> of BCN traffic during congestion.  Flooding this 
--> traffic to ALL
--> > --> RBridges
--> > 
--> > --> seems like a bad idea if you are concerned with link 
--> utilization.
--> > 
--> > A couple of separable points -
--> > 
--> > 1) Flooding will only occur when a specific RBridge has 
--> removed (due
--> > to aging, for example), or failed to retain, an entry it 
--> subsequently
--> > needs.  
--> > This kind of flooding could occur in any case (although it might
--> > involve a smaller subset of the entire network). 
--> 
--> I understand that this will occur when an edge RBridge does 
--> not have an
--> entry, but I assume that this will be a fairly rare 
--> condition.  Also, I
--> am expecting the number of flows through an edge RBridge to 
--> be much less
--> than throught a core RBridge, such that the number of MAC addresses
--> entries needed would be much less at an edge RBridge.  If a 
--> core RBridge
--> did not have a larger table, then it could get easily 
--> filled which would
--> require flooding of the BCNs much more than would occur 
--> naturally at an
--> edge RBridge.
--> 
--> > 
--> > 2) If, as you say, "there could be a significant amount of BCN
--> > traffic during congestion", then BCN suffers from fatal 
--> design flaws.
--> > If the need to occasionally flood BCN notifications contributes to
--> > this flaw, that is an issue (certainly), but it is one 
--> that is likely
--> > to be fixed at the same time as the current fatal flaw in BCN is
--> > fixed.     
--> 
--> I don't think it is fair to criticize the 802.1au group 
--> unless you have
--> better suggestions.  I suggest you contribute to that group 
--> if you feel
--> it is fatally broken.  In the meantime, RBridges should not 
--> compound the
--> problem.
--> 
--> > 
--> > -->
--> > --> >
--> > --> > 	2) it affects only implementations that are designed to
--> discard
--> > --> > 	potentially useful information in favor of reduced
--> memory needs
--> > --> > 	and
--> > --> >
--> > --> > 	3) it is a generic solution related to Caitlin's earlier
--> > remarks 
--> > --> > 	with respect to the relative numbers of "core RBridges"
--> and the
--> > --> > 	likelihood that next-hop RBridges on the Ingress RBridge
--> Tree
--> > are 
--> > --> > 	actually going to have an entry for the "unknown MAC
--> > destination" 
--> > --> > 	in the frame being flooded on the IRT.
--> > --> >
--> > 
--> > -- [SNIP] --
--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 18:20:26 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 5824

Larry,

	A slower look up may be okay for exception processing.

	BCNs should be required far less often than frames are being
forwarded.

	Having a transit RBridge "look inside [at?] the inner MAC"
is not what is effectively happening - as I understand it - when
a "core RBridge" is generating a BCN.  BCN-capable core RBridges
would presumably copy the header information from some subset of
the frames on a minimally-congested link, strip the tunneling 
encapsulation and originate a new frame containing a Notification
(BCN) message.

	This must be a new frame, as opposed to a reflection of the
original frame, so it is interesting that people assume this is a
trivial operation in hardware in the first place.

	Since the BCN-capable RBridge has to "flip" the MAC SA into
a MAC DA in a BCN anyway, it MUST look at that part of the frame
in every case before it can generate a BCN.  

	In effect, the frame is (partially) copied, the copied 
information is locally terminated and used to originate a new
message.  This message would then be sent - presumably using
the usual means for message origination - by encapsulating it
in RBridge tunnel encapsulation and forwarding it to (at least)
the ingress RBridge from which it was introduced.

	That is not nearly as much of a confusion of layers as it
is to 1) assume that the frame is munged in hardware and turned
around and 2) normal processing of originated local messages is 
bypassed in an attempt to optimize BCN sending at the cost of 
including additional information in _every_ frame.

	Oh, and, apparently I can blame you for trying... :-)

--
Eric

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 5:26 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 1st Issue
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:
--> 
--> > Larry,
--> > 
--> > 	Separating these issues...
--> > 
--> > -- [SNIP] --
--> > -->
--> > --> Please correct me if I incorrectly summarize the above.
--> > -->
--> > --> 1) Scaling the number of fowarding entries in the 
--> core is not a
--> > --> problem that TRILL needs to solve.
--> > 
--> > While this is a possible intrepretation, it is not an accurate
--> > characterization of what I said. 
--> > 
--> > I'll try again, starting with what you have said.
--> > 
--> > Scaling of the number of forwarding entries in the core is not a
--> > problem that the TRILL working group has decided to solve. 
--> > 
--> > Hence, you might conclude that the TRILL working group 
--> has passively
--> > decided that this is not a problem that TRILL needs to solve. 
--> > 
--> > One reason why this might be the case is that people 
--> could not decide
--> > the "by how much" question. 
--> > 
--> > Never-the-less, an implicit requirement that the solution 
--> should not
--> > prevent more scalable implementations, enables people who 
--> might not
--> > be able to agree in public (as to what factor of increased
--> > scalability should apply) to produce and deploy solutions 
--> that are in
--> > fact more scalable, by at least some amount.    
--> > 
--> > --> 2) Link utilization is a problem and TRILL needs to 
--> be concerned
--> > --> with it.
--> > 
--> > Certainly.
--> > 
--> > -->
--> > --> If this is correct, it leads me to believe that you 
--> would advocate
--> > --> for
--> > --> 1) Remove the destination RBridge from the shim, and 
--> just lookup
--> > the 
--> > --> destination MAC directly
--> > 
--> > How do you arrive at this conclusion?  There are 
--> scenarios where this
--> > might be done, but clearly the use of a smaller field for 
--> a look-up
--> > is traditionally viewed as likely to be quicker.  
--> 
--> I appologize for trying to put words in you mouth, but I am 
--> trying to
--> understand what you are arguing for...and after reading the above, I
--> still don't know.  Maybe it is because I am confusing what you are
--> personally saying versus what you are echoing from others 
--> in the group.
--> Do you believe we need the RBridge Id in the shim or not?  
--> If you do,
--> then why?  For a quicker lookup?  If so, then why would a 
--> slower lookup
--> to generate the source RBridge for BCN be acceptable?
--> 
--> > 
--> > --> 2) Eliminate the need for the outer MAC header between two
--> > RBridges 
--> > --> if the link is point to point (quite likely in my opinion).
--> > 
--> > Ultimately, point-to-point is very likely, but we have to 
--> deal with
--> > the step-by-step deployment scenarios. 
--> > 
--> > In any case, I do not advocate special-casing 
--> encapsulation based on
--> > link types in general - beyond that already required by 
--> the specific
--> > link.  As I thought would be obvious by now, I advocate functional
--> > separation - which works better if you don't build in a 
--> lot of layer
--> > dependencies.
--> 
--> I agree with you about building in a lot of layer 
--> dependencies.  Having
--> transit RBridges look inside the inner MAC seems like a 
--> layer dependency
--> to me.  Not encapsulating with an extra 14 to 18 bytes on 
--> point to point
--> link seems like it would be well worth it if you are 
--> concerned with link
--> overhead.  I would gladly trade 14/18 bytes of overhead for 
--> another 2
--> bytes of source RBridge which will help with BCN as well as 
--> help with
--> network troubleshooting.
--> 
--> > 
--> > -->
--> > --> Again, I apologize for not keeping up with the latest 
--> discussions,
--> > --> but have these ideas been discussed already?  If so, could you
--> > --> summarize the outcome?
--> > 
--> > This is not a reasonable request.
--> 
--> Oh well, cant' blame me for trying can you? ;-)
--> 
--> > 
--> > -- [SNIP] --
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 15:06:14 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 1612

Caitlin Bestler wrote on Friday, October 27, 2006 2:55 PM:

> Larry Kreeger, responding to Eric Gray, wrote:
>>> 
>>> 1) Flooding will only occur when a specific RBridge has removed (due
>>> to aging, for example), or failed to retain, an entry it
>>> subsequently needs. This kind of flooding could occur in any case
>>> (although it might involve a smaller subset of the entire network).
>> 
>> I understand that this will occur when an edge RBridge does not have
>> an entry, but I assume that this will be a fairly rare condition.
>> Also, I am expecting the number of flows through an edge RBridge to
>> be much less than throught a core RBridge, such that the number of
>> MAC addresses entries needed would be much less at an edge RBridge. 
>> If a core RBridge did not have a larger table, then it could get
>> easily filled which would require flooding of the BCNs much more
>> than would occur naturally at an edge RBridge.
>> 
> More fundamentally, the egress rbridge will in most case also
> encapsulate the reverse-bound frames, and so will have had a reason
> to note the mac->rbridge mapping in the first place. A "core rbridge"
> would not have forgotten the mapping, it would have never looked for
> it in the first place. Table size is irrelevant.   

Caitlin,

I agree with you (I think).  Core RBridges should not need to populate a
MAC table just in case they need to generate a BCN.  Given that, we have
two choices.  Either flood the BCN (which I don't like at all), or add
the source RBridge so it can be simply copied to the destination RBridge
of the BCN (which I do like).

 - Larry

Date: Fri, 27 Oct 2006 18:02:03 -0400
From: Russ White <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] How many trees, and per what
Status: RO
Content-Length: 851

> So the question is whether we should multiply the number of trees by the number of F-tag values. And if so,
> how many F-tag values are really needed.

I seem to be lost in the F-tag discussion, someplace.... Time warp,
anyone? :-)

My original impression was one tree per device per vlan throughout the
entire cloud, with some consideration for multicast still be taken in. I
don't really understand why we'd want one pre f-tag, maybe someone
should explain what we'd hope to gain through this?

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 14:54:41 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 1188

Larry Kreeger, responding to Eric Gray, wrote:
>> 
>> 1) Flooding will only occur when a specific RBridge has removed (due
>> to aging, for example), or failed to retain, an entry it
>> subsequently needs. This kind of flooding could occur in any case
>> (although it might involve a smaller subset of the entire network).
> 
> I understand that this will occur when an edge RBridge does
> not have an entry, but I assume that this will be a fairly
> rare condition.  Also, I am expecting the number of flows
> through an edge RBridge to be much less than throught a core
> RBridge, such that the number of MAC addresses entries needed
> would be much less at an edge RBridge.  If a core RBridge did
> not have a larger table, then it could get easily filled
> which would require flooding of the BCNs much more than would
> occur naturally at an edge RBridge.
> 
More fundamentally, the egress rbridge will in most case also
encapsulate the reverse-bound frames, and so will have had a 
reason to note the mac->rbridge mapping in the first place.
A "core rbridge" would not have forgotten the mapping, it would
have never looked for it in the first place. Table size is irrelevant.

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 14:50:38 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
Status: RO
Content-Length: 1972

Gray, Eric wrote on Friday, October 27, 2006 11:52 AM:

> -- [SNIP] --
> 
> --> > 3rd Issue - why use tunneling if RBridges typically may be
> --> > required to retain all MAC reachability information?
> --> > ==========================================
> --> >
> --> > 	There are several reasons to do this, independent of any
desire
> --> > to reduce memory requirements of RBridges.
> --> >
> --> > 	One is that 802.1X bridges on intermediate links are
shielded
> --> > from exposure to MAC addresses on separate bridged LAN
> segements. 
> -->
> --> I thought that was accomplished by adding the additional MAC
> header 
> --> between the two RBridges carrying their MACs.  The 802.1X bridges
> --> connecting them will only learn these two RBridges MACs regardless
> --> of whether there is a destination RBridge in the shim.
> 
> Look, again, at the definition of the "3rd Issue" above.
> 
> From you comment, it seems you missed that...

Ok, I looked again, but I don't get it.  Maybe we have a terminology
mismatch.  When you say 802.1X I assume you mean 802.1D or 802.1Q. I
assume you are talking about the case where one of these bridges is
providing transport between two RBridges.  If we are in sync with that,
then I am missing your point.

> --> >
> --> > 	Another is that the forwarding entries in RBridges are
based on
> --> > use of RBridge MAC addresses - which reduces the number of
> entries 
> --> > that will typically be used for forwarding by an intermediate
> RBridge. 
> -->
> --> I'm missing the destinction between what you call the "memory
> requirements
> --> RBridges", and "the number of entries that will typeically be used
> --> for forwarding".  I was assuming these were the same thing.
> 
> They are separable in a number of different ways.  Trying to state it
> at a high level, it is certainly possible to optimize your look-up
> algorithms for a subset of frequently used entries.  Caching comes to
> mind, for example.   
> 
> -->

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 14:43:17 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 3929

Gray, Eric wrote on Friday, October 27, 2006 11:46 AM:

> -- [SNIP] --
> 
> --> >
> --> > 2nd Issue - what is the importance of "optimizing" support for
> BCN? 
> --> >
> ================================================================== 
> --> >
> --> > 	BCN is likely to be important for a number of
applications that
> --> > we care about.  But is it important enough that we should design
> --> > an
> RBridge
> --> > solution that is optimized for it, or is it sufficient that our
> solution
> --> > is not significantly sub-optimal for these applications?
> --> >
> --> > 	As Radia has already pointed out, an RBridge that finds
itself
> --> > with a frame it must deliver, and no corresponding forwarding
> --> > entry, will forward that frame on the ingress RBridge tree
> --> > (corresponding to
> delivery
> --> > of unknown MAC destination "flooding").  This is sub-optimal,
> but 
> --> > the choice that leads to an RBridge finding it needs to do this
> in 
> --> > the BCN
> 
> --> > case is (as I've said before) entirely an implementation choice.
> --> > Presumably, the implementer may choose to discard even BCN
> related 
> --> > MAC
> 
> --> > reachability if - as a trade-off decision - they believe that
> conservative
> --> > retention of MAC reachability is desirable over optimal support
> of 
> BCN.
> --> >
> --> > 	I personally favor the idea of forwarding BCN
notifications on
> --> > the Ingress RBridge Tree - for those implementations that do not
> --> > keep the appropriate MAC reachability information.  I favor
> this because: 
> --> >
> --> > 	1) it is consistent with how bridges work now, therefore
it is
> --> > 	not a departure from "the devil we know,"
> -->
> --> Last time looked at the BCN proposal, there could be a significant
> amount
> --> of BCN traffic during congestion.  Flooding this traffic to ALL
> --> RBridges
> 
> --> seems like a bad idea if you are concerned with link utilization.
> 
> A couple of separable points -
> 
> 1) Flooding will only occur when a specific RBridge has removed (due
> to aging, for example), or failed to retain, an entry it subsequently
> needs.  
> This kind of flooding could occur in any case (although it might
> involve a smaller subset of the entire network). 

I understand that this will occur when an edge RBridge does not have an
entry, but I assume that this will be a fairly rare condition.  Also, I
am expecting the number of flows through an edge RBridge to be much less
than throught a core RBridge, such that the number of MAC addresses
entries needed would be much less at an edge RBridge.  If a core RBridge
did not have a larger table, then it could get easily filled which would
require flooding of the BCNs much more than would occur naturally at an
edge RBridge.

> 
> 2) If, as you say, "there could be a significant amount of BCN
> traffic during congestion", then BCN suffers from fatal design flaws.
> If the need to occasionally flood BCN notifications contributes to
> this flaw, that is an issue (certainly), but it is one that is likely
> to be fixed at the same time as the current fatal flaw in BCN is
> fixed.     

I don't think it is fair to criticize the 802.1au group unless you have
better suggestions.  I suggest you contribute to that group if you feel
it is fatally broken.  In the meantime, RBridges should not compound the
problem.

> 
> -->
> --> >
> --> > 	2) it affects only implementations that are designed to
discard
> --> > 	potentially useful information in favor of reduced
memory needs
> --> > 	and
> --> >
> --> > 	3) it is a generic solution related to Caitlin's earlier
> remarks 
> --> > 	with respect to the relative numbers of "core RBridges"
and the
> --> > 	likelihood that next-hop RBridges on the Ingress RBridge
Tree
> are 
> --> > 	actually going to have an entry for the "unknown MAC
> destination" 
> --> > 	in the frame being flooded on the IRT.
> --> >
> 
> -- [SNIP] --

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 14:26:01 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 3453

Gray, Eric wrote on Friday, October 27, 2006 11:33 AM:

> Larry,
> 
> 	Separating these issues...
> 
> -- [SNIP] --
> -->
> --> Please correct me if I incorrectly summarize the above.
> -->
> --> 1) Scaling the number of fowarding entries in the core is not a
> --> problem that TRILL needs to solve.
> 
> While this is a possible intrepretation, it is not an accurate
> characterization of what I said. 
> 
> I'll try again, starting with what you have said.
> 
> Scaling of the number of forwarding entries in the core is not a
> problem that the TRILL working group has decided to solve. 
> 
> Hence, you might conclude that the TRILL working group has passively
> decided that this is not a problem that TRILL needs to solve. 
> 
> One reason why this might be the case is that people could not decide
> the "by how much" question. 
> 
> Never-the-less, an implicit requirement that the solution should not
> prevent more scalable implementations, enables people who might not
> be able to agree in public (as to what factor of increased
> scalability should apply) to produce and deploy solutions that are in
> fact more scalable, by at least some amount.    
> 
> --> 2) Link utilization is a problem and TRILL needs to be concerned
> --> with it.
> 
> Certainly.
> 
> -->
> --> If this is correct, it leads me to believe that you would advocate
> --> for
> --> 1) Remove the destination RBridge from the shim, and just lookup
> the 
> --> destination MAC directly
> 
> How do you arrive at this conclusion?  There are scenarios where this
> might be done, but clearly the use of a smaller field for a look-up
> is traditionally viewed as likely to be quicker.  

I appologize for trying to put words in you mouth, but I am trying to
understand what you are arguing for...and after reading the above, I
still don't know.  Maybe it is because I am confusing what you are
personally saying versus what you are echoing from others in the group.
Do you believe we need the RBridge Id in the shim or not?  If you do,
then why?  For a quicker lookup?  If so, then why would a slower lookup
to generate the source RBridge for BCN be acceptable?

> 
> --> 2) Eliminate the need for the outer MAC header between two
> RBridges 
> --> if the link is point to point (quite likely in my opinion).
> 
> Ultimately, point-to-point is very likely, but we have to deal with
> the step-by-step deployment scenarios. 
> 
> In any case, I do not advocate special-casing encapsulation based on
> link types in general - beyond that already required by the specific
> link.  As I thought would be obvious by now, I advocate functional
> separation - which works better if you don't build in a lot of layer
> dependencies.

I agree with you about building in a lot of layer dependencies.  Having
transit RBridges look inside the inner MAC seems like a layer dependency
to me.  Not encapsulating with an extra 14 to 18 bytes on point to point
link seems like it would be well worth it if you are concerned with link
overhead.  I would gladly trade 14/18 bytes of overhead for another 2
bytes of source RBridge which will help with BCN as well as help with
network troubleshooting.

> 
> -->
> --> Again, I apologize for not keeping up with the latest discussions,
> --> but have these ideas been discussed already?  If so, could you
> --> summarize the outcome?
> 
> This is not a reasonable request.

Oh well, cant' blame me for trying can you? ;-)

> -- [SNIP] --

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 14:05:27 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 3022

Hi Caitlin,

I think you bring up a good point, that there are multiple scenarios
that we need to analyze.  Please allow me to try to make sure I
understand what you wrote.  In the figure below, we have two end
stations A and C connected via 802.1au capable 802.1q bridges (B) and
RBridges (RB).

A--RB1--B2--RB2--B3--C

In this scenario, B2 is providing transit for traffic from RB1 and RB2.
Assume traffic is flowing from A to C.

Caitlin Bestler wrote on Friday, October 27, 2006 9:53 AM:
> 
> My analasys is that an 802.1au-capable RBridge could send a BCN in
> three different ways: 
> 
> 1) RBridge encapsulated to the original source c/o its
>    source RBridge, which it already knew. The egress RBRidge
>    would typically have this information.

In my network above, I think you are referring to when B3 detects
congestion and generates a BCN back towards RB2. True?

> 2) non-RBridge encapsulated is sent to the outer source,
>    which is the *prior* rbridge and not necessarily the
>    source rbridge, and we specify that 802.1au-capable
>    RBridges act as proxies for BCNs received that are
>    not RBridge encapsulated.

In my network above, I think you are referring to when B2 detects
congestion and generates a BCN back towards RB1.  True?

> 3) RBridge encapsulated to the original source, but with
>    an unknown destination RBridge.

In my network above, I think you are referring to when RB2 detects
congestion and generates a BCN back towards B2.  True?  As I mentioned
earlier, I believe the amount of BCN traffic could be non-trivial, so I
am not comfortable with flooding BCN to all RBridges in this case.

> 
> I believe that #2 is required anyway, to deal with 802.1au bridges
> that are not RBridges. 
> 
> It is also worht pointing out that unless there are *four* RBridges
> in the "rbridge path" that the immediate prior rbridge to any core
> rbridge *will* be the source rbridge.

In a more interesting network (not the straight line I drew), the tree
sourced at the RBridge that is the congestion point may not always have
a branch that goes out the port that the original frame came in on (if
that link has a high cost).  So, I think the originating RBridge may
need to send the BCN on all branches of its tree to ensure it will reach
the source RBridge.
> 
> I believe these three options provide adequate solutions to this
> problem without requiring the addition of the source rbridge to the
> frame. But it does suggest that the header format should be designed
> so that it stacks efficiently with 802.1a headers.   
> 
> Standardizing the 802.1au proxy role is also important because
> otherwise you would have Rate Limited Frame wrappers around RBridge
> encapsulation. I believe it is far better to ensure that the BCN is
> forwarded to the original source so that RBridge encapsulates the
> Rate Limited Frame.    
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 13:01:18 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 724

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gray, Eric
> Sent: Friday, October 27, 2006 8:38 AM
> To: Silvano Gai
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge address and BCN
> 
> 	Already, we have discussed the fact that BCN capable 
> devices are typically segregated onto "BCN capable VLANs."  
> That being the case, it is certainly possible for an 
> implementer to retain MAC DA reachability advertisements for 
> configured "BCN capable VLANS."

Actually the division doesn't happen at VLAN granularity,
but rather at traffic class granularity.  Certain classes
are designated for BCN use.

Anoop

From: "Gray, Eric" <[email-masked]>
To: "Wadekar, Manoj K" <[email-masked]>
Date: Fri, 27 Oct 2006 15:59:36 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 10276

Sure.  Looking forward to it...  :-) 

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 3:29 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi,
--> 
--> I am planning to attend San Diego meeting. Will it be 
--> easier to discuss this and more with pictures (and little 
--> background info) in front of us?
--> 
--> Thanks,
--> Manoj
--> P.S. Meanwhile I will respond to your questions Eric in a bit. 
--> 
--> Sent from my GoodLink synchronized handheld (www.good.com)
--> 
--> 
-->  -----Original Message-----
--> From: 	Gray, Eric [mailto:[email-masked]]
--> Sent:	Friday, October 27, 2006 12:15 PM Pacific Standard Time
--> To:	Wadekar, Manoj K; Gray, Eric
--> Cc:	[email-masked]
--> Subject:	RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Manoj,
--> 
--> 	Thanks!  Your explanation does clarify a few things... 
--> 
--> 	So, BCN clouds can use priority bits to distinguish the
--> traffic that is BCN capable.  Does this mean that these bits
--> are over-loaded, or does a BCN cloud actually have a higher
--> priority in the original sense of the priority bits?
--> 
--> 	In any case, it would still seem that it is quite easy
--> to distinguish BCN cloud traffic from non-BCN cloud traffic.
--> What would be the point of having all traffic in a network at
--> the same elevated priority?  Hence some subset of devices are
--> actually going to be able to consume BCNs.
--> 
--> 	As a point of curiosity, how do the makers of BCN cloud
--> edge devices feel about the fact that the makers of BCN cloud
--> core switches have successfully "passed the buck" on the task 
--> of handling non-BCN compatible devices to the edge devices?
--> 
--> --
--> Eric
--> 
--> 
--> --> -----Original Message-----
--> --> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 2:56 PM
--> --> To: Gray, Eric
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Hi Gary,
--> --> 
--> --> 	"BCN-compliant-cloud" has edges that may connect to
--> --> non-compliant End Station )ES or non-compliant 
--> switches. So, it is
--> --> possible that core can generate BCN that go towards 
--> edge of such a
--> --> cloud. In this case, edge of the cloud provides appropriate 
--> --> termination of BCN (and RLT tags in the data frames). 
--> --> 	BCNs don't necessarily get "dropped" at such an 
--> edge switch. In
--> --> case where this edge connects to a non-compliant ES, 
--> edge switch may
--> --> perform rate control on behalf of such non-compliant ES. 
--> --> So, the edge switches are consuming the BCNs and not 
--> dropping them.
--> --> 
--> --> 	So, core switches do not make the decisions 
--> about to whom they
--> --> are sending BCNs - they can't. They just don't have that 
--> --> information.
--> --> (Only edges know that).
--> --> 
--> --> 	About BCNs and VLANs:
--> --> 	
--> --> 	Just to make sure that I am in sync with 
--> terminology: By VLAN -
--> --> we are discussing vid (12 bits from VLAN tag) and not 
--> --> priority bits (3
--> --> bits from same VLAN tag). 
--> --> 	
--> --> 	Traffic in data center will be separated for 
--> different classes -
--> --> ones that use BCN and ones that don't. But they are 
--> --> differentiated with
--> --> priority bits and not by vids. One can't limit 
--> --> "BCN-compliant traffic"
--> --> only to certain VLANs - because it is possible that from 
--> --> server - I will
--> --> have traffic of both the types. (E.g. LAN traffic going 
--> --> towards WAN -
--> --> does not need BCN, but storage traffic within DC - needs BCN).
--> --> 
--> --> 	Please let me know if this is clear - or I can 
--> start drawing
--> --> pictures or forward link with discussion. (My wording may 
--> --> be confusing
--> --> ..)
--> --> 
--> --> Thanks,
--> --> - Manoj
--> --> 
--> --> -----Original Message-----
--> --> From: Gray, Eric [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 11:27 AM
--> --> To: Wadekar, Manoj K; Gray, Eric
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Manoj,
--> --> 
--> --> 	A BCN notification sent to a non-BCN supporting 
--> end-station
--> --> is "junk traffic" - is it not?  Such an end-station 
--> will - at best
--> --> - simply ignore the extra traffic, and the switch will 
--> just end up
--> --> sending more "junk traffic" to that end-station.
--> --> 
--> --> 	A switch that sends junk traffic to end 
--> stations is not the
--> --> most useful of devices.  Hence it was suggested earlier (I don't
--> --> recall who suggested it) that BCN capable devices would 
--> nost likely
--> --> share common VLANs such that:
--> --> 
--> --> 	1) the aggregate of all BCN supporting devices 
--> can be protected
--> --> 	from non BCN supporting devices by protecting 
--> the bandwidth of
--> --> 	the BCN-VLAN(s);
--> --> 
--> --> 	2) BCN notifications only get sent to BCN 
--> capable devices.
--> --> 
--> --> Using this approach, a switch only needs to be configurable on a
--> --> per-VLAN basis to use, or not use, BCN.
--> --> 
--> --> --
--> --> Eric
--> --> 
--> --> --> -----Original Message-----
--> --> --> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> --> --> Sent: Friday, October 27, 2006 1:54 PM
--> --> --> To: Gray, Eric
--> --> --> Cc: [email-masked]
--> --> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> Hi Eric,
--> --> --> 
--> --> --> 	(My apologies for being slow in my responses..)
--> --> --> 	
--> --> --> 	I did not understand your comment about: " you 
--> --> have to be
--> --> --> careful not to send BCN messages to those end-stations 
--> --> that don't
--> --> --> support them." Can you please clarify? 
--> --> --> 
--> --> --> 	Switches do not have knowledge of which end 
--> --> stations support
--> --> --> BCNs and which do not. 
--> --> --> 
--> --> --> 	Have I missed your point?
--> --> --> 
--> --> --> Thanks,
--> --> --> - Manoj
--> --> --> 	
--> --> --> -----Original Message-----
--> --> --> From: Gray, Eric [mailto:[email-masked]] 
--> --> --> Sent: Friday, October 27, 2006 8:44 AM
--> --> --> To: Wadekar, Manoj K
--> --> --> Cc: [email-masked]
--> --> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> Manoj,
--> --> --> 
--> --> --> 	Once again, the assumption that cores do not 
--> --> retain "addresses
--> --> --> of
--> --> --> all the end-stations in [the] whole cluster" is a 
--> "convenient
--> --> --> assumption"
--> --> --> for making the argument that another mechanism is required.
--> --> --> 
--> --> --> 	Currently, there would be no requirement for 
--> --> retaining all such 
--> --> --> addresses as you have to be careful not to send BCN 
--> --> --> messages to those
--> --> --> end-stations that don't support them.  Moreover, as 
--> mentioned
--> --> --> previously,
--> --> --> it is trivially easy to determine what address 
--> --> information should be
--> --> --> kept.
--> --> --> 
--> --> --> --
--> --> --> Eric
--> --> --> 
--> --> --> --> -----Original Message-----
--> --> --> --> From: [email-masked] 
--> --> --> --> [mailto:[email-masked]] On Behalf Of 
--> --> --> Wadekar, Manoj K
--> --> --> --> Sent: Friday, October 27, 2006 11:21 AM
--> --> --> --> To: [email-masked]
--> --> --> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> --> 
--> --> --> --> Yes, for large clusters, if cores do not 
--> maintain addresses 
--> --> --> --> of all the
--> --> --> --> end-stations in whole cluster - then only way 
--> to get BCN 
--> --> --> --> back to ES, is
--> --> --> --> to send them to ingress rbridge-address and then have 
--> --> --> that ingress
--> --> --> --> rbridge forward BCN to end station with appropriate 
--> --> ES address.
--> --> --> --> 
--> --> --> --> If so, ingress rbdridge address seems to be 
--> --> requirement to me.
--> --> --> --> 
--> --> --> --> Thanks,
--> --> --> --> - Manoj
--> --> --> --> 
--> --> --> --> -----Original Message-----
--> --> --> --> From: Silvano Gai [mailto:[email-masked]] 
--> --> --> --> Sent: Friday, October 27, 2006 8:00 AM
--> --> --> --> To: [email-masked]; Wadekar, Manoj K
--> --> --> --> Cc: [email-masked]
--> --> --> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> --> --> 
--> --> --> --> 
--> --> --> --> If the congestion is detected in the core of the TRILL 
--> --> --> --> network, how do
--> --> --> --> you signal back to the source host if you don't know 
--> --> --> which is the
--> --> --> --> ingresss RBridge? 
--> --> --> --> 
--> --> --> --> You cannot look-up the inner MAC address, because in 
--> --> --> the core of the
--> --> --> --> network you don't keep the inner MAC addresses in the 
--> --> --> --> table. Correct?
--> --> --> --> 
--> --> --> --> This is a clear reason while you need the ingress 
--> --> --> RBridge address.
--> --> --> --> 
--> --> --> --> -- Silvano
--> --> --> --> 
--> --> --> --> > -----Original Message-----
--> --> --> --> > From: [email-masked] 
--> --> --> --> [mailto:[email-masked]]
--> --> --> --> On
--> --> --> --> > Behalf Of [email-masked]
--> --> --> --> > Sent: Thursday, October 26, 2006 5:02 PM
--> --> --> --> > To: Wadekar, Manoj K
--> --> --> --> > Cc: [email-masked]
--> --> --> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> --> > 
--> --> --> --> > Hi Manoj,
--> --> --> --> > 
--> --> --> --> > I'm confused about BCN. Wouldn't congestion 
--> notification 
--> --> --> --> need to go to
--> --> --> --> the
--> --> --> --> > original endnode source,
--> --> --> --> > and not the ingress RBridge?
--> --> --> --> > 
--> --> --> --> > Radia
--> --> --> --> > 
--> --> --> --> 
--> --> --> --> _______________________________________________
--> --> --> --> rbridge mailing list
--> --> --> --> [email-masked]
--> --> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> --> 
--> --> --> 
--> --> 
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 12:29:19 -0700
From: "Wadekar, Manoj K" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 8854

Hi,

I am planning to attend San Diego meeting. Will it be easier to discuss this and more with pictures (and little background info) in front of us?

Thanks,
Manoj
P.S. Meanwhile I will respond to your questions Eric in a bit. 

Sent from my GoodLink synchronized handheld (www.good.com)

 -----Original Message-----
From: 	Gray, Eric [mailto:[email-masked]]
Sent:	Friday, October 27, 2006 12:15 PM Pacific Standard Time
To:	Wadekar, Manoj K; Gray, Eric
Cc:	[email-masked]
Subject:	RE: [rbridge] Ingress Rbridge address and BCN

Manoj,

	Thanks!  Your explanation does clarify a few things... 

	So, BCN clouds can use priority bits to distinguish the
traffic that is BCN capable.  Does this mean that these bits
are over-loaded, or does a BCN cloud actually have a higher
priority in the original sense of the priority bits?

	In any case, it would still seem that it is quite easy
to distinguish BCN cloud traffic from non-BCN cloud traffic.
What would be the point of having all traffic in a network at
the same elevated priority?  Hence some subset of devices are
actually going to be able to consume BCNs.

	As a point of curiosity, how do the makers of BCN cloud
edge devices feel about the fact that the makers of BCN cloud
core switches have successfully "passed the buck" on the task 
of handling non-BCN compatible devices to the edge devices?

--
Eric

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 2:56 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi Gary,
--> 
--> 	"BCN-compliant-cloud" has edges that may connect to
--> non-compliant End Station )ES or non-compliant switches. So, it is
--> possible that core can generate BCN that go towards edge of such a
--> cloud. In this case, edge of the cloud provides appropriate 
--> termination of BCN (and RLT tags in the data frames). 
--> 	BCNs don't necessarily get "dropped" at such an edge switch. In
--> case where this edge connects to a non-compliant ES, edge switch may
--> perform rate control on behalf of such non-compliant ES. 
--> So, the edge switches are consuming the BCNs and not dropping them.
--> 
--> 	So, core switches do not make the decisions about to whom they
--> are sending BCNs - they can't. They just don't have that 
--> information.
--> (Only edges know that).
--> 
--> 	About BCNs and VLANs:
--> 	
--> 	Just to make sure that I am in sync with terminology: By VLAN -
--> we are discussing vid (12 bits from VLAN tag) and not 
--> priority bits (3
--> bits from same VLAN tag). 
--> 	
--> 	Traffic in data center will be separated for different classes -
--> ones that use BCN and ones that don't. But they are 
--> differentiated with
--> priority bits and not by vids. One can't limit 
--> "BCN-compliant traffic"
--> only to certain VLANs - because it is possible that from 
--> server - I will
--> have traffic of both the types. (E.g. LAN traffic going 
--> towards WAN -
--> does not need BCN, but storage traffic within DC - needs BCN).
--> 
--> 	Please let me know if this is clear - or I can start drawing
--> pictures or forward link with discussion. (My wording may 
--> be confusing
--> ..)
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: Gray, Eric [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 11:27 AM
--> To: Wadekar, Manoj K; Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Manoj,
--> 
--> 	A BCN notification sent to a non-BCN supporting end-station
--> is "junk traffic" - is it not?  Such an end-station will - at best
--> - simply ignore the extra traffic, and the switch will just end up
--> sending more "junk traffic" to that end-station.
--> 
--> 	A switch that sends junk traffic to end stations is not the
--> most useful of devices.  Hence it was suggested earlier (I don't
--> recall who suggested it) that BCN capable devices would nost likely
--> share common VLANs such that:
--> 
--> 	1) the aggregate of all BCN supporting devices can be protected
--> 	from non BCN supporting devices by protecting the bandwidth of
--> 	the BCN-VLAN(s);
--> 
--> 	2) BCN notifications only get sent to BCN capable devices.
--> 
--> Using this approach, a switch only needs to be configurable on a
--> per-VLAN basis to use, or not use, BCN.
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 1:54 PM
--> --> To: Gray, Eric
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Hi Eric,
--> --> 
--> --> 	(My apologies for being slow in my responses..)
--> --> 	
--> --> 	I did not understand your comment about: " you 
--> have to be
--> --> careful not to send BCN messages to those end-stations 
--> that don't
--> --> support them." Can you please clarify? 
--> --> 
--> --> 	Switches do not have knowledge of which end 
--> stations support
--> --> BCNs and which do not. 
--> --> 
--> --> 	Have I missed your point?
--> --> 
--> --> Thanks,
--> --> - Manoj
--> --> 	
--> --> -----Original Message-----
--> --> From: Gray, Eric [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 8:44 AM
--> --> To: Wadekar, Manoj K
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Manoj,
--> --> 
--> --> 	Once again, the assumption that cores do not 
--> retain "addresses
--> --> of
--> --> all the end-stations in [the] whole cluster" is a "convenient
--> --> assumption"
--> --> for making the argument that another mechanism is required.
--> --> 
--> --> 	Currently, there would be no requirement for 
--> retaining all such 
--> --> addresses as you have to be careful not to send BCN 
--> --> messages to those
--> --> end-stations that don't support them.  Moreover, as mentioned
--> --> previously,
--> --> it is trivially easy to determine what address 
--> information should be
--> --> kept.
--> --> 
--> --> --
--> --> Eric
--> --> 
--> --> --> -----Original Message-----
--> --> --> From: [email-masked] 
--> --> --> [mailto:[email-masked]] On Behalf Of 
--> --> Wadekar, Manoj K
--> --> --> Sent: Friday, October 27, 2006 11:21 AM
--> --> --> To: [email-masked]
--> --> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> Yes, for large clusters, if cores do not maintain addresses 
--> --> --> of all the
--> --> --> end-stations in whole cluster - then only way to get BCN 
--> --> --> back to ES, is
--> --> --> to send them to ingress rbridge-address and then have 
--> --> that ingress
--> --> --> rbridge forward BCN to end station with appropriate 
--> ES address.
--> --> --> 
--> --> --> If so, ingress rbdridge address seems to be 
--> requirement to me.
--> --> --> 
--> --> --> Thanks,
--> --> --> - Manoj
--> --> --> 
--> --> --> -----Original Message-----
--> --> --> From: Silvano Gai [mailto:[email-masked]] 
--> --> --> Sent: Friday, October 27, 2006 8:00 AM
--> --> --> To: [email-masked]; Wadekar, Manoj K
--> --> --> Cc: [email-masked]
--> --> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> 
--> --> --> If the congestion is detected in the core of the TRILL 
--> --> --> network, how do
--> --> --> you signal back to the source host if you don't know 
--> --> which is the
--> --> --> ingresss RBridge? 
--> --> --> 
--> --> --> You cannot look-up the inner MAC address, because in 
--> --> the core of the
--> --> --> network you don't keep the inner MAC addresses in the 
--> --> --> table. Correct?
--> --> --> 
--> --> --> This is a clear reason while you need the ingress 
--> --> RBridge address.
--> --> --> 
--> --> --> -- Silvano
--> --> --> 
--> --> --> > -----Original Message-----
--> --> --> > From: [email-masked] 
--> --> --> [mailto:[email-masked]]
--> --> --> On
--> --> --> > Behalf Of [email-masked]
--> --> --> > Sent: Thursday, October 26, 2006 5:02 PM
--> --> --> > To: Wadekar, Manoj K
--> --> --> > Cc: [email-masked]
--> --> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> > 
--> --> --> > Hi Manoj,
--> --> --> > 
--> --> --> > I'm confused about BCN. Wouldn't congestion notification 
--> --> --> need to go to
--> --> --> the
--> --> --> > original endnode source,
--> --> --> > and not the ingress RBridge?
--> --> --> > 
--> --> --> > Radia
--> --> --> > 
--> --> --> 
--> --> --> _______________________________________________
--> --> --> rbridge mailing list
--> --> --> [email-masked]
--> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> 
--> --> 
--> 

From: "Gray, Eric" <[email-masked]>
To: "Wadekar, Manoj K" <[email-masked]>, "Gray, Eric" <[email-masked]>
Date: Fri, 27 Oct 2006 15:15:19 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 8311

Manoj,

	Thanks!  Your explanation does clarify a few things... 

	So, BCN clouds can use priority bits to distinguish the
traffic that is BCN capable.  Does this mean that these bits
are over-loaded, or does a BCN cloud actually have a higher
priority in the original sense of the priority bits?

	In any case, it would still seem that it is quite easy
to distinguish BCN cloud traffic from non-BCN cloud traffic.
What would be the point of having all traffic in a network at
the same elevated priority?  Hence some subset of devices are
actually going to be able to consume BCNs.

	As a point of curiosity, how do the makers of BCN cloud
edge devices feel about the fact that the makers of BCN cloud
core switches have successfully "passed the buck" on the task 
of handling non-BCN compatible devices to the edge devices?

--
Eric

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 2:56 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi Gary,
--> 
--> 	"BCN-compliant-cloud" has edges that may connect to
--> non-compliant End Station )ES or non-compliant switches. So, it is
--> possible that core can generate BCN that go towards edge of such a
--> cloud. In this case, edge of the cloud provides appropriate 
--> termination of BCN (and RLT tags in the data frames). 
--> 	BCNs don't necessarily get "dropped" at such an edge switch. In
--> case where this edge connects to a non-compliant ES, edge switch may
--> perform rate control on behalf of such non-compliant ES. 
--> So, the edge switches are consuming the BCNs and not dropping them.
--> 
--> 	So, core switches do not make the decisions about to whom they
--> are sending BCNs - they can't. They just don't have that 
--> information.
--> (Only edges know that).
--> 
--> 	About BCNs and VLANs:
--> 	
--> 	Just to make sure that I am in sync with terminology: By VLAN -
--> we are discussing vid (12 bits from VLAN tag) and not 
--> priority bits (3
--> bits from same VLAN tag). 
--> 	
--> 	Traffic in data center will be separated for different classes -
--> ones that use BCN and ones that don't. But they are 
--> differentiated with
--> priority bits and not by vids. One can't limit 
--> "BCN-compliant traffic"
--> only to certain VLANs - because it is possible that from 
--> server - I will
--> have traffic of both the types. (E.g. LAN traffic going 
--> towards WAN -
--> does not need BCN, but storage traffic within DC - needs BCN).
--> 
--> 	Please let me know if this is clear - or I can start drawing
--> pictures or forward link with discussion. (My wording may 
--> be confusing
--> ..)
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: Gray, Eric [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 11:27 AM
--> To: Wadekar, Manoj K; Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Manoj,
--> 
--> 	A BCN notification sent to a non-BCN supporting end-station
--> is "junk traffic" - is it not?  Such an end-station will - at best
--> - simply ignore the extra traffic, and the switch will just end up
--> sending more "junk traffic" to that end-station.
--> 
--> 	A switch that sends junk traffic to end stations is not the
--> most useful of devices.  Hence it was suggested earlier (I don't
--> recall who suggested it) that BCN capable devices would nost likely
--> share common VLANs such that:
--> 
--> 	1) the aggregate of all BCN supporting devices can be protected
--> 	from non BCN supporting devices by protecting the bandwidth of
--> 	the BCN-VLAN(s);
--> 
--> 	2) BCN notifications only get sent to BCN capable devices.
--> 
--> Using this approach, a switch only needs to be configurable on a
--> per-VLAN basis to use, or not use, BCN.
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 1:54 PM
--> --> To: Gray, Eric
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Hi Eric,
--> --> 
--> --> 	(My apologies for being slow in my responses..)
--> --> 	
--> --> 	I did not understand your comment about: " you 
--> have to be
--> --> careful not to send BCN messages to those end-stations 
--> that don't
--> --> support them." Can you please clarify? 
--> --> 
--> --> 	Switches do not have knowledge of which end 
--> stations support
--> --> BCNs and which do not. 
--> --> 
--> --> 	Have I missed your point?
--> --> 
--> --> Thanks,
--> --> - Manoj
--> --> 	
--> --> -----Original Message-----
--> --> From: Gray, Eric [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 8:44 AM
--> --> To: Wadekar, Manoj K
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Manoj,
--> --> 
--> --> 	Once again, the assumption that cores do not 
--> retain "addresses
--> --> of
--> --> all the end-stations in [the] whole cluster" is a "convenient
--> --> assumption"
--> --> for making the argument that another mechanism is required.
--> --> 
--> --> 	Currently, there would be no requirement for 
--> retaining all such 
--> --> addresses as you have to be careful not to send BCN 
--> --> messages to those
--> --> end-stations that don't support them.  Moreover, as mentioned
--> --> previously,
--> --> it is trivially easy to determine what address 
--> information should be
--> --> kept.
--> --> 
--> --> --
--> --> Eric
--> --> 
--> --> --> -----Original Message-----
--> --> --> From: [email-masked] 
--> --> --> [mailto:[email-masked]] On Behalf Of 
--> --> Wadekar, Manoj K
--> --> --> Sent: Friday, October 27, 2006 11:21 AM
--> --> --> To: [email-masked]
--> --> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> Yes, for large clusters, if cores do not maintain addresses 
--> --> --> of all the
--> --> --> end-stations in whole cluster - then only way to get BCN 
--> --> --> back to ES, is
--> --> --> to send them to ingress rbridge-address and then have 
--> --> that ingress
--> --> --> rbridge forward BCN to end station with appropriate 
--> ES address.
--> --> --> 
--> --> --> If so, ingress rbdridge address seems to be 
--> requirement to me.
--> --> --> 
--> --> --> Thanks,
--> --> --> - Manoj
--> --> --> 
--> --> --> -----Original Message-----
--> --> --> From: Silvano Gai [mailto:[email-masked]] 
--> --> --> Sent: Friday, October 27, 2006 8:00 AM
--> --> --> To: [email-masked]; Wadekar, Manoj K
--> --> --> Cc: [email-masked]
--> --> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> --> 
--> --> --> 
--> --> --> If the congestion is detected in the core of the TRILL 
--> --> --> network, how do
--> --> --> you signal back to the source host if you don't know 
--> --> which is the
--> --> --> ingresss RBridge? 
--> --> --> 
--> --> --> You cannot look-up the inner MAC address, because in 
--> --> the core of the
--> --> --> network you don't keep the inner MAC addresses in the 
--> --> --> table. Correct?
--> --> --> 
--> --> --> This is a clear reason while you need the ingress 
--> --> RBridge address.
--> --> --> 
--> --> --> -- Silvano
--> --> --> 
--> --> --> > -----Original Message-----
--> --> --> > From: [email-masked] 
--> --> --> [mailto:[email-masked]]
--> --> --> On
--> --> --> > Behalf Of [email-masked]
--> --> --> > Sent: Thursday, October 26, 2006 5:02 PM
--> --> --> > To: Wadekar, Manoj K
--> --> --> > Cc: [email-masked]
--> --> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> --> > 
--> --> --> > Hi Manoj,
--> --> --> > 
--> --> --> > I'm confused about BCN. Wouldn't congestion notification 
--> --> --> need to go to
--> --> --> the
--> --> --> > original endnode source,
--> --> --> > and not the ingress RBridge?
--> --> --> > 
--> --> --> > Radia
--> --> --> > 
--> --> --> 
--> --> --> _______________________________________________
--> --> --> rbridge mailing list
--> --> --> [email-masked]
--> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> --> 
--> --> 
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 11:55:43 -0700
From: "Wadekar, Manoj K" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 6395

Hi Gary,

	"BCN-compliant-cloud" has edges that may connect to
non-compliant End Station )ES or non-compliant switches. So, it is
possible that core can generate BCN that go towards edge of such a
cloud. In this case, edge of the cloud provides appropriate termination
of BCN (and RLT tags in the data frames). 
	BCNs don't necessarily get "dropped" at such an edge switch. In
case where this edge connects to a non-compliant ES, edge switch may
perform rate control on behalf of such non-compliant ES. So, the edge
switches are consuming the BCNs and not dropping them.

	So, core switches do not make the decisions about to whom they
are sending BCNs - they can't. They just don't have that information.
(Only edges know that).

	About BCNs and VLANs:
	
	Just to make sure that I am in sync with terminology: By VLAN -
we are discussing vid (12 bits from VLAN tag) and not priority bits (3
bits from same VLAN tag). 
	
	Traffic in data center will be separated for different classes -
ones that use BCN and ones that don't. But they are differentiated with
priority bits and not by vids. One can't limit "BCN-compliant traffic"
only to certain VLANs - because it is possible that from server - I will
have traffic of both the types. (E.g. LAN traffic going towards WAN -
does not need BCN, but storage traffic within DC - needs BCN).

	Please let me know if this is clear - or I can start drawing
pictures or forward link with discussion. (My wording may be confusing
..)

Thanks,
- Manoj

-----Original Message-----
From: Gray, Eric [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 11:27 AM
To: Wadekar, Manoj K; Gray, Eric
Cc: [email-masked]
Subject: RE: [rbridge] Ingress Rbridge address and BCN

Manoj,

	A BCN notification sent to a non-BCN supporting end-station
is "junk traffic" - is it not?  Such an end-station will - at best
- simply ignore the extra traffic, and the switch will just end up
sending more "junk traffic" to that end-station.

	A switch that sends junk traffic to end stations is not the
most useful of devices.  Hence it was suggested earlier (I don't
recall who suggested it) that BCN capable devices would nost likely
share common VLANs such that:

	1) the aggregate of all BCN supporting devices can be protected
	from non BCN supporting devices by protecting the bandwidth of
	the BCN-VLAN(s);

	2) BCN notifications only get sent to BCN capable devices.

Using this approach, a switch only needs to be configurable on a
per-VLAN basis to use, or not use, BCN.

--
Eric

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 1:54 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi Eric,
--> 
--> 	(My apologies for being slow in my responses..)
--> 	
--> 	I did not understand your comment about: " you have to be
--> careful not to send BCN messages to those end-stations that don't
--> support them." Can you please clarify? 
--> 
--> 	Switches do not have knowledge of which end stations support
--> BCNs and which do not. 
--> 
--> 	Have I missed your point?
--> 
--> Thanks,
--> - Manoj
--> 	
--> -----Original Message-----
--> From: Gray, Eric [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 8:44 AM
--> To: Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Manoj,
--> 
--> 	Once again, the assumption that cores do not retain "addresses
--> of
--> all the end-stations in [the] whole cluster" is a "convenient
--> assumption"
--> for making the argument that another mechanism is required.
--> 
--> 	Currently, there would be no requirement for retaining all such 
--> addresses as you have to be careful not to send BCN 
--> messages to those
--> end-stations that don't support them.  Moreover, as mentioned
--> previously,
--> it is trivially easy to determine what address information should be
--> kept.
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: [email-masked] 
--> --> [mailto:[email-masked]] On Behalf Of 
--> Wadekar, Manoj K
--> --> Sent: Friday, October 27, 2006 11:21 AM
--> --> To: [email-masked]
--> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Yes, for large clusters, if cores do not maintain addresses 
--> --> of all the
--> --> end-stations in whole cluster - then only way to get BCN 
--> --> back to ES, is
--> --> to send them to ingress rbridge-address and then have 
--> that ingress
--> --> rbridge forward BCN to end station with appropriate ES address.
--> --> 
--> --> If so, ingress rbdridge address seems to be requirement to me.
--> --> 
--> --> Thanks,
--> --> - Manoj
--> --> 
--> --> -----Original Message-----
--> --> From: Silvano Gai [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 8:00 AM
--> --> To: [email-masked]; Wadekar, Manoj K
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> 
--> --> If the congestion is detected in the core of the TRILL 
--> --> network, how do
--> --> you signal back to the source host if you don't know 
--> which is the
--> --> ingresss RBridge? 
--> --> 
--> --> You cannot look-up the inner MAC address, because in 
--> the core of the
--> --> network you don't keep the inner MAC addresses in the 
--> --> table. Correct?
--> --> 
--> --> This is a clear reason while you need the ingress 
--> RBridge address.
--> --> 
--> --> -- Silvano
--> --> 
--> --> > -----Original Message-----
--> --> > From: [email-masked] 
--> --> [mailto:[email-masked]]
--> --> On
--> --> > Behalf Of [email-masked]
--> --> > Sent: Thursday, October 26, 2006 5:02 PM
--> --> > To: Wadekar, Manoj K
--> --> > Cc: [email-masked]
--> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> > 
--> --> > Hi Manoj,
--> --> > 
--> --> > I'm confused about BCN. Wouldn't congestion notification 
--> --> need to go to
--> --> the
--> --> > original endnode source,
--> --> > and not the ingress RBridge?
--> --> > 
--> --> > Radia
--> --> > 
--> --> 
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> 
--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 14:52:27 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue
Status: RO
Content-Length: 1543

-- [SNIP] --     
 
--> > 3rd Issue - why use tunneling if RBridges typically may be required
--> > to retain all MAC reachability information?
--> > ========================================== 
--> > 
--> > 	There are several reasons to do this, independent of any desire to
--> > reduce memory requirements of RBridges. 
--> > 
--> > 	One is that 802.1X bridges on intermediate links are shielded from
--> > exposure to MAC addresses on separate bridged LAN segements. 
--> 
--> I thought that was accomplished by adding the additional MAC header
--> between the two RBridges carrying their MACs.  The 802.1X bridges
--> connecting them will only learn these two RBridges MACs regardless of
--> whether there is a destination RBridge in the shim.

Look, again, at the definition of the "3rd Issue" above.

>From you comment, it seems you missed that...

--> > 
--> > 	Another is that the forwarding entries in RBridges are based on use
--> > of RBridge MAC addresses - which reduces the number of entries that
--> > will typically be used for forwarding by an intermediate RBridge.  
--> 
--> I'm missing the destinction between what you call the "memory
requirements 
--> RBridges", and "the number of entries that will typeically be used for 
--> forwarding".  I was assuming these were the same thing.

They are separable in a number of different ways.  Trying to state it
at a high level, it is certainly possible to optimize your look-up 
algorithms for a subset of frequently used entries.  Caching comes to
mind, for example.

--> 

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 14:46:14 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
Status: RO
Content-Length: 2948

-- [SNIP] --     

--> > 
--> > 2nd Issue - what is the importance of "optimizing" support for BCN?
--> > ==================================================================
--> > 
--> > 	BCN is likely to be important for a number of applications that we
--> > care about.  But is it important enough that we should design an
RBridge 
--> > solution that is optimized for it, or is it sufficient that our
solution 
--> > is not significantly sub-optimal for these applications?
--> > 
--> > 	As Radia has already pointed out, an RBridge that finds itself with
--> > a frame it must deliver, and no corresponding forwarding entry, will
--> > forward that frame on the ingress RBridge tree (corresponding to
delivery 
--> > of unknown MAC destination "flooding").  This is sub-optimal, but the 
--> > choice that leads to an RBridge finding it needs to do this in the BCN

--> > case is (as I've said before) entirely an implementation choice.  
--> > Presumably, the implementer may choose to discard even BCN related MAC

--> > reachability if - as a trade-off decision - they believe that
conservative 
--> > retention of MAC reachability is desirable over optimal support of
BCN.         
--> > 
--> > 	I personally favor the idea of forwarding BCN notifications on the
--> > Ingress RBridge Tree - for those implementations that do not keep the
--> > appropriate MAC reachability information.  I favor this because:  
--> > 
--> > 	1) it is consistent with how bridges work now, therefore it is
--> > 	not a departure from "the devil we know,"
--> 
--> Last time looked at the BCN proposal, there could be a significant
amount 
--> of BCN traffic during congestion.  Flooding this traffic to ALL RBridges

--> seems like a bad idea if you are concerned with link utilization.

A couple of separable points -

1) Flooding will only occur when a specific RBridge has removed (due to
aging, for example), or failed to retain, an entry it subsequently needs. 
This kind of flooding could occur in any case (although it might involve
a smaller subset of the entire network).

2) If, as you say, "there could be a significant amount of BCN traffic
during congestion", then BCN suffers from fatal design flaws.  If the
need to occasionally flood BCN notifications contributes to this flaw,
that is an issue (certainly), but it is one that is likely to be fixed
at the same time as the current fatal flaw in BCN is fixed.

--> 
--> > 
--> > 	2) it affects only implementations that are designed to discard
--> > 	potentially useful information in favor of reduced memory needs
--> > 	and
--> > 
--> > 	3) it is a generic solution related to Caitlin's earlier remarks
--> > 	with respect to the relative numbers of "core RBridges" and the
--> > 	likelihood that next-hop RBridges on the Ingress RBridge Tree are
--> > 	actually going to have an entry for the "unknown MAC destination"
--> > 	in the frame being flooded on the IRT.
--> > 

-- [SNIP] --

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 14:33:08 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue
Status: RO
Content-Length: 2274

Larry,

	Separating these issues...

-- [SNIP] --     
--> 
--> Please correct me if I incorrectly summarize the above.
--> 
--> 1) Scaling the number of fowarding entries in the core is not a problem
--> that TRILL needs to solve.

While this is a possible intrepretation, it is not an accurate 
characterization of what I said.

I'll try again, starting with what you have said.

Scaling of the number of forwarding entries in the core is not
a problem that the TRILL working group has decided to solve.

Hence, you might conclude that the TRILL working group has 
passively decided that this is not a problem that TRILL needs
to solve.

One reason why this might be the case is that people could 
not decide the "by how much" question.

Never-the-less, an implicit requirement that the solution 
should not prevent more scalable implementations, enables 
people who might not be able to agree in public (as to what
factor of increased scalability should apply) to produce
and deploy solutions that are in fact more scalable, by at
least some amount.

--> 2) Link utilization is a problem and TRILL needs to be concerned with
--> it.

Certainly.

--> 
--> If this is correct, it leads me to believe that you would advocate for 
--> 1) Remove the destination RBridge from the shim, and just lookup the
--> destination MAC directly

How do you arrive at this conclusion?  There are scenarios where
this might be done, but clearly the use of a smaller field for a
look-up is traditionally viewed as likely to be quicker.

--> 2) Eliminate the need for the outer MAC header between two RBridges if
--> the link is point to point (quite likely in my opinion).

Ultimately, point-to-point is very likely, but we have to deal with the
step-by-step deployment scenarios.

In any case, I do not advocate special-casing encapsulation based on
link types in general - beyond that already required by the specific
link.  As I thought would be obvious by now, I advocate functional
separation - which works better if you don't build in a lot of layer
dependencies.

--> 
--> Again, I apologize for not keeping up with the latest discussions, but
--> have these ideas been discussed already?  If so, could you summarize the
--> outcome?

This is not a reasonable request.

-- [SNIP] --

From: "Gray, Eric" <[email-masked]>
To: "Wadekar, Manoj K" <[email-masked]>, "Gray, Eric" <[email-masked]>
Date: Fri, 27 Oct 2006 14:27:21 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 4674

Manoj,

	A BCN notification sent to a non-BCN supporting end-station
is "junk traffic" - is it not?  Such an end-station will - at best
- simply ignore the extra traffic, and the switch will just end up
sending more "junk traffic" to that end-station.

	A switch that sends junk traffic to end stations is not the
most useful of devices.  Hence it was suggested earlier (I don't
recall who suggested it) that BCN capable devices would nost likely
share common VLANs such that:

	1) the aggregate of all BCN supporting devices can be protected
	from non BCN supporting devices by protecting the bandwidth of
	the BCN-VLAN(s);

	2) BCN notifications only get sent to BCN capable devices.

Using this approach, a switch only needs to be configurable on a
per-VLAN basis to use, or not use, BCN.

--
Eric

--> -----Original Message-----
--> From: Wadekar, Manoj K [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 1:54 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi Eric,
--> 
--> 	(My apologies for being slow in my responses..)
--> 	
--> 	I did not understand your comment about: " you have to be
--> careful not to send BCN messages to those end-stations that don't
--> support them." Can you please clarify? 
--> 
--> 	Switches do not have knowledge of which end stations support
--> BCNs and which do not. 
--> 
--> 	Have I missed your point?
--> 
--> Thanks,
--> - Manoj
--> 	
--> -----Original Message-----
--> From: Gray, Eric [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 8:44 AM
--> To: Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Manoj,
--> 
--> 	Once again, the assumption that cores do not retain "addresses
--> of
--> all the end-stations in [the] whole cluster" is a "convenient
--> assumption"
--> for making the argument that another mechanism is required.
--> 
--> 	Currently, there would be no requirement for retaining all such 
--> addresses as you have to be careful not to send BCN 
--> messages to those
--> end-stations that don't support them.  Moreover, as mentioned
--> previously,
--> it is trivially easy to determine what address information should be
--> kept.
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: [email-masked] 
--> --> [mailto:[email-masked]] On Behalf Of 
--> Wadekar, Manoj K
--> --> Sent: Friday, October 27, 2006 11:21 AM
--> --> To: [email-masked]
--> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> Yes, for large clusters, if cores do not maintain addresses 
--> --> of all the
--> --> end-stations in whole cluster - then only way to get BCN 
--> --> back to ES, is
--> --> to send them to ingress rbridge-address and then have 
--> that ingress
--> --> rbridge forward BCN to end station with appropriate ES address.
--> --> 
--> --> If so, ingress rbdridge address seems to be requirement to me.
--> --> 
--> --> Thanks,
--> --> - Manoj
--> --> 
--> --> -----Original Message-----
--> --> From: Silvano Gai [mailto:[email-masked]] 
--> --> Sent: Friday, October 27, 2006 8:00 AM
--> --> To: [email-masked]; Wadekar, Manoj K
--> --> Cc: [email-masked]
--> --> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> --> 
--> --> 
--> --> If the congestion is detected in the core of the TRILL 
--> --> network, how do
--> --> you signal back to the source host if you don't know 
--> which is the
--> --> ingresss RBridge? 
--> --> 
--> --> You cannot look-up the inner MAC address, because in 
--> the core of the
--> --> network you don't keep the inner MAC addresses in the 
--> --> table. Correct?
--> --> 
--> --> This is a clear reason while you need the ingress 
--> RBridge address.
--> --> 
--> --> -- Silvano
--> --> 
--> --> > -----Original Message-----
--> --> > From: [email-masked] 
--> --> [mailto:[email-masked]]
--> --> On
--> --> > Behalf Of [email-masked]
--> --> > Sent: Thursday, October 26, 2006 5:02 PM
--> --> > To: Wadekar, Manoj K
--> --> > Cc: [email-masked]
--> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> --> > 
--> --> > Hi Manoj,
--> --> > 
--> --> > I'm confused about BCN. Wouldn't congestion notification 
--> --> need to go to
--> --> the
--> --> > original endnode source,
--> --> > and not the ingress RBridge?
--> --> > 
--> --> > Radia
--> --> > 
--> --> 
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> 
--> 

Date: Fri, 27 Oct 2006 11:24:14 -0700
From: Joe Touch <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Last Call comment on:	http://www.ietf.org/internet- drafts/draft-ietf-trill-prob-01.txt
Status: RO
Content-Length: 3295

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCF8A01D52389571DAB0FA8C2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Gray, Eric wrote:
> --> Sgai 2> ST provides symmetrical forwarding, i.e. the path from A to=
 B is
> --> the reverse of the path from B to A. Is this a requirement for TRIL=
L?
>=20
> I believe this has certainly been assumed in discussions, but it
> might not have been deemed necessary to explicitly include this
> as a "requirement" in the PA&S document.  It is a behavior that
> applies to existing 802.1D bridges and we are required to be
> compatible with 802.1D bridges.

It would not necessarily be true depending on the routes used. The paths
between rbridge nodes would be symmetric, since that uses 802.1D links,
but paths within an rbridge would have only symmetric ingress/egress
pairs. Internally, the paths could differ, but that shouldn't matter.

> --> Sgai 3> the terminology used in this draft is not the one used in I=
EEE
> --> standards. This makes it difficult to understand what certain sente=
nces
> --> really mean. Concepts like autolearning and caches are not IEEE
> concepts.
>=20
> This observation has been made before.  Can you make specific=20
> proposals for textual changes (replace "XYZ" with "LMNOP")?

That'd be useful, but both terms might be needed; this isn't an IEEE
document, ultimately.

> --> Sgai 4> There is no mention of the applicability of other important=
 IEEE
> --> standards/WG/Study Groups, e.g.
> --> - 802.3ad-2000, Link Aggregation.
> --> - 802.1ah - Provider Backbone Bridges
> --> - 802.1aq - Shortest Path Bridging
> --> - 802.1au - Congestion Notification
> --> - 802.1ad - Provider Bridges=20
> --> - 802.1AE - MAC Security
> --> - 802.3ar - Congestion Management Task Force.
> --> - 802.3as - Frame Expansion Task Force.
> --> I think this document needs to clearly state the position of the WG=
 with
> --> respect to these projects.
> -->=20
> --> Sgai 5> I also think there need to be a mention of the applicabilit=
y of
> --> important industrial efforts:
> --> - NIC Teaming
> --> - uplinkfast
> --> - split-MLT
> --> - Q in Q
> --> All these are widely deployed in all datacenters/enterprises. I thi=
nk
> --> this document needs to clearly state the position of the WG with re=
spect
> --> to these de fact standards.
>=20
> Why?  Is it not sufficient to say that the solution must be compatible
> with existing technologies without listing them all?

The document should list the techologies we depend on (802.1D) and
intend to replace per se. Again, this isn't an IEEE document, so a
comprehensive list of all IEEE-related technologies might be out of
scope. The chairs might suggest where that boundary would be.

Joe

--------------enigCF8A01D52389571DAB0FA8C2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigCF8A01D52389571DAB0FA8C2--

Date: Fri, 27 Oct 2006 11:21:08 -0700
From: Radia Perlman <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 1337

Summary of below---asking how many RBridges anyone would ever expect to
need in a single campus.

Gray, Eric wrote:

>Radia,
>
>	I don't know where the idea that we only need a 2-byte
>nick-name comes from.  When did we change from the idea of using 
>an MPLS (or MPLS-like) SHIM with 19 bits to represent specific
>RBridges to using a completely different SHIM and only requiring 
>16-bits of RBridge identification?
>
The number 19-bits was chosen just because the MPLS label field was 20 bits,
and we were stealing one to indicate whether the field was "ingress" or 
"egress".
There was no science behind 19-bits other than it happened to be there, and
seemed uncontroversially way more than we'd actually need, so would
clearly be big enough.

If we weren't using an MPLS-like header, then we can actually think about
what size field we'd need. We wouldn't want the nickname space to be
too densely used, so 16 bits would support, say, 30,000 RBridges.

So the question is---how many RBridges would anyone need? Remember, this 
is for
your "LAN"---it's not intended to replace layer 3. What size bridged 
networks
are people building today? More than 1000 bridges?

So if nobody is building anything more than 1000 bridges, say, then 16 
bits is
safe. If 16 bits isn't safe, then sure, we can pick a different size field.

Radia

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 11:00:01 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 804

Larry Kreeger wrote:
> 
> I'm missing the destinction between what you call the "memory
> requirements RBridges", and "the number of entries that will
> typeically be used for forwarding".  I was assuming these
> were the same thing.
> 

It's not just how much memory is required by an intermediate
rbridge, it's whether it would have ever bother to not the
inner destination in the first place.

When there is no BCN to be generated an intermediate RBridge
would simply forward based on the destination RBridge and
never even look at the encapsulated packet. BCN could be
the only type of frame that it needs to encapsulate.

So this is more than just a "how much memory" issue.
But, as noted earlier, there are solutions that do not
involve larger tables or include the source rbridge
in the shim.

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Fri, 27 Oct 2006 13:58:53 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet-	drafts/draft-ietf-trill-prob-01.txt
Status: RO
Content-Length: 3240

Silvano, et al,

	 Please see below.

-- [SNIP] --
--> I don't think it is acceptable to have temporary loop for broadcast
--> multicast, even if they are mitigated by TTL. An interlock mechanism
--> similar to ST must be used for multicast/broadcast.
--> 
--> I ask for a strong requirement that says: "TRILL MUST avoid
--> multicast/broadcast storms"

I completely agree with this and I have been assuming an "interlock"
function would be applied - especially for non-unicast or unknown
frames.

In retrospect, it is obvious that this should be explicitly spelled
out.

--> 
--> Sgai 2> ST provides symmetrical forwarding, i.e. the path from A to B is
--> the reverse of the path from B to A. Is this a requirement for TRILL?

I believe this has certainly been assumed in discussions, but it
might not have been deemed necessary to explicitly include this
as a "requirement" in the PA&S document.  It is a behavior that
applies to existing 802.1D bridges and we are required to be
compatible with 802.1D bridges.

--> 
--> Sgai 3> the terminology used in this draft is not the one used in IEEE
--> standards. This makes it difficult to understand what certain sentences
--> really mean. Concepts like autolearning and caches are not IEEE
concepts.

This observation has been made before.  Can you make specific 
proposals for textual changes (replace "XYZ" with "LMNOP")?

--> 
--> Sgai 4> There is no mention of the applicability of other important IEEE
--> standards/WG/Study Groups, e.g.
--> - 802.3ad-2000, Link Aggregation.
--> - 802.1ah - Provider Backbone Bridges
--> - 802.1aq - Shortest Path Bridging
--> - 802.1au - Congestion Notification
--> - 802.1ad - Provider Bridges 
--> - 802.1AE - MAC Security
--> - 802.3ar - Congestion Management Task Force.
--> - 802.3as - Frame Expansion Task Force.
--> I think this document needs to clearly state the position of the WG with
--> respect to these projects.
--> 
--> Sgai 5> I also think there need to be a mention of the applicability of
--> important industrial efforts:
--> - NIC Teaming
--> - uplinkfast
--> - split-MLT
--> - Q in Q
--> All these are widely deployed in all datacenters/enterprises. I think
--> this document needs to clearly state the position of the WG with respect
--> to these de fact standards.

Why?  Is it not sufficient to say that the solution must be compatible
with existing technologies without listing them all?

--> 
--> Sgai 6> Many customers look at TRILL as a backbone network. They would
--> like to connect their current switches to the TRILL backbone using
--> Etherchannel  and connecting the member links on different RBridges for
--> High availability. Is this a requirement? In general which is the
--> relation between Etherchannel and TRILL?

These are good questions, touching on at least one of the issues that
has been brought up previously (the "wiring closet problem").

I am not sure that the WG has reached consensus on this.  At present,
there appears to be a distinct "lean" toward simply listing the set
of existing deployment scenarios that may not be directly supported
using RBridges in a partial-deployment scenario.

--> 
--> Sgai 7> Does TRILL work properly if Ethernet is deployed with Pause
--> enabled?
-- [SNIP] --

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 10:53:58 -0700
From: "Wadekar, Manoj K" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 3163

Hi Eric,

	(My apologies for being slow in my responses..)
	
	I did not understand your comment about: " you have to be
careful not to send BCN messages to those end-stations that don't
support them." Can you please clarify? 

	Switches do not have knowledge of which end stations support
BCNs and which do not. 

	Have I missed your point?

Thanks,
- Manoj
	
-----Original Message-----
From: Gray, Eric [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 8:44 AM
To: Wadekar, Manoj K
Cc: [email-masked]
Subject: RE: [rbridge] Ingress Rbridge address and BCN

Manoj,

	Once again, the assumption that cores do not retain "addresses
of
all the end-stations in [the] whole cluster" is a "convenient
assumption"
for making the argument that another mechanism is required.

	Currently, there would be no requirement for retaining all such 
addresses as you have to be careful not to send BCN messages to those
end-stations that don't support them.  Moreover, as mentioned
previously,
it is trivially easy to determine what address information should be
kept.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Wadekar, Manoj K
--> Sent: Friday, October 27, 2006 11:21 AM
--> To: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> Yes, for large clusters, if cores do not maintain addresses 
--> of all the
--> end-stations in whole cluster - then only way to get BCN 
--> back to ES, is
--> to send them to ingress rbridge-address and then have that ingress
--> rbridge forward BCN to end station with appropriate ES address.
--> 
--> If so, ingress rbdridge address seems to be requirement to me.
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 8:00 AM
--> To: [email-masked]; Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> 
--> If the congestion is detected in the core of the TRILL 
--> network, how do
--> you signal back to the source host if you don't know which is the
--> ingresss RBridge? 
--> 
--> You cannot look-up the inner MAC address, because in the core of the
--> network you don't keep the inner MAC addresses in the 
--> table. Correct?
--> 
--> This is a clear reason while you need the ingress RBridge address.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]
--> On
--> > Behalf Of [email-masked]
--> > Sent: Thursday, October 26, 2006 5:02 PM
--> > To: Wadekar, Manoj K
--> > Cc: [email-masked]
--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> > 
--> > Hi Manoj,
--> > 
--> > I'm confused about BCN. Wouldn't congestion notification 
--> need to go to
--> the
--> > original endnode source,
--> > and not the ingress RBridge?
--> > 
--> > Radia
--> > 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 10:46:55 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 6267

Eric,

My responses are inline below. - Larry

Gray, Eric wrote on Friday, October 27, 2006 10:13 AM:

> Larry,
> 
> 	The phrase "one of the advantages" is key here.
>                   +++++++++++++++++++++
> 
> 	We're complicating discussion by combining issues and trying to
> address them all at the same time. 
> 
> 1st Issue - Scale advantages of not retaining end-station MAC
> information in "core RBridges"? ==============================
> 
> 	The sole advantage that would derive from having a requirement
that
> so-called "core RBridges" do not need to retain MAC reachability
> information would be to increase the scale of LAN sizes by reducing
> the memory requirements associated with filtering database entries.   
> It is clearly demonstrable that having smaller filtering database
> entries _would_ result in better scaling properties, consequently
> many people are interested in doing this.  
> 
> 	But increased LAN scaling in not a goal of the work we are doing
> here.  While this is not specifically spelled out in the charter,
> past discussions - including those leading up to creation of the
> charter - have avoided saying anything more than "shall not preclude
> improvements in LAN scaling characteristics" or "must have at least
> similar scaling properties to those currently available with existing
> LAN technology."      
> 
> 	Any requirement we might imagine _should_ be in the charter for
> improving LAN scalability, is conspicuously _not_ in the charter. 
> 
> 	Realistically, our solution must allow for greater LAN scaling
by
> some amount, or it is unlikely to be of interest to many network
> users/administrators and would, therefore, be unlikely to be
> deployed.   
> And the option to discard reachability information that is not
> needed, is one of the factors that may lead to this greater
> scalability.  
> 
> 	But it is non-sensical to argue that discarding information that
is
> not needed will cause problems when it is needed. 
> 
> 	And filtering database sizes is not realistically a bottle-neck
for
> current LAN scalability.  Convergence in STP is.  Link utilization is
> as well.  But in networks where routers have to be able to retain as
> many as 10s of millions of route entries, are filtering databases in
> "core RBridge" with 10s of thousands of MAC entries something we
> should really view as a serious scaling limitation?     

Please correct me if I incorrectly summarize the above.

1) Scaling the number of fowarding entries in the core is not a problem
that TRILL needs to solve.
2) Link utilization is a problem and TRILL needs to be concerned with
it.

If this is correct, it leads me to believe that you would advocate for 
1) Remove the destination RBridge from the shim, and just lookup the
destination MAC directly
2) Eliminate the need for the outer MAC header between two RBridges if
the link is point to point (quite likely in my opinion).

Again, I apologize for not keeping up with the latest discussions, but
have these ideas been discussed already?  If so, could you summarize the
outcome?

> 
> 2nd Issue - what is the importance of "optimizing" support for BCN?
> ==================================================================
> 
> 	BCN is likely to be important for a number of applications that
we
> care about.  But is it important enough that we should design an
> RBridge solution that is optimized for it, or is it sufficient that
> our solution is not significantly sub-optimal for these applications?
> 
> 	As Radia has already pointed out, an RBridge that finds itself
with
> a frame it must deliver, and no corresponding forwarding entry, will
> forward that frame on the ingress RBridge tree (corresponding to
> delivery of unknown MAC destination "flooding").  This is
> sub-optimal, but the choice that leads to an RBridge finding it needs
> to do this in the BCN case is (as I've said before) entirely an
> implementation choice.  Presumably, the implementer may choose to
> discard even BCN related MAC reachability if - as a trade-off
> decision - they believe that conservative retention of MAC
> reachability is desirable over optimal support of BCN.         
> 
> 	I personally favor the idea of forwarding BCN notifications on
the
> Ingress RBridge Tree - for those implementations that do not keep the
> appropriate MAC reachability information.  I favor this because:  
> 
> 	1) it is consistent with how bridges work now, therefore it is
> 	not a departure from "the devil we know,"

Last time looked at the BCN proposal, there could be a significant
amount of BCN traffic during congestion.  Flooding this traffic to ALL
RBridges seems like a bad idea if you are concerned with link
utilization.

> 
> 	2) it affects only implementations that are designed to discard
> 	potentially useful information in favor of reduced memory needs
> 	and
> 
> 	3) it is a generic solution related to Caitlin's earlier remarks
> 	with respect to the relative numbers of "core RBridges" and the
> 	likelihood that next-hop RBridges on the Ingress RBridge Tree
are
> 	actually going to have an entry for the "unknown MAC
destination"
> 	in the frame being flooded on the IRT.
> 
> 3rd Issue - why use tunneling if RBridges typically may be required
> to retain all MAC reachability information?
> ======================================= 
> 
> 	There are several reasons to do this, indpendent of any desire
to
> reduce memory requirements of RBridges. 
> 
> 	One is that 802.1X bridges on intermediate links are shielded
from
> exposure to MAC addresses on separate bridged LAN segements. 

I thought that was accomplished by adding the additional MAC header
between the two RBridges carrying their MACs.  The 802.1X bridges
connecting them will only learn these two RBridges MACs regardless of
whether there is a destination RBridge in the shim.
> 
> 	Another is that the forwarding entries in RBridges are based on
use
> of RBridge MAC addresses - which reduces the number of entries that
> will typically be used for forwarding by an intermediate RBridge.  

I'm missing the destinction between what you call the "memory
requirements RBridges", and "the number of entries that will typeically
be used for forwarding".  I was assuming these were the same thing.

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>
Date: Fri, 27 Oct 2006 13:35:44 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 7229

Radia,

	I don't know where the idea that we only need a 2-byte
nick-name comes from.  When did we change from the idea of using 
an MPLS (or MPLS-like) SHIM with 19 bits to represent specific
RBridges to using a completely different SHIM and only requiring 
16-bits of RBridge identification?

	That means we've determined that we need fewer identifiers
by at least a factor of 8.  Have we reached that conclusion?

	I know that this has been discussed, but I do not know that 
there has been any conclusion out of that discussion.  I do not
agree that this conclusion is correct, but have not said anything
because I did not see the idea gaining ground in serious mailing
list discussion.

	IMO, if we go to using both ingress and egress in the SHIM,
we need to go to a 2-word SHIM with a full 20 bits (each) used to 
identify both the ingress and the egress.

	If we did that, I would advocate a SHIM format like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                Egress                 |  CoS  |       TTL     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|               Ingress                 |         Rerved        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

It is possible to argu that it might be more efficient to have 
the Ingress "label" first, but the format would otherwise stay 
the same.  I would prefer it in the order shown.

	I also disagree with the notion that there's no advantage in
keeping an MPLS-like SHIM format.  I think that people who argue
that there is no advantage in having a very similar format, have
not yet discussed this with implementers.

--
Eric 

--> -----Original Message-----
--> From: Radia Perlman [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 12:32 PM
--> To: Gray, Eric
--> Cc: Wadekar, Manoj K; [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> I think the intent is that RBridges not keep endnode 
--> information they 
--> don't need to keep. So for instance,
--> if the BCN is being sent to an endnode in VLAN A, an intermediate 
--> RBridge that does not have a
--> VLAN A link would not know about the endnodes in VLAN A. It 
--> would know 
--> which links are in VLAN A,
--> so it wouldn't have to send the BCN to every link, but it 
--> wouldn't know 
--> which VLAN A link had the endnode.
--> And also, it would be reasonable to have a core of RBridges 
--> that don'e 
--> have any endnodes.
--> 
--> Potential ways of dealing with BCN, and their costs:
--> a) make all RBridges know about all endnodes, just in case 
--> they want to 
--> send a BCN
--> b) flood BCNs to more links than necessary (the links in 
--> the VLAN) when 
--> the endnode is unknown
--> to the RBridge initiating the BCN
--> c) include the ingress RBridge in the shim header.
--> 
--> I'm not that excited about BCN---it's a new functionality, 
--> who knows if 
--> it will ever be widely deployed,
--> etc. However, what's interesting about it is that it does present a 
--> reason why it is useful to have
--> ingress RBridge there. Which means we might stumble on 
--> other things in 
--> the future.
--> 
--> I was a bit uncomfortable about overloading a field with "sometimes 
--> ingress sometimes egress".
--> Since we changed over to nicknames so we only need 2 bytes 
--> to specify 
--> each RBridge (rather than
--> 6 bytes for each), I'm leaning to doing this. The cost is 
--> an extra 2 
--> bytes in the header, and not being
--> MPLS-like, but given that people have said being MPLS-like and not 
--> "exactly MPLS" is not that
--> much of an advantage, the cost then becomes 2 bytes, which 
--> seems worth 
--> it for what seems
--> like a more conventional design (encapsulating with both 
--> ingress and 
--> egress).
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Manoj,
--> >
--> >	Once again, the assumption that cores do not retain 
--> "addresses of
--> >all the end-stations in [the] whole cluster" is a 
--> "convenient assumption"
--> >for making the argument that another mechanism is required.
--> >
--> >	Currently, there would be no requirement for retaining all such 
--> >addresses as you have to be careful not to send BCN 
--> messages to those
--> >end-stations that don't support them.  Moreover, as 
--> mentioned previously,
--> >it is trivially easy to determine what address information 
--> should be kept.
--> >
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: [email-masked] 
--> >--> [mailto:[email-masked]] On Behalf Of 
--> Wadekar, Manoj K
--> >--> Sent: Friday, October 27, 2006 11:21 AM
--> >--> To: [email-masked]
--> >--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> >--> 
--> >--> Yes, for large clusters, if cores do not maintain addresses 
--> >--> of all the
--> >--> end-stations in whole cluster - then only way to get BCN 
--> >--> back to ES, is
--> >--> to send them to ingress rbridge-address and then have 
--> that ingress
--> >--> rbridge forward BCN to end station with appropriate ES address.
--> >--> 
--> >--> If so, ingress rbdridge address seems to be requirement to me.
--> >--> 
--> >--> Thanks,
--> >--> - Manoj
--> >--> 
--> >--> -----Original Message-----
--> >--> From: Silvano Gai [mailto:[email-masked]] 
--> >--> Sent: Friday, October 27, 2006 8:00 AM
--> >--> To: [email-masked]; Wadekar, Manoj K
--> >--> Cc: [email-masked]
--> >--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> >--> 
--> >--> 
--> >--> If the congestion is detected in the core of the TRILL 
--> >--> network, how do
--> >--> you signal back to the source host if you don't know 
--> which is the
--> >--> ingresss RBridge? 
--> >--> 
--> >--> You cannot look-up the inner MAC address, because in 
--> the core of the
--> >--> network you don't keep the inner MAC addresses in the 
--> >--> table. Correct?
--> >--> 
--> >--> This is a clear reason while you need the ingress 
--> RBridge address.
--> >--> 
--> >--> -- Silvano
--> >--> 
--> >--> > -----Original Message-----
--> >--> > From: [email-masked] 
--> >--> [mailto:[email-masked]]
--> >--> On
--> >--> > Behalf Of [email-masked]
--> >--> > Sent: Thursday, October 26, 2006 5:02 PM
--> >--> > To: Wadekar, Manoj K
--> >--> > Cc: [email-masked]
--> >--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> >--> > 
--> >--> > Hi Manoj,
--> >--> > 
--> >--> > I'm confused about BCN. Wouldn't congestion notification 
--> >--> need to go to
--> >--> the
--> >--> > original endnode source,
--> >--> > and not the ingress RBridge?
--> >--> > 
--> >--> > Radia
--> >--> > 
--> >--> 
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> [email-masked]
--> >--> http://mailman.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 10:33:56 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
Status: RO
Content-Length: 22660

these are my comments:

Sgai 1> The document assume that in spanning tree there are transient
loops. THIS IS ABSOLUTELY FALSE. Spanning tree never causes a loop, not
even during a transition. The document assumes that, since in ST there
are transient loops, it is OK to have transient loops in TRILL and that
they only need to be mitigated through a TTL.

The TTL solution is OK for unicast traffic, since unicast traffic does
not replicate while in the loop and eventually the TTL will drop it or
the network will converge and the frame will be delivered.

The TTL solution is NOT OK for multicast/broadcast traffic, since this
traffic replicates while in the loop causing a broadcast/multicast
storm.

Due to the fact that switches replicate in HW and have low latency, in a
meshed network, even with a moderate TTL, in few hundreds microseconds,
billion of frames will be part of the storm.

These billions of frames will be queue everywhere, causing hosts to
crash, but especially they will saturate the queue of the switch CPU.
The CPU quickly becomes incapable of dealing with its queue and
incapable of receiving control frames to break the loop. 

Anyhow, ISIS will react in hundreds of milliseconds, while the storm
will reach its peak in hundreds of microseconds.

Customers that have seen a broadcast storm, due to a bogus ST
implementation or a misconfiguration, don't want to see a second one.

A solution based on TTL must therefore have a strong requirement for
dedicated buffers/paths for the control frames to reach the CPU, so that
it is guarantee that control frames will eventually break the loop. 

I don't think it is acceptable to have temporary loop for broadcast
multicast, even if they are mitigated by TTL. An interlock mechanism
similar to ST must be used for multicast/broadcast.

I ask for a strong requirement that says: "TRILL MUST avoid
multicast/broadcast storms"

Sgai 2> ST provides symmetrical forwarding, i.e. the path from A to B is
the reverse of the path from B to A. Is this a requirement for TRILL?

Sgai 3> the terminology used in this draft is not the one used in IEEE
standards. This makes it difficult to understand what certain sentences
really mean. Concepts like autolearning and caches are not IEEE
concepts.

Sgai 4> There is no mention of the applicability of other important IEEE
standards/WG/Study Groups, e.g.
- 802.3ad-2000, Link Aggregation.
- 802.1ah - Provider Backbone Bridges
- 802.1aq - Shortest Path Bridging
- 802.1au - Congestion Notification
- 802.1ad - Provider Bridges 
- 802.1AE - MAC Security
- 802.3ar - Congestion Management Task Force.
- 802.3as - Frame Expansion Task Force.
I think this document needs to clearly state the position of the WG with
respect to these projects.

Sgai 5> I also think there need to be a mention of the applicability of
important industrial efforts:
- NIC Teaming
- uplinkfast
- split-MLT
- Q in Q
All these are widely deployed in all datacenters/enterprises. I think
this document needs to clearly state the position of the WG with respect
to these de fact standards.

Sgai 6> Many customers look at TRILL as a backbone network. They would
like to connect their current switches to the TRILL backbone using
Etherchannel  and connecting the member links on different RBridges for
High availability. Is this a requirement? In general which is the
relation between Etherchannel and TRILL?

Sgai 7> Does TRILL work properly if Ethernet is deployed with Pause
enabled?

Additional comments in the text marked as sgai N> where N is the number
of the comment.

For all these reasons, but in particular for <sgai 1> I think this
document needs another major revision before it can complete the WG last
call.

-- Silvano

----------------------------------------------------------

2.5. Problems Not Addressed 

   There are other challenges to deploying Ethernet subnets that are not

   addressed in this document. These include: 

   o  increased Ethernet link subnet scale 

   o  increased node relocation 

   o  Ethernet link subnet management protocol security 

   o  flooding attacks on a Ethernet link subnet 

   Solutions to TRILL are not intended to support deployment of 
   increasingly larger scales of Ethernet link subnets than current 
   broadcast domains can support (e.g., around 1,000 end-hosts in a 
   single bridged LAN of 100 bridges, or 100,000 end-hosts inside 1,000 
   VLANs served by 10,000 bridges). 

Sgai 8> I don't know were these number come from, but with 256/512 ports
Ethernet switches available, it does not take 10,000 bridges to reach
100,000 nodes. I also don't understand if the mention of 1,000 VLANs is
intended as a limit. As I mentioned in previous emails, many customers
don't have enough of 4,000 VLANs and deploy private VLANs. All the
implementations I know about hash the pair (MAD-address, VLAN} into the
filtering database and the only limitation is the size of the filtering
database.

   Similarly, solutions to TRILL are not intended to address link layer 
   node migration, which can complicate the caches in learning bridges. 

Sgai 9> IEEE 802.1D does not contain the word "cache". Are you referring
to the filtering database? Why are filtering databases complicated by
node migration? I think that TRILL should provide a solution to node
migration that is as good as IEEE 802.1D or better.

   Similar challenges exist in the ARP protocol, where link layer 
   forwarding is not updated appropriately when nodes move to ports on 
   other bridges. Again, the compartmentalization available in network 
   routing, like that of network layer ASes, can help hide the effect of

   migration. That is a side effect, however, and not a primary focus of

   this work. 

Sgai 10> I am not sure what the previous sentence means, I will remove
it.

   Current link control plane protocols, including Ethernet link subnet 
   management (STP) and link/network integration (ARP), are vulnerable 
   to a variety of attacks. Solutions to TRILL are not intended to 
   directly address these vulnerabilities. Similar attacks exist in the 
   data plane, e.g., source address spoofing, single address traffic 
   attacks, traffic snooping, and broadcast flooding. TRILL solutions do

   not address any of these issues, although it is critical that they do

   not introduce new vulnerabilities in the process (see Section 5). 

3. Desired Properties of Solutions to TRILL 

   This section describes some of the desirable or required properties 
   of any system that would solve the TRILL problems, independent of the

   details of such an architecture. Most of these are based on retaining

   useful properties of bridges, or maintaining those properties while 
   solving the problems listed in Section 2. 

3.1. No Change to Link Capabilities 

   There must be no change to the service that Ethernet subnets already 
   provide as a result of deploying a TRILL solution. Ethernet supports 
   unicast, broadcast, and multicast natively. Although network 
   protocols, notably IP, can tolerate link layers that do not provide 
   all three, it would be useful to retain the support already in place 
   [7]. 

Sgai 11> This requirement needs to be a "must". It also needs to say
that TRILL need to work also for non-IP protocols,

Zeroconf, as well as existing bridge autoconfiguration, are 
   dependent on broadcast as well. 

   Current Ethernet ensures in-order delivery and no duplicated packets 
   under normal operation (excepting transients during reconfiguration).

Sgai 12> outside a marginal corner case in RSTP that affects only
in-order delivery, these two properties are also guarantee during
reconfiguration. There are no transient loops in ST, see <sgai 1>

   These criteria apply in varying degrees to the different variants of 
   Ethernet, e.g., basic Ethernet up through basic VLAN (802.1Q) ensures
 
Sgai 13> IEEE 802.1Q is not involved in this; it is a property of IEEE
802.1D.

   that all packets between two link addresses have both properties, but

   protocol/port VLAN (802.1V) ensures this only for packets with the 
   same protocol and port. [JUST CHECKING - OR AM I MISREADING WHAT 
   802.1V DOES?] 
Sgai 14> this needs to be resolved

Touch & Perlman         Expires April 22, 2007                 [Page 8] 

Internet-Draft     TRILL: Problem and Applicability        October 2006 

   There are subtle implications to such a requirement. Bridge 
   autolearning 

sgai 15> autolearning is not a well known concept, not present in IEEE
802.1D

already is susceptible to moving nodes between ports, 
   because previously learned associations between port and link address

   change. A TRILL solution could be similarly susceptible to such 
   changes. 

3.2. Zero Configuration and Zero Assumption 

   Both bridges and hubs are zero configuration devices; hubs having no 
   configuration at all, and bridges being automatically self-
   configured. Bridges are further zero-assumption devices, unlike hubs.

   Bridges can be interconnected in arbitrary topologies, without regard

   for cycles or even self-attachment. STP removes the impact of cycles 
   automatically, and port autolearning reduces unnecessary broadcast of

   unicast traffic. 

Sgai 16> port autolearning is not an IEEE concept. 

   A TRILL solution should strive to have similar zero configuration, 
   zero assumption operation. This includes having TRILL solution 
   components automatically discover other TRILL solution components and

   organize themselves, as well as to configure that organization for 
   proper operation (plug-and-play). It also includes zero configuration

   backward compatibility with existing bridges and hubs, which may 
   include interacting with some of the bridge protocols, such as STP. 

   VLANs add a caveat to zero configuration; a TRILL solution should 
   support automatic use of a default VLAN (like non-VLAN bridges), but 
   should require explicit configuration where the VLANS require them as

   well. 

Sgai 17> 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. See also <sgai 26>.

   Autoconfiguration extends to optional services, such as multicast 
   support via IGMP snooping, broadcast support via serial copy, and 
   supporting multiple VLANs.  

Sgai 18> what about VLAN pruning?

3.3. Forwarding Loop Mitigation 

   Spanning tree avoids forwarding loops by construction, although 
   transient loops can occur, e.g., via the appearance of a new link. 

Sgai 19> this statement is incorrect. ST does not have transient loops.
See <sgai 1>
  
   Solutions to TRILL are intended to use adapted network layer routing 
   protocols which may introduce transient loops during routing 
   convergence. TRILL solutions thus need support for mitigating the 
   effect of such routing loops. 

   In the Internet, loop mitigation is provided by a decrementing 
   hopcounts (TTL); in other networks, packets include a trace 
   (serialized or unioned) of visited nodes [1]. These mechanisms 
   (respectively) limit the impact of loops or detect them explicitly. A

   mechanism with similar effect should be included in TRILL solutions. 

Sgai 20> see <sgai 1>

 
Touch & Perlman         Expires April 22, 2007                 [Page 9] 

Internet-Draft     TRILL: Problem and Applicability        October 2006 

   [QUESTION: anyone have a good reference for serialized or union 
   traces - or better names for them?] 

sgai 21> this needs to be resolved

3.4. Spanning Tree Management 

   In order to address convergence under reconfiguration and robustness 
   to link interruption (Sections 2.2 and 2.3), participation in the STP

   must be carefully managed. The goal is to provide the desired 
   stability of the TRILL solution and of the entire Ethernet link 
   subnet while not interfering with the operation of STP of the 
   Ethernet on which the TRILL resides. This may involve TRILL solutions

   participating in the STP, where the protocol is used for TRILL might 
   dampen interactions with STP, or it may involve severing the STP into

   separate STPs on 'stub' external Ethernet link subnet segments. 

   A requirement is that a TRILL solution must not require modifications

   or exceptions to the existing spanning tree protocols (STP, MSTP).
 
Sgai 22> does this include RSTP? More in general this document does not
describe requirements for the interaction of TRILL with ST. 

   [we need pictures here; to appear] 

Sgai 23> this needs to be resolved

3.5. Multiple Attachments 

   In STP, a single NIC with multiple attachments to a single spanning 
   tree will always only get traffic over one of the two attachment 
   points, 

sgai 24> Not clear how a NIC in the host can have multiple attachments.
If you are referring to NIC teaming, what you says is false.

TRILL allows load sharing between the attachment points. 
   Further, TRILL must manage multicast and broadcast traffic so as not 
   to create feedback loops on Ethernet segments which are attached at 
   multiple TRILL access points. 

   [NOTE: this might be omitted, as it has not been shown to be a 
   problem with STP]. 

Sgai 25> this needs to be resolved

3.6. VLAN Issues 

   A TRILL solution should support multiple VLANs (802.1Q, 802.1V, and 
   802.1S). This may involve ignorance, just as many bridge devices do 
   not participate in the VLAN protocols. It may alternately support 
   direct VLAN support, e.g., by the use of separate TRILL routing 
   protocol instances to separate traffic for each VLAN traversing a 
   TRILL solution. 

Sgai 26> See also <sgai 17>. I am not sure what the first two sentences
are trying to say, the last part needs to be expanded and clearly
differentiated from the discussion related to the section 3.2. I propose
to call these VLANs the "outer VLANs" and the VLANs discussed in 3.2 the
"inner VLANs" (with reference to the position of the tag in the frame.

3.7. Equivalence 

   As with any extension to an existing architecture, it would be useful

   - though not strictly necessary - to be able to describe or consider 
   a TRILL solution as a model of an existing link layer component. Such

   equivalence provides a validation model for the architecture, and a 

Touch & Perlman         Expires April 22, 2007                [Page 10] 

Internet-Draft     TRILL: Problem and Applicability        October 2006 

   way for users to predict the effect of the use of a TRILL solution on

   a deployed Ethernet. In this case, 'user' refers to users of the 
   Ethernet protocol, whether at the host (data segments), bridge (ST 
   control segments), or VLAN (VLAN control). 

   This provides a sanity check, i.e., "we got it right if we can 
   replace a TRILL solution with an X" (where "X" might be a single 
   bridge, a hub, or some other link layer abstraction). It does not 
   matter whether "X" can be implemented on the same scale as the 
   corresponding TRILL solution. It also does not matter if it can - 
   there may be utility to deploying the TRILL solution components 
   incrementally, in ways that a single "X" could not be installed. 

   For example, if TRILL solution were equivalent to a single 802.1D 
   bridge, it would mean that the TRILL solution would - as a whole - 
   participate in the STP. This need not require that TRILL solution 
   would propagate STP, any more than a bridge need do so in its on-
   board control. It would mean that the solution would interact with 
   BPDUs at the edge, where the solution would - again, as a whole - 
   participate as if a single node in the spanning tree. Note that this 
   equivalence is not required; a solution may act as if an 802.1 hub, 
   or may not have a corresponding equivalent link layer component at 
   all. 

3.8. Optimizations 

   There are a number of optimizations that may be applied to TRILL 
   solutions. These must be applied in a way that does not affect 
   functionality as a tradeoff for increased performance. Such 
   optimizations address broadcast and multicast frame distribution, 
   VLAN support, and snooping of ARP and IPv6 neighbor discovery. 

   [NOTE: need to say more here.] 

Sgai 27> this needs to be resolved

3.9. Internet Architecture Issues 

   TRILL solutions are intended to have no impact on the Internet 
   network layer architecture. In particular, the Internet and higher 
   layer headers should remain intact when traversing a TRILL solution, 
   just as they do when traversing any other link subnet technologies. 
   This means that the IP TTL field cannot be co-opted for forwarding 
   loop mitigation, as it would interfere with the Internet layer 
   assuming that the link subnet was reachable with no changes in TTL 
   (Internet TTLs are changed only at routers, as per RFC 1812, and even

   if IP TTL were considered, TRILL is expected to support non-IP 
   payloads, and so requires a separate solution anyway) [1]. 

 Sgai 28> The requirement must be: "TRILL must support non-IP 
   Payloads"
 
Touch & Perlman         Expires April 22, 2007                [Page 11] 

Internet-Draft     TRILL: Problem and Applicability        October 2006 

   TRILL solutions should also have no impact on Internet routing or 
   signaling, which also means that broadcast and multicast, both of 
   which can pervade an entire Ethernet link subnet, must be able to 
   transparently pervade a TRILL solution. Changing how either of these 
   capabilities behaves would have significant effects on a variety of 
   protocols, including RIP (broadcast), RIPv2 (multicast), ARP 
   (broadcast), IPv6 neighbor discovery (multicast), etc. 

   Note that snooping of network layer packets may be useful, especially

   for certain optimizations. These include snooping multicast control 
   plane packets (IGMP) to tune link multicast to match the network 
   multicast topology, as is already done in existing smart switches 
   [2]. This also includes snooping IPv6 neighbor discovery messages to 
   assist with governing TRILL solution edge configuration, as is the 
   case in some smart learning bridges [9]. Other layers may similarly 
   be snooped, notably ARP packets, for similar reasons for IPv4 [13]. 

   [Need a ref for the router-router 'igmp' protocol] 

Sgai 29> this needs to be resolved

4. Applicability 

   As might be expected, TRILL solutions are intended to be used to 
   solve the problems described in Section 2. However, not all such 
   installations are appropriate environments for such solutions. This 
   section outlines the issues in the appropriate use of these 
   solutions. 

   TRILL solutions are intended to address problems of path efficiency 
   and stability within a single Ethernet link subnet. Like bridges, 
   individual TRILL solution components may find other TRILL solution 
   components within a single Ethernet link subnet and aggregate into a 
   single TRILL solution.  

   TRILL solutions are not intended to span separate Ethernet link 
   subnets where interconnected by network layer (e.g., router) devices,

   except via link layer tunnels that are in place prior to their 
   deployment, where such tunnels render the distinct subnet 
   undetectably equivalent from a single Ethernet link subnet. 

   A currently open question is whether a single Ethernet link subnet 
   should contain only one TRILL solution instance, either of necessity 
   of architecture or utility. 

Sgai 30> this needs to be resolved

Multiple TRILL solutions, like Internet 
   ASes, may allow TRILL routing protocols to be partitioned in ways 
   that help their stability, but this may come at the price of needing 
   the TRILL solutions to participate more fully as nodes (each modeling

   a bridge) in the Ethernet link subnet STP. Each architecture solution

   should decide whether multiple TRILL solutions are supported within a

Touch & Perlman         Expires April 22, 2007                [Page 12] 

Internet-Draft     TRILL: Problem and Applicability        October 2006 

   single Ethernet link subnet and mechanisms should be included to 
   enforce whatever decision is made. 

   TRILL solutions are not intended to address scalability limitations 
   in bridged subnets. Although there may be scale benefits of other 
   aspects of solving TRILL problems, e.g., of using network layer 
   routing to provide stability under link changes or intermittent 
   outages, this is not a focus of this work. 

   As also noted earlier, TRILL solutions are not intended to address 
   security vulnerabilities in either the data plane or control plane of

   the link layer. This means that TRILL solutions should not limit 
   broadcast frames, ARP requests, or spanning tree protocol messages 
   (if such are interpreted by the TRILL solution or solution edge). 

5. Security Considerations 

   TRILL solutions should not introduce new vulnerabilities compared to 
   traditional bridged subnets.  

   TRILL solutions are not intended to be a solution to Ethernet link 
   subnet vulnerabilities, including spoofing, flooding, snooping, and 
   attacks on the link control plane (STP, flooding the learning cache) 
   and link-network control plane (ARP). Although TRILL solutions are 
   intended to provide more stable routing than STP, this stability is 
   limited to performance, and the subsequent robustness is intended to 
   address non-malicious events. 

   There may be some side-effects to the use of TRILL solutions that can

   provide more robust operation under certain attacks, such as those 
   interrupting or adding link service, but TRILL solutions should not 
   be relied upon for such capabilities. 

   Finally, TRILL solutions should not interfere with other protocols 
   intended to address these vulnerabilities, such as those under 
   development to secure IPv6 neighbor discovery.  

   [need a ref for secure ipv6 nd] 

Sgai 31> this needs to be resolved

6. IANA Considerations 

   This document has no IANA considerations.  

   This section should be removed by the RFC Editor prior to final 
   publication. 

 
Touch & Perlman         Expires April 22, 2007                [Page 13] 

Internet-Draft     TRILL: Problem and Applicability        October 2006 

7. Conclusions 

   (TBA) 

Sgai 32> this needs to be resolved

From: "Gray, Eric" <[email-masked]>
To: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 27 Oct 2006 13:13:13 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 5880

Larry,

	The phrase "one of the advantages" is key here.
                  +++++++++++++++++++++

	We're complicating discussion by combining issues and trying
to address them all at the same time.

1st Issue - Scale advantages of not retaining end-station MAC
information in "core RBridges"?
==============================

	The sole advantage that would derive from having a requirement
that so-called "core RBridges" do not need to retain MAC reachability 
information would be to increase the scale of LAN sizes by reducing 
the memory requirements associated with filtering database entries.  
It is clearly demonstrable that having smaller filtering database
entries _would_ result in better scaling properties, consequently
many people are interested in doing this.

	But increased LAN scaling in not a goal of the work we are doing 
here.  While this is not specifically spelled out in the charter, past
discussions - including those leading up to creation of the charter -
have avoided saying anything more than "shall not preclude improvements
in LAN scaling characteristics" or "must have at least similar scaling
properties to those currently available with existing LAN technology."

	Any requirement we might imagine _should_ be in the charter for
improving LAN scalability, is conspicuously _not_ in the charter.

	Realistically, our solution must allow for greater LAN scaling
by some amount, or it is unlikely to be of interest to many network 
users/administrators and would, therefore, be unlikely to be deployed.
And the option to discard reachability information that is not needed,
is one of the factors that may lead to this greater scalability.

	But it is non-sensical to argue that discarding information that
is not needed will cause problems when it is needed.

	And filtering database sizes is not realistically a bottle-neck
for current LAN scalability.  Convergence in STP is.  Link utilization
is as well.  But in networks where routers have to be able to retain
as many as 10s of millions of route entries, are filtering databases in
"core RBridge" with 10s of thousands of MAC entries something we should 
really view as a serious scaling limitation?

2nd Issue - what is the importance of "optimizing" support for BCN?
==================================================================

	BCN is likely to be important for a number of applications that
we care about.  But is it important enough that we should design an
RBridge solution that is optimized for it, or is it sufficient that
our solution is not significantly sub-optimal for these applications?

	As Radia has already pointed out, an RBridge that finds itself
with a frame it must deliver, and no corresponding forwarding entry,
will forward that frame on the ingress RBridge tree (corresponding to
delivery of unknown MAC destination "flooding").  This is sub-optimal,
but the choice that leads to an RBridge finding it needs to do this
in the BCN case is (as I've said before) entirely an implementation
choice.  Presumably, the implementer may choose to discard even BCN
related MAC reachability if - as a trade-off decision - they believe 
that conservative retention of MAC reachability is desirable over 
optimal support of BCN.

	I personally favor the idea of forwarding BCN notifications on
the Ingress RBridge Tree - for those implementations that do not keep
the appropriate MAC reachability information.  I favor this because:

	1) it is consistent with how bridges work now, therefore it is 
	not a departure from "the devil we know,"

	2) it affects only implementations that are designed to discard
	potentially useful information in favor of reduced memory needs
	and

	3) it is a generic solution related to Caitlin's earlier remarks
	with respect to the relative numbers of "core RBridges" and the
	likelihood that next-hop RBridges on the Ingress RBridge Tree are
	actually going to have an entry for the "unknown MAC destination"
	in the frame being flooded on the IRT.

3rd Issue - why use tunneling if RBridges typically may be required to
retain all MAC reachability information?
=======================================

	There are several reasons to do this, indpendent of any desire
to reduce memory requirements of RBridges.

	One is that 802.1X bridges on intermediate links are shielded
from exposure to MAC addresses on separate bridged LAN segements.

	Another is that the forwarding entries in RBridges are based on
use of RBridge MAC addresses - which reduces the number of entries 
that will typically be used for forwarding by an intermediate RBridge.

--
Eric

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 12:07 PM
--> To: Gray, Eric; Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> Eric,
--> 
--> I thought one of the advantages of RBridges was that the core of the
--> network did not have to maintain forwarding tables for every host MAC
--> address in the network. If we assume they do, they why should we bother
--> to use RBridge addresses for forwarding at all?  You could essentially
--> program host routes for every destination MAC.
--> 
-->  - Larry
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 8:44 AM:
--> 
--> > Manoj,
--> > 
--> > 	Once again, the assumption that cores do not retain "addresses
--> > of all the end-stations in [the] whole cluster" is a "convenient
--> > assumption" for making the argument that another mechanism is
required.
--> > 
--> > 	Currently, there would be no requirement for retaining all such
--> > addresses as you have to be careful not to send BCN messages to those
--> > end-stations that don't support them.  Moreover, as mentioned
previously, 
--> > it is trivially easy to determine what address information should be 
--> > kept.    
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 09:52:42 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 2199

[email-masked] wrote:
> Interesting. In theory, it is possible to send a packet to an
> unknown destination MAC by sending through the ingress
> RBridge tree rooted at the RBridge that decided to send the
> BCN (or rooted at the Designated RBridge on the link on which
> some legacy bridge decided to send the BCN).
> 
> But if there are going to lots of BCN's, then it would cut
> down on traffic to know the original ingress RBridge, since
> the BCN's would never needed to be sent everywhere---just
> direct to the ingress RBridge.
> 
> Just to make sure I do understand though, the intent is that
> the BCN does need to get to the original source of the
> packet, and the ingress RBridge of the original packet will
> only forward the BCN to the source, right?
> 
> Radia
> 
> 
> 

My analasys is that an 802.1au-capable RBridge could send
a BCN in three different ways:

1) RBridge encapsulated to the original source c/o its 
   source RBridge, which it already knew. The egress RBRidge
   would typically have this information.
2) non-RBridge encapsulated is sent to the outer source,
   which is the *prior* rbridge and not necessarily the
   source rbridge, and we specify that 802.1au-capable
   RBridges act as proxies for BCNs received that are
   not RBridge encapsulated.
3) RBridge encapsulated to the original source, but with
   an unknown destination RBridge.

I believe that #2 is required anyway, to deal with 802.1au
bridges that are not RBridges.

It is also worht pointing out that unless there are *four*
RBridges in the "rbridge path" that the immediate prior
rbridge to any core rbridge *will* be the source rbridge.

I believe these three options provide adequate solutions
to this problem without requiring the addition of the
source rbridge to the frame. But it does suggest that
the header format should be designed so that it stacks
efficiently with 802.1a headers.

Standardizing the 802.1au proxy role is also important
because otherwise you would have Rate Limited Frame
wrappers around RBridge encapsulation. I believe it 
is far better to ensure that the BCN is forwarded
to the original source so that RBridge encapsulates
the Rate Limited Frame.

Date: Fri, 27 Oct 2006 09:31:57 -0700
From: Radia Perlman <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 4522

I think the intent is that RBridges not keep endnode information they 
don't need to keep. So for instance,
if the BCN is being sent to an endnode in VLAN A, an intermediate 
RBridge that does not have a
VLAN A link would not know about the endnodes in VLAN A. It would know 
which links are in VLAN A,
so it wouldn't have to send the BCN to every link, but it wouldn't know 
which VLAN A link had the endnode.
And also, it would be reasonable to have a core of RBridges that don'e 
have any endnodes.

Potential ways of dealing with BCN, and their costs:
a) make all RBridges know about all endnodes, just in case they want to 
send a BCN
b) flood BCNs to more links than necessary (the links in the VLAN) when 
the endnode is unknown
to the RBridge initiating the BCN
c) include the ingress RBridge in the shim header.

I'm not that excited about BCN---it's a new functionality, who knows if 
it will ever be widely deployed,
etc. However, what's interesting about it is that it does present a 
reason why it is useful to have
ingress RBridge there. Which means we might stumble on other things in 
the future.

I was a bit uncomfortable about overloading a field with "sometimes 
ingress sometimes egress".
Since we changed over to nicknames so we only need 2 bytes to specify 
each RBridge (rather than
6 bytes for each), I'm leaning to doing this. The cost is an extra 2 
bytes in the header, and not being
MPLS-like, but given that people have said being MPLS-like and not 
"exactly MPLS" is not that
much of an advantage, the cost then becomes 2 bytes, which seems worth 
it for what seems
like a more conventional design (encapsulating with both ingress and 
egress).

Radia

Gray, Eric wrote:

>Manoj,
>
>	Once again, the assumption that cores do not retain "addresses of
>all the end-stations in [the] whole cluster" is a "convenient assumption"
>for making the argument that another mechanism is required.
>
>	Currently, there would be no requirement for retaining all such 
>addresses as you have to be careful not to send BCN messages to those
>end-stations that don't support them.  Moreover, as mentioned previously,
>it is trivially easy to determine what address information should be kept.
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]] On Behalf Of Wadekar, Manoj K
>--> Sent: Friday, October 27, 2006 11:21 AM
>--> To: [email-masked]
>--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
>--> 
>--> Yes, for large clusters, if cores do not maintain addresses 
>--> of all the
>--> end-stations in whole cluster - then only way to get BCN 
>--> back to ES, is
>--> to send them to ingress rbridge-address and then have that ingress
>--> rbridge forward BCN to end station with appropriate ES address.
>--> 
>--> If so, ingress rbdridge address seems to be requirement to me.
>--> 
>--> Thanks,
>--> - Manoj
>--> 
>--> -----Original Message-----
>--> From: Silvano Gai [mailto:[email-masked]] 
>--> Sent: Friday, October 27, 2006 8:00 AM
>--> To: [email-masked]; Wadekar, Manoj K
>--> Cc: [email-masked]
>--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
>--> 
>--> 
>--> If the congestion is detected in the core of the TRILL 
>--> network, how do
>--> you signal back to the source host if you don't know which is the
>--> ingresss RBridge? 
>--> 
>--> You cannot look-up the inner MAC address, because in the core of the
>--> network you don't keep the inner MAC addresses in the 
>--> table. Correct?
>--> 
>--> This is a clear reason while you need the ingress RBridge address.
>--> 
>--> -- Silvano
>--> 
>--> > -----Original Message-----
>--> > From: [email-masked] 
>--> [mailto:[email-masked]]
>--> On
>--> > Behalf Of [email-masked]
>--> > Sent: Thursday, October 26, 2006 5:02 PM
>--> > To: Wadekar, Manoj K
>--> > Cc: [email-masked]
>--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
>--> > 
>--> > Hi Manoj,
>--> > 
>--> > I'm confused about BCN. Wouldn't congestion notification 
>--> need to go to
>--> the
>--> > original endnode source,
>--> > and not the ingress RBridge?
>--> > 
>--> > Radia
>--> > 
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://mailman.postel.org/mailman/listinfo/rbridge
>--> 
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 09:17:58 -0700
From: "Wadekar, Manoj K" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 2931

Hi Radia,

	Yes, the intent is that BCN needs to go to the source that is
contributing to congestion. I am trying to make sure that in the
deployments (very real, IMHO) where cores are not maintaining all ES
addresses in FDB, BCNs can still be delivered to the ES by ingress
Rbridge.

Thanks,
- Manoj

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 9:04 AM
To: Wadekar, Manoj K
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN

Interesting. In theory, it is possible to send a packet to an unknown 
destination MAC by sending
through the ingress RBridge tree rooted at the RBridge that decided to 
send the BCN (or rooted
at the Designated RBridge on the link on which some legacy bridge 
decided to send the BCN).

But if there are going to lots of BCN's, then it would cut down on 
traffic to know the original
ingress RBridge, since the BCN's would never needed to be sent 
everywhere---just direct to
the ingress RBridge.

Just to make sure I do understand though, the intent is that the BCN 
does need to get to the
original source of the packet, and the ingress RBridge of the original 
packet will only forward the
BCN to the source, right?

Radia

Wadekar, Manoj K wrote:

>Yes, for large clusters, if cores do not maintain addresses of all the
>end-stations in whole cluster - then only way to get BCN back to ES, is
>to send them to ingress rbridge-address and then have that ingress
>rbridge forward BCN to end station with appropriate ES address.
>
>If so, ingress rbdridge address seems to be requirement to me.
>
>Thanks,
>- Manoj
>
>-----Original Message-----
>From: Silvano Gai [mailto:[email-masked]] 
>Sent: Friday, October 27, 2006 8:00 AM
>To: [email-masked]; Wadekar, Manoj K
>Cc: [email-masked]
>Subject: RE: [rbridge] Ingress Rbridge address and BCN
>
>
>If the congestion is detected in the core of the TRILL network, how do
>you signal back to the source host if you don't know which is the
>ingresss RBridge? 
>
>You cannot look-up the inner MAC address, because in the core of the
>network you don't keep the inner MAC addresses in the table. Correct?
>
>This is a clear reason while you need the ingress RBridge address.
>
>-- Silvano
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>    
>>
>On
>  
>
>>Behalf Of [email-masked]
>>Sent: Thursday, October 26, 2006 5:02 PM
>>To: Wadekar, Manoj K
>>Cc: [email-masked]
>>Subject: Re: [rbridge] Ingress Rbridge address and BCN
>>
>>Hi Manoj,
>>
>>I'm confused about BCN. Wouldn't congestion notification need to go to
>>    
>>
>the
>  
>
>>original endnode source,
>>and not the ingress RBridge?
>>
>>Radia
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 09:07:19 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 927

Eric,

I thought one of the advantages of RBridges was that the core of the
network did not have to maintain forwarding tables for every host MAC
address in the network. If we assume they do, they why should we bother
to use RBridge addresses for forwarding at all?  You could essentially
program host routes for every destination MAC.

 - Larry

Gray, Eric wrote on Friday, October 27, 2006 8:44 AM:

> Manoj,
> 
> 	Once again, the assumption that cores do not retain "addresses
of
> all the end-stations in [the] whole cluster" is a "convenient
> assumption"  
> for making the argument that another mechanism is required.
> 
> 	Currently, there would be no requirement for retaining all such
> addresses as you have to be careful not to send BCN messages to those
> end-stations that don't support them.  Moreover, as mentioned
> previously, it is trivially easy to determine what address
> information should be kept.    

From: "Gray, Eric" <[email-masked]>
To: [email-masked]
Date: Fri, 27 Oct 2006 12:07:16 -0400
Cc: [email-masked]
Subject: Re: [rbridge] How many trees, and per what
Status: RO
Content-Length: 3682

Radia,

	What you say relative to the use of a "single Ingress Tree" is
correct, but we have not (and MUST NOT) preclude the use of VLANs in
interconnecting RBridges.

	Since the imposition of VLANs over an RBridge network creates
overlay VLANs that are not congruent, the creation of "ingress trees"
applies to each logically separate VLAN in use to connect RBridges.
Note that this requires no special behavior in RBridges, and thus is
a complicating factor in implementations, not in protocol design.

	What I mean is that 802.1Q encapsulation of RBridge "tunneled"
traffic is (and MUST be) as valid an encapsulation as other forms of
Ethernet encapsulation of RBridge "tunneled" traffic.  Consequently
(and without complicating RBridge protocols), it is certainly within
the range of possibility to configure VLAN information in RBridges 
such that there is a VLAN containing all RBridges with a common need
to deliver multicast traffic.

	I am unclear as to how this is semantically distinct from the
use of FTAGs - which would describe the same connectivity set and 
also require configuration - for support of "shared trees."

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of 
--> [email-masked]
--> Sent: Thursday, October 26, 2006 7:52 PM
--> To: Sanjay Sane (sanjays)
--> Cc: [email-masked]
--> Subject: [rbridge] How many trees, and per what
--> 
--> There is considerable confusion (certainly by me, and I'm 
--> sure others) at this point. Let me start a new thread to
--> specificallly discuss which trees should be computed.
--> 
--> The WG consensus seemed to be to compute per-ingress trees 
--> rather than
--> shared trees. For several reasons, e.g.,
--> 
--> a) the number of packet hops to deliver a packet to just a 
--> subset of links (as would be the case with
--> a packet only going to links for a particular VLAN, or for 
--> an IP multicast that is only going to links with
--> registered receivers plus IP multicast routers) can be a 
--> lot more than necessary if we are not using
--> a per-ingress tree, and instead using a shared tree
--> 
--> b) a few packets in a conversation from S to D are more 
--> likely to get out of order if at first D is unknown, and
--> the packet is sent on a shared tree, and then when D is 
--> found, going directly, since the path from S to D might
--> be much longer in the shared tree than the tree rooted at 
--> S's Designated Rbridge
--> 
--> It is true that it would take less memory and computation 
--> to use a shared tree, even multiple per-F-tag shared
--> trees, but they would not have the properties a) and b) above.
--> 
--> So I believe if we do per-F-tag trees, we will be 
--> multiplying the number of trees by F-tag, and computing
--> (# of Designated Rbridges) * (# of F-tag values).
--> 
--> I don't believe we should revisit the per-ingress trees. 
--> Especially if the reason is to make better use of
--> bandwidth by using F-tags, since using per-ingress trees 
--> certainly will cut down on bandwidth use for
--> IP multicast packets and unknown/multicast VLAN-tagged packets.
--> 
--> So the question is whether we should multiply the number of 
--> trees by the number of F-tag values. And if so,
--> how many F-tag values are really needed.
--> 
--> I *think* the only purpose of using multiple F-tag values 
--> and trees is to spread traffic around, and engineer traffic
--> for certain classes of traffic. 
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 27 Oct 2006 09:03:44 -0700
From: Radia Perlman <[email-masked]>
To: "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 2411

Interesting. In theory, it is possible to send a packet to an unknown 
destination MAC by sending
through the ingress RBridge tree rooted at the RBridge that decided to 
send the BCN (or rooted
at the Designated RBridge on the link on which some legacy bridge 
decided to send the BCN).

But if there are going to lots of BCN's, then it would cut down on 
traffic to know the original
ingress RBridge, since the BCN's would never needed to be sent 
everywhere---just direct to
the ingress RBridge.

Just to make sure I do understand though, the intent is that the BCN 
does need to get to the
original source of the packet, and the ingress RBridge of the original 
packet will only forward the
BCN to the source, right?

Radia

Wadekar, Manoj K wrote:

>Yes, for large clusters, if cores do not maintain addresses of all the
>end-stations in whole cluster - then only way to get BCN back to ES, is
>to send them to ingress rbridge-address and then have that ingress
>rbridge forward BCN to end station with appropriate ES address.
>
>If so, ingress rbdridge address seems to be requirement to me.
>
>Thanks,
>- Manoj
>
>-----Original Message-----
>From: Silvano Gai [mailto:[email-masked]] 
>Sent: Friday, October 27, 2006 8:00 AM
>To: [email-masked]; Wadekar, Manoj K
>Cc: [email-masked]
>Subject: RE: [rbridge] Ingress Rbridge address and BCN
>
>
>If the congestion is detected in the core of the TRILL network, how do
>you signal back to the source host if you don't know which is the
>ingresss RBridge? 
>
>You cannot look-up the inner MAC address, because in the core of the
>network you don't keep the inner MAC addresses in the table. Correct?
>
>This is a clear reason while you need the ingress RBridge address.
>
>-- Silvano
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>    
>>
>On
>  
>
>>Behalf Of [email-masked]
>>Sent: Thursday, October 26, 2006 5:02 PM
>>To: Wadekar, Manoj K
>>Cc: [email-masked]
>>Subject: Re: [rbridge] Ingress Rbridge address and BCN
>>
>>Hi Manoj,
>>
>>I'm confused about BCN. Wouldn't congestion notification need to go to
>>    
>>
>the
>  
>
>>original endnode source,
>>and not the ingress RBridge?
>>
>>Radia
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 08:54:47 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 1563

I have not been able to catch up on all the email of late, but Manoj
makes a very good point.  The combination of the "no-drop" behavior
provided by the 802.1au and the multipathing provided by TRILL would
make a very powerful combination for data center clustering
applications.  It would be extremely shortsighted for TRILL to be
designed in way such that hindered backward congestion notification.

802.1au returns the BCN to the source host by copying the source MAC to
the destination MAC of BCN.  RBridges in the center of the network
should be able to generate BCN frames back towards the source via the
originating source RBridge without doing a lookup on the internal source
MAC.

 - Larry

Wadekar, Manoj K wrote on Wednesday, October 25, 2006 7:06 PM:

> Hi,
> 
> 
> 
> New to TRILL mailing list. And hence catching up with lots of
> discussions about need for Ingress Rbridge address (and FTAG). 
> 
> 
> 
> I believe Datacenters are beginning to have large number of nodes in
> L2 network (scale-out clusters) and hence TRILL makes an attractive
> technology. At the same time fundamental enhancements in 802.1
> bridges are also required to ensure "no-drop" behavior in this large
> Ethernet network in Data Centers. So, Backward Congestion
> Notification (802.1au) and TRILL solutions need to work together.     
> 
> 
> 
> So, I think carrying Ingress Rbridge address in each packet is
> important for BCN. 
> 
> 
> 
> This will be used to generate the congestion notification to the
> appropriate ingress node. 
> 
> 
> 
> Thanks,
> 
> - Manoj

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 08:52:34 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, <[email-masked]>, "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 1237

Catlin,

I am not sure I understand your proposal.
Can you provide a bit more of explanation?

-- Silvano

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 8:45 AM
> To: Silvano Gai; [email-masked]; Wadekar, Manoj K
> Cc: [email-masked]
> Subject: RE: [rbridge] Ingress Rbridge address and BCN
> 
> [email-masked] wrote:
> > If the congestion is detected in the core of the TRILL
> > network, how do you signal back to the source host if you
> > don't know which is the ingresss RBridge?
> >
> > You cannot look-up the inner MAC address, because in the core
> > of the network you don't keep the inner MAC addresses in the table.
> > Correct?
> >
> > This is a clear reason while you need the ingress RBridge address.
> >
> 
> What harm would there be in sending the BCN RBridge encapsulated
> with the source-rbridge being the congesting detecting bridge?
> 
> Obviously it generates more traffic, but I'm not convinced that
> congestion detection by a "core rbridge" that does not already
> know of the source will be a common occurrence. The benefits of
> adding rbridge functionality are far stronger for the ingress
> and egress rbridges.

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 08:51:04 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 3866

Eric,

If you plan to pragmatically force implementers to keep all the MAC
addresses in the core, then simply don't require the outer
encapsulations. That will be a big saving in term of bandwidth (14
bytes), not the 2 bytes required to carry the ingress RBridge address!

More inline

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 8:38 AM
> To: Silvano Gai
> Cc: [email-masked]; [email-masked]
> Subject: RE: [rbridge] Ingress Rbridge address and BCN
> 
> Silvano,
> 
> 	Your assumption about retention of "inner MAC addresses" in
> RBridges at the core network would be an implementation choice.
> There is, and will be, no statement that "core RBridges MUST NOT
> retain advertisement information relating to MAC DA reachability.
> Nor is it the case that this information is not made available to
> RBridges in the core network.
> 
> 	Hence, if an RBridge implementation has not retained MAC DA
> reachability adsvertisements it receives, that is the choice made
> by that RBridge's implementers.
> 
> 	It is quite reasonable to assume that so-called core RBridges
> may elect not to retain MAC reachability information in cases where
> the "core RBridge" does not need this information.  Supposing that
> a "core RBridge" may need this MAC reachability information and yet
> not have retained it, is arguably a "dumb implementation" issue, as
> opposed to a protocol problem.
> 
> 	Note that an RBridge needs only to have one interface on which
> it has "delivery responsibility" (i.e. - is the designated RBridge)
> for a "native LAN" device (such as an 802.1X bridge), and it cannot
> be a "core RBridge."  With this qualification of what it means to be
> an RBridge in "core networks", this seems likely to be an exception
> case, and it is well known that it is not a good idea to design any
> protocol to be optimized for the exception case.
> 
> 	Already, we have discussed the fact that BCN capable devices
> are typically segregated onto "BCN capable VLANs."  That being the
> case, it is certainly possible for an implementer to retain MAC DA
> reachability advertisements for configured "BCN capable VLANS."

This is not the case, IEEE 802.1au will segregate BCN per VL (an
evolution of UP) not per VLAN.

-- Silvano

> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Friday, October 27, 2006 11:00 AM
> --> To: [email-masked]; Wadekar, Manoj K
> --> Cc: [email-masked]
> --> Subject: Re: [rbridge] Ingress Rbridge address and BCN
> -->
> -->
> --> If the congestion is detected in the core of the TRILL
> --> network, how do
> --> you signal back to the source host if you don't know which is the
> --> ingresss RBridge?
> -->
> --> You cannot look-up the inner MAC address, because in the core of
the
> --> network you don't keep the inner MAC addresses in the
> --> table. Correct?
> -->
> --> This is a clear reason while you need the ingress RBridge address.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: [email-masked]
> --> [mailto:[email-masked]]
> --> On
> --> > Behalf Of [email-masked]
> --> > Sent: Thursday, October 26, 2006 5:02 PM
> --> > To: Wadekar, Manoj K
> --> > Cc: [email-masked]
> --> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
> --> >
> --> > Hi Manoj,
> --> >
> --> > I'm confused about BCN. Wouldn't congestion notification
> --> need to go to
> --> the
> --> > original endnode source,
> --> > and not the ingress RBridge?
> --> >
> --> > Radia
> --> >
> -->
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

From: "Gray, Eric" <[email-masked]>
To: [email-masked], "Wadekar, Manoj K" <[email-masked]>
Date: Fri, 27 Oct 2006 11:47:04 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 864

Radia,

	One suggestion that has been made is that BCN notifications 
might be flooded on the LAN segment where the original MAC source 
exists.  If this were a desirable outcome, sending to the ingress
RBridge would make sense.

	Note that I am only mentioning that this has been suggested.
I do not think this is a good idea, for a number of reasons.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of 
--> [email-masked]
--> Sent: Thursday, October 26, 2006 8:02 PM
--> To: Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> Hi Manoj,
--> 
--> I'm confused about BCN. Wouldn't congestion notification 
--> need to go to the original endnode source,
--> and not the ingress RBridge?
--> 
--> Radia
--> 
--> 
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 08:44:30 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, [email-masked], "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 825

[email-masked] wrote:
> If the congestion is detected in the core of the TRILL
> network, how do you signal back to the source host if you
> don't know which is the ingresss RBridge?
> 
> You cannot look-up the inner MAC address, because in the core
> of the network you don't keep the inner MAC addresses in the table.
> Correct? 
> 
> This is a clear reason while you need the ingress RBridge address.
> 

What harm would there be in sending the BCN RBridge encapsulated
with the source-rbridge being the congesting detecting bridge?

Obviously it generates more traffic, but I'm not convinced that
congestion detection by a "core rbridge" that does not already
know of the source will be a common occurrence. The benefits of
adding rbridge functionality are far stronger for the ingress
and egress rbridges.

From: "Gray, Eric" <[email-masked]>
To: "Wadekar, Manoj K" <[email-masked]>
Date: Fri, 27 Oct 2006 11:43:41 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 2587

Manoj,

	Once again, the assumption that cores do not retain "addresses of
all the end-stations in [the] whole cluster" is a "convenient assumption"
for making the argument that another mechanism is required.

	Currently, there would be no requirement for retaining all such 
addresses as you have to be careful not to send BCN messages to those
end-stations that don't support them.  Moreover, as mentioned previously,
it is trivially easy to determine what address information should be kept.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Wadekar, Manoj K
--> Sent: Friday, October 27, 2006 11:21 AM
--> To: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> Yes, for large clusters, if cores do not maintain addresses 
--> of all the
--> end-stations in whole cluster - then only way to get BCN 
--> back to ES, is
--> to send them to ingress rbridge-address and then have that ingress
--> rbridge forward BCN to end station with appropriate ES address.
--> 
--> If so, ingress rbdridge address seems to be requirement to me.
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Friday, October 27, 2006 8:00 AM
--> To: [email-masked]; Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> 
--> If the congestion is detected in the core of the TRILL 
--> network, how do
--> you signal back to the source host if you don't know which is the
--> ingresss RBridge? 
--> 
--> You cannot look-up the inner MAC address, because in the core of the
--> network you don't keep the inner MAC addresses in the 
--> table. Correct?
--> 
--> This is a clear reason while you need the ingress RBridge address.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]
--> On
--> > Behalf Of [email-masked]
--> > Sent: Thursday, October 26, 2006 5:02 PM
--> > To: Wadekar, Manoj K
--> > Cc: [email-masked]
--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> > 
--> > Hi Manoj,
--> > 
--> > I'm confused about BCN. Wouldn't congestion notification 
--> need to go to
--> the
--> > original endnode source,
--> > and not the ingress RBridge?
--> > 
--> > Radia
--> > 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Fri, 27 Oct 2006 11:37:52 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 3076

Silvano,

	Your assumption about retention of "inner MAC addresses" in
RBridges at the core network would be an implementation choice.
There is, and will be, no statement that "core RBridges MUST NOT 
retain advertisement information relating to MAC DA reachability.
Nor is it the case that this information is not made available to
RBridges in the core network.

	Hence, if an RBridge implementation has not retained MAC DA
reachability adsvertisements it receives, that is the choice made
by that RBridge's implementers.

	It is quite reasonable to assume that so-called core RBridges
may elect not to retain MAC reachability information in cases where
the "core RBridge" does not need this information.  Supposing that
a "core RBridge" may need this MAC reachability information and yet 
not have retained it, is arguably a "dumb implementation" issue, as
opposed to a protocol problem.

	Note that an RBridge needs only to have one interface on which
it has "delivery responsibility" (i.e. - is the designated RBridge)
for a "native LAN" device (such as an 802.1X bridge), and it cannot 
be a "core RBridge."  With this qualification of what it means to be
an RBridge in "core networks", this seems likely to be an exception
case, and it is well known that it is not a good idea to design any
protocol to be optimized for the exception case.

	Already, we have discussed the fact that BCN capable devices 
are typically segregated onto "BCN capable VLANs."  That being the 
case, it is certainly possible for an implementer to retain MAC DA
reachability advertisements for configured "BCN capable VLANS."

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Friday, October 27, 2006 11:00 AM
--> To: [email-masked]; Wadekar, Manoj K
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> 
--> If the congestion is detected in the core of the TRILL 
--> network, how do
--> you signal back to the source host if you don't know which is the
--> ingresss RBridge? 
--> 
--> You cannot look-up the inner MAC address, because in the core of the
--> network you don't keep the inner MAC addresses in the 
--> table. Correct?
--> 
--> This is a clear reason while you need the ingress RBridge address.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]
--> On
--> > Behalf Of [email-masked]
--> > Sent: Thursday, October 26, 2006 5:02 PM
--> > To: Wadekar, Manoj K
--> > Cc: [email-masked]
--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> > 
--> > Hi Manoj,
--> > 
--> > I'm confused about BCN. Wouldn't congestion notification 
--> need to go to
--> the
--> > original endnode source,
--> > and not the ingress RBridge?
--> > 
--> > Radia
--> > 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 08:20:59 -0700
From: "Wadekar, Manoj K" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 1426

Yes, for large clusters, if cores do not maintain addresses of all the
end-stations in whole cluster - then only way to get BCN back to ES, is
to send them to ingress rbridge-address and then have that ingress
rbridge forward BCN to end station with appropriate ES address.

If so, ingress rbdridge address seems to be requirement to me.

Thanks,
- Manoj

-----Original Message-----
From: Silvano Gai [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 8:00 AM
To: [email-masked]; Wadekar, Manoj K
Cc: [email-masked]
Subject: RE: [rbridge] Ingress Rbridge address and BCN

If the congestion is detected in the core of the TRILL network, how do
you signal back to the source host if you don't know which is the
ingresss RBridge? 

You cannot look-up the inner MAC address, because in the core of the
network you don't keep the inner MAC addresses in the table. Correct?

This is a clear reason while you need the ingress RBridge address.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of [email-masked]
> Sent: Thursday, October 26, 2006 5:02 PM
> To: Wadekar, Manoj K
> Cc: [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge address and BCN
> 
> Hi Manoj,
> 
> I'm confused about BCN. Wouldn't congestion notification need to go to
the
> original endnode source,
> and not the ingress RBridge?
> 
> Radia
> 

Content-class: urn:content-classes:message
Date: Fri, 27 Oct 2006 08:00:28 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>, "Wadekar, Manoj K" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 832

If the congestion is detected in the core of the TRILL network, how do
you signal back to the source host if you don't know which is the
ingresss RBridge? 

You cannot look-up the inner MAC address, because in the core of the
network you don't keep the inner MAC addresses in the table. Correct?

This is a clear reason while you need the ingress RBridge address.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of [email-masked]
> Sent: Thursday, October 26, 2006 5:02 PM
> To: Wadekar, Manoj K
> Cc: [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge address and BCN
> 
> Hi Manoj,
> 
> I'm confused about BCN. Wouldn't congestion notification need to go to
the
> original endnode source,
> and not the ingress RBridge?
> 
> Radia
> 

Date: Thu, 26 Oct 2006 17:01:50 -0700
From: [email-masked]
To: "Wadekar, Manoj K" <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 6022

This is a multi-part message in MIME format.

--Boundary_(ID_tkMORaXCcsuZlvSz8rzsEA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Manoj,

I'm confused about BCN. Wouldn't congestion notification need to go to the original endnode source,
and not the ingress RBridge?

Radia

--Boundary_(ID_tkMORaXCcsuZlvSz8rzsEA)
Content-type: multipart/alternative;
	boundary="Boundary_(ID_Gx7GLPUMzE361n117AnJ9Q)"
Content-class: urn:content-classes:message

--Boundary_(ID_Gx7GLPUMzE361n117AnJ9Q)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,

New to TRILL mailing list. And hence catching up with lots of
discussions about need for Ingress Rbridge address (and FTAG).

I believe Datacenters are beginning to have large number of nodes in L2
network (scale-out clusters) and hence TRILL makes an attractive
technology. At the same time fundamental enhancements in 802.1 bridges
are also required to ensure "no-drop" behavior in this large Ethernet
network in Data Centers. So, Backward Congestion Notification (802.1au)
and TRILL solutions need to work together.

So, I think carrying Ingress Rbridge address in each packet is important
for BCN. 

This will be used to generate the congestion notification to the
appropriate ingress node.

Thanks,

- Manoj

--Boundary_(ID_Gx7GLPUMzE361n117AnJ9Q)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Courier New";
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>Hi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>New to TRILL mailing list. And
hence catching up with lots of discussions about need for Ingress Rbridge
address (and FTAG).<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>I believe Datacenters are beginning
to have large number of nodes in L2 network (scale-out clusters) and hence
TRILL makes an attractive technology. At the same time fundamental enhancements
in 802.1 bridges are also required to ensure &#8220;no-drop&#8221; behavior in
this large Ethernet network in Data Centers. So, Backward Congestion
Notification (802.1au) and TRILL solutions need to work together.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>So, I think carrying Ingress
Rbridge address in each packet is important for BCN. <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-indent:36.0pt'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>This will be used to
generate the congestion notification to the appropriate ingress node.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>Thanks,</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>- Manoj</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_Gx7GLPUMzE361n117AnJ9Q)--

--Boundary_(ID_tkMORaXCcsuZlvSz8rzsEA)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

--Boundary_(ID_tkMORaXCcsuZlvSz8rzsEA)--

Date: Thu, 26 Oct 2006 16:52:23 -0700
From: [email-masked]
To: "Sanjay Sane (sanjays)" <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: [rbridge] How many trees, and per what
Status: RO
Content-Length: 1869

There is considerable confusion (certainly by me, and I'm sure others) at this point. Let me start a new thread to
specificallly discuss which trees should be computed.

The WG consensus seemed to be to compute per-ingress trees rather than
shared trees. For several reasons, e.g.,

a) the number of packet hops to deliver a packet to just a subset of links (as would be the case with
a packet only going to links for a particular VLAN, or for an IP multicast that is only going to links with
registered receivers plus IP multicast routers) can be a lot more than necessary if we are not using
a per-ingress tree, and instead using a shared tree

b) a few packets in a conversation from S to D are more likely to get out of order if at first D is unknown, and
the packet is sent on a shared tree, and then when D is found, going directly, since the path from S to D might
be much longer in the shared tree than the tree rooted at S's Designated Rbridge

It is true that it would take less memory and computation to use a shared tree, even multiple per-F-tag shared
trees, but they would not have the properties a) and b) above.

So I believe if we do per-F-tag trees, we will be multiplying the number of trees by F-tag, and computing
(# of Designated Rbridges) * (# of F-tag values).

I don't believe we should revisit the per-ingress trees. Especially if the reason is to make better use of
bandwidth by using F-tags, since using per-ingress trees certainly will cut down on bandwidth use for
IP multicast packets and unknown/multicast VLAN-tagged packets.

So the question is whether we should multiply the number of trees by the number of F-tag values. And if so,
how many F-tag values are really needed.

I *think* the only purpose of using multiple F-tag values and trees is to spread traffic around, and engineer traffic
for certain classes of traffic. 

Radia

From: "Gray, Eric" <[email-masked]>
To: "Sanjay Sane (sanjays)" <[email-masked]>
Date: Thu, 26 Oct 2006 18:12:06 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 4637

Sanjay,

	There are no issues with using .1Q tags in the tunnel
encapsulation, any more than there would be issues in using
it in the native bridge segments' encapsulation.  It is just 
one more form of Ethernet commonly supported across RBridges.

	The use of Ethernet encapsulation - beyond the simple
statement that "some form of Ethernet encapsulation will be
used" is orthogonal to TRILL SHIM usage.  As it is orthogonal,
it is invalid to try to "combine this [802.1Q] concept with
TRILL" - because we are using a protocol model that allows us
to ignore how these things are combined.

	This is really the right way to proceed.  Otherwise, we
will be bogged down forever in discussions about how the TRILL
SHIM works in combination with a long list of potential types
of "ethernet" encapsulations.  It just does.

	As for forwarding decision impact, either the frame is
VLAN tagged (in which case all forwarding decisions are scoped
by the VLAN tag - independent of other encapsulations), or it
is not (which is logically equivalent to the "default" VLAN).

	We need to stop trying to find "rocket science" in the
way we do things.  There is nothing difficult about this.

	Finally, I don't think anyone is suggesting that VLAN tags
could be used for "FTAG purposes."  What has been suggested as a
justification for FTAGs is already within scope for VLAN tag use.
That should be taken to mean we don't need to invent a new kind 
of wheel to do what we already can do.  There is no reason to 
define anything for "FTAG purposes."

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Sanjay 
--> Sane (sanjays)
--> Sent: Thursday, October 26, 2006 5:39 PM
--> To: Maltbie, Dan; [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 
--> I think you're suggesting adding one (outer) .1Q Tag, apart from
--> customer's original (inner).1Q tag (the real VLAN tag), and use the
--> outer .1Q as the index to the forwarding table for purposes 
--> of Ftag. 
--> 
--> Issues with this approach could be combining this concept 
--> with TRILL.
--> For e.g. would such a .1Q tag come before TRILL's existing 
--> shim header
--> or after ? Where would original .1Q tag (original VLAN) fit in?
--> Potentially, forwarding decision may need to take all 3 
--> ethertype's into
--> account. 
--> Also .1Q payload portion is 16 bits (12 bits vlan, 3 bit pri, 1 bit
--> CFI). If we really need the Ftag functionality (from the 
--> outer .1Q tag),
--> 10 bits (as proposed in the new shim header) should be enough. 
--> 
--> The new shim header (proposed as per
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-
--> encap-00.txt
--> ) takes all of this into account and packs them into the 
--> TRILL context. 
--> 
--> -Sanjay
--> 
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Maltbie, Dan
--> Sent: Wednesday, October 25, 2006 11:07 PM
--> To: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> The IEEE 802.1Q VLAN TAG should do everything an rbridge 
--> could possibly
--> want to do with an FTAG and it will be much more interoperable with
--> existing and future Ethernet equipment. There's already a 
--> standard way
--> to push/pop VLAN tags. Other standards, like provider bridging, are
--> taking advantage of Ethernet's excellent flexibility. Why 
--> re-invent the
--> wheel?
--> 
--> just a thought...
--> 
--> Dan Maltbie
--> Woven Systems, Inc.
--> 
--> -----Original Message-----
--> Message: 5
--> Date: Wed, 25 Oct 2006 19:30:26 -0700
--> From: "Sanjay Sane \(sanjays\)" <[email-masked]>
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> To: "Radia Perlman" <[email-masked]>
--> Cc: [email-masked]
--> Message-ID:
--> 	
--> <[email-masked]
--> isco.com>
--> Content-Type: text/plain;	charset="us-ascii"
--> 
--> 
--> <<snip>>
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> 
--> End of rbridge Digest, Vol 29, Issue 30
--> ***************************************
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Thu, 26 Oct 2006 14:38:49 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Maltbie, Dan" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 2299

I think you're suggesting adding one (outer) .1Q Tag, apart from
customer's original (inner).1Q tag (the real VLAN tag), and use the
outer .1Q as the index to the forwarding table for purposes of Ftag. 

Issues with this approach could be combining this concept with TRILL.
For e.g. would such a .1Q tag come before TRILL's existing shim header
or after ? Where would original .1Q tag (original VLAN) fit in?
Potentially, forwarding decision may need to take all 3 ethertype's into
account. 
Also .1Q payload portion is 16 bits (12 bits vlan, 3 bit pri, 1 bit
CFI). If we really need the Ftag functionality (from the outer .1Q tag),
10 bits (as proposed in the new shim header) should be enough. 

The new shim header (proposed as per
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
) takes all of this into account and packs them into the TRILL context. 

-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maltbie, Dan
Sent: Wednesday, October 25, 2006 11:07 PM
To: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again

The IEEE 802.1Q VLAN TAG should do everything an rbridge could possibly
want to do with an FTAG and it will be much more interoperable with
existing and future Ethernet equipment. There's already a standard way
to push/pop VLAN tags. Other standards, like provider bridging, are
taking advantage of Ethernet's excellent flexibility. Why re-invent the
wheel?

just a thought...

Dan Maltbie
Woven Systems, Inc.

-----Original Message-----
Message: 5
Date: Wed, 25 Oct 2006 19:30:26 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

<<snip>>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

End of rbridge Digest, Vol 29, Issue 30
***************************************

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Wed, 25 Oct 2006 23:06:34 -0700
From: "Maltbie, Dan" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1023

The IEEE 802.1Q VLAN TAG should do everything an rbridge could possibly
want to do with an FTAG and it will be much more interoperable with
existing and future Ethernet equipment. There's already a standard way
to push/pop VLAN tags. Other standards, like provider bridging, are
taking advantage of Ethernet's excellent flexibility. Why re-invent the
wheel?

just a thought...

Dan Maltbie
Woven Systems, Inc.

-----Original Message-----
Message: 5
Date: Wed, 25 Oct 2006 19:30:26 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

<<snip>>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

End of rbridge Digest, Vol 29, Issue 30
***************************************

Content-class: urn:content-classes:message
Date: Wed, 25 Oct 2006 19:30:26 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 8894

see inline with <sanjay>

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 4:47 PM
To: Sanjay Sane (sanjays)
Cc: Alia Atlas; Dinesh G Dutt (ddutt); [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again

Sanjay Sane (sanjays) wrote:

>Thus, it would be easier if everyone agrees on a single number space 
>(Ftag!), and associate a given multicast-tree of a given VLAN to a 
>particular Ftag. Proposed Ftag is 10 bits, so maximum number of trees 
>in my port-logic/forwarding-table is 1k.

Again, apologies that I haven't had a chance to catch up on this whole
discussion, but I'm confused.
If you use 10 bits of Ftag to have 1000 different metrics, for which
1000 trees can be computed, don't you have to multiply the number of
trees by the number of ingress RBridges? So it wouldn't be 1K trees, it
would be 1K times the number of ingress RBridges.

<sanjay>
ftag # represents the shared tree. For a given tree, all rbridges
compute the same tree, with the same rbridge as the root, and associate
their forwarding tables with the same ftag #. Once a rbridge gets a
packet with the ftag #, they select the forwarding table relevant to
that ftag #. 

             B
             |
           |----|
          /| R2 |\
   |----|/ |----| \|----|
A--| R1 |          | R3 |-C
   |----|          |----|
        \        / 
         \|----|/
          | R4 |
          |----|
            |
            D

Lets say all hosts (A,B,C,D) are interested in groups G1, G2, 
All rbridges (R1, R2, R3, R4) build 2 trees, one rooted at R2 (loop
broken at R2-R3), (tree has ftag = Ftag-R2), another rooted at R4 (loop
broken at say R1-R2), (tree has ftag = Ftag-R4

Then, a multicast for G1 sourced at A, may be choosen to be sent on
Ftag-R2. 
Then, a multicast for G2 sourced at A, may be choosen to be sent on
Ftag-R4. 
[ It may be possible all packets sourced at R4 use only 1 tree --
Ftag-R4 ]

At any intermediate rbridge, say R2, I would consult the forwarding
table [Ftag-R2,G1] OR [Ftag-R4,G] based on the FTAG carried by the
packet (NOT what the source rbridge is). Similarly loops would be broken
based on Ftag in the packet. 

If we needed multipathing from each source-rbridge, say 2 trees per each
source-rbridge, we would need to be able to store 4 * 2 combinations. In
reality, we don't need so many trees, but at any given time, we may need
the flexibility to be able to provide multicast multi-pathing from any
given source rbridge.  

-Sanjay

The trees are shared by multiple source/ingress rbriges. We wont be
computing 1000 trees from each source rbridge. 

You also said:

>I can see FTAG being useful to reduce hardware-cost in the scenario of 
>shared multicast trees.

What hardware cost are you reducing? I'd assume that what you might save
in using multiple trees is bandwidth, since traffic would be spread
more. But I'd think having multiple per-F-tag trees would *increase*
hardware cost because of having to compute more trees and keep more
forwarding tables.

Radia

Sanjay Sane (sanjays) wrote:

>I can see FTAG being useful to reduce hardware-cost in the scenario of 
>shared multicast trees.
>
>Multi-pathing for multicast packets can be easily done only when there 
>are multiple shared trees to choose from. Each source-rbridge could 
>have a list of trees to choose from, and some hash (such as based on 
>DA) can be used to pick the tree. Once the tree is chosen, rest of 
>rbridges must forward the packet on the same tree, otherwise there'll 
>be loops & duplicates.
>
>Such shared multicast trees can be easily built by every rbridge 
>computing multiple trees/Djikstras with different (& well-placed)
roots.
>One may want to configure the roots of these trees in the core of the 
>network (assuming an access-aggregation-core topology).
>
>We may want some m number of trees per VLAN to support multicast 
>multi-pathing. Typically, unicast supports 16 path multi-pathing. So,
>(maybe) we should be able to support 16 trees per VLAN for multicast 
>multi-pathing.
>
>One way to distinguish different multicast trees is by carring some 
>additional tag & looking up forwarding-tables/port-logic with index 
>{vlan, tag-value}. Even if this additional tag is 3 bits (max 8 trees),

>hardware needs to support 4k * 8 = 32k values (or a tcam which is also
>expensive).   
>
>I don't expect we need so many multicast trees, but I do want the 
>flexibility to at least support 8-way multipathing for each VLAN, but 
>don't want to build such costly hardware.
>
>Thus, it would be easier if everyone agrees on a single number space 
>(Ftag!), and associate a given multicast-tree of a given VLAN to a 
>particular Ftag. Proposed Ftag is 10 bits, so maximum number of trees 
>in my port-logic/forwarding-table is 1k.
>
>Sanjay
> 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On

>Behalf Of Alia Atlas
>Sent: Monday, October 23, 2006 1:47 PM
>To: Dinesh G Dutt (ddutt)
>Cc: [email-masked]
>Subject: Re: [rbridge] Ingress Rbridge and FTAG again
>
>Hi Dinesh,
>
>On 10/20/06, Dinesh G Dutt <[email-masked]> wrote:
>  
>
>>Alia Atlas wrote:
>>    
>>
>>>I certainly haven't heard a strong enough argument for including the
>>>      
>>>
>
>  
>
>>>ingress rbridge.  For instance, if you really want traceroute equiv,
>>>      
>>>
>
>  
>
>>>well, the encapsulated Ethernet frame contains  the source MAC from 
>>>right before the entrance to the rbridge area.  Why can't that be 
>>>used to get replies back?
>>>      
>>>
>>The reason is that this requires the core Rbridges to also populate 
>>the tables with the mapping from MAC address to Rbridge. Not requiring
>>    
>>
>
>  
>
>>the core Rbridges to maintain a large MAC table is one of the 
>>advantages of Rbridges.
>>    
>>
>
>Not maintaining a large MAC table in hardware could be an advantage of 
>a core Rbridge.  However, given that the MAC to rbridge association is 
>provided through the routing protocol, even a core Rbridge will
>certainly have the information available in software.   Could you
>explain why you don't think this is sufficient?  Traceroute in IP is 
>frequently on the slowpath going through software; why would it need to

>be different for this case?
>
>  
>
>>>As to the Ftag, I've not heard why the 3 bits that are equiv to the 
>>>EXP bits in an MPLS header coudn't be used to indicate a CoS related
>>>      
>>>
>
>  
>
>>>mechanism.
>>>      
>>>
>>Again, if you read my rather lengthy email, you'll see why three bits 
>>are insufficient. The main reasons stem from having to do shared 
>>multicast trees. Eric points out a way to do it using an additional 
>>.1Q header and redefining (I think) the meaning of the VLAN field.
>>That has the disadvantages that I pointed out in my emails to him.
>>    
>>
>
>I had been scanning the emails & may have missed your argument about 
>three bits being insufficient.  How many shared multicast trees do you 
>think is sufficient and why?
>Does the ingress Rbridge select which shared multicast tree to use for
>a frame?   How are the shared multicast trees created and agreed upon?
>
>If a frame is destined for a shared multicast tree, does the ingress 
>rbridge id in the shim have any relevance to the forwarding?
>
>  
>
>>>I am particularly against the idea, that hasn't gotten much 
>>>discussion, of trying to include info about how the final rbridge 
>>>should direct a packet out.  I think this impacts the scalability & 
>>>requires additional knowledge be distributed to all the rbridges.  A
>>>      
>>>
>
>  
>
>>>similiar thing can be done with the MPLS Layer-3 VPN, where a 
>>>different label is used to indicate the outgoing interface, etc.
>>>      
>>>
>>If you're thinking about the LID, I don't think it is analogous to 
>>requiring an additional label. It is adding additional bits to the 
>>switchID that are of consequence to the final Rbridge only. Also, I 
>>understand that the arguments for including a LID may not be 
>>technically strong enough to merit the overhead they add.
>>    
>>
>
>My concern  for the LID isn't just the bits that it adds to the header.
>It is the additional table space required by the hardware of all the 
>Rbridges to produce frames with different encapsulations based upon the

>final outgoing interface.  Additionally, how many ports or interfaces 
>would be sufficient?  Why?
>
>If you're not seriously trying to move that idea forward, there's 
>probably little point discussing it here, given the debate on the other

>two.
>
>Alia
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Wed, 25 Oct 2006 19:05:48 -0700
From: "Wadekar, Manoj K" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Ingress Rbridge address and BCN
Status: RO
Content-Length: 5479

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F8A3.42673E7B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

New to TRILL mailing list. And hence catching up with lots of
discussions about need for Ingress Rbridge address (and FTAG).

=20

I believe Datacenters are beginning to have large number of nodes in L2
network (scale-out clusters) and hence TRILL makes an attractive
technology. At the same time fundamental enhancements in 802.1 bridges
are also required to ensure "no-drop" behavior in this large Ethernet
network in Data Centers. So, Backward Congestion Notification (802.1au)
and TRILL solutions need to work together.

=20

So, I think carrying Ingress Rbridge address in each packet is important
for BCN.=20

=20

This will be used to generate the congestion notification to the
appropriate ingress node.

=20

Thanks,

- Manoj

=20

------_=_NextPart_001_01C6F8A3.42673E7B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Courier New";
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>New to TRILL =
mailing list. And
hence catching up with lots of discussions about need for Ingress =
Rbridge
address (and FTAG).<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>I believe =
Datacenters are beginning
to have large number of nodes in L2 network (scale-out clusters) and =
hence
TRILL makes an attractive technology. At the same time fundamental =
enhancements
in 802.1 bridges are also required to ensure &#8220;no-drop&#8221; =
behavior in
this large Ethernet network in Data Centers. So, Backward Congestion
Notification (802.1au) and TRILL solutions need to work =
together.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>So, I think =
carrying Ingress
Rbridge address in each packet is important for BCN. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This will be used =
to
generate the congestion notification to the appropriate ingress =
node.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>- Manoj</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6F8A3.42673E7B--

Date: Wed, 25 Oct 2006 16:46:32 -0700
From: Radia Perlman <[email-masked]>
To: "Sanjay Sane (sanjays)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 6869

Sanjay Sane (sanjays) wrote:

>Thus, it would be easier if everyone agrees on a single number space
>(Ftag!), and associate a given multicast-tree of a given VLAN to a
>particular Ftag. Proposed Ftag is 10 bits, so maximum number of trees in
>my port-logic/forwarding-table is 1k. 

Again, apologies that I haven't had a chance to catch up on this whole 
discussion, but I'm confused.
If you use 10 bits of Ftag to have 1000 different metrics, for which 
1000 trees can be computed,
don't you have to multiply the number of trees by the number of ingress 
RBridges? So it wouldn't
be 1K trees, it would be 1K times the number of ingress RBridges.

You also said:

>I can see FTAG being useful to reduce hardware-cost in the scenario of
>shared multicast trees.

What hardware cost are you reducing? I'd assume that what you might save 
in using multiple trees
is bandwidth, since traffic would be spread more. But I'd think having 
multiple
per-F-tag trees would *increase* hardware cost
because of having to compute more trees and keep more forwarding tables.

Radia

Sanjay Sane (sanjays) wrote:

>I can see FTAG being useful to reduce hardware-cost in the scenario of
>shared multicast trees.
>
>Multi-pathing for multicast packets can be easily done only when there
>are multiple shared trees to choose from. Each source-rbridge could have
>a list of trees to choose from, and some hash (such as based on DA) can
>be used to pick the tree. Once the tree is chosen, rest of rbridges must
>forward the packet on the same tree, otherwise there'll be loops &
>duplicates. 
>
>Such shared multicast trees can be easily built by every rbridge
>computing multiple trees/Djikstras with different (& well-placed) roots.
>One may want to configure the roots of these trees in the core of the
>network (assuming an access-aggregation-core topology).
>
>We may want some m number of trees per VLAN to support multicast
>multi-pathing. Typically, unicast supports 16 path multi-pathing. So,
>(maybe) we should be able to support 16 trees per VLAN for multicast
>multi-pathing. 
>
>One way to distinguish different multicast trees is by carring some
>additional tag & looking up forwarding-tables/port-logic with index
>{vlan, tag-value}. Even if this additional tag is 3 bits (max 8 trees),
>hardware needs to support 4k * 8 = 32k values (or a tcam which is also
>expensive).   
>
>I don't expect we need so many multicast trees, but I do want the
>flexibility to at least support 8-way multipathing for each VLAN, but
>don't want to build such costly hardware. 
>
>Thus, it would be easier if everyone agrees on a single number space
>(Ftag!), and associate a given multicast-tree of a given VLAN to a
>particular Ftag. Proposed Ftag is 10 bits, so maximum number of trees in
>my port-logic/forwarding-table is 1k. 
>
>Sanjay
> 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Alia Atlas
>Sent: Monday, October 23, 2006 1:47 PM
>To: Dinesh G Dutt (ddutt)
>Cc: [email-masked]
>Subject: Re: [rbridge] Ingress Rbridge and FTAG again
>
>Hi Dinesh,
>
>On 10/20/06, Dinesh G Dutt <[email-masked]> wrote:
>  
>
>>Alia Atlas wrote:
>>    
>>
>>>I certainly haven't heard a strong enough argument for including the
>>>      
>>>
>
>  
>
>>>ingress rbridge.  For instance, if you really want traceroute equiv,
>>>      
>>>
>
>  
>
>>>well, the encapsulated Ethernet frame contains  the source MAC from 
>>>right before the entrance to the rbridge area.  Why can't that be 
>>>used to get replies back?
>>>      
>>>
>>The reason is that this requires the core Rbridges to also populate 
>>the tables with the mapping from MAC address to Rbridge. Not requiring
>>    
>>
>
>  
>
>>the core Rbridges to maintain a large MAC table is one of the 
>>advantages of Rbridges.
>>    
>>
>
>Not maintaining a large MAC table in hardware could be an advantage of a
>core Rbridge.  However, given that the MAC to rbridge association is
>provided through the routing protocol, even a core Rbridge will
>certainly have the information available in software.   Could you
>explain why you don't think this is sufficient?  Traceroute in IP is
>frequently on the slowpath going through software; why would it need to
>be different for this case?
>
>  
>
>>>As to the Ftag, I've not heard why the 3 bits that are equiv to the 
>>>EXP bits in an MPLS header coudn't be used to indicate a CoS related
>>>      
>>>
>
>  
>
>>>mechanism.
>>>      
>>>
>>Again, if you read my rather lengthy email, you'll see why three bits 
>>are insufficient. The main reasons stem from having to do shared 
>>multicast trees. Eric points out a way to do it using an additional 
>>.1Q header and redefining (I think) the meaning of the VLAN field. 
>>That has the disadvantages that I pointed out in my emails to him.
>>    
>>
>
>I had been scanning the emails & may have missed your argument about
>three bits being insufficient.  How many shared multicast trees do you
>think is sufficient and why?
>Does the ingress Rbridge select which shared multicast tree to use for
>a frame?   How are the shared multicast trees created and agreed upon?
>
>If a frame is destined for a shared multicast tree, does the ingress
>rbridge id in the shim have any relevance to the forwarding?
>
>  
>
>>>I am particularly against the idea, that hasn't gotten much 
>>>discussion, of trying to include info about how the final rbridge 
>>>should direct a packet out.  I think this impacts the scalability & 
>>>requires additional knowledge be distributed to all the rbridges.  A
>>>      
>>>
>
>  
>
>>>similiar thing can be done with the MPLS Layer-3 VPN, where a 
>>>different label is used to indicate the outgoing interface, etc.
>>>      
>>>
>>If you're thinking about the LID, I don't think it is analogous to 
>>requiring an additional label. It is adding additional bits to the 
>>switchID that are of consequence to the final Rbridge only. Also, I 
>>understand that the arguments for including a LID may not be 
>>technically strong enough to merit the overhead they add.
>>    
>>
>
>My concern  for the LID isn't just the bits that it adds to the header.
>It is the additional table space required by the hardware of all the
>Rbridges to produce frames with different encapsulations based upon the
>final outgoing interface.  Additionally, how many ports or interfaces
>would be sufficient?  Why?
>
>If you're not seriously trying to move that idea forward, there's
>probably little point discussing it here, given the debate on the other
>two.
>
>Alia
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Wed, 25 Oct 2006 15:06:28 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Alia Atlas" <[email-masked]>, "Dinesh G Dutt \(ddutt\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 5350

I can see FTAG being useful to reduce hardware-cost in the scenario of
shared multicast trees.

Multi-pathing for multicast packets can be easily done only when there
are multiple shared trees to choose from. Each source-rbridge could have
a list of trees to choose from, and some hash (such as based on DA) can
be used to pick the tree. Once the tree is chosen, rest of rbridges must
forward the packet on the same tree, otherwise there'll be loops &
duplicates. 

Such shared multicast trees can be easily built by every rbridge
computing multiple trees/Djikstras with different (& well-placed) roots.
One may want to configure the roots of these trees in the core of the
network (assuming an access-aggregation-core topology).

We may want some m number of trees per VLAN to support multicast
multi-pathing. Typically, unicast supports 16 path multi-pathing. So,
(maybe) we should be able to support 16 trees per VLAN for multicast
multi-pathing. 

One way to distinguish different multicast trees is by carring some
additional tag & looking up forwarding-tables/port-logic with index
{vlan, tag-value}. Even if this additional tag is 3 bits (max 8 trees),
hardware needs to support 4k * 8 = 32k values (or a tcam which is also
expensive).   

I don't expect we need so many multicast trees, but I do want the
flexibility to at least support 8-way multipathing for each VLAN, but
don't want to build such costly hardware. 

Thus, it would be easier if everyone agrees on a single number space
(Ftag!), and associate a given multicast-tree of a given VLAN to a
particular Ftag. Proposed Ftag is 10 bits, so maximum number of trees in
my port-logic/forwarding-table is 1k. 

Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alia Atlas
Sent: Monday, October 23, 2006 1:47 PM
To: Dinesh G Dutt (ddutt)
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again

Hi Dinesh,

On 10/20/06, Dinesh G Dutt <[email-masked]> wrote:
> Alia Atlas wrote:
> > I certainly haven't heard a strong enough argument for including the

> > ingress rbridge.  For instance, if you really want traceroute equiv,

> > well, the encapsulated Ethernet frame contains  the source MAC from 
> > right before the entrance to the rbridge area.  Why can't that be 
> > used to get replies back?
> The reason is that this requires the core Rbridges to also populate 
> the tables with the mapping from MAC address to Rbridge. Not requiring

> the core Rbridges to maintain a large MAC table is one of the 
> advantages of Rbridges.

Not maintaining a large MAC table in hardware could be an advantage of a
core Rbridge.  However, given that the MAC to rbridge association is
provided through the routing protocol, even a core Rbridge will
certainly have the information available in software.   Could you
explain why you don't think this is sufficient?  Traceroute in IP is
frequently on the slowpath going through software; why would it need to
be different for this case?

> > As to the Ftag, I've not heard why the 3 bits that are equiv to the 
> > EXP bits in an MPLS header coudn't be used to indicate a CoS related

> > mechanism.
> Again, if you read my rather lengthy email, you'll see why three bits 
> are insufficient. The main reasons stem from having to do shared 
> multicast trees. Eric points out a way to do it using an additional 
> .1Q header and redefining (I think) the meaning of the VLAN field. 
> That has the disadvantages that I pointed out in my emails to him.

I had been scanning the emails & may have missed your argument about
three bits being insufficient.  How many shared multicast trees do you
think is sufficient and why?
Does the ingress Rbridge select which shared multicast tree to use for
a frame?   How are the shared multicast trees created and agreed upon?

If a frame is destined for a shared multicast tree, does the ingress
rbridge id in the shim have any relevance to the forwarding?

> >
> > I am particularly against the idea, that hasn't gotten much 
> > discussion, of trying to include info about how the final rbridge 
> > should direct a packet out.  I think this impacts the scalability & 
> > requires additional knowledge be distributed to all the rbridges.  A

> > similiar thing can be done with the MPLS Layer-3 VPN, where a 
> > different label is used to indicate the outgoing interface, etc.
> If you're thinking about the LID, I don't think it is analogous to 
> requiring an additional label. It is adding additional bits to the 
> switchID that are of consequence to the final Rbridge only. Also, I 
> understand that the arguments for including a LID may not be 
> technically strong enough to merit the overhead they add.

My concern  for the LID isn't just the bits that it adds to the header.
It is the additional table space required by the hardware of all the
Rbridges to produce frames with different encapsulations based upon the
final outgoing interface.  Additionally, how many ports or interfaces
would be sufficient?  Why?

If you're not seriously trying to move that idea forward, there's
probably little point discussing it here, given the debate on the other
two.

Alia
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Wed, 25 Oct 2006 16:36:02 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Working Group Last Call on Problem and Applicability Statement and Routing Requirements, Expert Review of Architecture Draft
Status: RO
Content-Length: 1905

Hi,

TRILL now has three drafts which have been discussed within the TRILL
working group, improved based on mailing list comments, and about which
there does not seem to be a current serious controversy (in some cases
these draft went through multiple versions as personal drafts before
being adopted as working group drafts):

1	Transparent Interconnection of Lots of Links (TRILL): Problem
and Applicability Statement 
	draft-ietf-trill-prob-01.txt

2	The Architecture of an RBridge Solution to TRILL 
	draft-ietf-trill-rbridge-arch-01.txt

3	TRILL Routing Requirements in Support of RBridges
	draft-ietf-trill-routing-reqs-00.txt

We have decided to initiate a two week working group last call on the
first and third of these: the Problem and Applicability Statement draft
and the Routing Requirements draft. This will run through Wednesday, 8
November. Please post any further comments on these drafts to the
mailing list, preferably in a separate message for each draft.

We also plan to allocate some time for comments on these two drafts at
the TRILL WG meeting in San Diego which is during the last call period.
Based on the feedback we get, we expect to decided for each of these two
drafts whether to forward it to the IESG as is, forward it with minor
changes, or continue to work on it within the working group.

Our charter requires that the second draft above, the Architecture
draft, be subject to IEEE/IETF expert review. It seems reasonable to do
this review before working group last call. Accordingly, we are
arranging such review. If you would like to suggest an expert to review
the Architecture draft, preferably someone who has not been heavily
involved with TRILL thus far, please contact us directly. We also plan
to allocate some time at the San Diego meeting for comments on the
Architecture draft.

Thanks,
Donald and Erik

[email-masked], [email-masked]

From: "Gray, Eric" <[email-masked]>
To: [email-masked]
Date: Mon, 23 Oct 2006 17:02:40 -0400
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 2523

Radia,

	I agree, and these questions are essentially a re-statement
of the question: 

"Do we want to add the requirements implied in this work to the
 TRILL WG charter?"

	If we do, then we open the floor to other proposals for how
to solve those additional problems.  This is - I believe - the 
main reason why none (or at least very few) of the comments made
so far have been along the lines of "how good is this particular
proposal at meeting these additional requirements."

	There have been off-line discussions along those lines, and
- until we decide that this new set of problems is something we do
want to solve, in this version of TRILL - then off-line is where 
any such discussion belongs.

	As a participant in the process, what I see is that someone
can waltz in from the side-line with an alternative proposal and
try to stretch the problem we're trying to solve to fit their own
particular solution.  That is usually not allowed in the IETF.

	If there is a genuine need to deal with the other problems 
that are now being raised, then - as you say - we need to decide
that.

	And then we can start to design solutions to a new problem
statement, which will then include these new problems.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> Sent: Monday, October 23, 2006 4:17 PM
--> To: Gray, Eric
--> Cc: Dinesh G Dutt; Joe Touch; [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 
--> > 
--> > 	If we were to discard each solution as it comes to a point
--> > of some level of maturity in favor of a solution that also might
--> > address new problems, we will get nothing done.
--> > 
--> > --
--> > Eric
--> > 
--> 
--> With the caveat that I have not been following the 
--> discussion (I'm still travelling with limited opportunity 
--> for email),
--> although Eric's statement is true---that constantly 
--> changing for something slightly better means things never 
--> converge---I
--> don't think the layout of the shim header is that big a 
--> change. So if changing it means that TRILL will be
--> suitable for more things, or more likely to be adopted, 
--> then it seems prudent---but it should be decided very quickly.
--> 
--> For each of the proposed fields, how valuable is each one? 
--> Are there places that will adopt TRILL with those, and
--> would not without them? Are there places that would adopt 
--> TRILL with the MPLS-like header, but wouldn't without it?
--> 
--> Radia
--> 

Date: Mon, 23 Oct 2006 13:46:56 -0700
From: "Alia Atlas" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 3240

Hi Dinesh,

On 10/20/06, Dinesh G Dutt <[email-masked]> wrote:
> Alia Atlas wrote:
> > I certainly haven't heard a strong enough argument for including the
> > ingress rbridge.  For instance, if you really want traceroute equiv,
> > well, the encapsulated Ethernet frame contains  the source MAC from
> > right before the entrance to the rbridge area.  Why can't that be used
> > to get replies back?
> The reason is that this requires the core Rbridges to also populate the
> tables with the mapping from MAC address to Rbridge. Not requiring the
> core Rbridges to maintain a large MAC table is one of the advantages of
> Rbridges.

Not maintaining a large MAC table in hardware could be an advantage of
a core Rbridge.  However, given that the MAC to rbridge association is
provided through the routing protocol, even a core Rbridge will
certainly have the information available in software.   Could you
explain why you don't think this is sufficient?  Traceroute in IP is
frequently on the slowpath going through software; why would it need
to be different for this case?

> > As to the Ftag, I've not heard why the 3 bits that are equiv to the
> > EXP bits in an MPLS header coudn't be used to indicate a CoS related
> > mechanism.
> Again, if you read my rather lengthy email, you'll see why three bits
> are insufficient. The main reasons stem from having to do shared
> multicast trees. Eric points out a way to do it using an additional .1Q
> header and redefining (I think) the meaning of the VLAN field. That has
> the disadvantages that I pointed out in my emails to him.

I had been scanning the emails & may have missed your argument about
three bits being insufficient.  How many shared multicast trees do you
think is sufficient and why?
Does the ingress Rbridge select which shared multicast tree to use for
a frame?   How are the shared multicast trees created and agreed upon?

If a frame is destined for a shared multicast tree, does the ingress
rbridge id in the shim have any relevance to the forwarding?

> >
> > I am particularly against the idea, that hasn't gotten much
> > discussion, of trying to include info about how the final rbridge
> > should direct a packet out.  I think this impacts the scalability &
> > requires additional knowledge be distributed to all the rbridges.  A
> > similiar thing can be done with the MPLS Layer-3 VPN, where a
> > different label is used to indicate the outgoing interface, etc.
> If you're thinking about the LID, I don't think it is analogous to
> requiring an additional label. It is adding additional bits to the
> switchID that are of consequence to the final Rbridge only. Also, I
> understand that the arguments for including a LID may not be technically
> strong enough to merit the overhead they add.

My concern  for the LID isn't just the bits that it adds to the
header.  It is the additional table space required by the hardware of
all the Rbridges to produce frames with different encapsulations based
upon the final outgoing interface.  Additionally, how many ports or
interfaces would be sufficient?  Why?

If you're not seriously trying to move that idea forward, there's
probably little point discussing it here, given the debate on the
other two.

Alia

Date: Mon, 23 Oct 2006 13:16:34 -0700
From: [email-masked]
To: "Gray, Eric" <[email-masked]>
Priority: normal
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 911

> 
> 	If we were to discard each solution as it comes to a point
> of some level of maturity in favor of a solution that also might
> address new problems, we will get nothing done.
> 
> --
> Eric
> 

With the caveat that I have not been following the discussion (I'm still travelling with limited opportunity for email),
although Eric's statement is true---that constantly changing for something slightly better means things never converge---I
don't think the layout of the shim header is that big a change. So if changing it means that TRILL will be
suitable for more things, or more likely to be adopted, then it seems prudent---but it should be decided very quickly.

For each of the proposed fields, how valuable is each one? Are there places that will adopt TRILL with those, and
would not without them? Are there places that would adopt TRILL with the MPLS-like header, but wouldn't without it?

Radia

Content-class: urn:content-classes:message
Date: Mon, 23 Oct 2006 11:51:39 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1380

[email-masked] wrote:
> Silvano Gai wrote:
>> Joe,
>> 
>> Let's summarize what we are asking:
>> 
>> 1) today proposal has ingress RBridge address and egress RBdridge
>> address, but they are not carried both in the same frame. The first
>> request is to always carry both. I have hard time thinking that this
>> requires a change in the WG charter.
> 
> It does because they are required to support capabilities not
> indicated in the charter, namely traceroute.
> 

There is at least one justification that is in scope: namely that
a core RBridge that also supports 802.1au (congestion avoidance)
would benefit from having the source rbridge so that it could
properly encapsulate its BCN response without requiring a lookup
delay.

I am not convinced that the number of cases where this will be
relevant justifies the extra field -- but including to enable
this case would clearly be in scope.

One reason I currently do not estimate this as a worthwhile
feature is that I believe that the ingress and egress rbridge
will be a majority of the rbridges that any given packet 
traverses. But my perceptions are biased towards the edges
and the working group could come to a different assesment.

Without the source rbridge in the shim header there IS a
negative impact on an 802.1au bridge generating a BCN.
Is that not enough to make this an item to be considered?

From: "Gray, Eric" <[email-masked]>
To: Dinesh G Dutt <[email-masked]>, Joe Touch <[email-masked]>
Date: Mon, 23 Oct 2006 14:18:44 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 3457

Dinesh,

	Let me expand on what Joe said.

	There is a current proposal on the table, actually fairly
far along in development.  Because this exists, you and Silvano 
are obliged to show cause as to why this current proposal is not
sufficient to solve the problems we've decided to address - as a
working group, and as documented in the WG charter.

	This is not what you have done.  Instead, you suggest that
the solution you offer is better, because it also solves another 
set of problems.  This other set of problems is not currently in
the charter, hence the fact that your solution might be a better
answer from the perspective of solving these other problems is
not relevant, and the argument based on these other problems is
not sufficient to justify discarding what has been the consensus
solution to date.

	If we were to discard each solution as it comes to a point
of some level of maturity in favor of a solution that also might
address new problems, we will get nothing done.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
--> Sent: Monday, October 23, 2006 1:55 PM
--> To: Joe Touch
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> Good Morning Joe,
--> 
--> Joe Touch wrote:
--> > Anything not stated explicitly in the charter is 
--> out-of-scope, UNLESS it
--> > is needed to support something in the charter indirectly. 
-->  This isn't a
--> > matter of "permitted unless prohibited" - the point of 
--> the charter is to
--> > constrain the scope. It's also not a matter of "once you 
--> open the spec,
--> > anything is on the table"; that's not how charters work.
--> >   
--> I read the latest version of the P&AS at 
--> http://www.isi.edu/touch/pubs/draft-ietf-trill-prob-01.txt. 
--> I fail to 
--> see anything that precludes adding a source RBridge in the 
--> packet frame.
--> 
--> I also do not see anything that prevents using multiple 
--> shared trees to 
--> address the case of maximal link utilization for multicast. Since 
--> maximal link utilization is a part of the P&AS and the 
--> current solution 
--> of using source-Rbridge-based trees is not as efficient as multiple 
--> shared trees, FTAG addresses this requirement directly. 
--> Sure, you can 
--> attempt to alleviate the current situation by trying to 
--> build multple 
--> source-Rbridge-based trees, but FTAG provides a mechanism to do it 
--> better and also enables a host of other functionalities, 
--> that do not 
--> have to be called out in the charter.
--> 
--> In short, I'm unable to see how the addition of the two fields that 
--> Silvano & I are proposing requires a revisit or update of 
--> the charter. 
--> Since we're trying to address real-life problems (which includes 
--> troubleshooting), I continue to perceive a lack of 
--> technical merit in 
--> the arguments against addition of the two fields. I also 
--> continue to 
--> want to hear other voices in favor of or against the 
--> proposal and the 
--> reasons for their positions.
--> 
--> Dinesh
--> 
--> -- 
--> We make our world significant by the courage of our 
--> questions and by 
--> the depth of our answers.                               - Carl Sagan
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Mon, 23 Oct 2006 11:00:44 -0700
From: Joe Touch <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 2219

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBD98B30807435677F9F4F1E0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dinesh G Dutt wrote:
> Good Morning Joe,
>=20
> Joe Touch wrote:
>> Anything not stated explicitly in the charter is out-of-scope, UNLESS =
it
>> is needed to support something in the charter indirectly.  This isn't =
a
>> matter of "permitted unless prohibited" - the point of the charter is =
to
>> constrain the scope. It's also not a matter of "once you open the spec=
,
>> anything is on the table"; that's not how charters work.
>>  =20
> I read the latest version of the P&AS at
> http://www.isi.edu/touch/pubs/draft-ietf-trill-prob-01.txt. I fail to
> see anything that precludes adding a source RBridge in the packet frame=
=2E
>=20
> I also do not see anything that prevents using multiple shared trees to=

> address the case of maximal link utilization for multicast.
=2E..

> In short, I'm unable to see how the addition of the two fields that
> Silvano & I are proposing requires a revisit or update of the charter.

IMO, you need to make the case that these are REQUIRED by the charter,
not "not PREVENTED" by the charter.

> Since we're trying to address real-life problems (which includes
> troubleshooting),

Which is NOT in the charter, i.e., not functions beyond that supported
by 802.

> I continue to perceive a lack of technical merit in
> the arguments against addition of the two fields.

The issue is the lack of their necessity to support the current charter.
 You need to make the case that they are _required_ to support the
current charter, or make the case to change the charter.

JOe

--------------enigBD98B30807435677F9F4F1E0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigBD98B30807435677F9F4F1E0--

Date: Mon, 23 Oct 2006 10:54:34 -0700
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1786

Good Morning Joe,

Joe Touch wrote:
> Anything not stated explicitly in the charter is out-of-scope, UNLESS it
> is needed to support something in the charter indirectly.  This isn't a
> matter of "permitted unless prohibited" - the point of the charter is to
> constrain the scope. It's also not a matter of "once you open the spec,
> anything is on the table"; that's not how charters work.
>   
I read the latest version of the P&AS at 
http://www.isi.edu/touch/pubs/draft-ietf-trill-prob-01.txt. I fail to 
see anything that precludes adding a source RBridge in the packet frame.

I also do not see anything that prevents using multiple shared trees to 
address the case of maximal link utilization for multicast. Since 
maximal link utilization is a part of the P&AS and the current solution 
of using source-Rbridge-based trees is not as efficient as multiple 
shared trees, FTAG addresses this requirement directly. Sure, you can 
attempt to alleviate the current situation by trying to build multple 
source-Rbridge-based trees, but FTAG provides a mechanism to do it 
better and also enables a host of other functionalities, that do not 
have to be called out in the charter.

In short, I'm unable to see how the addition of the two fields that 
Silvano & I are proposing requires a revisit or update of the charter. 
Since we're trying to address real-life problems (which includes 
troubleshooting), I continue to perceive a lack of technical merit in 
the arguments against addition of the two fields. I also continue to 
want to hear other voices in favor of or against the proposal and the 
reasons for their positions.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

From: "Gray, Eric" <[email-masked]>
To: [email-masked]
Date: Mon, 23 Oct 2006 13:16:30 -0400
Subject: [rbridge] RBridge Architecture
Status: RO
Content-Length: 611

A new version of the Architecture draft is now available at the ID site:

http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt

In this latest version, minor changes were made to address "finishing-up"
editorial comments as follows:

Section 5 now has a brief summary of how this architecture addresses the
current problem statement and applcability draft concerns.  Previously,
this simply said that these were "for further study."

Some text having to do with protocol details beyond scope for this draft
was removed from section 4.6.1.

References were brought more up to date.

--
Eric 

Date: Mon, 23 Oct 2006 09:17:11 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 4844

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig087D26040D775849E62FA63D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> Let's summarize what we are asking:
>=20
> 1) today proposal has ingress RBridge address and egress RBdridge
> address, but they are not carried both in the same frame. The first
> request is to always carry both. I have hard time thinking that this
> requires a change in the WG charter.

It does because they are required to support capabilities not indicated
in the charter, namely traceroute.

Whether they impact performance on the line, or help performance at the
nodes, is orthogonal unless omitting the source address prevents
802-equivalent performance.

> We showed that on a 512 bytes frame the difference in overhead between
> the current TRILL solution and what we propose is 0.37%. Difficult to
> argue that it should not be done for bandwidth reason.
>=20
> 2) we are asking to add an FTAG field to better support forwarding, wit=
h
> particular emphasis on Multicast. The current TRILL proposal supports
> only ingress trees and not shared trees. Shared trees are the preferred=

> way to do multicast. I haven't read a single reply on FTAG that
> addresses Multicast.

Again, the goal of rbridges is 802 equivalence with modern routing.
Multicast might not be a case where there's a benefit for modern routing
at the link layer. If this is a performance issue then it's relevant
only if existing speeds cannot be supported without the FTAG.

> I don't think that to do these two simple changes we need to modify the=

> WG charter. If the WG chairs think so, please let us know.

I've given my interpretation of why they are not in the charter; at
best, it's ambiguous given the current arguments. But I'm not the chair
or AD, who are the arbiters.

Joe

>=20
> -- Silvano
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Monday, October 23, 2006 8:28 AM
>> To: Silvano Gai
>> Cc: Dinesh G Dutt; [email-masked]
>> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> Let's get this straight so we don't waste any more time: "are you
> saying
>>> that the WG charter is written, the A&P statement is drafted" and
>>> therefore the WG is no longer interested in listening to other
>>> requirements?
>> Anything not stated explicitly in the charter is out-of-scope, UNLESS
> it
>> is needed to support something in the charter indirectly.  This isn't
> a
>> matter of "permitted unless prohibited" - the point of the charter is
> to
>> constrain the scope. It's also not a matter of "once you open the
> spec,
>> anything is on the table"; that's not how charters work.
>>
>> I - and Eric - are saying that if you want to add requirements, FIRST
>> you need to get the WG consensus on changing the charter. THEN we need=

>> to get the AD's on board. THEN we do the work to address the
> requirements.
>> Joe
>>
>>> -- Silvano
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
> [mailto:[email-masked]]
>>> On
>>>> Behalf Of Joe Touch
>>>> Sent: Monday, October 23, 2006 6:36 AM
>>>> To: Dinesh G Dutt
>>>> Cc: [email-masked]
>>>> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
>>>>
>>>>
>>>>
>>>> Dinesh G Dutt wrote:
>>>>> Hi Eric,
>>>>>
>>>>> Gray, Eric wrote:
>>>>>> The argument that "You're changing things, and while you're at
> it,
>>>>>> why not change these other things" is a particularly obnoxious
> old
>>>>>> Dinosaur.
>>>>>>
>>>>> I have shown the reasons and with the exception of you and Joe, I
>>>>> haven't heard any objection to including the ingress Rbridge (at
>>> least)
>>>>> or the FTAG. So, from a democratic spirit, it is upto you two to
>>> give us
>>>>> technical reasons for objecting instead of saying "its not in the
>>>>> charter" or "you can't change that". The charter doesn't
> explicitly
>>>>> forbid doing traceroute, for example.
>>>> Charters define what is permitted; that which is not permitted is
>>>> prohibited, unless it is needed to support what is permitted.
>>>>
>>>> Otherwise, charters would be wide-open to anything not prohibited;
> we
>>>> don't have time to enumerate that list.
>>>>
>>>> Joe
>=20

--------------enig087D26040D775849E62FA63D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig087D26040D775849E62FA63D--

Content-class: urn:content-classes:message
Date: Mon, 23 Oct 2006 09:08:49 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 3311

Joe,

Let's summarize what we are asking:

1) today proposal has ingress RBridge address and egress RBdridge
address, but they are not carried both in the same frame. The first
request is to always carry both. I have hard time thinking that this
requires a change in the WG charter.

We showed that on a 512 bytes frame the difference in overhead between
the current TRILL solution and what we propose is 0.37%. Difficult to
argue that it should not be done for bandwidth reason.

2) we are asking to add an FTAG field to better support forwarding, with
particular emphasis on Multicast. The current TRILL proposal supports
only ingress trees and not shared trees. Shared trees are the preferred
way to do multicast. I haven't read a single reply on FTAG that
addresses Multicast.

I don't think that to do these two simple changes we need to modify the
WG charter. If the WG chairs think so, please let us know.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, October 23, 2006 8:28 AM
> To: Silvano Gai
> Cc: Dinesh G Dutt; [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > Let's get this straight so we don't waste any more time: "are you
saying
> > that the WG charter is written, the A&P statement is drafted" and
> > therefore the WG is no longer interested in listening to other
> > requirements?
> 
> Anything not stated explicitly in the charter is out-of-scope, UNLESS
it
> is needed to support something in the charter indirectly.  This isn't
a
> matter of "permitted unless prohibited" - the point of the charter is
to
> constrain the scope. It's also not a matter of "once you open the
spec,
> anything is on the table"; that's not how charters work.
> 
> I - and Eric - are saying that if you want to add requirements, FIRST
> you need to get the WG consensus on changing the charter. THEN we need
> to get the AD's on board. THEN we do the work to address the
requirements.
> 
> Joe
> 
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: [email-masked]
[mailto:[email-masked]]
> > On
> >> Behalf Of Joe Touch
> >> Sent: Monday, October 23, 2006 6:36 AM
> >> To: Dinesh G Dutt
> >> Cc: [email-masked]
> >> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
> >>
> >>
> >>
> >> Dinesh G Dutt wrote:
> >>> Hi Eric,
> >>>
> >>> Gray, Eric wrote:
> >>>> The argument that "You're changing things, and while you're at
it,
> >>>> why not change these other things" is a particularly obnoxious
old
> >>>> Dinosaur.
> >>>>
> >>> I have shown the reasons and with the exception of you and Joe, I
> >>> haven't heard any objection to including the ingress Rbridge (at
> > least)
> >>> or the FTAG. So, from a democratic spirit, it is upto you two to
> > give us
> >>> technical reasons for objecting instead of saying "its not in the
> >>> charter" or "you can't change that". The charter doesn't
explicitly
> >>> forbid doing traceroute, for example.
> >> Charters define what is permitted; that which is not permitted is
> >> prohibited, unless it is needed to support what is permitted.
> >>
> >> Otherwise, charters would be wide-open to anything not prohibited;
we
> >> don't have time to enumerate that list.
> >>
> >> Joe
> >

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Joe Touch <[email-masked]>, Dinesh G Dutt <[email-masked]>
Date: Mon, 23 Oct 2006 11:49:33 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 3166

Silvano,

	Joe said nothing of the kind.

	You are certainly welcome to discuss your ideas.  What the 
charter does is constrain the working group to a specific set of
goals.  As far as I can tell, and I think that there have been 
others who have indicated a similar opinion, your ideas (or those
of Dinesh, and yourself) do not fit within the existing charter's
scope.  Consequently, before the WG can do anything about your
ideas - beyond listening to them - you (and Dinesh) need to get
the consensus of the WG to expand the charter to include your
goals as well as those that are already included.

	The "default" under circumstances such as the ones that
prevail now in this WG, is to continue on current course.  So,
if you want to change the current course, you have to convince
the WG that doing so is necessary.

	Nobody in the WG is under any obligation to convince you
that we should stay on the current course, as oulined in the WG
charter.  Nobody in the WG is under any obligation to justify
the way things work, here in the IETF, either.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Monday, October 23, 2006 11:23 AM
--> To: Joe Touch; Dinesh G Dutt
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 
--> Joe,
--> 
--> Let's get this straight so we don't waste any more time: 
--> "are you saying
--> that the WG charter is written, the A&P statement is drafted" and
--> therefore the WG is no longer interested in listening to other
--> requirements?
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]
--> On
--> > Behalf Of Joe Touch
--> > Sent: Monday, October 23, 2006 6:36 AM
--> > To: Dinesh G Dutt
--> > Cc: [email-masked]
--> > Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> > 
--> > 
--> > 
--> > Dinesh G Dutt wrote:
--> > > Hi Eric,
--> > >
--> > > Gray, Eric wrote:
--> > >> The argument that "You're changing things, and while 
--> you're at it,
--> > >> why not change these other things" is a particularly 
--> obnoxious old
--> > >> Dinosaur.
--> > >>
--> > > I have shown the reasons and with the exception of you 
--> and Joe, I
--> > > haven't heard any objection to including the ingress Rbridge (at
--> least)
--> > > or the FTAG. So, from a democratic spirit, it is upto you two to
--> give us
--> > > technical reasons for objecting instead of saying "its 
--> not in the
--> > > charter" or "you can't change that". The charter 
--> doesn't explicitly
--> > > forbid doing traceroute, for example.
--> > 
--> > Charters define what is permitted; that which is not permitted is
--> > prohibited, unless it is needed to support what is permitted.
--> > 
--> > Otherwise, charters would be wide-open to anything not 
--> prohibited; we
--> > don't have time to enumerate that list.
--> > 
--> > Joe
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Mon, 23 Oct 2006 08:28:09 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 2754

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig84C653A300703692A56BCD79
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> Let's get this straight so we don't waste any more time: "are you sayin=
g
> that the WG charter is written, the A&P statement is drafted" and
> therefore the WG is no longer interested in listening to other
> requirements?

Anything not stated explicitly in the charter is out-of-scope, UNLESS it
is needed to support something in the charter indirectly.  This isn't a
matter of "permitted unless prohibited" - the point of the charter is to
constrain the scope. It's also not a matter of "once you open the spec,
anything is on the table"; that's not how charters work.

I - and Eric - are saying that if you want to add requirements, FIRST
you need to get the WG consensus on changing the charter. THEN we need
to get the AD's on board. THEN we do the work to address the requirements=
=2E

Joe

>=20
> -- Silvano
>=20
>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
> On
>> Behalf Of Joe Touch
>> Sent: Monday, October 23, 2006 6:36 AM
>> To: Dinesh G Dutt
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
>>
>>
>>
>> Dinesh G Dutt wrote:
>>> Hi Eric,
>>>
>>> Gray, Eric wrote:
>>>> The argument that "You're changing things, and while you're at it,
>>>> why not change these other things" is a particularly obnoxious old
>>>> Dinosaur.
>>>>
>>> I have shown the reasons and with the exception of you and Joe, I
>>> haven't heard any objection to including the ingress Rbridge (at
> least)
>>> or the FTAG. So, from a democratic spirit, it is upto you two to
> give us
>>> technical reasons for objecting instead of saying "its not in the
>>> charter" or "you can't change that". The charter doesn't explicitly
>>> forbid doing traceroute, for example.
>> Charters define what is permitted; that which is not permitted is
>> prohibited, unless it is needed to support what is permitted.
>>
>> Otherwise, charters would be wide-open to anything not prohibited; we
>> don't have time to enumerate that list.
>>
>> Joe
>=20

--------------enig84C653A300703692A56BCD79
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig84C653A300703692A56BCD79--

Content-class: urn:content-classes:message
Date: Mon, 23 Oct 2006 08:22:38 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1409

Joe,

Let's get this straight so we don't waste any more time: "are you saying
that the WG charter is written, the A&P statement is drafted" and
therefore the WG is no longer interested in listening to other
requirements?

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Joe Touch
> Sent: Monday, October 23, 2006 6:36 AM
> To: Dinesh G Dutt
> Cc: [email-masked]
> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
> 
> 
> 
> Dinesh G Dutt wrote:
> > Hi Eric,
> >
> > Gray, Eric wrote:
> >> The argument that "You're changing things, and while you're at it,
> >> why not change these other things" is a particularly obnoxious old
> >> Dinosaur.
> >>
> > I have shown the reasons and with the exception of you and Joe, I
> > haven't heard any objection to including the ingress Rbridge (at
least)
> > or the FTAG. So, from a democratic spirit, it is upto you two to
give us
> > technical reasons for objecting instead of saying "its not in the
> > charter" or "you can't change that". The charter doesn't explicitly
> > forbid doing traceroute, for example.
> 
> Charters define what is permitted; that which is not permitted is
> prohibited, unless it is needed to support what is permitted.
> 
> Otherwise, charters would be wide-open to anything not prohibited; we
> don't have time to enumerate that list.
> 
> Joe

Date: Mon, 23 Oct 2006 06:36:09 -0700
From: Joe Touch <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1584

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2CB808ECB334A04493246675
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dinesh G Dutt wrote:
> Hi Eric,
>=20
> Gray, Eric wrote:
>> The argument that "You're changing things, and while you're at it,
>> why not change these other things" is a particularly obnoxious old=20
>> Dinosaur. =20
>>  =20
> I have shown the reasons and with the exception of you and Joe, I=20
> haven't heard any objection to including the ingress Rbridge (at least)=
=20
> or the FTAG. So, from a democratic spirit, it is upto you two to give u=
s=20
> technical reasons for objecting instead of saying "its not in the
> charter" or "you can't change that". The charter doesn't explicitly=20
> forbid doing traceroute, for example.

Charters define what is permitted; that which is not permitted is
prohibited, unless it is needed to support what is permitted.

Otherwise, charters would be wide-open to anything not prohibited; we
don't have time to enumerate that list.

Joe

--------------enig2CB808ECB334A04493246675
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2CB808ECB334A04493246675--

Content-class: urn:content-classes:message
Date: Sun, 22 Oct 2006 20:11:15 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 2234

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Sunday, October 22, 2006 12:02 PM
> To: Silvano Gai
> Cc: Radia Perlman; Gray, Eric; Dino Farinacci (dino);
[email-masked]
> Subject: Re: Time for a summary?
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > Let me first point out the TRILL charter:
> > "(4) Produce a (set of) TRILL specification(s) for standards track
> > publication that define(s) what information must be carried in an
> > encapsulation header for data packets. Although this work will
> > initially be undertaken only for 802.1-compliant links, it
> > may later be expanded to non-802.1 links, so the design should be
> > link-layer agnostic to whatever extent possible."
> >
> > The spec can define the TRILL header to be 4 bytes, but the overhead
> > introduced on 802.1-compliant links is 18 bytes.
> 
> You're talking about the total header; the TRILL-specific portion is
the
> shim. Please see Eric's other posts.

The overhead is given by the total header, you don't send the the
TRILL-specific portion only.

> 
> > Therefore, when we compare two solutions from the bandwidth
perspective,
> > we need to say: "the current proposal introduces an overhead of 18
> > bytes, the new proposal as modified by Dinesh introduces an overhead
of
> > 20 bytes".
> 
> There are two issues that are distinct - one is running over any 802.1
> tunnel; the other are TRILL-specific.
> 
> > I also pointed out that 18 is not a multiple of 4 and therefore it
> > requires the payload to be realigned, while 20 is a multiple of 4,
it
> > does not require realignment, it provides more features, and
therefore
> > IMHO it is superior.
> 
> The argument for alignment has not been convincing. 802.1q is a
similar
> shim header and adds 4 bytes. Tunnels always deal with aligning their
> payloads separately; given existing ethernet hardware is capable of
> dealing with 14-byte realignment of its payload, we can to.
> 

If you spend some time trying to understand my drawings in the mail to
Eric you will see that there is no payload realignment in 1Q.

The existing Ethernet HW aligns the payload natively, it does not
realign.

MPLS, 1Q and 1S DO NOT REALLIGN THE PAYLOAD.

-- Silvano

Date: Sun, 22 Oct 2006 16:14:40 -0700
From: Joe Touch <[email-masked]>
To: [email-masked]
Subject: [rbridge] updated draft-ietf-trill-prob-01.txt
Status: RO
Content-Length: 1245

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig94C918964D4112C9950DFE52
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, all,

I've just submitted an update to the P&AS which incorporates all
suggestions excepting only Donald's of 10/18/06; I'm not sure what the
specific mods needed for that would be -- I'm hoping we can resolve that
in San Diego.

It should appear in the usual places shortly; until then, it's available
now at:
http://www.isi.edu/touch/pubs/draft-ietf-trill-prob-01.txt

There are a number of unresolved questions in the P&AS. It'd be useful
to scan the document and see how to help contribute so we can move this
to closure.

Thanks,

Joe

--------------enig94C918964D4112C9950DFE52
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig94C918964D4112C9950DFE52--

Date: Sun, 22 Oct 2006 15:56:00 -0700
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 690

Silvano did compare 18 bytes to 20. If you want the comparison done your 
way, it is 4 bytes vs 6.

Dinesh
Joe Touch wrote:
> Correction below:
>
> Silvano Gai wrote:
>   
>> Let's also use some quantitative analysis. The TRILL Ethernet header
>> currently defined in:
>> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
>> .txt
>> is 18 bytes
>>     
>
> That doc refers to the shim as defined in:
> draft-bryant-perlman-trill-pwe-encap-00.txt
>
> The shim - excluding the outer ethernet header - is 4 bytes, not 18.
>   
-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Sun, 22 Oct 2006 12:02:29 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 2262

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6600709B136E0A633FA281FD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,=20
>=20
> Let me first point out the TRILL charter:
> "(4) Produce a (set of) TRILL specification(s) for standards track
> publication that define(s) what information must be carried in an
> encapsulation header for data packets. Although this work will
> initially be undertaken only for 802.1-compliant links, it
> may later be expanded to non-802.1 links, so the design should be
> link-layer agnostic to whatever extent possible."
>=20
> The spec can define the TRILL header to be 4 bytes, but the overhead
> introduced on 802.1-compliant links is 18 bytes.

You're talking about the total header; the TRILL-specific portion is the
shim. Please see Eric's other posts.

> Therefore, when we compare two solutions from the bandwidth perspective=
,
> we need to say: "the current proposal introduces an overhead of 18
> bytes, the new proposal as modified by Dinesh introduces an overhead of=

> 20 bytes".

There are two issues that are distinct - one is running over any 802.1
tunnel; the other are TRILL-specific.

> I also pointed out that 18 is not a multiple of 4 and therefore it
> requires the payload to be realigned, while 20 is a multiple of 4, it
> does not require realignment, it provides more features, and therefore
> IMHO it is superior.

The argument for alignment has not been convincing. 802.1q is a similar
shim header and adds 4 bytes. Tunnels always deal with aligning their
payloads separately; given existing ethernet hardware is capable of
dealing with 14-byte realignment of its payload, we can to.

Joe

--------------enig6600709B136E0A633FA281FD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig6600709B136E0A633FA281FD--

Content-class: urn:content-classes:message
Date: Sun, 22 Oct 2006 12:00:45 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 15538

Eric,

This is your point of view and I disagree with it.

For the High Performance market (very relevant to TRILL), the switch
port ASICs are all limited by the buffer memory bandwidth. Therefore I
reaffirm my point that having a solution that does not require payload
realignment is superior.

Your point about MPLS is invalid, because I showed you with the diagram
that MPLS, .1Q, and 1S do not require payload realignment.

Your point about address representation in implementation is invalid,
since I am talking about payload realignment and I never mentioned
anything about header storage/processing.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 20, 2006 12:05 PM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] FTag
> 
> Silvano,
> 
> 	I was working on the replies to you analysis below, thinking
> I would not complete them this week.  As you can see, I had a bit
> more time than I expected to have and was able to complete my
> response earlier than I thought.
> 
> 	As a first observation, whenever someone says "this is not
> hardware friendly", my gut reaction is to ask "for what hardware"?
> 
> 	As a second observation, although the number of MPLS labels
> may change, the Ethernet encapsulations defined for PWE3 already
> uses a 32-bit alignment assumption independent of Ethernet frame
> alignment either "below" or "above" the MPLS SHIM.  Consequently,
> there is definitely hardware in existence, in development or both
> that deals with this alleged "alignment issue."
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[email-masked]]
> --> Sent: Wednesday, October 18, 2006 12:04 PM
> --> To: Gray, Eric
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> -->
> --> Eric,
> -->
> --> Let me depict you what happens when you insert one MPLS
> --> label, [or] a 1Q option or a 1S option
> -->
> --> Original:
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    Ethertype   |   Payload     |
> --> +--------------------------------+
> --> |                                |
> --> |         ...........            |
> -->
> -->
> --> Original + Opt (where Opt can be MPLS, 1Q or 1S)
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    Ethertype   |      Opt      |
> --> +--------------------------------+
> --> |      opt       |   Payload     |
> --> +--------------------------------+
> --> |                                |
> --> |         ...........            |
> -->
> --> The HW that perform the insertion/removal does not need to
> --> realign the payload that is in its buffer.
> -->
> 
> This is an interesting, but inefficient, storage scheme in the
> first place.  With this storage scheme, the same DA and/or SA
> values will be stored in uncompressed format hundreds or even
> thousands of times in any sizable buffer.
> 
> I think it is unrealistic to assert that this is the only way
> that this information might be stored in a buffer.  If it is
> not stored in this precise fashion, then the below observations
> are invalidated.
> 
> -->
> --> Now Let's consider the encapsulation/decapsulation function
> --> by looking at the Original frame + TRILL header (as proposed
> --> by the current draft)
> 
> Let's be clear about what is proposed by the current draft.
> 
> The encapsulation below is not - in any way - proposed by the
> current draft as it does not assume that there will be a 16-bit
> "slop factor" as you indicate with "????????" in your picture.
> 
> --> +--------------------------------+
> --> |         Outer DA               |
> --> +----------------+---------------+
> --> |    Outer DA    |  Outer SA     |
> --> +----------------+---------------+
> --> |         Outer SA               |
> --> +--------------------------------+
> --> |Ethertype=TRILL |   Trill Shim  |
> --> +--------------------------------+
> --> |  Trill Shim    |  ????????     |
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    Ethertype   |   Payload     |
> --> +--------------------------------+
> --> |                                |
> --> |         ...........            |
> 
> If this was proposed by "the current draft", then it should be
> put forward as "an example only" in later versions.  An equally
> valid example may be either of the following:
> 
>  +--------------------------------+
>  |         Outer DA               |
>  +----------------+---------------+
>  |    Outer DA    |  Outer SA     |
>  +----------------+---------------+
>  |         Outer SA               |
>  +--------------------------------+
>  |Ethertype=TRILL |   Trill Shim  |
>  +--------------------------------+
>  |  Trill Shim    |      DA       |
>  +--------------------------------+
>  |               DA               |
>  +----------------+---------------+
>  |               SA               |
>  +----------------+---------------+
>  |       SA       |   Ethertype   |
>  +--------------------------------+
>  |            Payload             |
>  +                                +
>  |          ...........           |
> 
> OR
> 
>  +--------------------------------+
>  |         Outer DA               |
>  +----------------+---------------+
>  |    Outer DA    |  Outer SA     |
>  +----------------+---------------+
>  |         Outer SA               |
>  +--------------------------------+
>  |Ethertype=TRILL |   Trill Shim  |
>  +--------------------------------+
>  |  Trill Shim    |      DA       |
>  +--------------------------------+
>  |               DA               |
>  +----------------+---------------+
>  |               SA               |
>  +----------------+---------------+
>  |       SA       |     0x8100    |
>  +--------------------------------+
>  | P |  VLAN ID   |   Ethertype   |
>  +--------------------------------+
>  |            Payload             |
>  +                                +
>  |          ...........           |
> 
> And there are others.  Note that this is a depiction of what a
> frame would look like "on the wire".  It is inappropriate for
> us to make assumptions about what it would look like in memory
> for any specific implementation.
> 
> In any case, when it goes on the wire, the 16-bit "field" shown
> in your example would not be present unless there was reason to
> have it.
> 
> -->
> --> If you don't have the 16 bits indicated by ???????, the
> --> hardware will need to realign the inner frame. The frame
> --> is not on the wire. The frame sits in the [frame] buffer
> --> and the memory bandwidth of the packet buffer is today
> --> the MOST important consideration in port ASIC design.
> 
> From the above discussions, you should be able to see the following:
> 
> 1) It is inappropriate to make assumptions about how frames are
>    stored in memory prior to being put on the wire as we are not
>    here to standardize that.
> 
> 2) It is likely that any such assumptions will be incorrect in
>    at least some implementations.
> 
> Based on this, your otherwise reasonable argument is invalidated
> as it is based on inappropriate, and incorrect, assumptions about
> implementations.
> 
> -->
> --> More inline
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[email-masked]]
> --> > Sent: Wednesday, October 18, 2006 4:57 AM
> --> > To: Silvano Gai
> --> > Cc: [email-masked]
> --> > Subject: RE: [rbridge] FTag
> --> >
> --> > Silvano,
> --> >
> --> > Let me answer your points in order, leaving out irrelevant
issues:
> --> >
> --> > <Your Point> N*32 is correct, when including Ethernet
options/shims
> --> >              (e.g. .1Q or .1S).  This is hardware friendly,
because
> --> > 		 alignment doesn't change going from one header
to
> another.
> --> >
> --> > There are a few different "Ethernet" encapsulations, once we
start
> to
> --> > include Ethernet options and the shims associated with those
> options.
> --> >
> --> > First, and I believe most important, the "shim" we are talking
about
> --> > (in TRILL) is not an Ethernet option (or associated shim).  It's
a
> --> > "shim" as a separate "layer."  Otherwise, it would be
inappropriate
> --> > for us to do this work here (in TRILL, as part of the IETF).
> -->
> --> From the above picture it should be clear that you should
> --> consider the TRILL header as a whole, and the TRILL header
> --> as only one form of Ethernet encapsulation.
> 
> Actually, what should be clear is that the intent is explicitly
> NOT to define an aggregate header type, combining a specific
> Ethernet header and TRILL SHIM.  Not only would doing so limit
> the usefulness of RBridges in general, it would also involve our
> doing work that is strictly out of scope in the IETF.
> 
> What we need to do is recognize that both tunnel, and native,
> encapsulations may be any defined Ethernet encapsulation that
> is supported by the interfaces of any specific implementation.
> 
> -->
> --> >
> --> > Second, "Ethernet" headers do not all align the same.
> --> >
> -->
> --> Agreed, but that is not my concern, My concern is to not
> --> change their alignment due to the insertion/removal of the
> --> TRILL header.
> 
> However, it is my concern.  A key reason for using a layer
> model in networking protocols is to separate functions and
> their definitions in ways that isolate the workings of one
> layer from the changes in another.
> 
> -->
> --> > Currently, we are talking about having a single Ethertype
defined to
> --> > distinguish inter-RBridge traffic from other types of Ethernet
> frames.
> --> > If your implementation produces 32-bit aligned Ethernet frames,
> using
> --> > 802.1Q, then it will similarly produce 32-bit aligned frames -
prior
> --> > to considering the TRILL shim - using the new Ethertype.
> --> >
> --> > We are not proposing a change in any Ethernet frame/header
format.
> -->
> --> Neither do I.
> 
> This is semantics.  You are clearly proposing that we should
> define a new type of Ethernet header - calling it a TRILL
> Ethernet header - and that is not what we're supposed to be
> doing.
> 
> -->
> --> >
> --> > The reference to 802.1Q is slightly disingenuous, because 802.1Q
> --> > effectively displaces the existing Ethertype by 32 bits.  802.1Q
> --> > "shims" include the Ethertype, because they replace the original
> --> > one with 0x8100 and have to include the original in the "shim."
> --> >
> --> > I assume that a similar observation could be made about 802.1S.
> -->
> --> Yes and a similar observation can be made for MPLS, but all these
> three
> --> do not change the alignment of the fields that follow.
> 
> And, as you may have noted from the above, if you're talking
> about frame alignment in a buffer, this depends a lot on the
> specifics of any implementation.
> 
> As I pointed out above, there is already a "proof of concept"
> example in PWE3 Ethernet encapsulation.
> 
> -->
> --> >
> --> > In TRILL, we are not replacing the original Ethertype, we are
adding
> --> > a new encapsulation.  The original Ethertype stays in the
original
> --> > - re-encapsulated, or tunneled - Ethernet frame.  Therefore,
there's
> --> > no reason to consider the Ethertype to be part of the TRILL
shim.
> -->
> --> As I told before you need to consider the whole TRILL header, i.e.
> --> 6 bytes of DA
> --> 6 bytes of SA
> --> 2 bytes of Ethertype
> --> 4 bytes of shim
> --> ----------------------
> --> 18 bytes
> 
> Yes, you have asserted this, and I have refuted it.
> 
> Hence we are in disagreement on that point and we should let other
> people make their own assertions (and refutations) and see how things
> turn out.
> 
> -->
> --> Which is 2 bytes short of N*32, i.e. it is not HW friendly.
> -->
> --> For this reason I propose that Ethertype + shim should be
> --> N*32 to be HW
> --> friendly.
> -->
> -->
> --> >
> --> > <Your Point> TRILL should adopt this model for its shim header -
the
> --> >              Ethertype should be included as part of computing
> "shim"
> --> >              size.
> --> >
> --> > In TRILL, we are not replacing the original Ethertype, we are
adding
> --> > a new encapsulation.  The original Ethertype stays in the
original
> --> > - re-encapsulated, or tunneled - Ethernet frame.  Therefore,
there's
> --> > no reason to consider the Ethertype to be part of the TRILL
shim.
> --> >
> --> > <Your Point> TRILL should optimize the Ethernet case that will
cover
> --> >              99% of TRILL applications.
> --> >
> --> > Coverage is slightly more complete than that.  Considering all
of
> the
> --> > layer 2 encapsulations that currently come under an Ethernet
> umbrella,
> --> > TRILL applications are 100% included.
> --> >
> --> > I think we are essentially in agreement on this point.
> --> >
> --> > <Your Point> TRILL bridges will be implemented mainly in
hardware
> and
> --> >              the encapsulation and decapsulation functions need
to
> be
> --> >              HW friendly.
> --> >
> --> > Okay.  I was not making any other point - except to say that
> alignment
> --> > is usually a software concern, especially in initial design.
> --> >
> --> > Let me be blunt, alignment does not factor into initial hardware
> design,
> --> > but is an issue with hardware re-use complexity.  Bits on a wire
are
> not
> --> > "aligned" - you simply collect them as they arrive, serially.
> -->
> --> I agree that bits on the wire are not aligned, but you need to
buffer
> --> the incoming frame (or at least part of it) until you have enough
> fields
> --> to perform your lookup and decide what to do with the frame. From
that
> --> point on the frame is not on the wire, it is in the packet buffer
and
> --> alignment is crucial at the performance we are talking about.
> 
> This is perhaps the most specious part of the argument.  While a huge
> majority of switch builders use essentially similar buffering models,
> at an architectural level, the details of how and where the frames are
> buffered is very much a part of the "secret sauce" of implementations.
> 
> Given the number of potential ways of doing input buffering, and the
> likelihood that we are going to be able to get enough data on specific
> implementations to perform any sort of meaningful statistical
analysis,
> I see no reason to assign any greater validity to the assumption that
> frame alignment is important than to the assumption that it is not.
> 
> -->
> --> I hope this time I made my point more clear
> 
> It did.  I had thought you were talking about the importance of
> alignment in framing hardware, and you clarified that you were
> talking about buffering.
> 
> This doesn't change the fact that I think you're wrong, but it
> does help me to understand exactly what you're wrong about.  :-)
> 
> -->
> --> -- Silvano
> -- [SNIP] --

Content-class: urn:content-classes:message
Date: Sun, 22 Oct 2006 11:55:03 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 2278

Joe, 

Let me first point out the TRILL charter:
"(4) Produce a (set of) TRILL specification(s) for standards track
publication that define(s) what information must be carried in an
encapsulation header for data packets. Although this work will
initially be undertaken only for 802.1-compliant links, it
may later be expanded to non-802.1 links, so the design should be
link-layer agnostic to whatever extent possible."

The spec can define the TRILL header to be 4 bytes, but the overhead
introduced on 802.1-compliant links is 18 bytes.

Therefore, when we compare two solutions from the bandwidth perspective,
we need to say: "the current proposal introduces an overhead of 18
bytes, the new proposal as modified by Dinesh introduces an overhead of
20 bytes".

I also pointed out that 18 is not a multiple of 4 and therefore it
requires the payload to be realigned, while 20 is a multiple of 4, it
does not require realignment, it provides more features, and therefore
IMHO it is superior.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Saturday, October 21, 2006 10:24 AM
> To: Silvano Gai
> Cc: Radia Perlman; Gray, Eric; Dino Farinacci (dino);
[email-masked]
> Subject: Re: Time for a summary?
> 
> Correction below:
> 
> Silvano Gai wrote:
> > Radia,
> >
> > I am not the right person for the summary, but let me give you my
> > perspective:
> >
> > It is bits Vs features:
> >
> > - One group advocates that features have been defined in the TRILL
> > charter and in the doc:
> > http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00.txt
> > and that we need to define a TRILL shim that accommodates these
features
> > using the minimum number of bits.
> >
> > - Another group claims that more features are required (e.g.
> > Troubleshooting, tracing, efficient multicast, etc.) and that these
> > features are worth few extra bytes.
> >
> > Let's also use some quantitative analysis. The TRILL Ethernet header
> > currently defined in:
> >
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
> > .txt
> > is 18 bytes
> 
> That doc refers to the shim as defined in:
> draft-bryant-perlman-trill-pwe-encap-00.txt
> 
> The shim - excluding the outer ethernet header - is 4 bytes, not 18.
> 

Date: Sat, 21 Oct 2006 10:23:36 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 1684

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig15C3BBF9420F9A509E1483F8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Correction below:

Silvano Gai wrote:
> Radia,
>=20
> I am not the right person for the summary, but let me give you my
> perspective:
>=20
> It is bits Vs features:
>=20
> - One group advocates that features have been defined in the TRILL
> charter and in the doc:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00.txt
> and that we need to define a TRILL shim that accommodates these feature=
s
> using the minimum number of bits.
>=20
> - Another group claims that more features are required (e.g.
> Troubleshooting, tracing, efficient multicast, etc.) and that these
> features are worth few extra bytes.
>=20
> Let's also use some quantitative analysis. The TRILL Ethernet header
> currently defined in:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
0
> .txt
> is 18 bytes

That doc refers to the shim as defined in:
draft-bryant-perlman-trill-pwe-encap-00.txt

The shim - excluding the outer ethernet header - is 4 bytes, not 18.

Joe

--------------enig15C3BBF9420F9A509E1483F8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig15C3BBF9420F9A509E1483F8--

Content-class: urn:content-classes:message
Date: Fri, 20 Oct 2006 17:49:59 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 1232

Eric,

Can you please reply to the following question?

                +---------------+
     100        |               |     X
--------------->|    RBridge    |----------------->
Not encapsulated|               |  Encapsulated
                +---------------+

When a frame of 1,000 bytes is received not-encapsulated by an RBridge
and transmitted encapsulated, how big is it (X) after the TRILL header
is added on Ethernet?

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 20, 2006 10:35 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: Time for a summary?
> 
> Silvano,
> 
> 
> 
> -- [SNIP] --
> -->
> --> Let's also use some quantitative analysis. The TRILL Ethernet
header
> --> currently defined in:
> -->
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-
> 00.txt
> --> is 18 bytes
> 
> We are _not_ defining an Ethernet header, and - whatever text it is
that
> leads you to believe we are - that text should be modified or removed.
> 
> We are simply using a standard Ethernet header, with an Ethertype that
> indicates that this header is followed by an Rbridge SHIM and another
> Ethernet header.
> 
> -- [SNIP] --

Date: Fri, 20 Oct 2006 14:22:41 -0700
From: Dinesh G Dutt <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 2302

Hi Alia,

Alia Atlas wrote:
> Hi Dinesh,
>
> On 10/20/06, Dinesh G Dutt <[email-masked]> wrote:
> Just because one is content to for Eric to do the work of discussing a
> common position doesn't indicate agreement with your position.
I apologize if my email communicated that point. I wanted to say that 
I'm curious to hear other voices in favor of or against the suggested 
changes.
>
> I certainly haven't heard a strong enough argument for including the
> ingress rbridge.  For instance, if you really want traceroute equiv,
> well, the encapsulated Ethernet frame contains  the source MAC from
> right before the entrance to the rbridge area.  Why can't that be used
> to get replies back?
The reason is that this requires the core Rbridges to also populate the 
tables with the mapping from MAC address to Rbridge. Not requiring the 
core Rbridges to maintain a large MAC table is one of the advantages of 
Rbridges.
>
> As to the Ftag, I've not heard why the 3 bits that are equiv to the
> EXP bits in an MPLS header coudn't be used to indicate a CoS related
> mechanism.
Again, if you read my rather lengthy email, you'll see why three bits 
are insufficient. The main reasons stem from having to do shared 
multicast trees. Eric points out a way to do it using an additional .1Q 
header and redefining (I think) the meaning of the VLAN field. That has 
the disadvantages that I pointed out in my emails to him.
>
> I am particularly against the idea, that hasn't gotten much
> discussion, of trying to include info about how the final rbridge
> should direct a packet out.  I think this impacts the scalability &
> requires additional knowledge be distributed to all the rbridges.  A
> similiar thing can be done with the MPLS Layer-3 VPN, where a
> different label is used to indicate the outgoing interface, etc.
If you're thinking about the LID, I don't think it is analogous to 
requiring an additional label. It is adding additional bits to the 
switchID that are of consequence to the final Rbridge only. Also, I 
understand that the arguments for including a LID may not be technically 
strong enough to merit the overhead they add.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Fri, 20 Oct 2006 14:09:25 -0700
From: "Alia Atlas" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1632

Hi Dinesh,

On 10/20/06, Dinesh G Dutt <[email-masked]> wrote:
> Hi Eric,
>
> Gray, Eric wrote:
> > The argument that "You're changing things, and while you're at it,
> > why not change these other things" is a particularly obnoxious old
> > Dinosaur.
> >
> I have shown the reasons and with the exception of you and Joe, I
> haven't heard any objection to including the ingress Rbridge (at least)
> or the FTAG. So, from a democratic spirit, it is upto you two to give us
> technical reasons for objecting instead of saying "its not in the
> charter" or "you can't change that". The charter doesn't explicitly
> forbid doing traceroute, for example.

Just because one is content to for Eric to do the work of discussing a
common position doesn't indicate agreement with your position.

I certainly haven't heard a strong enough argument for including the
ingress rbridge.  For instance, if you really want traceroute equiv,
well, the encapsulated Ethernet frame contains  the source MAC from
right before the entrance to the rbridge area.  Why can't that be used
to get replies back?

As to the Ftag, I've not heard why the 3 bits that are equiv to the
EXP bits in an MPLS header coudn't be used to indicate a CoS related
mechanism.

I am particularly against the idea, that hasn't gotten much
discussion, of trying to include info about how the final rbridge
should direct a packet out.  I think this impacts the scalability &
requires additional knowledge be distributed to all the rbridges.  A
similiar thing can be done with the MPLS Layer-3 VPN, where a
different label is used to indicate the outgoing interface, etc.

Alia

Content-class: urn:content-classes:message
Date: Fri, 20 Oct 2006 13:11:55 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 1005

[email-masked] wrote:
> Silvano,
> 
> 
> 
> -- [SNIP] --
> -->
> --> Let's also use some quantitative analysis. The TRILL Ethernet
> header 
> --> currently defined in:
> -->
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
> rotocol-00.txt --> is 18 bytes 
> 
> We are _not_ defining an Ethernet header, and - whatever text
> it is that leads you to believe we are - that text should be modified
> or removed. 
> 
> We are simply using a standard Ethernet header, with an
> Ethertype that indicates that this header is followed by an
> Rbridge SHIM and another Ethernet header.
> 

Ok, that aquatic feathered pet you have there is not a Duck,
but when we plan for its proper care and feeding can we admit
that it waddles and quacks?

As I see it, the RBridge L2 header is from a processing perspective
*very* similar to an 802.1au header. More so, they can stack
in either order.

So whether these headers are n*4 or 2+n*4 bytes long, shouldn't
their alignment rules match?

Date: Fri, 20 Oct 2006 12:45:26 -0700
From: Dinesh G Dutt <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 726

Hi Eric,

Gray, Eric wrote:
> The argument that "You're changing things, and while you're at it,
> why not change these other things" is a particularly obnoxious old 
> Dinosaur.  
>   
I have shown the reasons and with the exception of you and Joe, I 
haven't heard any objection to including the ingress Rbridge (at least) 
or the FTAG. So, from a democratic spirit, it is upto you two to give us 
technical reasons for objecting instead of saying "its not in the 
charter" or "you can't change that". The charter doesn't explicitly 
forbid doing traceroute, for example.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

From: "Gray, Eric" <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Date: Fri, 20 Oct 2006 15:12:21 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 3102

The argument that "You're changing things, and while you're at it,
why not change these other things" is a particularly obnoxious old 
Dinosaur.  

We have a charter to change certain things, and requirements to 
preserve certain other things.

If you cannot show why it is necessary to do what you propose in
order to accomplish our chartered goals, or meet our preservation
requirements, then you need to establish a consensus to change 
our charter.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
--> Sent: Friday, October 20, 2006 1:32 PM
--> To: Joe Touch
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> Good Morning,
--> 
--> Joe Touch wrote:
--> > There's no traceroute through ethernet switches now; I don't see why
--> > they ought to be supported uniquely in an rbridge.
--> >   
--> Could you provide me with technical reasons why you think this is 
--> unnecessary ? Ethernet bridges today don't have IS-IS. Why invent that ?

--> I repeat, troubleshooting networks is a critical aspect of 
--> any protocol. 
--> It can't be shoehorned in or added as an afterthought just 
--> like security 
--> cannot.
--> >> I'm unaware of any protocol, tunnelling or otherwise, 
--> that does not 
--> >> carry both an ingress and egress endpoint address in the 
--> header. Before 
--> >> you can utter that four letter word at me, remember that 
--> MPLS changes 
--> >> labels hop-by-hop; so having an ingress and egress in 
--> MPLS is not very
--> >> useful. I can visualize other optimizations and features 
--> that can be 
--> >> deployed if I have both ingress and egress addresses in a frame.
--> >>     
--> >
--> > This argues for using an IP header as the shim, at which 
--> point we just
--> > ought to deploy routers as rbridge nodes and call it a 
--> day. See below.
--> >   
--> I couldn't follow you here. Why does it assume an IP header 
--> as a shim ?
--> > IMO, tags argue either for VLANs over the rbridge (one 
--> per class) -
--> > which we had already agreed was possible (I thought) or 
--> argues for using
--> > an IP heaader with a flow tag. At which point we're back to IP.
--> >
--> > Let's please not reinvent IP here. As I said in other messages, if
--> > support for future use is the concern, it's more 
--> important to define
--> > reserved bits than to fix their allocation now.
--> >   
--> Please see my email to Eric about FTAG vs VLAN. I disagree 
--> with your 
--> point of view that we're reinventing IP. The moment we chose to do 
--> IS-IS, provide multipathing at L2, we're changing what current L2 
--> networks do and some would argue that we're reinventing IP.
--> 
--> Dinesh
--> 
--> -- 
--> We make our world significant by the courage of our 
--> questions and by 
--> the depth of our answers.                               - Carl Sagan
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Fri, 20 Oct 2006 15:05:14 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 14043

Silvano,

	I was working on the replies to you analysis below, thinking
I would not complete them this week.  As you can see, I had a bit
more time than I expected to have and was able to complete my
response earlier than I thought. 

	As a first observation, whenever someone says "this is not
hardware friendly", my gut reaction is to ask "for what hardware"?

	As a second observation, although the number of MPLS labels
may change, the Ethernet encapsulations defined for PWE3 already
uses a 32-bit alignment assumption independent of Ethernet frame
alignment either "below" or "above" the MPLS SHIM.  Consequently,
there is definitely hardware in existence, in development or both
that deals with this alleged "alignment issue."

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Wednesday, October 18, 2006 12:04 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> 
--> Eric,
--> 
--> Let me depict you what happens when you insert one MPLS 
--> label, [or] a 1Q option or a 1S option
--> 
--> Original:
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> 
--> Original + Opt (where Opt can be MPLS, 1Q or 1S)
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |      Opt      |
--> +--------------------------------+
--> |      opt       |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> The HW that perform the insertion/removal does not need to 
--> realign the payload that is in its buffer.
--> 

This is an interesting, but inefficient, storage scheme in the
first place.  With this storage scheme, the same DA and/or SA
values will be stored in uncompressed format hundreds or even
thousands of times in any sizable buffer.

I think it is unrealistic to assert that this is the only way
that this information might be stored in a buffer.  If it is 
not stored in this precise fashion, then the below observations
are invalidated.

--> 
--> Now Let's consider the encapsulation/decapsulation function 
--> by looking at the Original frame + TRILL header (as proposed 
--> by the current draft)

Let's be clear about what is proposed by the current draft.

The encapsulation below is not - in any way - proposed by the
current draft as it does not assume that there will be a 16-bit
"slop factor" as you indicate with "????????" in your picture.

--> +--------------------------------+
--> |         Outer DA               |
--> +----------------+---------------+
--> |    Outer DA    |  Outer SA     |
--> +----------------+---------------+
--> |         Outer SA               |
--> +--------------------------------+
--> |Ethertype=TRILL |   Trill Shim  |
--> +--------------------------------+
--> |  Trill Shim    |  ????????     |
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |

If this was proposed by "the current draft", then it should be
put forward as "an example only" in later versions.  An equally 
valid example may be either of the following:

 +--------------------------------+
 |         Outer DA               |
 +----------------+---------------+
 |    Outer DA    |  Outer SA     |
 +----------------+---------------+
 |         Outer SA               |
 +--------------------------------+
 |Ethertype=TRILL |   Trill Shim  |
 +--------------------------------+
 |  Trill Shim    |      DA       |
 +--------------------------------+
 |               DA               |
 +----------------+---------------+
 |               SA               |
 +----------------+---------------+
 |       SA       |   Ethertype   | 
 +--------------------------------+
 |            Payload             |
 +                                +
 |          ...........           |

OR

 +--------------------------------+
 |         Outer DA               |
 +----------------+---------------+
 |    Outer DA    |  Outer SA     |
 +----------------+---------------+
 |         Outer SA               |
 +--------------------------------+
 |Ethertype=TRILL |   Trill Shim  |
 +--------------------------------+
 |  Trill Shim    |      DA       |
 +--------------------------------+
 |               DA               |
 +----------------+---------------+
 |               SA               |
 +----------------+---------------+
 |       SA       |     0x8100    |
 +--------------------------------+
 | P |  VLAN ID   |   Ethertype   | 
 +--------------------------------+
 |            Payload             |
 +                                +
 |          ...........           |

And there are others.  Note that this is a depiction of what a
frame would look like "on the wire".  It is inappropriate for 
us to make assumptions about what it would look like in memory
for any specific implementation.

In any case, when it goes on the wire, the 16-bit "field" shown
in your example would not be present unless there was reason to
have it. 

--> 
--> If you don't have the 16 bits indicated by ???????, the 
--> hardware will need to realign the inner frame. The frame 
--> is not on the wire. The frame sits in the [frame] buffer 
--> and the memory bandwidth of the packet buffer is today 
--> the MOST important consideration in port ASIC design.

>From the above discussions, you should be able to see the following:

1) It is inappropriate to make assumptions about how frames are 
   stored in memory prior to being put on the wire as we are not
   here to standardize that.

2) It is likely that any such assumptions will be incorrect in
   at least some implementations.

Based on this, your otherwise reasonable argument is invalidated
as it is based on inappropriate, and incorrect, assumptions about
implementations.

--> 
--> More inline
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Wednesday, October 18, 2006 4:57 AM
--> > To: Silvano Gai
--> > Cc: [email-masked]
--> > Subject: RE: [rbridge] FTag
--> > 
--> > Silvano,
--> > 
--> > Let me answer your points in order, leaving out irrelevant issues:
--> > 
--> > <Your Point> N*32 is correct, when including Ethernet options/shims
--> >              (e.g. .1Q or .1S).  This is hardware friendly, because
--> > 		 alignment doesn't change going from one header to another.
--> > 
--> > There are a few different "Ethernet" encapsulations, once we start to
--> > include Ethernet options and the shims associated with those options.
--> > 
--> > First, and I believe most important, the "shim" we are talking about
--> > (in TRILL) is not an Ethernet option (or associated shim).  It's a
--> > "shim" as a separate "layer."  Otherwise, it would be inappropriate
--> > for us to do this work here (in TRILL, as part of the IETF).
--> 
--> From the above picture it should be clear that you should 
--> consider the TRILL header as a whole, and the TRILL header 
--> as only one form of Ethernet encapsulation.

Actually, what should be clear is that the intent is explicitly 
NOT to define an aggregate header type, combining a specific 
Ethernet header and TRILL SHIM.  Not only would doing so limit
the usefulness of RBridges in general, it would also involve our 
doing work that is strictly out of scope in the IETF.

What we need to do is recognize that both tunnel, and native, 
encapsulations may be any defined Ethernet encapsulation that
is supported by the interfaces of any specific implementation.

--> 
--> > 
--> > Second, "Ethernet" headers do not all align the same.
--> > 
--> 
--> Agreed, but that is not my concern, My concern is to not 
--> change their alignment due to the insertion/removal of the 
--> TRILL header.

However, it is my concern.  A key reason for using a layer
model in networking protocols is to separate functions and
their definitions in ways that isolate the workings of one
layer from the changes in another.

--> 
--> > Currently, we are talking about having a single Ethertype defined to
--> > distinguish inter-RBridge traffic from other types of Ethernet frames.
--> > If your implementation produces 32-bit aligned Ethernet frames, using
--> > 802.1Q, then it will similarly produce 32-bit aligned frames - prior
--> > to considering the TRILL shim - using the new Ethertype.
--> > 
--> > We are not proposing a change in any Ethernet frame/header format.
--> 
--> Neither do I.

This is semantics.  You are clearly proposing that we should 
define a new type of Ethernet header - calling it a TRILL
Ethernet header - and that is not what we're supposed to be
doing.

--> 
--> > 
--> > The reference to 802.1Q is slightly disingenuous, because 802.1Q
--> > effectively displaces the existing Ethertype by 32 bits.  802.1Q
--> > "shims" include the Ethertype, because they replace the original
--> > one with 0x8100 and have to include the original in the "shim."
--> > 
--> > I assume that a similar observation could be made about 802.1S.
--> 
--> Yes and a similar observation can be made for MPLS, but all these three
--> do not change the alignment of the fields that follow.

And, as you may have noted from the above, if you're talking 
about frame alignment in a buffer, this depends a lot on the
specifics of any implementation.

As I pointed out above, there is already a "proof of concept"
example in PWE3 Ethernet encapsulation.

--> 
--> > 
--> > In TRILL, we are not replacing the original Ethertype, we are adding
--> > a new encapsulation.  The original Ethertype stays in the original
--> > - re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
--> > no reason to consider the Ethertype to be part of the TRILL shim.
--> 
--> As I told before you need to consider the whole TRILL header, i.e.
--> 6 bytes of DA
--> 6 bytes of SA
--> 2 bytes of Ethertype
--> 4 bytes of shim
--> ----------------------
--> 18 bytes

Yes, you have asserted this, and I have refuted it.

Hence we are in disagreement on that point and we should let other
people make their own assertions (and refutations) and see how things 
turn out.

--> 
--> Which is 2 bytes short of N*32, i.e. it is not HW friendly.
--> 
--> For this reason I propose that Ethertype + shim should be 
--> N*32 to be HW
--> friendly.
--> 
--> 
--> > 
--> > <Your Point> TRILL should adopt this model for its shim header - the
--> >              Ethertype should be included as part of computing "shim"
--> >              size.
--> > 
--> > In TRILL, we are not replacing the original Ethertype, we are adding
--> > a new encapsulation.  The original Ethertype stays in the original
--> > - re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
--> > no reason to consider the Ethertype to be part of the TRILL shim.
--> > 
--> > <Your Point> TRILL should optimize the Ethernet case that will cover
--> >              99% of TRILL applications.
--> > 
--> > Coverage is slightly more complete than that.  Considering all of the
--> > layer 2 encapsulations that currently come under an Ethernet umbrella,
--> > TRILL applications are 100% included.
--> > 
--> > I think we are essentially in agreement on this point.
--> > 
--> > <Your Point> TRILL bridges will be implemented mainly in hardware and
--> >              the encapsulation and decapsulation functions need to be
--> >              HW friendly.
--> > 
--> > Okay.  I was not making any other point - except to say that alignment
--> > is usually a software concern, especially in initial design.
--> > 
--> > Let me be blunt, alignment does not factor into initial hardware
design,
--> > but is an issue with hardware re-use complexity.  Bits on a wire are
not
--> > "aligned" - you simply collect them as they arrive, serially.
--> 
--> I agree that bits on the wire are not aligned, but you need to buffer
--> the incoming frame (or at least part of it) until you have enough fields
--> to perform your lookup and decide what to do with the frame. From that
--> point on the frame is not on the wire, it is in the packet buffer and
--> alignment is crucial at the performance we are talking about.

This is perhaps the most specious part of the argument.  While a huge
majority of switch builders use essentially similar buffering models,
at an architectural level, the details of how and where the frames are 
buffered is very much a part of the "secret sauce" of implementations.

Given the number of potential ways of doing input buffering, and the
likelihood that we are going to be able to get enough data on specific
implementations to perform any sort of meaningful statistical analysis,
I see no reason to assign any greater validity to the assumption that
frame alignment is important than to the assumption that it is not.

--> 
--> I hope this time I made my point more clear

It did.  I had thought you were talking about the importance of 
alignment in framing hardware, and you clarified that you were
talking about buffering.

This doesn't change the fact that I think you're wrong, but it 
does help me to understand exactly what you're wrong about.  :-)

--> 
--> -- Silvano
-- [SNIP] -- 

To: "Silvano Gai" <[email-masked]>
From: Ed Bowen <[email-masked]>
Date: Fri, 20 Oct 2006 14:23:43 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>, [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 8154

--0__=0ABBF89EDFF01CAA8f9e8a93df938690918c0ABBF89EDFF01CAA
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable

All,

Of the thousand or so customers who are consuming my team's networking
services, I think all would be happy to give up 0.37% of the bandwidth =
for
these features.  I can't imagine a scenario where a customer would say =
the
0.37% of additional bandwidth is more important.  The burst conditions =
that
actually utilize the last 0.37% of the network are pretty rare.

Best regards,
Ed

[email-masked] wrote on 10/20/2006 12:20:59 PM:

> Radia,
>
> I am not the right person for the summary, but let me give you my
> perspective:
>
> It is bits Vs features:
>
> - One group advocates that features have been defined in the TRILL
> charter and in the doc:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00.txt
> and that we need to define a TRILL shim that accommodates these featu=
res
> using the minimum number of bits.
>
> - Another group claims that more features are required (e.g.
> Troubleshooting, tracing, efficient multicast, etc.) and that these
> features are worth few extra bytes.
>
> Let's also use some quantitative analysis. The TRILL Ethernet header
> currently defined in:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol=
-00
> .txt
> is 18 bytes
>
> The new proposal as modified by Dinesh Dutt is 20 bytes.
>
> On an average 512 bytes payload the old proposal has an overhead of
> 3.27% and the new proposal has an overhead of 3.64%, a difference of
> 0.37%.
>
> I claim you cannot find a single user that is not willing to spend 0.=
37%
> of its campus bandwidth to have:
> - more security
> - more troubleshooting (especially under attack)
> - better multicast handling
> - better topology management
>
> Do you agree?
>
> -- Silvano
>
> > -----Original Message-----
> > From: Radia Perlman [mailto:[email-masked]]
> > Sent: Friday, October 20, 2006 7:07 AM
> > To: Gray, Eric
> > Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); [email-masked]=
rg
> > Subject: Time for a summary?
> >
> > I've been travelling for a few days, and have just enough email acc=
ess
> > to notice there has been a really
> > high volume of email, which undoubtedly will be hard for me and mos=
t
> > others, to catch up on.
> >
> > Can someone who has been following this discussion the last couple
> days
> > post a summary? I think
> > we are arguing over several different potentially added fields:
> > a) F-Tag
> > b) both ingress and egress RBridge
> > c) ingress LID
> > d) egress LID
> >
> > I'd prefer a separate summary of the arguments for and against each=
 of
> > those fields.
> > Whoever is summarizing shouldn't be advocating, but rather just
> putting
> > in one message what they understand
> > to be all the arguments presented. I'd prefer no names as in "argum=
ent
> > against: extra space in header" rather
> > than "Person X claims it takes extra space".
> >
> > Then people can resume the discussion starting from the summary, an=
d
> > nobody needs to read any
> > of the previous emails.
> >
> > I suppose if nobody does this, I will eventually have some time and=

> > attempt it.
> >
> > Thanks,
> >
> > Radia
> >
> > >-->
> > >
> > >
>
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge=

--0__=0ABBF89EDFF01CAA8f9e8a93df938690918c0ABBF89EDFF01CAA
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body>
<p>All,<br>
<br>
Of the thousand or so customers who are consuming my team's networking =
services, I think all would be happy to give up 0.37% of the bandwidth =
for these features.  I can't imagine a scenario where a customer would =
say the 0.37% of additional bandwidth is more important.  The burst con=
ditions that actually utilize the last 0.37% of the network are pretty =
rare.<br>
<br>
Best regards, <br>
Ed  <br>
<br>
<tt>[email-masked] wrote on 10/20/2006 12:20:59 PM:<br>
<br>
&gt; Radia,<br>
&gt; <br>
&gt; I am not the right person for the summary, but let me give you my<=
br>
&gt; perspective:<br>
&gt; <br>
&gt; It is bits Vs features:<br>
&gt; <br>
&gt; - One group advocates that features have been defined in the TRILL=
<br>
&gt; charter and in the doc:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-trill-pr=
ob-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00=
.txt</a><br>
&gt; and that we need to define a TRILL shim that accommodates these fe=
atures<br>
&gt; using the minimum number of bits.<br>
&gt; <br>
&gt; - Another group claims that more features are required (e.g.<br>
&gt; Troubleshooting, tracing, efficient multicast, etc.) and that thes=
e<br>
&gt; features are worth few extra bytes.<br>
&gt; <br>
&gt; Let's also use some quantitative analysis. The TRILL Ethernet head=
er<br>
&gt; currently defined in:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-trill-rb=
ridge-protocol-00">http://www.ietf.org/internet-drafts/draft-ietf-trill=
-rbridge-protocol-00</a><br>
&gt; .txt<br>
&gt; is 18 bytes<br>
&gt; <br>
&gt; The new proposal as modified by Dinesh Dutt is 20 bytes.<br>
&gt; <br>
&gt; On an average 512 bytes payload the old proposal has an overhead o=
f<br>
&gt; 3.27% and the new proposal has an overhead of 3.64%, a difference =
of<br>
&gt; 0.37%.<br>
&gt; <br>
&gt; I claim you cannot find a single user that is not willing to spend=
 0.37%<br>
&gt; of its campus bandwidth to have:<br>
&gt; - more security<br>
&gt; - more troubleshooting (especially under attack)<br>
&gt; - better multicast handling<br>
&gt; - better topology management<br>
&gt; <br>
&gt; Do you agree?<br>
&gt; <br>
&gt; -- Silvano<br>
&gt; <br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Radia Perlman [<a href=3D"mailto:[email-masked]"=
>mailto:[email-masked]</a>]<br>
&gt; &gt; Sent: Friday, October 20, 2006 7:07 AM<br>
&gt; &gt; To: Gray, Eric<br>
&gt; &gt; Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); rbridge@po=
stel.org<br>
&gt; &gt; Subject: Time for a summary?<br>
&gt; &gt; <br>
&gt; &gt; I've been travelling for a few days, and have just enough ema=
il access<br>
&gt; &gt; to notice there has been a really<br>
&gt; &gt; high volume of email, which undoubtedly will be hard for me a=
nd most<br>
&gt; &gt; others, to catch up on.<br>
&gt; &gt; <br>
&gt; &gt; Can someone who has been following this discussion the last c=
ouple<br>
&gt; days<br>
&gt; &gt; post a summary? I think<br>
&gt; &gt; we are arguing over several different potentially added field=
s:<br>
&gt; &gt; a) F-Tag<br>
&gt; &gt; b) both ingress and egress RBridge<br>
&gt; &gt; c) ingress LID<br>
&gt; &gt; d) egress LID<br>
&gt; &gt; <br>
&gt; &gt; I'd prefer a separate summary of the arguments for and agains=
t each of<br>
&gt; &gt; those fields.<br>
&gt; &gt; Whoever is summarizing shouldn't be advocating, but rather ju=
st<br>
&gt; putting<br>
&gt; &gt; in one message what they understand<br>
&gt; &gt; to be all the arguments presented. I'd prefer no names as in =
&quot;argument<br>
&gt; &gt; against: extra space in header&quot; rather<br>
&gt; &gt; than &quot;Person X claims it takes extra space&quot;.<br>
&gt; &gt; <br>
&gt; &gt; Then people can resume the discussion starting from the summa=
ry, and<br>
&gt; &gt; nobody needs to read any<br>
&gt; &gt; of the previous emails.<br>
&gt; &gt; <br>
&gt; &gt; I suppose if nobody does this, I will eventually have some ti=
me and<br>
&gt; &gt; attempt it.<br>
&gt; &gt; <br>
&gt; &gt; Thanks,<br>
&gt; &gt; <br>
&gt; &gt; Radia<br>
&gt; &gt; <br>
&gt; &gt; &gt;--&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; rbridge mailing list<br>
&gt; [email-masked]<br>
&gt; <a href=3D"http://mailman.postel.org/mailman/listinfo/rbridge">htt=
p://mailman.postel.org/mailman/listinfo/rbridge</a><br>
</tt></body></html>=

--0__=0ABBF89EDFF01CAA8f9e8a93df938690918c0ABBF89EDFF01CAA--

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Fri, 20 Oct 2006 13:35:27 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 546

Silvano,

-- [SNIP] --
--> 
--> Let's also use some quantitative analysis. The TRILL Ethernet header
--> currently defined in:
-->
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00.txt
--> is 18 bytes

We are _not_ defining an Ethernet header, and - whatever text it is that 
leads you to believe we are - that text should be modified or removed.

We are simply using a standard Ethernet header, with an Ethertype that
indicates that this header is followed by an Rbridge SHIM and another
Ethernet header.

-- [SNIP] --

Date: Fri, 20 Oct 2006 10:32:14 -0700
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1953

Good Morning,

Joe Touch wrote:
> There's no traceroute through ethernet switches now; I don't see why
> they ought to be supported uniquely in an rbridge.
>   
Could you provide me with technical reasons why you think this is 
unnecessary ? Ethernet bridges today don't have IS-IS. Why invent that ? 
I repeat, troubleshooting networks is a critical aspect of any protocol. 
It can't be shoehorned in or added as an afterthought just like security 
cannot.
>> I'm unaware of any protocol, tunnelling or otherwise, that does not 
>> carry both an ingress and egress endpoint address in the header. Before 
>> you can utter that four letter word at me, remember that MPLS changes 
>> labels hop-by-hop; so having an ingress and egress in MPLS is not very
>> useful. I can visualize other optimizations and features that can be 
>> deployed if I have both ingress and egress addresses in a frame.
>>     
>
> This argues for using an IP header as the shim, at which point we just
> ought to deploy routers as rbridge nodes and call it a day. See below.
>   
I couldn't follow you here. Why does it assume an IP header as a shim ?
> IMO, tags argue either for VLANs over the rbridge (one per class) -
> which we had already agreed was possible (I thought) or argues for using
> an IP heaader with a flow tag. At which point we're back to IP.
>
> Let's please not reinvent IP here. As I said in other messages, if
> support for future use is the concern, it's more important to define
> reserved bits than to fix their allocation now.
>   
Please see my email to Eric about FTAG vs VLAN. I disagree with your 
point of view that we're reinventing IP. The moment we chose to do 
IS-IS, provide multipathing at L2, we're changing what current L2 
networks do and some would argue that we're reinventing IP.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

From: "Gray, Eric" <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Date: Fri, 20 Oct 2006 13:28:52 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE:	 New fields in shim header?)
Status: RO
Content-Length: 2702

Dinesh,

	We're making semantic distinctions here.  I can easily define a
VLAN consisting of a group of RBridges that corresponds to the same
semantics as the FTAG.  I am not redefining what an 802.1Q VLAN tag is
by doing this, I am simply defining one or more specific VLANs in ways
I certainly am allowed to by IEEE 802.1Q.

	There is no reason - as I said in my recent reply to Silvano -
why this is inconsistent with using what you are referring to as 
"shared trees." 

	There is no "protocol overhead" in this case, because we have
to deal with the fact that either the tunnel Ethernet, or the native
Ethernet, encapsulation may use 802.1Q.  Where protocol overhead is
introduced is where we introduce bits that may be used in some cases,
but must be present in all cases.

--
Eric

--> -----Original Message-----
--> From: Dinesh G Dutt [mailto:[email-masked]] 
--> Sent: Friday, October 20, 2006 1:22 PM
--> To: Gray, Eric
--> Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); 
--> [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> Hi Eric,
--> 
--> Gray, Eric wrote:
--> > Silvano,
--> >
--> > 	The VLAN space you mention is larger in the RBridges case.
--> > It is possible to use 802.1Q encapsulation in the RBridge tunnel
--> > encapsulation - in a fashion similar to (but not necessarily the
--> > same as) the way in which it may be used in the native Ethernet.
--> >
--> >   
--> If I understand what you're saying, it is that we can add 
--> an additional 
--> .1Q tag between the outer L2 MAC address (carrying Rbridge 
--> next hop mac 
--> address) and the TRILL shim header and we can use the VLAN 
--> field in this 
--> tag to do what FTAG is being proposed for.
--> 
--> If this is right, let me list the reasons why I think FTAG 
--> is a better 
--> approach:
-->     - Using the VLAN field doesn't permit you to construct 
--> shared trees 
--> and use the FTAG as a tree identifier. Sure, you can 
--> redefine the VLAN 
--> field to be that, but then it's no longer VLAN as defined by .1Q.
-->     - I'm concerned about protocol overhead; this adds 32 
--> bits to the 
--> protocol vs 10 bits by FTAG.
-->     - .1Q is a tag for Ethernet. If I want to use TRILL across 
--> non-Ethernet links, I need something that is independent of the L2 
--> transmission layer being used. While this case may not be the 90% 
--> scenario, it seems to intuitively violate layering in my mind.
--> 
--> Dinesh
--> 
--> -- 
--> We make our world significant by the courage of our 
--> questions and by 
--> the depth of our answers.                               - Carl Sagan
--> 

Date: Fri, 20 Oct 2006 10:21:43 -0700
From: Dinesh G Dutt <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1382

Hi Eric,

Gray, Eric wrote:
> Silvano,
>
> 	The VLAN space you mention is larger in the RBridges case.
> It is possible to use 802.1Q encapsulation in the RBridge tunnel
> encapsulation - in a fashion similar to (but not necessarily the
> same as) the way in which it may be used in the native Ethernet.
>
>   
If I understand what you're saying, it is that we can add an additional 
.1Q tag between the outer L2 MAC address (carrying Rbridge next hop mac 
address) and the TRILL shim header and we can use the VLAN field in this 
tag to do what FTAG is being proposed for.

If this is right, let me list the reasons why I think FTAG is a better 
approach:
    - Using the VLAN field doesn't permit you to construct shared trees 
and use the FTAG as a tree identifier. Sure, you can redefine the VLAN 
field to be that, but then it's no longer VLAN as defined by .1Q.
    - I'm concerned about protocol overhead; this adds 32 bits to the 
protocol vs 10 bits by FTAG.
    - .1Q is a tag for Ethernet. If I want to use TRILL across 
non-Ethernet links, I need something that is independent of the L2 
transmission layer being used. While this case may not be the 90% 
scenario, it seems to intuitively violate layering in my mind.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Content-class: urn:content-classes:message
Date: Fri, 20 Oct 2006 09:20:59 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Time for a summary?
Status: RO
Content-Length: 2509

Radia,

I am not the right person for the summary, but let me give you my
perspective:

It is bits Vs features:

- One group advocates that features have been defined in the TRILL
charter and in the doc:
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-00.txt
and that we need to define a TRILL shim that accommodates these features
using the minimum number of bits.

- Another group claims that more features are required (e.g.
Troubleshooting, tracing, efficient multicast, etc.) and that these
features are worth few extra bytes.

Let's also use some quantitative analysis. The TRILL Ethernet header
currently defined in:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt
is 18 bytes

The new proposal as modified by Dinesh Dutt is 20 bytes.

On an average 512 bytes payload the old proposal has an overhead of
3.27% and the new proposal has an overhead of 3.64%, a difference of
0.37%.

I claim you cannot find a single user that is not willing to spend 0.37%
of its campus bandwidth to have:
- more security
- more troubleshooting (especially under attack)
- better multicast handling
- better topology management

Do you agree?

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]]
> Sent: Friday, October 20, 2006 7:07 AM
> To: Gray, Eric
> Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); [email-masked]
> Subject: Time for a summary?
> 
> I've been travelling for a few days, and have just enough email access
> to notice there has been a really
> high volume of email, which undoubtedly will be hard for me and most
> others, to catch up on.
> 
> Can someone who has been following this discussion the last couple
days
> post a summary? I think
> we are arguing over several different potentially added fields:
> a) F-Tag
> b) both ingress and egress RBridge
> c) ingress LID
> d) egress LID
> 
> I'd prefer a separate summary of the arguments for and against each of
> those fields.
> Whoever is summarizing shouldn't be advocating, but rather just
putting
> in one message what they understand
> to be all the arguments presented. I'd prefer no names as in "argument
> against: extra space in header" rather
> than "Person X claims it takes extra space".
> 
> Then people can resume the discussion starting from the summary, and
> nobody needs to read any
> of the previous emails.
> 
> I suppose if nobody does this, I will eventually have some time and
> attempt it.
> 
> Thanks,
> 
> Radia
> 
> >-->
> >
> >

Content-class: urn:content-classes:message
Date: Fri, 20 Oct 2006 08:21:58 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 4052

Eric,

No Problem, in:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt

section 2.1.2 states:
"   Some frames (e.g., to unknown destinations, or multicast 
   destinations) will need to be delivered to multiple links. To 
   optimize delivery in the case where not all links are to receive the 
   frame (e.g., an IP multicast or a VLAN-tagged frame), and to avoid 
   out-of-order delivery when location of the destination is discovered 
   after a flow starts up, RBridges calculate a tree per ingress 
   RBridge, and deliver a frame along that distribution tree. The 
   ingress RBridge trees will be calculated based on the link state 
   information distributed in the core IS-IS instance. "

It is therefore clear that all multicast traffic will be sent on trees
rooted on the ingress RBridge, independently of how many VLANs are
present.

The use of shared trees is therefore impossible. Do you agree?

Also
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt
speaks about VLANs and it says:
" A VLAN is a broadcast domain. That means that a layer 2 broadcast 
   (multicast) frame sent to a VLAN must only be delivered to links that

   are in that VLAN. A encapsulated frame destined for a particular VLAN

   may transit any link on the campus, but an unencapsulated VLAN frame 
   must only be delivered to links that RBridges know (for example, 
   through configuration) support that VLAN."

>From this sentence I have a hard time understanding what you were saying
in a previous message, i.e.
"	Note that this use of VLAN tags in the tunnel encapsulation
- while not entirely orthogonal to VLAN tag usage in native encaps
- does not necessarily result in depletion of the native VLAN tag
space."

The draft states that "a particular VLAN may transit any link on the
campus". Pretty strong statement.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 20, 2006 7:45 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> Silvano,
> 
> 	I think the best use of our time - yours and mine - would be for
> you to review the protocol specification and point out where it is not
> clear what the text in that draft means to an implementer.
> 
> 	The reason why I say this is that your question indicates to me
> that - if you have read the existing specifications - we have not been
> doing a good job of capturing WG decisions and progress in this area,
> in those documents.
> 
> 	There is a logical construct we refer to as ingress rbridge tree
> that exists for each ingress RBridge.  This is a logical construct
only
> as it is not exactly a tree - and certainly not a tree in the sense of
> a spanning tree.
> 
> 	Essentially, it is an overlay of multiple trees, where the base
> tree provides one-way, p2mp delivery to at least the subset of egress
> RBridges having a common set of VLANs (including the "default" VLAN
> - corresponding to un-tagged Ethernet).  "Overlay" versions of this
> tree consist of various "prunings" of the base tree based on egress
> membership in VLANs and multicast groups.  "Pruning" is accomplished
> at intermediate RBridges by creating, modifying and deleting entries
> in a forwarding table used for IRT forwarding across the CRED (in the
> architecture document, this forwarding table is called the CFT-IRT).
> 
> 	Since it cannot be the case that a destination intended to be
> included in forwarding a multicast frame, is not reachable via the
> IRT, I cannot imagine why you say that VLANs cannot be used for this
> purpose.  Hence, there is clearly some kind of misunderstanding...
> 
> --
> Eric
> 
> -- [SNIP] --
> -->
> --> VLAN within a CRED can work for unicast, but not for multicast.
> --> As multicast is currently defined in TRILL the root of the tree is
> --> ALWAYS in the ingress RBridge, independently of how many
> --> VLANs you have.
> -->
> -- [SNIP] --

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Fri, 20 Oct 2006 10:44:44 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE:	 New fields in shim header?)
Status: RO
Content-Length: 1820

Silvano,

	I think the best use of our time - yours and mine - would be for
you to review the protocol specification and point out where it is not
clear what the text in that draft means to an implementer.

	The reason why I say this is that your question indicates to me
that - if you have read the existing specifications - we have not been
doing a good job of capturing WG decisions and progress in this area,
in those documents. 

	There is a logical construct we refer to as ingress rbridge tree
that exists for each ingress RBridge.  This is a logical construct only
as it is not exactly a tree - and certainly not a tree in the sense of
a spanning tree.  

	Essentially, it is an overlay of multiple trees, where the base
tree provides one-way, p2mp delivery to at least the subset of egress 
RBridges having a common set of VLANs (including the "default" VLAN
- corresponding to un-tagged Ethernet).  "Overlay" versions of this
tree consist of various "prunings" of the base tree based on egress 
membership in VLANs and multicast groups.  "Pruning" is accomplished 
at intermediate RBridges by creating, modifying and deleting entries 
in a forwarding table used for IRT forwarding across the CRED (in the 
architecture document, this forwarding table is called the CFT-IRT).

	Since it cannot be the case that a destination intended to be
included in forwarding a multicast frame, is not reachable via the
IRT, I cannot imagine why you say that VLANs cannot be used for this
purpose.  Hence, there is clearly some kind of misunderstanding...

--
Eric 

-- [SNIP] --
--> 
--> VLAN within a CRED can work for unicast, but not for multicast.
--> As multicast is currently defined in TRILL the root of the tree is
--> ALWAYS in the ingress RBridge, independently of how many 
--> VLANs you have.
--> 
-- [SNIP] --

Date: Fri, 20 Oct 2006 07:06:40 -0700
From: Radia Perlman <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: [rbridge] Time for a summary?
Status: RO
Content-Length: 1019

I've been travelling for a few days, and have just enough email access 
to notice there has been a really
high volume of email, which undoubtedly will be hard for me and most 
others, to catch up on.

Can someone who has been following this discussion the last couple days 
post a summary? I think
we are arguing over several different potentially added fields:
a) F-Tag
b) both ingress and egress RBridge
c) ingress LID
d) egress LID

I'd prefer a separate summary of the arguments for and against each of 
those fields.
Whoever is summarizing shouldn't be advocating, but rather just putting 
in one message what they understand
to be all the arguments presented. I'd prefer no names as in "argument 
against: extra space in header" rather
than "Person X claims it takes extra space".

Then people can resume the discussion starting from the summary, and 
nobody needs to read any
of the previous emails.

I suppose if nobody does this, I will eventually have some time and 
attempt it.

Thanks,

Radia

>--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, "Gray, Eric" <[email-masked]>, Joe Touch <[email-masked]>, "Dino Farinacci (dino)" <[email-masked]>
Date: Fri, 20 Oct 2006 09:57:07 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE:	 New fields in shim header?)
Status: RO
Content-Length: 8963

Past presentations can usually be seen by going to the IETF site,
picking "Meetings", "Past Meetings" and then whatever specific
meeting you want.  Presentations on general issues with VLANs and
p2mp trees started - I believe - in IETF 62. 

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Thursday, October 19, 2006 7:47 PM
--> To: Gray, Eric; Joe Touch; Dino Farinacci (dino)
--> Cc: [email-masked]; Radia Perlman
--> Subject: RE: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> 
--> Eric,
--> 
--> Help me here, can you send a pointer to a presentation?
--> 
--> VLAN within a CRED can work for unicast, but not for multicast.
--> As multicast is currently defined in TRILL the root of the tree is
--> ALWAYS in the ingress RBridge, independently of how many 
--> VLANs you have.
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Thursday, October 19, 2006 3:13 PM
--> > To: Silvano Gai; Joe Touch; Dino Farinacci (dino)
--> > Cc: [email-masked]; Radia Perlman
--> > Subject: RE: [rbridge] Range of appllicability (was Re: 
--> TTL only - was
--> RE:
--> > New fields in shim header?)
--> > 
--> > Silvano,
--> > 
--> > 	The VLAN space you mention is larger in the RBridges case.
--> > It is possible to use 802.1Q encapsulation in the RBridge tunnel
--> > encapsulation -
--> 
--> From this explanation I am not sure were you want to add 
--> the additional
--> 1Q tag.
--> 
--> -- Silvano
--> 
-->  in a fashion similar to (but not necessarily the
--> > same as) the way in which it may be used in the native Ethernet.
--> > 
--> > 	Consequently, if - in a deployment - network administrators
--> > want to optimize load balancing, they may do so by defining VLANs
--> > within the CRED.  Sets of CRED-VLANs would be configurable to use
--> > distinguishable paths.
--> > 
--> > 	As Radia has pointed out in several previous presentations,
--> > one of the "keys" used in a look-up for the "ingress RBridge tree"
--> > is the VLAN in the tunnel encapsulation - assuming one is present.
--> > 
--> > 	This could - among other things - serve the purpose of "tags"
--> > for use as you describe.  Since configuration would be needed in
--> > either case, this is both equivalent to adding any additional tags
--> > and more than is strictly required to solve the problems we've set
--> > out to solve.
--> > 
--> > 	Note that this use of VLAN tags in the tunnel encapsulation
--> > - while not entirely orthogonal to VLAN tag usage in native encaps
--> > - does not necessarily result in depletion of the native VLAN tag
--> > space.
--> > 
--> > 	Effectively, by potentially having VLAN tags in the tunnel
--> > encapsulation, and in the native Ethernet encapsulation as well,
--> > you have more than 4K potential "VLANs" - not less.
--> > 
--> > --
--> > Eric
--> > 
--> > 
--> > --> -----Original Message-----
--> > --> From: [email-masked]
--> > --> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> > --> Sent: Thursday, October 19, 2006 5:44 PM
--> > --> To: Joe Touch; Dino Farinacci (dino)
--> > --> Cc: [email-masked]; Radia Perlman
--> > --> Subject: Re: [rbridge] Range of appllicability (was Re: TTL
--> > --> only - was RE: New fields in shim header?)
--> > -->
--> > -->
--> > --> Joe,
--> > -->
--> > --> I have hard time understanding how you can use 
--> separate VLANs for
--> > --> unicast and broadcast, this will, for example, break IPv4,
--> > --> due to ARP.
--> > -->
--> > --> Using separate VLANs for Unicast and Multicast will break
--> > --> IPv6, due to
--> > --> ND.
--> > -->
--> > --> Today, all the applications assume that they can send
--> > --> Unicast, Multicast
--> > --> and Broadcast on the same VLAN (they basically ignore 
--> that a VLAN
--> > --> exists).
--> > -->
--> > --> Remember that many networks deploy "Private VLANs", since they
--> don't
--> > --> have enough of 4K VLANs, so proposing to reduce the 
--> 4K space to
--> 1/3
--> > --> seems highly unrealistic.
--> > -->
--> > --> Today TRILL specifies that multicast must be sent on 
--> the "ingress
--> > --> RBRidge tree" (for this reason, in the case of multicast,
--> > --> the ingress
--> > --> RBridge address is carried in the shim header). This
--> > --> provides shortest
--> > --> path, but not good load balancing. Multicast folks will
--> > --> prefer to have
--> > --> few shared trees routed in the core. In this way they 
--> get optimal
--> > --> forwarding, but also good load balancing. To support 
--> this it is
--> > --> necessary to carry in the frame an indication of the tree
--> > --> (FTAG) that
--> > --> needs to be used to forward the frame.
--> > -->
--> > --> I am sure that Dino can provide a better reply to this point.
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Joe Touch [mailto:[email-masked]]
--> > --> > Sent: Thursday, October 19, 2006 11:36 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: Erik Nordmark; [email-masked]; Radia Perlman
--> > --> > Subject: Re: [rbridge] Range of appllicability (was Re:
--> > --> TTL only - was
--> > --> RE:
--> > --> > New fields in shim header?)
--> > --> >
--> > --> >
--> > --> >
--> > --> > Silvano Gai wrote:
--> > --> > > Joe,
--> > --> > >
--> > --> > >> -----Original Message-----
--> > --> > >> From: Joe Touch [mailto:[email-masked]]
--> > --> > >> Sent: Thursday, October 19, 2006 8:58 AM
--> > --> > >> To: Silvano Gai
--> > --> > >> Cc: Erik Nordmark; [email-masked]; Radia Perlman
--> > --> > >> Subject: Re: [rbridge] Range of appllicability (was
--> > --> Re: TTL only -
--> > --> was
--> > --> > > RE:
--> > --> > >> New fields in shim header?)
--> > --> > >>
--> > --> > >>
--> > --> > >>
--> > --> > >> Silvano Gai wrote:
--> > --> > >> ...
--> > --> > >>>> The reason I'm asking is because I see a big
--> > --> difference between
--> > --> > > asking
--> > --> > >>>> RBridges to provide some new degree of
--> > --> filtering/security, and
--> > --> > > making
--> > --> > >>>> sure it isn't any worse than a bridged network.
--> > --> > >>> Understood, but a new standard is also a good place
--> > --> to improve.
--> > --> > >> The need for capabilities not in 802 now may be a good
--> > --> argument for
--> > --> > >> reserved bits
--> > --> > >>
--> > --> > >> Note that in hardware they too are problematic;
--> > --> > >
--> > --> > > I am not advocating reserved bit, I agree with 
--> you that they
--> are
--> > --> > > problematic and difficult to use in the future.
--> > --> > >
--> > --> > >
--> > --> > > we'd need three types:
--> > --> > >> 	- MUST set as 0 currently; MUST ignore on receipt
--> > --> > >> 		for optional extensions
--> > --> > >> 	- MUST set as 0 currently; MUST silently
--> > --> discard if not 0
--> > --> > >> 		for silently dropped required extensions
--> > --> > >> 	- MUST set as 0 currently; MUST report as error if not 0
--> > --> > >> 		for non0-silent required extensions
--> > --> > >>
--> > --> > >> I'd rather see the FTAG area blocked out for those
--> > --> kinds of bits at
--> > --> > > this
--> > --> > >> time than locked into a tag that a new VLAN header
--> > --> might replace,
--> > --> e.g.
--> > --> > >>
--> > --> > >
--> > --> > > The FTAG has two values:
--> > --> > >
--> > --> > > 1) for unicast traffic today 802 networks support:
--> > --> > >   a) per VLAN spanning tree
--> > --> > >   b) a single common spanning tree
--> > --> > >   c) shared spanning trees
--> > --> > >
--> > --> > > TRILL is the current equivalent of (b), (a) is 
--> pragmatically
--> > --> impossible,
--> > --> > > since you don't want to run an instance of ISIS per VLAN.
--> > --> >
--> > --> > Actually, I thought that was the plan.
--> > --> >
--> > --> > > If we want to
--> > --> > > support the equivalent of (c), we need to have a tag in
--> > --> the packet.
--> > --> > > Without a tag in the packet the implementations are
--> > --> full of corner
--> > --> > > cases.
--> > --> >
--> > --> > Not if we do (b), right?
--> > --> >
--> > --> > > 2) for multicast, if you want to have shared trees, you
--> > --> need a tag
--> > --> in
--> > --> > > the packet. In particular with two or three tiers
--> > --> networks the best
--> > --> > > solution is to have few shared trees rooted in the
--> > --> backbone. TRILL
--> > --> > > currently does not support this.
--> > --> >
--> > --> > It'd be useful to explain this further; I'm not exactly
--> > --> sure what you
--> > --> > mean. We had talked before about separate VLANs for 
--> broadcast,
--> > --> > multicast, and unicast groups.
--> > --> >
--> > --> > Joe
--> > -->
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [email-masked]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
--> 

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 16:47:21 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Joe Touch" <[email-masked]>, "Dino Farinacci \(dino\)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 7436

Eric,

Help me here, can you send a pointer to a presentation?

VLAN within a CRED can work for unicast, but not for multicast.
As multicast is currently defined in TRILL the root of the tree is
ALWAYS in the ingress RBridge, independently of how many VLANs you have.

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 3:13 PM
> To: Silvano Gai; Joe Touch; Dino Farinacci (dino)
> Cc: [email-masked]; Radia Perlman
> Subject: RE: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> Silvano,
> 
> 	The VLAN space you mention is larger in the RBridges case.
> It is possible to use 802.1Q encapsulation in the RBridge tunnel
> encapsulation -

>From this explanation I am not sure were you want to add the additional
1Q tag.

-- Silvano

 in a fashion similar to (but not necessarily the
> same as) the way in which it may be used in the native Ethernet.
> 
> 	Consequently, if - in a deployment - network administrators
> want to optimize load balancing, they may do so by defining VLANs
> within the CRED.  Sets of CRED-VLANs would be configurable to use
> distinguishable paths.
> 
> 	As Radia has pointed out in several previous presentations,
> one of the "keys" used in a look-up for the "ingress RBridge tree"
> is the VLAN in the tunnel encapsulation - assuming one is present.
> 
> 	This could - among other things - serve the purpose of "tags"
> for use as you describe.  Since configuration would be needed in
> either case, this is both equivalent to adding any additional tags
> and more than is strictly required to solve the problems we've set
> out to solve.
> 
> 	Note that this use of VLAN tags in the tunnel encapsulation
> - while not entirely orthogonal to VLAN tag usage in native encaps
> - does not necessarily result in depletion of the native VLAN tag
> space.
> 
> 	Effectively, by potentially having VLAN tags in the tunnel
> encapsulation, and in the native Ethernet encapsulation as well,
> you have more than 4K potential "VLANs" - not less.
> 
> --
> Eric
> 
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Thursday, October 19, 2006 5:44 PM
> --> To: Joe Touch; Dino Farinacci (dino)
> --> Cc: [email-masked]; Radia Perlman
> --> Subject: Re: [rbridge] Range of appllicability (was Re: TTL
> --> only - was RE: New fields in shim header?)
> -->
> -->
> --> Joe,
> -->
> --> I have hard time understanding how you can use separate VLANs for
> --> unicast and broadcast, this will, for example, break IPv4,
> --> due to ARP.
> -->
> --> Using separate VLANs for Unicast and Multicast will break
> --> IPv6, due to
> --> ND.
> -->
> --> Today, all the applications assume that they can send
> --> Unicast, Multicast
> --> and Broadcast on the same VLAN (they basically ignore that a VLAN
> --> exists).
> -->
> --> Remember that many networks deploy "Private VLANs", since they
don't
> --> have enough of 4K VLANs, so proposing to reduce the 4K space to
1/3
> --> seems highly unrealistic.
> -->
> --> Today TRILL specifies that multicast must be sent on the "ingress
> --> RBRidge tree" (for this reason, in the case of multicast,
> --> the ingress
> --> RBridge address is carried in the shim header). This
> --> provides shortest
> --> path, but not good load balancing. Multicast folks will
> --> prefer to have
> --> few shared trees routed in the core. In this way they get optimal
> --> forwarding, but also good load balancing. To support this it is
> --> necessary to carry in the frame an indication of the tree
> --> (FTAG) that
> --> needs to be used to forward the frame.
> -->
> --> I am sure that Dino can provide a better reply to this point.
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Joe Touch [mailto:[email-masked]]
> --> > Sent: Thursday, October 19, 2006 11:36 AM
> --> > To: Silvano Gai
> --> > Cc: Erik Nordmark; [email-masked]; Radia Perlman
> --> > Subject: Re: [rbridge] Range of appllicability (was Re:
> --> TTL only - was
> --> RE:
> --> > New fields in shim header?)
> --> >
> --> >
> --> >
> --> > Silvano Gai wrote:
> --> > > Joe,
> --> > >
> --> > >> -----Original Message-----
> --> > >> From: Joe Touch [mailto:[email-masked]]
> --> > >> Sent: Thursday, October 19, 2006 8:58 AM
> --> > >> To: Silvano Gai
> --> > >> Cc: Erik Nordmark; [email-masked]; Radia Perlman
> --> > >> Subject: Re: [rbridge] Range of appllicability (was
> --> Re: TTL only -
> --> was
> --> > > RE:
> --> > >> New fields in shim header?)
> --> > >>
> --> > >>
> --> > >>
> --> > >> Silvano Gai wrote:
> --> > >> ...
> --> > >>>> The reason I'm asking is because I see a big
> --> difference between
> --> > > asking
> --> > >>>> RBridges to provide some new degree of
> --> filtering/security, and
> --> > > making
> --> > >>>> sure it isn't any worse than a bridged network.
> --> > >>> Understood, but a new standard is also a good place
> --> to improve.
> --> > >> The need for capabilities not in 802 now may be a good
> --> argument for
> --> > >> reserved bits
> --> > >>
> --> > >> Note that in hardware they too are problematic;
> --> > >
> --> > > I am not advocating reserved bit, I agree with you that they
are
> --> > > problematic and difficult to use in the future.
> --> > >
> --> > >
> --> > > we'd need three types:
> --> > >> 	- MUST set as 0 currently; MUST ignore on receipt
> --> > >> 		for optional extensions
> --> > >> 	- MUST set as 0 currently; MUST silently
> --> discard if not 0
> --> > >> 		for silently dropped required extensions
> --> > >> 	- MUST set as 0 currently; MUST report as error if not 0
> --> > >> 		for non0-silent required extensions
> --> > >>
> --> > >> I'd rather see the FTAG area blocked out for those
> --> kinds of bits at
> --> > > this
> --> > >> time than locked into a tag that a new VLAN header
> --> might replace,
> --> e.g.
> --> > >>
> --> > >
> --> > > The FTAG has two values:
> --> > >
> --> > > 1) for unicast traffic today 802 networks support:
> --> > >   a) per VLAN spanning tree
> --> > >   b) a single common spanning tree
> --> > >   c) shared spanning trees
> --> > >
> --> > > TRILL is the current equivalent of (b), (a) is pragmatically
> --> impossible,
> --> > > since you don't want to run an instance of ISIS per VLAN.
> --> >
> --> > Actually, I thought that was the plan.
> --> >
> --> > > If we want to
> --> > > support the equivalent of (c), we need to have a tag in
> --> the packet.
> --> > > Without a tag in the packet the implementations are
> --> full of corner
> --> > > cases.
> --> >
> --> > Not if we do (b), right?
> --> >
> --> > > 2) for multicast, if you want to have shared trees, you
> --> need a tag
> --> in
> --> > > the packet. In particular with two or three tiers
> --> networks the best
> --> > > solution is to have few shared trees rooted in the
> --> backbone. TRILL
> --> > > currently does not support this.
> --> >
> --> > It'd be useful to explain this further; I'm not exactly
> --> sure what you
> --> > mean. We had talked before about separate VLANs for broadcast,
> --> > multicast, and unicast groups.
> --> >
> --> > Joe
> -->
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 16:40:15 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 876

Joe,

You said:
> We had talked before about separate VLANs for broadcast, 
> multicast, and unicast groups.

Not me!

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 2:48 PM
> To: Silvano Gai
> Cc: Dino Farinacci (dino); Erik Nordmark; [email-masked]; Radia
> Perlman
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > I have hard time understanding how you can use separate VLANs for
> > unicast and broadcast, this will, for example, break IPv4, due to
ARP.
> 
> Separate for different traffic classes, not separating unicast from
> broadcast. And I'm talking about the VLAN _inside_ the rbridge
(tunneled
> traffic), which has nothing to do with the VLAN outside the rbridge
per
> se.
> Joe

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Joe Touch <[email-masked]>, "Dino Farinacci (dino)" <[email-masked]>
Date: Thu, 19 Oct 2006 18:12:46 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE:	 New fields in shim header?)
Status: RO
Content-Length: 6410

Silvano,

	The VLAN space you mention is larger in the RBridges case.
It is possible to use 802.1Q encapsulation in the RBridge tunnel
encapsulation - in a fashion similar to (but not necessarily the
same as) the way in which it may be used in the native Ethernet.

	Consequently, if - in a deployment - network administrators
want to optimize load balancing, they may do so by defining VLANs
within the CRED.  Sets of CRED-VLANs would be configurable to use
distinguishable paths.

	As Radia has pointed out in several previous presentations,
one of the "keys" used in a look-up for the "ingress RBridge tree"
is the VLAN in the tunnel encapsulation - assuming one is present.

	This could - among other things - serve the purpose of "tags"
for use as you describe.  Since configuration would be needed in
either case, this is both equivalent to adding any additional tags
and more than is strictly required to solve the problems we've set
out to solve.

	Note that this use of VLAN tags in the tunnel encapsulation 
- while not entirely orthogonal to VLAN tag usage in native encaps
- does not necessarily result in depletion of the native VLAN tag
space.

	Effectively, by potentially having VLAN tags in the tunnel 
encapsulation, and in the native Ethernet encapsulation as well,
you have more than 4K potential "VLANs" - not less.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Thursday, October 19, 2006 5:44 PM
--> To: Joe Touch; Dino Farinacci (dino)
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> 
--> Joe,
--> 
--> I have hard time understanding how you can use separate VLANs for
--> unicast and broadcast, this will, for example, break IPv4, 
--> due to ARP.
--> 
--> Using separate VLANs for Unicast and Multicast will break 
--> IPv6, due to
--> ND.
--> 
--> Today, all the applications assume that they can send 
--> Unicast, Multicast
--> and Broadcast on the same VLAN (they basically ignore that a VLAN
--> exists).
--> 
--> Remember that many networks deploy "Private VLANs", since they don't
--> have enough of 4K VLANs, so proposing to reduce the 4K space to 1/3
--> seems highly unrealistic.
--> 
--> Today TRILL specifies that multicast must be sent on the "ingress
--> RBRidge tree" (for this reason, in the case of multicast, 
--> the ingress
--> RBridge address is carried in the shim header). This 
--> provides shortest
--> path, but not good load balancing. Multicast folks will 
--> prefer to have
--> few shared trees routed in the core. In this way they get optimal
--> forwarding, but also good load balancing. To support this it is
--> necessary to carry in the frame an indication of the tree 
--> (FTAG) that
--> needs to be used to forward the frame.
--> 
--> I am sure that Dino can provide a better reply to this point.
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Joe Touch [mailto:[email-masked]]
--> > Sent: Thursday, October 19, 2006 11:36 AM
--> > To: Silvano Gai
--> > Cc: Erik Nordmark; [email-masked]; Radia Perlman
--> > Subject: Re: [rbridge] Range of appllicability (was Re: 
--> TTL only - was
--> RE:
--> > New fields in shim header?)
--> > 
--> > 
--> > 
--> > Silvano Gai wrote:
--> > > Joe,
--> > >
--> > >> -----Original Message-----
--> > >> From: Joe Touch [mailto:[email-masked]]
--> > >> Sent: Thursday, October 19, 2006 8:58 AM
--> > >> To: Silvano Gai
--> > >> Cc: Erik Nordmark; [email-masked]; Radia Perlman
--> > >> Subject: Re: [rbridge] Range of appllicability (was 
--> Re: TTL only -
--> was
--> > > RE:
--> > >> New fields in shim header?)
--> > >>
--> > >>
--> > >>
--> > >> Silvano Gai wrote:
--> > >> ...
--> > >>>> The reason I'm asking is because I see a big 
--> difference between
--> > > asking
--> > >>>> RBridges to provide some new degree of 
--> filtering/security, and
--> > > making
--> > >>>> sure it isn't any worse than a bridged network.
--> > >>> Understood, but a new standard is also a good place 
--> to improve.
--> > >> The need for capabilities not in 802 now may be a good 
--> argument for
--> > >> reserved bits
--> > >>
--> > >> Note that in hardware they too are problematic;
--> > >
--> > > I am not advocating reserved bit, I agree with you that they are
--> > > problematic and difficult to use in the future.
--> > >
--> > >
--> > > we'd need three types:
--> > >> 	- MUST set as 0 currently; MUST ignore on receipt
--> > >> 		for optional extensions
--> > >> 	- MUST set as 0 currently; MUST silently 
--> discard if not 0
--> > >> 		for silently dropped required extensions
--> > >> 	- MUST set as 0 currently; MUST report as error if not 0
--> > >> 		for non0-silent required extensions
--> > >>
--> > >> I'd rather see the FTAG area blocked out for those 
--> kinds of bits at
--> > > this
--> > >> time than locked into a tag that a new VLAN header 
--> might replace,
--> e.g.
--> > >>
--> > >
--> > > The FTAG has two values:
--> > >
--> > > 1) for unicast traffic today 802 networks support:
--> > >   a) per VLAN spanning tree
--> > >   b) a single common spanning tree
--> > >   c) shared spanning trees
--> > >
--> > > TRILL is the current equivalent of (b), (a) is pragmatically
--> impossible,
--> > > since you don't want to run an instance of ISIS per VLAN.
--> > 
--> > Actually, I thought that was the plan.
--> > 
--> > > If we want to
--> > > support the equivalent of (c), we need to have a tag in 
--> the packet.
--> > > Without a tag in the packet the implementations are 
--> full of corner
--> > > cases.
--> > 
--> > Not if we do (b), right?
--> > 
--> > > 2) for multicast, if you want to have shared trees, you 
--> need a tag
--> in
--> > > the packet. In particular with two or three tiers 
--> networks the best
--> > > solution is to have few shared trees rooted in the 
--> backbone. TRILL
--> > > currently does not support this.
--> > 
--> > It'd be useful to explain this further; I'm not exactly 
--> sure what you
--> > mean. We had talked before about separate VLANs for broadcast,
--> > multicast, and unicast groups.
--> > 
--> > Joe
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Thu, 19 Oct 2006 14:47:35 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1100

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig79019255DC43C60816DA71F4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> I have hard time understanding how you can use separate VLANs for
> unicast and broadcast, this will, for example, break IPv4, due to ARP.

Separate for different traffic classes, not separating unicast from
broadcast. And I'm talking about the VLAN _inside_ the rbridge (tunneled
traffic), which has nothing to do with the VLAN outside the rbridge per s=
e.

Joe

--------------enig79019255DC43C60816DA71F4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig79019255DC43C60816DA71F4--

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 14:47:29 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 11350

Disagreement noted, waiting for the explanation

Cheers

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 11:48 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] FTag
> 
> Silvano,
> 
> 	In order to avoid giving the impression that I agree with the
> below analysis, I've discovered that I need to respond to it.
However,
> I do not currently have the time to do so in depth.
> 
> 	So please accept this brief note as evidence that I disagree
> with your analysis and conclusions with respect to alignment needs.
> I will respond in depth - hopefully - sometime next week...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[email-masked]]
> --> Sent: Wednesday, October 18, 2006 12:04 PM
> --> To: Gray, Eric
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> -->
> --> Eric,
> -->
> --> Let me depict you what happens when you insert one MPLS
> --> label, ore a 1Q
> --> option or a 1S option
> -->
> --> Original:
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    Ethertype   |   Payload     |
> --> +--------------------------------+
> --> |                                |
> --> |         ...........            |
> -->
> -->
> --> Original + Opt (where Opt can be MPLS, 1Q or 1S)
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    Ethertype   |      Opt      |
> --> +--------------------------------+
> --> |      opt       |   Payload     |
> --> +--------------------------------+
> --> |                                |
> --> |         ...........            |
> -->
> --> The HW that perform the insertion/removal does not need to
> --> realign the
> --> payload that is in its buffer.
> -->
> -->
> --> Now Let's consider the encapsulation/decapsulation function
> --> by looking
> --> at the Original frame + TRILL header (as proposed by the
> --> current draft)
> --> +--------------------------------+
> --> |         Outer DA               |
> --> +----------------+---------------+
> --> |    Outer DA    |  Outer SA     |
> --> +----------------+---------------+
> --> |         Outer SA               |
> --> +--------------------------------+
> --> |Ethertype=TRILL |   Trill Shim  |
> --> +--------------------------------+
> --> |  Trill Shim    |  ????????     |
> --> +--------------------------------+
> --> |               DA               |
> --> +----------------+---------------+
> --> |       DA       |     SA        |
> --> +----------------+---------------+
> --> |               SA               |
> --> +--------------------------------+
> --> |    Ethertype   |   Payload     |
> --> +--------------------------------+
> --> |                                |
> --> |         ...........            |
> -->
> --> If you don't have the 16 bits indicated by ???????, the
> --> hardware will
> --> need to realign the inner frame. The frame is not on the
> --> wire. The frame
> --> sits in the packet buffer and the memory bandwidth of the
> --> packet buffer
> --> is today the MOST important consideration in port ASIC design.
> -->
> --> More inline
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[email-masked]]
> --> > Sent: Wednesday, October 18, 2006 4:57 AM
> --> > To: Silvano Gai
> --> > Cc: [email-masked]
> --> > Subject: RE: [rbridge] FTag
> --> >
> --> > Silvano,
> --> >
> --> > Let me answer your points in order, leaving out irrelevant
issues:
> --> >
> --> > <Your Point> N*32 is correct, when including Ethernet
> --> options/shims
> --> >              (e.g. .1Q or .1S).  This is hardware
> --> friendly, because
> --> > 		 alignment doesn't change going from one header
to
> --> another.
> --> >
> --> > There are a few different "Ethernet" encapsulations, once
> --> we start to
> --> > include Ethernet options and the shims associated with
> --> those options.
> --> >
> --> > First, and I believe most important, the "shim" we are
> --> talking about
> --> > (in TRILL) is not an Ethernet option (or associated shim).  It's
a
> --> > "shim" as a separate "layer."  Otherwise, it would be
> --> inappropriate
> --> > for us to do this work here (in TRILL, as part of the IETF).
> -->
> --> From the above picture it should be clear that you should
> --> consider the
> --> TRILL header as a whole, and the TRILL header as only one form of
> --> Ethernet encapsulation.
> -->
> --> >
> --> > Second, "Ethernet" headers do not all align the same.
> --> >
> -->
> --> Agreed, but that is not my concern, My concern is to not
> --> change their
> --> alignment due to the insertion/removal of the TRILL header.
> -->
> --> > Currently, we are talking about having a single Ethertype
> --> defined to
> --> > distinguish inter-RBridge traffic from other types of
> --> Ethernet frames.
> --> > If your implementation produces 32-bit aligned Ethernet
> --> frames, using
> --> > 802.1Q, then it will similarly produce 32-bit aligned
> --> frames - prior
> --> > to considering the TRILL shim - using the new Ethertype.
> --> >
> --> > We are not proposing a change in any Ethernet frame/header
format.
> -->
> --> Neither do I.
> -->
> --> >
> --> > The reference to 802.1Q is slightly disingenuous, because 802.1Q
> --> > effectively displaces the existing Ethertype by 32 bits.  802.1Q
> --> > "shims" include the Ethertype, because they replace the original
> --> > one with 0x8100 and have to include the original in the "shim."
> --> >
> --> > I assume that a similar observation could be made about 802.1S.
> -->
> --> Yes and a similar observation can be made for MPLS, but all
> --> these three
> --> do not change the alignment of the fields that follow.
> -->
> --> >
> --> > In TRILL, we are not replacing the original Ethertype, we
> --> are adding
> --> > a new encapsulation.  The original Ethertype stays in the
original
> --> > - re-encapsulated, or tunneled - Ethernet frame.
> --> Therefore, there's
> --> > no reason to consider the Ethertype to be part of the TRILL
shim.
> -->
> --> As I told before you need to consider the whole TRILL header, i.e.
> --> 6 bytes of DA
> --> 6 bytes of SA
> --> 2 bytes of Ethertype
> --> 4 bytes of shim
> --> ----------------------
> --> 18 bytes
> -->
> --> Which is 2 bytes short of N*32, i.e. it is not HW friendly.
> -->
> --> For this reason I propose that Ethertype + shim should be
> --> N*32 to be HW
> --> friendly.
> -->
> -->
> --> >
> --> > <Your Point> TRILL should adopt this model for its shim
> --> header - the
> --> >              Ethertype should be included as part of
> --> computing "shim"
> --> >              size.
> --> >
> --> > In TRILL, we are not replacing the original Ethertype, we
> --> are adding
> --> > a new encapsulation.  The original Ethertype stays in the
original
> --> > - re-encapsulated, or tunneled - Ethernet frame.
> --> Therefore, there's
> --> > no reason to consider the Ethertype to be part of the TRILL
shim.
> --> >
> --> > <Your Point> TRILL should optimize the Ethernet case that
> --> will cover
> --> 99%
> --> >              of TRILL applications.
> --> >
> --> > Coverage is slightly more complete than that.
> --> Considering all of the
> --> > layer 2 encapsulations that currently come under an
> --> Ethernet umbrella,
> --> > TRILL applications are 100% included.
> --> >
> --> > I think we are essentially in agreement on this point.
> --> >
> --> > <Your Point> TRILL bridges will be implemented mainly in
> --> hardware and
> --> >              the encapsulation and decapsulation
> --> functions need to be
> --> >              HW friendly.
> --> >
> --> > Okay.  I was not making any other point - except to say
> --> that alignment
> --> > is usually a software concern, especially in initial design.
> --> >
> --> > Let me be blunt, alignment does not factor into initial hardware
> --> design,
> --> > but is an issue with hardware re-use complexity.  Bits on
> --> a wire are
> --> not
> --> > "aligned" - you simply collect them as they arrive, serially.
> -->
> --> I agree that bits on the wire are not aligned, but you need
> --> to buffer
> --> the incoming frame (or at least part of it) until you have
> --> enough fields
> --> to perform your lookup and decide what to do with the
> --> frame. From that
> --> point on the frame is not on the wire, it is in the packet
> --> buffer and
> --> alignment is crucial at the performance we are talking about.
> -->
> --> I hope this time I made my point more clear
> -->
> --> -- Silvano
> -->
> --> >
> --> > And, in any case, the "alignment issue" is moot, unless you
assume
> --> that
> --> > we need to add an _additional_ Ethertype and I am not
> --> including that
> --> in
> --> > my size computation.
> --> >
> --> > We do not need the additional Ethertype, consequently, we
> --> do not have
> --> to
> --> > account for it.
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:[email-masked]]
> --> > --> Sent: Wednesday, October 18, 2006 12:05 AM
> --> > --> To: Gray, Eric; Caitlin Bestler
> --> > --> Cc: [email-masked]
> --> > --> Subject: RE: [rbridge] FTag
> --> > -->
> --> > -->
> --> > --> Eric,
> --> > -->
> --> > --> I beg to differ.
> --> > -->
> --> > --> N*32 is correct, if you include the 16 bits of Ethertype.
> --> > -->
> --> > --> With all the respect for wikipedia, I prefer a
> --> reference to IEEE
> --> > 802.1Q
> --> > --> and IEEE 802.1D in which the Ethertype is considered
> --> part of the
> --> > options/shims.
> --> > -->
> --> > --> This is what happens for options like .1Q or .1S (16 bit of
> --> Ethertype
> --> > +
> --> > --> 16 bits of options).
> --> > -->
> --> > --> This is hardware friendly, since inserting or
> --> removing the shim
> --> does
> --> > not
> --> > --> change the 32 bit alignment of what follows.
> --> > -->
> --> > --> IMHO TRILL should adopt a shim header that is N*32
> --> including the
> --> > --> Ethertype = TRILL or 16 + M*32 excluding the Ethertype.
> --> > -->
> --> > --> I don't buy that, to be layer 2 independent, we need to not
> --> optimize
> --> > the
> --> > --> Ethernet case that will cover 99% of TRILL applications.
> --> > -->
> --> > --> I also don't buy any software implementation arguments:
TRILL
> --> bridges
> --> > --> will be implemented mainly in hardware and the
> --> encapsulation and
> --> > --> decapsulation functions need to be HW friendly.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:[email-masked]]
> --> > --> > Sent: Tuesday, October 17, 2006 9:48 AM
> --> > --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
> --> > --> > Cc: [email-masked]
> --> > --> > Subject: RE: [rbridge] FTag
> --> > ---[SNIP]---
> -->

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 14:44:11 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Dino Farinacci \(dino\)" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 3929

Joe,

I have hard time understanding how you can use separate VLANs for
unicast and broadcast, this will, for example, break IPv4, due to ARP.

Using separate VLANs for Unicast and Multicast will break IPv6, due to
ND.

Today, all the applications assume that they can send Unicast, Multicast
and Broadcast on the same VLAN (they basically ignore that a VLAN
exists).

Remember that many networks deploy "Private VLANs", since they don't
have enough of 4K VLANs, so proposing to reduce the 4K space to 1/3
seems highly unrealistic.

Today TRILL specifies that multicast must be sent on the "ingress
RBRidge tree" (for this reason, in the case of multicast, the ingress
RBridge address is carried in the shim header). This provides shortest
path, but not good load balancing. Multicast folks will prefer to have
few shared trees routed in the core. In this way they get optimal
forwarding, but also good load balancing. To support this it is
necessary to carry in the frame an indication of the tree (FTAG) that
needs to be used to forward the frame.

I am sure that Dino can provide a better reply to this point.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 11:36 AM
> To: Silvano Gai
> Cc: Erik Nordmark; [email-masked]; Radia Perlman
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Thursday, October 19, 2006 8:58 AM
> >> To: Silvano Gai
> >> Cc: Erik Nordmark; [email-masked]; Radia Perlman
> >> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only -
was
> > RE:
> >> New fields in shim header?)
> >>
> >>
> >>
> >> Silvano Gai wrote:
> >> ...
> >>>> The reason I'm asking is because I see a big difference between
> > asking
> >>>> RBridges to provide some new degree of filtering/security, and
> > making
> >>>> sure it isn't any worse than a bridged network.
> >>> Understood, but a new standard is also a good place to improve.
> >> The need for capabilities not in 802 now may be a good argument for
> >> reserved bits
> >>
> >> Note that in hardware they too are problematic;
> >
> > I am not advocating reserved bit, I agree with you that they are
> > problematic and difficult to use in the future.
> >
> >
> > we'd need three types:
> >> 	- MUST set as 0 currently; MUST ignore on receipt
> >> 		for optional extensions
> >> 	- MUST set as 0 currently; MUST silently discard if not 0
> >> 		for silently dropped required extensions
> >> 	- MUST set as 0 currently; MUST report as error if not 0
> >> 		for non0-silent required extensions
> >>
> >> I'd rather see the FTAG area blocked out for those kinds of bits at
> > this
> >> time than locked into a tag that a new VLAN header might replace,
e.g.
> >>
> >
> > The FTAG has two values:
> >
> > 1) for unicast traffic today 802 networks support:
> >   a) per VLAN spanning tree
> >   b) a single common spanning tree
> >   c) shared spanning trees
> >
> > TRILL is the current equivalent of (b), (a) is pragmatically
impossible,
> > since you don't want to run an instance of ISIS per VLAN.
> 
> Actually, I thought that was the plan.
> 
> > If we want to
> > support the equivalent of (c), we need to have a tag in the packet.
> > Without a tag in the packet the implementations are full of corner
> > cases.
> 
> Not if we do (b), right?
> 
> > 2) for multicast, if you want to have shared trees, you need a tag
in
> > the packet. In particular with two or three tiers networks the best
> > solution is to have few shared trees rooted in the backbone. TRILL
> > currently does not support this.
> 
> It'd be useful to explain this further; I'm not exactly sure what you
> mean. We had talked before about separate VLANs for broadcast,
> multicast, and unicast groups.
> 
> Joe

Date: Thu, 19 Oct 2006 12:09:10 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 3532

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF5A2F0FB2A1E6CF43748320E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

FWIW, regarding reserved bits:

Joe Touch wrote:
=2E..
>>> The need for capabilities not in 802 now may be a good argument for
>>> reserved bits
>>>
>>> Note that in hardware they too are problematic;=20
>> I am not advocating reserved bit, I agree with you that they are
>> problematic and difficult to use in the future.

They're problematic because we typically define them as Type I (see
below), but Type I is the least useful IMO compared to Type II and III.

The only issue is that type needs to be declared in advance, or
indicated in-band (the latter as IPv6 hop options do to some extent).

I'd rather give some bits each to Types I-III and another 8 to hopcount,
 and put both source/dest in the header than add FTAGs now, i.e.:

+--------+--------+
|11122233|hhhhhhhh|
+--------+--------+
|rbridge-source   |
+--------+--------+
|rbridge-destn    |
+--------+--------+

111 =3D Type I reserved bits
222 =3D Type II reserved bits
33  =3D Type III reserved bits
hhhhhhh =3D hopcount (7 bits)

That consumes 6 bytes.

The minimum header, IMO, ought to be 3 bytes:

+--------+--------+
|rbridge-destn    |
+--------+--------+
|hhhhhhhh|
+--------+

Frankly, I'd rather see a 3-byte shim.

JOe

-------------------------------------------------------------------------=
--

>> we'd need three types:

Type I:
>>> 	- MUST set as 0 currently; MUST ignore on receipt
>>> 		for optional extensions

Type II:
>>> 	- MUST set as 0 currently; MUST silently discard if not 0
>>> 		for silently dropped required extensions

Type III:
>>> 	- MUST set as 0 currently; MUST report as error if not 0
>>> 		for non0-silent required extensions
>>>
>>> I'd rather see the FTAG area blocked out for those kinds of bits at
>> this
>>> time than locked into a tag that a new VLAN header might replace, e.g=
=2E
>>>
>> The FTAG has two values:
>>
>> 1) for unicast traffic today 802 networks support:
>>   a) per VLAN spanning tree
>>   b) a single common spanning tree
>>   c) shared spanning trees
>>
>> TRILL is the current equivalent of (b), (a) is pragmatically impossibl=
e,
>> since you don't want to run an instance of ISIS per VLAN.=20
>=20
> Actually, I thought that was the plan.
>=20
>> If we want to
>> support the equivalent of (c), we need to have a tag in the packet.
>> Without a tag in the packet the implementations are full of corner
>> cases.=20
>=20
> Not if we do (b), right?
>=20
>> 2) for multicast, if you want to have shared trees, you need a tag in
>> the packet. In particular with two or three tiers networks the best
>> solution is to have few shared trees rooted in the backbone. TRILL
>> currently does not support this.
>=20
> It'd be useful to explain this further; I'm not exactly sure what you
> mean. We had talked before about separate VLANs for broadcast,
> multicast, and unicast groups.
>=20
> Joe
>=20

--------------enigF5A2F0FB2A1E6CF43748320E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigF5A2F0FB2A1E6CF43748320E--

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Thu, 19 Oct 2006 14:47:40 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 10540

Silvano,

	In order to avoid giving the impression that I agree with the
below analysis, I've discovered that I need to respond to it.  However,
I do not currently have the time to do so in depth.

	So please accept this brief note as evidence that I disagree
with your analysis and conclusions with respect to alignment needs.
I will respond in depth - hopefully - sometime next week...

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Wednesday, October 18, 2006 12:04 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> 
--> Eric,
--> 
--> Let me depict you what happens when you insert one MPLS 
--> label, ore a 1Q
--> option or a 1S option
--> 
--> Original:
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> 
--> Original + Opt (where Opt can be MPLS, 1Q or 1S)
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |      Opt      |
--> +--------------------------------+
--> |      opt       |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> The HW that perform the insertion/removal does not need to 
--> realign the
--> payload that is in its buffer.
--> 
--> 
--> Now Let's consider the encapsulation/decapsulation function 
--> by looking
--> at the Original frame + TRILL header (as proposed by the 
--> current draft)
--> +--------------------------------+
--> |         Outer DA               |
--> +----------------+---------------+
--> |    Outer DA    |  Outer SA     |
--> +----------------+---------------+
--> |         Outer SA               |
--> +--------------------------------+
--> |Ethertype=TRILL |   Trill Shim  |
--> +--------------------------------+
--> |  Trill Shim    |  ????????     |
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    Ethertype   |   Payload     |
--> +--------------------------------+
--> |                                |
--> |         ...........            |
--> 
--> If you don't have the 16 bits indicated by ???????, the 
--> hardware will
--> need to realign the inner frame. The frame is not on the 
--> wire. The frame
--> sits in the packet buffer and the memory bandwidth of the 
--> packet buffer
--> is today the MOST important consideration in port ASIC design.
--> 
--> More inline
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Wednesday, October 18, 2006 4:57 AM
--> > To: Silvano Gai
--> > Cc: [email-masked]
--> > Subject: RE: [rbridge] FTag
--> > 
--> > Silvano,
--> > 
--> > Let me answer your points in order, leaving out irrelevant issues:
--> > 
--> > <Your Point> N*32 is correct, when including Ethernet 
--> options/shims
--> >              (e.g. .1Q or .1S).  This is hardware 
--> friendly, because
--> > 		 alignment doesn't change going from one header to
--> another.
--> > 
--> > There are a few different "Ethernet" encapsulations, once 
--> we start to
--> > include Ethernet options and the shims associated with 
--> those options.
--> > 
--> > First, and I believe most important, the "shim" we are 
--> talking about
--> > (in TRILL) is not an Ethernet option (or associated shim).  It's a
--> > "shim" as a separate "layer."  Otherwise, it would be 
--> inappropriate
--> > for us to do this work here (in TRILL, as part of the IETF).
--> 
--> From the above picture it should be clear that you should 
--> consider the
--> TRILL header as a whole, and the TRILL header as only one form of
--> Ethernet encapsulation.
--> 
--> > 
--> > Second, "Ethernet" headers do not all align the same.
--> > 
--> 
--> Agreed, but that is not my concern, My concern is to not 
--> change their
--> alignment due to the insertion/removal of the TRILL header.
--> 
--> > Currently, we are talking about having a single Ethertype 
--> defined to
--> > distinguish inter-RBridge traffic from other types of 
--> Ethernet frames.
--> > If your implementation produces 32-bit aligned Ethernet 
--> frames, using
--> > 802.1Q, then it will similarly produce 32-bit aligned 
--> frames - prior
--> > to considering the TRILL shim - using the new Ethertype.
--> > 
--> > We are not proposing a change in any Ethernet frame/header format.
--> 
--> Neither do I.
--> 
--> > 
--> > The reference to 802.1Q is slightly disingenuous, because 802.1Q
--> > effectively displaces the existing Ethertype by 32 bits.  802.1Q
--> > "shims" include the Ethertype, because they replace the original
--> > one with 0x8100 and have to include the original in the "shim."
--> > 
--> > I assume that a similar observation could be made about 802.1S.
--> 
--> Yes and a similar observation can be made for MPLS, but all 
--> these three
--> do not change the alignment of the fields that follow.
--> 
--> > 
--> > In TRILL, we are not replacing the original Ethertype, we 
--> are adding
--> > a new encapsulation.  The original Ethertype stays in the original
--> > - re-encapsulated, or tunneled - Ethernet frame.  
--> Therefore, there's
--> > no reason to consider the Ethertype to be part of the TRILL shim.
--> 
--> As I told before you need to consider the whole TRILL header, i.e.
--> 6 bytes of DA
--> 6 bytes of SA
--> 2 bytes of Ethertype
--> 4 bytes of shim
--> ----------------------
--> 18 bytes
--> 
--> Which is 2 bytes short of N*32, i.e. it is not HW friendly.
--> 
--> For this reason I propose that Ethertype + shim should be 
--> N*32 to be HW
--> friendly.
--> 
--> 
--> > 
--> > <Your Point> TRILL should adopt this model for its shim 
--> header - the
--> >              Ethertype should be included as part of 
--> computing "shim"
--> >              size.
--> > 
--> > In TRILL, we are not replacing the original Ethertype, we 
--> are adding
--> > a new encapsulation.  The original Ethertype stays in the original
--> > - re-encapsulated, or tunneled - Ethernet frame.  
--> Therefore, there's
--> > no reason to consider the Ethertype to be part of the TRILL shim.
--> > 
--> > <Your Point> TRILL should optimize the Ethernet case that 
--> will cover
--> 99%
--> >              of TRILL applications.
--> > 
--> > Coverage is slightly more complete than that.  
--> Considering all of the
--> > layer 2 encapsulations that currently come under an 
--> Ethernet umbrella,
--> > TRILL applications are 100% included.
--> > 
--> > I think we are essentially in agreement on this point.
--> > 
--> > <Your Point> TRILL bridges will be implemented mainly in 
--> hardware and
--> >              the encapsulation and decapsulation 
--> functions need to be
--> >              HW friendly.
--> > 
--> > Okay.  I was not making any other point - except to say 
--> that alignment
--> > is usually a software concern, especially in initial design.
--> > 
--> > Let me be blunt, alignment does not factor into initial hardware
--> design,
--> > but is an issue with hardware re-use complexity.  Bits on 
--> a wire are
--> not
--> > "aligned" - you simply collect them as they arrive, serially.
--> 
--> I agree that bits on the wire are not aligned, but you need 
--> to buffer
--> the incoming frame (or at least part of it) until you have 
--> enough fields
--> to perform your lookup and decide what to do with the 
--> frame. From that
--> point on the frame is not on the wire, it is in the packet 
--> buffer and
--> alignment is crucial at the performance we are talking about.
--> 
--> I hope this time I made my point more clear
--> 
--> -- Silvano
--> 
--> > 
--> > And, in any case, the "alignment issue" is moot, unless you assume
--> that
--> > we need to add an _additional_ Ethertype and I am not 
--> including that
--> in
--> > my size computation.
--> > 
--> > We do not need the additional Ethertype, consequently, we 
--> do not have
--> to
--> > account for it.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[email-masked]]
--> > --> Sent: Wednesday, October 18, 2006 12:05 AM
--> > --> To: Gray, Eric; Caitlin Bestler
--> > --> Cc: [email-masked]
--> > --> Subject: RE: [rbridge] FTag
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> I beg to differ.
--> > -->
--> > --> N*32 is correct, if you include the 16 bits of Ethertype.
--> > -->
--> > --> With all the respect for wikipedia, I prefer a 
--> reference to IEEE
--> > 802.1Q
--> > --> and IEEE 802.1D in which the Ethertype is considered 
--> part of the
--> > options/shims.
--> > -->
--> > --> This is what happens for options like .1Q or .1S (16 bit of
--> Ethertype
--> > +
--> > --> 16 bits of options).
--> > -->
--> > --> This is hardware friendly, since inserting or 
--> removing the shim
--> does
--> > not
--> > --> change the 32 bit alignment of what follows.
--> > -->
--> > --> IMHO TRILL should adopt a shim header that is N*32 
--> including the
--> > --> Ethertype = TRILL or 16 + M*32 excluding the Ethertype.
--> > -->
--> > --> I don't buy that, to be layer 2 independent, we need to not
--> optimize
--> > the
--> > --> Ethernet case that will cover 99% of TRILL applications.
--> > -->
--> > --> I also don't buy any software implementation arguments: TRILL
--> bridges
--> > --> will be implemented mainly in hardware and the 
--> encapsulation and
--> > --> decapsulation functions need to be HW friendly.
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[email-masked]]
--> > --> > Sent: Tuesday, October 17, 2006 9:48 AM
--> > --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
--> > --> > Cc: [email-masked]
--> > --> > Subject: RE: [rbridge] FTag
--> > ---[SNIP]---
--> 

Date: Thu, 19 Oct 2006 11:35:45 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 3089

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig338A4CA00817C80A74154376
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Thursday, October 19, 2006 8:58 AM
>> To: Silvano Gai
>> Cc: Erik Nordmark; [email-masked]; Radia Perlman
>> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was=

> RE:
>> New fields in shim header?)
>>
>>
>>
>> Silvano Gai wrote:
>> ...
>>>> The reason I'm asking is because I see a big difference between
> asking
>>>> RBridges to provide some new degree of filtering/security, and
> making
>>>> sure it isn't any worse than a bridged network.
>>> Understood, but a new standard is also a good place to improve.
>> The need for capabilities not in 802 now may be a good argument for
>> reserved bits
>>
>> Note that in hardware they too are problematic;=20
>=20
> I am not advocating reserved bit, I agree with you that they are
> problematic and difficult to use in the future.
>=20
>=20
> we'd need three types:
>> 	- MUST set as 0 currently; MUST ignore on receipt
>> 		for optional extensions
>> 	- MUST set as 0 currently; MUST silently discard if not 0
>> 		for silently dropped required extensions
>> 	- MUST set as 0 currently; MUST report as error if not 0
>> 		for non0-silent required extensions
>>
>> I'd rather see the FTAG area blocked out for those kinds of bits at
> this
>> time than locked into a tag that a new VLAN header might replace, e.g.=

>>
>=20
> The FTAG has two values:
>=20
> 1) for unicast traffic today 802 networks support:
>   a) per VLAN spanning tree
>   b) a single common spanning tree
>   c) shared spanning trees
>=20
> TRILL is the current equivalent of (b), (a) is pragmatically impossible=
,
> since you don't want to run an instance of ISIS per VLAN.=20

Actually, I thought that was the plan.

> If we want to
> support the equivalent of (c), we need to have a tag in the packet.
> Without a tag in the packet the implementations are full of corner
> cases.=20

Not if we do (b), right?

> 2) for multicast, if you want to have shared trees, you need a tag in
> the packet. In particular with two or three tiers networks the best
> solution is to have few shared trees rooted in the backbone. TRILL
> currently does not support this.

It'd be useful to explain this further; I'm not exactly sure what you
mean. We had talked before about separate VLANs for broadcast,
multicast, and unicast groups.

Joe

--------------enig338A4CA00817C80A74154376
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig338A4CA00817C80A74154376--

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 11:05:22 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 2048

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 8:58 AM
> To: Silvano Gai
> Cc: Erik Nordmark; [email-masked]; Radia Perlman
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> 
> 
> Silvano Gai wrote:
> ...
> >> The reason I'm asking is because I see a big difference between
asking
> >> RBridges to provide some new degree of filtering/security, and
making
> >> sure it isn't any worse than a bridged network.
> >
> > Understood, but a new standard is also a good place to improve.
> 
> The need for capabilities not in 802 now may be a good argument for
> reserved bits
> 
> Note that in hardware they too are problematic; 

I am not advocating reserved bit, I agree with you that they are
problematic and difficult to use in the future.

we'd need three types:
> 
> 	- MUST set as 0 currently; MUST ignore on receipt
> 		for optional extensions
> 	- MUST set as 0 currently; MUST silently discard if not 0
> 		for silently dropped required extensions
> 	- MUST set as 0 currently; MUST report as error if not 0
> 		for non0-silent required extensions
> 
> I'd rather see the FTAG area blocked out for those kinds of bits at
this
> time than locked into a tag that a new VLAN header might replace, e.g.
> 

The FTAG has two values:

1) for unicast traffic today 802 networks support:
  a) per VLAN spanning tree
  b) a single common spanning tree
  c) shared spanning trees

TRILL is the current equivalent of (b), (a) is pragmatically impossible,
since you don't want to run an instance of ISIS per VLAN. If we want to
support the equivalent of (c), we need to have a tag in the packet.
Without a tag in the packet the implementations are full of corner
cases. 

2) for multicast, if you want to have shared trees, you need a tag in
the packet. In particular with two or three tiers networks the best
solution is to have few shared trees rooted in the backbone. TRILL
currently does not support this.

-- Silvano

Date: Thu, 19 Oct 2006 10:59:29 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, [email-masked]
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1877

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0A290B9A7F89EF1CA45035BD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Thursday, October 19, 2006 10:08 AM
>> To: Silvano Gai
>> Cc: Caitlin Bestler; Erik Nordmark; Ed Bowen; [email-masked];
> rbridge-
>> [email-masked]; Radia Perlman
>> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
>>
>>
>>
>> Silvano Gai wrote:
>>> Caitlin,
>>>
>>> ....
>>>
>>>> For the same reason Bernard Aboba cited on wireless. An set of
>>>> RBridges can distribute the new location information more
>>>> efficiently than existing bridges.
>>> When a VM move the first thing it does is an ARP, i.e. it sends a
>>> broadcast packet.
>> ...
>>> I doubt that in this aspect TRILL is more efficient that .1D, or am
> I
>>> missing something?
>> There's no rule to force an ARP upon move, but that would affect all
> 802
>> nets, including TRILL ones, equally badly.
>>
>=20
> I don't understand the last sentence, why does an ARP affect 802 nets
> badly?

Nodes that move and do not do ARP immediately affect 802 nets and TRILL
badly. You noted that 'most commercial nodes do this' (paraphrased), but
it's not a requirement.

Joe

--------------enig0A290B9A7F89EF1CA45035BD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0A290B9A7F89EF1CA45035BD--

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 10:50:22 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, [email-masked]
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 970

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 10:08 AM
> To: Silvano Gai
> Cc: Caitlin Bestler; Erik Nordmark; Ed Bowen; [email-masked];
rbridge-
> [email-masked]; Radia Perlman
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
> > Caitlin,
> >
> > ....
> >
> >> For the same reason Bernard Aboba cited on wireless. An set of
> >> RBridges can distribute the new location information more
> >> efficiently than existing bridges.
> >
> > When a VM move the first thing it does is an ARP, i.e. it sends a
> > broadcast packet.
> ...
> > I doubt that in this aspect TRILL is more efficient that .1D, or am
I
> > missing something?
> 
> There's no rule to force an ARP upon move, but that would affect all
802
> nets, including TRILL ones, equally badly.
> 

I don't understand the last sentence, why does an ARP affect 802 nets
badly?

-- Silvano

Date: Thu, 19 Oct 2006 10:29:54 -0700
From: Joe Touch <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 5038

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBC7C914195DFE2269FD8F43B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dinesh G Dutt wrote:
> I apologize for not responding to Joe's email earlier. I'd like to take=
=20
> another a more verbose crack (compared to my previous rather terse=20
> email) at stating why we need both ingress rbridge ID and FTAG.
>=20
> Ingress Rbridge is essential for multiple purposes especially for=20
> troubleshooting and for sending error messages or reports from the=20
> middle of the Rbridge core to the ingress Rbridge. Consider for example=
,=20
> the backward congestion notification scheme that is being pursued in=20
> IEEE (802.1au). If I want to deploy that work in Rbridges, I need the=20
> ability to signal congestion from the middle of the network back to the=
=20
> ingress Rbridge or source end station. If I do not have the ingress=20
> Rbridge in the frame, the only way to derive that address is by=20
> populating all the edge MAC addresses in the core of the network; this =

> defeats one of the key objectives of an Rbridge, IMHO.
>=20
> Over and over again, I've heard customers tell me that debugging the=20
> network is a critical feature that they want built into the products.=20
> With the help of TTL and ingress Rbridge ID, we can deliver a layer 2=20
> traceroute through the Rbridge network. This seems a critical feature t=
o=20
> me.

I buy Erik's observation that both addresses aren't strictly needed.
There's no traceroute through ethernet switches now; I don't see why
they ought to be supported uniquely in an rbridge.

> While I'll agree that having an ingress Rbridge isn't essential for=20
> security as Silvano stated it, I also think it is not an incorrect case=
=2E=20
> With an ingress Rbridge field in the frame, I can support customers who=
=20
> envisage Silvano's way of doing things.
>=20
> I'm unaware of any protocol, tunnelling or otherwise, that does not=20
> carry both an ingress and egress endpoint address in the header. Before=
=20
> you can utter that four letter word at me, remember that MPLS changes=20
> labels hop-by-hop; so having an ingress and egress in MPLS is not very
> useful. I can visualize other optimizations and features that can be=20
> deployed if I have both ingress and egress addresses in a frame.

This argues for using an IP header as the shim, at which point we just
ought to deploy routers as rbridge nodes and call it a day. See below.

> On the question of FTAG, I see three main usage cases.
> - The approach currently being pursued in TRILL does not seem different=
=20
> to me from the approach taken by 802.1D when they mandated a single=20
> spanning tree for all VLANs. While TRILL doesn't suffer from the proble=
m=20
> of a single spanning tree, I can see various reasons why customers may =

> prefer to keep a small number of separate forwarding topologies, not=20
> unlike a multiple spanning tree approach.
> - With the advent of I/O consolidation, people will want to traffic=20
> engineer their campus networks. FTAG allows you to do what MPLS did,=20
> which is have the edge of the network decide based on some deep packet =

> inspection or such what forwarding topology that any frame follows and =

> have the core of the network follow that decision without having every =

> hop along the way having to make that decision.
> - In case of multicast, the current approach seems focussed on only=20
> source Rbridge trees. But there are many scenarios in the case of the=20
> data center, where having a smaller number of shared trees and picking =

> one of these trees by hashing th group addr and such is sufficient and =

> more scalable. If we decide to support such a scheme, to avoid loops, i=
t=20
> is best to allow the ingress Rbridge to decide on the shared tree and=20
> stick that information in the frame. FTAG carries that kind of=20
> information. Is it possible to do all this using source Rbridge trees=20
> and building multiple trees per source Rbridge ? Yes, but it is less=20
> scalable, IMHO.

IMO, tags argue either for VLANs over the rbridge (one per class) -
which we had already agreed was possible (I thought) or argues for using
an IP heaader with a flow tag. At which point we're back to IP.

Let's please not reinvent IP here. As I said in other messages, if
support for future use is the concern, it's more important to define
reserved bits than to fix their allocation now.

Joe

--------------enigBC7C914195DFE2269FD8F43B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigBC7C914195DFE2269FD8F43B--

Date: Thu, 19 Oct 2006 10:07:43 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, [email-masked]
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1233

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC9FA2946284845252E88CEF0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Caitlin,
>=20
> ....
> =20
>> For the same reason Bernard Aboba cited on wireless. An set of
>> RBridges can distribute the new location information more
>> efficiently than existing bridges.=20
>=20
> When a VM move the first thing it does is an ARP, i.e. it sends a
> broadcast packet.
=2E..
> I doubt that in this aspect TRILL is more efficient that .1D, or am I
> missing something?

There's no rule to force an ARP upon move, but that would affect all 802
nets, including TRILL ones, equally badly.

Joe

--------------enigC9FA2946284845252E88CEF0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC9FA2946284845252E88CEF0--

Date: Thu, 19 Oct 2006 08:57:59 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1580

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7912E879BE7375F900A636F3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
=2E..
>> The reason I'm asking is because I see a big difference between asking=

>> RBridges to provide some new degree of filtering/security, and making
>> sure it isn't any worse than a bridged network.
>=20
> Understood, but a new standard is also a good place to improve.

The need for capabilities not in 802 now may be a good argument for
reserved bits

Note that in hardware they too are problematic; we'd need three types:

	- MUST set as 0 currently; MUST ignore on receipt
		for optional extensions
	- MUST set as 0 currently; MUST silently discard if not 0
		for silently dropped required extensions
	- MUST set as 0 currently; MUST report as error if not 0
		for non0-silent required extensions

I'd rather see the FTAG area blocked out for those kinds of bits at this
time than locked into a tag that a new VLAN header might replace, e.g.

Joe

--------------enig7912E879BE7375F900A636F3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7912E879BE7375F900A636F3--

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 08:22:06 -0700
From: "Silvano Gai" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 3372

Erik,

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 9:47 AM
> To: Silvano Gai
> Cc: Gray, Eric; Radia Perlman; Caitlin Bestler; [email-masked]
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> Silvano Gai wrote:
> > Eric,
> >
> > The fact that the network is under a single administrative domain
and
> > the fact that different part of the network have different
> > users/security are not in contradiction.
> >
> > Let's take a University, a single backbone interconnecting many
networks
> > (Departments, Labs, Administration, External) and many users (Profs,
> > Students, Admin). Firewall, Routers and 5-Tuple ACLs are probably
used
> > for security, but it is also important to guarantee that firewalls
and
> > routers are not bypassed. Therefore it is possible to think that a
> > network administrator may want to disallow the RBdridges connecting
the
> > Labs to talk directly with the Rbridges connecting the
administrations
> > and so on.
> 
> Silvano,
> 
> That sounds like a good argument for using VLANs.

It is, VLANs have been used extensively to solve this problem.
 
> 
> But I have a more fundamental question. Are people accomplishing what
> you are requesting of RBridges using 802.1D bridges today?
> If so, how are they doing it?

I used to work for a large switch company for many years and one of the
requests I got consistently from customers was: "tell me with certainty
where the frame entered the network". You cannot do that in IEEE 802.1D.
When the network is under attack this is a great feature to have. It
also allows building additional ACLs, as I explained in previous emails.

> 
> There is nothing in the 802.1D data plan which indicates the first
> bridge that forwarded a frame.

Agreed.

> 
> The reason I'm asking is because I see a big difference between asking
> RBridges to provide some new degree of filtering/security, and making
> sure it isn't any worse than a bridged network.
> 

Understood, but a new standard is also a good place to improve.
If you buy my argument that having 32 bits of TRILL shim is not hardware
friendly, while 48 is, and you want to limit to the minimum the TRILL
shim, then let's go with Dinesh proposal:

Ddutt> I'd like to reiterate that I share the concern of protocol
overhead Ddutt> with the others, but methinks the overhead of 16 bits
(16-bit ingress Ddutt> ID, 16-bit egress ID, 16-bit TTL/FTAG maybe
sufficient) is worth the
Ddutt>  bits.

i.e.

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      | FTag              | Hop Limit | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Ingress RBridge Address      |  Egress RBridge Address       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
It is simple, clean and HW friendly

-- Silvano

> 
> > In addition to ACLs, I have read that having the two RBridge
addresses
> > can be useful for:
> > - Policy based forwarding
> > - Network Troubleshooting
> > - Hardware based learning
> >
> > I think this WG should seriously consider inserting both addresses
in
> > the shim header
> 
> I think the WG is; that's why there are all these emails ;-)
> 
> Regards,
>     Erik

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 08:07:51 -0700
From: "Silvano Gai" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] LIDs
Status: RO
Content-Length: 1810

IMO we should avoid variable length matching in transit bridges. Fixed
length is easy to handle with a hash function.

-- Silvano 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Erik Nordmark
> Sent: Wednesday, October 18, 2006 11:06 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: [rbridge] LIDs
> 
> Radia Perlman wrote:
> 
> > We haven't discussed the LID fields. Perhaps that should be a
different
> > thread. Since that doesn't
> > affect forwarding, and is only a convenience to the egress RBridge,
that
> > doesn't seem too compelling.
> > The ingress RBridge has to do the lookup per endnode, so it's only
at
> > most twice as much computation
> > for a Designated RBridge to have to do the lookup both when a packet
> > leaves its link and when it enters.
> 
> If we are trying to squeeze bits and see a need for a LID capability,
it
> might make sense to allow different egress rbridges have different
> number of LID bits - they only need to number their ports so in some
> cases few bits would be sufficient.
> 
> Assuming we have a 19 bit space for RBridge alias plus LID, then an
> rbridge with 16 ports would ask for an alias that is 19-4=15 bits.
> 
> The downside of such an approach is that the alias setup would need to
> be able to handle variable length aliases, and the transit rbridges
> would either need variable length matching on the RBridge alias, or
> expand out to all the matching 19 bit patterns and have the hardware
do
> full 19 bit matches. For instance, the above 15 bit alias would expand
> to 16 different matches on 19 bits.
> 
>     Erik
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Thu, 19 Oct 2006 08:04:31 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Erik Nordmark" <[email-masked]>, "Ed Bowen" <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 799

Caitlin,

....
 
> 
> For the same reason Bernard Aboba cited on wireless. An set of
> RBridges can distribute the new location information more
> efficiently than existing bridges. 

When a VM move the first thing it does is an ARP, i.e. it sends a
broadcast packet.

In IEEE 802.1D this broadcast propagates on the VLAN and updates the
filtering databases (the new location is learnt).

In TRILL this broadcast propagate on the VLAN, but the new location is
not learnt inside the TRILL cloud, it is only learnt on the ingress
port. The learning in ingress causes the new location to be distributed
through ISIS. Each RBridge needs to compute a new forwarding table and
to download it to HW.

I doubt that in this aspect TRILL is more efficient that .1D, or am I
missing something?

-- Silvano

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 13:19:17 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] LIDs
Status: RO
Content-Length: 1858

Erik Nordmark wrote:
> Radia Perlman wrote:
> 
>> We haven't discussed the LID fields. Perhaps that should be a
>> different thread. Since that doesn't affect forwarding, and is only a
>> convenience to the egress RBridge, that doesn't seem too compelling.
>> The ingress RBridge has to do the lookup per endnode, so it's only at
>> most twice as much computation for a Designated RBridge to have to do
>> the lookup both when a packet leaves its link and when it enters.
> 
> If we are trying to squeeze bits and see a need for a LID
> capability, it might make sense to allow different egress
> rbridges have different number of LID bits - they only need
> to number their ports so in some cases few bits would be sufficient.
> 
> Assuming we have a 19 bit space for RBridge alias plus LID,
> then an rbridge with 16 ports would ask for an alias that is 19-4=15
> bits. 
> 
> The downside of such an approach is that the alias setup
> would need to be able to handle variable length aliases, and
> the transit rbridges would either need variable length
> matching on the RBridge alias, or expand out to all the
> matching 19 bit patterns and have the hardware do full 19 bit
> matches. For instance, the above 15 bit alias would expand to
> 16 different matches on 19 bits.
> 
>     Erik

Bitmask aliasing an RBridge ID has the same potential uses as
LID aliasing for InfiniBand, and the same complexities.

My generate comment on the LID is that it is only worth considering
if it can be multiplexed with the RBridge ID. Otherwise you are
replacing an egress RBridge table [local mac-->local port] by
having having more data in the ingress RBridge table
[remote mac-->remote rbridge + LID]. I'm not certain
that it really reduces the amount of memory, and given
the likely size of the [local mac-->local port] table
I don't think it improves latency.

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 11:24:33 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Erik Nordmark" <[email-masked]>, "Ed Bowen" <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2502

Silvano Gai wrote:
> Catlin,
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Caitlin Bestler Sent: Wednesday, October 18, 2006 10:41
>> AM 
>> To: Erik Nordmark; Ed Bowen
>> Cc: [email-masked]; [email-masked]; Radia Perlman;
>> Joe Touch Subject: Re: [rbridge] TTL only - was RE: New fields in
>> shim header? 
>> 
>> [email-masked] wrote:
>>> Ed Bowen wrote:
>>> 
>>>> What is the operational experience that indicates the requirement
>>>> for the other environments?  I am not aware of anyone who plans to
>>>> install TRILL outside of the environment Silvano outlines. What
>>>> need would motivate these additional environments?
>>> 
>>> Here is one data point, which isn't central to TRILL but illustrate
>>> the possibilities. 
>>> 
>>> Barnard Aboba made the observation a long time ago that using TRILL
>>> in wireless access points would solve certain existing issues.
>>> 
>>> By advertising the MAC address in the link-state routing protocol
>>> when the station has associated, then moving from one AP to another
>>> is less disruptive. Today one has to rely on the station
>>> transmitting packets via the new AP in order for the learning
>>> bridges to find update the learning tables.
>>> 
>> 
>> The same advantages will apply to live migration of virtual machines
>> within a subnet. Indeed, a believe virtualization may be a major
>> factor in the need for RBridges. VMs mean more MAC addresses per
>> physical host, and the desire to support live migration increases
>> the desire for larger subnets. 
>> 
> 
> I really don't understand this.
> Why does virtualization imply larger subnets?

a) more MAC addresses per physical host.
b) the desire to merge IP subnets to allow migration of VMs.
   You cannot maintain an existing TCP connection and move the host
   to a new subnet, the destination IP address will be wrong.

> Why is TRILL better with larger subnets?

If each bridge can easily track EVERY mac address in the subnet
then there would be little benefit to having an RBridge.

> How does TRILL support better virtualization than IEEE 802.1D?
> 

For the same reason Bernard Aboba cited on wireless. An set of
RBridges can distribute the new location information more
efficiently than existing bridges. Migrating a VM to a new
physial host isn't much fun if all the TCP connections
time out before the subnet learns to forward packets to
the correct new location.

Date: Wed, 18 Oct 2006 11:06:08 -0700
From: Erik Nordmark <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] LIDs
Status: RO
Content-Length: 1238

Radia Perlman wrote:

> We haven't discussed the LID fields. Perhaps that should be a different 
> thread. Since that doesn't
> affect forwarding, and is only a convenience to the egress RBridge, that 
> doesn't seem too compelling.
> The ingress RBridge has to do the lookup per endnode, so it's only at 
> most twice as much computation
> for a Designated RBridge to have to do the lookup both when a packet 
> leaves its link and when it enters.

If we are trying to squeeze bits and see a need for a LID capability, it 
might make sense to allow different egress rbridges have different 
number of LID bits - they only need to number their ports so in some 
cases few bits would be sufficient.

Assuming we have a 19 bit space for RBridge alias plus LID, then an 
rbridge with 16 ports would ask for an alias that is 19-4=15 bits.

The downside of such an approach is that the alias setup would need to 
be able to handle variable length aliases, and the transit rbridges 
would either need variable length matching on the RBridge alias, or 
expand out to all the matching 19 bit patterns and have the hardware do 
full 19 bit matches. For instance, the above 15 bit alias would expand 
to 16 different matches on 19 bits.

    Erik

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 11:18:12 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Erik Nordmark" <[email-masked]>, "Ed Bowen" <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1775

Catlin,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Caitlin Bestler
> Sent: Wednesday, October 18, 2006 10:41 AM
> To: Erik Nordmark; Ed Bowen
> Cc: [email-masked]; [email-masked]; Radia Perlman; Joe
> Touch
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> [email-masked] wrote:
> > Ed Bowen wrote:
> >
> >> What is the operational experience that indicates the requirement
for
> >> the other environments?  I am not aware of anyone who plans to
> >> install TRILL outside of the environment Silvano outlines. What
need
> >> would motivate these additional environments?
> >
> > Here is one data point, which isn't central to TRILL but
> > illustrate the possibilities.
> >
> > Barnard Aboba made the observation a long time ago that using
> > TRILL in wireless access points would solve certain existing issues.
> >
> > By advertising the MAC address in the link-state routing
> > protocol when the station has associated, then moving from
> > one AP to another is less disruptive. Today one has to rely
> > on the station transmitting packets via the new AP in order
> > for the learning bridges to find update the learning tables.
> >
> 
> The same advantages will apply to live migration of virtual machines
> within a subnet. Indeed, a believe virtualization may be a major
> factor in the need for RBridges. VMs mean more MAC addresses per
> physical host, and the desire to support live migration increases
> the desire for larger subnets.
> 

I really don't understand this. 
Why does virtualization imply larger subnets? 
Why is TRILL better with larger subnets?
How does TRILL support better virtualization than IEEE 802.1D?

-- Silvano

Date: Wed, 18 Oct 2006 11:14:15 -0700
From: Dinesh G Dutt <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1548

Caitlin Bestler wrote:
> [email-masked] wrote:
>
>   
>> Ingress Rbridge is essential for multiple purposes especially
>> for troubleshooting and for sending error messages or reports
>> from the middle of the Rbridge core to the ingress Rbridge.
>> Consider for example, the backward congestion notification
>> scheme that is being pursued in IEEE (802.1au). If I want to
>> deploy that work in Rbridges, I need the ability to signal
>> congestion from the middle of the network back to the ingress
>> Rbridge or source end station. If I do not have the ingress
>> Rbridge in the frame, the only way to derive that address is
>> by populating all the edge MAC addresses in the core of the
>> network; this defeats one of the key objectives of an Rbridge, IMHO.
>>
>>     
>
> Are you trying to optimize the sending of the BCN to the source
> MAC address so that the encapsulating RBridge is known without
> having to having stored that information in an intermediate or
> core RBridge?
>   
Yes.
> There is ultimately a need for core RBridges to be able to 
> map source MAC address to source RBridge in order to forward
> a BCN received from an 802.1au bridge that knows nothing 
> about RBridges. So this optimization would be about reducing
> table size and improving latency of BCN relay, rather than 
> about eliminating logic.
>   
Agree, but I don't want the advantages to seem trivial.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 11:04:00 -0700
From: "Silvano Gai" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Ed Bowen" <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2132

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Erik Nordmark
> Sent: Wednesday, October 18, 2006 10:22 AM
> To: Ed Bowen
> Cc: [email-masked]; [email-masked]; Radia Perlman; Joe
> Touch
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> Ed Bowen wrote:
> 
> > What is the operational experience that indicates the requirement
for
> the
> > other environments?  I am not aware of anyone who plans to install
TRILL
> > outside of the environment Silvano outlines. What need would
motivate
> these
> > additional environments?
> 
> Here is one data point, which isn't central to TRILL but illustrate
the
> possibilities.
> 
> Barnard Aboba made the observation a long time ago that using TRILL in
> wireless access points would solve certain existing issues.
> 
> By advertising the MAC address in the link-state routing protocol when
> the station has associated, then moving from one AP to another is less
> disruptive. Today one has to rely on the station transmitting packets
> via the new AP in order for the learning bridges to find update the
> learning tables.
> 

But if the station does not send packet, how are you going to learn that
it is there and therefore propagate its existence in ISIS?

If the AP learns by other way that the station is there, it just needs
to send a dummy broadcast packet with the SA of the station to have the
learning happen. This is what is done in commercial products, for
example, when the root port dies to quickly switch to the alternate
port.

IMHO the true value of TRILL is the capability to effectively
implementing fat tree networks, which is particularly crucial in this
moment, since the speed of the access links and the speed of the
backbone links are becoming the same, i.e. 10 GE. If 100GE was available
today for the backbone, TRILL will be still important, but less
compelling. That is also the reason we need to be very careful to be HW
friendly, since TRILL will be important where ASIC design is really at
the edge of what the technology can do.

-- Silvano

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 10:41:27 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Ed Bowen" <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1159

[email-masked] wrote:
> Ed Bowen wrote:
> 
>> What is the operational experience that indicates the requirement for
>> the other environments?  I am not aware of anyone who plans to
>> install TRILL outside of the environment Silvano outlines. What need
>> would motivate these additional environments?
> 
> Here is one data point, which isn't central to TRILL but
> illustrate the possibilities.
> 
> Barnard Aboba made the observation a long time ago that using
> TRILL in wireless access points would solve certain existing issues.
> 
> By advertising the MAC address in the link-state routing
> protocol when the station has associated, then moving from
> one AP to another is less disruptive. Today one has to rely
> on the station transmitting packets via the new AP in order
> for the learning bridges to find update the learning tables.
> 

The same advantages will apply to live migration of virtual machines
within a subnet. Indeed, a believe virtualization may be a major
factor in the need for RBridges. VMs mean more MAC addresses per
physical host, and the desire to support live migration increases
the desire for larger subnets.

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 10:38:39 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 1261

[email-masked] wrote:

> 
> Ingress Rbridge is essential for multiple purposes especially
> for troubleshooting and for sending error messages or reports
> from the middle of the Rbridge core to the ingress Rbridge.
> Consider for example, the backward congestion notification
> scheme that is being pursued in IEEE (802.1au). If I want to
> deploy that work in Rbridges, I need the ability to signal
> congestion from the middle of the network back to the ingress
> Rbridge or source end station. If I do not have the ingress
> Rbridge in the frame, the only way to derive that address is
> by populating all the edge MAC addresses in the core of the
> network; this defeats one of the key objectives of an Rbridge, IMHO.
>

Are you trying to optimize the sending of the BCN to the source
MAC address so that the encapsulating RBridge is known without
having to having stored that information in an intermediate or
core RBridge?

There is ultimately a need for core RBridges to be able to 
map source MAC address to source RBridge in order to forward
a BCN received from an 802.1au bridge that knows nothing 
about RBridges. So this optimization would be about reducing
table size and improving latency of BCN relay, rather than 
about eliminating logic.

Date: Wed, 18 Oct 2006 10:22:10 -0700
From: Erik Nordmark <[email-masked]>
To: Ed Bowen <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 807

Ed Bowen wrote:

> What is the operational experience that indicates the requirement for the
> other environments?  I am not aware of anyone who plans to install TRILL
> outside of the environment Silvano outlines. What need would motivate these
> additional environments?

Here is one data point, which isn't central to TRILL but illustrate the 
possibilities.

Barnard Aboba made the observation a long time ago that using TRILL in 
wireless access points would solve certain existing issues.

By advertising the MAC address in the link-state routing protocol when 
the station has associated, then moving from one AP to another is less 
disruptive. Today one has to rely on the station transmitting packets 
via the new AP in order for the learning bridges to find update the 
learning tables.

    Erik

Date: Wed, 18 Oct 2006 10:17:27 -0700
From: Dinesh G Dutt <[email-masked]>
To: [email-masked]
Subject: [rbridge] Ingress Rbridge and FTAG again
Status: RO
Content-Length: 3736

I apologize for not responding to Joe's email earlier. I'd like to take 
another a more verbose crack (compared to my previous rather terse 
email) at stating why we need both ingress rbridge ID and FTAG.

Ingress Rbridge is essential for multiple purposes especially for 
troubleshooting and for sending error messages or reports from the 
middle of the Rbridge core to the ingress Rbridge. Consider for example, 
the backward congestion notification scheme that is being pursued in 
IEEE (802.1au). If I want to deploy that work in Rbridges, I need the 
ability to signal congestion from the middle of the network back to the 
ingress Rbridge or source end station. If I do not have the ingress 
Rbridge in the frame, the only way to derive that address is by 
populating all the edge MAC addresses in the core of the network; this 
defeats one of the key objectives of an Rbridge, IMHO.

Over and over again, I've heard customers tell me that debugging the 
network is a critical feature that they want built into the products. 
With the help of TTL and ingress Rbridge ID, we can deliver a layer 2 
traceroute through the Rbridge network. This seems a critical feature to 
me.

While I'll agree that having an ingress Rbridge isn't essential for 
security as Silvano stated it, I also think it is not an incorrect case. 
With an ingress Rbridge field in the frame, I can support customers who 
envisage Silvano's way of doing things.

I'm unaware of any protocol, tunnelling or otherwise, that does not 
carry both an ingress and egress endpoint address in the header. Before 
you can utter that four letter word at me, remember that MPLS changes 
labels hop-by-hop; so having an ingress and egress in MPLS is not very 
useful. I can visualize other optimizations and features that can be 
deployed if I have both ingress and egress addresses in a frame.

On the question of FTAG, I see three main usage cases.
- The approach currently being pursued in TRILL does not seem different 
to me from the approach taken by 802.1D when they mandated a single 
spanning tree for all VLANs. While TRILL doesn't suffer from the problem 
of a single spanning tree, I can see various reasons why customers may 
prefer to keep a small number of separate forwarding topologies, not 
unlike a multiple spanning tree approach.
- With the advent of I/O consolidation, people will want to traffic 
engineer their campus networks. FTAG allows you to do what MPLS did, 
which is have the edge of the network decide based on some deep packet 
inspection or such what forwarding topology that any frame follows and 
have the core of the network follow that decision without having every 
hop along the way having to make that decision.
- In case of multicast, the current approach seems focussed on only 
source Rbridge trees. But there are many scenarios in the case of the 
data center, where having a smaller number of shared trees and picking 
one of these trees by hashing th group addr and such is sufficient and 
more scalable. If we decide to support such a scheme, to avoid loops, it 
is best to allow the ingress Rbridge to decide on the shared tree and 
stick that information in the frame. FTAG carries that kind of 
information. Is it possible to do all this using source Rbridge trees 
and building multiple trees per source Rbridge ? Yes, but it is less 
scalable, IMHO.

I'd like to reiterate that I share the concern of protocol overhead with 
the others, but methinks the overhead of 16 bits (16-bit ingress ID, 
16-bit egress ID, 16-bit TTL/FTAG maybe sufficient) is worth the bits.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Date: Wed, 18 Oct 2006 09:59:02 -0700
From: Erik Nordmark <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1600

Dinesh G Dutt wrote:
> I can see a few other possibilitites for the use of a source Rbridge field.
> - Consider for example, we want to return an error or send a 
> notification to the ingress Rbridge from the middle of the network, 
> analogous to an ICMP message. With the source RBridge, you know who to 
> send it to.
> - It allows hardware-based learning
> - It assists in network trouble-shooting

Dinesh,

I'd be interested in understanding the error reporting and 
trouble-shooting aspects a bit more.

Link state routing protocols have been used for IP traffic for a long 
time, and the operational tools used to not include the ability to tell 
the ingress (first) IS-IS/OSPF router something. The error reporting is 
just ICMP errors that are sent back to the IP source of the packet, plus 
MIBs and the like which allows network managers to observe the routers.

We could choose to just rely on the same approach for RBridges, in which 
case an ingress rbridge address isn't required.

Or we could try to come up with different way to trouble-shoot RBridged 
networks, but I certainly don't feel I understand what such a solution 
would look like. Would it mean we (or IEEE 802) would need to define L2 
error messages that can be sent back similar in spirit to ICMP? Would we 
need to invent a L2 or RBridge "traceroute" application?

Given that both IP networks using link-state routing protocols, and IEEE 
802.1D networks get away without reporting errors to the ingress, I 
think we need to understand this space quite a bit more before embarking 
down that path.

Regards,
    Erik

Date: Wed, 18 Oct 2006 09:46:41 -0700
From: Erik Nordmark <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1598

Silvano Gai wrote:
> Eric,
> 
> The fact that the network is under a single administrative domain and
> the fact that different part of the network have different
> users/security are not in contradiction.
> 
> Let's take a University, a single backbone interconnecting many networks
> (Departments, Labs, Administration, External) and many users (Profs,
> Students, Admin). Firewall, Routers and 5-Tuple ACLs are probably used
> for security, but it is also important to guarantee that firewalls and
> routers are not bypassed. Therefore it is possible to think that a
> network administrator may want to disallow the RBdridges connecting the
> Labs to talk directly with the Rbridges connecting the administrations
> and so on.

Silvano,

That sounds like a good argument for using VLANs.

But I have a more fundamental question. Are people accomplishing what 
you are requesting of RBridges using 802.1D bridges today?
If so, how are they doing it?

There is nothing in the 802.1D data plan which indicates the first 
bridge that forwarded a frame.

The reason I'm asking is because I see a big difference between asking 
RBridges to provide some new degree of filtering/security, and making 
sure it isn't any worse than a bridged network.

> In addition to ACLs, I have read that having the two RBridge addresses
> can be useful for:
> - Policy based forwarding
> - Network Troubleshooting
> - Hardware based learning
> 
> I think this WG should seriously consider inserting both addresses in
> the shim header

I think the WG is; that's why there are all these emails ;-)

Regards,
    Erik

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 12:10:26 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] draft-ietf-trill-prob-00.txt
Status: RO
Content-Length: 1202

OK, I amend my comments to just recommend removal of the parenthetical
examples.

Donald

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: Tuesday, August 29, 2006 12:19 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] draft-ietf-trill-prob-00.txt

> Page 2 in abstract at the top: I don't actually think of typical 
> distance vector routing as much, if any, better that spanning tree, 
> both being substantially inferior to link state protocols.  I would 
> suggest, in the 3rd & 4th line, changing "apply network layer routing 
> (e.g., link state or distance vector)" to "apply modern network layer 
> routing (e.g., link state)".

Except there are modern distance vector protocols.... BGP falls loosely
within the designation of "distance vector," for instance. I think we
could just kill the "e.g." in the parenthesis altogether.

:-)

Russ

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 12:10:17 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] draft-ietf-trill-prob-00.txt comment
Status: RO
Content-Length: 1342

Here is one additional comment from me as a working group member on
draft-ietf-trill-prob-00.txt:

Abstract and Section 1:
	The abstract mentions in order, as problem of bridges, the need
to avoid loops, inability to use alternative paths, and convergence
time. Section 1 mentions in order conversion time and the concentration
of traffic on a spanning tree and resulting bandwidth limitation.
	I have no problem with mentioning all of these but it seems to
me that, in practice, bandwidth/efficiency and, to a lesser extent,
latency due to suboptimal paths are the problems that people are worried
about. Loop safety is important and there have and can be loops but as a
practical matter, they seem to be extremely rare. As for convergence,
I've heard it claimed that RSTP can converge in three times the speed of
light delay across the diameter of the network. Regardless of that
claim, is there really a strong case that link-state convergence will
necessarily be faster?
	While they are certainly of importance, why are we putting
convergence and loop robustness first in these introductory sections
when, as a practical matter, the most notable improvement with TRILL
seems like it will be more efficient use of physical links? Admittedly,
when we get into the body of the draft, "2.1 Inefficient Paths" does
come first....

Donald

Content-class: urn:content-classes:message
Date: Wed, 18 Oct 2006 09:04:01 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 8675

Eric,

Let me depict you what happens when you insert one MPLS label, ore a 1Q
option or a 1S option

Original:
+--------------------------------+
|               DA               |
+----------------+---------------+
|       DA       |     SA        |
+----------------+---------------+
|               SA               |
+--------------------------------+
|    Ethertype   |   Payload     |
+--------------------------------+
|                                |
|         ...........            |

Original + Opt (where Opt can be MPLS, 1Q or 1S)
+--------------------------------+
|               DA               |
+----------------+---------------+
|       DA       |     SA        |
+----------------+---------------+
|               SA               |
+--------------------------------+
|    Ethertype   |      Opt      |
+--------------------------------+
|      opt       |   Payload     |
+--------------------------------+
|                                |
|         ...........            |

The HW that perform the insertion/removal does not need to realign the
payload that is in its buffer.

Now Let's consider the encapsulation/decapsulation function by looking
at the Original frame + TRILL header (as proposed by the current draft)
+--------------------------------+
|         Outer DA               |
+----------------+---------------+
|    Outer DA    |  Outer SA     |
+----------------+---------------+
|         Outer SA               |
+--------------------------------+
|Ethertype=TRILL |   Trill Shim  |
+--------------------------------+
|  Trill Shim    |  ????????     |
+--------------------------------+
|               DA               |
+----------------+---------------+
|       DA       |     SA        |
+----------------+---------------+
|               SA               |
+--------------------------------+
|    Ethertype   |   Payload     |
+--------------------------------+
|                                |
|         ...........            |

If you don't have the 16 bits indicated by ???????, the hardware will
need to realign the inner frame. The frame is not on the wire. The frame
sits in the packet buffer and the memory bandwidth of the packet buffer
is today the MOST important consideration in port ASIC design.

More inline

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 4:57 AM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: RE: [rbridge] FTag
> 
> Silvano,
> 
> Let me answer your points in order, leaving out irrelevant issues:
> 
> <Your Point> N*32 is correct, when including Ethernet options/shims
>              (e.g. .1Q or .1S).  This is hardware friendly, because
> 		 alignment doesn't change going from one header to
another.
> 
> There are a few different "Ethernet" encapsulations, once we start to
> include Ethernet options and the shims associated with those options.
> 
> First, and I believe most important, the "shim" we are talking about
> (in TRILL) is not an Ethernet option (or associated shim).  It's a
> "shim" as a separate "layer."  Otherwise, it would be inappropriate
> for us to do this work here (in TRILL, as part of the IETF).

>From the above picture it should be clear that you should consider the
TRILL header as a whole, and the TRILL header as only one form of
Ethernet encapsulation.

> 
> Second, "Ethernet" headers do not all align the same.
> 

Agreed, but that is not my concern, My concern is to not change their
alignment due to the insertion/removal of the TRILL header.

> Currently, we are talking about having a single Ethertype defined to
> distinguish inter-RBridge traffic from other types of Ethernet frames.
> If your implementation produces 32-bit aligned Ethernet frames, using
> 802.1Q, then it will similarly produce 32-bit aligned frames - prior
> to considering the TRILL shim - using the new Ethertype.
> 
> We are not proposing a change in any Ethernet frame/header format.

Neither do I.

> 
> The reference to 802.1Q is slightly disingenuous, because 802.1Q
> effectively displaces the existing Ethertype by 32 bits.  802.1Q
> "shims" include the Ethertype, because they replace the original
> one with 0x8100 and have to include the original in the "shim."
> 
> I assume that a similar observation could be made about 802.1S.

Yes and a similar observation can be made for MPLS, but all these three
do not change the alignment of the fields that follow.

> 
> In TRILL, we are not replacing the original Ethertype, we are adding
> a new encapsulation.  The original Ethertype stays in the original
> - re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
> no reason to consider the Ethertype to be part of the TRILL shim.

As I told before you need to consider the whole TRILL header, i.e.
6 bytes of DA
6 bytes of SA
2 bytes of Ethertype
4 bytes of shim
----------------------
18 bytes

Which is 2 bytes short of N*32, i.e. it is not HW friendly.

For this reason I propose that Ethertype + shim should be N*32 to be HW
friendly.

> 
> <Your Point> TRILL should adopt this model for its shim header - the
>              Ethertype should be included as part of computing "shim"
>              size.
> 
> In TRILL, we are not replacing the original Ethertype, we are adding
> a new encapsulation.  The original Ethertype stays in the original
> - re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
> no reason to consider the Ethertype to be part of the TRILL shim.
> 
> <Your Point> TRILL should optimize the Ethernet case that will cover
99%
>              of TRILL applications.
> 
> Coverage is slightly more complete than that.  Considering all of the
> layer 2 encapsulations that currently come under an Ethernet umbrella,
> TRILL applications are 100% included.
> 
> I think we are essentially in agreement on this point.
> 
> <Your Point> TRILL bridges will be implemented mainly in hardware and
>              the encapsulation and decapsulation functions need to be
>              HW friendly.
> 
> Okay.  I was not making any other point - except to say that alignment
> is usually a software concern, especially in initial design.
> 
> Let me be blunt, alignment does not factor into initial hardware
design,
> but is an issue with hardware re-use complexity.  Bits on a wire are
not
> "aligned" - you simply collect them as they arrive, serially.

I agree that bits on the wire are not aligned, but you need to buffer
the incoming frame (or at least part of it) until you have enough fields
to perform your lookup and decide what to do with the frame. From that
point on the frame is not on the wire, it is in the packet buffer and
alignment is crucial at the performance we are talking about.

I hope this time I made my point more clear

-- Silvano

> 
> And, in any case, the "alignment issue" is moot, unless you assume
that
> we need to add an _additional_ Ethertype and I am not including that
in
> my size computation.
> 
> We do not need the additional Ethertype, consequently, we do not have
to
> account for it.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[email-masked]]
> --> Sent: Wednesday, October 18, 2006 12:05 AM
> --> To: Gray, Eric; Caitlin Bestler
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> --> Eric,
> -->
> --> I beg to differ.
> -->
> --> N*32 is correct, if you include the 16 bits of Ethertype.
> -->
> --> With all the respect for wikipedia, I prefer a reference to IEEE
> 802.1Q
> --> and IEEE 802.1D in which the Ethertype is considered part of the
> options/shims.
> -->
> --> This is what happens for options like .1Q or .1S (16 bit of
Ethertype
> +
> --> 16 bits of options).
> -->
> --> This is hardware friendly, since inserting or removing the shim
does
> not
> --> change the 32 bit alignment of what follows.
> -->
> --> IMHO TRILL should adopt a shim header that is N*32 including the
> --> Ethertype = TRILL or 16 + M*32 excluding the Ethertype.
> -->
> --> I don't buy that, to be layer 2 independent, we need to not
optimize
> the
> --> Ethernet case that will cover 99% of TRILL applications.
> -->
> --> I also don't buy any software implementation arguments: TRILL
bridges
> --> will be implemented mainly in hardware and the encapsulation and
> --> decapsulation functions need to be HW friendly.
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[email-masked]]
> --> > Sent: Tuesday, October 17, 2006 9:48 AM
> --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
> --> > Cc: [email-masked]
> --> > Subject: RE: [rbridge] FTag
> ---[SNIP]---

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Wed, 18 Oct 2006 07:57:22 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 4813

Silvano,

Let me answer your points in order, leaving out irrelevant issues:

<Your Point> N*32 is correct, when including Ethernet options/shims 
             (e.g. .1Q or .1S).  This is hardware friendly, because
		 alignment doesn't change going from one header to another.

There are a few different "Ethernet" encapsulations, once we start to
include Ethernet options and the shims associated with those options.

First, and I believe most important, the "shim" we are talking about
(in TRILL) is not an Ethernet option (or associated shim).  It's a 
"shim" as a separate "layer."  Otherwise, it would be inappropriate 
for us to do this work here (in TRILL, as part of the IETF).

Second, "Ethernet" headers do not all align the same.  

Currently, we are talking about having a single Ethertype defined to
distinguish inter-RBridge traffic from other types of Ethernet frames.
If your implementation produces 32-bit aligned Ethernet frames, using
802.1Q, then it will similarly produce 32-bit aligned frames - prior
to considering the TRILL shim - using the new Ethertype.  

We are not proposing a change in any Ethernet frame/header format.

The reference to 802.1Q is slightly disingenuous, because 802.1Q
effectively displaces the existing Ethertype by 32 bits.  802.1Q
"shims" include the Ethertype, because they replace the original
one with 0x8100 and have to include the original in the "shim."

I assume that a similar observation could be made about 802.1S.

In TRILL, we are not replacing the original Ethertype, we are adding
a new encapsulation.  The original Ethertype stays in the original
- re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
no reason to consider the Ethertype to be part of the TRILL shim.

<Your Point> TRILL should adopt this model for its shim header - the
             Ethertype should be included as part of computing "shim"
             size.

In TRILL, we are not replacing the original Ethertype, we are adding
a new encapsulation.  The original Ethertype stays in the original
- re-encapsulated, or tunneled - Ethernet frame.  Therefore, there's
no reason to consider the Ethertype to be part of the TRILL shim.

<Your Point> TRILL should optimize the Ethernet case that will cover 99% 
             of TRILL applications.

Coverage is slightly more complete than that.  Considering all of the
layer 2 encapsulations that currently come under an Ethernet umbrella,
TRILL applications are 100% included.

I think we are essentially in agreement on this point.

<Your Point> TRILL bridges will be implemented mainly in hardware and 
             the encapsulation and decapsulation functions need to be 
             HW friendly.

Okay.  I was not making any other point - except to say that alignment
is usually a software concern, especially in initial design.  

Let me be blunt, alignment does not factor into initial hardware design,
but is an issue with hardware re-use complexity.  Bits on a wire are not
"aligned" - you simply collect them as they arrive, serially.

And, in any case, the "alignment issue" is moot, unless you assume that
we need to add an _additional_ Ethertype and I am not including that in
my size computation.

We do not need the additional Ethertype, consequently, we do not have to
account for it.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Wednesday, October 18, 2006 12:05 AM
--> To: Gray, Eric; Caitlin Bestler
--> Cc: [email-masked]
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> Eric,
--> 
--> I beg to differ.
--> 
--> N*32 is correct, if you include the 16 bits of Ethertype.
--> 
--> With all the respect for wikipedia, I prefer a reference to IEEE 802.1Q
--> and IEEE 802.1D in which the Ethertype is considered part of the
options/shims.
--> 
--> This is what happens for options like .1Q or .1S (16 bit of Ethertype +
--> 16 bits of options).
--> 
--> This is hardware friendly, since inserting or removing the shim does not
--> change the 32 bit alignment of what follows.
--> 
--> IMHO TRILL should adopt a shim header that is N*32 including the
--> Ethertype = TRILL or 16 + M*32 excluding the Ethertype.
--> 
--> I don't buy that, to be layer 2 independent, we need to not optimize the
--> Ethernet case that will cover 99% of TRILL applications.
--> 
--> I also don't buy any software implementation arguments: TRILL bridges
--> will be implemented mainly in hardware and the encapsulation and
--> decapsulation functions need to be HW friendly.
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Tuesday, October 17, 2006 9:48 AM
--> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
--> > Cc: [email-masked]
--> > Subject: RE: [rbridge] FTag
---[SNIP]---

Content-class: urn:content-classes:message
Date: Tue, 17 Oct 2006 21:05:19 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 7949

Eric,

I beg to differ.

N*32 is correct, if you include the 16 bits of Ethertype.

With all the respect for wikipedia, I prefer a reference to IEEE 802.1Q
and IEEE 802.1D in which the Ethertype is considered part of the
options/shims.

This is what happens for options like .1Q or .1S (16 bit of Ethertype +
16 bits of options).

This is hardware friendly, since inserting or removing the shim does not
change the 32 bit alignment of what follows.

IMHO TRILL should adopt a shim header that is N*32 including the
Ethertype = TRILL or 16 + M*32 excluding the Ethertype.

I don't buy that, to be layer 2 independent, we need to not optimize the
Ethernet case that will cover 99% of TRILL applications.

I also don't buy any software implementation arguments: TRILL bridges
will be implemented mainly in hardware and the encapsulation and
decapsulation functions need to be HW friendly.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2006 9:48 AM
> To: Silvano Gai; Gray, Eric; Caitlin Bestler
> Cc: [email-masked]
> Subject: RE: [rbridge] FTag
> 
> Silvano,
> 
> 	Ethertype is a field in the 802.3 header (see, for example, the
> figure at:
>
http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_Ether
Ty
> pe
> _field).
> 
> 	Assume that - when examining the SHIM header - the Ethernet
header
> has been
> removed, retaining only the relevant "context" information required by
a
> specific
> implementation.  Part of the "context" would be related to MAC DA (is
it
> mine?),
> and Ethertype.  Related to (perhaps as a litteral, perhaps as a
mapping),
> not the
> same as.
> 
> 	For purposes of examining the SHIM, it is convenient to assume
that
> it is
> aligned as presented.  How it is actually aligned will be
implementation
> specific.
> 
> 	Where alignment matters most is in software used to prepare data
for
> sending
> or decode data on receipt.  In some cases, alignment can be important
in
> reducing
> the complexity of hardware re-use.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[email-masked]]
> --> Sent: Tuesday, October 17, 2006 12:34 PM
> --> To: Gray, Eric; Caitlin Bestler
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> --> Eric,
> -->
> --> Do you include in your computation the 16 bits of Ethertype =
TRILL?
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[email-masked]]
> --> > Sent: Monday, October 16, 2006 4:06 PM
> --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
> --> > Cc: [email-masked]
> --> > Subject: RE: [rbridge] FTag
> --> >
> --> > Silvano,
> --> >
> --> > 	The "encapsulated frame" alignment varies from layer to
> --> > layer and is independent from layer to layer.  When the bits
> --> > hit the wire (or glass), the alignment is not of a particular
> --> > importance.  It is the process of "hand-off" between stack
> --> > layers that might be relevant, depending on implementation.
> --> >
> --> > 	It is problematic - at best - to attempt to include the
> --> > next layer in the protocol stack in computing alignment, thus
> --> > it is not a good idea to take into account bit-wise alignment
> --> > of the MAC header when determining the "proper" alignment of
> --> > the SHIM, or the "proper" alignment of the next MAC header.
> --> >
> --> > 	Hence, if we want to have a 32-bit aligment of the SHIM
> --> > header, the options are N*32 bits.
> --> >
> --> > --
> --> > Eric
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Silvano Gai [mailto:[email-masked]]
> --> > --> Sent: Monday, October 16, 2006 6:21 PM
> --> > --> To: Gray, Eric; Caitlin Bestler
> --> > --> Cc: [email-masked]
> --> > --> Subject: RE: [rbridge] FTag
> --> > -->
> --> > -->
> --> > --> IMHO, since the encapsulated frame should be 32 bit
> --> > --> aligned, the size of
> --> > --> this option can be 16+n*32, without counting the Ethertype.
> --> > --> I proposed
> --> > --> n=2, i.e. 80 bits, the only other pragmatic alternative is
> --> > --> n=1, i.e. 48
> --> > --> bits.
> --> > -->
> --> > --> -- Silvano
> --> > -->
> --> > --> > -----Original Message-----
> --> > --> > From: Gray, Eric [mailto:[email-masked]]
> --> > --> > Sent: Monday, October 16, 2006 9:29 AM
> --> > --> > To: Gray, Eric; 'Caitlin Bestler'
> --> > --> > Cc: [email-masked]'; Silvano Gai
> --> > --> > Subject: RE: [rbridge] FTag
> --> > --> >
> --> > --> > Oops - "they come in handy 32-bit packages" is the quote
> --> > --> I meant to
> --> > --> > include...
> --> > --> >
> --> > --> > --> -----Original Message-----
> --> > --> > --> From: Gray, Eric
> --> > --> > --> Sent: Monday, October 16, 2006 12:27 PM
> --> > --> > --> To: Caitlin Bestler
> --> > --> > --> Cc: [email-masked]; Silvano Gai
> --> > --> > --> Subject: RE: [rbridge] FTag
> --> > --> > -->
> --> > --> > --> Actually, it is the fact that "they in handy 32-bit
> --> > --> packages" that
> --> > --> > --> should mandate the level of need required to justify
> --> > --> an extra bit.
> --> > --> > -->
> --> > --> > --> If inclusion of an extra bit means including 31
> --> > --> additional bits,
> --> > --> it
> --> > --> > --> should be just a little bit harder to justify the
extra
> --> bit...
> --> > --> > -->
> --> > --> > --> --
> --> > --> > --> Eric
> --> > --> > -->
> --> > --> > --> --> -----Original Message-----
> --> > --> > --> --> From: [email-masked]
> --> > --> > --> --> [mailto:[email-masked]] On
> --> Behalf Of Caitlin
> --> > --> Bestler
> --> > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM
> --> > --> > --> --> To: Silvano Gai; [email-masked]
> --> > --> > --> --> Subject: Re: [rbridge] FTag
> --> > --> > --> -->
> --> > --> > --> --> [email-masked] wrote:
> --> > --> > --> --> > Another important field proposed in:
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > -->
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
> --> > --> > --> --> > cap-00.txt
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> > Is the Ftag (see section 3).
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> > Is there any opposition to add this field?
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> >
> --> > --> > --> --> > -- Silvano
> --> > --> > --> -->
> --> > --> > --> --> Despite the description, this is ultimately a
> --> > --> Class of Service
> --> > --> > --> --> field. Class of Service fields are always useful,
> --> > --> the question
> --> > --> > --> --> is whether they are useful enough. Each extra bit
is
> --> > --> > --> less useful,
> --> > --> > --> --> and potentially costs a lot more.
> --> > --> > --> -->
> --> > --> > --> --> To justify increasing the shim header size I
> --> > --> think a scenario
> --> > --> > --> --> that would specifically require the extra
> --> classes would
> --> be
> --> > --> > --> --> useful -- or at least one that exhausts
> --> those available
> --> > --> without
> --> > --> > --> --> the extra field.
> --> > --> > --> -->
> --> > --> > --> --> Philosophically, I take the attitude that
> --> the bandwidth
> --> > --> belongs
> --> > --> > --> --> to the customer. I want a justification for each
> --> > --> and every bit
> --> > --> > --> --> I take out of it (although realistically I know
> --> > --> that they come
> --> > --> > --> --> in handy 32-bit packages).
> --> > --> > --> -->
> --> > --> > --> -->
> --> > --> > --> -->
> --> > --> > --> --> _______________________________________________
> --> > --> > --> --> rbridge mailing list
> --> > --> > --> --> [email-masked]
> --> > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > --> > --> -->
> --> > --> > -->
> --> > -->
> -->

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, "Gray, Eric" <[email-masked]>, Caitlin Bestler <[email-masked]>
Date: Tue, 17 Oct 2006 12:48:12 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 6460

Silvano,

	Ethertype is a field in the 802.3 header (see, for example, the
figure at:
http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_EtherType
_field).

	Assume that - when examining the SHIM header - the Ethernet header
has been
removed, retaining only the relevant "context" information required by a
specific
implementation.  Part of the "context" would be related to MAC DA (is it
mine?),
and Ethertype.  Related to (perhaps as a litteral, perhaps as a mapping),
not the
same as.

	For purposes of examining the SHIM, it is convenient to assume that
it is 
aligned as presented.  How it is actually aligned will be implementation
specific.

	Where alignment matters most is in software used to prepare data for
sending
or decode data on receipt.  In some cases, alignment can be important in
reducing
the complexity of hardware re-use.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Tuesday, October 17, 2006 12:34 PM
--> To: Gray, Eric; Caitlin Bestler
--> Cc: [email-masked]
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> Eric,
--> 
--> Do you include in your computation the 16 bits of Ethertype = TRILL?
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Monday, October 16, 2006 4:06 PM
--> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
--> > Cc: [email-masked]
--> > Subject: RE: [rbridge] FTag
--> > 
--> > Silvano,
--> > 
--> > 	The "encapsulated frame" alignment varies from layer to
--> > layer and is independent from layer to layer.  When the bits
--> > hit the wire (or glass), the alignment is not of a particular
--> > importance.  It is the process of "hand-off" between stack
--> > layers that might be relevant, depending on implementation.
--> > 
--> > 	It is problematic - at best - to attempt to include the
--> > next layer in the protocol stack in computing alignment, thus
--> > it is not a good idea to take into account bit-wise alignment
--> > of the MAC header when determining the "proper" alignment of
--> > the SHIM, or the "proper" alignment of the next MAC header.
--> > 
--> > 	Hence, if we want to have a 32-bit aligment of the SHIM
--> > header, the options are N*32 bits.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:[email-masked]]
--> > --> Sent: Monday, October 16, 2006 6:21 PM
--> > --> To: Gray, Eric; Caitlin Bestler
--> > --> Cc: [email-masked]
--> > --> Subject: RE: [rbridge] FTag
--> > -->
--> > -->
--> > --> IMHO, since the encapsulated frame should be 32 bit
--> > --> aligned, the size of
--> > --> this option can be 16+n*32, without counting the Ethertype.
--> > --> I proposed
--> > --> n=2, i.e. 80 bits, the only other pragmatic alternative is
--> > --> n=1, i.e. 48
--> > --> bits.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:[email-masked]]
--> > --> > Sent: Monday, October 16, 2006 9:29 AM
--> > --> > To: Gray, Eric; 'Caitlin Bestler'
--> > --> > Cc: [email-masked]'; Silvano Gai
--> > --> > Subject: RE: [rbridge] FTag
--> > --> >
--> > --> > Oops - "they come in handy 32-bit packages" is the quote
--> > --> I meant to
--> > --> > include...
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: Gray, Eric
--> > --> > --> Sent: Monday, October 16, 2006 12:27 PM
--> > --> > --> To: Caitlin Bestler
--> > --> > --> Cc: [email-masked]; Silvano Gai
--> > --> > --> Subject: RE: [rbridge] FTag
--> > --> > -->
--> > --> > --> Actually, it is the fact that "they in handy 32-bit
--> > --> packages" that
--> > --> > --> should mandate the level of need required to justify
--> > --> an extra bit.
--> > --> > -->
--> > --> > --> If inclusion of an extra bit means including 31
--> > --> additional bits,
--> > --> it
--> > --> > --> should be just a little bit harder to justify the extra
--> bit...
--> > --> > -->
--> > --> > --> --
--> > --> > --> Eric
--> > --> > -->
--> > --> > --> --> -----Original Message-----
--> > --> > --> --> From: [email-masked]
--> > --> > --> --> [mailto:[email-masked]] On 
--> Behalf Of Caitlin
--> > --> Bestler
--> > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM
--> > --> > --> --> To: Silvano Gai; [email-masked]
--> > --> > --> --> Subject: Re: [rbridge] FTag
--> > --> > --> -->
--> > --> > --> --> [email-masked] wrote:
--> > --> > --> --> > Another important field proposed in:
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
--> > --> > --> --> > cap-00.txt
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> > Is the Ftag (see section 3).
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> > Is there any opposition to add this field?
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> > -- Silvano
--> > --> > --> -->
--> > --> > --> --> Despite the description, this is ultimately a
--> > --> Class of Service
--> > --> > --> --> field. Class of Service fields are always useful,
--> > --> the question
--> > --> > --> --> is whether they are useful enough. Each extra bit is
--> > --> > --> less useful,
--> > --> > --> --> and potentially costs a lot more.
--> > --> > --> -->
--> > --> > --> --> To justify increasing the shim header size I
--> > --> think a scenario
--> > --> > --> --> that would specifically require the extra 
--> classes would
--> be
--> > --> > --> --> useful -- or at least one that exhausts 
--> those available
--> > --> without
--> > --> > --> --> the extra field.
--> > --> > --> -->
--> > --> > --> --> Philosophically, I take the attitude that 
--> the bandwidth
--> > --> belongs
--> > --> > --> --> to the customer. I want a justification for each
--> > --> and every bit
--> > --> > --> --> I take out of it (although realistically I know
--> > --> that they come
--> > --> > --> --> in handy 32-bit packages).
--> > --> > --> -->
--> > --> > --> -->
--> > --> > --> -->
--> > --> > --> --> _______________________________________________
--> > --> > --> --> rbridge mailing list
--> > --> > --> --> [email-masked]
--> > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> > --> -->
--> > --> > -->
--> > -->
--> 

Content-class: urn:content-classes:message
Date: Tue, 17 Oct 2006 09:34:04 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 4756

Eric,

Do you include in your computation the 16 bits of Ethertype = TRILL?

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 4:06 PM
> To: Silvano Gai; Gray, Eric; Caitlin Bestler
> Cc: [email-masked]
> Subject: RE: [rbridge] FTag
> 
> Silvano,
> 
> 	The "encapsulated frame" alignment varies from layer to
> layer and is independent from layer to layer.  When the bits
> hit the wire (or glass), the alignment is not of a particular
> importance.  It is the process of "hand-off" between stack
> layers that might be relevant, depending on implementation.
> 
> 	It is problematic - at best - to attempt to include the
> next layer in the protocol stack in computing alignment, thus
> it is not a good idea to take into account bit-wise alignment
> of the MAC header when determining the "proper" alignment of
> the SHIM, or the "proper" alignment of the next MAC header.
> 
> 	Hence, if we want to have a 32-bit aligment of the SHIM
> header, the options are N*32 bits.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:[email-masked]]
> --> Sent: Monday, October 16, 2006 6:21 PM
> --> To: Gray, Eric; Caitlin Bestler
> --> Cc: [email-masked]
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> --> IMHO, since the encapsulated frame should be 32 bit
> --> aligned, the size of
> --> this option can be 16+n*32, without counting the Ethertype.
> --> I proposed
> --> n=2, i.e. 80 bits, the only other pragmatic alternative is
> --> n=1, i.e. 48
> --> bits.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:[email-masked]]
> --> > Sent: Monday, October 16, 2006 9:29 AM
> --> > To: Gray, Eric; 'Caitlin Bestler'
> --> > Cc: [email-masked]'; Silvano Gai
> --> > Subject: RE: [rbridge] FTag
> --> >
> --> > Oops - "they come in handy 32-bit packages" is the quote
> --> I meant to
> --> > include...
> --> >
> --> > --> -----Original Message-----
> --> > --> From: Gray, Eric
> --> > --> Sent: Monday, October 16, 2006 12:27 PM
> --> > --> To: Caitlin Bestler
> --> > --> Cc: [email-masked]; Silvano Gai
> --> > --> Subject: RE: [rbridge] FTag
> --> > -->
> --> > --> Actually, it is the fact that "they in handy 32-bit
> --> packages" that
> --> > --> should mandate the level of need required to justify
> --> an extra bit.
> --> > -->
> --> > --> If inclusion of an extra bit means including 31
> --> additional bits,
> --> it
> --> > --> should be just a little bit harder to justify the extra
bit...
> --> > -->
> --> > --> --
> --> > --> Eric
> --> > -->
> --> > --> --> -----Original Message-----
> --> > --> --> From: [email-masked]
> --> > --> --> [mailto:[email-masked]] On Behalf Of Caitlin
> --> Bestler
> --> > --> --> Sent: Monday, October 16, 2006 12:09 PM
> --> > --> --> To: Silvano Gai; [email-masked]
> --> > --> --> Subject: Re: [rbridge] FTag
> --> > --> -->
> --> > --> --> [email-masked] wrote:
> --> > --> --> > Another important field proposed in:
> --> > --> --> >
> --> > --> --> >
> --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
> --> > --> --> > cap-00.txt
> --> > --> --> >
> --> > --> --> >
> --> > --> --> >
> --> > --> --> > Is the Ftag (see section 3).
> --> > --> --> >
> --> > --> --> >
> --> > --> --> >
> --> > --> --> > Is there any opposition to add this field?
> --> > --> --> >
> --> > --> --> >
> --> > --> --> >
> --> > --> --> > -- Silvano
> --> > --> -->
> --> > --> --> Despite the description, this is ultimately a
> --> Class of Service
> --> > --> --> field. Class of Service fields are always useful,
> --> the question
> --> > --> --> is whether they are useful enough. Each extra bit is
> --> > --> less useful,
> --> > --> --> and potentially costs a lot more.
> --> > --> -->
> --> > --> --> To justify increasing the shim header size I
> --> think a scenario
> --> > --> --> that would specifically require the extra classes would
be
> --> > --> --> useful -- or at least one that exhausts those available
> --> without
> --> > --> --> the extra field.
> --> > --> -->
> --> > --> --> Philosophically, I take the attitude that the bandwidth
> --> belongs
> --> > --> --> to the customer. I want a justification for each
> --> and every bit
> --> > --> --> I take out of it (although realistically I know
> --> that they come
> --> > --> --> in handy 32-bit packages).
> --> > --> -->
> --> > --> -->
> --> > --> -->
> --> > --> --> _______________________________________________
> --> > --> --> rbridge mailing list
> --> > --> --> [email-masked]
> --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> > --> -->
> --> > -->
> -->

Date: Tue, 17 Oct 2006 11:15:43 -0500
From: "Dale W. Carder" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 503

On Oct 13, 2006, at 11:42 AM, Gray, Eric wrote:
> Do you have a real deployment example in which an enterprise
> would not use firewalls and/or routers to protect an entire
> LAN but would use bridges to protect portions of it?

Sure, RFC 3069 and "private vlans"[1] are both tools that the
operator community uses for this functionality.  Metro ethernet
ISP's are also included in the problem space that trill addresses.

Dale

[1] http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-05.txt

Date: Tue, 17 Oct 2006 07:28:35 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1522

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEEA5778F4FE9BBD778A52113
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
>>>> the appropriate source rbridge for that packet may change
>>>> by the time the packet arrives elsewhere in the rbridge campus.
>>> If you put the source RBridge address in the frame, why should it
>>> change?
>> What might change is what the subsequent hops thinks the source
> _should_
>> be. The address in the packet wouldn't change, but would be useless in=

>> that case.
>>
>=20
> It will tell me with certainty where the frame entered the RBridge
> network (which RBridge did the encapsulation), which for me is
> important, not useless.

While any sort of record-path info would be useful for debugging, what
does this tell you for rbridge?

Again, we're inside the LAN already. You don't know which bridge packets
come through either. Why do you need to know the rbridge ingress?

Joe

--------------enigEEA5778F4FE9BBD778A52113
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigEEA5778F4FE9BBD778A52113--

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 17 Oct 2006 09:51:44 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3641

Silvano,

	It is clear at this point that you would like to include the ingress
RBridge information in the frame as it traverses the CRED.  I believe it's
also clear why: you would like to perform filtering and policy enforcement
within RBridges, and you would like to be able to do this at any arbitrary
subset of deployed RBridges - for example, at specific egress RBridges to
protect the segments to which they deliver from untrusted access by other
segments.

	However, there are two objections you need to overcome:

1)	why do RBridges specifically need to solve this problem or provide
	this capability?  To do this you either have to establish that this
	is covered somewhere in the existing working group charter, or you
	have to convince enough people to achieve a consensus that this is
	something we want to add to the existing charter.

2)	is the approach you propose the one we want to adopt - i.e. - do we
	have a consensus that we want to do this as a data path function in
	RBridges (as opposed to in other network devices) and do we have 
	consensus that expanding the SHIM header is the approach we should 
	use to do this?  To over come this objection, you must - serially -
	establish that there is consensus to do this in RBridges using some
	approach (as yet to be determined) and then work with the WG to get
	consensus on how to do it.

	In my opinion, I believe you are asserting that this is something we
must do, while some of us within the working group view it as something it
might be "nice to do."  There is a significant disparity - at this point -
in what might be called "requirements levels" for this capability.  

	Also, again in my opinion, you are asserting that it must be done 
using your approach.  Assuming that we ever get agreement that this is a
thing tha RBridges should do, how they will do it remains TBD.

	And yet, it does not appear to me that you have established that
this
is a problem RBridges have to solve.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Tuesday, October 17, 2006 12:35 AM
--> To: Joe Touch
--> Cc: Caitlin Bestler; Gray, Eric; [email-masked]; Radia Perlman
--> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> Joe,
--> 
--> > -----Original Message-----
--> > From: Joe Touch [mailto:[email-masked]]
--> > Sent: Monday, October 16, 2006 4:49 PM
--> > To: Silvano Gai
--> > Cc: Caitlin Bestler; Gray, Eric; [email-masked]; Radia Perlman
--> > Subject: Re: [rbridge] TTL only - was RE: New fields in 
--> shim header?
--> > 
--> > 
--> > 
--> > Silvano Gai wrote:
--> > > Joe,
--> > >
--> > > .....
--> > >
--> > >> The enclosed source MAC indicates the source rbridge 
--> at the time it
--> > > was
--> > >> encapsulated;
--> > >
--> > > Not true if the source MAC was spoofed by a host connected to
--> another
--> > > RBridge. Do you agree?
--> > 
--> > True for all spoofing of MACs. That's not addressed by rbridges at
--> all.
--> > 
--> > >> the appropriate source rbridge for that packet may change
--> > >> by the time the packet arrives elsewhere in the rbridge campus.
--> > >
--> > > If you put the source RBridge address in the frame, why 
--> should it
--> > > change?
--> > 
--> > What might change is what the subsequent hops thinks the source
--> _should_
--> > be. The address in the packet wouldn't change, but would 
--> be useless in
--> > that case.
--> > 
--> 
--> It will tell me with certainty where the frame entered the RBridge
--> network (which RBridge did the encapsulation), which for me is
--> important, not useless.
--> 
--> -- Silvano
--> 

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 21:35:17 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1170

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 4:49 PM
> To: Silvano Gai
> Cc: Caitlin Bestler; Gray, Eric; [email-masked]; Radia Perlman
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > .....
> >
> >> The enclosed source MAC indicates the source rbridge at the time it
> > was
> >> encapsulated;
> >
> > Not true if the source MAC was spoofed by a host connected to
another
> > RBridge. Do you agree?
> 
> True for all spoofing of MACs. That's not addressed by rbridges at
all.
> 
> >> the appropriate source rbridge for that packet may change
> >> by the time the packet arrives elsewhere in the rbridge campus.
> >
> > If you put the source RBridge address in the frame, why should it
> > change?
> 
> What might change is what the subsequent hops thinks the source
_should_
> be. The address in the packet wouldn't change, but would be useless in
> that case.
> 

It will tell me with certainty where the frame entered the RBridge
network (which RBridge did the encapsulation), which for me is
important, not useless.

-- Silvano

Date: Mon, 16 Oct 2006 19:58:07 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1458

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0EC9B163FC554B179B8CAE14
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> IMO the correct behavior is:
>=20
> Rm - receives an "RBridge encapsulated frame", determines that the Oute=
r
> DA MAC address is its own address, determines from the shim header that=

> it is not the egress, and forwards another "Rbridge encapsulated frame"=

> to zero or more next-hop RBridge(s).
>=20
> Rn - receives an "RBridge encapsulated frame", determines that the Oute=
r
> DA MAC address is its own address, determines from the shim header that=

> it is the egress, and forwards one or more "native frame(s)."
>=20
> I am not sure in Rm why it is "zero or more" instead of "one or more".

Zero when hopcount=3D0 ;-) That's why it is zero for the shim version, an=
d
one for the native (I think; Radia can confirm).

Joe

--------------enig0EC9B163FC554B179B8CAE14
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0EC9B163FC554B179B8CAE14--

Date: Mon, 16 Oct 2006 19:58:12 -0700
From: Joe Touch <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1027

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5104F2C66081C0D316077804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Gray, Eric wrote:
> Silvano,
>=20
> 	It is zero or more because - in a dynamically changing network
> - it is possible for an intermediate RBridge to legitimately receive=20
> a frame for which it has no legitimate forwarding entries.

Indeed - another good reason (default forwarding is not required in an
rbridge campus).

--------------enig5104F2C66081C0D316077804
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5104F2C66081C0D316077804--

Date: Mon, 16 Oct 2006 19:40:31 -0700
From: Joe Touch <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 4259

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6A88F8FAEE58BE5039CC9E3B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Gray, Eric wrote:
> Joe/Radia,
>=20
> 	This is a point of substantial ambiguity in the currently
> available base protocol specification (dated May, 2006).
>=20
> 	Section 2.6 ("Forwarding Behavior") - which is presumably
> the section that would talk about this - talks about the initial
> tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native=20
> Packet"), but states that the ingress RBridge uses the next-hop
> RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
> This implies router-like (or non-transparent bridging) behavior,
> which _might_ further imply that both the MAC DA and SA will be
> changed at the addressed RBridge next-hop.  But nowhere does it
> say this and - in fact - there have been people who assume that
> only the MAC DA is changed in intermediate RBridges.

Agreed. I was assuming that the SA/DA pair on the outermost header was
per-hop; that seems necessary, since otherwise a SA might appear as
sourced on by different nodes on a segment, confusing the STP used on
those (conventionally-bridged) segments.

> 	Section 2.6.2 - titled "Receipt of an In-Transit Packet",=20
> and which should talk about forwarding across an intermediate=20
> RBridge - does not address anything to do with MAC encapsulation=20
> at an intermediate RBridge.  In fact, it doesn't actually address=20
> all that much that would be interesting at an intermediate RBridge
> generally.

It should probably have an algorithmic description of the desired
behavior. The notes below should be addressed as well (mostly as stated,
but we'll confirm when we go through them in detail).

Joe

> 	Section 2.6.2.1 ("Flooded Packet") - for example - appears
> also to address behavior at the ingress RBridge only.  Reading
> this section, it appears to use "R1" exclusively in talking about
> the RBridge under discussion ("R1" was the ingress RBridge in the
> previous section) and even refers to R1 as the ingress RBridge in
> the 3rd paragraph on page 12.
>=20
> 	Section 2.6.2.2 ("Unicast Packet") does say something that=20
> appears to imply that both MAC DA and SA are changed, except that
> it - once again - uses the ubiquitous "R1" designation (and - in
> this case - R1 appears ambiguously to be either the ingress, the
> local or the egress Rbridge).
>=20
> 	I hope this text is clearer in a soon-to-be-available new
> version of the base protocol specification.  I would suggest the
> use of a figure and new labels to make things less ambiguous.  I
> would also suggest having a distinct section to address egress
> behavior (separate from intermediate, or in-transit, behavior).
>=20
> 	For example, you could add a really simple illustration -=20
>=20
> 	---- R1 --- --- --- Rm --- --- --- Rn ----
>=20
> 	  (ingress)   (intermediate)    (egress)
>=20
> - and identify what makes a particular RBridge one or another
> of these.  I think it's simple enough:
>=20
> R1 - receives "native frame" (for a deifinition of "native") and
> encapsulates it using an Ethertype of "RBridge encapsulated frame".=20
>=20
> Rm - receives an "RBridge encapsulated frame", determines from the
> shim header that it is not the egress, and forwards another "Rbridge
> encapsulated frame" to zero or more next-hop RBridge(s).
>=20
> Rn - receives an "RBridge encapsulated frame", determines from the
> shim header that it is the egress, and forwards one or more "native=20
> frame(s)."
>=20
> 	I also suggest being consistent in which of these RBridges=20
> you're talking about in any of the sub-sections of section 2.6.
>=20
> --
> Eric

--------------enig6A88F8FAEE58BE5039CC9E3B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig6A88F8FAEE58BE5039CC9E3B--

Date: Mon, 16 Oct 2006 16:49:00 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1392

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig48CE6D299FEBEE6008C84F96
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> .....
>=20
>> The enclosed source MAC indicates the source rbridge at the time it
> was
>> encapsulated;=20
>=20
> Not true if the source MAC was spoofed by a host connected to another
> RBridge. Do you agree?

True for all spoofing of MACs. That's not addressed by rbridges at all.

>> the appropriate source rbridge for that packet may change
>> by the time the packet arrives elsewhere in the rbridge campus.
>=20
> If you put the source RBridge address in the frame, why should it
> change?

What might change is what the subsequent hops thinks the source _should_
be. The address in the packet wouldn't change, but would be useless in
that case.

Joe

--------------enig48CE6D299FEBEE6008C84F96
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig48CE6D299FEBEE6008C84F96--

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, "Gray, Eric" <[email-masked]>, Caitlin Bestler <[email-masked]>
Date: Mon, 16 Oct 2006 19:05:41 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 4204

Silvano,

	The "encapsulated frame" alignment varies from layer to
layer and is independent from layer to layer.  When the bits
hit the wire (or glass), the alignment is not of a particular 
importance.  It is the process of "hand-off" between stack
layers that might be relevant, depending on implementation.

	It is problematic - at best - to attempt to include the
next layer in the protocol stack in computing alignment, thus
it is not a good idea to take into account bit-wise alignment
of the MAC header when determining the "proper" alignment of
the SHIM, or the "proper" alignment of the next MAC header.

	Hence, if we want to have a 32-bit aligment of the SHIM
header, the options are N*32 bits.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Monday, October 16, 2006 6:21 PM
--> To: Gray, Eric; Caitlin Bestler
--> Cc: [email-masked]
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> IMHO, since the encapsulated frame should be 32 bit 
--> aligned, the size of
--> this option can be 16+n*32, without counting the Ethertype. 
--> I proposed
--> n=2, i.e. 80 bits, the only other pragmatic alternative is 
--> n=1, i.e. 48
--> bits.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Monday, October 16, 2006 9:29 AM
--> > To: Gray, Eric; 'Caitlin Bestler'
--> > Cc: [email-masked]'; Silvano Gai
--> > Subject: RE: [rbridge] FTag
--> > 
--> > Oops - "they come in handy 32-bit packages" is the quote 
--> I meant to
--> > include...
--> > 
--> > --> -----Original Message-----
--> > --> From: Gray, Eric
--> > --> Sent: Monday, October 16, 2006 12:27 PM
--> > --> To: Caitlin Bestler
--> > --> Cc: [email-masked]; Silvano Gai
--> > --> Subject: RE: [rbridge] FTag
--> > -->
--> > --> Actually, it is the fact that "they in handy 32-bit 
--> packages" that
--> > --> should mandate the level of need required to justify 
--> an extra bit.
--> > -->
--> > --> If inclusion of an extra bit means including 31 
--> additional bits,
--> it
--> > --> should be just a little bit harder to justify the extra bit...
--> > -->
--> > --> --
--> > --> Eric
--> > -->
--> > --> --> -----Original Message-----
--> > --> --> From: [email-masked]
--> > --> --> [mailto:[email-masked]] On Behalf Of Caitlin
--> Bestler
--> > --> --> Sent: Monday, October 16, 2006 12:09 PM
--> > --> --> To: Silvano Gai; [email-masked]
--> > --> --> Subject: Re: [rbridge] FTag
--> > --> -->
--> > --> --> [email-masked] wrote:
--> > --> --> > Another important field proposed in:
--> > --> --> >
--> > --> --> >
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
--> > --> --> > cap-00.txt
--> > --> --> >
--> > --> --> >
--> > --> --> >
--> > --> --> > Is the Ftag (see section 3).
--> > --> --> >
--> > --> --> >
--> > --> --> >
--> > --> --> > Is there any opposition to add this field?
--> > --> --> >
--> > --> --> >
--> > --> --> >
--> > --> --> > -- Silvano
--> > --> -->
--> > --> --> Despite the description, this is ultimately a 
--> Class of Service
--> > --> --> field. Class of Service fields are always useful, 
--> the question
--> > --> --> is whether they are useful enough. Each extra bit is
--> > --> less useful,
--> > --> --> and potentially costs a lot more.
--> > --> -->
--> > --> --> To justify increasing the shim header size I 
--> think a scenario
--> > --> --> that would specifically require the extra classes would be
--> > --> --> useful -- or at least one that exhausts those available
--> without
--> > --> --> the extra field.
--> > --> -->
--> > --> --> Philosophically, I take the attitude that the bandwidth
--> belongs
--> > --> --> to the customer. I want a justification for each 
--> and every bit
--> > --> --> I take out of it (although realistically I know 
--> that they come
--> > --> --> in handy 32-bit packages).
--> > --> -->
--> > --> -->
--> > --> -->
--> > --> --> _______________________________________________
--> > --> --> rbridge mailing list
--> > --> --> [email-masked]
--> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> -->
--> > -->
--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, "Gray, Eric" <[email-masked]>, Joe Touch <[email-masked]>, Caitlin Bestler <[email-masked]>
Date: Mon, 16 Oct 2006 18:58:59 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 7028

Silvano,

	It is zero or more because - in a dynamically changing network
- it is possible for an intermediate RBridge to legitimately receive 
a frame for which it has no legitimate forwarding entries.

--
Eric 

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Monday, October 16, 2006 5:31 PM
--> To: Gray, Eric; Joe Touch; Caitlin Bestler
--> Cc: [email-masked]; Radia Perlman
--> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> IMO the correct behavior is:
--> 
--> Rm - receives an "RBridge encapsulated frame", determines 
--> that the Outer
--> DA MAC address is its own address, determines from the shim 
--> header that
--> it is not the egress, and forwards another "Rbridge 
--> encapsulated frame"
--> to zero or more next-hop RBridge(s).
--> 
--> Rn - receives an "RBridge encapsulated frame", determines 
--> that the Outer
--> DA MAC address is its own address, determines from the shim 
--> header that
--> it is the egress, and forwards one or more "native frame(s)."
--> 
--> I am not sure in Rm why it is "zero or more" instead of 
--> "one or more".
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Monday, October 16, 2006 10:49 AM
--> > To: Joe Touch; Caitlin Bestler
--> > Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
--> > Subject: RE: [rbridge] TTL only - was RE: New fields in 
--> shim header?
--> > 
--> > Joe/Radia,
--> > 
--> > 	This is a point of substantial ambiguity in the currently
--> > available base protocol specification (dated May, 2006).
--> > 
--> > 	Section 2.6 ("Forwarding Behavior") - which is presumably
--> > the section that would talk about this - talks about the initial
--> > tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native
--> > Packet"), but states that the ingress RBridge uses the next-hop
--> > RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
--> > This implies router-like (or non-transparent bridging) behavior,
--> > which _might_ further imply that both the MAC DA and SA will be
--> > changed at the addressed RBridge next-hop.  But nowhere does it
--> > say this and - in fact - there have been people who assume that
--> > only the MAC DA is changed in intermediate RBridges.
--> > 
--> > 	Section 2.6.2 - titled "Receipt of an In-Transit Packet",
--> > and which should talk about forwarding across an intermediate
--> > RBridge - does not address anything to do with MAC encapsulation
--> > at an intermediate RBridge.  In fact, it doesn't actually address
--> > all that much that would be interesting at an intermediate RBridge
--> > generally.
--> > 
--> > 	Section 2.6.2.1 ("Flooded Packet") - for example - appears
--> > also to address behavior at the ingress RBridge only.  Reading
--> > this section, it appears to use "R1" exclusively in talking about
--> > the RBridge under discussion ("R1" was the ingress RBridge in the
--> > previous section) and even refers to R1 as the ingress RBridge in
--> > the 3rd paragraph on page 12.
--> > 
--> > 	Section 2.6.2.2 ("Unicast Packet") does say something that
--> > appears to imply that both MAC DA and SA are changed, except that
--> > it - once again - uses the ubiquitous "R1" designation (and - in
--> > this case - R1 appears ambiguously to be either the ingress, the
--> > local or the egress Rbridge).
--> > 
--> > 	I hope this text is clearer in a soon-to-be-available new
--> > version of the base protocol specification.  I would suggest the
--> > use of a figure and new labels to make things less ambiguous.  I
--> > would also suggest having a distinct section to address egress
--> > behavior (separate from intermediate, or in-transit, behavior).
--> > 
--> > 	For example, you could add a really simple illustration -
--> > 
--> > 	---- R1 --- --- --- Rm --- --- --- Rn ----
--> > 
--> > 	  (ingress)   (intermediate)    (egress)
--> > 
--> > - and identify what makes a particular RBridge one or another
--> > of these.  I think it's simple enough:
--> > 
--> > R1 - receives "native frame" (for a deifinition of "native") and
--> > encapsulates it using an Ethertype of "RBridge 
--> encapsulated frame".
--> > 
--> > Rm - receives an "RBridge encapsulated frame", determines from the
--> > shim header that it is not the egress, and forwards 
--> another "Rbridge
--> > encapsulated frame" to zero or more next-hop RBridge(s).
--> > 
--> > Rn - receives an "RBridge encapsulated frame", determines from the
--> > shim header that it is the egress, and forwards one or 
--> more "native
--> > frame(s)."
--> > 
--> > 	I also suggest being consistent in which of these RBridges
--> > you're talking about in any of the sub-sections of section 2.6.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Joe Touch [mailto:[email-masked]]
--> > --> Sent: Monday, October 16, 2006 12:49 PM
--> > --> To: Caitlin Bestler
--> > --> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
--> > --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
--> header?
--> > -->
--> > -->
--> > -->
--> > --> Caitlin Bestler wrote:
--> > --> > Joe Touch wrote:
--> > --> >
--> > --> >> I don't think we're precluding ingress/egress filtering on
--> > --> >> the LAN, just that it isn't needed inside the 
--> rbridge campus.
--> > --> >> Traffic either originates inside the LAN (on an 
--> rbridge node
--> > --> >> or host) or enters via a transit (a router). Both can be
--> > --> >> constrained with the outer ethernet header 
--> addresses; there's
--> > --> >> nothing magic about the ingress or egress rbridge 
--> node as far
--> as
--> > --> >> filtering is concerned.
--> > --> >>
--> > --> >
--> > --> > Agreed.
--> > --> >
--> > --> > More precisely, there WILL be environments with sufficient
--> > --> > perimeter ingress control that internal checking would not
--> > --> > be required. But if we put the extra fields in the header
--> > --> > they will ALWAYS be there.
--> > -->
--> > --> Rbridge traffic is already differentiated on a per-hop
--> > --> basis; what's the
--> > --> utility in knowing the ingress? That increases - rather
--> > --> than decreases -
--> > --> the state at the interior rbridge nodes.
--> > -->
--> > --> > Most of the extra fields CAN be derived from other 
--> information.
--> > --> > For example the enclosed source MAC address implies the
--> > --> > source RBridge. Therefore it is hard to make a case that
--> > --> > they will provide a permanent benefit.
--> > -->
--> > --> The enclosed source MAC indicates the source rbridge at the
--> > --> time it was
--> > --> encapsulated; the appropriate source rbridge for that
--> > --> packet may change
--> > --> by the time the packet arrives elsewhere in the rbridge
--> > --> campus. That's
--> > --> another reason it's not useful to know the source - it is
--> > --> ephemeral anyway.
--> > -->
--> > --> Joe
--> > -->
--> > -->
--> 

From: "Saikat Ray" <[email-masked]>
To: "'Silvano Gai'" <[email-masked]>, "'Gray, Eric'" <[email-masked]>, "'Joe Touch'" <[email-masked]>,  "'Caitlin Bestler'" <[email-masked]>
Date: Mon, 16 Oct 2006 18:35:36 -0400
Organization: University of Pennsylvania
Cc: [email-masked], 'Radia Perlman' <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Reply-To: [email-masked]
Status: RO
Content-Length: 6473

The outer MAC SA should reflect the last RBridge that forwarded the packet
(and not the ingress RBridge). Otherwise, if legacy Ethernet segments
connect the RBridges (as opposed to having direct physical links), then the
MAC learning of the legacy bridges would get messed up and they _might_
start delivering packets incorrectly.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Silvano Gai
> Sent: Monday, October 16, 2006 6:24 PM
> To: Gray, Eric; Joe Touch; Caitlin Bestler
> Cc: [email-masked]; Radia Perlman
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> Joe/Radia,
> 
> inline
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]]
> > Sent: Monday, October 16, 2006 10:49 AM
> > To: Joe Touch; Caitlin Bestler
> > Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
> > Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> >
> > Joe/Radia,
> >
> > 	This is a point of substantial ambiguity in the currently
> > available base protocol specification (dated May, 2006).
> >
> > 	Section 2.6 ("Forwarding Behavior") - which is presumably
> > the section that would talk about this - talks about the initial
> > tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native
> > Packet"), but states that the ingress RBridge uses the next-hop
> > RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
> > This implies router-like (or non-transparent bridging) behavior,
> > which _might_ further imply that both the MAC DA and SA will be
> > changed at the addressed RBridge next-hop.  But nowhere does it
> > say this and - in fact - there have been people who assume that
> > only the MAC DA is changed in intermediate RBridges.
> 
> Can you clarify which is the proposed behavior for the outer MAC SA?
> 
> Thanks
> 
> -- Silvano
> 
> 
> >
> > 	Section 2.6.2 - titled "Receipt of an In-Transit Packet",
> > and which should talk about forwarding across an intermediate
> > RBridge - does not address anything to do with MAC encapsulation
> > at an intermediate RBridge.  In fact, it doesn't actually address
> > all that much that would be interesting at an intermediate RBridge
> > generally.
> >
> > 	Section 2.6.2.1 ("Flooded Packet") - for example - appears
> > also to address behavior at the ingress RBridge only.  Reading
> > this section, it appears to use "R1" exclusively in talking about
> > the RBridge under discussion ("R1" was the ingress RBridge in the
> > previous section) and even refers to R1 as the ingress RBridge in
> > the 3rd paragraph on page 12.
> >
> > 	Section 2.6.2.2 ("Unicast Packet") does say something that
> > appears to imply that both MAC DA and SA are changed, except that
> > it - once again - uses the ubiquitous "R1" designation (and - in
> > this case - R1 appears ambiguously to be either the ingress, the
> > local or the egress Rbridge).
> >
> > 	I hope this text is clearer in a soon-to-be-available new
> > version of the base protocol specification.  I would suggest the
> > use of a figure and new labels to make things less ambiguous.  I
> > would also suggest having a distinct section to address egress
> > behavior (separate from intermediate, or in-transit, behavior).
> >
> > 	For example, you could add a really simple illustration -
> >
> > 	---- R1 --- --- --- Rm --- --- --- Rn ----
> >
> > 	  (ingress)   (intermediate)    (egress)
> >
> > - and identify what makes a particular RBridge one or another
> > of these.  I think it's simple enough:
> >
> > R1 - receives "native frame" (for a deifinition of "native") and
> > encapsulates it using an Ethertype of "RBridge encapsulated frame".
> >
> > Rm - receives an "RBridge encapsulated frame", determines from the
> > shim header that it is not the egress, and forwards another "Rbridge
> > encapsulated frame" to zero or more next-hop RBridge(s).
> >
> > Rn - receives an "RBridge encapsulated frame", determines from the
> > shim header that it is the egress, and forwards one or more "native
> > frame(s)."
> >
> > 	I also suggest being consistent in which of these RBridges
> > you're talking about in any of the sub-sections of section 2.6.
> >
> > --
> > Eric
> >
> > --> -----Original Message-----
> > --> From: Joe Touch [mailto:[email-masked]]
> > --> Sent: Monday, October 16, 2006 12:49 PM
> > --> To: Caitlin Bestler
> > --> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
> > --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
> header?
> > -->
> > -->
> > -->
> > --> Caitlin Bestler wrote:
> > --> > Joe Touch wrote:
> > --> >
> > --> >> I don't think we're precluding ingress/egress filtering on
> > --> >> the LAN, just that it isn't needed inside the rbridge campus.
> > --> >> Traffic either originates inside the LAN (on an rbridge node
> > --> >> or host) or enters via a transit (a router). Both can be
> > --> >> constrained with the outer ethernet header addresses; there's
> > --> >> nothing magic about the ingress or egress rbridge node as far
> as
> > --> >> filtering is concerned.
> > --> >>
> > --> >
> > --> > Agreed.
> > --> >
> > --> > More precisely, there WILL be environments with sufficient
> > --> > perimeter ingress control that internal checking would not
> > --> > be required. But if we put the extra fields in the header
> > --> > they will ALWAYS be there.
> > -->
> > --> Rbridge traffic is already differentiated on a per-hop
> > --> basis; what's the
> > --> utility in knowing the ingress? That increases - rather
> > --> than decreases -
> > --> the state at the interior rbridge nodes.
> > -->
> > --> > Most of the extra fields CAN be derived from other information.
> > --> > For example the enclosed source MAC address implies the
> > --> > source RBridge. Therefore it is hard to make a case that
> > --> > they will provide a permanent benefit.
> > -->
> > --> The enclosed source MAC indicates the source rbridge at the
> > --> time it was
> > --> encapsulated; the appropriate source rbridge for that
> > --> packet may change
> > --> by the time the packet arrives elsewhere in the rbridge
> > --> campus. That's
> > --> another reason it's not useful to know the source - it is
> > --> ephemeral anyway.
> > -->
> > --> Joe
> > -->
> > -->
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 15:23:59 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Joe Touch" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 5399

Joe/Radia,

inline

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 10:49 AM
> To: Joe Touch; Caitlin Bestler
> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> Joe/Radia,
> 
> 	This is a point of substantial ambiguity in the currently
> available base protocol specification (dated May, 2006).
> 
> 	Section 2.6 ("Forwarding Behavior") - which is presumably
> the section that would talk about this - talks about the initial
> tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native
> Packet"), but states that the ingress RBridge uses the next-hop
> RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
> This implies router-like (or non-transparent bridging) behavior,
> which _might_ further imply that both the MAC DA and SA will be
> changed at the addressed RBridge next-hop.  But nowhere does it
> say this and - in fact - there have been people who assume that
> only the MAC DA is changed in intermediate RBridges.

Can you clarify which is the proposed behavior for the outer MAC SA?

Thanks

-- Silvano

> 
> 	Section 2.6.2 - titled "Receipt of an In-Transit Packet",
> and which should talk about forwarding across an intermediate
> RBridge - does not address anything to do with MAC encapsulation
> at an intermediate RBridge.  In fact, it doesn't actually address
> all that much that would be interesting at an intermediate RBridge
> generally.
> 
> 	Section 2.6.2.1 ("Flooded Packet") - for example - appears
> also to address behavior at the ingress RBridge only.  Reading
> this section, it appears to use "R1" exclusively in talking about
> the RBridge under discussion ("R1" was the ingress RBridge in the
> previous section) and even refers to R1 as the ingress RBridge in
> the 3rd paragraph on page 12.
> 
> 	Section 2.6.2.2 ("Unicast Packet") does say something that
> appears to imply that both MAC DA and SA are changed, except that
> it - once again - uses the ubiquitous "R1" designation (and - in
> this case - R1 appears ambiguously to be either the ingress, the
> local or the egress Rbridge).
> 
> 	I hope this text is clearer in a soon-to-be-available new
> version of the base protocol specification.  I would suggest the
> use of a figure and new labels to make things less ambiguous.  I
> would also suggest having a distinct section to address egress
> behavior (separate from intermediate, or in-transit, behavior).
> 
> 	For example, you could add a really simple illustration -
> 
> 	---- R1 --- --- --- Rm --- --- --- Rn ----
> 
> 	  (ingress)   (intermediate)    (egress)
> 
> - and identify what makes a particular RBridge one or another
> of these.  I think it's simple enough:
> 
> R1 - receives "native frame" (for a deifinition of "native") and
> encapsulates it using an Ethertype of "RBridge encapsulated frame".
> 
> Rm - receives an "RBridge encapsulated frame", determines from the
> shim header that it is not the egress, and forwards another "Rbridge
> encapsulated frame" to zero or more next-hop RBridge(s).
> 
> Rn - receives an "RBridge encapsulated frame", determines from the
> shim header that it is the egress, and forwards one or more "native
> frame(s)."
> 
> 	I also suggest being consistent in which of these RBridges
> you're talking about in any of the sub-sections of section 2.6.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Joe Touch [mailto:[email-masked]]
> --> Sent: Monday, October 16, 2006 12:49 PM
> --> To: Caitlin Bestler
> --> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
> --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
header?
> -->
> -->
> -->
> --> Caitlin Bestler wrote:
> --> > Joe Touch wrote:
> --> >
> --> >> I don't think we're precluding ingress/egress filtering on
> --> >> the LAN, just that it isn't needed inside the rbridge campus.
> --> >> Traffic either originates inside the LAN (on an rbridge node
> --> >> or host) or enters via a transit (a router). Both can be
> --> >> constrained with the outer ethernet header addresses; there's
> --> >> nothing magic about the ingress or egress rbridge node as far
as
> --> >> filtering is concerned.
> --> >>
> --> >
> --> > Agreed.
> --> >
> --> > More precisely, there WILL be environments with sufficient
> --> > perimeter ingress control that internal checking would not
> --> > be required. But if we put the extra fields in the header
> --> > they will ALWAYS be there.
> -->
> --> Rbridge traffic is already differentiated on a per-hop
> --> basis; what's the
> --> utility in knowing the ingress? That increases - rather
> --> than decreases -
> --> the state at the interior rbridge nodes.
> -->
> --> > Most of the extra fields CAN be derived from other information.
> --> > For example the enclosed source MAC address implies the
> --> > source RBridge. Therefore it is hard to make a case that
> --> > they will provide a permanent benefit.
> -->
> --> The enclosed source MAC indicates the source rbridge at the
> --> time it was
> --> encapsulated; the appropriate source rbridge for that
> --> packet may change
> --> by the time the packet arrives elsewhere in the rbridge
> --> campus. That's
> --> another reason it's not useful to know the source - it is
> --> ephemeral anyway.
> -->
> --> Joe
> -->
> -->

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 15:20:37 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 2844

IMHO, since the encapsulated frame should be 32 bit aligned, the size of
this option can be 16+n*32, without counting the Ethertype. I proposed
n=2, i.e. 80 bits, the only other pragmatic alternative is n=1, i.e. 48
bits.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 9:29 AM
> To: Gray, Eric; 'Caitlin Bestler'
> Cc: [email-masked]'; Silvano Gai
> Subject: RE: [rbridge] FTag
> 
> Oops - "they come in handy 32-bit packages" is the quote I meant to
> include...
> 
> --> -----Original Message-----
> --> From: Gray, Eric
> --> Sent: Monday, October 16, 2006 12:27 PM
> --> To: Caitlin Bestler
> --> Cc: [email-masked]; Silvano Gai
> --> Subject: RE: [rbridge] FTag
> -->
> --> Actually, it is the fact that "they in handy 32-bit packages" that
> --> should mandate the level of need required to justify an extra bit.
> -->
> --> If inclusion of an extra bit means including 31 additional bits,
it
> --> should be just a little bit harder to justify the extra bit...
> -->
> --> --
> --> Eric
> -->
> --> --> -----Original Message-----
> --> --> From: [email-masked]
> --> --> [mailto:[email-masked]] On Behalf Of Caitlin
Bestler
> --> --> Sent: Monday, October 16, 2006 12:09 PM
> --> --> To: Silvano Gai; [email-masked]
> --> --> Subject: Re: [rbridge] FTag
> --> -->
> --> --> [email-masked] wrote:
> --> --> > Another important field proposed in:
> --> --> >
> --> --> >
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
> --> --> > cap-00.txt
> --> --> >
> --> --> >
> --> --> >
> --> --> > Is the Ftag (see section 3).
> --> --> >
> --> --> >
> --> --> >
> --> --> > Is there any opposition to add this field?
> --> --> >
> --> --> >
> --> --> >
> --> --> > -- Silvano
> --> -->
> --> --> Despite the description, this is ultimately a Class of Service
> --> --> field. Class of Service fields are always useful, the question
> --> --> is whether they are useful enough. Each extra bit is
> --> less useful,
> --> --> and potentially costs a lot more.
> --> -->
> --> --> To justify increasing the shim header size I think a scenario
> --> --> that would specifically require the extra classes would be
> --> --> useful -- or at least one that exhausts those available
without
> --> --> the extra field.
> --> -->
> --> --> Philosophically, I take the attitude that the bandwidth
belongs
> --> --> to the customer. I want a justification for each and every bit
> --> --> I take out of it (although realistically I know that they come
> --> --> in handy 32-bit packages).
> --> -->
> --> -->
> --> -->
> --> --> _______________________________________________
> --> --> rbridge mailing list
> --> --> [email-masked]
> --> --> http://mailman.postel.org/mailman/listinfo/rbridge
> --> -->
> -->

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 14:30:57 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Joe Touch" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 5864

IMO the correct behavior is:

Rm - receives an "RBridge encapsulated frame", determines that the Outer
DA MAC address is its own address, determines from the shim header that
it is not the egress, and forwards another "Rbridge encapsulated frame"
to zero or more next-hop RBridge(s).

Rn - receives an "RBridge encapsulated frame", determines that the Outer
DA MAC address is its own address, determines from the shim header that
it is the egress, and forwards one or more "native frame(s)."

I am not sure in Rm why it is "zero or more" instead of "one or more".

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 10:49 AM
> To: Joe Touch; Caitlin Bestler
> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> Joe/Radia,
> 
> 	This is a point of substantial ambiguity in the currently
> available base protocol specification (dated May, 2006).
> 
> 	Section 2.6 ("Forwarding Behavior") - which is presumably
> the section that would talk about this - talks about the initial
> tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native
> Packet"), but states that the ingress RBridge uses the next-hop
> RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
> This implies router-like (or non-transparent bridging) behavior,
> which _might_ further imply that both the MAC DA and SA will be
> changed at the addressed RBridge next-hop.  But nowhere does it
> say this and - in fact - there have been people who assume that
> only the MAC DA is changed in intermediate RBridges.
> 
> 	Section 2.6.2 - titled "Receipt of an In-Transit Packet",
> and which should talk about forwarding across an intermediate
> RBridge - does not address anything to do with MAC encapsulation
> at an intermediate RBridge.  In fact, it doesn't actually address
> all that much that would be interesting at an intermediate RBridge
> generally.
> 
> 	Section 2.6.2.1 ("Flooded Packet") - for example - appears
> also to address behavior at the ingress RBridge only.  Reading
> this section, it appears to use "R1" exclusively in talking about
> the RBridge under discussion ("R1" was the ingress RBridge in the
> previous section) and even refers to R1 as the ingress RBridge in
> the 3rd paragraph on page 12.
> 
> 	Section 2.6.2.2 ("Unicast Packet") does say something that
> appears to imply that both MAC DA and SA are changed, except that
> it - once again - uses the ubiquitous "R1" designation (and - in
> this case - R1 appears ambiguously to be either the ingress, the
> local or the egress Rbridge).
> 
> 	I hope this text is clearer in a soon-to-be-available new
> version of the base protocol specification.  I would suggest the
> use of a figure and new labels to make things less ambiguous.  I
> would also suggest having a distinct section to address egress
> behavior (separate from intermediate, or in-transit, behavior).
> 
> 	For example, you could add a really simple illustration -
> 
> 	---- R1 --- --- --- Rm --- --- --- Rn ----
> 
> 	  (ingress)   (intermediate)    (egress)
> 
> - and identify what makes a particular RBridge one or another
> of these.  I think it's simple enough:
> 
> R1 - receives "native frame" (for a deifinition of "native") and
> encapsulates it using an Ethertype of "RBridge encapsulated frame".
> 
> Rm - receives an "RBridge encapsulated frame", determines from the
> shim header that it is not the egress, and forwards another "Rbridge
> encapsulated frame" to zero or more next-hop RBridge(s).
> 
> Rn - receives an "RBridge encapsulated frame", determines from the
> shim header that it is the egress, and forwards one or more "native
> frame(s)."
> 
> 	I also suggest being consistent in which of these RBridges
> you're talking about in any of the sub-sections of section 2.6.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Joe Touch [mailto:[email-masked]]
> --> Sent: Monday, October 16, 2006 12:49 PM
> --> To: Caitlin Bestler
> --> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
> --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
header?
> -->
> -->
> -->
> --> Caitlin Bestler wrote:
> --> > Joe Touch wrote:
> --> >
> --> >> I don't think we're precluding ingress/egress filtering on
> --> >> the LAN, just that it isn't needed inside the rbridge campus.
> --> >> Traffic either originates inside the LAN (on an rbridge node
> --> >> or host) or enters via a transit (a router). Both can be
> --> >> constrained with the outer ethernet header addresses; there's
> --> >> nothing magic about the ingress or egress rbridge node as far
as
> --> >> filtering is concerned.
> --> >>
> --> >
> --> > Agreed.
> --> >
> --> > More precisely, there WILL be environments with sufficient
> --> > perimeter ingress control that internal checking would not
> --> > be required. But if we put the extra fields in the header
> --> > they will ALWAYS be there.
> -->
> --> Rbridge traffic is already differentiated on a per-hop
> --> basis; what's the
> --> utility in knowing the ingress? That increases - rather
> --> than decreases -
> --> the state at the interior rbridge nodes.
> -->
> --> > Most of the extra fields CAN be derived from other information.
> --> > For example the enclosed source MAC address implies the
> --> > source RBridge. Therefore it is hard to make a case that
> --> > they will provide a permanent benefit.
> -->
> --> The enclosed source MAC indicates the source rbridge at the
> --> time it was
> --> encapsulated; the appropriate source rbridge for that
> --> packet may change
> --> by the time the packet arrives elsewhere in the rbridge
> --> campus. That's
> --> another reason it's not useful to know the source - it is
> --> ephemeral anyway.
> -->
> --> Joe
> -->
> -->

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 14:20:49 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 518

Joe,

.....

> 
> The enclosed source MAC indicates the source rbridge at the time it
was
> encapsulated; 

Not true if the source MAC was spoofed by a host connected to another
RBridge. Do you agree?

> the appropriate source rbridge for that packet may change
> by the time the packet arrives elsewhere in the rbridge campus.

If you put the source RBridge address in the frame, why should it
change?

-- Silvano

> That's
> another reason it's not useful to know the source - it is ephemeral
> anyway.
> 
> Joe

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>
Date: Mon, 16 Oct 2006 14:34:29 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 3418

Radia,

	I believe it is not quite accurate to interpret Caitlin's 
included reply to Silvano as "support for FTag" - but I may be
wrong.  In fact, in qualifying that "support" I would say that
you are offering more support for FTag than Caitlin is.

	I am unsure why the earlier suggestion to use the EXP bits
(analog - since this is technically not exactly an MPLS shim) is
not sufficient.  Do we need more than that?   Why, and for what
potential gain?

	I personally don't see any reason to steal further from the
20-1 bits we currently expect to use to identify either where the
frame came from or where it is going to.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Monday, October 16, 2006 2:10 PM
--> To: Caitlin Bestler
--> Cc: [email-masked]
--> Subject: Re: [rbridge] FTag
--> 
--> I agree with Caitlin, that FTag is certainly valuable. The 
--> question is 
--> how valuable, and how many bits.
--> In the 4-byte (MPLE-like) shim, the egress/ingress RBridge 
--> nickname is 
--> 19 bits. I suspect 16 bits
--> would suffice, and we could use 3 bits for F-tag. Would 
--> that be enough? 
--> I'd sort of hope so, since
--> 3 bits means 8 forwarding tables, 8 times as many ingress 
--> RBridge trees.
--> 
--> So potentially we could eat 3 bits out of the 
--> label/nickname field and 
--> use that for F-tag.
--> 
--> We haven't discussed the LID fields. Perhaps that should be 
--> a different 
--> thread. Since that doesn't
--> affect forwarding, and is only a convenience to the egress 
--> RBridge, that 
--> doesn't seem too compelling.
--> The ingress RBridge has to do the lookup per endnode, so 
--> it's only at 
--> most twice as much computation
--> for a Designated RBridge to have to do the lookup both when 
--> a packet 
--> leaves its link and when it enters.
--> 
--> Radia
--> 
--> 
--> 
--> Caitlin Bestler wrote:
--> 
--> >[email-masked] wrote:
--> >  
--> >
--> >>Another important field proposed in:
--> >>
--> >>http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
--> >>cap-00.txt 
--> >>
--> >>
--> >>
--> >>Is the Ftag (see section 3).
--> >>
--> >>
--> >>
--> >>Is there any opposition to add this field?
--> >>
--> >>
--> >>
--> >>-- Silvano
--> >>    
--> >>
--> >
--> >Despite the description, this is ultimately a Class of Service
--> >field. Class of Service fields are always useful, the question
--> >is whether they are useful enough. Each extra bit is less useful,
--> >and potentially costs a lot more.
--> >
--> >To justify increasing the shim header size I think a scenario
--> >that would specifically require the extra classes would be
--> >useful -- or at least one that exhausts those available without
--> >the extra field.
--> >
--> >Philosophically, I take the attitude that the bandwidth belongs
--> >to the customer. I want a justification for each and every bit
--> >I take out of it (although realistically I know that they come
--> >in handy 32-bit packages).
--> >
--> >
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Mon, 16 Oct 2006 11:09:58 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 2023

I agree with Caitlin, that FTag is certainly valuable. The question is 
how valuable, and how many bits.
In the 4-byte (MPLE-like) shim, the egress/ingress RBridge nickname is 
19 bits. I suspect 16 bits
would suffice, and we could use 3 bits for F-tag. Would that be enough? 
I'd sort of hope so, since
3 bits means 8 forwarding tables, 8 times as many ingress RBridge trees.

So potentially we could eat 3 bits out of the label/nickname field and 
use that for F-tag.

We haven't discussed the LID fields. Perhaps that should be a different 
thread. Since that doesn't
affect forwarding, and is only a convenience to the egress RBridge, that 
doesn't seem too compelling.
The ingress RBridge has to do the lookup per endnode, so it's only at 
most twice as much computation
for a Designated RBridge to have to do the lookup both when a packet 
leaves its link and when it enters.

Radia

Caitlin Bestler wrote:

>[email-masked] wrote:
>  
>
>>Another important field proposed in:
>>
>>http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
>>cap-00.txt 
>>
>>
>>
>>Is the Ftag (see section 3).
>>
>>
>>
>>Is there any opposition to add this field?
>>
>>
>>
>>-- Silvano
>>    
>>
>
>Despite the description, this is ultimately a Class of Service
>field. Class of Service fields are always useful, the question
>is whether they are useful enough. Each extra bit is less useful,
>and potentially costs a lot more.
>
>To justify increasing the shim header size I think a scenario
>that would specifically require the extra classes would be
>useful -- or at least one that exhausts those available without
>the extra field.
>
>Philosophically, I take the attitude that the bandwidth belongs
>to the customer. I want a justification for each and every bit
>I take out of it (although realistically I know that they come
>in handy 32-bit packages).
>
>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

From: "Gray, Eric" <[email-masked]>
To: Joe Touch <[email-masked]>, Caitlin Bestler <[email-masked]>
Date: Mon, 16 Oct 2006 13:49:14 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 4786

Joe/Radia,

	This is a point of substantial ambiguity in the currently
available base protocol specification (dated May, 2006).

	Section 2.6 ("Forwarding Behavior") - which is presumably
the section that would talk about this - talks about the initial
tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native 
Packet"), but states that the ingress RBridge uses the next-hop
RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
This implies router-like (or non-transparent bridging) behavior,
which _might_ further imply that both the MAC DA and SA will be
changed at the addressed RBridge next-hop.  But nowhere does it
say this and - in fact - there have been people who assume that
only the MAC DA is changed in intermediate RBridges.

	Section 2.6.2 - titled "Receipt of an In-Transit Packet", 
and which should talk about forwarding across an intermediate 
RBridge - does not address anything to do with MAC encapsulation 
at an intermediate RBridge.  In fact, it doesn't actually address 
all that much that would be interesting at an intermediate RBridge
generally.

	Section 2.6.2.1 ("Flooded Packet") - for example - appears
also to address behavior at the ingress RBridge only.  Reading
this section, it appears to use "R1" exclusively in talking about
the RBridge under discussion ("R1" was the ingress RBridge in the
previous section) and even refers to R1 as the ingress RBridge in
the 3rd paragraph on page 12.

	Section 2.6.2.2 ("Unicast Packet") does say something that 
appears to imply that both MAC DA and SA are changed, except that
it - once again - uses the ubiquitous "R1" designation (and - in
this case - R1 appears ambiguously to be either the ingress, the
local or the egress Rbridge).

	I hope this text is clearer in a soon-to-be-available new
version of the base protocol specification.  I would suggest the
use of a figure and new labels to make things less ambiguous.  I
would also suggest having a distinct section to address egress
behavior (separate from intermediate, or in-transit, behavior).

	For example, you could add a really simple illustration - 

	---- R1 --- --- --- Rm --- --- --- Rn ----

	  (ingress)   (intermediate)    (egress)

- and identify what makes a particular RBridge one or another
of these.  I think it's simple enough:

R1 - receives "native frame" (for a deifinition of "native") and
encapsulates it using an Ethertype of "RBridge encapsulated frame". 

Rm - receives an "RBridge encapsulated frame", determines from the
shim header that it is not the egress, and forwards another "Rbridge
encapsulated frame" to zero or more next-hop RBridge(s).

Rn - receives an "RBridge encapsulated frame", determines from the
shim header that it is the egress, and forwards one or more "native 
frame(s)."

	I also suggest being consistent in which of these RBridges 
you're talking about in any of the sub-sections of section 2.6.

--
Eric

--> -----Original Message-----
--> From: Joe Touch [mailto:[email-masked]] 
--> Sent: Monday, October 16, 2006 12:49 PM
--> To: Caitlin Bestler
--> Cc: Silvano Gai; Gray, Eric; [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> 
--> Caitlin Bestler wrote:
--> > Joe Touch wrote:
--> > 
--> >> I don't think we're precluding ingress/egress filtering on
--> >> the LAN, just that it isn't needed inside the rbridge campus.
--> >> Traffic either originates inside the LAN (on an rbridge node
--> >> or host) or enters via a transit (a router). Both can be
--> >> constrained with the outer ethernet header addresses; there's
--> >> nothing magic about the ingress or egress rbridge node as far as
--> >> filtering is concerned. 
--> >>
--> > 
--> > Agreed.
--> > 
--> > More precisely, there WILL be environments with sufficient
--> > perimeter ingress control that internal checking would not
--> > be required. But if we put the extra fields in the header
--> > they will ALWAYS be there.
--> 
--> Rbridge traffic is already differentiated on a per-hop 
--> basis; what's the
--> utility in knowing the ingress? That increases - rather 
--> than decreases -
--> the state at the interior rbridge nodes.
--> 
--> > Most of the extra fields CAN be derived from other information.
--> > For example the enclosed source MAC address implies the 
--> > source RBridge. Therefore it is hard to make a case that
--> > they will provide a permanent benefit. 
--> 
--> The enclosed source MAC indicates the source rbridge at the 
--> time it was
--> encapsulated; the appropriate source rbridge for that 
--> packet may change
--> by the time the packet arrives elsewhere in the rbridge 
--> campus. That's
--> another reason it's not useful to know the source - it is 
--> ephemeral anyway.
--> 
--> Joe
--> 
--> 

Date: Mon, 16 Oct 2006 09:59:36 -0700
From: Joe Touch <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 1756

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8F0177E2AFCADEA7B01749AC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Caitlin Bestler wrote:...
> Despite the description, this is ultimately a Class of Service
> field. Class of Service fields are always useful, the question
> is whether they are useful enough. Each extra bit is less useful,
> and potentially costs a lot more.
>=20
> To justify increasing the shim header size I think a scenario
> that would specifically require the extra classes would be
> useful -- or at least one that exhausts those available without
> the extra field.
>=20
> Philosophically, I take the attitude that the bandwidth belongs
> to the customer. I want a justification for each and every bit
> I take out of it (although realistically I know that they come
> in handy 32-bit packages).

And it's nice to have room for expansion, i.e., unused bits.

IMO, we're either trying to support routed ethernet or routed IP; if the
former, there's no point in anything other than the TTL field beyond the
destination address. If the latter, then let's put in a full IPv6 header
- with options and run IP on the nodes - i.e., just use IP.

Joe

--------------enig8F0177E2AFCADEA7B01749AC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig8F0177E2AFCADEA7B01749AC--

Date: Mon, 16 Oct 2006 10:03:15 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1522

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7C0126CC087AA1EB3F59BABA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:...
> In addition to ACLs, I have read that having the two RBridge addresses
> can be useful for:
> - Policy based forwarding
> - Network Troubleshooting
> - Hardware based learning

The source address tells you which source did the encapsulation, which
may have changed. It might be useful for debugging, but so might a lot
of other information; we can't fit a full set of diagnostics there.

Policy-based forwarding implies that the source rbridge is useful
information; as I noted in my other post, it can change while a packet
is in transit, so it doesn't really mean much anyway.

It'd be useful to understand what 'hardware based learning' refers to;
there are still source/dest MAC addresses used between the rbridge
components which support existing hardware learning ('smart bridges').

Joe

--------------enig7C0126CC087AA1EB3F59BABA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7C0126CC087AA1EB3F59BABA--

Date: Mon, 16 Oct 2006 09:49:28 -0700
From: Joe Touch <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2116

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3DE20CB00921A040B73E18AC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Caitlin Bestler wrote:
> Joe Touch wrote:
>=20
>> I don't think we're precluding ingress/egress filtering on
>> the LAN, just that it isn't needed inside the rbridge campus.
>> Traffic either originates inside the LAN (on an rbridge node
>> or host) or enters via a transit (a router). Both can be
>> constrained with the outer ethernet header addresses; there's
>> nothing magic about the ingress or egress rbridge node as far as
>> filtering is concerned.=20
>>
>=20
> Agreed.
>=20
> More precisely, there WILL be environments with sufficient
> perimeter ingress control that internal checking would not
> be required. But if we put the extra fields in the header
> they will ALWAYS be there.

Rbridge traffic is already differentiated on a per-hop basis; what's the
utility in knowing the ingress? That increases - rather than decreases -
the state at the interior rbridge nodes.

> Most of the extra fields CAN be derived from other information.
> For example the enclosed source MAC address implies the=20
> source RBridge. Therefore it is hard to make a case that
> they will provide a permanent benefit.=20

The enclosed source MAC indicates the source rbridge at the time it was
encapsulated; the appropriate source rbridge for that packet may change
by the time the packet arrives elsewhere in the rbridge campus. That's
another reason it's not useful to know the source - it is ephemeral anywa=
y.

Joe

--------------enig3DE20CB00921A040B73E18AC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig3DE20CB00921A040B73E18AC--

From: "Gray, Eric" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "'Caitlin Bestler'" <[email-masked]>
Date: Mon, 16 Oct 2006 12:28:34 -0400
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 2269

Oops - "they come in handy 32-bit packages" is the quote I meant to
include...

--> -----Original Message-----
--> From: Gray, Eric 
--> Sent: Monday, October 16, 2006 12:27 PM
--> To: Caitlin Bestler
--> Cc: [email-masked]; Silvano Gai
--> Subject: RE: [rbridge] FTag
--> 
--> Actually, it is the fact that "they in handy 32-bit packages" that
--> should mandate the level of need required to justify an extra bit.
--> 
--> If inclusion of an extra bit means including 31 additional bits, it
--> should be just a little bit harder to justify the extra bit...
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: [email-masked] 
--> --> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
--> --> Sent: Monday, October 16, 2006 12:09 PM
--> --> To: Silvano Gai; [email-masked]
--> --> Subject: Re: [rbridge] FTag
--> --> 
--> --> [email-masked] wrote:
--> --> > Another important field proposed in:
--> --> > 
--> --> > http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
--> --> > cap-00.txt 
--> --> > 
--> --> > 
--> --> > 
--> --> > Is the Ftag (see section 3).
--> --> > 
--> --> > 
--> --> > 
--> --> > Is there any opposition to add this field?
--> --> > 
--> --> > 
--> --> > 
--> --> > -- Silvano
--> --> 
--> --> Despite the description, this is ultimately a Class of Service
--> --> field. Class of Service fields are always useful, the question
--> --> is whether they are useful enough. Each extra bit is 
--> less useful,
--> --> and potentially costs a lot more.
--> --> 
--> --> To justify increasing the shim header size I think a scenario
--> --> that would specifically require the extra classes would be
--> --> useful -- or at least one that exhausts those available without
--> --> the extra field.
--> --> 
--> --> Philosophically, I take the attitude that the bandwidth belongs
--> --> to the customer. I want a justification for each and every bit
--> --> I take out of it (although realistically I know that they come
--> --> in handy 32-bit packages).
--> --> 
--> --> 
--> --> 
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> --> 
--> 

From: "Gray, Eric" <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Date: Mon, 16 Oct 2006 12:27:06 -0400
Cc: [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 1757

Actually, it is the fact that "they in handy 32-bit packages" that
should mandate the level of need required to justify an extra bit.

If inclusion of an extra bit means including 31 additional bits, it
should be just a little bit harder to justify the extra bit...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
--> Sent: Monday, October 16, 2006 12:09 PM
--> To: Silvano Gai; [email-masked]
--> Subject: Re: [rbridge] FTag
--> 
--> [email-masked] wrote:
--> > Another important field proposed in:
--> > 
--> > http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
--> > cap-00.txt 
--> > 
--> > 
--> > 
--> > Is the Ftag (see section 3).
--> > 
--> > 
--> > 
--> > Is there any opposition to add this field?
--> > 
--> > 
--> > 
--> > -- Silvano
--> 
--> Despite the description, this is ultimately a Class of Service
--> field. Class of Service fields are always useful, the question
--> is whether they are useful enough. Each extra bit is less useful,
--> and potentially costs a lot more.
--> 
--> To justify increasing the shim header size I think a scenario
--> that would specifically require the extra classes would be
--> useful -- or at least one that exhausts those available without
--> the extra field.
--> 
--> Philosophically, I take the attitude that the bandwidth belongs
--> to the customer. I want a justification for each and every bit
--> I take out of it (although realistically I know that they come
--> in handy 32-bit packages).
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 09:02:49 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 864

Joe Touch wrote:

> 
> I don't think we're precluding ingress/egress filtering on
> the LAN, just that it isn't needed inside the rbridge campus.
> Traffic either originates inside the LAN (on an rbridge node
> or host) or enters via a transit (a router). Both can be
> constrained with the outer ethernet header addresses; there's
> nothing magic about the ingress or egress rbridge node as far as
> filtering is concerned. 
> 

Agreed.

More precisely, there WILL be environments with sufficient
perimeter ingress control that internal checking would not
be required. But if we put the extra fields in the header
they will ALWAYS be there.

Most of the extra fields CAN be derived from other information.
For example the enclosed source MAC address implies the 
source RBridge. Therefore it is hard to make a case that
they will provide a permanent benefit. 

Content-class: urn:content-classes:message
Date: Mon, 16 Oct 2006 09:09:13 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] FTag
Status: RO
Content-Length: 922

[email-masked] wrote:
> Another important field proposed in:
> 
> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
> cap-00.txt 
> 
> 
> 
> Is the Ftag (see section 3).
> 
> 
> 
> Is there any opposition to add this field?
> 
> 
> 
> -- Silvano

Despite the description, this is ultimately a Class of Service
field. Class of Service fields are always useful, the question
is whether they are useful enough. Each extra bit is less useful,
and potentially costs a lot more.

To justify increasing the shim header size I think a scenario
that would specifically require the extra classes would be
useful -- or at least one that exhausts those available without
the extra field.

Philosophically, I take the attitude that the bandwidth belongs
to the customer. I want a justification for each and every bit
I take out of it (although realistically I know that they come
in handy 32-bit packages).

Date: Sun, 15 Oct 2006 23:13:56 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2553

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBB64B1E13AE283C0DB835474
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Eric,
>=20
>> -----Original Message-----
>> From: Gray, Eric [mailto:[email-masked]]
>> Sent: Friday, October 13, 2006 9:43 AM
>> To: Silvano Gai; Caitlin Bestler; Joe Touch
>> Cc: [email-masked]; Radia Perlman
>> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
>>
>>
>>
>> --- [SNIP] ---
>> -->
>> --> The issue is not Rogue RBridges, the issue is that in a network
> there
>> --> will be RBridges that will connect unsecured hosts/links and the
>> network
>> --> manager may desire an easy way to restrict them to a subset of the=

>> TRILL
>> --> cloud.
>>
>> Do you have a real deployment example in which an enterprise
>> would not use firewalls and/or routers to protect an entire
>> LAN but would use bridges to protect portions of it?
>=20
>=20
> Enterprise uses any possible combination of Firewall, Routers, ACL at
> the 5-tuple layers, VLANs, ACL at the MAC address layer and whatever
> else you give them to protect their network. I have seen many large
> networks and even if there are similarities, nobody does it exactly the=

> same way.=20
>=20
> Ingress / Egress RBridge address filtering is just a tool, as many
> others to empower some network managers. Will it solve all the security=

> problems? NO.
> Will it be used in several deployments? YES.
>=20
> Of course, if we design the encapsulation so that it is not supported,
> it cannot be done! Why do you want to preclude it?

I don't think we're precluding ingress/egress filtering on the LAN, just
that it isn't needed inside the rbridge campus. Traffic either
originates inside the LAN (on an rbridge node or host) or enters via a
transit (a router). Both can be constrained with the outer ethernet
header addresses; there's nothing magic about the ingress or egress
rbridge node as far as filtering is concerned.

Joe

--------------enigBB64B1E13AE283C0DB835474
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigBB64B1E13AE283C0DB835474--

Content-class: urn:content-classes:message
Date: Sun, 15 Oct 2006 18:24:38 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 7728

Eric,

The fact that the network is under a single administrative domain and
the fact that different part of the network have different
users/security are not in contradiction.

Let's take a University, a single backbone interconnecting many networks
(Departments, Labs, Administration, External) and many users (Profs,
Students, Admin). Firewall, Routers and 5-Tuple ACLs are probably used
for security, but it is also important to guarantee that firewalls and
routers are not bypassed. Therefore it is possible to think that a
network administrator may want to disallow the RBdridges connecting the
Labs to talk directly with the Rbridges connecting the administrations
and so on.

Radia mentioned a Hospital Network: I think it has similar issues.

Clearly ingress/egress RBridge ACLs cannot be the only tool, but being
able to test in a generalized ACL the ingress and egress RBridge address
is valuable.

If we put the ingress RBridge address in the packet then products can
test it in value added features, if it is not there, such features
cannot be built.

In addition to ACLs, I have read that having the two RBridge addresses
can be useful for:
- Policy based forwarding
- Network Troubleshooting
- Hardware based learning

I think this WG should seriously consider inserting both addresses in
the shim header

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 13, 2006 4:27 PM
> To: Silvano Gai; Radia Perlman; Caitlin Bestler
> Cc: [email-masked]
> Subject: RE: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> Silvano,
> 
> 	I am still having difficulty in understanding why, in a single
> layer 2 network (LAN) and in a common administrative domain, we should
> be concerned about the possibility of attack from one portion of the
> LAN and not be concerned about other portions of the same LAN.
> 
> 	If you have suspected bad-guys in your LAN, inside the
protection
> typically provided by a router/firewall, why would the risk be common
> to one bridged segment and not a factor in others?
> 
> 	I suspect that the concern you have - if applied to any bridged
> segment connected to an RBridge might apply as well to bridged
segments
> that connect RBridges.  Consequently, it doesn't help to know what the
> "ingress RBridge" is if that can be spoofed by a bad-guy operating in
a
> bridged segment connecting two or more RBridges.
> 
> 	If - in fact - you know that there is a subset of "questionably
> trustworthy" bridged segments, you should isolate them.  Typically
> that would be done at the IP (network) layer.
> 
> 	Also, if you put your bad-guys in a cell, you station a guard on
> the cell, not at all the other doors in the building.
> 
> 	If your intent is to prevent anyone in bridged segment "X" from
> sending anything to bridged segment "Y", (this is a different problem)
> why would you not put them in separate VLANs - thus forcing separation
> and forwarding via a router?
> 
> 	We're not actually trying to replace the routing function, so we
> would be stepping over the bounds to suggest that certain functions we
> currently support using firewalls/gateways/routers should be subsumed
> by RBridges.
> 
> 	If you want to do filtering based on which bridged segment it is
> going to arrive from, why would you do the configuration at
arbitrarily
> many egress RBridges rather than at the corresponding ingress RBridge?
> 
> 	Generally the more places you have to do configuration, the more
> likely a configuration error is to occur.
> 
> 	Why, specifically, would the risk of a single misconfiguration
> error be considered more severe if it effects the entire LAN, when the
> trade off is potentially many such errors effecting many different
> parts of the same LAN in potentially many different ways?
> 
> 	You usually don't want to address risks of misconfiguration
errors
> by introducing more configuration requirements.  Moreover, it is very
> well understood that you don't want to block/drop on egress as you are
> them consuming network resources for frames/packets you will not
deliver.
> 
> --
> Eric
> 
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Friday, October 13, 2006 4:47 PM
> --> To: Radia Perlman; Caitlin Bestler
> --> Cc: [email-masked]
> --> Subject: Re: [rbridge] Range of appllicability (was Re: TTL
> --> only - was RE: New fields in shim header?)
> -->
> --> Radia,
> -->
> --> I will repeat myself,
> -->
> --> Ingress ACLs are much weaker than egress ACLs. A single
> --> misconfigured
> --> port opens the whole network to attack.
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: [email-masked]
> --> [mailto:[email-masked]]
> --> On
> --> > Behalf Of Radia Perlman
> --> > Sent: Friday, October 13, 2006 12:21 PM
> --> > To: Caitlin Bestler
> --> > Cc: [email-masked]
> --> > Subject: Re: [rbridge] Range of appllicability (was Re:
> --> TTL only - was
> --> RE:
> --> > New fields in shim header?)
> --> >
> --> > Caitlin said:
> --> >
> --> > >Given that an RBridge is presumably a single
> --> administrative domain,
> --> > >why would you use the ingress-RBridge to *infer* a class
> --> of service
> --> > >rather than just stating the class of service in the F-Tag?
> --> > >
> --> > I agree that for RBridges, source address filtering is
> --> best done at
> --> the
> --> > ingress RBridge, and that
> --> > our trust model is that RBridges should trust each other
> --> not to forge
> --> > the header fields. So that use
> --> > of ingress RBridge in the shim header doesn't seem too
compelling.
> --> >
> --> > So let's see if the field makes sense for service classes.
> --> >
> --> > It seems like there are two types of classes of service:
> --> > a) those that affect the forwarding decision
> --> > b) those that affect how you handle the packet (as in
> --> priority queue).
> --> >
> --> > ********
> --> > Let's first examine the use of ingress RBridge for the
> --> first type of
> --> > service class:
> --> >
> --> > The simplest forwarding decision is a single forwarding
> --> table, and you
> --> > do a lookup based on destination
> --> > address.
> --> >
> --> > To use F-tags, you'd need a different forwarding table
> --> for each F-tag.
> --> >
> --> > To also base forwarding decisions based on ingress
> --> RBridge, I guess
> --> > you'd need to multiply the
> --> > number of forwarding tables by the number of ingress
> --> RBridges? That
> --> > certainly seems impractical.
> --> > If you trust the ingress RBridge to put in the right
> --> F-tag, it seems
> --> > like you wouldn't need both fields.
> --> >
> --> > *******
> --> > So, that leaves only one rationale I think for ingress
> --> RBridge...which
> --> > is for priority, but the MPLS-like
> --> > header already has a priority field.
> --> >
> --> > The only thing I can think of is that different portions of the
> --> > RBridged-topology would have different
> --> > priorities for different ingress RBridges.
> --> >
> --> > And speaking of filtering...I think my posts to rbridge
> --> aren't getting
> --> > through, or at any rate, have a very
> --> > long delay (as in many hours).
> --> >
> --> > Radia
> --> >
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [email-masked]
> --> > http://mailman.postel.org/mailman/listinfo/rbridge
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

Content-class: urn:content-classes:message
Date: Sun, 15 Oct 2006 18:20:56 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] FTag
Status: RO
Content-Length: 3010

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F0C1.A7852E0D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Another important field proposed in:

http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt

=20

Is the Ftag (see section 3).

=20

Is there any opposition to add this field?

=20

-- Silvano

------_=_NextPart_001_01C6F0C1.A7852E0D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Another important field proposed =
in:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap=
-00.txt">http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-enca=
p-00.txt</a></span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is the Ftag (see section =
3).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is there any opposition to add this =
field?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-- Silvano<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6F0C1.A7852E0D--

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Radia Perlman <[email-masked]>, Caitlin Bestler <[email-masked]>
Date: Fri, 13 Oct 2006 19:27:08 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE:	 New fields in shim header?)
Status: RO
Content-Length: 5821

Silvano,

	I am still having difficulty in understanding why, in a single
layer 2 network (LAN) and in a common administrative domain, we should
be concerned about the possibility of attack from one portion of the
LAN and not be concerned about other portions of the same LAN.

	If you have suspected bad-guys in your LAN, inside the protection
typically provided by a router/firewall, why would the risk be common 
to one bridged segment and not a factor in others?

	I suspect that the concern you have - if applied to any bridged
segment connected to an RBridge might apply as well to bridged segments
that connect RBridges.  Consequently, it doesn't help to know what the
"ingress RBridge" is if that can be spoofed by a bad-guy operating in a
bridged segment connecting two or more RBridges.

	If - in fact - you know that there is a subset of "questionably
trustworthy" bridged segments, you should isolate them.  Typically
that would be done at the IP (network) layer.    

	Also, if you put your bad-guys in a cell, you station a guard on 
the cell, not at all the other doors in the building.

	If your intent is to prevent anyone in bridged segment "X" from
sending anything to bridged segment "Y", (this is a different problem)
why would you not put them in separate VLANs - thus forcing separation 
and forwarding via a router?

	We're not actually trying to replace the routing function, so we
would be stepping over the bounds to suggest that certain functions we
currently support using firewalls/gateways/routers should be subsumed
by RBridges.

	If you want to do filtering based on which bridged segment it is
going to arrive from, why would you do the configuration at arbitrarily
many egress RBridges rather than at the corresponding ingress RBridge?

	Generally the more places you have to do configuration, the more 
likely a configuration error is to occur.  

	Why, specifically, would the risk of a single misconfiguration 
error be considered more severe if it effects the entire LAN, when the 
trade off is potentially many such errors effecting many different 
parts of the same LAN in potentially many different ways?  

	You usually don't want to address risks of misconfiguration errors 
by introducing more configuration requirements.  Moreover, it is very
well understood that you don't want to block/drop on egress as you are 
them consuming network resources for frames/packets you will not deliver.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Friday, October 13, 2006 4:47 PM
--> To: Radia Perlman; Caitlin Bestler
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> Radia,
--> 
--> I will repeat myself,
--> 
--> Ingress ACLs are much weaker than egress ACLs. A single 
--> misconfigured
--> port opens the whole network to attack.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> [mailto:[email-masked]]
--> On
--> > Behalf Of Radia Perlman
--> > Sent: Friday, October 13, 2006 12:21 PM
--> > To: Caitlin Bestler
--> > Cc: [email-masked]
--> > Subject: Re: [rbridge] Range of appllicability (was Re: 
--> TTL only - was
--> RE:
--> > New fields in shim header?)
--> > 
--> > Caitlin said:
--> > 
--> > >Given that an RBridge is presumably a single 
--> administrative domain,
--> > >why would you use the ingress-RBridge to *infer* a class 
--> of service
--> > >rather than just stating the class of service in the F-Tag?
--> > >
--> > I agree that for RBridges, source address filtering is 
--> best done at
--> the
--> > ingress RBridge, and that
--> > our trust model is that RBridges should trust each other 
--> not to forge
--> > the header fields. So that use
--> > of ingress RBridge in the shim header doesn't seem too compelling.
--> > 
--> > So let's see if the field makes sense for service classes.
--> > 
--> > It seems like there are two types of classes of service:
--> > a) those that affect the forwarding decision
--> > b) those that affect how you handle the packet (as in 
--> priority queue).
--> > 
--> > ********
--> > Let's first examine the use of ingress RBridge for the 
--> first type of
--> > service class:
--> > 
--> > The simplest forwarding decision is a single forwarding 
--> table, and you
--> > do a lookup based on destination
--> > address.
--> > 
--> > To use F-tags, you'd need a different forwarding table 
--> for each F-tag.
--> > 
--> > To also base forwarding decisions based on ingress 
--> RBridge, I guess
--> > you'd need to multiply the
--> > number of forwarding tables by the number of ingress 
--> RBridges? That
--> > certainly seems impractical.
--> > If you trust the ingress RBridge to put in the right 
--> F-tag, it seems
--> > like you wouldn't need both fields.
--> > 
--> > *******
--> > So, that leaves only one rationale I think for ingress 
--> RBridge...which
--> > is for priority, but the MPLS-like
--> > header already has a priority field.
--> > 
--> > The only thing I can think of is that different portions of the
--> > RBridged-topology would have different
--> > priorities for different ingress RBridges.
--> > 
--> > And speaking of filtering...I think my posts to rbridge 
--> aren't getting
--> > through, or at any rate, have a very
--> > long delay (as in many hours).
--> > 
--> > Radia
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 17:51:13 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Radia Perlman" <[email-masked]>,  "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1320

Hi Don,

I didn't suggest that 'the world be all Rbridges'. I asked, as a
rhetorical question, what might be bad about replacing all bridges with
Rbridges? Looks like both of us think that people who want to do MPLS
traffic engineering or the like, would look to LSRs or similar devices
rather than either bridges or rbridges.

Donald

PS: In answer to another comment, as far as I can see Rbridges do
support incremental deployment. You can replace your bridges by rbridges
one at a time, if you wish to do so.

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]] 
Sent: Friday, October 13, 2006 2:51 PM
To: Radia Perlman
Cc: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Range of appllicability (was Re: TTL only - was
RE: New fields in shim header?)

Hi Radia 

...

I was referring to the fact that RBridge is more plug and play and
implicitly engineered rather than explicitly engineered.  The way I see
it RBridge creates a topology and does a good job of utilizing that
topology but it is a connectionless view.  So Donald's comment was too
broad in my opinion (IE why isn't the world all RBridge). I'm not
arguing for more engineering in the case of RBridge I'm just saying it
is more like a connectionless IP network. Plug and play with some knobs
for control. 

...

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, "Gray, Eric" <[email-masked]>, Caitlin Bestler <[email-masked]>, Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 16:52:33 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3410

Silvano,

	The project/techniques coming out of 802 committee should
be orthogonal to the work in this WG, in the IETF.  Presumably,
implementors will be able to reconcile their implementations to
more than one set of standards.

	I am aware that you did not suggest using either IPSec or
a subset thereof.  I believe Caitlin brought that up.  I think 
you will discover that we will almost certainly be required to
suggest use of IPSec for at least control plain authentication 
in deployment modes with a trust model requiring authentication.
Similarly, if a requirement for L2 data-plane authentication is
determined, then we will simply adopt what is defined in IEEE.

	I see no particular advantage to making this harder than 
it has to be.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:[email-masked]] 
--> Sent: Friday, October 13, 2006 4:43 PM
--> To: Gray, Eric; Caitlin Bestler; Joe Touch
--> Cc: [email-masked]; Radia Perlman
--> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> Eric,
--> 
--> If you want to support 802, IEEE has authentication 
--> project/techniques
--> different from IPsec. 
--> 
--> I never said that I want IPsec or a subset.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Friday, October 13, 2006 9:58 AM
--> > To: Silvano Gai; Caitlin Bestler; Joe Touch
--> > Cc: [email-masked]; Radia Perlman
--> > Subject: RE: [rbridge] TTL only - was RE: New fields in 
--> shim header?
--> > 
--> > Silvano,
--> > 
--> > 	In this forum, it is a bit risky to argue that any subset of
--> > IPSec authentication is useful - particularly if you can also make
--> > the assumption that IPSec could be used directly.
--> > 
--> > 	The phrase "much more difficult" is not especially meaningful
--> > when what you really need is to distinguish possible and 
--> impossible.
--> > "More difficult" equates to "more challenging" to the 
--> average hacker
--> > and assuming that "more difficult" provides any degree of 
--> protection
--> > is an easy mistake to make.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [email-masked]
--> > --> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> > --> Sent: Thursday, October 12, 2006 4:26 PM
--> > --> To: Caitlin Bestler; Joe Touch
--> > --> Cc: [email-masked]; Radia Perlman
--> > --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
--> header?
--> > -->
--> > --> Catlin,
--> > -->
--> > --> I didn't reply to your last point
--> > -->
--> > --> >
--> > --> > I am assuming there is no desire to replicate IPSEC
--> funcationality
--> > --> > at L2 then *all* of the L2 headers may be forged. I 
--> don't see
--> how
--> > --> > you can claim that any specific one is more trustworthy than
--> > --> > the others.
--> > -->
--> > --> Even without IPsec, RBridges can authenticate to each other
--> > --> and forging
--> > --> an RBridge is much more difficult that using a readily
--> > --> available program
--> > --> on your PC to spoof the IP or MAC address.
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [email-masked]
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
--> 

Date: Fri, 13 Oct 2006 13:53:46 -0700
From: Dinesh G Dutt <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 2546

I can see a few other possibilitites for the use of a source Rbridge field.
- Consider for example, we want to return an error or send a 
notification to the ingress Rbridge from the middle of the network, 
analogous to an ICMP message. With the source RBridge, you know who to 
send it to.
- It allows hardware-based learning
- It assists in network trouble-shooting

Dinesh
Radia Perlman wrote:
> Caitlin said:
>
>   
>> Given that an RBridge is presumably a single administrative domain,
>> why would you use the ingress-RBridge to *infer* a class of service
>> rather than just stating the class of service in the F-Tag?
>>
>>     
> I agree that for RBridges, source address filtering is best done at the 
> ingress RBridge, and that
> our trust model is that RBridges should trust each other not to forge 
> the header fields. So that use
> of ingress RBridge in the shim header doesn't seem too compelling.
>
> So let's see if the field makes sense for service classes.
>
> It seems like there are two types of classes of service:
> a) those that affect the forwarding decision
> b) those that affect how you handle the packet (as in priority queue).
>
> ********
> Let's first examine the use of ingress RBridge for the first type of 
> service class:
>
> The simplest forwarding decision is a single forwarding table, and you 
> do a lookup based on destination
> address.
>
> To use F-tags, you'd need a different forwarding table for each F-tag.
>
> To also base forwarding decisions based on ingress RBridge, I guess 
> you'd need to multiply the
> number of forwarding tables by the number of ingress RBridges? That 
> certainly seems impractical.
> If you trust the ingress RBridge to put in the right F-tag, it seems 
> like you wouldn't need both fields.
>
> *******
> So, that leaves only one rationale I think for ingress RBridge...which 
> is for priority, but the MPLS-like
> header already has a priority field.
>
> The only thing I can think of is that different portions of the 
> RBridged-topology would have different
> priorities for different ingress RBridges.
>
> And speaking of filtering...I think my posts to rbridge aren't getting 
> through, or at any rate, have a very
> long delay (as in many hours).
>
> Radia
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 13:46:47 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 2471

Radia,

I will repeat myself,

Ingress ACLs are much weaker than egress ACLs. A single misconfigured
port opens the whole network to attack.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Friday, October 13, 2006 12:21 PM
> To: Caitlin Bestler
> Cc: [email-masked]
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> Caitlin said:
> 
> >Given that an RBridge is presumably a single administrative domain,
> >why would you use the ingress-RBridge to *infer* a class of service
> >rather than just stating the class of service in the F-Tag?
> >
> I agree that for RBridges, source address filtering is best done at
the
> ingress RBridge, and that
> our trust model is that RBridges should trust each other not to forge
> the header fields. So that use
> of ingress RBridge in the shim header doesn't seem too compelling.
> 
> So let's see if the field makes sense for service classes.
> 
> It seems like there are two types of classes of service:
> a) those that affect the forwarding decision
> b) those that affect how you handle the packet (as in priority queue).
> 
> ********
> Let's first examine the use of ingress RBridge for the first type of
> service class:
> 
> The simplest forwarding decision is a single forwarding table, and you
> do a lookup based on destination
> address.
> 
> To use F-tags, you'd need a different forwarding table for each F-tag.
> 
> To also base forwarding decisions based on ingress RBridge, I guess
> you'd need to multiply the
> number of forwarding tables by the number of ingress RBridges? That
> certainly seems impractical.
> If you trust the ingress RBridge to put in the right F-tag, it seems
> like you wouldn't need both fields.
> 
> *******
> So, that leaves only one rationale I think for ingress RBridge...which
> is for priority, but the MPLS-like
> header already has a priority field.
> 
> The only thing I can think of is that different portions of the
> RBridged-topology would have different
> priorities for different ingress RBridges.
> 
> And speaking of filtering...I think my posts to rbridge aren't getting
> through, or at any rate, have a very
> long delay (as in many hours).
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 13:43:15 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2057

Eric,

If you want to support 802, IEEE has authentication project/techniques
different from IPsec. 

I never said that I want IPsec or a subset.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 13, 2006 9:58 AM
> To: Silvano Gai; Caitlin Bestler; Joe Touch
> Cc: [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> Silvano,
> 
> 	In this forum, it is a bit risky to argue that any subset of
> IPSec authentication is useful - particularly if you can also make
> the assumption that IPSec could be used directly.
> 
> 	The phrase "much more difficult" is not especially meaningful
> when what you really need is to distinguish possible and impossible.
> "More difficult" equates to "more challenging" to the average hacker
> and assuming that "more difficult" provides any degree of protection
> is an easy mistake to make.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Thursday, October 12, 2006 4:26 PM
> --> To: Caitlin Bestler; Joe Touch
> --> Cc: [email-masked]; Radia Perlman
> --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
header?
> -->
> --> Catlin,
> -->
> --> I didn't reply to your last point
> -->
> --> >
> --> > I am assuming there is no desire to replicate IPSEC
funcationality
> --> > at L2 then *all* of the L2 headers may be forged. I don't see
how
> --> > you can claim that any specific one is more trustworthy than
> --> > the others.
> -->
> --> Even without IPsec, RBridges can authenticate to each other
> --> and forging
> --> an RBridge is much more difficult that using a readily
> --> available program
> --> on your PC to spoof the IP or MAC address.
> -->
> --> -- Silvano
> -->
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 13:40:16 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 4697

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 13, 2006 9:43 AM
> To: Silvano Gai; Caitlin Bestler; Joe Touch
> Cc: [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 
> --- [SNIP] ---
> -->
> --> The issue is not Rogue RBridges, the issue is that in a network
there
> --> will be RBridges that will connect unsecured hosts/links and the
> network
> --> manager may desire an easy way to restrict them to a subset of the
> TRILL
> --> cloud.
> 
> Do you have a real deployment example in which an enterprise
> would not use firewalls and/or routers to protect an entire
> LAN but would use bridges to protect portions of it?

Enterprise uses any possible combination of Firewall, Routers, ACL at
the 5-tuple layers, VLANs, ACL at the MAC address layer and whatever
else you give them to protect their network. I have seen many large
networks and even if there are similarities, nobody does it exactly the
same way. 

Ingress / Egress RBridge address filtering is just a tool, as many
others to empower some network managers. Will it solve all the security
problems? NO.
Will it be used in several deployments? YES.

Of course, if we design the encapsulation so that it is not supported,
it cannot be done! Why do you want to preclude it?

Moreover when you have the ingress Rbridge address you can start to do
other things, as was observed in other emails, like policy forwarding.

-- Silvano

> 
> This does not sound very practical to me.
> 
> In addition - if you don't filter at an ingress, and it is
> possible to spoof the inner source MAC address - how is it
> useful to filter based on the ingress and egress RBridge at
> any point other than the ingress?  If you do, you are only
> saying that any traffic arriving from bridged segment "X"
> is not allowed to be delivered to bridged segment "Y" and -
> if that is what you want to do, there are better ways to do
> it than to use ACLs on a bridge (or RBridge).
> 
> -->
> --> > a larger shim header to optimize dropping their packets then
> --> > things are in a pretty bad shape. If there are network elements
> --> > that cannot ultimately be physically disconnected by the network
> --> > administrator then they should probably be separated by a router
> --> > and not included in the subnet.
> -->
> --> In today world, any tool you can give a network administrator to
> --> segregate traffic is welcomed.
> 
> I'd like to hear that directly from a network administrator.  There
> are practical limits to the capacity of their "tool belt" and more
> tools means even more administration/management complexity.
> 
> -->
> --> >
> --> > And given that any RBRidge header is not going to have IPSEC
> --> > quality authentication the degree to which we can provide
> --> > protection from a malicious RBridge is fundamentally limited.
> --> >
> --> > Let's be realistic and keep security at the IP layer.
> -->
> --> This is IEEE 802.1D replacement, there may not be an IP layer.
> 
> The request was "let's be realistic."  The statement that "there
> may not be an IP layer" is a significant departure from realism,
> in today's networks.
> 
> -->
> -->
> --> > The originally proposed short envelope solves the
> --> > essential problems. The additional fields that Radia's
> --> > recent draft suggested are all interesting. Many of
> --> > them MIGHT help RBridges perform certain functions
> --> > more efficiently. But I do not believe any of the
> --> > extra fields are necessary, and my initial thought
> --> > is that they do not justify eating away at the MTU.
> -->
> --> I am much more concerned that TRILL will provide a superset of
> --> the functionalities that 802.1D and all its variations provide,
> --> than saving few bytes in the shim headers. I think the times
> --> where optimizing to the last byte was important are long gone
> --> with 1 and 10 GE.
> 
> Herein lies the disconnect.  Attempting to support every variation
> of 802.1D in specifications produced by this WG is a non-starter.
> 
> We therefore have to decide what is, and is not, in scope.
> 
> Since there are certainly existance proofs of tunneling technologies
> that do not retain all of the information of the tunneled data in an
> "outer" (tunneling) encapsulation (indeed, what would be the point
> of tunneling otherwise), then it is completely legitimate to state
> that this is out of scope.
> 
> -->
> --> -- Silvano
> -->
> -->
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 13:32:44 -0700
From: "Silvano Gai" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 6546

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Friday, October 13, 2006 9:08 AM
> To: Silvano Gai; Joe Touch
> Cc: [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> Silvano,
> 
> 	You (re)make Joe's point, I believe.  It _is_ easy to
> spoof a MAC address.   So it gains us nothing to attempt to
> incorporate a source-MAC mapping in the outer encapsulation.

I never proposed that.

> On the other hand, if you're talking about filtering based
> on the _ingress_ and _egress_ RBridges, there's no reasonable
> application for this.
> 

IMHO, there is.

-- Silvano

> 	If you cannot trust the ingress and egress RBridges in
> your own administrative domain, then you should expect them
> to be able to overcome this "filtering" through spoofing (as
> Joe said already).
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]] On Behalf Of Silvano Gai
> --> Sent: Thursday, October 12, 2006 12:14 PM
> --> To: Joe Touch
> --> Cc: [email-masked]; Radia Perlman
> --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim
header?
> -->
> -->
> -->
> --> -----Original Message-----
> --> From: Joe Touch [mailto:[email-masked]]
> --> Sent: Thursday, October 12, 2006 8:55 AM
> --> To: Silvano Gai
> --> Cc: Radia Perlman; [email-masked]
> --> Subject: Re: TTL only - was RE: [rbridge] New fields in shim
header?
> -->
> -->
> -->
> --> Silvano Gai wrote:
> --> > In today Ethernet I can write an ACL on the pair Source, Dest
MAC
> --> > address, and many network managers find this extremely
> --> useful, but I
> --> > will not be able to do that on the RBridge addresses, if
> --> I have only
> --> > one.
> --> >
> --> > When an RBdridge receives a unicast frame, with the
> --> current proposal
> --> it
> --> > cannot screen it according to the ingress RBridge and
> --> this is a big
> --> > security hole.
> -->
> --> That's trivial to spoof,
> -->
> --> Is it?  You need to emulate an RBridge to be able to spoof
> --> the RBridge
> --> address. This includes passing all the link negotiation, bringing
up
> --> ISIS, passing the security test of ISIS. I will say it is
> --> much harder
> --> that spoofing a MAC address or an IP address.
> -->
> --> Agreed?
> -->
> --> -- Silvano
> -->
> -->
> -->
> --> so it's not a security issue per se. If there
> --> is any filtering based on an address, it ought to be at the inner
> --> address (which is already paired) anyway. If this is just
> --> for ACLs, it
> --> seems like a thin reason.
> -->
> --> > An Rbridge needs to be able to drop traffic originated by
> --> > another RBridge: this requires two addresses.
> --> >
> --> > IMHO addresses come in pair, I am not aware of a
> --> successful protocol
> --> > that has a single address.
> --> >
> --> > -- Silvano
> --> >
> --> >
> --> > -----Original Message-----
> --> > From: Joe Touch [mailto:[email-masked]]
> --> > Sent: Thursday, October 12, 2006 7:30 AM
> --> > To: Silvano Gai
> --> > Cc: Radia Perlman; [email-masked]
> --> > Subject: Re: TTL only - was RE: [rbridge] New fields in
> --> shim header?
> --> >
> --> >
> --> >
> --> > Silvano Gai wrote:
> --> >> OK,
> --> >> Let's restrict the discussion to IEEE 802.1-compliant Ethernet
> --> > networks.
> --> >> Today the outer header contains:
> --> >>
> --> >>    o  L2 destination = next RBridge, or for flooded
> --> frames, a new (to
> --> > be
> --> >>       assigned) multicast layer 2 address meaning "all
RBridges"
> --> >>
> --> >>    o  L2 source = transmitting RBridge (the one that
> --> most recently
> --> >>       handled this frame)
> --> >>
> --> >> If we want to avoid carrying the egress RBridge address
> --> in the shim
> --> >> header, we need to put it in the outer header - L2 destination.
> --> >
> --> > The reason for the single shim rbridge address is a
> --> tradeoff, to avoid
> --> > populating the inner rbridge nodes with complete ingress tables.
> --> That's
> --> > a trade-off rather than a requirement.
> --> >
> --> > If we went with strict minimalism, we could avoid the
> --> need for that
> --> > field; I understand the desire to avoid populating every node
with
> --> full
> --> > tables, though. So I'll update my earlier note and add the
single
> --> > desination/mulitcast source address field, as per the
> --> protocol doc.
> --> >
> --> > As we go beyond that minimal requirement, we're starting to add
> --> > capability that looks more like IP than ethernet. IMO,
> --> rbridges should
> --> > support what ethernet supports, not necessarily what IP
> --> is capable of.
> --> > If you want IP, use IP.
> --> >
> --> > Joe
> --> >
> --> >> -----Original Message-----
> --> >> From: Joe Touch [mailto:[email-masked]]
> --> >> Sent: Thursday, October 12, 2006 7:07 AM
> --> >> To: Silvano Gai
> --> >> Cc: Radia Perlman; [email-masked]
> --> >> Subject: Re: TTL only - was RE: [rbridge] New fields in
> --> shim header?
> --> >>
> --> >>
> --> >>
> --> >> Silvano Gai wrote:
> --> >>> Joe,
> --> >>>
> --> >>> Let me focus on the need of RBridge addresses.
> --> >>>
> --> >>> I didn't propose them; they are in the current WG draft:
> --> >>>
> --> >
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -protocol-00
> --> >>> .txt
> --> >>> to achieve scalability at the ISIS level.
> --> >>>
> --> >>> The outer MAC addresses are present only if the frame
> --> is sent over
> --> > 802
> --> >>> link (section 2.9), but it may not be present on other media;
> --> >> therefore
> --> >>> TRILL cannot rely on them.
> --> >>>
> --> >>> If you disagree with these two points, I think you
> --> disagree with the
> --> >>> work that has been done in TRILL till now.
> --> >> I agree with the charter, which limits us to specifying
solutions
> --> that
> --> >> work on 802.1 nets:
> --> >>
> --> >> ---
> --> >> The TRILL WG will design a solution for shortest-path
> --> frame routing
> --> in
> --> >> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
> --> >> topologies, using an existing link-state routing
> --> protocol technology.
> --> >> ---
> --> >>
> --> >> The fact that the architecture discusses other links is OK;
it's
> --> >> informational anyway.
> --> >>
> --> >> Joe
> --> >>
> --> >
> -->
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 12:56:13 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 2953

I read the draft to understand the specification of F-tag, and here's
what it reads 

===========
The Forwarding Tag (FTag) identifies the forwarding topology assigned to
a given frame. In current enterprise networks, for a given frame it is
possible to pick from multiple topologies on which the frame can be
forwarded. 
<snip>
===========

If there's a choice of multiple topologies to forward the packet on, and
if that choice is to be made by the source-rbridge, and if subsequent
rbridges should forward the packet along that chosen topology, THEN

rest of the rbridges would need something (during the forwarding
decision) to idenfity what choice was made at the source-rbridge. 

Is that (or isnt that) one of the purpose of having FTAG ?

-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Friday, October 13, 2006 12:21 PM
To: Caitlin Bestler
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE: New fields in shim header?)

Caitlin said:

>Given that an RBridge is presumably a single administrative domain, why

>would you use the ingress-RBridge to *infer* a class of service rather 
>than just stating the class of service in the F-Tag?
>
I agree that for RBridges, source address filtering is best done at the
ingress RBridge, and that our trust model is that RBridges should trust
each other not to forge the header fields. So that use of ingress
RBridge in the shim header doesn't seem too compelling.

So let's see if the field makes sense for service classes.

It seems like there are two types of classes of service:
a) those that affect the forwarding decision
b) those that affect how you handle the packet (as in priority queue).

********
Let's first examine the use of ingress RBridge for the first type of
service class:

The simplest forwarding decision is a single forwarding table, and you
do a lookup based on destination address.

To use F-tags, you'd need a different forwarding table for each F-tag.

To also base forwarding decisions based on ingress RBridge, I guess
you'd need to multiply the number of forwarding tables by the number of
ingress RBridges? That certainly seems impractical.
If you trust the ingress RBridge to put in the right F-tag, it seems
like you wouldn't need both fields.

*******
So, that leaves only one rationale I think for ingress RBridge...which
is for priority, but the MPLS-like header already has a priority field.

The only thing I can think of is that different portions of the
RBridged-topology would have different priorities for different ingress
RBridges.

And speaking of filtering...I think my posts to rbridge aren't getting
through, or at any rate, have a very long delay (as in many hours).

Radia

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>
Date: Fri, 13 Oct 2006 15:42:24 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE:	 New fields in shim header?)
Status: RO
Content-Length: 2820

Radia,

	I've noticed the same with mine.  This results in serious
problems with posts that "cross in the mail." 

	I believe it may be because the mailing list server - not
being accustomed to seeing a single posting in a period of less
than a month - has been overcome by the recent posting volume.

	:-)

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Friday, October 13, 2006 3:21 PM
--> To: Caitlin Bestler
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> Caitlin said:
--> 
--> >Given that an RBridge is presumably a single administrative domain,
--> >why would you use the ingress-RBridge to *infer* a class of service
--> >rather than just stating the class of service in the F-Tag?
--> >
--> I agree that for RBridges, source address filtering is best 
--> done at the 
--> ingress RBridge, and that
--> our trust model is that RBridges should trust each other 
--> not to forge 
--> the header fields. So that use
--> of ingress RBridge in the shim header doesn't seem too compelling.
--> 
--> So let's see if the field makes sense for service classes.
--> 
--> It seems like there are two types of classes of service:
--> a) those that affect the forwarding decision
--> b) those that affect how you handle the packet (as in 
--> priority queue).
--> 
--> ********
--> Let's first examine the use of ingress RBridge for the 
--> first type of 
--> service class:
--> 
--> The simplest forwarding decision is a single forwarding 
--> table, and you 
--> do a lookup based on destination
--> address.
--> 
--> To use F-tags, you'd need a different forwarding table for 
--> each F-tag.
--> 
--> To also base forwarding decisions based on ingress RBridge, I guess 
--> you'd need to multiply the
--> number of forwarding tables by the number of ingress RBridges? That 
--> certainly seems impractical.
--> If you trust the ingress RBridge to put in the right F-tag, 
--> it seems 
--> like you wouldn't need both fields.
--> 
--> *******
--> So, that leaves only one rationale I think for ingress 
--> RBridge...which 
--> is for priority, but the MPLS-like
--> header already has a priority field.
--> 
--> The only thing I can think of is that different portions of the 
--> RBridged-topology would have different
--> priorities for different ingress RBridges.
--> 
--> And speaking of filtering...I think my posts to rbridge 
--> aren't getting 
--> through, or at any rate, have a very
--> long delay (as in many hours).
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 13 Oct 2006 12:20:41 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1751

Caitlin said:

>Given that an RBridge is presumably a single administrative domain,
>why would you use the ingress-RBridge to *infer* a class of service
>rather than just stating the class of service in the F-Tag?
>
I agree that for RBridges, source address filtering is best done at the 
ingress RBridge, and that
our trust model is that RBridges should trust each other not to forge 
the header fields. So that use
of ingress RBridge in the shim header doesn't seem too compelling.

So let's see if the field makes sense for service classes.

It seems like there are two types of classes of service:
a) those that affect the forwarding decision
b) those that affect how you handle the packet (as in priority queue).

********
Let's first examine the use of ingress RBridge for the first type of 
service class:

The simplest forwarding decision is a single forwarding table, and you 
do a lookup based on destination
address.

To use F-tags, you'd need a different forwarding table for each F-tag.

To also base forwarding decisions based on ingress RBridge, I guess 
you'd need to multiply the
number of forwarding tables by the number of ingress RBridges? That 
certainly seems impractical.
If you trust the ingress RBridge to put in the right F-tag, it seems 
like you wouldn't need both fields.

*******
So, that leaves only one rationale I think for ingress RBridge...which 
is for priority, but the MPLS-like
header already has a priority field.

The only thing I can think of is that different portions of the 
RBridged-topology would have different
priorities for different ingress RBridges.

And speaking of filtering...I think my posts to rbridge aren't getting 
through, or at any rate, have a very
long delay (as in many hours).

Radia

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 11:57:42 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1616

[email-masked] wrote:
> Don Fedyk wrote:
> 
>> 
>> I think this is an oversimplifying statement. Rbridge leverages link
>> state for better plug and play use of network topologies.  This
>> fucntion is superior to STP or RSTP. But if you are engineering the
>> bridged network there are other options besides STP/RSTP and I don't
>> see these capabilities in Rbridge.
>> 
> Does your comment relate to the extra potential fields? There
> are two of the proposed fields that I could imagine would
> enable engineering the network: F-tag and ingress RBridge.
> 
> I'd imagine that the F-tag would enable
> engineering of the paths to dynamically choose different
> types of paths based on different types of traffic.
> 
> And the ingress-RBridge (for unicast traffic) could also be
> used to choose paths based not just on destination address,
> but source RBridge (some favored portion of the net hanging
> off RBridge R1).
> The mailing list discussion (as much as I could follow) seems
> to assume that ingress RBridge is for filtering spoofed
> source address, but I agree that use of it would be better
> done by trusting all the RBridges and letting the first
> RBridge discard spoofed packets. However, a different use of
> ingress RBridge could be for choosing paths based not just on
> egress but also on ingress RBridge.
> 
> So, would these two fields help for providing engineering of paths?
> 

Given that an RBridge is presumably a single administrative domain,
why would you use the ingress-RBridge to *infer* a class of service
rather than just stating the class of service in the F-Tag?

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 14:51:23 -0400
From: "Don Fedyk" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 2532

Hi Radia 

> -----Original Message-----
> 
> 
> Don Fedyk wrote:
> 
> >
> >I think this is an oversimplifying statement. RBridge leverages link 
> >state for better plug and play use of network topologies.  This 
> >fucntion is superior to STP or RSTP. But if you are engineering the 
> >bridged network there are other options besides STP/RSTP and I don't 
> >see these capabilities in RBridge.
> >
> Does your comment relate to the extra potential fields? There 
> are two of the proposed fields that I could imagine would 
> enable engineering the network: F-tag and ingress RBridge.

I was referring to the fact that RBridge is more plug and play and
implicitly engineered rather than explicitly engineered.  The way I see
it RBridge creates a topology and does a good job of utilizing that
topology but it is a connectionless view.  So Donald's comment was too
broad in my opinion (IE why isn't the world all RBridge). I'm not
arguing for more engineering in the case of RBridge I'm just saying it
is more like a connectionless IP network. Plug and play with some knobs
for control. 

Myself and some others are working on means to explicitly engineer
Ethernet traffic but we find that engineering bridged networks exists to
a degree with combinations of static assigned paths and these
technologies can make use of all links. What I'm working on is more
analogous to MPLS and no I'm not arguing that it should be applied to
all bridged networks it is too big a hammer for many situations. 

> 
> I'd imagine that the F-tag would enable
> engineering of the paths to dynamically choose different 
> types of paths based on different types of traffic.

Like Diff serv? Yes but this is with in the connectionless topology
context. 

> 
> And the ingress-RBridge (for unicast traffic) could also be 
> used to choose paths based not just on destination address, 
> but source RBridge (some favored portion of the net hanging 
> off RBridge R1).
Like an ECMP algorithm. Again within the connectionless context. 

Regards,
Don 

> The mailing list discussion (as much as I could follow) seems 
> to assume that ingress RBridge is for filtering spoofed 
> source address, but I agree that use of it would be better 
> done by trusting all the RBridges and letting the first 
> RBridge discard spoofed packets. However, a different use of 
> ingress RBridge could be for choosing paths based not just on 
> egress but also on ingress RBridge.
> 
> So, would these two fields help for providing engineering of paths?
> 
> Radia
> 
> 

Date: Fri, 13 Oct 2006 11:01:23 -0700
From: Radia Perlman <[email-masked]>
To: Don Fedyk <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1337

Don Fedyk wrote:

>
>I think this is an oversimplifying statement. Rbridge leverages link
>state for better plug and play use of network topologies.  This fucntion
>is superior to STP or RSTP. But if you are engineering the bridged
>network there are other options besides STP/RSTP and I don't see these
>capabilities in Rbridge.
>
Does your comment relate to the extra potential fields? There are two of 
the proposed fields
that I could imagine would enable engineering the network: F-tag and 
ingress RBridge.

I'd imagine that the F-tag would enable
engineering of the paths to dynamically choose different types of paths 
based on different types
of traffic.

And the ingress-RBridge (for unicast traffic) could also be used to 
choose paths based not just on
destination address, but source RBridge (some favored portion of the net 
hanging off RBridge R1).
The mailing list discussion (as much as I could follow) seems to assume 
that ingress RBridge is for
filtering spoofed source address, but I agree that use of it would be 
better done by trusting all the RBridges
and letting the first RBridge discard spoofed packets. However, a 
different use of ingress RBridge could
be for choosing paths based not just on egress but also on ingress RBridge.

So, would these two fields help for providing engineering of paths?

Radia

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 13:05:45 -0400
From: "Don Fedyk" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 680

Hi Donald 

> -----Original Message-----
> 
> Hi,
>  
> Why not ask the question the other way? If Rbridges exist, 
> why would anyone want to use an old fashioned STP or RSTP 
> based bridge?  :-) Simplifying a lot, Rbridges make better 
> use of available links while various forms of spanning tree 
> work by turning off and thus wasting links. 

I think this is an oversimplifying statement. Rbridge leverages link
state for better plug and play use of network topologies.  This fucntion
is superior to STP or RSTP. But if you are engineering the bridged
network there are other options besides STP/RSTP and I don't see these
capabilities in Rbridge. 

Regards,
Don 

<snip>

From: "Gray, Eric" <[email-masked]>
To: Caitlin Bestler <[email-masked]>, Silvano Gai <[email-masked]>, Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 13:04:09 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1629

Caitlin,

Agree.

The thing to remember here is that RBridges on essentially intra-LAN
devices.  The point at which it makes sense to do authentication is
on entry to the LAN - either from a top-down view of protocol-stack 
traversal, or from a perspective of peer-to-peer traversal of routers 
and/or firewalls.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
--> Sent: Thursday, October 12, 2006 4:37 PM
--> To: Silvano Gai; Joe Touch
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> Silvano Gai wrote:
--> > Catlin,
--> > 
--> > I didn't reply to your last point
--> > 
--> >> 
--> >> I am assuming there is no desire to replicate IPSEC funcationality
--> >> at L2 then *all* of the L2 headers may be forged. I don't see how
--> >> you can claim that any specific one is more trustworthy than the
--> >> others.
--> > 
--> > Even without IPsec, RBridges can authenticate to each other
--> > and forging an RBridge is much more difficult that using a
--> > readily available program on your PC to spoof the IP or 
--> > MAC address.
--> > 
--> > -- Silvano
--> 
--> I wouldn't be surprised if RBridges ending up authenticating
--> to each other as part of fabric discovery. But clearly there
--> will be no high quality authentication applied at L2 on a 
--> per packet basis.
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Caitlin Bestler <[email-masked]>, Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 12:58:26 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1535

Silvano,

	In this forum, it is a bit risky to argue that any subset of
IPSec authentication is useful - particularly if you can also make
the assumption that IPSec could be used directly. 

	The phrase "much more difficult" is not especially meaningful
when what you really need is to distinguish possible and impossible.
"More difficult" equates to "more challenging" to the average hacker
and assuming that "more difficult" provides any degree of protection
is an easy mistake to make.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Thursday, October 12, 2006 4:26 PM
--> To: Caitlin Bestler; Joe Touch
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> Catlin,
--> 
--> I didn't reply to your last point
--> 
--> > 
--> > I am assuming there is no desire to replicate IPSEC funcationality
--> > at L2 then *all* of the L2 headers may be forged. I don't see how
--> > you can claim that any specific one is more trustworthy than
--> > the others.
--> 
--> Even without IPsec, RBridges can authenticate to each other 
--> and forging
--> an RBridge is much more difficult that using a readily 
--> available program
--> on your PC to spoof the IP or MAC address.
--> 
--> -- Silvano
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Caitlin Bestler <[email-masked]>, Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 12:52:50 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1719

Silvano,

	Any tunneling technology introduces overhead, resulting in
reduced forwarding efficiency - in terms of content verses packet
(or frame) size.

	If you can put less content in a frame, then you may have
to send more frames to transfer the same content.

	It's theoretically true that - in developing a new approach
- you might assume that you could enlarge frame sizes to eliminate
the "cost" of the additional over-head.  Practically, this is not
true.

	In the RBridge case, it is possible to have 802-1D devices
between RBridges.  Consequently, it is an error to assume that we
can define any frame size we want.  In addition, changing anything
arbitrarily has the additional complication of potentially making
it necessary to re-spin hardware components that might otherwise
be used off-the-shelf.

--
Eric  

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Thursday, October 12, 2006 4:17 PM
--> To: Caitlin Bestler; Joe Touch
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> Caitlin,
--> 
--> See below
--> 
--> ...
--> 
--> > 
--> > And as we all know the probability of MsgSize having been
--> > crafted so the MsgSize % n is zero is all too high. So the
--> > more we add to the header, the more IP datagrams will be
--> > required to send the same traffic. 
--> 
--> I had the impression that TRILL was increasing the frame size on the
--> encapsulated size, not MTU reduction at the IP level. The 
--> fact that we
--> add few bytes more or less impacts performance, but not number of IP
--> datagram.
--> 
--> -- Silvano

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Caitlin Bestler <[email-masked]>, Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 12:42:52 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3476

--- [SNIP] ---
--> 
--> The issue is not Rogue RBridges, the issue is that in a network there
--> will be RBridges that will connect unsecured hosts/links and the network
--> manager may desire an easy way to restrict them to a subset of the TRILL
--> cloud.

Do you have a real deployment example in which an enterprise 
would not use firewalls and/or routers to protect an entire
LAN but would use bridges to protect portions of it?

This does not sound very practical to me.

In addition - if you don't filter at an ingress, and it is 
possible to spoof the inner source MAC address - how is it
useful to filter based on the ingress and egress RBridge at
any point other than the ingress?  If you do, you are only
saying that any traffic arriving from bridged segment "X" 
is not allowed to be delivered to bridged segment "Y" and -
if that is what you want to do, there are better ways to do
it than to use ACLs on a bridge (or RBridge).

--> 
--> > a larger shim header to optimize dropping their packets then
--> > things are in a pretty bad shape. If there are network elements
--> > that cannot ultimately be physically disconnected by the network
--> > administrator then they should probably be separated by a router
--> > and not included in the subnet.
--> 
--> In today world, any tool you can give a network administrator to
--> segregate traffic is welcomed.

I'd like to hear that directly from a network administrator.  There
are practical limits to the capacity of their "tool belt" and more
tools means even more administration/management complexity.

--> 
--> > 
--> > And given that any RBRidge header is not going to have IPSEC
--> > quality authentication the degree to which we can provide
--> > protection from a malicious RBridge is fundamentally limited.
--> > 
--> > Let's be realistic and keep security at the IP layer.
--> 
--> This is IEEE 802.1D replacement, there may not be an IP layer.

The request was "let's be realistic."  The statement that "there
may not be an IP layer" is a significant departure from realism,
in today's networks.

--> 
--> 
--> > The originally proposed short envelope solves the
--> > essential problems. The additional fields that Radia's
--> > recent draft suggested are all interesting. Many of
--> > them MIGHT help RBridges perform certain functions
--> > more efficiently. But I do not believe any of the
--> > extra fields are necessary, and my initial thought
--> > is that they do not justify eating away at the MTU.
--> 
--> I am much more concerned that TRILL will provide a superset of
--> the functionalities that 802.1D and all its variations provide, 
--> than saving few bytes in the shim headers. I think the times 
--> where optimizing to the last byte was important are long gone 
--> with 1 and 10 GE.

Herein lies the disconnect.  Attempting to support every variation
of 802.1D in specifications produced by this WG is a non-starter.

We therefore have to decide what is, and is not, in scope.

Since there are certainly existance proofs of tunneling technologies
that do not retain all of the information of the tunneled data in an
"outer" (tunneling) encapsulation (indeed, what would be the point
of tunneling otherwise), then it is completely legitimate to state
that this is out of scope.

--> 
--> -- Silvano
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 09:43:03 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1445

[email-masked] wrote:
> Hi,
> 
> Why not ask the question the other way? If Rbridges exist,
> why would anyone want to use an old fashioned STP or RSTP
> based bridge?  :-) Simplifying a lot, Rbridges make better
> use of available links while various forms of spanning tree
> work by turning off and thus wasting links.
> 
> Of course there are some reasons, like Rbridges probably
> require greater computational resources and bandwidth for
> routing messages. But as computation gets cheaper and link
> bandwidth keeps rising, these factors become less significant...
> 
> While I suppose this is all an interesting discussion, I
> personally don't think it actually has much effect on the
> Rbridge specification. As long as rbridges are to be
> applicable where high end bridges are currently used, then
> they need to be able to support VLANs, optimize multicast,
> etc. Whether or not they are beneficial where mid or lower
> range bridges are used seems less important.
> 
> Donald
> 

At the minimum there is the need for phased deployment.
I doubt there are many sites that would agree to bring
the entire subnet down so that every existing bridge
can be replaced instantly.

RBRidges can also make sense to provide a large campus wide
network connecting many departments/floors/rooms (not just
racks in a data center). In a campus deployment I suspect
that conventional Bridges will be around at least as long
as IPv4.

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>, Joe Touch <[email-masked]>
Date: Fri, 13 Oct 2006 12:08:28 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 5894

Silvano,

	You (re)make Joe's point, I believe.  It _is_ easy to
spoof a MAC address.   So it gains us nothing to attempt to
incorporate a source-MAC mapping in the outer encapsulation.
On the other hand, if you're talking about filtering based
on the _ingress_ and _egress_ RBridges, there's no reasonable
application for this.

	If you cannot trust the ingress and egress RBridges in
your own administrative domain, then you should expect them 
to be able to overcome this "filtering" through spoofing (as
Joe said already).

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Silvano Gai
--> Sent: Thursday, October 12, 2006 12:14 PM
--> To: Joe Touch
--> Cc: [email-masked]; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> 
--> -----Original Message-----
--> From: Joe Touch [mailto:[email-masked]] 
--> Sent: Thursday, October 12, 2006 8:55 AM
--> To: Silvano Gai
--> Cc: Radia Perlman; [email-masked]
--> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
--> 
--> 
--> 
--> Silvano Gai wrote:
--> > In today Ethernet I can write an ACL on the pair Source, Dest MAC
--> > address, and many network managers find this extremely 
--> useful, but I
--> > will not be able to do that on the RBridge addresses, if 
--> I have only
--> > one.
--> >
--> > When an RBdridge receives a unicast frame, with the 
--> current proposal
--> it
--> > cannot screen it according to the ingress RBridge and 
--> this is a big
--> > security hole.
--> 
--> That's trivial to spoof, 
--> 
--> Is it?  You need to emulate an RBridge to be able to spoof 
--> the RBridge
--> address. This includes passing all the link negotiation, bringing up
--> ISIS, passing the security test of ISIS. I will say it is 
--> much harder
--> that spoofing a MAC address or an IP address.
--> 
--> Agreed?
--> 
--> -- Silvano
--> 
--> 
--> 
--> so it's not a security issue per se. If there
--> is any filtering based on an address, it ought to be at the inner
--> address (which is already paired) anyway. If this is just 
--> for ACLs, it
--> seems like a thin reason.
--> 
--> > An Rbridge needs to be able to drop traffic originated by
--> > another RBridge: this requires two addresses.
--> > 
--> > IMHO addresses come in pair, I am not aware of a 
--> successful protocol
--> > that has a single address.
--> > 
--> > -- Silvano
--> > 
--> > 
--> > -----Original Message-----
--> > From: Joe Touch [mailto:[email-masked]] 
--> > Sent: Thursday, October 12, 2006 7:30 AM
--> > To: Silvano Gai
--> > Cc: Radia Perlman; [email-masked]
--> > Subject: Re: TTL only - was RE: [rbridge] New fields in 
--> shim header?
--> > 
--> > 
--> > 
--> > Silvano Gai wrote:
--> >> OK,
--> >> Let's restrict the discussion to IEEE 802.1-compliant Ethernet
--> > networks.
--> >> Today the outer header contains: 
--> >>
--> >>    o  L2 destination = next RBridge, or for flooded 
--> frames, a new (to
--> > be
--> >>       assigned) multicast layer 2 address meaning "all RBridges" 
--> >>
--> >>    o  L2 source = transmitting RBridge (the one that 
--> most recently 
--> >>       handled this frame)
--> >>
--> >> If we want to avoid carrying the egress RBridge address 
--> in the shim
--> >> header, we need to put it in the outer header - L2 destination.
--> > 
--> > The reason for the single shim rbridge address is a 
--> tradeoff, to avoid
--> > populating the inner rbridge nodes with complete ingress tables.
--> That's
--> > a trade-off rather than a requirement.
--> > 
--> > If we went with strict minimalism, we could avoid the 
--> need for that
--> > field; I understand the desire to avoid populating every node with
--> full
--> > tables, though. So I'll update my earlier note and add the single
--> > desination/mulitcast source address field, as per the 
--> protocol doc.
--> > 
--> > As we go beyond that minimal requirement, we're starting to add
--> > capability that looks more like IP than ethernet. IMO, 
--> rbridges should
--> > support what ethernet supports, not necessarily what IP 
--> is capable of.
--> > If you want IP, use IP.
--> > 
--> > Joe
--> > 
--> >> -----Original Message-----
--> >> From: Joe Touch [mailto:[email-masked]] 
--> >> Sent: Thursday, October 12, 2006 7:07 AM
--> >> To: Silvano Gai
--> >> Cc: Radia Perlman; [email-masked]
--> >> Subject: Re: TTL only - was RE: [rbridge] New fields in 
--> shim header?
--> >>
--> >>
--> >>
--> >> Silvano Gai wrote:
--> >>> Joe,
--> >>>
--> >>> Let me focus on the need of RBridge addresses.
--> >>>
--> >>> I didn't propose them; they are in the current WG draft:
--> >>>
--> >
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -protocol-00
--> >>> .txt
--> >>> to achieve scalability at the ISIS level.
--> >>>
--> >>> The outer MAC addresses are present only if the frame 
--> is sent over
--> > 802
--> >>> link (section 2.9), but it may not be present on other media;
--> >> therefore
--> >>> TRILL cannot rely on them.
--> >>>
--> >>> If you disagree with these two points, I think you 
--> disagree with the
--> >>> work that has been done in TRILL till now.
--> >> I agree with the charter, which limits us to specifying solutions
--> that
--> >> work on 802.1 nets:
--> >>
--> >> ---
--> >> The TRILL WG will design a solution for shortest-path 
--> frame routing
--> in
--> >> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
--> >> topologies, using an existing link-state routing 
--> protocol technology.
--> >> ---
--> >>
--> >> The fact that the architecture discusses other links is OK; it's
--> >> informational anyway.
--> >>
--> >> Joe
--> >>
--> > 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 12:01:13 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Status: RO
Content-Length: 1839

Hi,
 
Why not ask the question the other way? If Rbridges exist, why would
anyone want to use an old fashioned STP or RSTP based bridge?  :-)
Simplifying a lot, Rbridges make better use of available links while
various forms of spanning tree work by turning off and thus wasting
links. 
 
Of course there are some reasons, like Rbridges probably require greater
computational resources and bandwidth for routing messages. But as
computation gets cheaper and link bandwidth keeps rising, these factors
become less significant...
 
While I suppose this is all an interesting discussion, I personally
don't think it actually has much effect on the Rbridge specification. As
long as rbridges are to be applicable where high end bridges are
currently used, then they need to be able to support VLANs, optimize
multicast, etc. Whether or not they are beneficial where mid or lower
range bridges are used seems less important.
 
Donald

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Bowen
Sent: Friday, October 13, 2006 9:29 AM
To: Joe Touch
Cc: [email-masked]; [email-masked]; Radia Perlman
Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?

Joe Touch <[email-masked]> wrote on 10/12/2006 04:52:43 PM:
> 
> 
> Silvano Gai wrote:
> > Joe,
> > 
> > IMHO TRILL will be valuable in HPC and Datacenters, where high
> > bisectional bandwidth is a must, and in Enterprise Backbone. 
> 
> Sure, but that's not the only place they will be deployed. Please
review
> the P&AS.
> Joe

Joe, 

What is the operational experience that indicates the requirement for
the other environments?  I am not aware of anyone who plans to install
TRILL outside of the environment Silvano outlines. What need would
motivate these additional environments?

Ed

From: "Gray, Eric" <[email-masked]>
To: Joe Touch <[email-masked]>, Silvano Gai <[email-masked]>
Date: Fri, 13 Oct 2006 12:01:38 -0400
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1105

I agree with Joe, and - to add to what he says - the entire RBridge
domain must fall within a single administrative domain.  Consequently,
and such filtering can (and most reasonably would) be done at ingress.

However, as Joe's comment indicates, it is always possible to do this
filtering based on the "inner" header.  Therefore, it is easy to see
that we can treat this concern as "out of scope."

--
Eric

Joe Touch wrote:
> Silvano Gai wrote:
> > In today Ethernet I can write an ACL on the pair Source, Dest MAC
> > address, and many network managers find this extremely useful, but I
> > will not be able to do that on the RBridge addresses, if I have only
> > one.
> >
> > When an RBdridge receives a unicast frame, with the current proposal it
> > cannot screen it according to the ingress RBridge and this is a big
> > security hole.
> 
> That's trivial to spoof, so it's not a security issue per se. If there
> is any filtering based on an address, it ought to be at the inner
> address (which is already paired) anyway. If this is just for ACLs, it
> seems like a thin reason.

... [SNIP] ...

Date: Fri, 13 Oct 2006 08:52:13 -0700
From: Radia Perlman <[email-masked]>
To: Ed Bowen <[email-masked]>
Cc: [email-masked], [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1278

The situation that originally inspired this design was the huge hospital 
network that was something like
14 hops across and had zillions of nodes (forgot the size) that was all 
bridged. Apparently people like
the operational simplicity of bridges, and build large networks. Routing 
should be at layer 3, and the
Ethernet header was not designed to be a layer 3 header. The Ethernet 
designers never envisioned it
to be something that would be forwarded, or else, for instance, they'd 
have a TTL.

So this is useful wherever people want an IP network that requires 
minimal management but still
reasonable paths, etc.

Radia

Ed Bowen wrote:

> Joe Touch <[email-masked]> wrote on 10/12/2006 04:52:43 PM:
> >
> >
> > Silvano Gai wrote:
> > > Joe,
> > >
> > > IMHO TRILL will be valuable in HPC and Datacenters, where high
> > > bisectional bandwidth is a must, and in Enterprise Backbone.
> >
> > Sure, but that's not the only place they will be deployed. Please review
> > the P&AS.
> >
> > Joe
>
> Joe,
>
> What is the operational experience that indicates the requirement for 
> the other environments?  I am not aware of anyone who plans to install 
> TRILL outside of the environment Silvano outlines. What need would 
> motivate these additional environments?
>
> Ed
>

Date: Fri, 13 Oct 2006 08:19:27 -0700
From: Joe Touch <[email-masked]>
To: Ed Bowen <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1644

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5E6E57C0CACBA2FDF7D2192F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ed Bowen wrote:
> Joe,
>=20
> Joe Touch <[email-masked]> wrote on 10/13/2006 10:08:45 AM:
>=20
>> TRILL applies anytime the cross-section bandwidth of a set of deployed=

>> bridges is constrained because of the spanning tree algorithm rather
>> than the link capacity.
>=20
> Exactly, I know of no operational experience that this constraint is
> significant outside the Cluster/Datacenter/Enterprise-Backbone
> environments. I can imagine theoretical problems in other areas, but I
> know of no operational experience to prove the need. Do you?

Operational experience is not the only thing that drives the IETF
process. Please review the Tao of the IETF.

>> Again, please review the problem and applicability statement and the
>> working group charter.
>=20
> Done. Didn't see anything to make me believe otherwise. Did I miss
> something?

That document doesn't define this as an operational enterprise issue,
nor does the charter.

Joe

--------------enig5E6E57C0CACBA2FDF7D2192F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5E6E57C0CACBA2FDF7D2192F--

To: Joe Touch <[email-masked]>
From: Ed Bowen <[email-masked]>
Date: Fri, 13 Oct 2006 11:12:11 -0400
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1953

--0__=0ABBF895DFC245A08f9e8a93df938690918c0ABBF895DFC245A0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable

Joe,

Joe Touch <[email-masked]> wrote on 10/13/2006 10:08:45 AM:

> TRILL applies anytime the cross-section bandwidth of a set of deploye=
d
> bridges is constrained because of the spanning tree algorithm rather
> than the link capacity.

Exactly, I know of no operational experience that this constraint is
significant outside the Cluster/Datacenter/Enterprise-Backbone
environments. I can imagine theoretical problems in other areas, but I =
know
of no operational experience to prove the need. Do you?

>
> Again, please review the problem and applicability statement and the
> working group charter.

Done. Didn't see anything to make me believe otherwise. Did I miss
something?

Ed=

--0__=0ABBF895DFC245A08f9e8a93df938690918c0ABBF895DFC245A0
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body>
<p><tt>Joe,</tt><br>
<br>
<tt>Joe Touch &lt;[email-masked]&gt; wrote on 10/13/2006 10:08:45 AM:<br=
<br>
&gt; TRILL applies anytime the cross-section bandwidth of a set of depl=
oyed<br>
&gt; bridges is constrained because of the spanning tree algorithm rath=
er<br>
&gt; than the link capacity.</tt><br>
<br>
<tt>Exactly, I know of no operational experience that this constraint i=
s significant outside the Cluster/Datacenter/Enterprise-Backbone enviro=
nments. I can imagine theoretical problems in other areas, but I know o=
f no operational experience to prove the need. Do you? </tt><br>
<tt><br>
&gt; <br>
&gt; Again, please review the problem and applicability statement and t=
he<br>
&gt; working group charter.<br>
 </tt><br>
<tt>Done. Didn't see anything to make me believe otherwise. Did I miss =
something?</tt><br>
<br>
<tt>Ed</tt></body></html>=

--0__=0ABBF895DFC245A08f9e8a93df938690918c0ABBF895DFC245A0--

Date: Fri, 13 Oct 2006 07:08:45 -0700
From: Joe Touch <[email-masked]>
To: Ed Bowen <[email-masked]>
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1607

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD04838D085DCA26395901692
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ed Bowen wrote:
> Joe Touch <[email-masked]> wrote on 10/12/2006 04:52:43 PM:
>>
>>
>> Silvano Gai wrote:
>> > Joe,
>> >
>> > IMHO TRILL will be valuable in HPC and Datacenters, where high
>> > bisectional bandwidth is a must, and in Enterprise Backbone.
>>
>> Sure, but that's not the only place they will be deployed. Please revi=
ew
>> the P&AS.
>>
>> Joe
>=20
> Joe,
>=20
> What is the operational experience that indicates the requirement for
> the other environments?  I am not aware of anyone who plans to install
> TRILL outside of the environment Silvano outlines. What need would
> motivate these additional environments?
>=20
> Ed

TRILL applies anytime the cross-section bandwidth of a set of deployed
bridges is constrained because of the spanning tree algorithm rather
than the link capacity.

Again, please review the problem and applicability statement and the
working group charter.

Joe

--------------enigD04838D085DCA26395901692
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigD04838D085DCA26395901692--

To: Joe Touch <[email-masked]>
From: Ed Bowen <[email-masked]>
Date: Fri, 13 Oct 2006 09:29:01 -0400
Cc: [email-masked], [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1806

--0__=0ABBF895DF99E7368f9e8a93df938690918c0ABBF895DF99E736
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable

Joe Touch <[email-masked]> wrote on 10/12/2006 04:52:43 PM:
>
>
> Silvano Gai wrote:
> > Joe,
> >
> > IMHO TRILL will be valuable in HPC and Datacenters, where high
> > bisectional bandwidth is a must, and in Enterprise Backbone.
>
> Sure, but that's not the only place they will be deployed. Please rev=
iew
> the P&AS.
> Joe

Joe,

What is the operational experience that indicates the requirement for t=
he
other environments?  I am not aware of anyone who plans to install TRIL=
L
outside of the environment Silvano outlines. What need would motivate t=
hese
additional environments?

Ed=

--0__=0ABBF895DF99E7368f9e8a93df938690918c0ABBF895DF99E736
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body>
<p><tt>Joe Touch &lt;[email-masked]&gt;</tt><tt>&nbsp;wrote on 10/12/200=
6 04:52:43 PM:<br>
&gt; <br>
&gt; <br>
&gt; Silvano Gai wrote:<br>
&gt; &gt; Joe,<br>
&gt; &gt; <br>
&gt; &gt; IMHO TRILL will be valuable in HPC and Datacenters, where hig=
h<br>
&gt; &gt; bisectional bandwidth is a must, and in Enterprise Backbone. =
<br>
&gt; <br>
&gt; Sure, but that's not the only place they will be deployed. Please =
review<br>
&gt; the P&amp;AS.<br>
&gt; <br>
&gt; Joe<br>
</tt><br>
<tt>Joe, </tt><br>
<br>
<tt>What is the operational experience that indicates the requirement f=
or the other environments? &nbsp;I am not aware of anyone who plans to =
install TRILL outside of the environment Silvano outlines. What need wo=
uld motivate these additional environments?</tt><br>
<br>
<tt>Ed</tt></body></html>=

--0__=0ABBF895DF99E7368f9e8a93df938690918c0ABBF895DF99E736--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 17:42:50 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "N, Venkatesh" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] : Application of RBRidge
Status: RO
Content-Length: 3417

Hi,

Please see the TRILL Charter at
http://www.ietf.org/html.charters/trill-charter.html and the drafts
linked off that page, particularly the problem and applicability
statement draft. TRILL is chartered to specify a solution using
link-state routing technology. There is also an effort to solve the
problem using entirely spanning tree technology in IEEE 802.1aq,
http://www.ieee802.org/1/pages/802.1aq.html. (By the way, if you are
interested, these parallel efforts are being pursued by mutual agreement
after discussions at the highest level between the IETF and IEEE 802.)

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of N, Venkatesh
Sent: Thursday, October 12, 2006 12:00 PM
To: Silvano Gai; Joe Touch
Cc: [email-masked]; Radia Perlman
Subject: [rbridge] : Application of RBRidge

Hello All,

I'm new to this group, can someone point me to application of RBridges?
Sorry to ask some thing very basic.

As per my understanding existing protocols like MSTP would do good job
of load distribution of traffic in l2 network.

Regards,
Venky

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Silvano Gai
Sent: Thursday, October 12, 2006 7:49 PM
To: Joe Touch
Cc: [email-masked]; Radia Perlman
Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?

OK,
Let's restrict the discussion to IEEE 802.1-compliant Ethernet networks.

Today the outer header contains: 

   o  L2 destination = next RBridge, or for flooded frames, a new (to be

      assigned) multicast layer 2 address meaning "all RBridges" 

   o  L2 source = transmitting RBridge (the one that most recently 
      handled this frame)

If we want to avoid carrying the egress RBridge address in the shim
header, we need to put it in the outer header - L2 destination.

Is this what you are proposing?

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Thursday, October 12, 2006 7:07 AM
To: Silvano Gai
Cc: Radia Perlman; [email-masked]
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> Joe,
> 
> Let me focus on the need of RBridge addresses.
> 
> I didn't propose them; they are in the current WG draft:
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
> .txt
> to achieve scalability at the ISIS level.
> 
> The outer MAC addresses are present only if the frame is sent over 802
> link (section 2.9), but it may not be present on other media;
therefore
> TRILL cannot rely on them.
> 
> If you disagree with these two points, I think you disagree with the
> work that has been done in TRILL till now.

I agree with the charter, which limits us to specifying solutions that
work on 802.1 nets:

---
The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
topologies, using an existing link-state routing protocol technology.
---

The fact that the architecture discusses other links is OK; it's
informational anyway.

Joe

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 14:42:07 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 497

Silvano Gai wrote:
> Catlin,
> 
> Can you clarify what you mean by "do NOT require dynamic learning of
> MAC addresses". 
> 

My point is that a specific RBridge implementation MAY be
configured to "learn" that MAC Addrress X is on Port Y
solely through administrative configuration, and that
if anything else shows up on Port Y it is not to be
trusted.

Or more broadly, the specification does not limit
the methods by which an RBRidge can learn what MAC
Addresses are directly attached to it.

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 14:32:04 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2194

Catlin,

Can you clarify what you mean by "do NOT require dynamic learning of MAC
addresses".

If you mean that you don't want to implement backward learning and you
want to learn through ISIS, I am OK, but I don't see a difference from a
security perspective.

Let's suppose the host A is connected to RBridge R1.

Let's also suppose that an intruder connects to R2 and spoofs the MAC
address of A. The ISIS of R2 will start to announce A and the RBridges
will learn that A is connected to either R1 or R2, in a non
deterministic way.

If RBridge R3 connects server that need a high level of protection, it
may have an ACL that admits traffic from R1, but drop traffic from R2.

This is not achievable simply testing the MAC address A, since its
position is not deterministic during an attack even if backward learning
is disabled.

Am I missing something?

-- Silvano

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 2:05 PM
> To: Silvano Gai; Joe Touch
> Cc: [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> Silvano Gai wrote:
> > Joe,
> >
> > IMHO TRILL will be valuable in HPC and Datacenters, where
> > high bisectional bandwidth is a must, and in Enterprise Backbone. In
> > the last 3 to 5 years, in this kind of applications:
> > 1) I haven't seen a hub
> > 2) All links are full-duplex
> > 3) I haven't seen wireless
> > 4) The existing switches support large jumbo frames 5) Almost all
> > links are fiber 6) The attacks are originated by the host, not by
the
> > switches 7) Backbones are shared by different applications
> >
> > IMHO, if we want to design something that addresses user
> > needs, we need to keep this in mind.
> >
> 
> The environment you describe is indeed an important one.
> It is also the environment that has the *least* need for
> wire-mechanisms to detect intruders. The main support
> for security in data center environments that the RBridge
> drafts should have is to make certain that we do NOT require
> dynamic learning of MAC addresses, and be very clear that
> MAC locations MAY be administratively configured.
> 

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 14:05:21 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1005

Silvano Gai wrote:
> Joe,
> 
> IMHO TRILL will be valuable in HPC and Datacenters, where
> high bisectional bandwidth is a must, and in Enterprise Backbone. In
> the last 3 to 5 years, in this kind of applications:
> 1) I haven't seen a hub
> 2) All links are full-duplex
> 3) I haven't seen wireless
> 4) The existing switches support large jumbo frames 5) Almost all
> links are fiber 6) The attacks are originated by the host, not by the
> switches 7) Backbones are shared by different applications
> 
> IMHO, if we want to design something that addresses user
> needs, we need to keep this in mind.
> 

The environment you describe is indeed an important one.
It is also the environment that has the *least* need for
wire-mechanisms to detect intruders. The main support
for security in data center environments that the RBridge
drafts should have is to make certain that we do NOT require
dynamic learning of MAC addresses, and be very clear that
MAC locations MAY be administratively configured.

Date: Thu, 12 Oct 2006 13:52:43 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 954

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig760CEC5626FE4EC55B1A08AD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> IMHO TRILL will be valuable in HPC and Datacenters, where high
> bisectional bandwidth is a must, and in Enterprise Backbone.=20

Sure, but that's not the only place they will be deployed. Please review
the P&AS.

Joe

--------------enig760CEC5626FE4EC55B1A08AD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig760CEC5626FE4EC55B1A08AD--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 13:50:08 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1534

Joe,

IMHO TRILL will be valuable in HPC and Datacenters, where high
bisectional bandwidth is a must, and in Enterprise Backbone. In the last
3 to 5 years, in this kind of applications:
1) I haven't seen a hub
2) All links are full-duplex
3) I haven't seen wireless
4) The existing switches support large jumbo frames
5) Almost all links are fiber
6) The attacks are originated by the host, not by the switches
7) Backbones are shared by different applications

IMHO, if we want to design something that addresses user needs, we need
to keep this in mind.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 1:30 PM
> To: Silvano Gai
> Cc: Caitlin Bestler; [email-masked]; Radia Perlman
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
> > Catlin,
> >
> > I didn't reply to your last point
> >
> >> I am assuming there is no desire to replicate IPSEC funcationality
> >> at L2 then *all* of the L2 headers may be forged. I don't see how
> >> you can claim that any specific one is more trustworthy than
> >> the others.
> >
> > Even without IPsec, RBridges can authenticate to each other and
forging
> > an RBridge is much more difficult that using a readily available
program
> > on your PC to spoof the IP or MAC address.
> 
> I don't need to spoof another rbridge to inject spoofed traffic; I
just
> need to see the traffic going by; I can do that by plugging in a hub
and
> running tcpdump.
> Joe

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 13:37:23 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 706

Silvano Gai wrote:
> Catlin,
> 
> I didn't reply to your last point
> 
>> 
>> I am assuming there is no desire to replicate IPSEC funcationality at
>> L2 then *all* of the L2 headers may be forged. I don't see how you
>> can claim that any specific one is more trustworthy than the others.
> 
> Even without IPsec, RBridges can authenticate to each other
> and forging an RBridge is much more difficult that using a
> readily available program on your PC to spoof the IP or MAC address.
> 
> -- Silvano

I wouldn't be surprised if RBridges ending up authenticating
to each other as part of fabric discovery. But clearly there
will be no high quality authentication applied at L2 on a 
per packet basis.

Date: Thu, 12 Oct 2006 13:30:08 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1367

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCEF55E785A8E19F60E2B5C20
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Catlin,
>=20
> I didn't reply to your last point
>=20
>> I am assuming there is no desire to replicate IPSEC funcationality
>> at L2 then *all* of the L2 headers may be forged. I don't see how
>> you can claim that any specific one is more trustworthy than
>> the others.
>=20
> Even without IPsec, RBridges can authenticate to each other and forging=

> an RBridge is much more difficult that using a readily available progra=
m
> on your PC to spoof the IP or MAC address.

I don't need to spoof another rbridge to inject spoofed traffic; I just
need to see the traffic going by; I can do that by plugging in a hub and
running tcpdump.

Joe

--------------enigCEF55E785A8E19F60E2B5C20
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigCEF55E785A8E19F60E2B5C20--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 13:26:03 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 464

Catlin,

I didn't reply to your last point

> 
> I am assuming there is no desire to replicate IPSEC funcationality
> at L2 then *all* of the L2 headers may be forged. I don't see how
> you can claim that any specific one is more trustworthy than
> the others.

Even without IPsec, RBridges can authenticate to each other and forging
an RBridge is much more difficult that using a readily available program
on your PC to spoof the IP or MAC address.

-- Silvano

Date: Thu, 12 Oct 2006 13:23:34 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1257

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig08C765EA7008738C65DD1C60
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Caitlin,
>=20
> See below
>=20
> ...
>=20
>> And as we all know the probability of MsgSize having been
>> crafted so the MsgSize % n is zero is all too high. So the
>> more we add to the header, the more IP datagrams will be
>> required to send the same traffic.=20
>=20
> I had the impression that TRILL was increasing the frame size on the
> encapsulated size,=20

That'd be nice, but it's not possible; we need to run over existing
802.1D equipment as transit inside the rbridge. See sec 3.2 of
draft-ietf-trill-prob-00.txt

Joe

--------------enig08C765EA7008738C65DD1C60
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig08C765EA7008738C65DD1C60--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 13:16:44 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 976

Caitlin,

See below

...

> 
> And as we all know the probability of MsgSize having been
> crafted so the MsgSize % n is zero is all too high. So the
> more we add to the header, the more IP datagrams will be
> required to send the same traffic. 

I had the impression that TRILL was increasing the frame size on the
encapsulated size, not MTU reduction at the IP level. The fact that we
add few bytes more or less impacts performance, but not number of IP
datagram.

-- Silvano

That's not only more
> bandwidth, but a reduced probability of the entire message
> arriving on first try, deeper queues in all the forwarding
> elements, etc.
> 
> Using the larger header needs a solid justification, not
> just a presumption that bandwidth is cheap.
> 
> I am assuming there is no desire to replicate IPSEC funcationality
> at L2 then *all* of the L2 headers may be forged. I don't see how
> you can claim that any specific one is more trustworthy than
> the others.
> 
> 

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 12:41:58 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3721

Silvano Gai wrote:
> Caitlin,
> 
> See inline
> 
>> -----Original Message-----
>> From: Caitlin Bestler [mailto:[email-masked]]
>> Sent: Thursday, October 12, 2006 9:18 AM
>> To: Silvano Gai; Joe Touch
>> Cc: [email-masked]; Radia Perlman
>> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
>> 
>> [email-masked] wrote:
>>> In today Ethernet I can write an ACL on the pair Source, Dest MAC
>>> address, and many network managers find this extremely useful, but I
>>> will not be able to do that on the RBridge addresses, if I have
>>> only one. 
>>> 
>>> When an RBdridge receives a unicast frame, with the current proposal
>>> it cannot screen it according to the ingress RBridge and this is a
>>> big security hole. An Rbridge needs to be able to drop traffic
>>> originated by another RBridge: this requires two addresses.
>>> 
>> 
>> It can certainly do so with the current header. It merely has to map
>> the source MAC address to the source RBridge -- something it would
>> end up doing for the reverse packet anyway.
> 
> The source MAC address is much easier to spoof than the
> ingress RBridge address, there is no guarantee that the frame
> entered the RBridge cloud at the RBridge derived by the mapping you
> propose. 
> 
>> 
>> If the frequency of rogue RBridges is high enough to justify
> 
> The issue is not Rogue RBridges, the issue is that in a
> network there will be RBridges that will connect unsecured
> hosts/links and the network manager may desire an easy way to
> restrict them to a subset of the TRILL cloud.
> 
>> a larger shim header to optimize dropping their packets then things
>> are in a pretty bad shape. If there are network elements that cannot
>> ultimately be physically disconnected by the network administrator
>> then they should probably be separated by a router and not included
>> in the subnet.
> 
> In today world, any tool you can give a network administrator
> to segregate traffic is welcomed.
> 
>> 
>> And given that any RBRidge header is not going to have IPSEC quality
>> authentication the degree to which we can provide protection from a
>> malicious RBridge is fundamentally limited.
>> 
>> Let's be realistic and keep security at the IP layer.
> 
> This is IEEE 802.1D replacement, there may not be an IP layer.
> 
> 
>> The originally proposed short envelope solves the essential problems.
>> The additional fields that Radia's recent draft suggested are all
>> interesting. Many of them MIGHT help RBridges perform certain
>> functions more efficiently. But I do not believe any of the extra
>> fields are necessary, and my initial thought is that they do not
>> justify eating away at the MTU.
> 
> I am much more concerned that TRILL will provide a superset
> of the functionalities that 802.1D and all its variations
> provide, than saving few bytes in the shim headers. I think
> the times where optimizing to the last byte was important are long
> gone with 1 and 10 GE. 
> 

No matter what the wire speed:

MsgSize/(n-4) >= MsgSize/n

And as we all know the probability of MsgSize having been
crafted so the MsgSize % n is zero is all too high. So the
more we add to the header, the more IP datagrams will be
required to send the same traffic. That's not only more
bandwidth, but a reduced probability of the entire message
arriving on first try, deeper queues in all the forwarding
elements, etc.

Using the larger header needs a solid justification, not 
just a presumption that bandwidth is cheap.

I am assuming there is no desire to replicate IPSEC funcationality
at L2 then *all* of the L2 headers may be forged. I don't see how
you can claim that any specific one is more trustworthy than
the others.

Date: Thu, 12 Oct 2006 12:29:25 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1518

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig139B05B21A0B6F8C8FE76A30
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
=2E..
>> Let's be realistic and keep security at the IP layer.
>=20
> This is IEEE 802.1D replacement, there may not be an IP layer.

Agreed, but this is not an 802.1D _replacement_; this _supports_ 802.1D
functionality. It's not intended to overcome limitations - e.g., the
need for policy tags - that 802.1D lacks.

=2E..
> I am much more concerned that TRILL will provide a superset of the
> functionalities that 802.1D and all its variations provide, than saving=

> few bytes in the shim headers. I think the times where optimizing to th=
e
> last byte was important are long gone with 1 and 10 GE.

The only additional capability is supposed to be independent-path
forwarding, AFAICT.

As to "long gone with 1 and 10 GE", 802.1D also works at much slower
speeds, notably in wireless.

Joe

--------------enig139B05B21A0B6F8C8FE76A30
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig139B05B21A0B6F8C8FE76A30--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 12:06:45 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 2887

Caitlin, 

See inline

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 9:18 AM
> To: Silvano Gai; Joe Touch
> Cc: [email-masked]; Radia Perlman
> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
> 
> [email-masked] wrote:
> > In today Ethernet I can write an ACL on the pair Source, Dest
> > MAC address, and many network managers find this extremely
> > useful, but I will not be able to do that on the RBridge
> > addresses, if I have only one.
> >
> > When an RBdridge receives a unicast frame, with the current
> > proposal it cannot screen it according to the ingress RBridge
> > and this is a big security hole. An Rbridge needs to be able
> > to drop traffic originated by another RBridge: this requires
> > two addresses.
> >
> 
> It can certainly do so with the current header. It merely has
> to map the source MAC address to the source RBridge -- something
> it would end up doing for the reverse packet anyway.

The source MAC address is much easier to spoof than the ingress RBridge
address, there is no guarantee that the frame entered the RBridge cloud
at the RBridge derived by the mapping you propose.

> 
> If the frequency of rogue RBridges is high enough to justify

The issue is not Rogue RBridges, the issue is that in a network there
will be RBridges that will connect unsecured hosts/links and the network
manager may desire an easy way to restrict them to a subset of the TRILL
cloud.

> a larger shim header to optimize dropping their packets then
> things are in a pretty bad shape. If there are network elements
> that cannot ultimately be physically disconnected by the network
> administrator then they should probably be separated by a router
> and not included in the subnet.

In today world, any tool you can give a network administrator to
segregate traffic is welcomed.

> 
> And given that any RBRidge header is not going to have IPSEC
> quality authentication the degree to which we can provide
> protection from a malicious RBridge is fundamentally limited.
> 
> Let's be realistic and keep security at the IP layer.

This is IEEE 802.1D replacement, there may not be an IP layer.

> The originally proposed short envelope solves the
> essential problems. The additional fields that Radia's
> recent draft suggested are all interesting. Many of
> them MIGHT help RBridges perform certain functions
> more efficiently. But I do not believe any of the
> extra fields are necessary, and my initial thought
> is that they do not justify eating away at the MTU.

I am much more concerned that TRILL will provide a superset of the
functionalities that 802.1D and all its variations provide, than saving
few bytes in the shim headers. I think the times where optimizing to the
last byte was important are long gone with 1 and 10 GE.

-- Silvano

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 09:18:23 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1657

[email-masked] wrote:
> In today Ethernet I can write an ACL on the pair Source, Dest
> MAC address, and many network managers find this extremely
> useful, but I will not be able to do that on the RBridge
> addresses, if I have only one.
> 
> When an RBdridge receives a unicast frame, with the current
> proposal it cannot screen it according to the ingress RBridge
> and this is a big security hole. An Rbridge needs to be able
> to drop traffic originated by another RBridge: this requires
> two addresses.
> 

It can certainly do so with the current header. It merely has
to map the source MAC address to the source RBridge -- something
it would end up doing for the reverse packet anyway.

If the frequency of rogue RBridges is high enough to justify
a larger shim header to optimize dropping their packets then
things are in a pretty bad shape. If there are network elements
that cannot ultimately be physically disconnected by the network
administrator then they should probably be separated by a router
and not included in the subnet.

And given that any RBRidge header is not going to have IPSEC
quality authentication the degree to which we can provide
protection from a malicious RBridge is fundamentally limited.

Let's be realistic and keep security at the IP layer.
The originally proposed short envelope solves the 
essential problems. The additional fields that Radia's
recent draft suggested are all interesting. Many of
them MIGHT help RBridges perform certain functions
more efficiently. But I do not believe any of the
extra fields are necessary, and my initial thought
is that they do not justify eating away at the MTU.

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 09:14:18 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 4204

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 8:55 AM
To: Silvano Gai
Cc: Radia Perlman; [email-masked]
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> In today Ethernet I can write an ACL on the pair Source, Dest MAC
> address, and many network managers find this extremely useful, but I
> will not be able to do that on the RBridge addresses, if I have only
> one.
>
> When an RBdridge receives a unicast frame, with the current proposal
it
> cannot screen it according to the ingress RBridge and this is a big
> security hole.

That's trivial to spoof, 

Is it?  You need to emulate an RBridge to be able to spoof the RBridge
address. This includes passing all the link negotiation, bringing up
ISIS, passing the security test of ISIS. I will say it is much harder
that spoofing a MAC address or an IP address.

Agreed?

-- Silvano

so it's not a security issue per se. If there
is any filtering based on an address, it ought to be at the inner
address (which is already paired) anyway. If this is just for ACLs, it
seems like a thin reason.

> An Rbridge needs to be able to drop traffic originated by
> another RBridge: this requires two addresses.
> 
> IMHO addresses come in pair, I am not aware of a successful protocol
> that has a single address.
> 
> -- Silvano
> 
> 
> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 7:30 AM
> To: Silvano Gai
> Cc: Radia Perlman; [email-masked]
> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
>> OK,
>> Let's restrict the discussion to IEEE 802.1-compliant Ethernet
> networks.
>> Today the outer header contains: 
>>
>>    o  L2 destination = next RBridge, or for flooded frames, a new (to
> be
>>       assigned) multicast layer 2 address meaning "all RBridges" 
>>
>>    o  L2 source = transmitting RBridge (the one that most recently 
>>       handled this frame)
>>
>> If we want to avoid carrying the egress RBridge address in the shim
>> header, we need to put it in the outer header - L2 destination.
> 
> The reason for the single shim rbridge address is a tradeoff, to avoid
> populating the inner rbridge nodes with complete ingress tables.
That's
> a trade-off rather than a requirement.
> 
> If we went with strict minimalism, we could avoid the need for that
> field; I understand the desire to avoid populating every node with
full
> tables, though. So I'll update my earlier note and add the single
> desination/mulitcast source address field, as per the protocol doc.
> 
> As we go beyond that minimal requirement, we're starting to add
> capability that looks more like IP than ethernet. IMO, rbridges should
> support what ethernet supports, not necessarily what IP is capable of.
> If you want IP, use IP.
> 
> Joe
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]] 
>> Sent: Thursday, October 12, 2006 7:07 AM
>> To: Silvano Gai
>> Cc: Radia Perlman; [email-masked]
>> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> Let me focus on the need of RBridge addresses.
>>>
>>> I didn't propose them; they are in the current WG draft:
>>>
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
>>> .txt
>>> to achieve scalability at the ISIS level.
>>>
>>> The outer MAC addresses are present only if the frame is sent over
> 802
>>> link (section 2.9), but it may not be present on other media;
>> therefore
>>> TRILL cannot rely on them.
>>>
>>> If you disagree with these two points, I think you disagree with the
>>> work that has been done in TRILL till now.
>> I agree with the charter, which limits us to specifying solutions
that
>> work on 802.1 nets:
>>
>> ---
>> The TRILL WG will design a solution for shortest-path frame routing
in
>> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
>> topologies, using an existing link-state routing protocol technology.
>> ---
>>
>> The fact that the architecture discusses other links is OK; it's
>> informational anyway.
>>
>> Joe
>>
> 

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 21:29:32 +0530
From: "N, Venkatesh" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: [rbridge]  : Application of RBRidge
Status: RO
Content-Length: 2408

Hello All,

I'm new to this group, can someone point me to application of RBridges?
Sorry to ask some thing very basic.

As per my understanding existing protocols like MSTP would do good job
of load distribution of traffic in l2 network.

Regards,
Venky

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Silvano Gai
Sent: Thursday, October 12, 2006 7:49 PM
To: Joe Touch
Cc: [email-masked]; Radia Perlman
Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?

OK,
Let's restrict the discussion to IEEE 802.1-compliant Ethernet networks.

Today the outer header contains: 

   o  L2 destination = next RBridge, or for flooded frames, a new (to be

      assigned) multicast layer 2 address meaning "all RBridges" 

   o  L2 source = transmitting RBridge (the one that most recently 
      handled this frame)

If we want to avoid carrying the egress RBridge address in the shim
header, we need to put it in the outer header - L2 destination.

Is this what you are proposing?

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 7:07 AM
To: Silvano Gai
Cc: Radia Perlman; [email-masked]
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> Joe,
> 
> Let me focus on the need of RBridge addresses.
> 
> I didn't propose them; they are in the current WG draft:
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
> .txt
> to achieve scalability at the ISIS level.
> 
> The outer MAC addresses are present only if the frame is sent over 802
> link (section 2.9), but it may not be present on other media;
therefore
> TRILL cannot rely on them.
> 
> If you disagree with these two points, I think you disagree with the
> work that has been done in TRILL till now.

I agree with the charter, which limits us to specifying solutions that
work on 802.1 nets:

---
The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
topologies, using an existing link-state routing protocol technology.
---

The fact that the architecture discusses other links is OK; it's
informational anyway.

Joe

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Date: Thu, 12 Oct 2006 08:54:44 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 4441

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1E5230D225B1EF41185CA442
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> In today Ethernet I can write an ACL on the pair Source, Dest MAC
> address, and many network managers find this extremely useful, but I
> will not be able to do that on the RBridge addresses, if I have only
> one.
>
> When an RBdridge receives a unicast frame, with the current proposal it=

> cannot screen it according to the ingress RBridge and this is a big
> security hole.

That's trivial to spoof, so it's not a security issue per se. If there
is any filtering based on an address, it ought to be at the inner
address (which is already paired) anyway. If this is just for ACLs, it
seems like a thin reason.

> An Rbridge needs to be able to drop traffic originated by
> another RBridge: this requires two addresses.
>=20
> IMHO addresses come in pair, I am not aware of a successful protocol
> that has a single address.
>=20
> -- Silvano
>=20
>=20
> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]=20
> Sent: Thursday, October 12, 2006 7:30 AM
> To: Silvano Gai
> Cc: Radia Perlman; [email-masked]
> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
>=20
>=20
>=20
> Silvano Gai wrote:
>> OK,
>> Let's restrict the discussion to IEEE 802.1-compliant Ethernet
> networks.
>> Today the outer header contains:=20
>>
>>    o  L2 destination =3D next RBridge, or for flooded frames, a new (t=
o
> be
>>       assigned) multicast layer 2 address meaning "all RBridges"=20
>>
>>    o  L2 source =3D transmitting RBridge (the one that most recently=20
>>       handled this frame)
>>
>> If we want to avoid carrying the egress RBridge address in the shim
>> header, we need to put it in the outer header - L2 destination.
>=20
> The reason for the single shim rbridge address is a tradeoff, to avoid
> populating the inner rbridge nodes with complete ingress tables. That's=

> a trade-off rather than a requirement.
>=20
> If we went with strict minimalism, we could avoid the need for that
> field; I understand the desire to avoid populating every node with full=

> tables, though. So I'll update my earlier note and add the single
> desination/mulitcast source address field, as per the protocol doc.
>=20
> As we go beyond that minimal requirement, we're starting to add
> capability that looks more like IP than ethernet. IMO, rbridges should
> support what ethernet supports, not necessarily what IP is capable of.
> If you want IP, use IP.
>=20
> Joe
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]=20
>> Sent: Thursday, October 12, 2006 7:07 AM
>> To: Silvano Gai
>> Cc: Radia Perlman; [email-masked]
>> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> Let me focus on the need of RBridge addresses.
>>>
>>> I didn't propose them; they are in the current WG draft:
>>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
0
>>> .txt
>>> to achieve scalability at the ISIS level.
>>>
>>> The outer MAC addresses are present only if the frame is sent over
> 802
>>> link (section 2.9), but it may not be present on other media;
>> therefore
>>> TRILL cannot rely on them.
>>>
>>> If you disagree with these two points, I think you disagree with the
>>> work that has been done in TRILL till now.
>> I agree with the charter, which limits us to specifying solutions that=

>> work on 802.1 nets:
>>
>> ---
>> The TRILL WG will design a solution for shortest-path frame routing in=

>> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
>> topologies, using an existing link-state routing protocol technology.
>> ---
>>
>> The fact that the architecture discusses other links is OK; it's
>> informational anyway.
>>
>> Joe
>>
>=20

--------------enig1E5230D225B1EF41185CA442
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig1E5230D225B1EF41185CA442--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 08:05:10 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3303

In today Ethernet I can write an ACL on the pair Source, Dest MAC
address, and many network managers find this extremely useful, but I
will not be able to do that on the RBridge addresses, if I have only
one.

When an RBdridge receives a unicast frame, with the current proposal it
cannot screen it according to the ingress RBridge and this is a big
security hole. An Rbridge needs to be able to drop traffic originated by
another RBridge: this requires two addresses.

IMHO addresses come in pair, I am not aware of a successful protocol
that has a single address.

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 7:30 AM
To: Silvano Gai
Cc: Radia Perlman; [email-masked]
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> OK,
> Let's restrict the discussion to IEEE 802.1-compliant Ethernet
networks.
> 
> Today the outer header contains: 
> 
>    o  L2 destination = next RBridge, or for flooded frames, a new (to
be
> 
>       assigned) multicast layer 2 address meaning "all RBridges" 
> 
>    o  L2 source = transmitting RBridge (the one that most recently 
>       handled this frame)
> 
> If we want to avoid carrying the egress RBridge address in the shim
> header, we need to put it in the outer header - L2 destination.

The reason for the single shim rbridge address is a tradeoff, to avoid
populating the inner rbridge nodes with complete ingress tables. That's
a trade-off rather than a requirement.

If we went with strict minimalism, we could avoid the need for that
field; I understand the desire to avoid populating every node with full
tables, though. So I'll update my earlier note and add the single
desination/mulitcast source address field, as per the protocol doc.

As we go beyond that minimal requirement, we're starting to add
capability that looks more like IP than ethernet. IMO, rbridges should
support what ethernet supports, not necessarily what IP is capable of.
If you want IP, use IP.

Joe

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 7:07 AM
> To: Silvano Gai
> Cc: Radia Perlman; [email-masked]
> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
> 
> 
> 
> Silvano Gai wrote:
>> Joe,
>>
>> Let me focus on the need of RBridge addresses.
>>
>> I didn't propose them; they are in the current WG draft:
>>
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
>> .txt
>> to achieve scalability at the ISIS level.
>>
>> The outer MAC addresses are present only if the frame is sent over
802
>> link (section 2.9), but it may not be present on other media;
> therefore
>> TRILL cannot rely on them.
>>
>> If you disagree with these two points, I think you disagree with the
>> work that has been done in TRILL till now.
> 
> I agree with the charter, which limits us to specifying solutions that
> work on 802.1 nets:
> 
> ---
> The TRILL WG will design a solution for shortest-path frame routing in
> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
> topologies, using an existing link-state routing protocol technology.
> ---
> 
> The fact that the architecture discusses other links is OK; it's
> informational anyway.
> 
> Joe
> 

Date: Thu, 12 Oct 2006 07:29:36 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3237

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig841C2602343F6C67A06BD3B4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> OK,
> Let's restrict the discussion to IEEE 802.1-compliant Ethernet networks=
=2E
>=20
> Today the outer header contains:=20
>=20
>    o  L2 destination =3D next RBridge, or for flooded frames, a new (to=
 be
>=20
>       assigned) multicast layer 2 address meaning "all RBridges"=20
>=20
>    o  L2 source =3D transmitting RBridge (the one that most recently=20
>       handled this frame)
>=20
> If we want to avoid carrying the egress RBridge address in the shim
> header, we need to put it in the outer header - L2 destination.

The reason for the single shim rbridge address is a tradeoff, to avoid
populating the inner rbridge nodes with complete ingress tables. That's
a trade-off rather than a requirement.

If we went with strict minimalism, we could avoid the need for that
field; I understand the desire to avoid populating every node with full
tables, though. So I'll update my earlier note and add the single
desination/mulitcast source address field, as per the protocol doc.

As we go beyond that minimal requirement, we're starting to add
capability that looks more like IP than ethernet. IMO, rbridges should
support what ethernet supports, not necessarily what IP is capable of.
If you want IP, use IP.

Joe

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]=20
> Sent: Thursday, October 12, 2006 7:07 AM
> To: Silvano Gai
> Cc: Radia Perlman; [email-masked]
> Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?
>=20
>=20
>=20
> Silvano Gai wrote:
>> Joe,
>>
>> Let me focus on the need of RBridge addresses.
>>
>> I didn't propose them; they are in the current WG draft:
>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
0
>> .txt
>> to achieve scalability at the ISIS level.
>>
>> The outer MAC addresses are present only if the frame is sent over 802=

>> link (section 2.9), but it may not be present on other media;
> therefore
>> TRILL cannot rely on them.
>>
>> If you disagree with these two points, I think you disagree with the
>> work that has been done in TRILL till now.
>=20
> I agree with the charter, which limits us to specifying solutions that
> work on 802.1 nets:
>=20
> ---
> The TRILL WG will design a solution for shortest-path frame routing in
> multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
> topologies, using an existing link-state routing protocol technology.
> ---
>=20
> The fact that the architecture discusses other links is OK; it's
> informational anyway.
>=20
> Joe
>=20

--------------enig841C2602343F6C67A06BD3B4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig841C2602343F6C67A06BD3B4--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 07:18:53 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1728

OK,
Let's restrict the discussion to IEEE 802.1-compliant Ethernet networks.

Today the outer header contains: 

   o  L2 destination = next RBridge, or for flooded frames, a new (to be

      assigned) multicast layer 2 address meaning "all RBridges" 

   o  L2 source = transmitting RBridge (the one that most recently 
      handled this frame)

If we want to avoid carrying the egress RBridge address in the shim
header, we need to put it in the outer header - L2 destination.

Is this what you are proposing?

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 7:07 AM
To: Silvano Gai
Cc: Radia Perlman; [email-masked]
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> Joe,
> 
> Let me focus on the need of RBridge addresses.
> 
> I didn't propose them; they are in the current WG draft:
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
> .txt
> to achieve scalability at the ISIS level.
> 
> The outer MAC addresses are present only if the frame is sent over 802
> link (section 2.9), but it may not be present on other media;
therefore
> TRILL cannot rely on them.
> 
> If you disagree with these two points, I think you disagree with the
> work that has been done in TRILL till now.

I agree with the charter, which limits us to specifying solutions that
work on 802.1 nets:

---
The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
topologies, using an existing link-state routing protocol technology.
---

The fact that the architecture discusses other links is OK; it's
informational anyway.

Joe

Date: Thu, 12 Oct 2006 07:07:23 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 1678

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2BEC6B1B374EF7A065C8B618
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> Let me focus on the need of RBridge addresses.
>=20
> I didn't propose them; they are in the current WG draft:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0=
0
> .txt
> to achieve scalability at the ISIS level.
>=20
> The outer MAC addresses are present only if the frame is sent over 802
> link (section 2.9), but it may not be present on other media; therefore=

> TRILL cannot rely on them.
>=20
> If you disagree with these two points, I think you disagree with the
> work that has been done in TRILL till now.

I agree with the charter, which limits us to specifying solutions that
work on 802.1 nets:

---
The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
topologies, using an existing link-state routing protocol technology.
---

The fact that the architecture discusses other links is OK; it's
informational anyway.

Joe

--------------enig2BEC6B1B374EF7A065C8B618
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2BEC6B1B374EF7A065C8B618--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 06:58:25 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 5670

Joe,

Let me focus on the need of RBridge addresses.

I didn't propose them; they are in the current WG draft:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt
to achieve scalability at the ISIS level.

The outer MAC addresses are present only if the frame is sent over 802
link (section 2.9), but it may not be present on other media; therefore
TRILL cannot rely on them.

If you disagree with these two points, I think you disagree with the
work that has been done in TRILL till now.

What my draft adds is that addresses always come in pairs and there is a
value to have the source and destination RBridge addresses in the shim
header.

Let see if we are in synch up to here, then we can discuss the other
fields.

Cheers

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 6:31 AM
To: Silvano Gai
Cc: Radia Perlman; [email-masked]
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> Joe,
> 
> Are you advocating a model in which TRILL add an Ethernet shim header
> containing the TTL only? No RBridge addresses/nicknames?

Not necessarily, but it's clear that only TTL is *required*, and
everything else ought to have a very strong reason for inclusion.

> IMO, without a level of addressing at the RBridge level the forwarding
> is not flexible and scalable.

It would be useful to explain. In particular:

- how do rbridge addresses/nicknames enable flexibility vs. either VLAN
tags or the outer ethernet addresses?

- how does the lack of such tags affect scalability, *especially* given
that the solution is not intended to scale beyond that of current
ethernet deployments (we've discussed this before, and that was the WG
consensus).

- which nodes would this affect?

- why is it important to carry decapsulation forwarding information in
the packet? (e.g., for the new proposal)

Joe

> -- Silvano
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Joe Touch
> Sent: Wednesday, October 11, 2006 9:46 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] New fields in shim header?
> 
> 
> 
> Radia Perlman wrote:
>> Silvano Gai has posted an interest draft suggesting new fields for
the
>> shim header.
>> The draft is at:
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
>> If new fields are added, we'll have to give up on the MPLS-like 
>> encoding, and the shim header
>> would be slightly larger, so we should consider each of these fields
> and 
>> see whether people think
>> the functionality they give warrants the extra space in the shim
> header.
>> I think it might be best to start a thread about each field
> separately. 
>> But I'll summarize here.
>>
>> The current shim header contains:
>> a) RBridge nickname, which is either egress or ingress RBridge
> depending 
>> on whether it is
>> directed unicast or not. This fits in MPLS's 20-bit Label field with
> one 
>> bit indicating whether
>> the RBridge nickname is the ingress (multicast) or egress (directed 
>> unicast).
>>
>> b) TTL
>>
>> c) priority
> 
> Of these, only the TTL seems absolutely required; that includes the
ones
> below. Keeping the shim minimal seems important (to reduce MTU impact,
> in particular). If further IP functionality is required - e.g.,
diffserv
> code point-like f-tags, or source-routes-like LIDs - then perhaps we
> shouldn't be doing this at the link layer, IMO.
> 
> Joe
> 
>> ****************
>> The proposed extra fields for the shim header are:
>> a) have BOTH ingress and egress RBridge nicknames, and shrink the 
>> nicknames down to 16 bits.
>> The reason for this is that in the case of directed unicast policy
> (such 
>> as source address filtering)
>> can be applied to ingress as well as egress RBridge).
>>
>> b) F-Tag: I think of this as a metric identifier, proposed length 
>> 10-bits. This enables setting multiple
>> costs for each link, and calculating paths and trees differently for 
>> different types of traffic
>>
>> c) egress LID ("local identifier"). This is for the convenience of
the
> 
>> egress RBridge---for example, it could
>> be the port onto which the (decapsulated) frame should be forwarded.
> It 
>> saves the egress RBridge
>> from looking up the destination address in the original frame (since
> the 
>> ingress RBridge already
>> had to do that work). The ingress RBridge knew the LID to put in
> because 
>> the egress RBridge had
>> announced (my nickname, LID) for that destination. The ingress
RBridge
> 
>> does not interpret the LID---just
>> sticks it into the shim header.
>>
>> d) ingress LID  The only reason I think to have an ingress
>> LID is in case at some point in the future learning of (destination
> MAC 
>> address corresponds to
>> egress RBridge, LID) is done based on looking at data packets. 
>> Otherwise, this would be learned
>> from link state advertisements, and only one LID (egress LID) would
be
> 
>> in the shim.
>>
>> Anyway---the format of the shim is something we really should decide
> on 
>> and attempt to never change
>> in the future. I don't have strong opinions. What do other people
> think?
>> If you care about any of these fields (pro or con) start a thread
with
> 
>> subject line, e.g., "F-tag in shim header".
>> Or maybe I'll do it. Or for now, reply to this note with opinions
> about 
>> any of the fields.
>>
>> Thanks,
>>
>> Radia
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Thu, 12 Oct 2006 06:31:16 -0700
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 5449

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3941F3EB8B07AAEA624008FD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> Are you advocating a model in which TRILL add an Ethernet shim header
> containing the TTL only? No RBridge addresses/nicknames?

Not necessarily, but it's clear that only TTL is *required*, and
everything else ought to have a very strong reason for inclusion.

> IMO, without a level of addressing at the RBridge level the forwarding
> is not flexible and scalable.

It would be useful to explain. In particular:

- how do rbridge addresses/nicknames enable flexibility vs. either VLAN
tags or the outer ethernet addresses?

- how does the lack of such tags affect scalability, *especially* given
that the solution is not intended to scale beyond that of current
ethernet deployments (we've discussed this before, and that was the WG
consensus).

- which nodes would this affect?

- why is it important to carry decapsulation forwarding information in
the packet? (e.g., for the new proposal)

Joe

> -- Silvano
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=

> Behalf Of Joe Touch
> Sent: Wednesday, October 11, 2006 9:46 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] New fields in shim header?
>=20
>=20
>=20
> Radia Perlman wrote:
>> Silvano Gai has posted an interest draft suggesting new fields for the=

>=20
>> shim header.
>> The draft is at:
>>
> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.tx=
t
>> If new fields are added, we'll have to give up on the MPLS-like=20
>> encoding, and the shim header
>> would be slightly larger, so we should consider each of these fields
> and=20
>> see whether people think
>> the functionality they give warrants the extra space in the shim
> header.
>> I think it might be best to start a thread about each field
> separately.=20
>> But I'll summarize here.
>>
>> The current shim header contains:
>> a) RBridge nickname, which is either egress or ingress RBridge
> depending=20
>> on whether it is
>> directed unicast or not. This fits in MPLS's 20-bit Label field with
> one=20
>> bit indicating whether
>> the RBridge nickname is the ingress (multicast) or egress (directed=20
>> unicast).
>>
>> b) TTL
>>
>> c) priority
>=20
> Of these, only the TTL seems absolutely required; that includes the one=
s
> below. Keeping the shim minimal seems important (to reduce MTU impact,
> in particular). If further IP functionality is required - e.g., diffser=
v
> code point-like f-tags, or source-routes-like LIDs - then perhaps we
> shouldn't be doing this at the link layer, IMO.
>=20
> Joe
>=20
>> ****************
>> The proposed extra fields for the shim header are:
>> a) have BOTH ingress and egress RBridge nicknames, and shrink the=20
>> nicknames down to 16 bits.
>> The reason for this is that in the case of directed unicast policy
> (such=20
>> as source address filtering)
>> can be applied to ingress as well as egress RBridge).
>>
>> b) F-Tag: I think of this as a metric identifier, proposed length=20
>> 10-bits. This enables setting multiple
>> costs for each link, and calculating paths and trees differently for=20
>> different types of traffic
>>
>> c) egress LID ("local identifier"). This is for the convenience of the=

>=20
>> egress RBridge---for example, it could
>> be the port onto which the (decapsulated) frame should be forwarded.
> It=20
>> saves the egress RBridge
>> from looking up the destination address in the original frame (since
> the=20
>> ingress RBridge already
>> had to do that work). The ingress RBridge knew the LID to put in
> because=20
>> the egress RBridge had
>> announced (my nickname, LID) for that destination. The ingress RBridge=

>=20
>> does not interpret the LID---just
>> sticks it into the shim header.
>>
>> d) ingress LID  The only reason I think to have an ingress
>> LID is in case at some point in the future learning of (destination
> MAC=20
>> address corresponds to
>> egress RBridge, LID) is done based on looking at data packets.=20
>> Otherwise, this would be learned
>> from link state advertisements, and only one LID (egress LID) would be=

>=20
>> in the shim.
>>
>> Anyway---the format of the shim is something we really should decide
> on=20
>> and attempt to never change
>> in the future. I don't have strong opinions. What do other people
> think?
>> If you care about any of these fields (pro or con) start a thread with=

>=20
>> subject line, e.g., "F-tag in shim header".
>> Or maybe I'll do it. Or for now, reply to this note with opinions
> about=20
>> any of the fields.
>>
>> Thanks,
>>
>> Radia
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>=20

--------------enig3941F3EB8B07AAEA624008FD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig3941F3EB8B07AAEA624008FD--

Content-class: urn:content-classes:message
Date: Thu, 12 Oct 2006 06:23:42 -0700
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] TTL only - was RE:  New fields in shim header?
Status: RO
Content-Length: 3836

Joe,

Are you advocating a model in which TRILL add an Ethernet shim header
containing the TTL only? No RBridge addresses/nicknames?

IMO, without a level of addressing at the RBridge level the forwarding
is not flexible and scalable.

-- Silvano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Wednesday, October 11, 2006 9:46 PM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] New fields in shim header?

Radia Perlman wrote:
> Silvano Gai has posted an interest draft suggesting new fields for the

> shim header.
> The draft is at:
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
> 
> If new fields are added, we'll have to give up on the MPLS-like 
> encoding, and the shim header
> would be slightly larger, so we should consider each of these fields
and 
> see whether people think
> the functionality they give warrants the extra space in the shim
header.
> 
> I think it might be best to start a thread about each field
separately. 
> But I'll summarize here.
> 
> The current shim header contains:
> a) RBridge nickname, which is either egress or ingress RBridge
depending 
> on whether it is
> directed unicast or not. This fits in MPLS's 20-bit Label field with
one 
> bit indicating whether
> the RBridge nickname is the ingress (multicast) or egress (directed 
> unicast).
> 
> b) TTL
> 
> c) priority

Of these, only the TTL seems absolutely required; that includes the ones
below. Keeping the shim minimal seems important (to reduce MTU impact,
in particular). If further IP functionality is required - e.g., diffserv
code point-like f-tags, or source-routes-like LIDs - then perhaps we
shouldn't be doing this at the link layer, IMO.

Joe

> ****************
> The proposed extra fields for the shim header are:
> a) have BOTH ingress and egress RBridge nicknames, and shrink the 
> nicknames down to 16 bits.
> The reason for this is that in the case of directed unicast policy
(such 
> as source address filtering)
> can be applied to ingress as well as egress RBridge).
> 
> b) F-Tag: I think of this as a metric identifier, proposed length 
> 10-bits. This enables setting multiple
> costs for each link, and calculating paths and trees differently for 
> different types of traffic
> 
> c) egress LID ("local identifier"). This is for the convenience of the

> egress RBridge---for example, it could
> be the port onto which the (decapsulated) frame should be forwarded.
It 
> saves the egress RBridge
> from looking up the destination address in the original frame (since
the 
> ingress RBridge already
> had to do that work). The ingress RBridge knew the LID to put in
because 
> the egress RBridge had
> announced (my nickname, LID) for that destination. The ingress RBridge

> does not interpret the LID---just
> sticks it into the shim header.
> 
> d) ingress LID  The only reason I think to have an ingress
> LID is in case at some point in the future learning of (destination
MAC 
> address corresponds to
> egress RBridge, LID) is done based on looking at data packets. 
> Otherwise, this would be learned
> from link state advertisements, and only one LID (egress LID) would be

> in the shim.
> 
> Anyway---the format of the shim is something we really should decide
on 
> and attempt to never change
> in the future. I don't have strong opinions. What do other people
think?
> 
> If you care about any of these fields (pro or con) start a thread with

> subject line, e.g., "F-tag in shim header".
> Or maybe I'll do it. Or for now, reply to this note with opinions
about 
> any of the fields.
> 
> Thanks,
> 
> Radia
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

Date: Wed, 11 Oct 2006 21:45:51 -0700
From: Joe Touch <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] New fields in shim header?
Status: RO
Content-Length: 4139

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig05B4170C801B97AA879E80D9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Radia Perlman wrote:
> Silvano Gai has posted an interest draft suggesting new fields for the =

> shim header.
> The draft is at:
> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.tx=
t
>=20
> If new fields are added, we'll have to give up on the MPLS-like=20
> encoding, and the shim header
> would be slightly larger, so we should consider each of these fields an=
d=20
> see whether people think
> the functionality they give warrants the extra space in the shim header=
=2E
>=20
> I think it might be best to start a thread about each field separately.=
=20
> But I'll summarize here.
>=20
> The current shim header contains:
> a) RBridge nickname, which is either egress or ingress RBridge dependin=
g=20
> on whether it is
> directed unicast or not. This fits in MPLS's 20-bit Label field with on=
e=20
> bit indicating whether
> the RBridge nickname is the ingress (multicast) or egress (directed=20
> unicast).
>=20
> b) TTL
>=20
> c) priority

Of these, only the TTL seems absolutely required; that includes the ones
below. Keeping the shim minimal seems important (to reduce MTU impact,
in particular). If further IP functionality is required - e.g., diffserv
code point-like f-tags, or source-routes-like LIDs - then perhaps we
shouldn't be doing this at the link layer, IMO.

Joe

> ****************
> The proposed extra fields for the shim header are:
> a) have BOTH ingress and egress RBridge nicknames, and shrink the=20
> nicknames down to 16 bits.
> The reason for this is that in the case of directed unicast policy (suc=
h=20
> as source address filtering)
> can be applied to ingress as well as egress RBridge).
>=20
> b) F-Tag: I think of this as a metric identifier, proposed length=20
> 10-bits. This enables setting multiple
> costs for each link, and calculating paths and trees differently for=20
> different types of traffic
>=20
> c) egress LID ("local identifier"). This is for the convenience of the =

> egress RBridge---for example, it could
> be the port onto which the (decapsulated) frame should be forwarded. It=
=20
> saves the egress RBridge
> from looking up the destination address in the original frame (since th=
e=20
> ingress RBridge already
> had to do that work). The ingress RBridge knew the LID to put in becaus=
e=20
> the egress RBridge had
> announced (my nickname, LID) for that destination. The ingress RBridge =

> does not interpret the LID---just
> sticks it into the shim header.
>=20
> d) ingress LID  The only reason I think to have an ingress
> LID is in case at some point in the future learning of (destination MAC=
=20
> address corresponds to
> egress RBridge, LID) is done based on looking at data packets.=20
> Otherwise, this would be learned
> from link state advertisements, and only one LID (egress LID) would be =

> in the shim.
>=20
> Anyway---the format of the shim is something we really should decide on=
=20
> and attempt to never change
> in the future. I don't have strong opinions. What do other people think=
?
>=20
> If you care about any of these fields (pro or con) start a thread with =

> subject line, e.g., "F-tag in shim header".
> Or maybe I'll do it. Or for now, reply to this note with opinions about=
=20
> any of the fields.
>=20
> Thanks,
>=20
> Radia
>=20
>=20
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

--------------enig05B4170C801B97AA879E80D9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig05B4170C801B97AA879E80D9--

Date: Wed, 11 Oct 2006 14:46:43 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] New fields in shim header?
Status: RO
Content-Length: 2674

Silvano Gai has posted an interest draft suggesting new fields for the 
shim header.
The draft is at:
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt

If new fields are added, we'll have to give up on the MPLS-like 
encoding, and the shim header
would be slightly larger, so we should consider each of these fields and 
see whether people think
the functionality they give warrants the extra space in the shim header.

I think it might be best to start a thread about each field separately. 
But I'll summarize here.

The current shim header contains:
a) RBridge nickname, which is either egress or ingress RBridge depending 
on whether it is
directed unicast or not. This fits in MPLS's 20-bit Label field with one 
bit indicating whether
the RBridge nickname is the ingress (multicast) or egress (directed 
unicast).

b) TTL

c) priority

****************
The proposed extra fields for the shim header are:
a) have BOTH ingress and egress RBridge nicknames, and shrink the 
nicknames down to 16 bits.
The reason for this is that in the case of directed unicast policy (such 
as source address filtering)
can be applied to ingress as well as egress RBridge).

b) F-Tag: I think of this as a metric identifier, proposed length 
10-bits. This enables setting multiple
costs for each link, and calculating paths and trees differently for 
different types of traffic

c) egress LID ("local identifier"). This is for the convenience of the 
egress RBridge---for example, it could
be the port onto which the (decapsulated) frame should be forwarded. It 
saves the egress RBridge
from looking up the destination address in the original frame (since the 
ingress RBridge already
had to do that work). The ingress RBridge knew the LID to put in because 
the egress RBridge had
announced (my nickname, LID) for that destination. The ingress RBridge 
does not interpret the LID---just
sticks it into the shim header.

d) ingress LID  The only reason I think to have an ingress
LID is in case at some point in the future learning of (destination MAC 
address corresponds to
egress RBridge, LID) is done based on looking at data packets. 
Otherwise, this would be learned
from link state advertisements, and only one LID (egress LID) would be 
in the shim.

Anyway---the format of the shim is something we really should decide on 
and attempt to never change
in the future. I don't have strong opinions. What do other people think?

If you care about any of these fields (pro or con) start a thread with 
subject line, e.g., "F-tag in shim header".
Or maybe I'll do it. Or for now, reply to this note with opinions about 
any of the fields.

Thanks,

Radia

Content-class: urn:content-classes:message
Date: Wed, 11 Oct 2006 10:22:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] WG Meeting in San Diego schedule
Status: RO
Content-Length: 432

Hi,

The TRILL Working Group meeting at the November IETF meeting in San
Diego has been tentatively scheduled for Tuesday morning, 0900 to 1130.
This could change but will probably remain stable.

Thanks,
Donald

 =========================================================
 Donald E. Eastlake III       [email-masked]
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive
 Marlboro, MA 01752 USA

Content-class: urn:content-classes:message
Date: Tue, 10 Oct 2006 23:06:43 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] draft-gray-trill-routing-reqs-01.txt
Status: RO
Content-Length: 2024

Hi Eric,

Thanks for your improvements to this draft also.

I've again deleted below the cases where we completely agreed and
responded to the one where I have something to say. See at @@@ 

-----Original Message-----
From: Gray, Eric [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 3:56 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: [rbridge] draft-gray-trill-routing-reqs-01.txt

Donald,

	The following is the disposition with respect to your comments
on the Routing Requirements draft.  I have made other - relatively minor
- changes to this draft and will be submitting it to the Internet Drafts
site shortly.

@@@ (numerous cases of agreement deleted here)

	Page 8, section 4.3, last line, replace "interactions with 
	bridges" with "interactions between routers and bridges".

	As a general comment, this draft spends more time than it 
	needs to on co-located routers and RBridges. It's okay to 
	mention that as it makes particularly clear the need to be 
	able to distinguish routing protocol messages used for 
	routing and for RBridge interaction but I'm not the sort 
	of co-location needs to be mentioned so much.

		? - there are a total of 4 instances of use of the 
		word "co-located" (or "colocated" as it was before)
		and - of those - one could be removed without loss
		of information.  However, that one instance serves 
		as a parenthetical reminder in the sentence:

@@@ My comment was based on my general impression. I hadn't counted
instances...

		"there may be specific requirements imposed on the
		interactions [...] between RBridge instances and
		(potentially co-located) IP routing instances."

		It's parenthetical, I think it adds value, and it
		is a single (extra) instance that could hardly be
		thought to wear out the expression.

		However, if other people feel that it doesn't add
		value, I will be happy to take it out.
 
--- [SNIP] ---

@@@ ^ This is how me mail ends... Was there any additional material?

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Tue, 10 Oct 2006 22:45:54 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.txt
Status: RO
Content-Length: 8390

Hi Eric,

Thanks for your improvements to the draft and details responses below.

I'll delete below the [ many :-) ] ones where we completely agreed and respond to the others where I have something to say. See at @@@ 

-----Original Message-----
From: Gray, Eric [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 7:25 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.txt

Donald (et al),

Here is my response on your (Donald's) comments:

	Abstract: I'm not familiar with the term "cross-section 
	bandwidth".  Suggest "... to provide higher aggregate 
	throughput & more robust behavior under link interruption 
	or rapidly varying topologoy than an ..."

		Replaced with "higher aggregate throughput".

		It's possible that "cross-section badwidth" is
		more accurate, but - even if it is - what's the
		point in being more accurate but not understood?

@@@ OK.

	Page 4, 3rd paragraph, next to last line, replace "all
	available" with "optimized".

		Replaced "all available" with "an optimized subset 
		of all available" - using "optimized" to replace
		"all available" implies that STP results in sub-
		optimal paths.  That is not necessarily true (and
		is likely to offend some people); what is true is 
		that STP results in sub-optimal use of available 
		paths.  

		Even that statement makes assumptions about loop
		prevention/avoidance/mitigation behaviors.  It is
		not "optimal use of available bandwidth" if I am
		able to use twice as many links, but use 60% of 
		of the combined link capacity in "clocking down" 
		TTL on looping traffic.

@@@ OK, but I think even the most ardent fan of STP would admit that the use of one spanning tree for forwarding can result in non-optimal paths for unicast frames.

	Page 10, 2nd bullet. Actually, I think it would be nice 
	if we could drop all occurrences of "Switch" since it 
	seems to randomly be used for bridges and routers and 
	who knows what. I think of it as more a marketing than a 
	technical term. At the end of this item, did you actually 
	mean "exclude"? Or "execute"? Or how about "exclude or
	execute"? ;-)

		Deleted the bullet and all instances of use of the
		word "switch."  Actually, the definition did have
		a purpose at one time - specifically relating to 
		the fact that switches can be anything from a weak
		bridge (that doesn't do STP, for instance) to an 
		almost router.

		The discussion came up on the list (and carried on
		off the list) when Harald Alvestrand observed that
		he found some "work group switches" apparently do
		not do STP at all.

		It was a consideration at the time that we may 
		have to deal with potential loops inserted by a
		lame bridge.  However, I believe we eventually
		concluded that this is not an RBridge-specific
		problem - hence not one we have to solve.

@@@ OK.

	Page 14, section 3.2.2, 1st line. Does "special-case" 
	really add anything? How about dropping it?

		Reworded this.  "Special- case" is not the right
		word.  CFT-IRT entries are distinct from the CFT
		entries.  It's hard to go very far into how they
		differ, however, without making assumptions about
		protocol and implementation.

		Hopefully it will be clearer now.

@@@ OK.

	Page 16, section 3.2.3, 1st paragraph: looks like the 
	first "see Section" refers to Section 3.1. Not so sure 
	about the 2nd reference...

		Removed both references.  The ****** document 
		processing software substitutes "0" for any 
		cross-reference when the reference is deleted.

		The referenced section was removed as a result
		of moving some of the "options" completely out
		of the last version.  Since the referenced text
		was deemed not required, the references were
		OBE.

		I am not happy with the way that this section 
		is worded.  I would be very happy to get some
		sort of suggestions as to how to fix it.

		What the section is describing is how a CTT 
		(CRED Transit Table) is used by an ingress 
		RBridge to inject frames on a "tunnel" toward 
		appropriate egress RBridge(s).

		I think I can hijack some text from an RFC I am
		familiar with, later, that has to describe the 
		same sort of problem.

@@@ Fine if you can improve it, but it doesn't seem so bad to me.

	Page 19, section 4.2, 2nd paragraph: This can be read 
	to imply that the discovery protocol messages are 
	flooded. How about changing the first sentence to read 
	"The discovery mechanisms must use protocol messages
	which propagate information through ..."

		They should be flooded - at least until consumed
		by a peer RBridge.  Therefore I am happy to hear
		that it sounds that way.  See below.  If RBridge
		discovery protocol is distributed - on a LAN (or 
		perhaps I should say bridged segment) - by means
		other than "blind flooding" (broadcast), the only
		way we can make sure that every RBridge is found
		is to have 'a priori' knowledge of topology and
		what types of devices are included.

		However, I take your point, and I believe I made
		it clearer that the peer discovery is not flooded
		throughout an entire broadcast domain.  It should
		be a one-hop protocol where messages are consumed
		by a peer, chewed and (possibly) emitted (in some
		modified form) on links that might connect to 
		additional peers.

		I replaced the second paragraph with:

"The discovery mechanisms must use protocol messages which will be propagated throughout a LAN (or broadcast domain) until they are consumed by another RBridge.  This must happen in order to ensure that RBridges in the same broadcast domain are discovered by their peers as required to allow for accurate determination of RBridge topology."

@@@ OK.

	Page 20, 3rd & 4th paragraphs, beginning - 

	"Rbridges must..." 

	and 

	"Note that...": 

	Both paragraphs include the phrase "same type" which 
	I don't understand in the context...

		Modified - hopefully should be clearer.  "Same
		type" means RBridge control frames.  The point
		is that RBridges which cannot consume a frame
		- even if it is an RBridge control frame - must
		forward it according to existing L2 forwarding
		rules.  Otherwise, it is possible to black-hole
		a co-existing discovery protocol and create an
		undiscovered "loopy" configuration.

@@@ OK.

	Page 20, 5th paragraph. Reference seems to be to 
	"section 4.8".

		DONE - also added discussion of the "wiring 
		closet" problem to this section (4.8, that is).

		On this subject, the squishy sense of the room
		at the last meeting (very accurately captured
		in the minutes) was that we need to figure out
		if we can address it, how, and whether or not
		we should.

		I think the added text does this - at least to
		the degree it is appropriate for this draft to
		do so.  I think the WG needs to make that call
		and - when we do - the results should be in the
		protocol specification.

		I got a good deal of help on this from Stewart
		Bryant and Guillermo Ib??ez (though they have
		not seen the current text - so, if you don't
		like what I wrote, it isn't their fault).

@@@ I'm not so sure that we necessarily have to solve the problem of a wiring closet with bridges in it. Maybe, if it works when you replace the bridges with rbridges, which I think it does, we are OK. Seems like this rbridge deployment solution to the problem should be mentioned. Also, in reference to the last paragraph of that section, I don't actually see a chicken-and-egg problem if a bridge-STP function incorporated into an rbridge acts as if it were a separate outboard bridge on each STP port...

As a by the way, the only other comments I saw on the list since the last meeting (and maybe those were slightly before or even during the meeting) that might apply to the arch doc was one from Radia that we need to make it clearer in these specifications we are not trying to prohibit configuration.

I looked at the text on configuration in the architecture draft and cannot find any that is not reasonably clear on this.  However, my ideas on what is clear about text I've bee working on should be suspect.

I would appreciate it if people could give me examples of specific text where things like this are not clear.

Also, anybody, feel free to comment on the changes above.

@@@ I agree that it would be good to see additional review and comment on this draft.

@@@ Thanks,
@@@ Donald

--
Eric