[rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
sgai at nuovasystems.com (Silvano Gai) Wed, 01 November 2006 06:20 UTC
From: "sgai at nuovasystems.com"
Date: Tue, 31 Oct 2006 22:20:53 -0800
Subject: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt
Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4BA77@nuova-ex1.hq.nuovaimpresa.com>
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 -- > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA16KtQo011522 for <rbridge@postel.org>; Tue, 31 Oct 2006 22:20:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 22:20:53 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4BA77@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt Thread-Index: Acb9PgksMI9zChUBS8Wlaz6ot7GBNwAPwjOQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA16KtQo011522 Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Nov 2006 06:21:39 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 2:44 PM > To: Silvano Gai > Cc: rbridge@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@nuovasystems.com] > --> Sent: Tuesday, October 31, 2006 5:34 PM > --> To: Gray, Eric > --> Cc: rbridge@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@marconi.com] > --> > Sent: Tuesday, October 31, 2006 1:46 PM > --> > To: Silvano Gai > --> > Cc: rbridge@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 -- > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA168A4w007638 for <rbridge@postel.org>; Tue, 31 Oct 2006 22:08:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 22:08:09 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4BA74@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt Thread-Index: Acb9EX8zTPJHusFtRe+8tfDCGrIOewAamsxg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA168A4w007638 Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Nov 2006 06:08:18 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 9:25 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA165xxh006582 for <rbridge@postel.org>; Tue, 31 Oct 2006 22:05:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 22:05:57 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4BA72@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt Thread-Index: Acb9EKZ9X+doZmqOTlCzTGKYuKpcWAAafGGw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA165xxh006582 Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Nov 2006 06:06:19 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 9:19 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Monday, October 30, 2006 12:13 PM > --> To: rbridge@postel.org > --> 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 ... Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA15tHbl002270 for <rbridge@postel.org>; Tue, 31 Oct 2006 21:55:18 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 21:55:16 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4BA6C@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLANs Thread-Index: Acb9DoHmaqaeShEuQpqiUTK5BlsgFAAZXg1w From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA15tHbl002270 Cc: rbridge@postel.org Subject: Re: [rbridge] VLANs X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Nov 2006 05:55:47 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 9:04 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Monday, October 30, 2006 12:29 PM > --> To: rbridge@postel.org > --> 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id kA159qsI017846 for <rbridge@postel.org>; Tue, 31 Oct 2006 21:09:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 21:09:51 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4BA5F@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] New shim header proposal---without F-tag field Thread-Index: Acb9DOf2SFUr7vsTTMuECQxh7ZzIeQAZg7dw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id kA159qsI017846 Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 01 Nov 2006 05:10:16 -0000 Status: RO Content-Length: 4781 Eric, > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Gray, Eric > Sent: Tuesday, October 31, 2006 8:48 AM > To: Radia Perlman; rbridge@postel.org > 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman > --> Sent: Monday, October 30, 2006 9:50 PM > --> To: rbridge@postel.org > --> 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VMhodb017208 for <rbridge@postel.org>; Tue, 31 Oct 2006 14:43:51 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VMhmfK017783; Tue, 31 Oct 2006 17:43:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14422; Tue, 31 Oct 2006 17:43:48 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CBBWW>; Tue, 31 Oct 2006 17:43:47 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA04E6@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 17:43:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 22:44:14 -0000 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:sgai@nuovasystems.com] --> Sent: Tuesday, October 31, 2006 5:34 PM --> To: Gray, Eric --> Cc: rbridge@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@marconi.com] --> > Sent: Tuesday, October 31, 2006 1:46 PM --> > To: Silvano Gai --> > Cc: rbridge@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 -- --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VMZpdo013852 for <rbridge@postel.org>; Tue, 31 Oct 2006 14:35:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 14:35:50 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B9AE@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt Thread-Index: Acb9E/dj5Y+3FXhBQxKIabQxVMGkGwAKNr6Q From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9VMZpdo013852 Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 22:36:00 -0000 Status: RO Content-Length: 1201 Eric, Inline > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 9:43 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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 -- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VMYNKP013284 for <rbridge@postel.org>; Tue, 31 Oct 2006 14:34:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 14:34:21 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B9AD@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt Thread-Index: Acb9NgeySXocHwrARGmd5padtEvLTgABh77A From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9VMYNKP013284 Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 22:34:38 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 1:46 PM > To: Silvano Gai > Cc: rbridge@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 -- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VMX2aH012803 for <rbridge@postel.org>; Tue, 31 Oct 2006 14:33:03 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VMX0fK017694; Tue, 31 Oct 2006 17:33:01 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13990; Tue, 31 Oct 2006 17:33:00 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CBBS8>; Tue, 31 Oct 2006 17:33:00 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA04E4@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "'Eastlake III Donald-LDE008'" <Donald.Eastlake@motorola.com> Date: Tue, 31 Oct 2006 17:33:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: "'rbridge@postel.org'" <rbridge@postel.org> Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 22:33:42 -0000 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: rbridge@postel.org --> 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:Donald.Eastlake@motorola.com] --> --> Sent: Tuesday, October 31, 2006 2:36 PM --> --> To: Gray, Eric; rbridge@postel.org --> --> 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:Eric.Gray@marconi.com] --> --> Sent: Tuesday, October 31, 2006 2:21 PM --> --> To: Eastlake III Donald-LDE008; rbridge@postel.org --> --> 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: rbridge-bounces@postel.org --> --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> Eastlake III --> --> --> Donald-LDE008 --> --> --> Sent: Tuesday, October 31, 2006 2:03 PM --> --> --> To: rbridge@postel.org --> --> --> 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: rbridge-bounces@postel.org --> --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White --> --> --> Sent: Tuesday, October 31, 2006 9:19 AM --> --> --> To: Radia Perlman --> --> --> Cc: rbridge@postel.org --> --> --> 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 --> --> --> > rbridge@postel.org --> --> --> > 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 --> --> --> rbridge@postel.org --> --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> --> --> --> _______________________________________________ --> --> --> rbridge mailing list --> --> --> rbridge@postel.org --> --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> --> --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VMNJr3009541 for <rbridge@postel.org>; Tue, 31 Oct 2006 14:23:19 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VMNFfK017578; Tue, 31 Oct 2006 17:23:15 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13605; Tue, 31 Oct 2006 17:22:26 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CBBPH>; Tue, 31 Oct 2006 17:22:26 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA04E2@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Date: Tue, 31 Oct 2006 17:22:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 22:23:31 -0000 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:Donald.Eastlake@motorola.com] --> Sent: Tuesday, October 31, 2006 2:36 PM --> To: Gray, Eric; rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> Sent: Tuesday, October 31, 2006 2:21 PM --> To: Eastlake III Donald-LDE008; rbridge@postel.org --> 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III --> --> Donald-LDE008 --> --> Sent: Tuesday, October 31, 2006 2:03 PM --> --> To: rbridge@postel.org --> --> 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White --> --> Sent: Tuesday, October 31, 2006 9:19 AM --> --> To: Radia Perlman --> --> Cc: rbridge@postel.org --> --> 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 --> --> > rbridge@postel.org --> --> > 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 --> --> rbridge@postel.org --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> --> _______________________________________________ --> --> rbridge mailing list --> --> rbridge@postel.org --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VM0Cjw001660 for <rbridge@postel.org>; Tue, 31 Oct 2006 14:00:12 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VM09fK017327; Tue, 31 Oct 2006 17:00:10 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12669; Tue, 31 Oct 2006 17:00:09 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CBBHG>; Tue, 31 Oct 2006 17:00:09 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA04DD@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia Perlman <Radia.Perlman@sun.com>, "Gray, Eric" <Eric.Gray@marconi.com> Date: Tue, 31 Oct 2006 17:00:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 22:00:33 -0000 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:Radia.Perlman@sun.com] --> Sent: Tuesday, October 31, 2006 4:49 PM --> To: Gray, Eric --> Cc: Dinesh G Dutt; rbridge@postel.org --> 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 --> > --> > --> > --> Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VLmkvd027304 for <rbridge@postel.org>; Tue, 31 Oct 2006 13:48:46 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J80002DHSL5V910@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 31 Oct 2006 13:48:41 -0800 (PST) Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J80009KNSL4T3B0@mail.sunlabs.com> for rbridge@postel.org; Tue, 31 Oct 2006 13:48:41 -0800 (PST) Date: Tue, 31 Oct 2006 13:48:40 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <0BF76B30C100624BA997C9CED19D8125BA0472@uspitsmsgusr08.pit.comms.marconi.com> To: "Gray, Eric" <Eric.Gray@marconi.com> Message-id: <4547C4B8.2090904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <0BF76B30C100624BA997C9CED19D8125BA0472@uspitsmsgusr08.pit.comms.marconi.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 21:49:02 -0000 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 > > > Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VLkWeJ026138 for <rbridge@postel.org>; Tue, 31 Oct 2006 13:46:32 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VLkUfK017175; Tue, 31 Oct 2006 16:46:30 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA11805; Tue, 31 Oct 2006 16:46:29 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CBBB1>; Tue, 31 Oct 2006 16:46:29 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA04D8@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 16:46:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 21:47:05 -0000 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 -- Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9VJaqw1008199 for <rbridge@postel.org>; Tue, 31 Oct 2006 11:36:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1162323391!6650728!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 4557 invoked from network); 31 Oct 2006 19:36:31 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-7.tower-119.messagelabs.com with SMTP; 31 Oct 2006 19:36:31 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id k9VJekPf001359 for <rbridge@postel.org>; Tue, 31 Oct 2006 12:40:47 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k9VJaKvP029559 for <rbridge@postel.org>; Tue, 31 Oct 2006 13:36:21 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 14:36:19 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790019CA852@de01exm64.ds.mot.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125BA0484@uspitsmsgusr08.pit.comms.marconi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] New shim header proposal---without F-tag field thread-index: Acb9IgVZMCb8MaXcS02lxSHusgEWqgAACrsw From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9VJaqw1008199 Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 19:37:40 -0000 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:Eric.Gray@marconi.com] Sent: Tuesday, October 31, 2006 2:21 PM To: Eastlake III Donald-LDE008; rbridge@postel.org 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III --> Donald-LDE008 --> Sent: Tuesday, October 31, 2006 2:03 PM --> To: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White --> Sent: Tuesday, October 31, 2006 9:19 AM --> To: Radia Perlman --> Cc: rbridge@postel.org --> 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 --> > rbridge@postel.org --> > 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VJLww6029759 for <rbridge@postel.org>; Tue, 31 Oct 2006 11:21:59 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VJLLfK014664; Tue, 31 Oct 2006 14:21:21 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01998; Tue, 31 Oct 2006 14:21:21 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA9K2>; Tue, 31 Oct 2006 14:21:20 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0484@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, rbridge@postel.org Date: Tue, 31 Oct 2006 14:21:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 19:22:36 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake --> III Donald-LDE008 --> Sent: Tuesday, October 31, 2006 2:03 PM --> To: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Russ White --> Sent: Tuesday, October 31, 2006 9:19 AM --> To: Radia Perlman --> Cc: rbridge@postel.org --> 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 --> > rbridge@postel.org --> > 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9VJ4JJG021630 for <rbridge@postel.org>; Tue, 31 Oct 2006 11:04:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1162321360!3207223!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28354 invoked from network); 31 Oct 2006 19:02:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 31 Oct 2006 19:02:40 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9VJ2Wum008584 for <rbridge@postel.org>; Tue, 31 Oct 2006 12:02:36 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k9VJ2WcP023594 for <rbridge@postel.org>; Tue, 31 Oct 2006 13:02:32 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 14:02:31 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790019CA7EA@de01exm64.ds.mot.com> In-Reply-To: <45475B46.8000707@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] New shim header proposal---without F-tag field thread-index: Acb8+DqX+beg4ol7TS6fJsYW/rX4IAAIfMaA From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9VJ4JJG021630 Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 19:05:18 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Russ White Sent: Tuesday, October 31, 2006 9:19 AM To: Radia Perlman Cc: rbridge@postel.org 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 > rbridge@postel.org > 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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VJ3hW7021465 for <rbridge@postel.org>; Tue, 31 Oct 2006 11:03:43 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VJ3ffK014317; Tue, 31 Oct 2006 14:03:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00839; Tue, 31 Oct 2006 14:03:40 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA802>; Tue, 31 Oct 2006 14:03:40 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0472@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia Perlman <Radia.Perlman@sun.com>, Dinesh G Dutt <ddutt@cisco.com> Date: Tue, 31 Oct 2006 14:03:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 19:04:06 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> Sent: Tuesday, October 31, 2006 1:06 PM --> To: Dinesh G Dutt --> Cc: rbridge@postel.org --> 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 --> >> rbridge@postel.org --> >> http://mailman.postel.org/mailman/listinfo/rbridge --> >> --> >> --> > --> > --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VI65tJ029920 for <rbridge@postel.org>; Tue, 31 Oct 2006 10:06:05 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J8000212IA0V910@dps.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 31 Oct 2006 10:06:00 -0800 (PST) Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J800090II9XT3B0@mail.sunlabs.com> for rbridge@postel.org; Tue, 31 Oct 2006 10:05:58 -0800 (PST) Date: Tue, 31 Oct 2006 10:05:57 -0800 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <45476ACF.8090004@cisco.com> To: Dinesh G Dutt <ddutt@cisco.com> Message-id: <45479085.9000900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <4546B9D0.7070305@sun.com> <45476ACF.8090004@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 18:06:24 -0000 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 >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VHggE0014326 for <rbridge@postel.org>; Tue, 31 Oct 2006 09:42:42 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VHgefK012533; Tue, 31 Oct 2006 12:42:40 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23931; Tue, 31 Oct 2006 12:42:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA7HL>; Tue, 31 Oct 2006 12:42:39 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA043F@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 12:42:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 17:42:54 -0000 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 -- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VHP1mY007209 for <rbridge@postel.org>; Tue, 31 Oct 2006 09:25:02 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VHP0fK008094; Tue, 31 Oct 2006 12:25:00 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA16256; Tue, 31 Oct 2006 12:24:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA682>; Tue, 31 Oct 2006 12:24:59 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA042F@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 12:24:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 17:25:17 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VHIwW9005060 for <rbridge@postel.org>; Tue, 31 Oct 2006 09:18:58 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VHIufK008019; Tue, 31 Oct 2006 12:18:56 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15973; Tue, 31 Oct 2006 12:18:55 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA653>; Tue, 31 Oct 2006 12:18:55 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0429@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 12:18:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Comments on: http://www.ietf.org/internet-drafts/dr aft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 17:19:39 -0000 Status: RO Content-Length: 2088 Silvano, See comments below... --> -----Original Message----- --> From: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Monday, October 30, 2006 12:13 PM --> To: rbridge@postel.org --> 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 ... Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VH3cNv028960 for <rbridge@postel.org>; Tue, 31 Oct 2006 09:03:38 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VH3ZfK007749; Tue, 31 Oct 2006 12:03:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14822; Tue, 31 Oct 2006 12:03:35 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA6QB>; Tue, 31 Oct 2006 12:03:35 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA041E@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 12:03:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] VLANs X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 17:05:07 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Monday, October 30, 2006 12:29 PM --> To: rbridge@postel.org --> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VH2OJY028260 for <rbridge@postel.org>; Tue, 31 Oct 2006 09:02:24 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 09:02:22 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B8C0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] New shim header proposal---without F-tag field Thread-Index: Acb9CtzRM0O9sNQsT/OE7rfAQuD2vAAAz8Bg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9VH2OJY028260 Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 17:03:22 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 31, 2006 8:37 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Tuesday, October 31, 2006 11:02 AM > --> To: Dinesh G Dutt; Radia Perlman > --> Cc: rbridge@postel.org > --> 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] > --> On > --> > Behalf Of Dinesh G Dutt > --> > Sent: Tuesday, October 31, 2006 7:25 AM > --> > To: Radia Perlman > --> > Cc: rbridge@postel.org > --> > 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 > --> > > rbridge@postel.org > --> > > 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 > --> > rbridge@postel.org > --> > http://mailman.postel.org/mailman/listinfo/rbridge > --> > --> _______________________________________________ > --> rbridge mailing list > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VGlgTK022983 for <rbridge@postel.org>; Tue, 31 Oct 2006 08:47:43 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VGlgfK007437; Tue, 31 Oct 2006 11:47:42 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13640; Tue, 31 Oct 2006 11:47:41 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA6F4>; Tue, 31 Oct 2006 11:47:41 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0419@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia Perlman <Radia.Perlman@sun.com>, rbridge@postel.org Date: Tue, 31 Oct 2006 11:47:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 16:48:35 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> Sent: Monday, October 30, 2006 9:50 PM --> To: rbridge@postel.org --> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VGbWXA019327 for <rbridge@postel.org>; Tue, 31 Oct 2006 08:37:33 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9VGbTfK007227; Tue, 31 Oct 2006 11:37:29 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13013; Tue, 31 Oct 2006 11:37:28 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8CA50P>; Tue, 31 Oct 2006 11:37:28 -0500 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0410@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 31 Oct 2006 11:37:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 16:38:16 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Tuesday, October 31, 2006 11:02 AM --> To: Dinesh G Dutt; Radia Perlman --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] --> On --> > Behalf Of Dinesh G Dutt --> > Sent: Tuesday, October 31, 2006 7:25 AM --> > To: Radia Perlman --> > Cc: rbridge@postel.org --> > 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 --> > > rbridge@postel.org --> > > 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 --> > rbridge@postel.org --> > http://mailman.postel.org/mailman/listinfo/rbridge --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VG1xFw006776 for <rbridge@postel.org>; Tue, 31 Oct 2006 08:01:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Oct 2006 08:01:58 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B8B2@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] New shim header proposal---without F-tag field Thread-Index: Acb9AgTj9+A1G10RTYirJwWC4Leb8wAA0pcA From: "Silvano Gai" <sgai@nuovasystems.com> To: "Dinesh G Dutt" <ddutt@cisco.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9VG1xFw006776 Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 16:03:24 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Dinesh G Dutt > Sent: Tuesday, October 31, 2006 7:25 AM > To: Radia Perlman > Cc: rbridge@postel.org > 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 > > rbridge@postel.org > > 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VFP4U8022730 for <rbridge@postel.org>; Tue, 31 Oct 2006 07:25:04 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 07:25:04 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VFP4jw018844; Tue, 31 Oct 2006 07:25:04 -0800 Received: from [10.21.97.29] (sjc-vpn1-285.cisco.com [10.21.97.29]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VFP4Ao002126; Tue, 31 Oct 2006 07:25:04 -0800 (PST) Message-ID: <45476ACF.8090004@cisco.com> Date: Tue, 31 Oct 2006 07:25:03 -0800 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20061021) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <4546B9D0.7070305@sun.com> In-Reply-To: <4546B9D0.7070305@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2902; t=1162308304; x=1163172304; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20New=20shim=20header=20proposal---without=20F-tag=20f ield; X=v=3Dcisco.com=3B=20h=3DmG0Tg0FzmaJ3jC2/iBNg1qQ7c04=3D; b=fq5AM0t/mjcQktfC84jY1rPtRnlURzmOueDXJ4hW/33nn+hAwdYV7ggDvpCV3xbHx7lxOxLo BhgiM8+Vi3h+I45DNXYkiDyjHS7iIWrct5NcqL9QlmtKO+POSTWQh7aG; Authentication-Results: sj-dkim-1.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 15:25:23 -0000 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 > rbridge@postel.org > 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 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VFMqMl021940 for <rbridge@postel.org>; Tue, 31 Oct 2006 07:22:53 -0800 (PST) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 07:22:52 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VFMqlH025129; Tue, 31 Oct 2006 07:22:52 -0800 Received: from [10.21.97.29] (sjc-vpn1-285.cisco.com [10.21.97.29]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VFMqbF023972; Tue, 31 Oct 2006 07:22:52 -0800 (PST) Message-ID: <45476A4C.7060307@cisco.com> Date: Tue, 31 Oct 2006 07:22:52 -0800 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20061021) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <4546B9D0.7070305@sun.com> In-Reply-To: <4546B9D0.7070305@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2836; t=1162308172; x=1163172172; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20New=20shim=20header=20proposal---without=20F-tag=20f ield; X=v=3Dcisco.com=3B=20h=3DmG0Tg0FzmaJ3jC2/iBNg1qQ7c04=3D; b=cgNHE6jrT0VV0PcknSX1LkZlyDuyTl1XToJSA4z352Z1zMpS2p+Es7VRFAglAzrFSAlqQEqV Icoa4LULdKbwof923QjIsonKgxYotZC2z47FqG73KpRcJ97dqmkufjMo; Authentication-Results: sj-dkim-7.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 15:23:12 -0000 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 > rbridge@postel.org > 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 Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9VEIl2x028534 for <rbridge@postel.org>; Tue, 31 Oct 2006 06:18:48 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Oct 2006 09:18:47 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VEIlVj009641; Tue, 31 Oct 2006 09:18:47 -0500 Received: from [64.102.48.121] (dhcp-64-102-48-121.cisco.com [64.102.48.121]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VEIkYJ002148; Tue, 31 Oct 2006 09:18:46 -0500 (EST) Message-ID: <45475B46.8000707@cisco.com> Date: Tue, 31 Oct 2006 09:18:46 -0500 From: Russ White <riw@cisco.com> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <4546B9D0.7070305@sun.com> In-Reply-To: <4546B9D0.7070305@sun.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3212; t=1162304327; x=1163168327; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20<riw@cisco.com> |Subject:Re=3A=20[rbridge]=20New=20shim=20header=20proposal---without=20F-tag=20f ield |To:Radia=20Perlman=20<Radia.Perlman@sun.com>; X=v=3Dcisco.com=3B=20h=3D5Uz0Fj7OuaHjsxE4lVFjtzPQJ9I=3D; b=LJbEnXg0MAv2w6TSyvkqt/NoTe9x7CLIry5DIDnbfAjgQMtooyvRmuRq7GchlNKbGoeKbDyp l2XruKAthAyyk8hRL/tME0JptURfnwv2vUKTbJGzuzjBAbqZQi0BuClQ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 14:19:22 -0000 Status: RO Content-Length: 3157 -----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 > rbridge@postel.org > 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----- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9V3WXbf010372 for <rbridge@postel.org>; Mon, 30 Oct 2006 19:32:33 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Oct 2006 19:32:30 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B87A@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] New shim header proposal---without F-tag field Thread-Index: Acb8m+NFmNvsfOcVS2WpfHx8b+FfpwAAS8Mg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9V3WXbf010372 Subject: Re: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 03:32:48 -0000 Status: RO Content-Length: 2883 Radia, Thank you for improving our proposal, Of course, I am in favor -- Silvano > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Monday, October 30, 2006 6:50 PM > To: rbridge@postel.org > 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9V2nv38029100 for <rbridge@postel.org>; Mon, 30 Oct 2006 18:49:57 -0800 (PST) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7Z0025ABV5V900@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 30 Oct 2006 18:49:53 -0800 (PST) Received: from sun.com ([129.150.22.255]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7Z0094DBV4T3A0@mail.sunlabs.com> for rbridge@postel.org; Mon, 30 Oct 2006 18:49:53 -0800 (PST) Date: Mon, 30 Oct 2006 18:49:52 -0800 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <4546B9D0.7070305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] New shim header proposal---without F-tag field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 31 Oct 2006 02:50:17 -0000 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 Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9UIAAcN000351 for <rbridge@postel.org>; Mon, 30 Oct 2006 10:10:11 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1162231809!8440906!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 32650 invoked from network); 30 Oct 2006 18:10:09 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-8.tower-119.messagelabs.com with SMTP; 30 Oct 2006 18:10:09 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id k9UIA8Bx003647 for <rbridge@postel.org>; Mon, 30 Oct 2006 12:10:08 -0600 (CST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k9UIA752018944 for <rbridge@postel.org>; Mon, 30 Oct 2006 12:10:07 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FC4E.A10508F2" Date: Mon, 30 Oct 2006 13:10:05 -0500 Message-ID: <3870C46029D1F945B1472F170D2D97900197F02D@de01exm64.ds.mot.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B6@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] A question onhttp://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt thread-index: Acb6n/PZevAOkmKyQFyTAesDwudq0QALNd3g From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Subject: Re: [rbridge] A question onhttp://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 30 Oct 2006 18:10:31 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai Sent: Saturday, October 28, 2006 10:47 AM To: rbridge@postel.org 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> </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> </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> </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> rbridge-bounces@postel.org=20 [mailto:rbridge-bounces@postel.org] <B>On Behalf Of </B>Silvano=20 Gai<BR><B>Sent:</B> Saturday, October 28, 2006 10:47 AM<BR><B>To:</B>=20 rbridge@postel.org<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> </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> </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">“</SPAN></FONT> 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"> 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"> 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">“<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> </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'"> =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'"> =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> </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> </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> </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-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9UHT5ki015368 for <rbridge@postel.org>; Mon, 30 Oct 2006 09:29:05 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Oct 2006 09:28:55 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B698@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VLANs Thread-Index: Acb8SOBsJzKj70VOTDawiXhOW+FS+A== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9UHT5ki015368 Subject: [rbridge] VLANs X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 30 Oct 2006 17:29:24 -0000 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9UHITut010916 for <rbridge@postel.org>; Mon, 30 Oct 2006 09:18:29 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Oct 2006 09:18:20 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B688@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Broadcsat/Multicast storm Thread-Index: Acb8R2W8oSAuFL1OTwS3CEz28MlHlQ== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9UHITut010916 Subject: [rbridge] Broadcsat/Multicast storm X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 30 Oct 2006 17:18:54 -0000 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9UHCxdY008961 for <rbridge@postel.org>; Mon, 30 Oct 2006 09:12:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Oct 2006 09:12:49 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B685@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt Thread-Index: Acb8RqATCLWKbziXTMKFyVkXRO/4dA== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9UHCxdY008961 Subject: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 30 Oct 2006 17:13:52 -0000 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 ... Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9THN7M4029781 for <rbridge@postel.org>; Sun, 29 Oct 2006 09:23:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Oct 2006 09:23:03 -0800 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5FE@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call comments to: http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt Thread-Index: Acb7fuQbcgNuaYWOR0u0ehoeYYH/5A== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9THN7M4029781 Subject: [rbridge] WG last call comments to: http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 29 Oct 2006 17:23:26 -0000 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 ... Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9T31eWE007511 for <rbridge@postel.org>; Sat, 28 Oct 2006 20:01:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1162090899!12368223!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25495 invoked from network); 29 Oct 2006 03:01:39 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 29 Oct 2006 03:01:39 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9T31cEs026051 for <rbridge@postel.org>; Sat, 28 Oct 2006 20:01:38 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k9T31ciT005273 for <rbridge@postel.org>; Sat, 28 Oct 2006 22:01:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 2006 23:01:37 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900197EC19@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tentative agenda uploaded thread-index: Acb7Box9MYZaizvDQOe5YZF89rpfBQ== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9T31eWE007511 Subject: [rbridge] Tentative agenda uploaded X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 29 Oct 2006 03:02:02 -0000 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 Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9T22o5d025425 for <rbridge@postel.org>; Sat, 28 Oct 2006 19:02:50 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7V00031KCPF700@dps.sfvic.sunlabs.com> for rbridge@postel.org; Sat, 28 Oct 2006 19:02:49 -0700 (PDT) Received: from sun.com ([129.150.20.126]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7V009AOKCLT370@mail.sunlabs.com> for rbridge@postel.org; Sat, 28 Oct 2006 19:02:46 -0700 (PDT) Date: Sat, 28 Oct 2006 19:02:45 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B6@nuova-ex1.hq.nuovaimpresa.com> To: Silvano Gai <sgai@nuovasystems.com> Message-id: <45440BC5.1030709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B6@nuova-ex1.hq.nuovaimpresa.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] A question on http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 29 Oct 2006 02:03:02 -0000 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 >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9T17KJw012926 for <rbridge@postel.org>; Sat, 28 Oct 2006 18:07:20 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Sat, 28 Oct 2006 18:07:08 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9F95A2B0; Sat, 28 Oct 2006 18:07:08 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 73C6F2AF; Sat, 28 Oct 2006 18:07:08 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJG28343; Sat, 28 Oct 2006 18:07:03 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 9003220501; Sat, 28 Oct 2006 18:07:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 28 Oct 2006 18:07:00 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE8F8@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125BA0109@uspitsmsgusr08.pit.comms.marconi.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 2nd Issue Thread-Index: Acb6HtTlZm/hZmMPSleBko9Qgt2JwAA1iJqA From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-WSS-ID: 695D213638S6052853-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9T17KJw012926 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 29 Oct 2006 01:07:37 -0000 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. Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9SFSZ4A019671 for <rbridge@postel.org>; Sat, 28 Oct 2006 08:28:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 2006 08:28:32 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B9@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb59SXLcPVMWNtUQXSQTZjd+F9YNgArRauQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9SFSZ4A019671 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 15:28:43 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Friday, October 27, 2006 11:21 AM > To: Gray, Eric > Cc: rbridge@postel.org > 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9SFG3t5016056 for <rbridge@postel.org>; Sat, 28 Oct 2006 08:16:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 2006 08:16:00 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B8@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue Thread-Index: Acb6FuepYgv8q/VBQtCKLKw8kdVNAwAjLoSg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9SFG3t5016056 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 15:16:16 -0000 Status: RO Content-Length: 6764 Eric, > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Gray, Eric > Sent: Friday, October 27, 2006 3:20 PM > To: Larry Kreeger (kreeger) > Cc: rbridge@postel.org > 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:kreeger@cisco.com] > --> Sent: Friday, October 27, 2006 5:26 PM > --> To: Gray, Eric > --> Cc: rbridge@postel.org > --> 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9SExRp7010542 for <rbridge@postel.org>; Sat, 28 Oct 2006 07:59:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 2006 07:59:24 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B7@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt Thread-Index: Acb58ZJYZLrV3NEmS3+tz3IXm7jakgArtQog From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9SExRp7010542 Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 14:59:45 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 27, 2006 10:59 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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] -- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9SElFLZ006914 for <rbridge@postel.org>; Sat, 28 Oct 2006 07:47:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FA9F.F565C6E6" Date: Sat, 28 Oct 2006 07:47:12 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B5B6@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A question on http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt Thread-Index: Acb6n/PZevAOkmKyQFyTAesDwudq0Q== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Subject: [rbridge] A question on http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-00.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 14:47:42 -0000 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> </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> </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'>“</span></font> &= 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'> 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'> 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'>“<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> </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"'> = </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"'> = </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> </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> </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> </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-- Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9S2gw9j001061 for <rbridge@postel.org>; Fri, 27 Oct 2006 19:42:59 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x4so1385812nfb for <rbridge@postel.org>; Fri, 27 Oct 2006 19:42:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F0Z3upaZ+llynzlf5t4TqCegojPLYBSjDpegi51Ew9vV5TTenK8HTeOH4AKtetNnNVOf1F8DG8Nm9xUl/fpqsYWQUrsfD0JRoMy+r04dlJPoKnN5wKsU9aPfGXJ2BWr98RigNLuShE5PtC3X40X8hPUYx/xxdrc0k55ms3AfXpM= Received: by 10.78.201.10 with SMTP id y10mr608893huf; Fri, 27 Oct 2006 19:42:57 -0700 (PDT) Received: by 10.78.90.3 with HTTP; Fri, 27 Oct 2006 19:42:57 -0700 (PDT) Message-ID: <6280db520610271942w10835b2fo2aa7205551dc6cfb@mail.gmail.com> Date: Fri, 27 Oct 2006 19:42:57 -0700 From: "Alia Atlas" <akatlas@gmail.com> To: "Sanjay Sane (sanjays)" <sanjays@cisco.com> In-Reply-To: <7178B7E237F45D45BE404AFF0AF58D870181BCDE@xmb-sjc-213.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7178B7E237F45D45BE404AFF0AF58D870181BCDE@xmb-sjc-213.amer.cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] How many trees, and per what X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 02:43:23 -0000 Status: RO Content-Length: 1381 Sanjay, On 10/27/06, Sanjay Sane (sanjays) <sanjays@cisco.com> 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 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9S0fEnN000161 for <rbridge@postel.org>; Fri, 27 Oct 2006 17:41:14 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 17:41:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9S0fEux011127; Fri, 27 Oct 2006 17:41:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9S0fEAo023082; Fri, 27 Oct 2006 17:41:14 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:41:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 17:41:13 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BCDE@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] How many trees, and per what Thread-Index: Acb6E4/Cc1gnz5ucR2GtaM96jJ2LmwAFTiJA From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Russ White" <riw@cisco.com>, <Radia.Perlman@sun.com> X-OriginalArrivalTime: 28 Oct 2006 00:41:13.0921 (UTC) FILETIME=[C568A310:01C6FA29] DKIM-Signature: a=rsa-sha1; q=dns; l=2519; t=1161996074; x=1162860074; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:RE=3A=20[rbridge]=20How=20many=20trees,=20and=20per=20what; X=v=3Dcisco.com=3B=20h=3DBO5PO7X6dtWqNqmJ6fNMayWzLRI=3D; b=LHMffrwBhf1u1weJAQxQ+2wl5/osDsa9r2Li6PZ1xH3gZCPit3BJ/Rh7Gy1m29XxJsmP2GCx oiqx+iMewn8qhMWagN6l4pItEQfqDmHpRy83owz8/bwhBE5S8us1y4Yq; Authentication-Results: sj-dkim-1.cisco.com; header.From=sanjays@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9S0fEnN000161 Cc: rbridge@postel.org Subject: Re: [rbridge] How many trees, and per what X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 00:41:44 -0000 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:riw@cisco.com] Sent: Friday, October 27, 2006 3:02 PM To: Radia.Perlman@sun.com Cc: Sanjay Sane (sanjays); rbridge@postel.org Subject: Re: [rbridge] How many trees, and per what -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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 - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFQoHbER27sUhU9OQRAipMAJ4whaXVLKMKVOfXBujtgRfd3vgK5wCgvGGQ r2IwhU5kgDBVfpL9FGJ16Yc= =g8Wb -----END PGP SIGNATURE----- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9S03gTt016626 for <rbridge@postel.org>; Fri, 27 Oct 2006 17:03:42 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9S03ffK020903; Fri, 27 Oct 2006 20:03:41 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA11843; Fri, 27 Oct 2006 20:03:40 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04WN>; Fri, 27 Oct 2006 20:03:39 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA010C@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>, "Gray, Eric" <Eric.Gray@marconi.com> Date: Fri, 27 Oct 2006 20:03:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 00:04:16 -0000 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:kreeger@cisco.com] --> Sent: Friday, October 27, 2006 7:55 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:kreeger@cisco.com] --> > --> Sent: Friday, October 27, 2006 5:51 PM --> > --> To: Gray, Eric --> > --> Cc: rbridge@postel.org --> > --> 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. --> > --> > --> > --> > --> --> > --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9S00Lfn015448 for <rbridge@postel.org>; Fri, 27 Oct 2006 17:00:22 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9S00KfK020883; Fri, 27 Oct 2006 20:00:20 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA11767; Fri, 27 Oct 2006 20:00:20 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04V6>; Fri, 27 Oct 2006 20:00:19 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA010B@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 20:00:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 28 Oct 2006 00:00:40 -0000 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] -- Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RNssFX013617 for <rbridge@postel.org>; Fri, 27 Oct 2006 16:54:54 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2006 16:54:54 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RNsr3p008164; Fri, 27 Oct 2006 16:54:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9RNsrin017018; Fri, 27 Oct 2006 16:54:53 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 16:54:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 16:54:52 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B6FE@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 3rd Issue Thread-Index: Acb6GgsjnDRtPMOsS06FBqGXy4PpggACKodA From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 23:54:53.0310 (UTC) FILETIME=[4C0911E0:01C6FA23] DKIM-Signature: a=rsa-sha1; q=dns; l=4171; t=1161993293; x=1162857293; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN=20-=203rd=20 Issue; X=v=3Dcisco.com=3B=20h=3Du7LjvYOw11tHylgt93NRORFUBHI=3D; b=LvqZ1tP5AZYoJdlJqwo0Ip352zxa33+Qif9BGzxm54OExvYc0lNTyjsO7l1BXalrsq9oh2ml A/K+fbqktwznCJm93X3vYgNZujQ10XvKv7D2EWIk3MZpqkET8nMdgSKB; Authentication-Results: sj-dkim-2.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RNssFX013617 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 23:55:10 -0000 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:kreeger@cisco.com] > --> Sent: Friday, October 27, 2006 5:51 PM > --> To: Gray, Eric > --> Cc: rbridge@postel.org > --> 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. > --> > > --> > --> > --> Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RNd0WD008036 for <rbridge@postel.org>; Fri, 27 Oct 2006 16:39:00 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2006 16:39:00 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RNcxIE004838; Fri, 27 Oct 2006 16:38:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9RNcxAo022771; Fri, 27 Oct 2006 16:38:59 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 16:38:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 16:38:58 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B6EF@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue Thread-Index: Acb6Fh0M3AC+1HRZS5OpPgH4z9aeQQAAOyUg From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 23:38:59.0572 (UTC) FILETIME=[13903340:01C6FA21] DKIM-Signature: a=rsa-sha1; q=dns; l=2290; t=1161992339; x=1162856339; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN=20-=201st=20 Issue; X=v=3Dcisco.com=3B=20h=3DiQa7ts5yo11GQk6qqC8vxaJ45oc=3D; b=ZQ9QsHsMEERsOH00V1zmrpYMo9Ujv2BYvB1/xCfjdWWtV095TbdAmm9XWGLg831snGhj/0f5 3haMatBzPGixN1LxEByDoQ3BErw6UTP5mGlUyy7JmvuPmUgf8WB4p54r; Authentication-Results: sj-dkim-1.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RNd0WD008036 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 23:39:13 -0000 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... :-) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RNYHEL006509 for <rbridge@postel.org>; Fri, 27 Oct 2006 16:34:18 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RNYFfK020690; Fri, 27 Oct 2006 19:34:15 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10997; Fri, 27 Oct 2006 19:34:15 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04RG>; Fri, 27 Oct 2006 19:34:14 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA010A@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 19:34:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 23:34:40 -0000 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 --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RNMiGu002974 for <rbridge@postel.org>; Fri, 27 Oct 2006 16:22:44 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RNMffK020622; Fri, 27 Oct 2006 19:22:41 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10618; Fri, 27 Oct 2006 19:22:41 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B043H>; Fri, 27 Oct 2006 19:22:40 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0109@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Caitlin Bestler <caitlinb@broadcom.com> Date: Fri, 27 Oct 2006 19:22:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 23:23:09 -0000 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:caitlinb@broadcom.com] --> Sent: Friday, October 27, 2006 6:57 PM --> To: Gray, Eric; Larry Kreeger (kreeger) --> Cc: rbridge@postel.org --> 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 --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMwBRU025220 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:58:12 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RMw9fK020452; Fri, 27 Oct 2006 18:58:09 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09771; Fri, 27 Oct 2006 18:58:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04JF>; Fri, 27 Oct 2006 18:58:08 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0104@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>, Caitlin Bestler <caitlinb@broadcom.com>, "Gray, Eric" <Eric.Gray@marconi.com> Date: Fri, 27 Oct 2006 18:58:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:58:45 -0000 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:kreeger@cisco.com] --> Sent: Friday, October 27, 2006 6:06 PM --> To: Caitlin Bestler; Gray, Eric --> Cc: rbridge@postel.org --> 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 --> Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMv9Ui024570 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:57:09 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 27 Oct 2006 15:56:57 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8458D2AF; Fri, 27 Oct 2006 15:56:57 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 614C02AE; Fri, 27 Oct 2006 15:56:57 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJE01157; Fri, 27 Oct 2006 15:56:56 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id AAFFB20501; Fri, 27 Oct 2006 15:56:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 15:56:55 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE8A7@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125BA0102@uspitsmsgusr08.pit.comms.marconi.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 2nd Issue Thread-Index: Acb6Gp5R7Q0Mj627TtCFfhGRINMCWwAADoOw From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Larry Kreeger (kreeger)" <kreeger@cisco.com> X-WSS-ID: 695C513335W5364192-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RMv9Ui024570 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:57:48 -0000 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. Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMraWJ023500 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:53:36 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 27 Oct 2006 15:53:22 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 705412AF; Fri, 27 Oct 2006 15:53:22 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 448622AE; Fri, 27 Oct 2006 15:53:22 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJE00569; Fri, 27 Oct 2006 15:53:20 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id BD68220501; Fri, 27 Oct 2006 15:53:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 15:53:19 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE8A5@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125BA00FA@uspitsmsgusr08.pit.comms.marconi.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue Thread-Index: Acb6FnEj7eMb1IeUSiKqYvmr0QbbVAAA258Q From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Larry Kreeger (kreeger)" <kreeger@cisco.com> X-WSS-ID: 695C526838S5545875-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RMraWJ023500 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:54:11 -0000 Status: RO Content-Length: 2163 rbridge-bounces@postel.org 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. Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMqX8f022737 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:52:33 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RMqUfK020422; Fri, 27 Oct 2006 18:52:31 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09620; Fri, 27 Oct 2006 18:52:30 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B042J>; Fri, 27 Oct 2006 18:52:29 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0102@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Caitlin Bestler <caitlinb@broadcom.com>, "Larry Kreeger (kreeger)" <kreeger@cisco.com>, "Gray, Eric" <Eric.Gray@marconi.com> Date: Fri, 27 Oct 2006 18:52:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:53:14 -0000 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:caitlinb@broadcom.com] --> Sent: Friday, October 27, 2006 5:55 PM --> To: Larry Kreeger (kreeger); Gray, Eric --> Cc: rbridge@postel.org --> 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. --> --> --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMmTpd021170 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:48:30 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RMmSfK020403; Fri, 27 Oct 2006 18:48:28 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09548; Fri, 27 Oct 2006 18:48:28 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04H5>; Fri, 27 Oct 2006 18:48:27 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0100@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 18:48:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:48:42 -0000 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:kreeger@cisco.com] --> Sent: Friday, October 27, 2006 5:51 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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. --> > --> > --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMdSZC018195 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:39:29 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RMdRfK020354; Fri, 27 Oct 2006 18:39:27 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09249; Fri, 27 Oct 2006 18:39:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04GC>; Fri, 27 Oct 2006 18:39:26 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA00FD@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 18:39:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:39:39 -0000 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:kreeger@cisco.com] --> Sent: Friday, October 27, 2006 5:43 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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] -- --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RMKUrw012808 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:20:31 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RMKSfK020211; Fri, 27 Oct 2006 18:20:28 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08552; Fri, 27 Oct 2006 18:20:28 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B04BC>; Fri, 27 Oct 2006 18:20:27 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA00FA@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 18:20:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:20:44 -0000 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:kreeger@cisco.com] --> Sent: Friday, October 27, 2006 5:26 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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] -- --> Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RM6JkF008106 for <rbridge@postel.org>; Fri, 27 Oct 2006 15:06:19 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2006 15:06:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RM6J9Z024253; Fri, 27 Oct 2006 15:06:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9RM6DAs021391; Fri, 27 Oct 2006 15:06:19 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 15:06:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 15:06:14 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B69B@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 2nd Issue Thread-Index: Acb5+DIqKNCkdp1/RgGUkJve1GRDygAFvnxwAADCLaAAAGABkA== From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 22:06:15.0651 (UTC) FILETIME=[1F353B30:01C6FA14] DKIM-Signature: a=rsa-sha1; q=dns; l=1655; t=1161986779; x=1162850779; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN=20-=202nd=20 Issue; X=v=3Dcisco.com=3B=20h=3D7fQn/2qmKYiYdfnqETt5yu2LoYs=3D; b=URUxaIH8o51buKkMcJj7W4t5KeBO2RkpTFNj+51zAnZwGH2qC3mbWZIPmKJygDLFlFY1r1OA qBJmdsKJryGr3am7IHZdA7yt8EHDX5OQ83yYlO4INBSeRoHfTJb09rhz; Authentication-Results: sj-dkim-1.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RM6JkF008106 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:06:42 -0000 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 Received: from xmail03.myhosting.com (xmail03.myhosting.com [168.144.250.217]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RM2OWM006696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Fri, 27 Oct 2006 15:02:24 -0700 (PDT) Received: (qmail 3425 invoked from network); 27 Oct 2006 22:02:13 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender <riw@cisco.com>) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for <Radia.Perlman@sun.com>; 27 Oct 2006 22:02:13 -0000 Message-ID: <454281DB.1090304@cisco.com> Date: Fri, 27 Oct 2006 18:02:03 -0400 From: Russ White <riw@cisco.com> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Radia.Perlman@sun.com References: <ff85cd0c62b5.4540e7c7@sunlabs.com> In-Reply-To: <ff85cd0c62b5.4540e7c7@sunlabs.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] How many trees, and per what X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 22:02:36 -0000 Status: RO Content-Length: 851 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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 - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFQoHbER27sUhU9OQRAipMAJ4whaXVLKMKVOfXBujtgRfd3vgK5wCgvGGQ r2IwhU5kgDBVfpL9FGJ16Yc= =g8Wb -----END PGP SIGNATURE----- Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RLt7m5004433 for <rbridge@postel.org>; Fri, 27 Oct 2006 14:55:07 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 27 Oct 2006 14:54:45 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 3E8FE2AF; Fri, 27 Oct 2006 14:54:45 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1B82C2AE; Fri, 27 Oct 2006 14:54:45 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJD88375; Fri, 27 Oct 2006 14:54:42 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 19D2A20501; Fri, 27 Oct 2006 14:54:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 14:54:41 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE892@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <A0A653F4CB702442BFBF2FAF02C031E902C8B673@xmb-sjc-21e.amer.cisco.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 2nd Issue Thread-Index: Acb5+DIqKNCkdp1/RgGUkJve1GRDygAFvnxwAADCLaA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>, "Gray, Eric" <Eric.Gray@marconi.com> X-WSS-ID: 695C5FAF38S5527458-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RLt7m5004433 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 21:55:39 -0000 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. Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RLodBe002682 for <rbridge@postel.org>; Fri, 27 Oct 2006 14:50:39 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 14:50:39 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RLodhY000965; Fri, 27 Oct 2006 14:50:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9RLodW4018887; Fri, 27 Oct 2006 14:50:39 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 14:50:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 14:50:38 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B67F@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 3rd Issue Thread-Index: Acb5+Q+8N+xSSRpDSwuy3PdC1uxviQAF+AUA From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 21:50:39.0097 (UTC) FILETIME=[F0FA6E90:01C6FA11] DKIM-Signature: a=rsa-sha1; q=dns; l=2133; t=1161985839; x=1162849839; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN=20-=203rd=20 Issue; X=v=3Dcisco.com=3B=20h=3Du7LjvYOw11tHylgt93NRORFUBHI=3D; b=e9NkX4Yw1OavxdsrEbOCpHMRpACae5iw0FRQ9P6ZsS47zJaqznIhvPB5bevq7T0kDSnBU4Ej St7ruGo2DQAHZsVRLJn965Xe9x8OL6RJMC0EwaMmUyW4dq1vPiP2UKsA; Authentication-Results: sj-dkim-2.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RLodBe002682 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 21:51:19 -0000 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. > > --> Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RLhJje000362 for <rbridge@postel.org>; Fri, 27 Oct 2006 14:43:19 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 14:43:19 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RLhIVp030599; Fri, 27 Oct 2006 14:43:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9RLhIin022579; Fri, 27 Oct 2006 14:43:18 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 14:43:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 14:43:17 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B673@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 2nd Issue Thread-Index: Acb5+DIqKNCkdp1/RgGUkJve1GRDygAFvnxw From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 21:43:18.0446 (UTC) FILETIME=[EA546CE0:01C6FA10] DKIM-Signature: a=rsa-sha1; q=dns; l=4208; t=1161985398; x=1162849398; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN=20-=202nd=20 Issue; X=v=3Dcisco.com=3B=20h=3D7fQn/2qmKYiYdfnqETt5yu2LoYs=3D; b=UVmpw44kF4AdPg2Jrjx8mk6102e7Gvx00vwe9FYKqNwDpQ6ml+qH33X0y8EdP5Li59QAWw3Y AnPRKjWB4FYvt6twsRdHhxk3NkXSd5/gqs1YMcgWhGhyOIG7NDIj5rho; Authentication-Results: sj-dkim-1.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( 14 extraneous bytes; sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RLhJje000362 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 21:43:46 -0000 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] -- Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RLQ36v024671 for <rbridge@postel.org>; Fri, 27 Oct 2006 14:26:03 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 14:26:03 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RLQ2VG003109; Fri, 27 Oct 2006 14:26:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9RLQ2Ao014526; Fri, 27 Oct 2006 14:26:02 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 14:26:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 14:26:01 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B65E@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN - 1st Issue Thread-Index: Acb59lw7MoLmA5CRRY66Lu79ySXX4wAFZ0AQ From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 21:26:02.0541 (UTC) FILETIME=[80E1DDD0:01C6FA0E] DKIM-Signature: a=rsa-sha1; q=dns; l=3581; t=1161984363; x=1162848363; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN=20-=201st=20 Issue; X=v=3Dcisco.com=3B=20h=3DiQa7ts5yo11GQk6qqC8vxaJ45oc=3D; b=rM5iGqDFlM6T1HQZfvn1oo+zeLT4Rj7q+ZayEZOTK6YpP4jDqjdcmuvxoHixBeqSp85gOhla JvLUYSAjOmdjWkbwwNSgqzqX+FE7lnpnPyBb27WZACFOuEyJdZajXRHD; Authentication-Results: sj-dkim-2.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( 14 extraneous bytes; sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RLQ36v024671 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 21:26:46 -0000 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] -- Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RL5RZa018207 for <rbridge@postel.org>; Fri, 27 Oct 2006 14:05:27 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2006 14:05:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RL5Run022882; Fri, 27 Oct 2006 14:05:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9RL5RW4014025; Fri, 27 Oct 2006 14:05:27 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 14:05:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 14:05:27 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B643@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb54dXiunzTlVs6RWuLP4TLslxjZQAAyxSgAAjva5A= From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> X-OriginalArrivalTime: 27 Oct 2006 21:05:26.0971 (UTC) FILETIME=[A06CD8B0:01C6FA0B] DKIM-Signature: a=rsa-sha1; q=dns; l=3121; t=1161983127; x=1162847127; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN; X=v=3Dcisco.com=3B=20h=3DWta47CeRJGQ2Yh9eeJPEi2XDyeE=3D; b=NJGsp+OhcOa/MefDEg61T8yXC0uxPWnCVyf2S2MEN58yAxljYi7L4VrKTExagwzXu7hZC4Pq FiC5MuMu4P68r+cMkFON88q/MMDxYoyxJLd7DA/hdQpK1twPjMXyXCXU; Authentication-Results: sj-dkim-1.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RL5RZa018207 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 21:05:43 -0000 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9RK3a4Z023981 for <rbridge@postel.org>; Fri, 27 Oct 2006 13:03:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: anoop@brocade.com X-Msg-Ref: server-13.tower-136.messagelabs.com!1161979414!3064781!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 21244 invoked from network); 27 Oct 2006 20:03:34 -0000 Received: from f112.brocade.com (HELO scooby.brocade.com) (66.243.153.112) by server-13.tower-136.messagelabs.com with SMTP; 27 Oct 2006 20:03:34 -0000 Received: from hq-exch-1.corp.brocade.com (hq-exch-1.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id 0A86D25801B; Fri, 27 Oct 2006 12:57:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 13:01:18 -0700 Message-ID: <39BA3BC178B4394DB184389E88A97F8CF2A4F9@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb54V8l3PEVrdriRGi2zAsK0PkP7AAIRjOw From: "Anoop Ghanwani" <anoop@brocade.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Silvano Gai" <sgai@nuovasystems.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop@brocade.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RK3a4Z023981 Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 20:04:02 -0000 Status: RO Content-Length: 724 > -----Original Message----- > From: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] On Behalf Of Gray, Eric > Sent: Friday, October 27, 2006 8:38 AM > To: Silvano Gai > Cc: rbridge@postel.org; Radia.Perlman@sun.com > 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RJxhPe022268 for <rbridge@postel.org>; Fri, 27 Oct 2006 12:59:44 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RJxcfK018571; Fri, 27 Oct 2006 15:59:38 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01739; Fri, 27 Oct 2006 15:59:38 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <VX8B0SLH>; Fri, 27 Oct 2006 15:59:37 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA00D8@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> Date: Fri, 27 Oct 2006 15:59:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 20:01:39 -0000 Status: RO Content-Length: 10276 Sure. Looking forward to it... :-) --> -----Original Message----- --> From: Wadekar, Manoj K [mailto:manoj.k.wadekar@intel.com] --> Sent: Friday, October 27, 2006 3:29 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> Sent: Friday, October 27, 2006 12:15 PM Pacific Standard Time --> To: Wadekar, Manoj K; Gray, Eric --> Cc: rbridge@postel.org --> 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:manoj.k.wadekar@intel.com] --> --> Sent: Friday, October 27, 2006 2:56 PM --> --> To: Gray, Eric --> --> Cc: rbridge@postel.org --> --> 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:Eric.Gray@marconi.com] --> --> Sent: Friday, October 27, 2006 11:27 AM --> --> To: Wadekar, Manoj K; Gray, Eric --> --> Cc: rbridge@postel.org --> --> 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:manoj.k.wadekar@intel.com] --> --> --> Sent: Friday, October 27, 2006 1:54 PM --> --> --> To: Gray, Eric --> --> --> Cc: rbridge@postel.org --> --> --> 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:Eric.Gray@marconi.com] --> --> --> Sent: Friday, October 27, 2006 8:44 AM --> --> --> To: Wadekar, Manoj K --> --> --> Cc: rbridge@postel.org --> --> --> 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: rbridge-bounces@postel.org --> --> --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> --> --> Wadekar, Manoj K --> --> --> --> Sent: Friday, October 27, 2006 11:21 AM --> --> --> --> To: rbridge@postel.org --> --> --> --> 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:sgai@nuovasystems.com] --> --> --> --> Sent: Friday, October 27, 2006 8:00 AM --> --> --> --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> --> --> --> Cc: rbridge@postel.org --> --> --> --> 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: rbridge-bounces@postel.org --> --> --> --> [mailto:rbridge-bounces@postel.org] --> --> --> --> On --> --> --> --> > Behalf Of Radia.Perlman@sun.com --> --> --> --> > Sent: Thursday, October 26, 2006 5:02 PM --> --> --> --> > To: Wadekar, Manoj K --> --> --> --> > Cc: rbridge@postel.org --> --> --> --> > 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 --> --> --> --> rbridge@postel.org --> --> --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> --> --> --> --> --> --> --> Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RJTLZ6011322 for <rbridge@postel.org>; Fri, 27 Oct 2006 12:29:22 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 27 Oct 2006 12:29:19 -0700 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by azsmga001.ch.intel.com with ESMTP; 27 Oct 2006 12:29:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,366,1157353200"; d="scan'208"; a="136896754:sNHT33269754" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 12:29:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 27 Oct 2006 12:29:19 -0700 Message-ID: <79E93560F4A5FD42BB769DAAF8BEF62A275791@scsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb5/EuZS9fSMNrlT8usT0m6seuP/gAAean5 From: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 19:29:18.0961 (UTC) FILETIME=[326C5E10:01C6F9FE] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: manoj.k.wadekar@intel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RJTLZ6011322 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 19:29:43 -0000 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:Eric.Gray@marconi.com] Sent: Friday, October 27, 2006 12:15 PM Pacific Standard Time To: Wadekar, Manoj K; Gray, Eric Cc: rbridge@postel.org 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:manoj.k.wadekar@intel.com] --> Sent: Friday, October 27, 2006 2:56 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> Sent: Friday, October 27, 2006 11:27 AM --> To: Wadekar, Manoj K; Gray, Eric --> Cc: rbridge@postel.org --> 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:manoj.k.wadekar@intel.com] --> --> Sent: Friday, October 27, 2006 1:54 PM --> --> To: Gray, Eric --> --> Cc: rbridge@postel.org --> --> 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:Eric.Gray@marconi.com] --> --> Sent: Friday, October 27, 2006 8:44 AM --> --> To: Wadekar, Manoj K --> --> Cc: rbridge@postel.org --> --> 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: rbridge-bounces@postel.org --> --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> --> Wadekar, Manoj K --> --> --> Sent: Friday, October 27, 2006 11:21 AM --> --> --> To: rbridge@postel.org --> --> --> 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:sgai@nuovasystems.com] --> --> --> Sent: Friday, October 27, 2006 8:00 AM --> --> --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> --> --> Cc: rbridge@postel.org --> --> --> 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: rbridge-bounces@postel.org --> --> --> [mailto:rbridge-bounces@postel.org] --> --> --> On --> --> --> > Behalf Of Radia.Perlman@sun.com --> --> --> > Sent: Thursday, October 26, 2006 5:02 PM --> --> --> > To: Wadekar, Manoj K --> --> --> > Cc: rbridge@postel.org --> --> --> > 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 --> --> --> rbridge@postel.org --> --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> --> --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RJFO9O006824 for <rbridge@postel.org>; Fri, 27 Oct 2006 12:15:25 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RJFNfK017674; Fri, 27 Oct 2006 15:15:23 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28435; Fri, 27 Oct 2006 15:15:23 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q7Q7>; Fri, 27 Oct 2006 15:15:22 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA00B9@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com>, "Gray, Eric" <Eric.Gray@marconi.com> Date: Fri, 27 Oct 2006 15:15:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 19:15:35 -0000 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:manoj.k.wadekar@intel.com] --> Sent: Friday, October 27, 2006 2:56 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> Sent: Friday, October 27, 2006 11:27 AM --> To: Wadekar, Manoj K; Gray, Eric --> Cc: rbridge@postel.org --> 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:manoj.k.wadekar@intel.com] --> --> Sent: Friday, October 27, 2006 1:54 PM --> --> To: Gray, Eric --> --> Cc: rbridge@postel.org --> --> 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:Eric.Gray@marconi.com] --> --> Sent: Friday, October 27, 2006 8:44 AM --> --> To: Wadekar, Manoj K --> --> Cc: rbridge@postel.org --> --> 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: rbridge-bounces@postel.org --> --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> --> Wadekar, Manoj K --> --> --> Sent: Friday, October 27, 2006 11:21 AM --> --> --> To: rbridge@postel.org --> --> --> 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:sgai@nuovasystems.com] --> --> --> Sent: Friday, October 27, 2006 8:00 AM --> --> --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> --> --> Cc: rbridge@postel.org --> --> --> 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: rbridge-bounces@postel.org --> --> --> [mailto:rbridge-bounces@postel.org] --> --> --> On --> --> --> > Behalf Of Radia.Perlman@sun.com --> --> --> > Sent: Thursday, October 26, 2006 5:02 PM --> --> --> > To: Wadekar, Manoj K --> --> --> > Cc: rbridge@postel.org --> --> --> > 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 --> --> --> rbridge@postel.org --> --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> --> --> --> Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIuA7t029728 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:56:11 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 27 Oct 2006 11:56:06 -0700 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by fmsmga001.fm.intel.com with ESMTP; 27 Oct 2006 11:56:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,366,1157353200"; d="scan'208"; a="153135991:sNHT27998166" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 11:55:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 11:55:43 -0700 Message-ID: <79E93560F4A5FD42BB769DAAF8BEF62ABE6AC4@scsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb59ZUM5+iW4Pi9QZOY2x46WzYDHgAAffmA From: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 18:55:44.0557 (UTC) FILETIME=[81BEB5D0:01C6F9F9] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: manoj.k.wadekar@intel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RIuA7t029728 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:56:42 -0000 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:Eric.Gray@marconi.com] Sent: Friday, October 27, 2006 11:27 AM To: Wadekar, Manoj K; Gray, Eric Cc: rbridge@postel.org 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:manoj.k.wadekar@intel.com] --> Sent: Friday, October 27, 2006 1:54 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> Sent: Friday, October 27, 2006 8:44 AM --> To: Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> Wadekar, Manoj K --> --> Sent: Friday, October 27, 2006 11:21 AM --> --> To: rbridge@postel.org --> --> 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:sgai@nuovasystems.com] --> --> Sent: Friday, October 27, 2006 8:00 AM --> --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> --> Cc: rbridge@postel.org --> --> 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] --> --> On --> --> > Behalf Of Radia.Perlman@sun.com --> --> > Sent: Thursday, October 26, 2006 5:02 PM --> --> > To: Wadekar, Manoj K --> --> > Cc: rbridge@postel.org --> --> > 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 --> --> rbridge@postel.org --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIqUIu028267 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:52:30 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RIqSfK017279; Fri, 27 Oct 2006 14:52:29 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26686; Fri, 27 Oct 2006 14:52:28 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q7CH>; Fri, 27 Oct 2006 14:52:27 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA00A9@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 14:52:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 3rd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:53:02 -0000 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. --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIkH7q026203 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:46:17 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RIkGfK017158; Fri, 27 Oct 2006 14:46:16 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26185; Fri, 27 Oct 2006 14:46:16 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q69B>; Fri, 27 Oct 2006 14:46:15 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA009D@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 14:46:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 2nd Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:46:33 -0000 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] -- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIXB4W021696 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:33:12 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RIX9fK016894; Fri, 27 Oct 2006 14:33:10 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25240; Fri, 27 Oct 2006 14:33:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q6VN>; Fri, 27 Oct 2006 14:33:08 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0092@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 14:33:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN - 1st Issue X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:33:29 -0000 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] -- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIRPJh018926 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:27:26 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RIRMfK016727; Fri, 27 Oct 2006 14:27:23 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24694; Fri, 27 Oct 2006 14:27:22 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q6Q6>; Fri, 27 Oct 2006 14:27:21 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0090@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com>, "Gray, Eric" <Eric.Gray@marconi.com> Date: Fri, 27 Oct 2006 14:27:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:28:11 -0000 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:manoj.k.wadekar@intel.com] --> Sent: Friday, October 27, 2006 1:54 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> Sent: Friday, October 27, 2006 8:44 AM --> To: Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> Wadekar, Manoj K --> --> Sent: Friday, October 27, 2006 11:21 AM --> --> To: rbridge@postel.org --> --> 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:sgai@nuovasystems.com] --> --> Sent: Friday, October 27, 2006 8:00 AM --> --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> --> Cc: rbridge@postel.org --> --> 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] --> --> On --> --> > Behalf Of Radia.Perlman@sun.com --> --> > Sent: Thursday, October 26, 2006 5:02 PM --> --> > To: Wadekar, Manoj K --> --> > Cc: rbridge@postel.org --> --> > 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 --> --> rbridge@postel.org --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIMgjw017426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Fri, 27 Oct 2006 11:22:42 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9RIMGFT027568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Oct 2006 11:22:18 -0700 (PDT) Message-ID: <45424ECE.20703@isi.edu> Date: Fri, 27 Oct 2006 11:24:14 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Gray, Eric" <Eric.Gray@marconi.com> References: <0BF76B30C100624BA997C9CED19D8125BA0084@uspitsmsgusr08.pit.comms.marconi.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125BA0084@uspitsmsgusr08.pit.comms.marconi.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCF8A01D52389571DAB0FA8C2" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet- drafts/draft-ietf-trill-prob-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:23:32 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFQk7SE5f5cImnZrsRAng5AJ4ksh7jx6h4C88vOpbE6T+6zpsk3QCfXmYH r9F6xDz3YLscSQKOlVetl4s= =DcQb -----END PGP SIGNATURE----- --------------enigCF8A01D52389571DAB0FA8C2-- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RILDec016960 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:21:13 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7T00K3I4B8YQ10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 27 Oct 2006 11:21:09 -0700 (PDT) Received: from sun.com ([129.150.20.126]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7T009UQ4B8T350@mail.sunlabs.com> for rbridge@postel.org; Fri, 27 Oct 2006 11:21:08 -0700 (PDT) Date: Fri, 27 Oct 2006 11:21:08 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <0BF76B30C100624BA997C9CED19D8125BA007E@uspitsmsgusr08.pit.comms.marconi.com> To: "Gray, Eric" <Eric.Gray@marconi.com> Message-id: <45424E14.1020405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <0BF76B30C100624BA997C9CED19D8125BA007E@uspitsmsgusr08.pit.comms.marconi.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:21:44 -0000 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 Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RI0EBn009050 for <rbridge@postel.org>; Fri, 27 Oct 2006 11:00:14 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 27 Oct 2006 11:00:03 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 81E522B0; Fri, 27 Oct 2006 11:00:03 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 532A22AE; Fri, 27 Oct 2006 11:00:03 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJD36516; Fri, 27 Oct 2006 11:00:02 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 657D120502; Fri, 27 Oct 2006 11:00:02 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Oct 2006 11:00:01 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE84C@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <A0A653F4CB702442BFBF2FAF02C031E902C8B53E@xmb-sjc-21e.amer.cisco.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb57ANdT0x9zZyjQAK0kEiplwm/0gAASNdwAAD1IKA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>, "Gray, Eric" <Eric.Gray@marconi.com> X-WSS-ID: 695C96A935W5257685-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RI0EBn009050 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 18:00:30 -0000 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. Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RHwuHi008677 for <rbridge@postel.org>; Fri, 27 Oct 2006 10:58:56 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RHwsfK016178; Fri, 27 Oct 2006 13:58:55 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22437; Fri, 27 Oct 2006 13:58:54 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q58L>; Fri, 27 Oct 2006 13:58:54 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0084@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Fri, 27 Oct 2006 13:58:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Last Call comment on: http://www.ietf.org/internet- drafts/draft-ietf-trill-prob-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 17:59:39 -0000 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] -- Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RHs2Fc006757 for <rbridge@postel.org>; Fri, 27 Oct 2006 10:54:02 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 27 Oct 2006 10:54:01 -0700 Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by fmsmga001.fm.intel.com with ESMTP; 27 Oct 2006 10:54:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,366,1157353200"; d="scan'208"; a="153104855:sNHT28846622" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 10:53:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 10:53:58 -0700 Message-ID: <79E93560F4A5FD42BB769DAAF8BEF62ABE6A1D@scsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb53sVNmjz8W7rjQdyQNwLIXbO7mgAD7O7A From: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 17:53:59.0769 (UTC) FILETIME=[E184EC90:01C6F9F0] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: manoj.k.wadekar@intel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RHs2Fc006757 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 17:54:32 -0000 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:Eric.Gray@marconi.com] Sent: Friday, October 27, 2006 8:44 AM To: Wadekar, Manoj K Cc: rbridge@postel.org 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Wadekar, Manoj K --> Sent: Friday, October 27, 2006 11:21 AM --> To: rbridge@postel.org --> 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:sgai@nuovasystems.com] --> Sent: Friday, October 27, 2006 8:00 AM --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] --> On --> > Behalf Of Radia.Perlman@sun.com --> > Sent: Thursday, October 26, 2006 5:02 PM --> > To: Wadekar, Manoj K --> > Cc: rbridge@postel.org --> > 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RHkuNh003517 for <rbridge@postel.org>; Fri, 27 Oct 2006 10:46:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 10:46:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RHkuDG012366; Fri, 27 Oct 2006 10:46:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9RHktAu018493; Fri, 27 Oct 2006 10:46:56 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 10:46:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 10:46:55 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B53E@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb57ANdT0x9zZyjQAK0kEiplwm/0gAASNdw From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-OriginalArrivalTime: 27 Oct 2006 17:46:55.0708 (UTC) FILETIME=[E4C259C0:01C6F9EF] DKIM-Signature: a=rsa-sha1; q=dns; l=6777; t=1161971216; x=1162835216; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN; X=v=3Dcisco.com=3B=20h=3DWta47CeRJGQ2Yh9eeJPEi2XDyeE=3D; b=Zr3ZmwRF5u2YUT2DJbMZoJXVWvIUKSRRDO4jouurx+oecZwKT5lPSwJUkGfgqUmC42q7nTwL 3fQUp2uDQdH/9QCi/YcaHbsrtou2oQK5ah140siIs3iwEIhxHkPwNV1R; Authentication-Results: sj-dkim-3.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RHkuNh003517 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 17:47:49 -0000 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. Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RHZkm1029510 for <rbridge@postel.org>; Fri, 27 Oct 2006 10:35:47 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RHZjfK015650; Fri, 27 Oct 2006 13:35:46 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20750; Fri, 27 Oct 2006 13:35:45 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q53N>; Fri, 27 Oct 2006 13:35:45 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA007E@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia Perlman <Radia.Perlman@sun.com> Date: Fri, 27 Oct 2006 13:35:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 17:36:10 -0000 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:Radia.Perlman@sun.com] --> Sent: Friday, October 27, 2006 12:32 PM --> To: Gray, Eric --> Cc: Wadekar, Manoj K; rbridge@postel.org --> 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: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org] On Behalf Of --> Wadekar, Manoj K --> >--> Sent: Friday, October 27, 2006 11:21 AM --> >--> To: rbridge@postel.org --> >--> 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:sgai@nuovasystems.com] --> >--> Sent: Friday, October 27, 2006 8:00 AM --> >--> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> >--> Cc: rbridge@postel.org --> >--> 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: rbridge-bounces@postel.org --> >--> [mailto:rbridge-bounces@postel.org] --> >--> On --> >--> > Behalf Of Radia.Perlman@sun.com --> >--> > Sent: Thursday, October 26, 2006 5:02 PM --> >--> > To: Wadekar, Manoj K --> >--> > Cc: rbridge@postel.org --> >--> > 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 --> >--> rbridge@postel.org --> >--> http://mailman.postel.org/mailman/listinfo/rbridge --> >--> --> >_______________________________________________ --> >rbridge mailing list --> >rbridge@postel.org --> >http://mailman.postel.org/mailman/listinfo/rbridge --> > --> > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RHY0u4029123 for <rbridge@postel.org>; Fri, 27 Oct 2006 10:34:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 10:33:56 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B448@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt Thread-Index: Acb518ivbzn8rp8LTIui5gTHu9ZLvw== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RHY0u4029123 Subject: [rbridge] Last Call comment on: http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 17:35:07 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RHDJ9A021873 for <rbridge@postel.org>; Fri, 27 Oct 2006 10:13:19 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RHDHfK015203; Fri, 27 Oct 2006 13:13:17 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19330; Fri, 27 Oct 2006 13:13:17 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4Q5B5>; Fri, 27 Oct 2006 13:13:16 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0073@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Larry Kreeger (kreeger)" <kreeger@cisco.com> Date: Fri, 27 Oct 2006 13:13:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 17:13:57 -0000 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:kreeger@cisco.com] --> Sent: Friday, October 27, 2006 12:07 PM --> To: Gray, Eric; Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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. --> Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RGr0QY014901 for <rbridge@postel.org>; Fri, 27 Oct 2006 09:53:00 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 27 Oct 2006 09:52:46 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BF85A2AE; Fri, 27 Oct 2006 09:52:46 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 83A902B0; Fri, 27 Oct 2006 09:52:46 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJD16276; Fri, 27 Oct 2006 09:52:43 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 5382720501; Fri, 27 Oct 2006 09:52:43 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Oct 2006 09:52:42 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE834@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <45422DE0.9060305@sun.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb54dXiunzTlVs6RWuLP4TLslxjZQAAyxSg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> X-WSS-ID: 695CE6D438S5405581-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RGr0QY014901 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 16:53:39 -0000 Status: RO Content-Length: 2199 rbridge-bounces@postel.org 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. Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RGVwus008443 for <rbridge@postel.org>; Fri, 27 Oct 2006 09:31:58 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7S00KUOZ9AYQ00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 27 Oct 2006 09:31:58 -0700 (PDT) Received: from sun.com ([129.150.20.126]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7S009HIZ99T350@mail.sunlabs.com> for rbridge@postel.org; Fri, 27 Oct 2006 09:31:58 -0700 (PDT) Date: Fri, 27 Oct 2006 09:31:57 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <0BF76B30C100624BA997C9CED19D8125BA0053@uspitsmsgusr08.pit.comms.marconi.com> To: "Gray, Eric" <Eric.Gray@marconi.com> Message-id: <4542347D.8050508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <0BF76B30C100624BA997C9CED19D8125BA0053@uspitsmsgusr08.pit.comms.marconi.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 16:32:36 -0000 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: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org] On Behalf Of Wadekar, Manoj K >--> Sent: Friday, October 27, 2006 11:21 AM >--> To: rbridge@postel.org >--> 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:sgai@nuovasystems.com] >--> Sent: Friday, October 27, 2006 8:00 AM >--> To: Radia.Perlman@sun.com; Wadekar, Manoj K >--> Cc: rbridge@postel.org >--> 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: rbridge-bounces@postel.org >--> [mailto:rbridge-bounces@postel.org] >--> On >--> > Behalf Of Radia.Perlman@sun.com >--> > Sent: Thursday, October 26, 2006 5:02 PM >--> > To: Wadekar, Manoj K >--> > Cc: rbridge@postel.org >--> > 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 >--> rbridge@postel.org >--> http://mailman.postel.org/mailman/listinfo/rbridge >--> >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RGI0Gs003511 for <rbridge@postel.org>; Fri, 27 Oct 2006 09:18:01 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 27 Oct 2006 09:18:00 -0700 Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by fmsmga001.fm.intel.com with ESMTP; 27 Oct 2006 09:18:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,366,1157353200"; d="scan'208"; a="153049432:sNHT111599719" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 09:17:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 09:17:58 -0700 Message-ID: <79E93560F4A5FD42BB769DAAF8BEF62ABE693E@scsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb54ZZph0neoT0TTyW1Ir7mQwNgogAACZHA From: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 27 Oct 2006 16:17:59.0243 (UTC) FILETIME=[77FA69B0:01C6F9E3] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: manoj.k.wadekar@intel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RGI0Gs003511 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 16:18:47 -0000 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:Radia.Perlman@sun.com] Sent: Friday, October 27, 2006 9:04 AM To: Wadekar, Manoj K Cc: rbridge@postel.org 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:sgai@nuovasystems.com] >Sent: Friday, October 27, 2006 8:00 AM >To: Radia.Perlman@sun.com; Wadekar, Manoj K >Cc: rbridge@postel.org >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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >> >> >On > > >>Behalf Of Radia.Perlman@sun.com >>Sent: Thursday, October 26, 2006 5:02 PM >>To: Wadekar, Manoj K >>Cc: rbridge@postel.org >>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 >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RG7Qd7028624 for <rbridge@postel.org>; Fri, 27 Oct 2006 09:07:26 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 09:07:26 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RG7Oht021362; Fri, 27 Oct 2006 09:07:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9RG7Oir018123; Fri, 27 Oct 2006 09:07:24 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 09:07:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 09:07:19 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B4B2@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb54OjlNeAYlyEhRpeE9O1sgOe+1QAAJlEA From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> X-OriginalArrivalTime: 27 Oct 2006 16:07:18.0624 (UTC) FILETIME=[FA23B600:01C6F9E1] DKIM-Signature: a=rsa-sha1; q=dns; l=959; t=1161965244; x=1162829244; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN; X=v=3Dcisco.com=3B=20h=3DWta47CeRJGQ2Yh9eeJPEi2XDyeE=3D; b=w8G5aoie132Hl4ECf58WtMMZ6v6B0wA8gcBJh08QHPO0RYC/YTPVgjwcGBJpD/+CgWq6LwQG +0TxpxQ7ojHoqxL0wnrhhWXvqr0b4WDSkvt2VDnCZ8i9gNGB5kK3ClnX; Authentication-Results: sj-dkim-2.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RG7Qd7028624 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 16:08:24 -0000 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. Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RG7Jjp028585 for <rbridge@postel.org>; Fri, 27 Oct 2006 09:07:19 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RG7HfK014058; Fri, 27 Oct 2006 12:07:18 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14777; Fri, 27 Oct 2006 12:07:17 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4QY5A>; Fri, 27 Oct 2006 12:07:16 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA005C@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia.Perlman@sun.com Date: Fri, 27 Oct 2006 12:07:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] How many trees, and per what X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 16:07:45 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> Radia.Perlman@sun.com --> Sent: Thursday, October 26, 2006 7:52 PM --> To: Sanjay Sane (sanjays) --> Cc: rbridge@postel.org --> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RG3oGf027220 for <rbridge@postel.org>; Fri, 27 Oct 2006 09:03:50 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7S00KSJXYAYQ00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 27 Oct 2006 09:03:46 -0700 (PDT) Received: from sun.com ([129.150.20.126]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7S009DZXY9T350@mail.sunlabs.com> for rbridge@postel.org; Fri, 27 Oct 2006 09:03:46 -0700 (PDT) Date: Fri, 27 Oct 2006 09:03:44 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <79E93560F4A5FD42BB769DAAF8BEF62ABA5290@scsmsx411.amr.corp.intel.com> To: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> Message-id: <45422DE0.9060305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <79E93560F4A5FD42BB769DAAF8BEF62ABA5290@scsmsx411.amr.corp.intel.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 16:04:00 -0000 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:sgai@nuovasystems.com] >Sent: Friday, October 27, 2006 8:00 AM >To: Radia.Perlman@sun.com; Wadekar, Manoj K >Cc: rbridge@postel.org >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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >> >> >On > > >>Behalf Of Radia.Perlman@sun.com >>Sent: Thursday, October 26, 2006 5:02 PM >>To: Wadekar, Manoj K >>Cc: rbridge@postel.org >>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 >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFsn3J023797 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:54:49 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 08:54:50 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RFsnim011560 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:54:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9RFsmOX006600 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:54:49 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 08:54:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 08:54:47 -0700 Message-ID: <A0A653F4CB702442BFBF2FAF02C031E902C8B4A7@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb4o0ErKUSnEhhASr6GhDhesbNTMgBOFWtA From: "Larry Kreeger \(kreeger\)" <kreeger@cisco.com> To: <rbridge@postel.org> X-OriginalArrivalTime: 27 Oct 2006 15:54:48.0201 (UTC) FILETIME=[3ADA3F90:01C6F9E0] DKIM-Signature: a=rsa-sha1; q=dns; l=1651; t=1161964489; x=1162828489; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kreeger@cisco.com; z=From:=22Larry=20Kreeger=20\(kreeger\)=22=20<kreeger@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20address=20and=20BCN; X=v=3Dcisco.com=3B=20h=3DWta47CeRJGQ2Yh9eeJPEi2XDyeE=3D; b=EOmwOs0ikNmPNjF39lhWJ1EThX82Dy86m/5Dpb3pYI301Zk3gUWVjcLmJj+vC1r4mVHLb0EI ULv9Z/WAMEpBmdX4fc4IHPxtLUdrpI1EYkHHLioZhxfYXl9Debd+Ixoz; Authentication-Results: sj-dkim-6.cisco.com; header.From=kreeger@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: kreeger@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RFsn3J023797 Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:55:00 -0000 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFqcg0022725 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:52:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 08:52:34 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B401@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb5XAUFWw1JBt61Q8euEeSaMfQumAAe9arwAAGjsJAAAFps0A== From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, <Radia.Perlman@sun.com>, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RFqcg0022725 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:53:01 -0000 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:caitlinb@broadcom.com] > Sent: Friday, October 27, 2006 8:45 AM > To: Silvano Gai; Radia.Perlman@sun.com; Wadekar, Manoj K > Cc: rbridge@postel.org > Subject: RE: [rbridge] Ingress Rbridge address and BCN > > rbridge-bounces@postel.org 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. Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFp7VG022281 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:51:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 08:51:04 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B3FE@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb53qRSKMKc6QcdTze+wLMtJMPEFQAAGjuw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RFp7VG022281 Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:51:29 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 27, 2006 8:38 AM > To: Silvano Gai > Cc: rbridge@postel.org; Radia.Perlman@sun.com > 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Friday, October 27, 2006 11:00 AM > --> To: Radia.Perlman@sun.com; Wadekar, Manoj K > --> Cc: rbridge@postel.org > --> 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] > --> On > --> > Behalf Of Radia.Perlman@sun.com > --> > Sent: Thursday, October 26, 2006 5:02 PM > --> > To: Wadekar, Manoj K > --> > Cc: rbridge@postel.org > --> > 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFl9xp020547 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:47:10 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RFl5fK013667; Fri, 27 Oct 2006 11:47:05 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13140; Fri, 27 Oct 2006 11:47:05 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4QYM3>; Fri, 27 Oct 2006 11:47:04 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0056@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia.Perlman@sun.com, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> Date: Fri, 27 Oct 2006 11:47:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:47:43 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of --> Radia.Perlman@sun.com --> Sent: Thursday, October 26, 2006 8:02 PM --> To: Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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 --> --> --> Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFiveI019744 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:44:57 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 27 Oct 2006 08:44:34 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EC67F2AF; Fri, 27 Oct 2006 08:44:33 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C67082AE; Fri, 27 Oct 2006 08:44:33 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJC91925; Fri, 27 Oct 2006 08:44:32 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C88AC20502; Fri, 27 Oct 2006 08:44:31 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Oct 2006 08:44:30 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1BCE821@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2B4B3EA@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb5XAUFWw1JBt61Q8euEeSaMfQumAAe9arwAAGjsJA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, Radia.Perlman@sun.com, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> X-WSS-ID: 695CF6E835W5184738-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RFiveI019744 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:46:22 -0000 Status: RO Content-Length: 825 rbridge-bounces@postel.org 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. Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFhl5b019153 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:43:47 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RFhgfK013590; Fri, 27 Oct 2006 11:43:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12939; Fri, 27 Oct 2006 11:43:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4QYKW>; Fri, 27 Oct 2006 11:43:41 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0053@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> Date: Fri, 27 Oct 2006 11:43:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:43:58 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Wadekar, Manoj K --> Sent: Friday, October 27, 2006 11:21 AM --> To: rbridge@postel.org --> 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:sgai@nuovasystems.com] --> Sent: Friday, October 27, 2006 8:00 AM --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] --> On --> > Behalf Of Radia.Perlman@sun.com --> > Sent: Thursday, October 26, 2006 5:02 PM --> > To: Wadekar, Manoj K --> > Cc: rbridge@postel.org --> > 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFhPGR019088 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:43:26 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9RFbrfK013443; Fri, 27 Oct 2006 11:37:54 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12410; Fri, 27 Oct 2006 11:37:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4QYG0>; Fri, 27 Oct 2006 11:37:52 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125BA0050@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Fri, 27 Oct 2006 11:37:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia.Perlman@sun.com Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:43:59 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Friday, October 27, 2006 11:00 AM --> To: Radia.Perlman@sun.com; Wadekar, Manoj K --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] --> On --> > Behalf Of Radia.Perlman@sun.com --> > Sent: Thursday, October 26, 2006 5:02 PM --> > To: Wadekar, Manoj K --> > Cc: rbridge@postel.org --> > 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RFL1IO011264 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:21:01 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 27 Oct 2006 08:21:01 -0700 Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by azsmga001.ch.intel.com with ESMTP; 27 Oct 2006 08:21:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,366,1157353200"; d="scan'208"; a="136776757:sNHT23684388" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 08:21:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 08:20:59 -0700 Message-ID: <79E93560F4A5FD42BB769DAAF8BEF62ABA5290@scsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb5XAUFWw1JBt61Q8euEeSaMfQumAAe9arwAADMJ6A= From: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> To: <rbridge@postel.org> X-OriginalArrivalTime: 27 Oct 2006 15:21:00.0672 (UTC) FILETIME=[8259E000:01C6F9DB] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: manoj.k.wadekar@intel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RFL1IO011264 Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:21:52 -0000 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:sgai@nuovasystems.com] Sent: Friday, October 27, 2006 8:00 AM To: Radia.Perlman@sun.com; Wadekar, Manoj K Cc: rbridge@postel.org 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia.Perlman@sun.com > Sent: Thursday, October 26, 2006 5:02 PM > To: Wadekar, Manoj K > Cc: rbridge@postel.org > 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 > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9RF0VO1004078 for <rbridge@postel.org>; Fri, 27 Oct 2006 08:00:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 2006 08:00:28 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2B4B3EA@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge address and BCN Thread-Index: Acb5XAUFWw1JBt61Q8euEeSaMfQumAAe9arw From: "Silvano Gai" <sgai@nuovasystems.com> To: <Radia.Perlman@sun.com>, "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9RF0VO1004078 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 15:00:56 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia.Perlman@sun.com > Sent: Thursday, October 26, 2006 5:02 PM > To: Wadekar, Manoj K > Cc: rbridge@postel.org > 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 > Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9R01oql022459 for <rbridge@postel.org>; Thu, 26 Oct 2006 17:01:50 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7R00K1FPF2YQ00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 26 Oct 2006 17:01:50 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7R00AXCPF2QM00@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 26 Oct 2006 17:01:50 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 26 Oct 2006 17:01:50 -0700 Date: Thu, 26 Oct 2006 17:01:50 -0700 From: Radia.Perlman@sun.com To: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> Message-id: <ffa96e6369c2.4540e9fe@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_tkMORaXCcsuZlvSz8rzsEA)" Content-language: en X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 27 Oct 2006 00:02:13 -0000 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> </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> </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 “no-drop” 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> </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> </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> </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> </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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge --Boundary_(ID_tkMORaXCcsuZlvSz8rzsEA)-- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9QNqQLl019175 for <rbridge@postel.org>; Thu, 26 Oct 2006 16:52:26 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7R00K1BOZBYP00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 26 Oct 2006 16:52:23 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7R00AVQOZBQM00@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Thu, 26 Oct 2006 16:52:23 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [67.160.72.180]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 26 Oct 2006 16:52:23 -0700 Date: Thu, 26 Oct 2006 16:52:23 -0700 From: Radia.Perlman@sun.com To: "Sanjay Sane (sanjays)" <sanjays@cisco.com> Message-id: <ff85cd0c62b5.4540e7c7@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: [rbridge] How many trees, and per what X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 26 Oct 2006 23:52:41 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9QMCCkU015994 for <rbridge@postel.org>; Thu, 26 Oct 2006 15:12:12 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9QMC8fK000989; Thu, 26 Oct 2006 18:12:08 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA22746; Thu, 26 Oct 2006 18:12:07 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4QNTG>; Thu, 26 Oct 2006 18:12:07 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FFD0@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Sanjay Sane (sanjays)" <sanjays@cisco.com> Date: Thu, 26 Oct 2006 18:12:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 26 Oct 2006 22:12:38 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Sanjay --> Sane (sanjays) --> Sent: Thursday, October 26, 2006 5:39 PM --> To: Maltbie, Dan; rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Maltbie, Dan --> Sent: Wednesday, October 25, 2006 11:07 PM --> To: rbridge@postel.org --> 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\)" <sanjays@cisco.com> --> Subject: Re: [rbridge] Ingress Rbridge and FTAG again --> To: "Radia Perlman" <Radia.Perlman@sun.com> --> Cc: rbridge@postel.org --> Message-ID: --> --> <7178B7E237F45D45BE404AFF0AF58D870181BCCF@xmb-sjc-213.amer.c --> isco.com> --> Content-Type: text/plain; charset="us-ascii" --> --> --> <<snip>> --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> End of rbridge Digest, Vol 29, Issue 30 --> *************************************** --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9QLcowM006039 for <rbridge@postel.org>; Thu, 26 Oct 2006 14:38:50 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 14:38:50 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QLcnSA002679; Thu, 26 Oct 2006 14:38:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9QLcnW4026011; Thu, 26 Oct 2006 14:38:49 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Oct 2006 14:38:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Oct 2006 14:38:49 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BCD3@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acb4sPvUarlGeZvASvKmZwoiLf8LkgAD/dlwACBgykA= From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Maltbie, Dan" <dmaltbie@wovensystems.com>, <rbridge@postel.org> X-OriginalArrivalTime: 26 Oct 2006 21:38:49.0821 (UTC) FILETIME=[1FCDC0D0:01C6F947] DKIM-Signature: a=rsa-sha1; q=dns; l=2378; t=1161898729; x=1162762729; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3DXLcZB5rjg+vmTnIBR12KxyowRQ4=3D; b=Kx9cMhmT5XV9UIG3DtLAmMSp3ln/BVvUnUBkaAX+14h3s3qS1lv3LeM6KQvNl+xSxUOY1D86 tZBImRrJBZHtZlfDLfMq0Ew0QU8a94O/PYwy23ujXcGwchtzbr01Ai/9; Authentication-Results: sj-dkim-4.cisco.com; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9QLcowM006039 Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 26 Oct 2006 21:39:10 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Maltbie, Dan Sent: Wednesday, October 25, 2006 11:07 PM To: rbridge@postel.org 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\)" <sanjays@cisco.com> Subject: Re: [rbridge] Ingress Rbridge and FTAG again To: "Radia Perlman" <Radia.Perlman@sun.com> Cc: rbridge@postel.org Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BCCF@xmb-sjc-213.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" <<snip>> _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge End of rbridge Digest, Vol 29, Issue 30 *************************************** _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail.wovensystems.com (h-66-167-200-162.snvacaid.covad.net [66.167.200.162]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9Q66aVM005834 for <rbridge@postel.org>; Wed, 25 Oct 2006 23:06:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Oct 2006 23:06:34 -0700 Message-ID: <6BE8F8BB68FDA14381725153C20B7171220759@MAIL1.wovensystems.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ingress Rbridge and FTAG again Thread-Index: Acb4sPvUarlGeZvASvKmZwoiLf8LkgAD/dlw From: "Maltbie, Dan" <dmaltbie@wovensystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dmaltbie@wovensystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9Q66aVM005834 Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 26 Oct 2006 06:07:03 -0000 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\)" <sanjays@cisco.com> Subject: Re: [rbridge] Ingress Rbridge and FTAG again To: "Radia Perlman" <Radia.Perlman@sun.com> Cc: rbridge@postel.org Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BCCF@xmb-sjc-213.amer.cisco.com> Content-Type: text/plain; charset="us-ascii" <<snip>> _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge End of rbridge Digest, Vol 29, Issue 30 *************************************** Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9Q2URgK028892 for <rbridge@postel.org>; Wed, 25 Oct 2006 19:30:27 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2006 19:30:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9Q2UQfx011946; Wed, 25 Oct 2006 19:30:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9Q2UQW4013701; Wed, 25 Oct 2006 19:30:26 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Oct 2006 19:30:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Oct 2006 19:30:26 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BCCF@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acb4j+CAa+9Xc7/3R8KQa1nNgk/XNAAEr/lA From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-OriginalArrivalTime: 26 Oct 2006 02:30:26.0775 (UTC) FILETIME=[B2634E70:01C6F8A6] DKIM-Signature: a=rsa-sha1; q=dns; l=9325; t=1161829827; x=1162693827; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3DXLcZB5rjg+vmTnIBR12KxyowRQ4=3D; b=WIxbExjADK1LKmSIwAQtgfHntYlgCzG/SVE3XmW5GFcQy365xXF912B7j9d9C5TB4SuB9Q0y 9zYJgKDG7U4SwrniQBG2xun0c/51GVCqWozxm6Cg13xLjlehevkcZzh8; Authentication-Results: sj-dkim-4.cisco.com; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9Q2URgK028892 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 26 Oct 2006 02:32:40 -0000 Status: RO Content-Length: 8894 see inline with <sanjay> -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@sun.com] Sent: Wednesday, October 25, 2006 4:47 PM To: Sanjay Sane (sanjays) Cc: Alia Atlas; Dinesh G Dutt (ddutt); rbridge@postel.org 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Alia Atlas >Sent: Monday, October 23, 2006 1:47 PM >To: Dinesh G Dutt (ddutt) >Cc: rbridge@postel.org >Subject: Re: [rbridge] Ingress Rbridge and FTAG again > >Hi Dinesh, > >On 10/20/06, Dinesh G Dutt <ddutt@cisco.com> 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 >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9Q25pHb018329 for <rbridge@postel.org>; Wed, 25 Oct 2006 19:05:51 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 25 Oct 2006 19:05:51 -0700 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by fmsmga001.fm.intel.com with ESMTP; 25 Oct 2006 19:05:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,358,1157353200"; d="scan'208,217"; a="152140777:sNHT63974015" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Oct 2006 19:05:50 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F8A3.42673E7B" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Oct 2006 19:05:48 -0700 Message-ID: <79E93560F4A5FD42BB769DAAF8BEF62ABA4B46@scsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ingress Rbridge address and BCN Thread-Index: Acb4o0ErKUSnEhhASr6GhDhesbNTMg== From: "Wadekar, Manoj K" <manoj.k.wadekar@intel.com> To: <rbridge@postel.org> X-OriginalArrivalTime: 26 Oct 2006 02:05:50.0369 (UTC) FILETIME=[4261A110:01C6F8A3] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: manoj.k.wadekar@intel.com Subject: [rbridge] Ingress Rbridge address and BCN X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 26 Oct 2006 02:06:24 -0000 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> </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> </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 “no-drop” = 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> </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> </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> </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> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C6F8A3.42673E7B-- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9PNkidM006515 for <rbridge@postel.org>; Wed, 25 Oct 2006 16:46:44 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7P00J0QU1K7H00@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 25 Oct 2006 16:46:32 -0700 (PDT) Received: from sun.com ([129.150.21.98]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7P0096BU1FT320@mail.sunlabs.com> for rbridge@postel.org; Wed, 25 Oct 2006 16:46:28 -0700 (PDT) Date: Wed, 25 Oct 2006 16:46:32 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <7178B7E237F45D45BE404AFF0AF58D870181BCCB@xmb-sjc-213.amer.cisco.com> To: "Sanjay Sane (sanjays)" <sanjays@cisco.com> Message-id: <453FF758.60505@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <7178B7E237F45D45BE404AFF0AF58D870181BCCB@xmb-sjc-213.amer.cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 25 Oct 2006 23:47:01 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On >Behalf Of Alia Atlas >Sent: Monday, October 23, 2006 1:47 PM >To: Dinesh G Dutt (ddutt) >Cc: rbridge@postel.org >Subject: Re: [rbridge] Ingress Rbridge and FTAG again > >Hi Dinesh, > >On 10/20/06, Dinesh G Dutt <ddutt@cisco.com> 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 >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > >_______________________________________________ >rbridge mailing list >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9PM6XZt004323 for <rbridge@postel.org>; Wed, 25 Oct 2006 15:06:33 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2006 15:06:33 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PM6XXo021045; Wed, 25 Oct 2006 15:06:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9PM6SbF009434; Wed, 25 Oct 2006 15:06:29 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Oct 2006 15:06:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Oct 2006 15:06:28 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BCCB@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acb25hi7HgqEHavgQLSmuKBuO3ixZABlHMUg From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Alia Atlas" <akatlas@gmail.com>, "Dinesh G Dutt \(ddutt\)" <ddutt@cisco.com> X-OriginalArrivalTime: 25 Oct 2006 22:06:28.0837 (UTC) FILETIME=[D23DC150:01C6F881] DKIM-Signature: a=rsa-sha1; q=dns; l=5516; t=1161813993; x=1162677993; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:RE=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3DXLcZB5rjg+vmTnIBR12KxyowRQ4=3D; b=pyWZBR0Vf3rh4ufLGF1wgHNiok9X9xbksi4SmBA+wAA5BZWw+eieYOTSAAct27CzPWc8xJ4l oWXrt18o2NjdpnZMux2Gx1g9u/Oq/q8Awmr4Hc7L/6U7EgV/JL8+dV0X; Authentication-Results: sj-dkim-7.cisco.com; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9PM6XZt004323 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 25 Oct 2006 22:06:53 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Alia Atlas Sent: Monday, October 23, 2006 1:47 PM To: Dinesh G Dutt (ddutt) Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again Hi Dinesh, On 10/20/06, Dinesh G Dutt <ddutt@cisco.com> 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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9PKbhpZ001013 for <rbridge@postel.org>; Wed, 25 Oct 2006 13:37:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1161808582!4709364!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 6589 invoked from network); 25 Oct 2006 20:36:22 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-7.tower-128.messagelabs.com with SMTP; 25 Oct 2006 20:36:22 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id k9PKeDT0009363 for <rbridge@postel.org>; Wed, 25 Oct 2006 13:40:30 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k9PKa32T005209 for <rbridge@postel.org>; Wed, 25 Oct 2006 15:36:04 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Oct 2006 16:36:02 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979001934A46@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call on Problem and Applicability Statement and Routing Requirements, Expert Review of Architecture Draft thread-index: Acb4dS/tLm5z5SbnQLG4+dNiBLTKwA== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9PKbhpZ001013 Subject: [rbridge] Working Group Last Call on Problem and Applicability Statement and Routing Requirements, Expert Review of Architecture Draft X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 25 Oct 2006 20:38:47 -0000 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 Donald.Eastlake@motorola.com, erik.nordmark@sun.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NL2lRi018946 for <rbridge@postel.org>; Mon, 23 Oct 2006 14:02:47 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9NL2hfK020538; Mon, 23 Oct 2006 17:02:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09064; Mon, 23 Oct 2006 17:02:43 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4J0PD>; Mon, 23 Oct 2006 17:02:42 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FC64@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia.Perlman@sun.com Date: Mon, 23 Oct 2006 17:02:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 21:03:09 -0000 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: Radia.Perlman@sun.com [mailto:Radia.Perlman@sun.com] --> Sent: Monday, October 23, 2006 4:17 PM --> To: Gray, Eric --> Cc: Dinesh G Dutt; Joe Touch; rbridge@postel.org --> 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 --> Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NKl1Bv012848 for <rbridge@postel.org>; Mon, 23 Oct 2006 13:47:01 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id p31so1266999ugc for <rbridge@postel.org>; Mon, 23 Oct 2006 13:46:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GH5zbRO6ZzwYUgycRXEMQUhJdl+iaia8DpIn9trWB94N7ZO8F+HmNAE8JikpNmhixphLYATnlc6xHG5u0CnGqCvxtPtGeOE57pEE+q178SiP3h+nyyx7ZJQ97Dm4/bvON9802gyfuzTgsLCcBYdqkXDePDyCXc89Dn3BTMJ+p7s= Received: by 10.78.166.7 with SMTP id o7mr8050026hue; Mon, 23 Oct 2006 13:46:56 -0700 (PDT) Received: by 10.78.90.3 with HTTP; Mon, 23 Oct 2006 13:46:56 -0700 (PDT) Message-ID: <6280db520610231346re66a3e4t493fa6fc229a4e28@mail.gmail.com> Date: Mon, 23 Oct 2006 13:46:56 -0700 From: "Alia Atlas" <akatlas@gmail.com> To: "Dinesh G Dutt" <ddutt@cisco.com> In-Reply-To: <45393E21.2060201@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> <45392756.6070901@cisco.com> <6280db520610201409i2e00c43aq50a3ffc518e52ab9@mail.gmail.com> <45393E21.2060201@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 20:47:39 -0000 Status: RO Content-Length: 3240 Hi Dinesh, On 10/20/06, Dinesh G Dutt <ddutt@cisco.com> 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 Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NKGmQO000598 for <rbridge@postel.org>; Mon, 23 Oct 2006 13:16:49 -0700 (PDT) Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7L00E2YUZM0E10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 23 Oct 2006 13:16:34 -0700 (PDT) Received: from sunlabs.com ([152.70.2.254]) by mail-srv.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7L00MABUZMSP40@mail-srv.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 23 Oct 2006 13:16:34 -0700 (PDT) Received: from [152.70.2.164] (Forwarded-For: [192.18.43.249]) by mail-srv.sfvic.sunlabs.com (mshttpd); Mon, 23 Oct 2006 13:16:34 -0700 Date: Mon, 23 Oct 2006 13:16:34 -0700 From: Radia.Perlman@sun.com To: "Gray, Eric" <Eric.Gray@marconi.com> Message-id: <ed52d69f4e2b.453cc0b2@sunlabs.com> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 20:17:07 -0000 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 Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NIppuM028539 for <rbridge@postel.org>; Mon, 23 Oct 2006 11:51:51 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 23 Oct 2006 11:51:42 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BE27E2AE; Mon, 23 Oct 2006 11:51:42 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 680162AF; Mon, 23 Oct 2006 11:51:42 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIP29610; Mon, 23 Oct 2006 11:51:41 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6685020501; Mon, 23 Oct 2006 11:51:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 11:51:39 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1B00299@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <453CEB07.1030606@isi.edu> Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acb2v/WTvNKbQOboQjG1/brE/Uc5uQAEvFqw From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Joe Touch" <touch@ISI.EDU>, "Silvano Gai" <sgai@nuovasystems.com> X-WSS-ID: 6923D0B435W2925407-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9NIppuM028539 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 18:52:06 -0000 Status: RO Content-Length: 1380 rbridge-bounces@postel.org 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? Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NIIoJG016727 for <rbridge@postel.org>; Mon, 23 Oct 2006 11:18:51 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9NIIlfK011760; Mon, 23 Oct 2006 14:18:48 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26060; Mon, 23 Oct 2006 14:18:47 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4JSL9>; Mon, 23 Oct 2006 14:18:46 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FC16@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Dinesh G Dutt <ddutt@cisco.com>, Joe Touch <touch@ISI.EDU> Date: Mon, 23 Oct 2006 14:18:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 18:19:02 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Dinesh G Dutt --> Sent: Monday, October 23, 2006 1:55 PM --> To: Joe Touch --> Cc: rbridge@postel.org --> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NI1NnH009336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 23 Oct 2006 11:01:23 -0700 (PDT) Received: from [12.158.230.155] ([12.158.230.155]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9NI0l1I012639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2006 11:00:47 -0700 (PDT) Message-ID: <453D034C.5080901@isi.edu> Date: Mon, 23 Oct 2006 11:00:44 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dinesh G Dutt <ddutt@cisco.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE40CF@nuova-ex1.hq.nuovaimpresa.com> <453CDF89.3070608@isi.edu> <453D01DA.40201@cisco.com> In-Reply-To: <453D01DA.40201@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD98B30807435677F9F4F1E0" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 18:01:29 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPQNME5f5cImnZrsRAqDpAKDMImXRFO5brW/aFgwwb6myrFR7YQCg3VBI DXJ42mE9JgMfzKRyuLS7zLE= =v793 -----END PGP SIGNATURE----- --------------enigBD98B30807435677F9F4F1E0-- Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NHqGdh005807 for <rbridge@postel.org>; Mon, 23 Oct 2006 10:52:16 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2006 10:52:16 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NHqGRb020564; Mon, 23 Oct 2006 10:52:16 -0700 Received: from [171.71.49.62] (dhcp-171-71-49-62.cisco.com [171.71.49.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9NHqGbF028913; Mon, 23 Oct 2006 10:52:16 -0700 (PDT) Message-ID: <453D01DA.40201@cisco.com> Date: Mon, 23 Oct 2006 10:54:34 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: Joe Touch <touch@ISI.EDU> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE40CF@nuova-ex1.hq.nuovaimpresa.com> <453CDF89.3070608@isi.edu> In-Reply-To: <453CDF89.3070608@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1770; t=1161625936; x=1162489936; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3D3jjxpAx9673MJB0jP307edyAkIQ=3D; b=eQsxBkSgxkz+9+IZh7uu3bu1QHcCRXHv1BAP4IDAUyMe1lNRLNwwK4h0YbEK/VRf1uGNsZke MRxf0beQ0WYvFKf+lI7fy45OfqyhFCk8pa/Zi/O75diRjiSr+kj7Gm3D; Authentication-Results: sj-dkim-8.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 17:52:40 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NHGWjG021975 for <rbridge@postel.org>; Mon, 23 Oct 2006 10:16:32 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9NHGVfK008934 for <rbridge@postel.org>; Mon, 23 Oct 2006 13:16:32 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA13798 for <rbridge@postel.org>; Mon, 23 Oct 2006 13:16:31 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4J3V1>; Mon, 23 Oct 2006 13:16:30 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FBF3@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: rbridge@postel.org Date: Mon, 23 Oct 2006 13:16:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Subject: [rbridge] RBridge Architecture X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 17:16:57 -0000 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NGHjHA000280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 23 Oct 2006 09:17:45 -0700 (PDT) Received: from [12.158.230.155] ([12.158.230.155]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9NGHE5H017256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2006 09:17:15 -0700 (PDT) Message-ID: <453CEB07.1030606@isi.edu> Date: Mon, 23 Oct 2006 09:17:11 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE40E0@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE40E0@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig087D26040D775849E62FA63D" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 16:18:12 -0000 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:touch@ISI.EDU] >> Sent: Monday, October 23, 2006 8:28 AM >> To: Silvano Gai >> Cc: Dinesh G Dutt; rbridge@postel.org >> 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: rbridge-bounces@postel.org > [mailto:rbridge-bounces@postel.org] >>> On >>>> Behalf Of Joe Touch >>>> Sent: Monday, October 23, 2006 6:36 AM >>>> To: Dinesh G Dutt >>>> Cc: rbridge@postel.org >>>> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPOsHE5f5cImnZrsRAvfkAKCosNPu1FmZmjfNlNM9nDnQF8oCvQCfdG/3 Ha53ldbawzQI3yKEkpDusOY= =Trt4 -----END PGP SIGNATURE----- --------------enig087D26040D775849E62FA63D-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NG8rvT027245 for <rbridge@postel.org>; Mon, 23 Oct 2006 09:08:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Oct 2006 09:08:49 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE40E0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acb2uDR863DVZdQfQe6crK/7EdRWFAAAfQ7w From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9NG8rvT027245 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 16:09:31 -0000 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:touch@ISI.EDU] > Sent: Monday, October 23, 2006 8:28 AM > To: Silvano Gai > Cc: Dinesh G Dutt; rbridge@postel.org > 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > > On > >> Behalf Of Joe Touch > >> Sent: Monday, October 23, 2006 6:36 AM > >> To: Dinesh G Dutt > >> Cc: rbridge@postel.org > >> 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 > > Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NFnruc019688 for <rbridge@postel.org>; Mon, 23 Oct 2006 08:49:53 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9NFnafK005415; Mon, 23 Oct 2006 11:49:40 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26977; Mon, 23 Oct 2006 11:49:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4JJ76>; Mon, 23 Oct 2006 11:49:35 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FBD4@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Joe Touch <touch@ISI.EDU>, Dinesh G Dutt <ddutt@cisco.com> Date: Mon, 23 Oct 2006 11:49:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 15:50:28 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Monday, October 23, 2006 11:23 AM --> To: Joe Touch; Dinesh G Dutt --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] --> On --> > Behalf Of Joe Touch --> > Sent: Monday, October 23, 2006 6:36 AM --> > To: Dinesh G Dutt --> > Cc: rbridge@postel.org --> > 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NFUht3011784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 23 Oct 2006 08:30:43 -0700 (PDT) Received: from [12.158.230.155] ([12.158.230.155]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9NFSCS2003581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2006 08:28:12 -0700 (PDT) Message-ID: <453CDF89.3070608@isi.edu> Date: Mon, 23 Oct 2006 08:28:09 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE40CF@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE40CF@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig84C653A300703692A56BCD79" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 15:30:58 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] > On >> Behalf Of Joe Touch >> Sent: Monday, October 23, 2006 6:36 AM >> To: Dinesh G Dutt >> Cc: rbridge@postel.org >> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPN+JE5f5cImnZrsRAkB5AJ4myqI3t1038Si8UPsJEMRlHeZDHACgzyLE X57AgSeNAmR3l+zo93w8IP8= =oVac -----END PGP SIGNATURE----- --------------enig84C653A300703692A56BCD79-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NFMgl2008825 for <rbridge@postel.org>; Mon, 23 Oct 2006 08:22:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Oct 2006 08:22:38 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE40CF@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acb2qb5pDyp+enuYQaa4lXPixnqNNwADLnNg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU>, "Dinesh G Dutt" <ddutt@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9NFMgl2008825 Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 15:23:06 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Joe Touch > Sent: Monday, October 23, 2006 6:36 AM > To: Dinesh G Dutt > Cc: rbridge@postel.org > 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9NDatwd004147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 23 Oct 2006 06:36:55 -0700 (PDT) Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9NDaCSU008897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2006 06:36:13 -0700 (PDT) Message-ID: <453CC549.3080400@isi.edu> Date: Mon, 23 Oct 2006 06:36:09 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dinesh G Dutt <ddutt@cisco.com> References: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> <45392756.6070901@cisco.com> In-Reply-To: <45392756.6070901@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CB808ECB334A04493246675" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 13:37:24 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPMVJE5f5cImnZrsRAh5bAJ9GT+/pk+BwwCl3NtxHwamL269CkACfWj1V /JnTGd9q1/5LRMgTcoCj0RQ= =11En -----END PGP SIGNATURE----- --------------enig2CB808ECB334A04493246675-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9N3BIel006187 for <rbridge@postel.org>; Sun, 22 Oct 2006 20:11:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Oct 2006 20:11:15 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE40A8@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time for a summary? Thread-Index: Acb2DL8c6k2VvtlHTbKV79413qP41wAQ4Z3Q From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9N3BIel006187 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 23 Oct 2006 03:11:32 -0000 Status: RO Content-Length: 2234 Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Sunday, October 22, 2006 12:02 PM > To: Silvano Gai > Cc: Radia Perlman; Gray, Eric; Dino Farinacci (dino); rbridge@postel.org > 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9MNFdEl008494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sun, 22 Oct 2006 16:15:39 -0700 (PDT) Received: from [128.9.176.73] ([128.9.176.73]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9MNEgXd028110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Oct 2006 16:14:43 -0700 (PDT) Message-ID: <453BFB60.7060106@isi.edu> Date: Sun, 22 Oct 2006 16:14:40 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: rbridge@postel.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig94C918964D4112C9950DFE52" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Subject: [rbridge] updated draft-ietf-trill-prob-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 22 Oct 2006 23:15:55 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFO/tgE5f5cImnZrsRAiB2AKD6J6Djh//MMMWvn8bEWljE+xmoXgCdGlG3 RQcP4LaEaVIRDfiyMX9szLs= =v6/s -----END PGP SIGNATURE----- --------------enig94C918964D4112C9950DFE52-- Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9MMriq0000538 for <rbridge@postel.org>; Sun, 22 Oct 2006 15:53:45 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2006 15:53:45 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9MMriMq020460; Sun, 22 Oct 2006 15:53:44 -0700 Received: from [10.21.112.135] (sjc-vpn2-135.cisco.com [10.21.112.135]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9MMrhOV006903; Sun, 22 Oct 2006 15:53:44 -0700 (PDT) Message-ID: <453BF700.5010102@cisco.com> Date: Sun, 22 Oct 2006 15:56:00 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: Joe Touch <touch@ISI.EDU> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3E60@nuova-ex1.hq.nuovaimpresa.com> <453A5798.70809@isi.edu> In-Reply-To: <453A5798.70809@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=714; t=1161557624; x=1162421624; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Time=20for=20a=20summary?; X=v=3Dcisco.com=3B=20h=3DYvNh6huxXtNOuMvPNOxDsCfXFvI=3D; b=OZ2peqmw3M9xTgwf0vI2BPWOXhZ0qdbHYNh9MrI2TR87y8WnvaswZHX090+CxqtOlJ6O/cQU TrWhxxq0DA5kMEmnbwU8Yahc1JrGBDUJ4+sG2K+dmTTsdv7GwyWrMaUt; Authentication-Results: sj-dkim-7.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 22 Oct 2006 22:53:56 -0000 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9MJ3MA8001993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sun, 22 Oct 2006 12:03:22 -0700 (PDT) Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9MJ2WBG011563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Oct 2006 12:02:32 -0700 (PDT) Message-ID: <453BC045.9080902@isi.edu> Date: Sun, 22 Oct 2006 12:02:29 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE4090@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE4090@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6600709B136E0A633FA281FD" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 22 Oct 2006 19:03:47 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFO8BFE5f5cImnZrsRAv3sAJwOopy6HZOMoPKTR6yfwT3vb8EzXQCfTajs uOKYJAaCYHJQ8RoZYCCa/7E= =vP2S -----END PGP SIGNATURE----- --------------enig6600709B136E0A633FA281FD-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9MJ0mT1001078 for <rbridge@postel.org>; Sun, 22 Oct 2006 12:00:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Oct 2006 12:00:45 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE4091@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FTag Thread-Index: Acb0eq99lXazXuWETa+6xzIs2FBE7QBkQSGw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9MJ0mT1001078 Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 22 Oct 2006 19:01:19 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 20, 2006 12:05 PM > To: Silvano Gai > Cc: rbridge@postel.org > 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:sgai@nuovasystems.com] > --> Sent: Wednesday, October 18, 2006 12:04 PM > --> To: Gray, Eric > --> Cc: rbridge@postel.org > --> 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:Eric.Gray@marconi.com] > --> > Sent: Wednesday, October 18, 2006 4:57 AM > --> > To: Silvano Gai > --> > Cc: rbridge@postel.org > --> > 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] -- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9MIt6EL029696 for <rbridge@postel.org>; Sun, 22 Oct 2006 11:55:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Oct 2006 11:55:03 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE4090@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time for a summary? Thread-Index: Acb1NcTbelGHAnbuS4C7TUVC3Hxq6AA1I5pw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9MIt6EL029696 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sun, 22 Oct 2006 18:55:22 -0000 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:touch@ISI.EDU] > Sent: Saturday, October 21, 2006 10:24 AM > To: Silvano Gai > Cc: Radia Perlman; Gray, Eric; Dino Farinacci (dino); rbridge@postel.org > 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. > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9LHOUcS023540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sat, 21 Oct 2006 10:24:31 -0700 (PDT) Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9LHNftc020570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 21 Oct 2006 10:23:44 -0700 (PDT) Message-ID: <453A5798.70809@isi.edu> Date: Sat, 21 Oct 2006 10:23:36 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3E60@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3E60@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig15C3BBF9420F9A509E1483F8" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 21 Oct 2006 17:24:33 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFOlebE5f5cImnZrsRAqkCAJ9WBIJV14dU79Ay/Tpa1CfhjSyCYwCghhm0 B3y27656r3qWd/Nf9m2uEQs= =Xe3I -----END PGP SIGNATURE----- --------------enig15C3BBF9420F9A509E1483F8-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9L0o2K6008126 for <rbridge@postel.org>; Fri, 20 Oct 2006 17:50:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Oct 2006 17:49:59 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE4010@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time for a summary? Thread-Index: Acb0fyAiEl3LcnATTCGFkcanFjsPhwAKpP1Q From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9L0o2K6008126 Cc: rbridge@postel.org Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 21 Oct 2006 00:50:33 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 20, 2006 10:35 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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] -- Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KLKPTL002644 for <rbridge@postel.org>; Fri, 20 Oct 2006 14:20:25 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2006 14:20:26 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KLKPc2002721; Fri, 20 Oct 2006 14:20:25 -0700 Received: from [10.21.89.173] (sjc-vpn5-429.cisco.com [10.21.89.173]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9KLKPOV029808; Fri, 20 Oct 2006 14:20:25 -0700 (PDT) Message-ID: <45393E21.2060201@cisco.com> Date: Fri, 20 Oct 2006 14:22:41 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> <45392756.6070901@cisco.com> <6280db520610201409i2e00c43aq50a3ffc518e52ab9@mail.gmail.com> In-Reply-To: <6280db520610201409i2e00c43aq50a3ffc518e52ab9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2350; t=1161379225; x=1162243225; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3D3jjxpAx9673MJB0jP307edyAkIQ=3D; b=CwowT9t1Ng12J7L2wmMYH8rqSzfW7wsBplQ/K91r6+Cq9qvY7QeIlknJNlfZ3RqxLBYh7uus b88eiNDPTuDhh0pK4H3HBNjNkiWXD+e0F2cK9502XJYEv9oDmLhe6UXm; Authentication-Results: sj-dkim-5.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 21:20:58 -0000 Status: RO Content-Length: 2302 Hi Alia, Alia Atlas wrote: > Hi Dinesh, > > On 10/20/06, Dinesh G Dutt <ddutt@cisco.com> 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 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KL9Z2H028587 for <rbridge@postel.org>; Fri, 20 Oct 2006 14:09:35 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id 30so1285163ugs for <rbridge@postel.org>; Fri, 20 Oct 2006 14:09:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OZroKhT47qJuvMQCdBwYE5z1hsUKd+QFuPcHSPhu4mZ4Jc4fQiuriLMduqs1Sw5Kw2aFyX9HL+ZcH3YTUJrtoaaXfb1XYrg12nGxT1VGYubXn2MXvmF1KnMhTIoMPQTVxWHD58bgoo1qVlj2KiWH7hDkY6q8VDOPrrPiqkSSrmQ= Received: by 10.78.151.15 with SMTP id y15mr2727896hud; Fri, 20 Oct 2006 14:09:25 -0700 (PDT) Received: by 10.78.90.3 with HTTP; Fri, 20 Oct 2006 14:09:24 -0700 (PDT) Message-ID: <6280db520610201409i2e00c43aq50a3ffc518e52ab9@mail.gmail.com> Date: Fri, 20 Oct 2006 14:09:25 -0700 From: "Alia Atlas" <akatlas@gmail.com> To: "Dinesh G Dutt" <ddutt@cisco.com> In-Reply-To: <45392756.6070901@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> <45392756.6070901@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 21:10:05 -0000 Status: RO Content-Length: 1632 Hi Dinesh, On 10/20/06, Dinesh G Dutt <ddutt@cisco.com> 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 Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KKC98C008427 for <rbridge@postel.org>; Fri, 20 Oct 2006 13:12:09 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 20 Oct 2006 13:11:57 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8F5BF2B0; Fri, 20 Oct 2006 13:11:57 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 67EEA2AF; Fri, 20 Oct 2006 13:11:57 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EII24672; Fri, 20 Oct 2006 13:11:57 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 016FC20501; Fri, 20 Oct 2006 13:11:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Oct 2006 13:11:55 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1B00170@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125B9FAFA@uspitsmsgusr08.pit.comms.marconi.com> Thread-Topic: [rbridge] Time for a summary? Thread-Index: Acb0b9L69a2hwlCkTfOPOyvR6Cp2rAAE6v2A From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Silvano Gai" <sgai@nuovasystems.com> X-WSS-ID: 6927F20738S941156-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9KKC98C008427 Cc: rbridge@postel.org Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 20:12:25 -0000 Status: RO Content-Length: 1005 rbridge-bounces@postel.org 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? Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KJhBpi026843 for <rbridge@postel.org>; Fri, 20 Oct 2006 12:43:11 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2006 12:43:11 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KJhAuS006661; Fri, 20 Oct 2006 12:43:10 -0700 Received: from [10.21.89.173] (sjc-vpn5-429.cisco.com [10.21.89.173]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9KJhAOV005238; Fri, 20 Oct 2006 12:43:10 -0700 (PDT) Message-ID: <45392756.6070901@cisco.com> Date: Fri, 20 Oct 2006 12:45:26 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: "Gray, Eric" <Eric.Gray@marconi.com> References: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=745; t=1161373390; x=1162237390; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3D3jjxpAx9673MJB0jP307edyAkIQ=3D; b=bq243tpH89v9T5YoWp2IfS4ThCHNxZpiCsIgXiMtVsLXopwlrSglvItAxuuQj9puj613lQam JfVUISTrvSsMXFBEYK68SCmb0pMbogAAWnu9X9MnUuxqTvxcqlwt1SNe; Authentication-Results: sj-dkim-7.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 19:43:47 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KJCUQX014627 for <rbridge@postel.org>; Fri, 20 Oct 2006 12:12:30 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9KJCQfK025070; Fri, 20 Oct 2006 15:12:27 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26409; Fri, 20 Oct 2006 15:12:26 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N41M7W>; Fri, 20 Oct 2006 15:12:25 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FB10@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Dinesh G Dutt <ddutt@cisco.com> Date: Fri, 20 Oct 2006 15:12:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 19:13:07 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Dinesh G Dutt --> Sent: Friday, October 20, 2006 1:32 PM --> To: Joe Touch --> Cc: rbridge@postel.org --> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KJ5JCK012202 for <rbridge@postel.org>; Fri, 20 Oct 2006 12:05:19 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9KJ5GfK024576; Fri, 20 Oct 2006 15:05:16 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24619; Fri, 20 Oct 2006 15:05:16 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N41MNM>; Fri, 20 Oct 2006 15:05:15 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FB0B@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Fri, 20 Oct 2006 15:05:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 19:06:08 -0000 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:sgai@nuovasystems.com] --> Sent: Wednesday, October 18, 2006 12:04 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> > Sent: Wednesday, October 18, 2006 4:57 AM --> > To: Silvano Gai --> > Cc: rbridge@postel.org --> > 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] -- Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KINo8P027605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Oct 2006 11:23:50 -0700 (PDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k9KINn9m015866; Fri, 20 Oct 2006 14:23:49 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9KINnAr527742; Fri, 20 Oct 2006 12:23:49 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9KINmTe021311; Fri, 20 Oct 2006 12:23:49 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.17.195.60]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9KINmF0021305; Fri, 20 Oct 2006 12:23:48 -0600 In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3E60@nuova-ex1.hq.nuovaimpresa.com> To: "Silvano Gai" <sgai@nuovasystems.com> X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: <OF715F426F.4A428A2B-ON8525720D.00639A3A-8525720D.00650CAB@us.ibm.com> From: Ed Bowen <edbowen@us.ibm.com> Date: Fri, 20 Oct 2006 14:23:43 -0400 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/20/2006 12:23:48 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF89EDFF01CAA8f9e8a93df938690918c0ABBF89EDFF01CAA" Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: edbowen@us.ibm.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, rbridge-bounces@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 18:24:37 -0000 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 rbridge-bounces@postel.org 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:Radia.Perlman@sun.com] > > Sent: Friday, October 20, 2006 7:07 AM > > To: Gray, Eric > > Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); rbridge@postel.o= 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 > rbridge@postel.org > 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>rbridge-bounces@postel.org wrote on 10/20/2006 12:20:59 PM:<br> <br> > Radia,<br> > <br> > I am not the right person for the summary, but let me give you my<= br> > perspective:<br> > <br> > It is bits Vs features:<br> > <br> > - One group advocates that features have been defined in the TRILL= <br> > charter and in the doc:<br> > <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> > and that we need to define a TRILL shim that accommodates these fe= atures<br> > using the minimum number of bits.<br> > <br> > - Another group claims that more features are required (e.g.<br> > Troubleshooting, tracing, efficient multicast, etc.) and that thes= e<br> > features are worth few extra bytes.<br> > <br> > Let's also use some quantitative analysis. The TRILL Ethernet head= er<br> > currently defined in:<br> > <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> > .txt<br> > is 18 bytes<br> > <br> > The new proposal as modified by Dinesh Dutt is 20 bytes.<br> > <br> > On an average 512 bytes payload the old proposal has an overhead o= f<br> > 3.27% and the new proposal has an overhead of 3.64%, a difference = of<br> > 0.37%.<br> > <br> > I claim you cannot find a single user that is not willing to spend= 0.37%<br> > of its campus bandwidth to have:<br> > - more security<br> > - more troubleshooting (especially under attack)<br> > - better multicast handling<br> > - better topology management<br> > <br> > Do you agree?<br> > <br> > -- Silvano<br> > <br> > > -----Original Message-----<br> > > From: Radia Perlman [<a href=3D"mailto:Radia.Perlman@sun.com"= >mailto:Radia.Perlman@sun.com</a>]<br> > > Sent: Friday, October 20, 2006 7:07 AM<br> > > To: Gray, Eric<br> > > Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); rbridge@po= stel.org<br> > > Subject: Time for a summary?<br> > > <br> > > I've been travelling for a few days, and have just enough ema= il access<br> > > to notice there has been a really<br> > > high volume of email, which undoubtedly will be hard for me a= nd most<br> > > others, to catch up on.<br> > > <br> > > Can someone who has been following this discussion the last c= ouple<br> > days<br> > > post a summary? I think<br> > > we are arguing over several different potentially added field= s:<br> > > a) F-Tag<br> > > b) both ingress and egress RBridge<br> > > c) ingress LID<br> > > d) egress LID<br> > > <br> > > I'd prefer a separate summary of the arguments for and agains= t each of<br> > > those fields.<br> > > Whoever is summarizing shouldn't be advocating, but rather ju= st<br> > putting<br> > > in one message what they understand<br> > > to be all the arguments presented. I'd prefer no names as in = "argument<br> > > against: extra space in header" rather<br> > > than "Person X claims it takes extra space".<br> > > <br> > > Then people can resume the discussion starting from the summa= ry, and<br> > > nobody needs to read any<br> > > of the previous emails.<br> > > <br> > > I suppose if nobody does this, I will eventually have some ti= me and<br> > > attempt it.<br> > > <br> > > Thanks,<br> > > <br> > > Radia<br> > > <br> > > >--><br> > > ><br> > > ><br> > <br> > <br> > _______________________________________________<br> > rbridge mailing list<br> > rbridge@postel.org<br> > <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-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KHhMVw015390 for <rbridge@postel.org>; Fri, 20 Oct 2006 10:43:22 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9KHZpfK018632; Fri, 20 Oct 2006 13:35:51 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04682; Fri, 20 Oct 2006 13:35:50 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N41GTP>; Fri, 20 Oct 2006 13:35:35 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FAFA@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Fri, 20 Oct 2006 13:35:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 17:43:50 -0000 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] -- Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KHTwWQ010933 for <rbridge@postel.org>; Fri, 20 Oct 2006 10:29:58 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2006 10:29:58 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KHTwQA010733; Fri, 20 Oct 2006 10:29:58 -0700 Received: from [10.21.89.173] (sjc-vpn5-429.cisco.com [10.21.89.173]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9KHTvOV026130; Fri, 20 Oct 2006 10:29:57 -0700 (PDT) Message-ID: <4539081E.4090601@cisco.com> Date: Fri, 20 Oct 2006 10:32:14 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: Joe Touch <touch@ISI.EDU> References: <453661A7.9070509@cisco.com> <4537B612.1080907@isi.edu> In-Reply-To: <4537B612.1080907@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1994; t=1161365398; x=1162229398; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3D3jjxpAx9673MJB0jP307edyAkIQ=3D; b=RenSyzAYy3/khzrsO3wNUHcDFJF2rH3RcS3VE5wmTP6mD5LVvI7G40aQX+HIrv+qcfePBczT 9EP44MCgtgkrKViymIpNmBEHEV7auMyA235cnv+hbYm0pH2/xLTISCvJ; Authentication-Results: sj-dkim-5.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 17:30:25 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KHSwdf010619 for <rbridge@postel.org>; Fri, 20 Oct 2006 10:28:58 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9KHSrfK017935; Fri, 20 Oct 2006 13:28:54 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02750; Fri, 20 Oct 2006 13:28:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N41GAC>; Fri, 20 Oct 2006 13:28:52 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FAF7@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Dinesh G Dutt <ddutt@cisco.com> Date: Fri, 20 Oct 2006 13:28:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 17:29:28 -0000 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:ddutt@cisco.com] --> Sent: Friday, October 20, 2006 1:22 PM --> To: Gray, Eric --> Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); --> rbridge@postel.org; 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 --> Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KHJUC7007349 for <rbridge@postel.org>; Fri, 20 Oct 2006 10:19:30 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2006 10:19:30 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KHJUh6009677; Fri, 20 Oct 2006 10:19:30 -0700 Received: from [10.21.89.173] (sjc-vpn5-429.cisco.com [10.21.89.173]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9KHJQbF025105; Fri, 20 Oct 2006 10:19:30 -0700 (PDT) Message-ID: <453905A7.1000808@cisco.com> Date: Fri, 20 Oct 2006 10:21:43 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: "Gray, Eric" <Eric.Gray@marconi.com> References: <0BF76B30C100624BA997C9CED19D8125B9FA82@uspitsmsgusr08.pit.comms.marconi.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D8125B9FA82@uspitsmsgusr08.pit.comms.marconi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1415; t=1161364770; x=1162228770; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Range=20of=20appllicability=20(was=20Re=3A=20TTL=20o nly=20-=20was=20RE=3A=0A=20=09New=20fields=20in=20shim=20header?); X=v=3Dcisco.com=3B=20h=3D3XZD+bXS71GFZWBYe8uwQ7yRbbs=3D; b=IYg61f6cNFW613Ts3EZzBVmxVVVFMykOT/1Y/pzlWb3jvez7G7Nmu3YOnfgE5rt2QTgSydUn QQu7HL3158LhYQg5jTcVQZ/jsYXT152+6WM4yjkvODdCWugcRXryYYDW; Authentication-Results: sj-dkim-6.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 17:20:20 -0000 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KGL1IQ018505 for <rbridge@postel.org>; Fri, 20 Oct 2006 09:21:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Oct 2006 09:20:59 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3E60@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time for a summary? Thread-Index: Acb0UPm7Cm3ZZ7HhRdq6r3ZEotYPhQAEPQRA From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9KGL1IQ018505 Cc: rbridge@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 16:21:21 -0000 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:Radia.Perlman@sun.com] > Sent: Friday, October 20, 2006 7:07 AM > To: Gray, Eric > Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); rbridge@postel.org > 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 > > >--> > > > > Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KFM1GI000254 for <rbridge@postel.org>; Fri, 20 Oct 2006 08:22:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Oct 2006 08:21:58 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3E38@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acb0VkntMCN2d894Q5Ocs6u9gWWwbgAAnaKA From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9KFM1GI000254 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 15:22:38 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 20, 2006 7:45 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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] -- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KEilAl008785 for <rbridge@postel.org>; Fri, 20 Oct 2006 07:44:47 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9KEijfK008350; Fri, 20 Oct 2006 10:44:45 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00707; Fri, 20 Oct 2006 10:44:45 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4D752>; Fri, 20 Oct 2006 10:44:44 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FABF@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Fri, 20 Oct 2006 10:44:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 14:45:26 -0000 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] -- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KE6sMb015412 for <rbridge@postel.org>; Fri, 20 Oct 2006 07:06:54 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7F00ABHTV4MZ20@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 20 Oct 2006 07:06:40 -0700 (PDT) Received: from sun.com ([129.150.21.154]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7F002CRTV2MO00@mail.sunlabs.com> for rbridge@postel.org; Fri, 20 Oct 2006 07:06:40 -0700 (PDT) Date: Fri, 20 Oct 2006 07:06:40 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <0BF76B30C100624BA997C9CED19D8125B9FAB8@uspitsmsgusr08.pit.comms.marconi.com> To: "Gray, Eric" <Eric.Gray@marconi.com> Message-id: <4538D7F0.4070804@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <0BF76B30C100624BA997C9CED19D8125B9FAB8@uspitsmsgusr08.pit.comms.marconi.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org, Joe Touch <touch@ISI.EDU> Subject: [rbridge] Time for a summary? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 14:07:27 -0000 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 >--> > > Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9KDvOJI011590 for <rbridge@postel.org>; Fri, 20 Oct 2006 06:57:26 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9KDvAfK005732; Fri, 20 Oct 2006 09:57:11 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21163; Fri, 20 Oct 2006 09:57:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4D5BJ>; Fri, 20 Oct 2006 09:57:08 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FAB8@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, "Gray, Eric" <Eric.Gray@marconi.com>, Joe Touch <touch@ISI.EDU>, "Dino Farinacci (dino)" <dino@cisco.com> Date: Fri, 20 Oct 2006 09:57:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 20 Oct 2006 13:57:57 -0000 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:sgai@nuovasystems.com] --> Sent: Thursday, October 19, 2006 7:47 PM --> To: Gray, Eric; Joe Touch; Dino Farinacci (dino) --> Cc: rbridge@postel.org; 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:Eric.Gray@marconi.com] --> > Sent: Thursday, October 19, 2006 3:13 PM --> > To: Silvano Gai; Joe Touch; Dino Farinacci (dino) --> > Cc: rbridge@postel.org; 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: rbridge-bounces@postel.org --> > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> > --> Sent: Thursday, October 19, 2006 5:44 PM --> > --> To: Joe Touch; Dino Farinacci (dino) --> > --> Cc: rbridge@postel.org; 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:touch@ISI.EDU] --> > --> > Sent: Thursday, October 19, 2006 11:36 AM --> > --> > To: Silvano Gai --> > --> > Cc: Erik Nordmark; rbridge@postel.org; 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:touch@ISI.EDU] --> > --> > >> Sent: Thursday, October 19, 2006 8:58 AM --> > --> > >> To: Silvano Gai --> > --> > >> Cc: Erik Nordmark; rbridge@postel.org; 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 --> > --> rbridge@postel.org --> > --> http://mailman.postel.org/mailman/listinfo/rbridge --> > --> --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JNlOSh007936 for <rbridge@postel.org>; Thu, 19 Oct 2006 16:47:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 16:47:21 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3D91@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acbzy8FaGMBaFbKvSe+O3oP0Q40l2AADEDRw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Joe Touch" <touch@ISI.EDU>, "Dino Farinacci \(dino\)" <dino@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JNlOSh007936 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 23:48:19 -0000 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:Eric.Gray@marconi.com] > Sent: Thursday, October 19, 2006 3:13 PM > To: Silvano Gai; Joe Touch; Dino Farinacci (dino) > Cc: rbridge@postel.org; 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Thursday, October 19, 2006 5:44 PM > --> To: Joe Touch; Dino Farinacci (dino) > --> Cc: rbridge@postel.org; 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:touch@ISI.EDU] > --> > Sent: Thursday, October 19, 2006 11:36 AM > --> > To: Silvano Gai > --> > Cc: Erik Nordmark; rbridge@postel.org; 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:touch@ISI.EDU] > --> > >> Sent: Thursday, October 19, 2006 8:58 AM > --> > >> To: Silvano Gai > --> > >> Cc: Erik Nordmark; rbridge@postel.org; 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JNeHhn005851 for <rbridge@postel.org>; Thu, 19 Oct 2006 16:40:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 16:40:15 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3D8C@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: AcbzyFH11y99ZLV2SvSkxljADFEBbgAD1aVw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JNeHhn005851 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 23:41:01 -0000 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:touch@ISI.EDU] > Sent: Thursday, October 19, 2006 2:48 PM > To: Silvano Gai > Cc: Dino Farinacci (dino); Erik Nordmark; rbridge@postel.org; 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JMD77w008732 for <rbridge@postel.org>; Thu, 19 Oct 2006 15:13:07 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9JMD2fK000350; Thu, 19 Oct 2006 18:13:02 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA13319; Thu, 19 Oct 2006 18:13:01 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4C4AQ>; Thu, 19 Oct 2006 18:12:46 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FA82@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Joe Touch <touch@ISI.EDU>, "Dino Farinacci (dino)" <dino@cisco.com> Date: Thu, 19 Oct 2006 18:12:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 22:13:28 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Thursday, October 19, 2006 5:44 PM --> To: Joe Touch; Dino Farinacci (dino) --> Cc: rbridge@postel.org; 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:touch@ISI.EDU] --> > Sent: Thursday, October 19, 2006 11:36 AM --> > To: Silvano Gai --> > Cc: Erik Nordmark; rbridge@postel.org; 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:touch@ISI.EDU] --> > >> Sent: Thursday, October 19, 2006 8:58 AM --> > >> To: Silvano Gai --> > >> Cc: Erik Nordmark; rbridge@postel.org; 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JLmVED001517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 19 Oct 2006 14:48:31 -0700 (PDT) Received: from [192.168.200.29] (70-91-142-101-ma-ne.hfc.comcastbusiness.net [70.91.142.101] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JLlaBQ021628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 14:47:37 -0700 (PDT) Message-ID: <4537F277.7040206@isi.edu> Date: Thu, 19 Oct 2006 14:47:35 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3D2D@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3D2D@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79019255DC43C60816DA71F4" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 21:48:53 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN/J3E5f5cImnZrsRAqGKAJ48e6MuXpyEkkNSuee8Vwoj9Pq/ewCgmB2o dqNhGxQnMn/nIW36LHJefns= =E4Xz -----END PGP SIGNATURE----- --------------enig79019255DC43C60816DA71F4-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JLlUrR000986 for <rbridge@postel.org>; Thu, 19 Oct 2006 14:47:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 14:47:29 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3D30@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FTag Thread-Index: Acbzrw/WwVu0QIDcQW+lZ3+Ilq8YeQAGQQlw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JLlUrR000986 Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 21:47:49 -0000 Status: RO Content-Length: 11350 Disagreement noted, waiting for the explanation Cheers -- Silvano > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > Sent: Thursday, October 19, 2006 11:48 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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:sgai@nuovasystems.com] > --> Sent: Wednesday, October 18, 2006 12:04 PM > --> To: Gray, Eric > --> Cc: rbridge@postel.org > --> 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:Eric.Gray@marconi.com] > --> > Sent: Wednesday, October 18, 2006 4:57 AM > --> > To: Silvano Gai > --> > Cc: rbridge@postel.org > --> > 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:sgai@nuovasystems.com] > --> > --> Sent: Wednesday, October 18, 2006 12:05 AM > --> > --> To: Gray, Eric; Caitlin Bestler > --> > --> Cc: rbridge@postel.org > --> > --> 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:Eric.Gray@marconi.com] > --> > --> > Sent: Tuesday, October 17, 2006 9:48 AM > --> > --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler > --> > --> > Cc: rbridge@postel.org > --> > --> > Subject: RE: [rbridge] FTag > --> > ---[SNIP]--- > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JLiD3u000102 for <rbridge@postel.org>; Thu, 19 Oct 2006 14:44:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 14:44:11 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3D2D@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: AcbzrX+hgo3UcD7xTqC8SwvUjAtQZQAEMF8A From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU>, "Dino Farinacci \(dino\)" <dino@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JLiD3u000102 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 21:44:18 -0000 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:touch@ISI.EDU] > Sent: Thursday, October 19, 2006 11:36 AM > To: Silvano Gai > Cc: Erik Nordmark; rbridge@postel.org; 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:touch@ISI.EDU] > >> Sent: Thursday, October 19, 2006 8:58 AM > >> To: Silvano Gai > >> Cc: Erik Nordmark; rbridge@postel.org; 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JJ9g0N010638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 19 Oct 2006 12:09:42 -0700 (PDT) Received: from [75.195.117.117] (117.sub-75-195-117.myvzw.com [75.195.117.117]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JJ9EXv015927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 12:09:16 -0700 (PDT) Message-ID: <4537CD56.3090302@isi.edu> Date: Thu, 19 Oct 2006 12:09:10 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Joe Touch <touch@ISI.EDU> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C6E@nuova-ex1.hq.nuovaimpresa.com> <4537C581.8090200@isi.edu> In-Reply-To: <4537C581.8090200@isi.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF5A2F0FB2A1E6CF43748320E" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 19:10:14 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN81WE5f5cImnZrsRAp1rAJ9n4ssOfVf19oEh5YDUNaaWmcqcLACfdvU6 aI7VjqOCw4xf5jQbHc/bPXc= =jEc0 -----END PGP SIGNATURE----- --------------enigF5A2F0FB2A1E6CF43748320E-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JIlim1003347 for <rbridge@postel.org>; Thu, 19 Oct 2006 11:47:44 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9JIlffK017172; Thu, 19 Oct 2006 14:47:41 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27363; Thu, 19 Oct 2006 14:47:41 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48N4CGLP>; Thu, 19 Oct 2006 14:47:40 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D8125B9FA27@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Thu, 19 Oct 2006 14:47:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 18:48:13 -0000 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:sgai@nuovasystems.com] --> Sent: Wednesday, October 18, 2006 12:04 PM --> To: Gray, Eric --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> > Sent: Wednesday, October 18, 2006 4:57 AM --> > To: Silvano Gai --> > Cc: rbridge@postel.org --> > 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:sgai@nuovasystems.com] --> > --> Sent: Wednesday, October 18, 2006 12:05 AM --> > --> To: Gray, Eric; Caitlin Bestler --> > --> Cc: rbridge@postel.org --> > --> 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:Eric.Gray@marconi.com] --> > --> > Sent: Tuesday, October 17, 2006 9:48 AM --> > --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler --> > --> > Cc: rbridge@postel.org --> > --> > Subject: RE: [rbridge] FTag --> > ---[SNIP]--- --> Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JIaW7L029930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 19 Oct 2006 11:36:32 -0700 (PDT) Received: from [75.195.117.117] (117.sub-75-195-117.myvzw.com [75.195.117.117]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JIZlHD008043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 11:35:51 -0700 (PDT) Message-ID: <4537C581.8090200@isi.edu> Date: Thu, 19 Oct 2006 11:35:45 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C6E@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C6E@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig338A4CA00817C80A74154376" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 18:36:39 -0000 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:touch@ISI.EDU] >> Sent: Thursday, October 19, 2006 8:58 AM >> To: Silvano Gai >> Cc: Erik Nordmark; rbridge@postel.org; 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN8WBE5f5cImnZrsRAlQcAJ9PyPRKRxLhGikAZz2LVhg85k2atgCg6ziB lcMfcPmKpGAsf7XsaCcKBQE= =fpir -----END PGP SIGNATURE----- --------------enig338A4CA00817C80A74154376-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JI5OWp020455 for <rbridge@postel.org>; Thu, 19 Oct 2006 11:05:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 11:05:22 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C6E@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acbzl3GWj3QPwKrNSHCLaUbSZ4ulCgAEEYsg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JI5OWp020455 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 18:05:38 -0000 Status: RO Content-Length: 2048 Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Thursday, October 19, 2006 8:58 AM > To: Silvano Gai > Cc: Erik Nordmark; rbridge@postel.org; 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JHxuVj018568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 10:59:56 -0700 (PDT) Received: from [75.194.186.108] (108.sub-75-194-186.myvzw.com [75.194.186.108]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JHxd1J029681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 10:59:42 -0700 (PDT) Message-ID: <4537BD01.6060603@isi.edu> Date: Thu, 19 Oct 2006 10:59:29 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C50@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C50@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A290B9A7F89EF1CA45035BD" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, rbridge-bounces@postel.org Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 18:00:27 -0000 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:touch@ISI.EDU] >> Sent: Thursday, October 19, 2006 10:08 AM >> To: Silvano Gai >> Cc: Caitlin Bestler; Erik Nordmark; Ed Bowen; rbridge@postel.org; > rbridge- >> bounces@postel.org; 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN70BE5f5cImnZrsRAtHCAKCCDkMaeKZhtnzwAoyYk6qgv3S8KwCfSEHW yfZBHXRRVDCtrVbpAdMTpxs= =LLOQ -----END PGP SIGNATURE----- --------------enig0A290B9A7F89EF1CA45035BD-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JHoNWk015431; Thu, 19 Oct 2006 10:50:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 10:50:22 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3C50@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbzoTj7onIGoOCyTy2BE1a+K0iH2QABX2Dg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JHoNWk015431 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, rbridge-bounces@postel.org Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 17:50:54 -0000 Status: RO Content-Length: 970 Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Thursday, October 19, 2006 10:08 AM > To: Silvano Gai > Cc: Caitlin Bestler; Erik Nordmark; Ed Bowen; rbridge@postel.org; rbridge- > bounces@postel.org; 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JHUkln008566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 19 Oct 2006 10:30:46 -0700 (PDT) Received: from [75.192.161.136] (136.sub-75-192-161.myvzw.com [75.192.161.136]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JHTtXO022922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 10:29:57 -0700 (PDT) Message-ID: <4537B612.1080907@isi.edu> Date: Thu, 19 Oct 2006 10:29:54 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dinesh G Dutt <ddutt@cisco.com> References: <453661A7.9070509@cisco.com> In-Reply-To: <453661A7.9070509@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC7C914195DFE2269FD8F43B" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 17:31:48 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN7YSE5f5cImnZrsRAn5vAJ9+QZdDtb3B7gNrbWb2brZSByVp4gCg/ejz if4MqBbemc0jhZnO6xbDUZM= =H4d8 -----END PGP SIGNATURE----- --------------enigBC7C914195DFE2269FD8F43B-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JH8doL001416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 10:08:39 -0700 (PDT) Received: from [75.192.161.136] (136.sub-75-192-161.myvzw.com [75.192.161.136]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JH7j7n017352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 10:07:48 -0700 (PDT) Message-ID: <4537B0DF.1060904@isi.edu> Date: Thu, 19 Oct 2006 10:07:43 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB3@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB3@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9FA2946284845252E88CEF0" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, rbridge-bounces@postel.org Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 17:09:42 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN7DfE5f5cImnZrsRAlt1AJ98XeJXcNy3pwJ4JMDUx4qrKYRmPQCgrsvd c43Rkv/ME3dY6x22f9wal8M= =zTof -----END PGP SIGNATURE----- --------------enigC9FA2946284845252E88CEF0-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JFwdxg007175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 19 Oct 2006 08:58:39 -0700 (PDT) Received: from [75.195.147.60] (60.sub-75-195-147.myvzw.com [75.195.147.60]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9JFw5Kw029166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 08:58:11 -0700 (PDT) Message-ID: <4537A087.7090305@isi.edu> Date: Thu, 19 Oct 2006 08:57:59 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB9@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB9@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7912E879BE7375F900A636F3" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 15:59:04 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFN6CLE5f5cImnZrsRAsqaAJwO+kW8RGNSj9d1K7A+kPAkBpaSkQCgiiQu CYVc7rc3/UJKz6YDR4zNsyM= =AHUv -----END PGP SIGNATURE----- --------------enig7912E879BE7375F900A636F3-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JFM7vR024923 for <rbridge@postel.org>; Thu, 19 Oct 2006 08:22:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 08:22:06 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB9@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acby1QLlhLrkSfbZQKKvZ73mrXvf8gAu6AKQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Erik Nordmark" <erik.nordmark@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JFM7vR024923 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 15:22:55 -0000 Status: RO Content-Length: 3372 Erik, > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Wednesday, October 18, 2006 9:47 AM > To: Silvano Gai > Cc: Gray, Eric; Radia Perlman; Caitlin Bestler; rbridge@postel.org > 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JF7rGx019963 for <rbridge@postel.org>; Thu, 19 Oct 2006 08:07:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 08:07:51 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB4@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] LIDs Thread-Index: Acby5IUk5GeHDeC2T9SZwj07dnqdyQAq5INw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JF7rGx019963 Cc: rbridge@postel.org Subject: Re: [rbridge] LIDs X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 15:08:14 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Wednesday, October 18, 2006 11:06 AM > To: Radia Perlman > Cc: rbridge@postel.org > 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9JF4XW7018845; Thu, 19 Oct 2006 08:04:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Oct 2006 08:04:31 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3BB3@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acby23jlZvDmtawDSbaSXgavG1EstAAANklgAAEMxQAAAFvgYAArIx0Q From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Erik Nordmark" <erik.nordmark@sun.com>, "Ed Bowen" <edbowen@us.ibm.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9JF4XW7018845 Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 19 Oct 2006 15:05:34 -0000 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 Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IKJnsZ015023 for <rbridge@postel.org>; Wed, 18 Oct 2006 13:19:49 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 18 Oct 2006 13:19:41 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id AFC582B2; Wed, 18 Oct 2006 13:19:41 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7E1D92B1; Wed, 18 Oct 2006 13:19:41 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIB76709; Wed, 18 Oct 2006 13:19:18 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 7A2B120501; Wed, 18 Oct 2006 13:19:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 13:19:17 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFFB3@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <45366D10.7060105@sun.com> Thread-Topic: LIDs Thread-Index: Acby4lFXsEqxu94iRvehpH6TvWktDQAD3QvA From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Radia Perlman" <Radia.Perlman@sun.com> X-WSS-ID: 692853D73AK2782033-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IKJnsZ015023 Cc: rbridge@postel.org Subject: Re: [rbridge] LIDs X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 20:19:54 -0000 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. Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IIPIFR004199; Wed, 18 Oct 2006 11:25:18 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 18 Oct 2006 11:25:12 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C64E42B0; Wed, 18 Oct 2006 11:25:11 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 979312AE; Wed, 18 Oct 2006 11:25:11 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIB42603; Wed, 18 Oct 2006 11:24:32 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id A7F7E20501; Wed, 18 Oct 2006 11:24:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 11:24:33 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFF9A@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE3A01@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acby23jlZvDmtawDSbaSXgavG1EstAAANklgAAEMxQAAAFvgYA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Erik Nordmark" <erik.nordmark@sun.com>, "Ed Bowen" <edbowen@us.ibm.com> X-WSS-ID: 6928AE023AK2749897-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IIPIFR004199 Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 18:26:24 -0000 Status: RO Content-Length: 2502 Silvano Gai wrote: > Catlin, > >> -----Original Message----- >> From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] >> On Behalf Of Caitlin Bestler Sent: Wednesday, October 18, 2006 10:41 >> AM >> To: Erik Nordmark; Ed Bowen >> Cc: rbridge@postel.org; rbridge-bounces@postel.org; Radia Perlman; >> Joe Touch Subject: Re: [rbridge] TTL only - was RE: New fields in >> shim header? >> >> rbridge-bounces@postel.org 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. Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IILrXB002870 for <rbridge@postel.org>; Wed, 18 Oct 2006 11:21:53 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.106.31]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IILq72013220; Wed, 18 Oct 2006 11:21:53 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9IILess380998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 11:21:41 -0700 (PDT) Message-ID: <45366D10.7060105@sun.com> Date: Wed, 18 Oct 2006 11:06:08 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFCE0@NT-SJCA-0751.brcm.ad.broadcom.com> <4533CAF6.1010302@sun.com> In-Reply-To: <4533CAF6.1010302@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org Subject: [rbridge] LIDs X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 18:22:24 -0000 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IIIDqi002041; Wed, 18 Oct 2006 11:18:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 2006 11:18:12 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3A01@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acby23jlZvDmtawDSbaSXgavG1EstAAANklgAAEMxQA= From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Erik Nordmark" <erik.nordmark@sun.com>, "Ed Bowen" <edbowen@us.ibm.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IIIDqi002041 Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 18:18:49 -0000 Status: RO Content-Length: 1775 Catlin, > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Caitlin Bestler > Sent: Wednesday, October 18, 2006 10:41 AM > To: Erik Nordmark; Ed Bowen > Cc: rbridge@postel.org; rbridge-bounces@postel.org; Radia Perlman; Joe > Touch > Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? > > rbridge-bounces@postel.org 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 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IIBxqU029642 for <rbridge@postel.org>; Wed, 18 Oct 2006 11:11:59 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Oct 2006 11:11:59 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IIBxCS024518; Wed, 18 Oct 2006 11:11:59 -0700 Received: from [171.71.47.109] (dhcp-171-71-47-109.cisco.com [171.71.47.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9IIBxAo006119; Wed, 18 Oct 2006 11:11:59 -0700 (PDT) Message-ID: <45366EF7.9090109@cisco.com> Date: Wed, 18 Oct 2006 11:14:15 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFF86@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1AFFF86@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1586; t=1161195119; x=1162059119; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3D3jjxpAx9673MJB0jP307edyAkIQ=3D; b=mgvjgYUkGJ5A+aXBX30XNRAa0UbDwg04zgq89i4V4tYVFIsw4RGVWtrKXHt9jctJc/xL/u+E +aMTUOUGvBQCXrxhES7Zu8UL6RqEoCq1nlQNd1I8PugI2DXA57Mgp/aK; Authentication-Results: sj-dkim-1.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 18:12:23 -0000 Status: RO Content-Length: 1548 Caitlin Bestler wrote: > ddutt@cisco.com 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9II42KC026937; Wed, 18 Oct 2006 11:04:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 2006 11:04:00 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE39F3@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acby3apshOIr4TXySDCTONKiXovbcAAAGA8g From: "Silvano Gai" <sgai@nuovasystems.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Ed Bowen" <edbowen@us.ibm.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9II42KC026937 Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 18:05:02 -0000 Status: RO Content-Length: 2132 > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Erik Nordmark > Sent: Wednesday, October 18, 2006 10:22 AM > To: Ed Bowen > Cc: rbridge@postel.org; rbridge-bounces@postel.org; 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 Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IHfh99019175; Wed, 18 Oct 2006 10:41:43 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 18 Oct 2006 10:41:30 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EA9012B0; Wed, 18 Oct 2006 10:41:29 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B48752AE; Wed, 18 Oct 2006 10:41:29 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIB27472; Wed, 18 Oct 2006 10:41:29 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D35CB20504; Wed, 18 Oct 2006 10:41:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 10:41:27 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFF8A@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <453662C2.9030005@sun.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acby23jlZvDmtawDSbaSXgavG1EstAAANklg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Erik Nordmark" <erik.nordmark@sun.com>, "Ed Bowen" <edbowen@us.ibm.com> X-WSS-ID: 6928B8C03AK2735246-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IHfh99019175 Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 17:42:10 -0000 Status: RO Content-Length: 1159 rbridge-bounces@postel.org 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. Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IHcq5l018195 for <rbridge@postel.org>; Wed, 18 Oct 2006 10:38:52 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 18 Oct 2006 10:38:42 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id F1F1F2AF; Wed, 18 Oct 2006 10:38:41 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CBF992AE; Wed, 18 Oct 2006 10:38:41 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIB26723; Wed, 18 Oct 2006 10:38:41 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 4656F20502; Wed, 18 Oct 2006 10:38:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 10:38:39 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFF86@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <453661A7.9070509@cisco.com> Thread-Topic: [rbridge] Ingress Rbridge and FTAG again Thread-Index: Acby2ZkdfoOUf+ndSxS547+q/VK25wAAMeSA From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Dinesh G Dutt" <ddutt@cisco.com>, rbridge@postel.org X-WSS-ID: 6928B92809W6045748-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IHcq5l018195 Subject: Re: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 17:39:34 -0000 Status: RO Content-Length: 1261 ddutt@cisco.com 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. Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IHMCBw012693; Wed, 18 Oct 2006 10:22:13 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IHMBZb004807; Wed, 18 Oct 2006 11:22:11 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9IHMA17366789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 10:22:11 -0700 (PDT) Message-ID: <453662C2.9030005@sun.com> Date: Wed, 18 Oct 2006 10:22:10 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Ed Bowen <edbowen@us.ibm.com> References: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> In-Reply-To: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 17:22:33 -0000 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 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IHFBUT010444 for <rbridge@postel.org>; Wed, 18 Oct 2006 10:15:11 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2006 10:15:11 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IHFBEv020484 for <rbridge@postel.org>; Wed, 18 Oct 2006 10:15:11 -0700 Received: from [171.71.49.211] (dhcp-171-71-49-211.cisco.com [171.71.49.211]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9IHFBbF001836 for <rbridge@postel.org>; Wed, 18 Oct 2006 10:15:11 -0700 (PDT) Message-ID: <453661A7.9070509@cisco.com> Date: Wed, 18 Oct 2006 10:17:27 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: rbridge@postel.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3726; t=1161191711; x=1162055711; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Ingress=20Rbridge=20and=20FTAG=20again; X=v=3Dcisco.com=3B=20h=3DlCYeetplbsWAl+JCzjSH1p1jrPo=3D; b=HTMCyZuExzX12BGOhQrG+nWH3A7iYMyQ2OuaIsZeMbnU7vt8xh4NfdeqqgRSSDNtt3047D2i 4zqT4WKYxjm6cZ2ZKroHNruEH/x8RGHe7fchhu9pklUPhIos3gAM0Zn/; Authentication-Results: sj-dkim-8.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Subject: [rbridge] Ingress Rbridge and FTAG again X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 17:15:33 -0000 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 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IGxFCA004673 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:59:15 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IGxEZ3004317; Wed, 18 Oct 2006 09:59:15 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9IGx3vX359934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 09:59:04 -0700 (PDT) Message-ID: <45365D56.10706@sun.com> Date: Wed, 18 Oct 2006 09:59:02 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Dinesh G Dutt <ddutt@cisco.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFB60@NT-SJCA-0751.brcm.ad.broadcom.com> <452FE709.7090900@sun.com> <452FFCDA.6070203@cisco.com> In-Reply-To: <452FFCDA.6070203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 16:59:17 -0000 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 Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IGkpe2000036 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:46:51 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9IGkhdS005451; Wed, 18 Oct 2006 09:46:43 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9IGkfLr355637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 09:46:42 -0700 (PDT) Message-ID: <45365A71.40107@sun.com> Date: Wed, 18 Oct 2006 09:46:41 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF7CA@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF7CA@nuova-ex1.hq.nuovaimpresa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 16:47:24 -0000 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 Received: from mail125.messagelabs.com (mail125.messagelabs.com [85.158.136.35]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9IGCUVJ018796 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:12:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-8.tower-125.messagelabs.com!1161187841!18369935!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 18033 invoked from network); 18 Oct 2006 16:10:42 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-8.tower-125.messagelabs.com with SMTP; 18 Oct 2006 16:10:42 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id k9IGELGt011656 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:14:31 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k9IGATvm025755 for <rbridge@postel.org>; Wed, 18 Oct 2006 11:10:29 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 2006 12:10:26 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790018A037B@de01exm64.ds.mot.com> In-Reply-To: <44F468FA.5030507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] draft-ietf-trill-prob-00.txt thread-index: AcbLhvcStnqYb1BFSCOY9s+GccfOMAnSMrtw From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IGCUVJ018796 Subject: Re: [rbridge] draft-ietf-trill-prob-00.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 16:12:52 -0000 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:riw@cisco.com] Sent: Tuesday, August 29, 2006 12:19 PM To: Eastlake III Donald-LDE008 Cc: rbridge@postel.org Subject: Re: [rbridge] draft-ietf-trill-prob-00.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9Gj6ER27sUhU9OQRArymAJsEjcDZh5zxd1Nbeqje35rChMIsawCg1zcD 70TUVNCfjUbFZQdOZ2jY/10= =psXn -----END PGP SIGNATURE----- Received: from mail125.messagelabs.com (mail125.messagelabs.com [85.158.136.35]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9IGCT4X018794 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:12:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-6.tower-125.messagelabs.com!1161187820!18262333!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26240 invoked from network); 18 Oct 2006 16:10:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-125.messagelabs.com with SMTP; 18 Oct 2006 16:10:20 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9IGAJhE029370 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:10:19 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k9IGAIVf012296 for <rbridge@postel.org>; Wed, 18 Oct 2006 11:10:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 2006 12:10:17 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790018A037A@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-trill-prob-00.txt comment thread-index: Acbyz+dBHJhZMybPS+CCB3HQ1cnjlw== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IGCT4X018794 Subject: [rbridge] draft-ietf-trill-prob-00.txt comment X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 16:12:52 -0000 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IG43KN016648 for <rbridge@postel.org>; Wed, 18 Oct 2006 09:04:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Oct 2006 09:04:01 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE3943@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FTag Thread-Index: AcbyrJQbl3gZ2zr3QyCjBRaslVjWKgAGmSQQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9IG43KN016648 Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 16:04:29 -0000 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:Eric.Gray@marconi.com] > Sent: Wednesday, October 18, 2006 4:57 AM > To: Silvano Gai > Cc: rbridge@postel.org > 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:sgai@nuovasystems.com] > --> Sent: Wednesday, October 18, 2006 12:05 AM > --> To: Gray, Eric; Caitlin Bestler > --> Cc: rbridge@postel.org > --> 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:Eric.Gray@marconi.com] > --> > Sent: Tuesday, October 17, 2006 9:48 AM > --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler > --> > Cc: rbridge@postel.org > --> > Subject: RE: [rbridge] FTag > ---[SNIP]--- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9IBvQ4j029025 for <rbridge@postel.org>; Wed, 18 Oct 2006 04:57:26 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9IBvOfK019847; Wed, 18 Oct 2006 07:57:24 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA17152; Wed, 18 Oct 2006 07:57:23 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT0G79>; Wed, 18 Oct 2006 07:57:22 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0D3A@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Wed, 18 Oct 2006 07:57:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 11:57:38 -0000 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:sgai@nuovasystems.com] --> Sent: Wednesday, October 18, 2006 12:05 AM --> To: Gray, Eric; Caitlin Bestler --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> > Sent: Tuesday, October 17, 2006 9:48 AM --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler --> > Cc: rbridge@postel.org --> > Subject: RE: [rbridge] FTag ---[SNIP]--- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9I45L2v020280 for <rbridge@postel.org>; Tue, 17 Oct 2006 21:05:21 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Oct 2006 21:05:19 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE38ED@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FTag Thread-Index: AcbyDAuNitrTTuQVRwKzwicHqYd3SAASwbcw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9I45L2v020280 Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2006 04:06:51 -0000 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:Eric.Gray@marconi.com] > Sent: Tuesday, October 17, 2006 9:48 AM > To: Silvano Gai; Gray, Eric; Caitlin Bestler > Cc: rbridge@postel.org > 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:sgai@nuovasystems.com] > --> Sent: Tuesday, October 17, 2006 12:34 PM > --> To: Gray, Eric; Caitlin Bestler > --> Cc: rbridge@postel.org > --> Subject: RE: [rbridge] FTag > --> > --> > --> Eric, > --> > --> Do you include in your computation the 16 bits of Ethertype = TRILL? > --> > --> -- Silvano > --> > --> > --> > -----Original Message----- > --> > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > --> > Sent: Monday, October 16, 2006 4:06 PM > --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler > --> > Cc: rbridge@postel.org > --> > 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:sgai@nuovasystems.com] > --> > --> Sent: Monday, October 16, 2006 6:21 PM > --> > --> To: Gray, Eric; Caitlin Bestler > --> > --> Cc: rbridge@postel.org > --> > --> 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:Eric.Gray@marconi.com] > --> > --> > Sent: Monday, October 16, 2006 9:29 AM > --> > --> > To: Gray, Eric; 'Caitlin Bestler' > --> > --> > Cc: 'rbridge@postel.org'; 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: rbridge@postel.org; 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: rbridge-bounces@postel.org > --> > --> > --> --> [mailto:rbridge-bounces@postel.org] On > --> Behalf Of Caitlin > --> > --> Bestler > --> > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM > --> > --> > --> --> To: Silvano Gai; rbridge@postel.org > --> > --> > --> --> Subject: Re: [rbridge] FTag > --> > --> > --> --> > --> > --> > --> --> rbridge-bounces@postel.org 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 > --> > --> > --> --> rbridge@postel.org > --> > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge > --> > --> > --> --> > --> > --> > --> > --> > --> > --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9HGmHJt025232 for <rbridge@postel.org>; Tue, 17 Oct 2006 09:48:18 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9HGmEfK008150; Tue, 17 Oct 2006 12:48:14 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14799; Tue, 17 Oct 2006 12:48:13 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT8XT0>; Tue, 17 Oct 2006 12:48:13 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0C56@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, "Gray, Eric" <Eric.Gray@marconi.com>, Caitlin Bestler <caitlinb@broadcom.com> Date: Tue, 17 Oct 2006 12:48:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 16:48:51 -0000 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:sgai@nuovasystems.com] --> Sent: Tuesday, October 17, 2006 12:34 PM --> To: Gray, Eric; Caitlin Bestler --> Cc: rbridge@postel.org --> Subject: RE: [rbridge] FTag --> --> --> Eric, --> --> Do you include in your computation the 16 bits of Ethertype = TRILL? --> --> -- Silvano --> --> --> > -----Original Message----- --> > From: Gray, Eric [mailto:Eric.Gray@marconi.com] --> > Sent: Monday, October 16, 2006 4:06 PM --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler --> > Cc: rbridge@postel.org --> > 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:sgai@nuovasystems.com] --> > --> Sent: Monday, October 16, 2006 6:21 PM --> > --> To: Gray, Eric; Caitlin Bestler --> > --> Cc: rbridge@postel.org --> > --> 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:Eric.Gray@marconi.com] --> > --> > Sent: Monday, October 16, 2006 9:29 AM --> > --> > To: Gray, Eric; 'Caitlin Bestler' --> > --> > Cc: 'rbridge@postel.org'; 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: rbridge@postel.org; 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: rbridge-bounces@postel.org --> > --> > --> --> [mailto:rbridge-bounces@postel.org] On --> Behalf Of Caitlin --> > --> Bestler --> > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM --> > --> > --> --> To: Silvano Gai; rbridge@postel.org --> > --> > --> --> Subject: Re: [rbridge] FTag --> > --> > --> --> --> > --> > --> --> rbridge-bounces@postel.org 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 --> > --> > --> --> rbridge@postel.org --> > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> > --> > --> --> --> > --> > --> --> > --> --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9HGY5cR020552 for <rbridge@postel.org>; Tue, 17 Oct 2006 09:34:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Oct 2006 09:34:04 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE371B@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FTag Thread-Index: Acbxd5xNIKT2GMS/QjmZZ8ASo0oqkAAkVjiQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9HGY5cR020552 Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 16:34:29 -0000 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:Eric.Gray@marconi.com] > Sent: Monday, October 16, 2006 4:06 PM > To: Silvano Gai; Gray, Eric; Caitlin Bestler > Cc: rbridge@postel.org > 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:sgai@nuovasystems.com] > --> Sent: Monday, October 16, 2006 6:21 PM > --> To: Gray, Eric; Caitlin Bestler > --> Cc: rbridge@postel.org > --> 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:Eric.Gray@marconi.com] > --> > Sent: Monday, October 16, 2006 9:29 AM > --> > To: Gray, Eric; 'Caitlin Bestler' > --> > Cc: 'rbridge@postel.org'; 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: rbridge@postel.org; 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: rbridge-bounces@postel.org > --> > --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin > --> Bestler > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM > --> > --> --> To: Silvano Gai; rbridge@postel.org > --> > --> --> Subject: Re: [rbridge] FTag > --> > --> --> > --> > --> --> rbridge-bounces@postel.org 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 > --> > --> --> rbridge@postel.org > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge > --> > --> --> > --> > --> > --> Received: from smtpauth.wiscmail.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9HGFiSB014840 for <rbridge@postel.org>; Tue, 17 Oct 2006 09:15:44 -0700 (PDT) Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7A00D05FU4P100@smtpauth1.wiscmail.wisc.edu> for rbridge@postel.org; Tue, 17 Oct 2006 11:15:40 -0500 (CDT) Received: from [144.92.67.116] (schabzeiger.doit.wisc.edu [144.92.67.116]) by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7A00ILJFU1SUA0@smtpauth1.wiscmail.wisc.edu>; Tue, 17 Oct 2006 11:15:37 -0500 (CDT) Date: Tue, 17 Oct 2006 11:15:43 -0500 From: "Dale W. Carder" <dwcarder@doit.wisc.edu> In-reply-to: <0BF76B30C100624BA997C9CED19D81259D09EF@uspitsmsgusr08.win.marconi.com> To: "Gray, Eric" <Eric.Gray@marconi.com> Message-id: <8DB4390A-511F-4805-86A4-C45FE3459975@doit.wisc.edu> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Report: AuthenticatedSender=yes, SenderIP=144.92.67.116 X-Spam-PmxInfo: Server=avs-7, Version=5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.10.17.83942, SenderIP=144.92.67.116 References: <0BF76B30C100624BA997C9CED19D81259D09EF@uspitsmsgusr08.win.marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dwcarder@doit.wisc.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 16:16:17 -0000 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9HEc7HZ013446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Tue, 17 Oct 2006 07:38:07 -0700 (PDT) Received: from [75.192.25.211] (211.sub-75-192-25.myvzw.com [75.192.25.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9HEZXt6018375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2006 07:35:37 -0700 (PDT) Message-ID: <4534E893.90604@isi.edu> Date: Tue, 17 Oct 2006 07:28:35 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE36A0@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE36A0@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEEA5778F4FE9BBD778A52113" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 14:38:28 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNOiTE5f5cImnZrsRAtiWAJ9qCWHl2brqHJnC8XWMqA+Kl1+2vwCgiSuN ixNRWJ/LGXZI4BnVHEWqnRc= =i04j -----END PGP SIGNATURE----- --------------enigEEA5778F4FE9BBD778A52113-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9HDpx0k027934 for <rbridge@postel.org>; Tue, 17 Oct 2006 06:51:59 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9HDpmfK029870; Tue, 17 Oct 2006 09:51:48 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12761; Tue, 17 Oct 2006 09:51:45 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT8NJR>; Tue, 17 Oct 2006 09:51:45 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0BF3@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com> Date: Tue, 17 Oct 2006 09:51:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com>, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 13:52:18 -0000 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:sgai@nuovasystems.com] --> Sent: Tuesday, October 17, 2006 12:35 AM --> To: Joe Touch --> Cc: Caitlin Bestler; Gray, Eric; rbridge@postel.org; Radia Perlman --> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header? --> --> Joe, --> --> > -----Original Message----- --> > From: Joe Touch [mailto:touch@ISI.EDU] --> > Sent: Monday, October 16, 2006 4:49 PM --> > To: Silvano Gai --> > Cc: Caitlin Bestler; Gray, Eric; rbridge@postel.org; 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 --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9H4ZLo2026452 for <rbridge@postel.org>; Mon, 16 Oct 2006 21:35:21 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 2006 21:35:17 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE36A0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbxfcAPFiyjBgcrSkSzEO4WHKiAowAJ5LSQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9H4ZLo2026452 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 04:35:26 -0000 Status: RO Content-Length: 1170 Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Monday, October 16, 2006 4:49 PM > To: Silvano Gai > Cc: Caitlin Bestler; Gray, Eric; rbridge@postel.org; 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9H36vsX004873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 20:06:57 -0700 (PDT) Received: from [75.194.68.240] (240.sub-75-194-68.myvzw.com [75.194.68.240]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9H2wBZ8028901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 19:58:13 -0700 (PDT) Message-ID: <453446BF.4040405@isi.edu> Date: Mon, 16 Oct 2006 19:58:07 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE35F8@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE35F8@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0EC9B163FC554B179B8CAE14" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 03:07:30 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNEa/E5f5cImnZrsRAjhQAJ94gljn+bEkfbjT+avKIac+NRS2TwCgjuN4 7YhBfYO6Wp4PTwEw7pBGaQk= =4h1q -----END PGP SIGNATURE----- --------------enig0EC9B163FC554B179B8CAE14-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9H36PjO004783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 20:06:25 -0700 (PDT) Received: from [75.194.68.240] (240.sub-75-194-68.myvzw.com [75.194.68.240]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9H2wFXd028917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 19:58:17 -0700 (PDT) Message-ID: <453446C4.30708@isi.edu> Date: Mon, 16 Oct 2006 19:58:12 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Gray, Eric" <Eric.Gray@marconi.com> References: <0BF76B30C100624BA997C9CED19D81259D0B9D@uspitsmsgusr08.pit.comms.marconi.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D81259D0B9D@uspitsmsgusr08.pit.comms.marconi.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5104F2C66081C0D316077804" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 03:06:56 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNEbEE5f5cImnZrsRAkqxAKDvaJTX4U8p066+LVWoJqnOkQYP1gCghwtL kiqy6Mepl0lHKlPH3dXJ7mw= =e8Oo -----END PGP SIGNATURE----- --------------enig5104F2C66081C0D316077804-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9H2mXkg029696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 19:48:33 -0700 (PDT) Received: from [75.194.68.240] (240.sub-75-194-68.myvzw.com [75.194.68.240]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9H2fCh8026120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 19:41:15 -0700 (PDT) Message-ID: <4534429F.5090502@isi.edu> Date: Mon, 16 Oct 2006 19:40:31 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Gray, Eric" <Eric.Gray@marconi.com> References: <0BF76B30C100624BA997C9CED19D81259D0B40@uspitsmsgusr08.pit.comms.marconi.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D81259D0B40@uspitsmsgusr08.pit.comms.marconi.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6A88F8FAEE58BE5039CC9E3B" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 17 Oct 2006 02:49:01 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNEKfE5f5cImnZrsRAnubAJ4/ogjcUBm3GsapH9I2cyB9PmkoFACfchvV X65AvT2HYGbQekMNeFPpLmM= =z0eK -----END PGP SIGNATURE----- --------------enig6A88F8FAEE58BE5039CC9E3B-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GNngN1013026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 16:49:42 -0700 (PDT) Received: from [75.194.68.240] (240.sub-75-194-68.myvzw.com [75.194.68.240]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9GNn3VU022932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 16:49:06 -0700 (PDT) Message-ID: <45341A6C.1010103@isi.edu> Date: Mon, 16 Oct 2006 16:49:00 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA2AE35E9@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE35E9@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig48CE6D299FEBEE6008C84F96" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 23:49:48 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNBpsE5f5cImnZrsRAs3kAKCN/Lm8fNox6ayhf34/jPVex6jQSwCdEVbf m43SoSdb5qyTmmzPViMNQV8= =xcTj -----END PGP SIGNATURE----- --------------enig48CE6D299FEBEE6008C84F96-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GN5j4K001257 for <rbridge@postel.org>; Mon, 16 Oct 2006 16:05:45 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9GN5hfK028352; Mon, 16 Oct 2006 19:05:43 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA15839; Mon, 16 Oct 2006 19:05:43 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT7G0P>; Mon, 16 Oct 2006 19:05:42 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0B9E@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, "Gray, Eric" <Eric.Gray@marconi.com>, Caitlin Bestler <caitlinb@broadcom.com> Date: Mon, 16 Oct 2006 19:05:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 23:06:22 -0000 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:sgai@nuovasystems.com] --> Sent: Monday, October 16, 2006 6:21 PM --> To: Gray, Eric; Caitlin Bestler --> Cc: rbridge@postel.org --> 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:Eric.Gray@marconi.com] --> > Sent: Monday, October 16, 2006 9:29 AM --> > To: Gray, Eric; 'Caitlin Bestler' --> > Cc: 'rbridge@postel.org'; 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: rbridge@postel.org; 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: rbridge-bounces@postel.org --> > --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin --> Bestler --> > --> --> Sent: Monday, October 16, 2006 12:09 PM --> > --> --> To: Silvano Gai; rbridge@postel.org --> > --> --> Subject: Re: [rbridge] FTag --> > --> --> --> > --> --> rbridge-bounces@postel.org 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 --> > --> --> rbridge@postel.org --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> > --> --> --> > --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GMx79d029244 for <rbridge@postel.org>; Mon, 16 Oct 2006 15:59:08 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9GMx2fK028154; Mon, 16 Oct 2006 18:59:03 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA14996; Mon, 16 Oct 2006 18:59:02 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT7GXP>; Mon, 16 Oct 2006 18:59:00 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0B9D@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, "Gray, Eric" <Eric.Gray@marconi.com>, Joe Touch <touch@ISI.EDU>, Caitlin Bestler <caitlinb@broadcom.com> Date: Mon, 16 Oct 2006 18:58:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 22:59:33 -0000 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:sgai@nuovasystems.com] --> Sent: Monday, October 16, 2006 5:31 PM --> To: Gray, Eric; Joe Touch; Caitlin Bestler --> Cc: rbridge@postel.org; 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:Eric.Gray@marconi.com] --> > Sent: Monday, October 16, 2006 10:49 AM --> > To: Joe Touch; Caitlin Bestler --> > Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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:touch@ISI.EDU] --> > --> Sent: Monday, October 16, 2006 12:49 PM --> > --> To: Caitlin Bestler --> > --> Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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 --> > --> --> > --> --> Received: from stag.seas.upenn.edu (stag.SEAS.UPENN.EDU [158.130.70.79]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GMalqH023069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 15:36:48 -0700 (PDT) Received: from Abacas (MOR306-14.seas.upenn.edu [158.130.70.168]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.6/8.13.6) with ESMTP id k9GMZTNd026999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Oct 2006 18:35:29 -0400 From: "Saikat Ray" <saikat@seas.upenn.edu> To: "'Silvano Gai'" <sgai@nuovasystems.com>, "'Gray, Eric'" <Eric.Gray@marconi.com>, "'Joe Touch'" <touch@ISI.EDU>, "'Caitlin Bestler'" <caitlinb@broadcom.com> Date: Mon, 16 Oct 2006 18:35:36 -0400 Organization: University of Pennsylvania Message-ID: <001f01c6f173$69205ee0$a846829e@Abacas> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2AE361F@nuova-ex1.hq.nuovaimpresa.com> Thread-Index: AcbxS2kY8zMIwXAZTSqgnSWIxXcERwAJjYFQAABRmnA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: saikat@seas.upenn.edu Cc: rbridge@postel.org, 'Radia Perlman' <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: saikat@seas.upenn.edu List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 22:37:16 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Silvano Gai > Sent: Monday, October 16, 2006 6:24 PM > To: Gray, Eric; Joe Touch; Caitlin Bestler > Cc: rbridge@postel.org; Radia Perlman > Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? > > > Joe/Radia, > > inline > > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > > Sent: Monday, October 16, 2006 10:49 AM > > To: Joe Touch; Caitlin Bestler > > Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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:touch@ISI.EDU] > > --> Sent: Monday, October 16, 2006 12:49 PM > > --> To: Caitlin Bestler > > --> Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GMO4Q2020111 for <rbridge@postel.org>; Mon, 16 Oct 2006 15:24:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 2006 15:23:59 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE361F@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbxS2kY8zMIwXAZTSqgnSWIxXcERwAJjYFQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Joe Touch" <touch@ISI.EDU>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9GMO4Q2020111 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 22:24:21 -0000 Status: RO Content-Length: 5399 Joe/Radia, inline > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > Sent: Monday, October 16, 2006 10:49 AM > To: Joe Touch; Caitlin Bestler > Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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:touch@ISI.EDU] > --> Sent: Monday, October 16, 2006 12:49 PM > --> To: Caitlin Bestler > --> Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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 > --> > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GMKfSA018958 for <rbridge@postel.org>; Mon, 16 Oct 2006 15:20:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 2006 15:20:37 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE361B@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] FTag Thread-Index: AcbxQCJZBdu5J8TeTEuic0f8p18ABAAMIhBg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9GMKfSA018958 Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 22:21:22 -0000 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:Eric.Gray@marconi.com] > Sent: Monday, October 16, 2006 9:29 AM > To: Gray, Eric; 'Caitlin Bestler' > Cc: 'rbridge@postel.org'; 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: rbridge@postel.org; 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: rbridge-bounces@postel.org > --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler > --> --> Sent: Monday, October 16, 2006 12:09 PM > --> --> To: Silvano Gai; rbridge@postel.org > --> --> Subject: Re: [rbridge] FTag > --> --> > --> --> rbridge-bounces@postel.org 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 > --> --> rbridge@postel.org > --> --> http://mailman.postel.org/mailman/listinfo/rbridge > --> --> > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GLV1eC026052 for <rbridge@postel.org>; Mon, 16 Oct 2006 14:31:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 2006 14:30:57 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE35F8@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbxS2kY8zMIwXAZTSqgnSWIxXcERwAHh8dA From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Joe Touch" <touch@ISI.EDU>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9GLV1eC026052 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 21:31:20 -0000 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:Eric.Gray@marconi.com] > Sent: Monday, October 16, 2006 10:49 AM > To: Joe Touch; Caitlin Bestler > Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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:touch@ISI.EDU] > --> Sent: Monday, October 16, 2006 12:49 PM > --> To: Caitlin Bestler > --> Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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 > --> > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GLKtht020792 for <rbridge@postel.org>; Mon, 16 Oct 2006 14:20:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Oct 2006 14:20:49 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2AE35E9@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbxQ3wK5qyGZjWiR5yTrYmX7zoo1QAJPYtg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9GLKtht020792 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 21:21:13 -0000 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GIYo8d009005 for <rbridge@postel.org>; Mon, 16 Oct 2006 11:34:51 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9GIYmfK015363; Mon, 16 Oct 2006 14:34:48 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24475; Mon, 16 Oct 2006 14:34:47 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT6WD6>; Mon, 16 Oct 2006 14:34:36 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0B57@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia Perlman <Radia.Perlman@sun.com> Date: Mon, 16 Oct 2006 14:34:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 18:35:09 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> Sent: Monday, October 16, 2006 2:10 PM --> To: Caitlin Bestler --> Cc: rbridge@postel.org --> 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: --> --> >rbridge-bounces@postel.org 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 --> >rbridge@postel.org --> >http://mailman.postel.org/mailman/listinfo/rbridge --> > --> > --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GIAEcw029071 for <rbridge@postel.org>; Mon, 16 Oct 2006 11:10:14 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J78003V7QGNL800@dps.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 16 Oct 2006 11:09:59 -0700 (PDT) Received: from sun.com ([129.150.23.204]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7800IY3QGNHN00@mail.sunlabs.com> for rbridge@postel.org; Mon, 16 Oct 2006 11:09:59 -0700 (PDT) Date: Mon, 16 Oct 2006 11:09:58 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <54AD0F12E08D1541B826BE97C98F99F1AFFCE0@NT-SJCA-0751.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <4533CAF6.1010302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <54AD0F12E08D1541B826BE97C98F99F1AFFCE0@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 18:10:42 -0000 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: >rbridge-bounces@postel.org 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 >rbridge@postel.org >http://mailman.postel.org/mailman/listinfo/rbridge > > Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GHnLi7020621 for <rbridge@postel.org>; Mon, 16 Oct 2006 10:49:21 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9GHnGfK013518; Mon, 16 Oct 2006 13:49:17 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17102; Mon, 16 Oct 2006 13:49:16 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT6TXP>; Mon, 16 Oct 2006 13:49:15 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0B40@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Joe Touch <touch@ISI.EDU>, Caitlin Bestler <caitlinb@broadcom.com> Date: Mon, 16 Oct 2006 13:49:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 17:49:46 -0000 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:touch@ISI.EDU] --> Sent: Monday, October 16, 2006 12:49 PM --> To: Caitlin Bestler --> Cc: Silvano Gai; Gray, Eric; rbridge@postel.org; 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 --> --> Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GH4231003784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 10:04:02 -0700 (PDT) Received: from [75.215.31.243] (243.sub-75-215-31.myvzw.com [75.215.31.243]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9GH3WFx025547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 10:03:34 -0700 (PDT) Message-ID: <4533BA78.9030005@isi.edu> Date: Mon, 16 Oct 2006 09:59:36 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFCE0@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1AFFCE0@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F0177E2AFCADEA7B01749AC" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 17:04:44 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFM7p4E5f5cImnZrsRAuROAKCNiM1buRSlvNgZKyIkpv0R/PD6NQCfTGnw EKGRFl/c4kx2/VcF4Sww9QA= =QCFr -----END PGP SIGNATURE----- --------------enig8F0177E2AFCADEA7B01749AC-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GH460C003811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 10:04:06 -0700 (PDT) Received: from [75.215.31.243] (243.sub-75-215-31.myvzw.com [75.215.31.243]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9GH3cG7025573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 10:03:40 -0700 (PDT) Message-ID: <4533BB53.4020001@isi.edu> Date: Mon, 16 Oct 2006 10:03:15 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF7CA@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF7CA@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C0126CC087AA1EB3F59BABA" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 17:04:42 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFM7tTE5f5cImnZrsRAhfbAJ9kvfkuNl8+hGZ876Hn1qS3PGdv8wCeJ3ER W7QtiWB7mFqlTngb0SdGTl4= =L3nw -----END PGP SIGNATURE----- --------------enig7C0126CC087AA1EB3F59BABA-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GGqa4b028617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Mon, 16 Oct 2006 09:52:37 -0700 (PDT) Received: from [75.214.144.183] (183.sub-75-214-144.myvzw.com [75.214.144.183]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9GGnWWm022350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 09:49:33 -0700 (PDT) Message-ID: <4533B818.2030000@isi.edu> Date: Mon, 16 Oct 2006 09:49:28 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Caitlin Bestler <caitlinb@broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFCDC@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1AFFCDC@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3DE20CB00921A040B73E18AC" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 16:53:03 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFM7gYE5f5cImnZrsRArjbAKD5uwjmS9RqHCUtMO2PKMBWv9M4tACg6nQW TvCB8fEr3Fp2oLJ5d+Y+MXM= =lQ2g -----END PGP SIGNATURE----- --------------enig3DE20CB00921A040B73E18AC-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GGScoU020179 for <rbridge@postel.org>; Mon, 16 Oct 2006 09:28:38 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9GGSZfK009913; Mon, 16 Oct 2006 12:28:35 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03184; Mon, 16 Oct 2006 12:28:35 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT6PAY>; Mon, 16 Oct 2006 12:28:34 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0B24@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "'Caitlin Bestler'" <caitlinb@broadcom.com> Date: Mon, 16 Oct 2006 12:28:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: "'rbridge@postel.org'" <rbridge@postel.org> Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 16:29:08 -0000 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: rbridge@postel.org; 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: rbridge-bounces@postel.org --> --> [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler --> --> Sent: Monday, October 16, 2006 12:09 PM --> --> To: Silvano Gai; rbridge@postel.org --> --> Subject: Re: [rbridge] FTag --> --> --> --> rbridge-bounces@postel.org 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 --> --> rbridge@postel.org --> --> http://mailman.postel.org/mailman/listinfo/rbridge --> --> --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GGRDAo019447 for <rbridge@postel.org>; Mon, 16 Oct 2006 09:27:14 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9GGRAfK009861; Mon, 16 Oct 2006 12:27:11 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02993; Mon, 16 Oct 2006 12:27:10 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <48NT6393>; Mon, 16 Oct 2006 12:27:09 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0B23@uspitsmsgusr08.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Caitlin Bestler <caitlinb@broadcom.com> Date: Mon, 16 Oct 2006 12:27:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 16:27:37 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler --> Sent: Monday, October 16, 2006 12:09 PM --> To: Silvano Gai; rbridge@postel.org --> Subject: Re: [rbridge] FTag --> --> rbridge-bounces@postel.org 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GGBCZo013737 for <rbridge@postel.org>; Mon, 16 Oct 2006 09:11:12 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 16 Oct 2006 09:11:02 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 7A3612AE; Mon, 16 Oct 2006 09:11:02 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 38FCC2B0; Mon, 16 Oct 2006 09:11:02 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHU00248; Mon, 16 Oct 2006 09:03:04 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6917E20509; Mon, 16 Oct 2006 09:03:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Oct 2006 09:02:49 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFCDC@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <45332324.8010400@isi.edu> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acbw6maA7ZWvqIlWRaGDWOdsnFaG+QAUXiDA From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Joe Touch" <touch@ISI.EDU>, "Silvano Gai" <sgai@nuovasystems.com> X-WSS-ID: 692D709C09W5219705-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9GGBCZo013737 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 16:12:08 -0000 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. Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9GG9eWx013367 for <rbridge@postel.org>; Mon, 16 Oct 2006 09:09:40 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 16 Oct 2006 09:09:34 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 482BD2AE; Mon, 16 Oct 2006 09:09:34 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1C5E82AF; Mon, 16 Oct 2006 09:09:34 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHU02431; Mon, 16 Oct 2006 09:09:15 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B02E820501; Mon, 16 Oct 2006 09:09:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Oct 2006 09:09:13 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFCE0@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF7C8@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] FTag Thread-Index: AcbwwVTLK5sVJsXuT3GV4VGYqzdkogAe3b6g From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, rbridge@postel.org X-WSS-ID: 692D713409W5219138-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9GG9eWx013367 Subject: Re: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 16:10:08 -0000 Status: RO Content-Length: 922 rbridge-bounces@postel.org 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). Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9G6Eri9007188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Sun, 15 Oct 2006 23:14:53 -0700 (PDT) Received: from [128.9.176.218] (c2-vpn06.isi.edu [128.9.176.218]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9G6Dxxb000683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2006 23:13:59 -0700 (PDT) Message-ID: <45332324.8010400@isi.edu> Date: Sun, 15 Oct 2006 23:13:56 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF676@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF676@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBB64B1E13AE283C0DB835474" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 06:15:18 -0000 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:Eric.Gray@marconi.com] >> Sent: Friday, October 13, 2006 9:43 AM >> To: Silvano Gai; Caitlin Bestler; Joe Touch >> Cc: rbridge@postel.org; 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFMyMlE5f5cImnZrsRArqTAJ0QwxirW8rqtc+nikaamJz+Ho1yNQCffWnX 1OXJkXcPVfsGSThDeYytBNg= =/Kku -----END PGP SIGNATURE----- --------------enigBB64B1E13AE283C0DB835474-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9G1OgpY025669 for <rbridge@postel.org>; Sun, 15 Oct 2006 18:24:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Oct 2006 18:24:38 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF7CA@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: AcbvHx2odEQCeqPhSqCLD1P3VDDObQBn81Uw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9G1OgpY025669 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 01:25:11 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 13, 2006 4:27 PM > To: Silvano Gai; Radia Perlman; Caitlin Bestler > Cc: rbridge@postel.org > 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Friday, October 13, 2006 4:47 PM > --> To: Radia Perlman; Caitlin Bestler > --> Cc: rbridge@postel.org > --> 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] > --> On > --> > Behalf Of Radia Perlman > --> > Sent: Friday, October 13, 2006 12:21 PM > --> > To: Caitlin Bestler > --> > Cc: rbridge@postel.org > --> > 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 > --> > rbridge@postel.org > --> > http://mailman.postel.org/mailman/listinfo/rbridge > --> > --> _______________________________________________ > --> rbridge mailing list > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9G1NGaV025314 for <rbridge@postel.org>; Sun, 15 Oct 2006 18:23:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F0C1.A7852E0D" Date: Sun, 15 Oct 2006 18:20:56 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF7C8@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FTag Thread-Index: AcbwwVTLK5sVJsXuT3GV4VGYqzdkog== From: "Silvano Gai" <sgai@nuovasystems.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Subject: [rbridge] FTag X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 16 Oct 2006 01:23:35 -0000 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> </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> </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> </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-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DNREqd029177 for <rbridge@postel.org>; Fri, 13 Oct 2006 16:27:15 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DNRCfK013437; Fri, 13 Oct 2006 19:27:12 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA18931; Fri, 13 Oct 2006 19:27:11 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5609>; Fri, 13 Oct 2006 19:27:10 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0A70@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Radia Perlman <Radia.Perlman@sun.com>, Caitlin Bestler <caitlinb@broadcom.com> Date: Fri, 13 Oct 2006 19:27:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 23:27:46 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Friday, October 13, 2006 4:47 PM --> To: Radia Perlman; Caitlin Bestler --> Cc: rbridge@postel.org --> 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] --> On --> > Behalf Of Radia Perlman --> > Sent: Friday, October 13, 2006 12:21 PM --> > To: Caitlin Bestler --> > Cc: rbridge@postel.org --> > 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 --> > rbridge@postel.org --> > http://mailman.postel.org/mailman/listinfo/rbridge --> --> _______________________________________________ --> rbridge mailing list --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9DLpThE003328 for <rbridge@postel.org>; Fri, 13 Oct 2006 14:51:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1160776283!2930329!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 3699 invoked from network); 13 Oct 2006 21:51:23 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-3.tower-128.messagelabs.com with SMTP; 13 Oct 2006 21:51:23 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id k9DLpMas001264 for <rbridge@postel.org>; Fri, 13 Oct 2006 14:51:23 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k9DLpL5H010522 for <rbridge@postel.org>; Fri, 13 Oct 2006 16:51:22 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 17:51:13 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900184F13D@de01exm64.ds.mot.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40B3DEB00@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) thread-index: Acbu8aUZTGatWmNUSh2hLAD/Wbci5AAAfyLQAAXGBlA= From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Don Fedyk" <dwfedyk@nortel.com>, "Radia Perlman" <Radia.Perlman@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DLpThE003328 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 21:51:42 -0000 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:dwfedyk@nortel.com] Sent: Friday, October 13, 2006 2:51 PM To: Radia Perlman Cc: Eastlake III Donald-LDE008; rbridge@postel.org 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. ... Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DKqhUP014110 for <rbridge@postel.org>; Fri, 13 Oct 2006 13:52:44 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DKqZfK007733; Fri, 13 Oct 2006 16:52:36 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29609; Fri, 13 Oct 2006 16:52:35 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5V9F>; Fri, 13 Oct 2006 16:52:35 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0A62@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, "Gray, Eric" <Eric.Gray@marconi.com>, Caitlin Bestler <caitlinb@broadcom.com>, Joe Touch <touch@ISI.EDU> Date: Fri, 13 Oct 2006 16:52:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 20:53:42 -0000 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:sgai@nuovasystems.com] --> Sent: Friday, October 13, 2006 4:43 PM --> To: Gray, Eric; Caitlin Bestler; Joe Touch --> Cc: rbridge@postel.org; 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:Eric.Gray@marconi.com] --> > Sent: Friday, October 13, 2006 9:58 AM --> > To: Silvano Gai; Caitlin Bestler; Joe Touch --> > Cc: rbridge@postel.org; 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: rbridge-bounces@postel.org --> > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> > --> Sent: Thursday, October 12, 2006 4:26 PM --> > --> To: Caitlin Bestler; Joe Touch --> > --> Cc: rbridge@postel.org; 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 --> > --> rbridge@postel.org --> > --> http://mailman.postel.org/mailman/listinfo/rbridge --> > --> --> Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DKpWQg013805 for <rbridge@postel.org>; Fri, 13 Oct 2006 13:51:32 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2006 13:51:32 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9DKpWFb000324; Fri, 13 Oct 2006 13:51:32 -0700 Received: from [171.71.58.82] (dhcp-171-71-58-82.cisco.com [171.71.58.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9DKpWbF003069; Fri, 13 Oct 2006 13:51:32 -0700 (PDT) Message-ID: <452FFCDA.6070203@cisco.com> Date: Fri, 13 Oct 2006 13:53:46 -0700 From: Dinesh G Dutt <ddutt@cisco.com> User-Agent: Thunderbird 2.0b1pre (X11/20060921) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFB60@NT-SJCA-0751.brcm.ad.broadcom.com> <452FE709.7090900@sun.com> In-Reply-To: <452FE709.7090900@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2618; t=1160772692; x=1161636692; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ddutt@cisco.com; z=From:Dinesh=20G=20Dutt=20<ddutt@cisco.com> |Subject:Re=3A=20[rbridge]=20Range=20of=20appllicability=20(was=20Re=3A=20TTL=20o nly=20-=20was=20RE=3A=0A=20New=20fields=20in=20shim=20header?); X=v=3Dcisco.com=3B=20h=3D3XZD+bXS71GFZWBYe8uwQ7yRbbs=3D; b=WfaT5s9sOruIJlk3gR3ZXnAQOxE0RziN+h/PbF3asDgI32XCU6/MOW0YGLcByaWfiQr348aJ VM4aRwgV7mlfdTcDbk8wLfAfXF9YfYZTQ7uu8w2mR9vtGQBoPKs9aiIB; Authentication-Results: sj-dkim-5.cisco.com; header.From=ddutt@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ddutt@cisco.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 20:51:40 -0000 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 > rbridge@postel.org > 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 Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DKkoHm012405 for <rbridge@postel.org>; Fri, 13 Oct 2006 13:46:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 13:46:47 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF67B@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acbu/y6oupCc8qXpRqKT+bxqwW8SbAACTbAQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DKkoHm012405 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 20:47:31 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Radia Perlman > Sent: Friday, October 13, 2006 12:21 PM > To: Caitlin Bestler > Cc: rbridge@postel.org > 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DKhXTx011551 for <rbridge@postel.org>; Fri, 13 Oct 2006 13:43:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 13:43:15 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF678@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acbu6NA/lL7GEx50TcanMojXQs4IewAHwkww From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DKhXTx011551 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 20:43:39 -0000 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:Eric.Gray@marconi.com] > Sent: Friday, October 13, 2006 9:58 AM > To: Silvano Gai; Caitlin Bestler; Joe Touch > Cc: rbridge@postel.org; 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Thursday, October 12, 2006 4:26 PM > --> To: Caitlin Bestler; Joe Touch > --> Cc: rbridge@postel.org; 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DKeJP1010531 for <rbridge@postel.org>; Fri, 13 Oct 2006 13:40:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 13:40:16 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF676@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acbu5qitPpdwuTZ5QcewsMoCMoBnGgAIDE1w From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Caitlin Bestler" <caitlinb@broadcom.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DKeJP1010531 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 20:40:41 -0000 Status: RO Content-Length: 4697 Eric, > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > Sent: Friday, October 13, 2006 9:43 AM > To: Silvano Gai; Caitlin Bestler; Joe Touch > Cc: rbridge@postel.org; 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DKWms6008309 for <rbridge@postel.org>; Fri, 13 Oct 2006 13:32:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 13:32:44 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF66D@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: Acbu4eJNZOzTc6beS9mG1fWD+MHz5AAJHrPA From: "Silvano Gai" <sgai@nuovasystems.com> To: "Gray, Eric" <Eric.Gray@marconi.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DKWms6008309 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 20:33:38 -0000 Status: RO Content-Length: 6546 Eric, > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > Sent: Friday, October 13, 2006 9:08 AM > To: Silvano Gai; Joe Touch > Cc: rbridge@postel.org; 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: rbridge-bounces@postel.org > --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai > --> Sent: Thursday, October 12, 2006 12:14 PM > --> To: Joe Touch > --> Cc: rbridge@postel.org; Radia Perlman > --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? > --> > --> > --> > --> -----Original Message----- > --> From: Joe Touch [mailto:touch@ISI.EDU] > --> Sent: Thursday, October 12, 2006 8:55 AM > --> To: Silvano Gai > --> Cc: Radia Perlman; rbridge@postel.org > --> 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:touch@ISI.EDU] > --> > Sent: Thursday, October 12, 2006 7:30 AM > --> > To: Silvano Gai > --> > Cc: Radia Perlman; rbridge@postel.org > --> > 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:touch@ISI.EDU] > --> >> Sent: Thursday, October 12, 2006 7:07 AM > --> >> To: Silvano Gai > --> >> Cc: Radia Perlman; rbridge@postel.org > --> >> 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 > --> rbridge@postel.org > --> http://mailman.postel.org/mailman/listinfo/rbridge > --> Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DJuJ2u021833 for <rbridge@postel.org>; Fri, 13 Oct 2006 12:56:19 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 13 Oct 2006 12:56:19 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9DJuJvl008294; Fri, 13 Oct 2006 12:56:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9DJuEbL005632; Fri, 13 Oct 2006 12:56:19 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 12:56:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 12:56:13 -0700 Message-ID: <7178B7E237F45D45BE404AFF0AF58D870181BC82@xmb-sjc-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acbu/tJl18fShimgRMy0K09MRZGLnAAAeH5w From: "Sanjay Sane \(sanjays\)" <sanjays@cisco.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Caitlin Bestler" <caitlinb@broadcom.com> X-OriginalArrivalTime: 13 Oct 2006 19:56:14.0016 (UTC) FILETIME=[A349B400:01C6EF01] DKIM-Signature: a=rsa-sha1; q=dns; l=3090; t=1160769379; x=1161633379; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjays@cisco.com; z=From:=22Sanjay=20Sane=20\(sanjays\)=22=20<sanjays@cisco.com> |Subject:RE=3A=20[rbridge]=20Range=20of=20appllicability=20(was=20Re=3A=20TTL=20o nly=20-=20was=20RE=3A=20New=20fields=20in=20shim=20header?); X=v=3Dcisco.com=3B=20h=3DzkvGtcIOrlpb3ZylZJR1dprQSpg=3D; b=RECUvIMdK8QNZQ99IQ+opA76d5IdeHH5WhcS3tV+Fe+Mw667OecxehAUk/xOFmB3g0nT6Wf6 R6lkbRmljqT5lnq+vtiRBo8QqYIoI87atbFoZcT9Vdo67IoZtwb5j+mv; Authentication-Results: sj-dkim-6.cisco.com; header.From=sanjays@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sanjays@cisco.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DJuJ2u021833 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 19:57:11 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman Sent: Friday, October 13, 2006 12:21 PM To: Caitlin Bestler Cc: rbridge@postel.org 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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DJgV2w017024 for <rbridge@postel.org>; Fri, 13 Oct 2006 12:42:32 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DJgQfK002031; Fri, 13 Oct 2006 15:42:26 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA11930; Fri, 13 Oct 2006 15:42:26 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5Q1L>; Fri, 13 Oct 2006 15:42:25 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D0A44@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Radia Perlman <Radia.Perlman@sun.com> Date: Fri, 13 Oct 2006 15:42:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 19:43:10 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Radia Perlman --> Sent: Friday, October 13, 2006 3:21 PM --> To: Caitlin Bestler --> Cc: rbridge@postel.org --> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DJKkVK010981 for <rbridge@postel.org>; Fri, 13 Oct 2006 12:20:46 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J730005G9QI4X10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 13 Oct 2006 12:20:42 -0700 (PDT) Received: from sun.com ([129.150.27.11]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7300FAT9QH1J10@mail.sunlabs.com> for rbridge@postel.org; Fri, 13 Oct 2006 12:20:42 -0700 (PDT) Date: Fri, 13 Oct 2006 12:20:41 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <54AD0F12E08D1541B826BE97C98F99F1AFFB60@NT-SJCA-0751.brcm.ad.broadcom.com> To: Caitlin Bestler <caitlinb@broadcom.com> Message-id: <452FE709.7090900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <54AD0F12E08D1541B826BE97C98F99F1AFFB60@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 19:21:04 -0000 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 Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DIw01r003749 for <rbridge@postel.org>; Fri, 13 Oct 2006 11:58:00 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 13 Oct 2006 11:57:46 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id DF9632AF; Fri, 13 Oct 2006 11:57:45 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A6A2D2AE; Fri, 13 Oct 2006 11:57:45 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHM62407; Fri, 13 Oct 2006 11:57:44 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id DBAD320501; Fri, 13 Oct 2006 11:57:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Oct 2006 11:57:42 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFB60@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <452FD473.3020103@sun.com> Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acbu9ByjS4HtdimPQrumHaiCJ8GWnwABShNg From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Radia Perlman" <Radia.Perlman@sun.com>, "Don Fedyk" <dwfedyk@nortel.com> X-WSS-ID: 69313E202I04244169-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DIw01r003749 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 18:58:36 -0000 Status: RO Content-Length: 1616 rbridge-bounces@postel.org 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? Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DIqRIY001777 for <rbridge@postel.org>; Fri, 13 Oct 2006 11:52:27 -0700 (PDT) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9DIpWN18639; Fri, 13 Oct 2006 14:51:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 14:51:23 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40B3DEB00@zrtphxm2.corp.nortel.com> In-Reply-To: <452FD473.3020103@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: Acbu8aUZTGatWmNUSh2hLAD/Wbci5AAAfyLQ From: "Don Fedyk" <dwfedyk@nortel.com> To: "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dwfedyk@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DIqRIY001777 Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 18:53:08 -0000 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 > > Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DI1SBY015032 for <rbridge@postel.org>; Fri, 13 Oct 2006 11:01:28 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J730000862C4X10@dps.sfvic.sunlabs.com> for rbridge@postel.org; Fri, 13 Oct 2006 11:01:24 -0700 (PDT) Received: from sun.com ([129.150.27.11]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7300F1362B1J10@mail.sunlabs.com> for rbridge@postel.org; Fri, 13 Oct 2006 11:01:24 -0700 (PDT) Date: Fri, 13 Oct 2006 11:01:23 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <34B3EAA5B3066A42914D28C5ECF5FEA40B3DE8B0@zrtphxm2.corp.nortel.com> To: Don Fedyk <dwfedyk@nortel.com> Message-id: <452FD473.3020103@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <34B3EAA5B3066A42914D28C5ECF5FEA40B3DE8B0@zrtphxm2.corp.nortel.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 18:02:03 -0000 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 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DH6x2S027549 for <rbridge@postel.org>; Fri, 13 Oct 2006 10:07:00 -0700 (PDT) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9DH5m214957; Fri, 13 Oct 2006 13:05:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 13:05:45 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40B3DE8B0@zrtphxm2.corp.nortel.com> In-Reply-To: <3870C46029D1F945B1472F170D2D97900184EEDB@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: AcbuzdoeEci3IUDnQo+LJsuvkSpNNAADPrWQAANKp1A= From: "Don Fedyk" <dwfedyk@nortel.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: dwfedyk@nortel.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DH6x2S027549 Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 17:07:27 -0000 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> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DH4E9M026752 for <rbridge@postel.org>; Fri, 13 Oct 2006 10:04:14 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DH4BfK024425; Fri, 13 Oct 2006 13:04:11 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15611; Fri, 13 Oct 2006 13:04:11 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5H9F>; Fri, 13 Oct 2006 13:04:10 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D09FA@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Caitlin Bestler <caitlinb@broadcom.com>, Silvano Gai <sgai@nuovasystems.com>, Joe Touch <touch@ISI.EDU> Date: Fri, 13 Oct 2006 13:04:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 17:04:29 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Caitlin Bestler --> Sent: Thursday, October 12, 2006 4:37 PM --> To: Silvano Gai; Joe Touch --> Cc: rbridge@postel.org; 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DGwVBS024513 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:58:32 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DGwSfK024190; Fri, 13 Oct 2006 12:58:28 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14643; Fri, 13 Oct 2006 12:58:28 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5H49>; Fri, 13 Oct 2006 12:58:27 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D09F9@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Caitlin Bestler <caitlinb@broadcom.com>, Joe Touch <touch@ISI.EDU> Date: Fri, 13 Oct 2006 12:58:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:59:03 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Thursday, October 12, 2006 4:26 PM --> To: Caitlin Bestler; Joe Touch --> Cc: rbridge@postel.org; 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DGqtiO022669 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:52:55 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DGqqfK023967; Fri, 13 Oct 2006 12:52:52 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13814; Fri, 13 Oct 2006 12:52:52 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5HM4>; Fri, 13 Oct 2006 12:52:51 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D09F3@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Caitlin Bestler <caitlinb@broadcom.com>, Joe Touch <touch@ISI.EDU> Date: Fri, 13 Oct 2006 12:52:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:53:27 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Thursday, October 12, 2006 4:17 PM --> To: Caitlin Bestler; Joe Touch --> Cc: rbridge@postel.org; 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DGh6ZW019494 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:43:07 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DGgsfK023428; Fri, 13 Oct 2006 12:42:54 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12163; Fri, 13 Oct 2006 12:42:54 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5G6T>; Fri, 13 Oct 2006 12:42:53 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D09EF@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Caitlin Bestler <caitlinb@broadcom.com>, Joe Touch <touch@ISI.EDU> Date: Fri, 13 Oct 2006 12:42:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:43:42 -0000 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DGhGpQ019519 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:43:16 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Fri, 13 Oct 2006 09:43:07 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5194E2AF; Fri, 13 Oct 2006 09:43:07 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2B9D52AE; Fri, 13 Oct 2006 09:43:07 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHM33172; Fri, 13 Oct 2006 09:43:04 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 5B91920501; Fri, 13 Oct 2006 09:43:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Oct 2006 09:43:03 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFB25@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <3870C46029D1F945B1472F170D2D97900184EEDB@de01exm64.ds.mot.com> Thread-Topic: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) Thread-Index: AcbuzdoeEci3IUDnQo+LJsuvkSpNNAADPrWQAAKn2/A= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, rbridge@postel.org X-WSS-ID: 69311D912I04210108-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DGhGpQ019519 Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:43:35 -0000 Status: RO Content-Length: 1445 rbridge-bounces@postel.org 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. Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DG8xhR008141 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:08:59 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DG8qfK021824; Fri, 13 Oct 2006 12:08:53 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06742; Fri, 13 Oct 2006 12:08:29 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN5FGM>; Fri, 13 Oct 2006 12:08:28 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D09DE@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Silvano Gai <sgai@nuovasystems.com>, Joe Touch <touch@ISI.EDU> Date: Fri, 13 Oct 2006 12:08:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:09:50 -0000 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: rbridge-bounces@postel.org --> [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai --> Sent: Thursday, October 12, 2006 12:14 PM --> To: Joe Touch --> Cc: rbridge@postel.org; Radia Perlman --> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? --> --> --> --> -----Original Message----- --> From: Joe Touch [mailto:touch@ISI.EDU] --> Sent: Thursday, October 12, 2006 8:55 AM --> To: Silvano Gai --> Cc: Radia Perlman; rbridge@postel.org --> 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:touch@ISI.EDU] --> > Sent: Thursday, October 12, 2006 7:30 AM --> > To: Silvano Gai --> > Cc: Radia Perlman; rbridge@postel.org --> > 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:touch@ISI.EDU] --> >> Sent: Thursday, October 12, 2006 7:07 AM --> >> To: Silvano Gai --> >> Cc: Radia Perlman; rbridge@postel.org --> >> 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 --> rbridge@postel.org --> http://mailman.postel.org/mailman/listinfo/rbridge --> Received: from mail125.messagelabs.com (mail125.messagelabs.com [85.158.136.35]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9DG4FnD006390 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:04:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-125.messagelabs.com!1160755276!17392136!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 20730 invoked from network); 13 Oct 2006 16:01:17 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-11.tower-125.messagelabs.com with SMTP; 13 Oct 2006 16:01:17 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id k9DG1FZC004879 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:01:16 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k9DG1Ews025712 for <rbridge@postel.org>; Fri, 13 Oct 2006 11:01:15 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 2006 12:01:13 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900184EEDB@de01exm64.ds.mot.com> In-Reply-To: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Range of appllicability (was Re: [rbridge] TTL only - was RE: New fields in shim header?) thread-index: AcbuzdoeEci3IUDnQo+LJsuvkSpNNAADPrWQ From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9DG4FnD006390 Subject: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?) X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:04:55 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Ed Bowen Sent: Friday, October 13, 2006 9:29 AM To: Joe Touch Cc: rbridge@postel.org; rbridge-bounces@postel.org; Radia Perlman Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? Joe Touch <touch@ISI.EDU> 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 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DG1rk8005260 for <rbridge@postel.org>; Fri, 13 Oct 2006 09:01:54 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k9DG1efK020764; Fri, 13 Oct 2006 12:01:40 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03335; Fri, 13 Oct 2006 12:01:40 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <TXJN51BL>; Fri, 13 Oct 2006 12:01:39 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81259D09DD@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: Joe Touch <touch@ISI.EDU>, Silvano Gai <sgai@nuovasystems.com> Date: Fri, 13 Oct 2006 12:01:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 16:02:26 -0000 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] ... Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DFqIB9001343; Fri, 13 Oct 2006 08:52:18 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J73000S00324X00@dps.sfvic.sunlabs.com>; Fri, 13 Oct 2006 08:52:14 -0700 (PDT) Received: from sun.com ([129.150.20.233]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7300FJF0311J00@mail.sunlabs.com>; Fri, 13 Oct 2006 08:52:14 -0700 (PDT) Date: Fri, 13 Oct 2006 08:52:13 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> To: Ed Bowen <edbowen@us.ibm.com> Message-id: <452FB62D.6060302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 15:52:55 -0000 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 <touch@ISI.EDU> 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 > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DFJuM0021156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Oct 2006 08:19:57 -0700 (PDT) Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9DFJTrV005269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Oct 2006 08:19:30 -0700 (PDT) Message-ID: <452FAE7F.8050604@isi.edu> Date: Fri, 13 Oct 2006 08:19:27 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ed Bowen <edbowen@us.ibm.com> References: <OFD3243B41.A8C80DE8-ON85257206.0051C330-85257206.0053835B@us.ibm.com> In-Reply-To: <OFD3243B41.A8C80DE8-ON85257206.0051C330-85257206.0053835B@us.ibm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E6E57C0CACBA2FDF7D2192F" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 15:20:48 -0000 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 <touch@ISI.EDU> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFL65/E5f5cImnZrsRAlCCAJ4vNp803ndZZ7BSaxb1jH3y7icSsQCgkkkR rpIzgtJr3rIuDzxrc/Dv7zg= =nwnx -----END PGP SIGNATURE----- --------------enig5E6E57C0CACBA2FDF7D2192F-- Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DFCKJu018586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Oct 2006 08:12:20 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k9DFCJH8002445; Fri, 13 Oct 2006 11:12:19 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9DFCHDH358162; Fri, 13 Oct 2006 09:12:18 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9DFCH4C013604; Fri, 13 Oct 2006 09:12:17 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.17.195.60]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9DFCGIW013549; Fri, 13 Oct 2006 09:12:17 -0600 In-Reply-To: <452F9DED.3080105@isi.edu> To: Joe Touch <touch@ISI.EDU> X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: <OFD3243B41.A8C80DE8-ON85257206.0051C330-85257206.0053835B@us.ibm.com> From: Ed Bowen <edbowen@us.ibm.com> Date: Fri, 13 Oct 2006 11:12:11 -0400 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/13/2006 09:12:17 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF895DFC245A08f9e8a93df938690918c0ABBF895DFC245A0" Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: edbowen@us.ibm.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 15:12:56 -0000 Status: RO Content-Length: 1953 --0__=0ABBF895DFC245A08f9e8a93df938690918c0ABBF895DFC245A0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Joe, Joe Touch <touch@ISI.EDU> 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 <touch@ISI.EDU> wrote on 10/13/2006 10:08:45 AM:<br= > <br> > TRILL applies anytime the cross-section bandwidth of a set of depl= oyed<br> > bridges is constrained because of the spanning tree algorithm rath= er<br> > 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> > <br> > Again, please review the problem and applicability statement and t= he<br> > 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-- Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DE9Ntc029279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Oct 2006 07:09:23 -0700 (PDT) Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9DE8qvN019678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Oct 2006 07:08:55 -0700 (PDT) Message-ID: <452F9DED.3080105@isi.edu> Date: Fri, 13 Oct 2006 07:08:45 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ed Bowen <edbowen@us.ibm.com> References: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> In-Reply-To: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD04838D085DCA26395901692" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 14:09:58 -0000 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 <touch@ISI.EDU> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFL53yE5f5cImnZrsRAvKqAJ0XKQdTzp4VFf3rcvYH+ukBiY0sMwCfUccG uJdF31FDJUrMMe58tMucIDw= =0c/F -----END PGP SIGNATURE----- --------------enigD04838D085DCA26395901692-- Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9DDX789017602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Oct 2006 06:33:08 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k9DDX6ah006695; Fri, 13 Oct 2006 09:33:06 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9DDX6sX311954; Fri, 13 Oct 2006 07:33:06 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9DDX4Zm031049; Fri, 13 Oct 2006 07:33:06 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.17.195.60]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9DDX34m030832; Fri, 13 Oct 2006 07:33:03 -0600 In-Reply-To: <452EAB1B.9030509@isi.edu> To: Joe Touch <touch@ISI.EDU> X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: <OF27F08223.6AAD27B7-ON85257206.000A61A6-85257206.004A116B@us.ibm.com> From: Ed Bowen <edbowen@us.ibm.com> Date: Fri, 13 Oct 2006 09:29:01 -0400 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/13/2006 07:33:03 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF895DF99E7368f9e8a93df938690918c0ABBF895DF99E736" Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: edbowen@us.ibm.com Cc: rbridge@postel.org, rbridge-bounces@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 13 Oct 2006 13:33:30 -0000 Status: RO Content-Length: 1806 --0__=0ABBF895DF99E7368f9e8a93df938690918c0ABBF895DF99E736 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Joe Touch <touch@ISI.EDU> 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 <touch@ISI.EDU></tt><tt> wrote on 10/12/200= 6 04:52:43 PM:<br> > <br> > <br> > Silvano Gai wrote:<br> > > Joe,<br> > > <br> > > IMHO TRILL will be valuable in HPC and Datacenters, where hig= h<br> > > bisectional bandwidth is a must, and in Enterprise Backbone. = <br> > <br> > Sure, but that's not the only place they will be deployed. Please = review<br> > the P&AS.<br> > <br> > Joe<br> </tt><br> <tt>Joe, </tt><br> <br> <tt>What is the operational experience that indicates the requirement f= or the other environments? 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-- Received: from mail125.messagelabs.com (mail125.messagelabs.com [85.158.136.35]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9CLgvl6025985 for <rbridge@postel.org>; Thu, 12 Oct 2006 14:42:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-12.tower-125.messagelabs.com!1160689374!17255847!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 6070 invoked from network); 12 Oct 2006 21:42:54 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-125.messagelabs.com with SMTP; 12 Oct 2006 21:42:54 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id k9CLgqKn016121 for <rbridge@postel.org>; Thu, 12 Oct 2006 16:42:53 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k9CLgppa006020 for <rbridge@postel.org>; Thu, 12 Oct 2006 16:42:51 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 17:42:50 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900184EC47@de01exm64.ds.mot.com> In-Reply-To: <FCAF0E8A270B6E4781D91431E853F6F3036DA16A@GONDOR.rs.riverstonenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] : Application of RBRidge thread-index: AcbuB88+Ko7wOx9cR4mnwAC/+LGDOQAANcDQAAOYglAAC1GH4A== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "N, Venkatesh" <venkatesh@riverstonenet.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CLgvl6025985 Cc: rbridge@postel.org Subject: Re: [rbridge] : Application of RBRidge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 21:43:17 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of N, Venkatesh Sent: Thursday, October 12, 2006 12:00 PM To: Silvano Gai; Joe Touch Cc: rbridge@postel.org; 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai Sent: Thursday, October 12, 2006 7:49 PM To: Joe Touch Cc: rbridge@postel.org; 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:touch@ISI.EDU] Sent: Thursday, October 12, 2006 7:07 AM To: Silvano Gai Cc: Radia Perlman; rbridge@postel.org 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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CLgFR4025782 for <rbridge@postel.org>; Thu, 12 Oct 2006 14:42:16 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 12 Oct 2006 14:42:09 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E998C2AF; Thu, 12 Oct 2006 14:42:08 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C51632AE; Thu, 12 Oct 2006 14:42:08 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHK57185; Thu, 12 Oct 2006 14:42:08 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 40B3C20501; Thu, 12 Oct 2006 14:42:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 14:42:07 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFA70@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF4B0@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuPU9ECOis2xMCTMuj/e7YXqurBgAAa9AgAACq2eAAADDlEAABGakA From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-WSS-ID: 6930693B09W3993550-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CLgFR4025782 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 21:42:51 -0000 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. Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CLW6FY021730 for <rbridge@postel.org>; Thu, 12 Oct 2006 14:32:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 14:32:04 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF4B0@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuPU9ECOis2xMCTMuj/e7YXqurBgAAa9AgAACq2eAAADDlEA== From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CLW6FY021730 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 21:32:22 -0000 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:caitlinb@broadcom.com] > Sent: Thursday, October 12, 2006 2:05 PM > To: Silvano Gai; Joe Touch > Cc: rbridge@postel.org; 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. > Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CL5eff013739 for <rbridge@postel.org>; Thu, 12 Oct 2006 14:05:40 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 12 Oct 2006 14:05:26 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 7D66A2AF; Thu, 12 Oct 2006 14:05:26 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5482C2AE; Thu, 12 Oct 2006 14:05:26 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHK49497; Thu, 12 Oct 2006 14:05:25 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 95FCF20501; Thu, 12 Oct 2006 14:05:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 14:05:21 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFA5F@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF490@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuPU9ECOis2xMCTMuj/e7YXqurBgAAa9AgAACq2eA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-WSS-ID: 6930719C2I03929755-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CL5eff013739 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 21:05:46 -0000 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. Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKrOn1009984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 13:53:24 -0700 (PDT) Received: from [128.9.176.72] ([128.9.176.72]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKqkU1018639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 13:52:47 -0700 (PDT) Message-ID: <452EAB1B.9030509@isi.edu> Date: Thu, 12 Oct 2006 13:52:43 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF490@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF490@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig760CEC5626FE4EC55B1A08AD" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:53:46 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLqsbE5f5cImnZrsRAj8+AKDg9ZKuYRi1+wFZWJev55O0XKy4RQCg2PO8 kHvxVR/PzPvyx+f01BNVcEk= =MPVZ -----END PGP SIGNATURE----- --------------enig760CEC5626FE4EC55B1A08AD-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKoADi008839 for <rbridge@postel.org>; Thu, 12 Oct 2006 13:50:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 13:50:08 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF490@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuPU9ECOis2xMCTMuj/e7YXqurBgAAa9Ag From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CKoADi008839 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:50:22 -0000 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:touch@ISI.EDU] > Sent: Thursday, October 12, 2006 1:30 PM > To: Silvano Gai > Cc: Caitlin Bestler; rbridge@postel.org; 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 Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKbkms004719 for <rbridge@postel.org>; Thu, 12 Oct 2006 13:37:46 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 12 Oct 2006 13:37:26 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 252072AF; Thu, 12 Oct 2006 13:37:26 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id F06102AE; Thu, 12 Oct 2006 13:37:25 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHK44169; Thu, 12 Oct 2006 13:37:25 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 40B7A20501; Thu, 12 Oct 2006 13:37:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 13:37:23 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFA51@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF47E@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6rawAAKPBUAABZiVQAABlblQAAGtFVAAAEQLcA== From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-WSS-ID: 6930780C2I03923152-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CKbkms004719 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:38:18 -0000 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. Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKUphR002759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 13:30:51 -0700 (PDT) Received: from [128.9.176.72] ([128.9.176.72]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKUBaR013732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 13:30:12 -0700 (PDT) Message-ID: <452EA5D0.6090609@isi.edu> Date: Thu, 12 Oct 2006 13:30:08 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF47E@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF47E@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEF55E785A8E19F60E2B5C20" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:31:16 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLqXQE5f5cImnZrsRAukoAKDLe9WfyKhHIT3IedXVX1tKeXpYZgCfYMbk OGSUvBlC5VpQRZ4fehtFsOQ= =DN4r -----END PGP SIGNATURE----- --------------enigCEF55E785A8E19F60E2B5C20-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKQ5sh001339 for <rbridge@postel.org>; Thu, 12 Oct 2006 13:26:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 13:26:03 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF47E@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6rawAAKPBUAABZiVQAABlblQAAGtFVA= From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CKQ5sh001339 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:26:14 -0000 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKOxMY001089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 13:24:59 -0700 (PDT) Received: from [75.214.196.161] (161.sub-75-214-196.myvzw.com [75.214.196.161]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKNfWH012112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 13:23:53 -0700 (PDT) Message-ID: <452EA446.4010104@isi.edu> Date: Thu, 12 Oct 2006 13:23:34 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF477@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF477@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08C765EA7008738C65DD1C60" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:25:24 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLqRKE5f5cImnZrsRAsqrAKDTVXCGdPJwVTvL4eeLVfWg7vt6vQCgpGYz MpjFRBD3q5OqUk21BmJC8mQ= =wZzd -----END PGP SIGNATURE----- --------------enig08C765EA7008738C65DD1C60-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CKGkOo028560 for <rbridge@postel.org>; Thu, 12 Oct 2006 13:16:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 13:16:44 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF477@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6rawAAKPBUAABZiVQAABlblQAAFHCbA= From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CKGkOo028560 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 20:17:17 -0000 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. > > Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CJgHL5017742 for <rbridge@postel.org>; Thu, 12 Oct 2006 12:42:17 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 12 Oct 2006 12:42:02 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 634962AE; Thu, 12 Oct 2006 12:42:02 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2A5792B0; Thu, 12 Oct 2006 12:42:02 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHK34078; Thu, 12 Oct 2006 12:41:59 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 568F920501; Thu, 12 Oct 2006 12:41:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 12:41:58 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFA38@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF452@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6rawAAKPBUAABZiVQAABlblQ From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-WSS-ID: 693045003AK699208-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CJgHL5017742 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 19:42:55 -0000 Status: RO Content-Length: 3721 Silvano Gai wrote: > Caitlin, > > See inline > >> -----Original Message----- >> From: Caitlin Bestler [mailto:caitlinb@broadcom.com] >> Sent: Thursday, October 12, 2006 9:18 AM >> To: Silvano Gai; Joe Touch >> Cc: rbridge@postel.org; Radia Perlman >> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header? >> >> rbridge-bounces@postel.org 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. Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CJTtlg014315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 12:29:55 -0700 (PDT) Received: from [128.9.176.73] ([128.9.176.73]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CJTRfV029811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 12:29:29 -0700 (PDT) Message-ID: <452E9795.3070304@isi.edu> Date: Thu, 12 Oct 2006 12:29:25 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF452@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF452@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig139B05B21A0B6F8C8FE76A30" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 19:30:19 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLpeVE5f5cImnZrsRApFnAJ93cyOJqu+p8kID9dF/XmognR6rhwCg2g+J yAWn2sr+AWmgFxcwMyHPTDs= =O786 -----END PGP SIGNATURE----- --------------enig139B05B21A0B6F8C8FE76A30-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CJ6m1A006577 for <rbridge@postel.org>; Thu, 12 Oct 2006 12:06:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 12:06:45 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF452@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6rawAAKPBUAABZiVQA== From: "Silvano Gai" <sgai@nuovasystems.com> To: "Caitlin Bestler" <caitlinb@broadcom.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CJ6m1A006577 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 19:07:15 -0000 Status: RO Content-Length: 2887 Caitlin, See inline > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Thursday, October 12, 2006 9:18 AM > To: Silvano Gai; Joe Touch > Cc: rbridge@postel.org; Radia Perlman > Subject: RE: [rbridge] TTL only - was RE: New fields in shim header? > > rbridge-bounces@postel.org 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 Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CGIdIf010138 for <rbridge@postel.org>; Thu, 12 Oct 2006 09:18:39 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 12 Oct 2006 09:18:25 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EE0E62AF; Thu, 12 Oct 2006 09:18:24 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C81712AE; Thu, 12 Oct 2006 09:18:24 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHJ92796; Thu, 12 Oct 2006 09:18:23 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3952C20501; Thu, 12 Oct 2006 09:18:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 09:18:23 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFF9E5@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF373@nuova-ex1.hq.nuovaimpresa.com> Thread-Topic: [rbridge] TTL only - was RE: New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6rawAAKPBUA= From: "Caitlin Bestler" <caitlinb@broadcom.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-WSS-ID: 6930B55B3AK640805-01-01 Content-Type: text/plain; charset=us-ascii X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: caitlinb@broadcom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CGIdIf010138 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 16:19:08 -0000 Status: RO Content-Length: 1657 rbridge-bounces@postel.org 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. Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CGEKhp008695 for <rbridge@postel.org>; Thu, 12 Oct 2006 09:14:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 09:14:18 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF39B@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL only - was RE: [rbridge] New fields in shim header? Thread-Index: AcbuFszesHkKuQQeSFi0xXhVyxx7hAAAlkjA From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CGEKhp008695 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 16:14:47 -0000 Status: RO Content-Length: 4204 -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Thursday, October 12, 2006 8:55 AM To: Silvano Gai Cc: Radia Perlman; rbridge@postel.org 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:touch@ISI.EDU] > Sent: Thursday, October 12, 2006 7:30 AM > To: Silvano Gai > Cc: Radia Perlman; rbridge@postel.org > 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:touch@ISI.EDU] >> Sent: Thursday, October 12, 2006 7:07 AM >> To: Silvano Gai >> Cc: Radia Perlman; rbridge@postel.org >> 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 >> > Received: from riverstonenet.com ([63.113.148.10]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CFxfjA003067 for <rbridge@postel.org>; Thu, 12 Oct 2006 08:59:41 -0700 (PDT) Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id IAA00588; Thu, 12 Oct 2006 08:59:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 21:29:32 +0530 Message-ID: <FCAF0E8A270B6E4781D91431E853F6F3036DA16A@GONDOR.rs.riverstonenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] : Application of RBRidge Thread-Index: AcbuB88+Ko7wOx9cR4mnwAC/+LGDOQAANcDQAAOYglA= From: "N, Venkatesh" <venkatesh@riverstonenet.com> To: "Silvano Gai" <sgai@nuovasystems.com>, "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: venkatesh@riverstonenet.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CFxfjA003067 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: [rbridge] : Application of RBRidge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 16:00:38 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Silvano Gai Sent: Thursday, October 12, 2006 7:49 PM To: Joe Touch Cc: rbridge@postel.org; 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:touch@ISI.EDU] Sent: Thursday, October 12, 2006 7:07 AM To: Silvano Gai Cc: Radia Perlman; rbridge@postel.org 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 rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CFtBAe001520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 08:55:11 -0700 (PDT) Received: from [75.212.135.79] (79.sub-75-212-135.myvzw.com [75.212.135.79]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CFslGK009656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 08:54:52 -0700 (PDT) Message-ID: <452E6544.10404@isi.edu> Date: Thu, 12 Oct 2006 08:54:44 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF373@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF373@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1E5230D225B1EF41185CA442" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 15:55:38 -0000 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:touch@ISI.EDU]=20 > Sent: Thursday, October 12, 2006 7:30 AM > To: Silvano Gai > Cc: Radia Perlman; rbridge@postel.org > 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:touch@ISI.EDU]=20 >> Sent: Thursday, October 12, 2006 7:07 AM >> To: Silvano Gai >> Cc: Radia Perlman; rbridge@postel.org >> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLmVEE5f5cImnZrsRAqBLAKCnwa6Kk80TJvx7WJ38Qw5Zeyj4xACfSN5X /0dD4JTa4XLuVfs3bpDxivc= =b3BM -----END PGP SIGNATURE----- --------------enig1E5230D225B1EF41185CA442-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CF5DEd015737 for <rbridge@postel.org>; Thu, 12 Oct 2006 08:05:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 08:05:10 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF373@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL only - was RE: [rbridge] New fields in shim header? Thread-Index: AcbuCuxl3dCEn5LkTimrWL/pr6Ty5gAA6raw From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CF5DEd015737 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 15:05:40 -0000 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:touch@ISI.EDU] Sent: Thursday, October 12, 2006 7:30 AM To: Silvano Gai Cc: Radia Perlman; rbridge@postel.org 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:touch@ISI.EDU] > Sent: Thursday, October 12, 2006 7:07 AM > To: Silvano Gai > Cc: Radia Perlman; rbridge@postel.org > 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 > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CEUAjn005187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 07:30:10 -0700 (PDT) Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CETdIU020469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 07:29:39 -0700 (PDT) Message-ID: <452E5150.8010907@isi.edu> Date: Thu, 12 Oct 2006 07:29:36 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF36F@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF36F@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig841C2602343F6C67A06BD3B4" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 14:30:36 -0000 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:touch@ISI.EDU]=20 > Sent: Thursday, October 12, 2006 7:07 AM > To: Silvano Gai > Cc: Radia Perlman; rbridge@postel.org > 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLlFQE5f5cImnZrsRAkytAKCEW38jCXhAqBNzhAV1Qh7OR0/KUwCfW3dV ElAwGnQ03eriOUW3ItIqVIs= =CFd9 -----END PGP SIGNATURE----- --------------enig841C2602343F6C67A06BD3B4-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CEIuFW001764 for <rbridge@postel.org>; Thu, 12 Oct 2006 07:18:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 07:18:53 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF36F@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL only - was RE: [rbridge] New fields in shim header? Thread-Index: AcbuB88+Ko7wOx9cR4mnwAC/+LGDOQAANcDQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CEIuFW001764 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 14:19:07 -0000 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:touch@ISI.EDU] Sent: Thursday, October 12, 2006 7:07 AM To: Silvano Gai Cc: Radia Perlman; rbridge@postel.org 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 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CE7rWx027733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 07:07:53 -0700 (PDT) Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CE7P5J015612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 07:07:26 -0700 (PDT) Message-ID: <452E4C1B.5040201@isi.edu> Date: Thu, 12 Oct 2006 07:07:23 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF36E@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF36E@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2BEC6B1B374EF7A065C8B618" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 14:08:10 -0000 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLkwbE5f5cImnZrsRAs3nAJ0UVPH1u7U90CI4dtHDmIf8nyQpvACgtaU3 nM/9Q+f5tLc+d3ZGz7uggZA= =JYee -----END PGP SIGNATURE----- --------------enig2BEC6B1B374EF7A065C8B618-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CDwRBF024725 for <rbridge@postel.org>; Thu, 12 Oct 2006 06:58:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 06:58:25 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF36E@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL only - was RE: [rbridge] New fields in shim header? Thread-Index: AcbuAr6aAGm77rh7TpSiRHPqZhJalQAAgJsQ From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CDwRBF024725 Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 13:59:18 -0000 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:touch@ISI.EDU] Sent: Thursday, October 12, 2006 6:31 AM To: Silvano Gai Cc: Radia Perlman; rbridge@postel.org 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Joe Touch > Sent: Wednesday, October 11, 2006 9:46 PM > To: Radia Perlman > Cc: rbridge@postel.org > 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 >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge > Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CDVbwQ015704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Thu, 12 Oct 2006 06:31:38 -0700 (PDT) Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9CDVIkv007475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Oct 2006 06:31:19 -0700 (PDT) Message-ID: <452E43A4.6060504@isi.edu> Date: Thu, 12 Oct 2006 06:31:16 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Silvano Gai <sgai@nuovasystems.com> References: <34BDD2A93E5FD84594BB230DD6C18EA29FF36B@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA29FF36B@nuova-ex1.hq.nuovaimpresa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3941F3EB8B07AAEA624008FD" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org, Radia Perlman <Radia.Perlman@sun.com> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 13:32:32 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On= > Behalf Of Joe Touch > Sent: Wednesday, October 11, 2006 9:46 PM > To: Radia Perlman > Cc: rbridge@postel.org > 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 >> rbridge@postel.org >> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLkOkE5f5cImnZrsRAk+oAKDzo2WwlQe626iAbWt0B0FWO20FwQCeOA4i L7OkYGWcKd0lhtuMMNrRNUk= =dU8m -----END PGP SIGNATURE----- --------------enig3941F3EB8B07AAEA624008FD-- Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9CDNijl013336 for <rbridge@postel.org>; Thu, 12 Oct 2006 06:23:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Oct 2006 06:23:42 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA29FF36B@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL only - was RE: [rbridge] New fields in shim header? Thread-Index: Acbtu0ro/e7wQ1B4Try6/e9XGfZjiQARTAsg From: "Silvano Gai" <sgai@nuovasystems.com> To: "Joe Touch" <touch@ISI.EDU>, "Radia Perlman" <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sgai@nuovasystems.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9CDNijl013336 Cc: rbridge@postel.org Subject: [rbridge] TTL only - was RE: New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 13:24:04 -0000 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: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Joe Touch Sent: Wednesday, October 11, 2006 9:46 PM To: Radia Perlman Cc: rbridge@postel.org 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 > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9C4kJ9h012674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rbridge@postel.org>; Wed, 11 Oct 2006 21:46:19 -0700 (PDT) Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9C4jrf8015635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Oct 2006 21:45:54 -0700 (PDT) Message-ID: <452DC87F.8020709@isi.edu> Date: Wed, 11 Oct 2006 21:45:51 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Radia Perlman <Radia.Perlman@sun.com> References: <452D6643.6030600@sun.com> In-Reply-To: <452D6643.6030600@sun.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05B4170C801B97AA879E80D9" X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbridge@postel.org Subject: Re: [rbridge] New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 12 Oct 2006 04:46:51 -0000 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 > rbridge@postel.org > 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLch/E5f5cImnZrsRAgDbAJ963Uqf7WnfaYaillTPtoeqFgKmjQCeJRjW S/ID6EQK2SVJ0pn3mGB9GiQ= =DsZN -----END PGP SIGNATURE----- --------------enig05B4170C801B97AA879E80D9-- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id k9BLksRY009457 for <rbridge@postel.org>; Wed, 11 Oct 2006 14:46:54 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J6Z00JE0R5WP410@dps.sfvic.sunlabs.com> for rbridge@postel.org; Wed, 11 Oct 2006 14:46:44 -0700 (PDT) Received: from sun.com ([129.150.20.233]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J6Z00B0UR5WF820@mail.sunlabs.com> for rbridge@postel.org; Wed, 11 Oct 2006 14:46:44 -0700 (PDT) Date: Wed, 11 Oct 2006 14:46:43 -0700 From: Radia Perlman <Radia.Perlman@sun.com> To: rbridge@postel.org Message-id: <452D6643.6030600@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] New fields in shim header? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 11 Oct 2006 21:47:09 -0000 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 Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9BEN5Mu015402 for <rbridge@postel.org>; Wed, 11 Oct 2006 07:23:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1160576584!7578764!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17233 invoked from network); 11 Oct 2006 14:23:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 11 Oct 2006 14:23:04 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9BEN0fC005912 for <rbridge@postel.org>; Wed, 11 Oct 2006 07:23:04 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k9BEMxij001902 for <rbridge@postel.org>; Wed, 11 Oct 2006 09:22:59 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Oct 2006 10:22:58 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790017FFB4E@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Meeting in San Diego schedule thread-index: AcbtQMBFyGChnSJuQqaXf9Pk7aYktA== From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9BEN5Mu015402 Subject: [rbridge] WG Meeting in San Diego schedule X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 11 Oct 2006 14:23:18 -0000 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 Donald.Eastlake@Motorola.com Motorola Laboratories +1-508-786-7554 (work) 111 Locke Drive Marlboro, MA 01752 USA Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9B36tt4029220 for <rbridge@postel.org>; Tue, 10 Oct 2006 20:06:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1160536007!2604726!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 13774 invoked from network); 11 Oct 2006 03:06:47 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-11.tower-128.messagelabs.com with SMTP; 11 Oct 2006 03:06:47 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id k9B36jSb015879 for <rbridge@postel.org>; Tue, 10 Oct 2006 22:06:46 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k9B36ihN024625 for <rbridge@postel.org>; Tue, 10 Oct 2006 22:06:45 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Oct 2006 23:06:43 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790017FFA00@de01exm64.ds.mot.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D81257D4519@uspitsmsgusr08.win.marconi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] draft-gray-trill-routing-reqs-01.txt thread-index: Acbc7tTr0UozEsXwRgWnugb67xyRHwP8x7gw From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9B36tt4029220 Cc: rbridge@postel.org Subject: Re: [rbridge] draft-gray-trill-routing-reqs-01.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 11 Oct 2006 03:07:31 -0000 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:Eric.Gray@marconi.com] Sent: Wednesday, September 20, 2006 3:56 PM To: Eastlake III Donald-LDE008 Cc: rbridge@postel.org 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 Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id k9B2kjdO022476 for <rbridge@postel.org>; Tue, 10 Oct 2006 19:46:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1160534761!9824512!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20784 invoked from network); 11 Oct 2006 02:46:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 11 Oct 2006 02:46:01 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9B2jvv8004396 for <rbridge@postel.org>; Tue, 10 Oct 2006 19:46:01 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k9B2juYh004154 for <rbridge@postel.org>; Tue, 10 Oct 2006 21:45:56 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Oct 2006 22:45:54 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790017FF9F4@de01exm64.ds.mot.com> In-Reply-To: <0BF76B30C100624BA997C9CED19D81257D4015@uspitsmsgusr08.win.marconi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.txt thread-index: AcbXi+pu87oPnfoYQ8iD8H+q1GXkxwVFRnng From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> To: "Gray, Eric" <Eric.Gray@marconi.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k9B2kjdO022476 Cc: rbridge@postel.org Subject: Re: [rbridge] Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.txt X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://mailman.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 11 Oct 2006 02:47:03 -0000 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:Eric.Gray@marconi.com] Sent: Wednesday, September 13, 2006 7:25 PM To: Eastlake III Donald-LDE008 Cc: rbridge@postel.org 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
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai
- [rbridge] Comments on: http://www.ietf.org/intern… Silvano Gai