From d3e3e3 at gmail.com Sun Jan 4 18:56:16 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 4 Jan 2009 21:56:16 -0500 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <49307E3D.6070400@sun.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307E3D.6070400@sun.com> Message-ID: <1028365c0901041856o5bc46e5at3d34f2df341bd0ca@mail.gmail.com> Hi Ayan, See below On Fri, Nov 28, 2008 at 6:26 PM, Radia Perlman wrote: > More re: Ayan Banerjee's comments on protocol-10: > >> >> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear. >> > > How about adding a comma after "controls" How about just simplifying it so it reads: "5. A flag which, if set, indicates that the sender's port was configured as an access port. When it is asserted in Hellos sent by the DRB, all ports on that link act as access ports." >... >> Item 16: Section 4.2.3.3 - (last note - should this must be the >> ext-ckt-id for P2P, and in a lan. This implies >> that we should mandate 3-way handshake for >> P2P links I think the last point (note) can be deleted. >> Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose >> all (see note 3 in the last call) I guess the comments above and below concern the changes in distribution tree determination, etc. See other messages. >> Item 18: Section 4.3 - Distribution tree (see note 3 in last call and >> please see draft-ward) > > Hmm. I don't understand the above comments, probably because I don't > know what "note 5" > and "note 3" are referring to. >> Item 19: Section 4.3.1 - Talk about parallel links and what needs to >> break them I believe the second paragraph of 4.3.1 does that. >> Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address >> and go everywhere) >> > Can you be more specific about your concern? I can't tell, based on > reading the section, what you're asking about. ? Maybe the word "encapsulated" should be inserted so it says "... then the encapsulaed frame is forwarded ...". >> Item 21: Section 4.4.1.2 - Second last paragraph - please change the >> last sentence. > > I think the last sentence you are referring to is: > >>>(Using a unicast >>> Outer.MacDA is of no benefit on a point-to-point link but may result >>> in substantial savings if the link is actually a bridged LAN with >>> many bridged branches and end stations, to all of which the frame may>> >>> get flooded if a multicast destination is used.) > > Not sure what's wrong with it... Actually I think the sentence referred to is "Also, RB1 MUST select a tree that RB1 has announced (in RB1's own LSP) to be one of those that RB1 may choose as a distribution tree or the tree with the highest priority root if none is announced." which is part of the changes for distrbution tree determination, etc >> Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on >> the link (paragraph 2, consider a P2P case). >> Or make a statement, that on a P2P, rbridges >> are automatically AFs. >> > I think this is just a simple clarification. That if it's a P2P case > RBridge-endnode, that the RBridge is automatically an AF... > >> Item 23: Section 4.5 needs more text on forwarding of various classes of >> multicast control plane packets >> some are forwarded using a special address while >> other are flooded. > > Hope Donald understands this one... I'll see what I can do. I think it also need to be a bit clearer about the effect of whether or not the RBridge is an appointed forwarder. >> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. >> > It might be nice to quote the offending text, but I think you are > referring to: > >>> When the appointed forwarder lost counter for RBridge RBn for VLAN-x >>> is observed to increase via the core TRILL IS-IS link state database >>> but RBn continues to be an appointed forwarder for VLAN-x on at least >>> one of its ports, every other RBridge that is an appointed forwarder >>> for VLAN-x modifies the aging of all the addresses it has learned by >>> decapsulating native frames in VLAN-x from ingress RBridge RBn as >>> follows: The time remaining for each entry is adjusted to be no >>> larger than a per RBridge configuration parameter called (to >>> correspond to [802.1Q]) "Forward Delay". > > Hmm. I don't remember that section, and don't remember the purpose of > counting the number of times appointed forwarder status is lost. Wouldn't > the sequence number on the ESADI (together with the CSNP to assure delivery > of the latest ESADI from each RBridge) make is unnecessary to have a > "appointed forwarder lost counter"? The sentence does seem a bit long :-) The provision here has nothing to do with ESADI. The problem is that for remote end station MAC addresses learned from data, RBridges only know what the remote RBridge is, not the remote port. So, assume everything is in the same VLAN X and RBridge A learns some MAC address is attached to RBridge B. If, at some later point, RBridge B advertises that it is no longer connected to VLAN X, RBridge A can forget all those addresses as the path to them is no longer through RBridge B. This is better than bridges do with a topology change, which is just trim the time for MAC address cache entries to the Forwarding Delay. But what if RBridge B has multiple ports where it is appointed forwarder for VLAN X and it loses appointed forwarder status for some but not all of these ports? Some, but not all, of the remote MAC addresses that RBridge A learned as being accessed bia RBridge B are probably invalidated. So RBridge A doesn't want to forget all the MAC addresses it learned from RBridge B. Under these circumstances, it seems like the best you can do is what a bridge would do for a topology change, which is trim MAC timers to the Forwarding Delay. > ... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Sun Jan 4 19:00:33 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 4 Jan 2009 22:00:33 -0500 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <49307783.9010504@sun.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307783.9010504@sun.com> Message-ID: <1028365c0901041900t11b6b48dt3fe28612324ce6a0@mail.gmail.com> Hi Ayan, See a couple of comments below: On Fri, Nov 28, 2008 at 5:58 PM, Radia Perlman wrote: > Re Ayan Banerjee's comments on protocol-10: > > ... > > e) you said: > >>>Item 10: Section 4.2.3.5 - New section -- I think that we are better >>>served with a P2P IIH > > Just to confirm on the mailing list what I asked at the meeting (since sometimes > "off the top of people's head at a meeting" might be incorrect): > > I was worried about sending a P2P IIH and having it misinterpreted. Someone > said that P2P IIHs and multi-access IIHs are different PDU types. Is this correct? Yes. > If so, (or if there is some other way of not getting confused by getting one when > you are expecting the other), it seems OK, but we'd have to look through the > P2P IIH and make sure that all the TRILL information we need is there. I suppose > there is no VLAN information needed, pseudonodes, or information about whether it's > a trunk or access port. maybe there really is no TRILL information needed in > a P2P IIH... > > f) You said you were confused by this sentence: >>>Note that an RBridge RBn does not defer to the >>> DRB listed in a Hello, even if that claimed DRB is higher priority, >>> if the Hello was sent by an RBridge with lower priority than RBn. > > I think that's saying that RB1 might hear a Hello from RB2, wherein RB2 announces > that RB2 thinks RB3 is DRB, and that RB1 should not defer to RB2 unless RB3 > actually hears Hellos from RB3. > That's kind of interesting -- maybe it should... I think that "Note" should be deleted > ... > > Radia Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Sun Jan 4 19:01:33 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 4 Jan 2009 22:01:33 -0500 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> Message-ID: <1028365c0901041901y1731486nc851f34073062d7b@mail.gmail.com> Hi Ayan, On Wed, Nov 26, 2008 at 1:48 PM, Ayan Banerjee (ayabaner) wrote: > ... > > Item 1: Section 1.3, can we change the order of control > frame/trill-frame/native-frame (editing nits) I don't think anyone else reponded to this. Of the five other possible orders, which would you like? I put control frames first because their definition is completely self contained. On the other hand the definitions of TRILL and native frames have some cross referencing and both currently refer to control frames. Of course, there are other ways to re-word this... > ... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Wed Jan 7 08:20:49 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 7 Jan 2009 11:20:49 -0500 Subject: [rbridge] VLAN Mapping -> WG Draft Message-ID: <1028365c0901070820q49061753w7f1e2dd796c44860@mail.gmail.com> Hi, The VLAN mapping draft (draft-perlman-trill-rbridge-vlan-mapping-00.txt) has been out for some time. It was discussed on the WG mailing list and at the last meeting. Opinion seems to be generally favorable so, unless there are significant objections and the ensuing discussion makes it clear that the WG opposed this, we will be making it a WG draft. Donald & Erik ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Thu Jan 8 20:33:31 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 8 Jan 2009 23:33:31 -0500 Subject: [rbridge] draft-ietf-trill-rbridge-protocol-11.txt interim draft Message-ID: <1028365c0901082033vffc0e34g9d8e271cb9b66517@mail.gmail.com> Hi, An interim protocol draft-ietf-trill-rbridge-protocol-11.txt is being posted. It has changes which I believe resolve some the of the WG Last Call comments but not all of them. A -12 draft will be posted later resolving more those comments. draft-ietf-trill-rbridge-protocol-11.txt is being uploaded partly so that IEEE 802.1 will have the latest to look at during their interim meeting next week. (802.1 has been asked to comment on the draft from the point of view of its effect on the Ethernet service model.) Hopefully draft-ietf-trill-rbridge-protocol-11.txt will appear in the internet-draft directories tomorrow. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Internet-Drafts at ietf.org Mon Jan 12 09:45:01 2009 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 12 Jan 2009 09:45:01 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-11.txt Message-ID: <20090112174501.3460428C333@core3.amsl.com> From d3e3e3 at gmail.com Mon Jan 12 18:43:01 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 12 Jan 2009 21:43:01 -0500 Subject: [rbridge] Distribution Trees determination and announcement Message-ID: <1028365c0901121843r5017a186y2bc74adbf63c4cec@mail.gmail.com> I have re-read the mailing list discussion at the end of October and the presentation and minutes from the Minneapolis meeting on the topic of distribution tree root determination and announcement in TRILL. There seemed to be a clear desire for change although not complete agreement on what change to make. I think a change to that described below was the most preferred. Thanks, Donald Each RBridge announces in its LSP (a) a priority, (b) a number, and (c) a list of RBridges in the campus. For the RBridge with the highest priority (ties in the announced priority being broken by system ID): The number announced by this RBridge is the number of distribution trees all RBridges in the campus must also compute minus 1. Assume that number is n-1. If the list being announced is empty, the every RBridge computes a tree rooted at the n highest priority RBridges. If the list has k entries where k is between 1 and n-1, every RBridge computes a tree rooted at the k listed RBridges and enough of the highest priority RBridges not on the list to compute n trees. If k is greater than or equal to n, then every RBridge computes a distribution tree rooted at the first n entries in the announced list. The set of RBridges used as tree roots is considered to be ordered starting with those in the advertised list, if any, followed by those determined by priority with the highest priority first. When an ingress RBridge chooses a distribution tree root for a multi-destination frame, and that RBridge is announcing that j trees should be calculated, it must choose from among the first j (or n if j > n) RBridges in the ordering of roots specified in the above paragraph. If j is zero, it can choose any of the RBridges specified above as distribution tree roots. ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From ayabaner at cisco.com Tue Jan 13 14:10:32 2009 From: ayabaner at cisco.com (Ayan Banerjee) Date: Tue, 13 Jan 2009 14:10:32 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <1028365c0901041901y1731486nc851f34073062d7b@mail.gmail.com> Message-ID: Donald, I believe that the itemized list looks fine and I prefer that order. I was just pointing out that the test in the document before the itemized list has a different order than the itemized list order. To be specific please modify In this document, Layer 2 frames are divided into three categories, TRILL frames, control frames, and native frames, as follows: With In this document, Layer 2 frames are divided into three categories, control frames, TRILL frames, and native frames, as follows: As I had mentioned, just an editing nit. Thanks, Ayan On 1/4/09 7:01 PM, "Donald Eastlake" wrote: > Hi Ayan, > > On Wed, Nov 26, 2008 at 1:48 PM, Ayan Banerjee (ayabaner) > wrote: >> ... >> >> Item 1: Section 1.3, can we change the order of control >> frame/trill-frame/native-frame (editing nits) > > I don't think anyone else reponded to this. Of the five other > possible orders, which would you like? I put control frames first > because their definition is completely self contained. On the other hand > the definitions of TRILL and native frames have some cross referencing > and both currently refer to control frames. Of course, there are other ways > to re-word this... > >> ... > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Tue Jan 13 14:32:36 2009 From: touch at ISI.EDU (Joe Touch) Date: Tue, 13 Jan 2009 14:32:36 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: References: Message-ID: <496D1684.8080605@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a clarification: TRILL control or 802 control? Joe Ayan Banerjee wrote: > Donald, > > I believe that the itemized list looks fine and I prefer that order. I was > just pointing out that the test in the document before the itemized list has > a different order than the itemized list order. To be specific please modify > > > In this document, Layer 2 frames are divided into three categories, > TRILL frames, control frames, and native frames, as follows: > > With > > > In this document, Layer 2 frames are divided into three categories, > control frames, TRILL frames, and native frames, as follows: > > As I had mentioned, just an editing nit. > > Thanks, > Ayan > > > On 1/4/09 7:01 PM, "Donald Eastlake" wrote: > >> Hi Ayan, >> >> On Wed, Nov 26, 2008 at 1:48 PM, Ayan Banerjee (ayabaner) >> wrote: >>> ... >>> >>> Item 1: Section 1.3, can we change the order of control >>> frame/trill-frame/native-frame (editing nits) >> I don't think anyone else reponded to this. Of the five other >> possible orders, which would you like? I put control frames first >> because their definition is completely self contained. On the other hand >> the definitions of TRILL and native frames have some cross referencing >> and both currently refer to control frames. Of course, there are other ways >> to re-word this... >> >>> ... >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-634-2066 (home) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3 at gmail.com >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkltFoQACgkQE5f5cImnZrt0FACfVLzeqxlEiZQPG6aiNrGq/xam x8UAoOtGQYSLpMXUSSvvr/wYoVz+aFbj =SdJO -----END PGP SIGNATURE----- From ayabaner at cisco.com Tue Jan 13 14:56:49 2009 From: ayabaner at cisco.com (Ayan Banerjee) Date: Tue, 13 Jan 2009 14:56:49 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <49307783.9010504@sun.com> Message-ID: Radia and Donald, Apologies for the delayed response. I have aggregated information from the other emails and have clubbed it here. Clarification for EASDI: If my understanding of the draft is accurate, there are possibly 4K vlan-ESADIs and on each node and we are "only" running the CSNP functionality (of traditional IS-IS). The "hello" functionality is not run on them. Consider a router that is interested in all "vlans"; such a router will have to support *all* VLAN-ESADIs. I believe that this is a significant load on the router. I believe that we should have an optional single-ESADI instance as well; this will allow for control-plane learning of unicast MAC addresses in a more scalable fashion. I am fine with having the optional 4K instances also co-exist; but my preference is to have a single instance for unicast MAC distribution. P2P IIHs and LAN IIHs: When TRILL-IS-IS sends out hellos it does so based on the link capability. On P2P links (configured or real ones) it sends P2P IIHs and on multi-access links it sends LAN IIHs. I presume that in TRILL we want to default sending out LAN IIHs (is this accurate?). We should have a section on P2P IIHs and just talk about if any functionality/sub-tlvs are not required for that case (for example, do we need to find a common vlan in P2P like in a LAN - probably not etc). Note that a P2P IIH and LAN IIH will not be bring up and adjacency. Parallel links between rbridges: We need information in the draft that states that we break ties using (a) extended circuit id on P2P links (makes 3-way handshake mandatory) and (b) in a LAN, use lan circuit id. Thanks, Ayan P.S. I have not fully cross-checked with version 11 to see all that has gone in, but I will take a look. Also, I will take a closer look on the hello-AF/AC issue with mis-configurations and get back to you. On 11/28/08 2:58 PM, "Radia Perlman" wrote: > Re Ayan Banerjee's comments on protocol-10: > > a) your concern about spraying of hellos. Indeed there was much > discussion, with viewpoints ranging > from "send Hellos on every VLAN by all RBridges" (which minimizes the > possibility of two RBridges > not noticing each other because of weird bridge configurations) to "only > send Hellos on VLAN 1" (simplicity, > least bandwidth). What is in the spec is a compromise which people > seemed willing to live with. Only > the DRB (once established) sends Hellos on more than one VLAN, and it > can be configured to > send on a smaller set of VLANs than the set it supports. > > Another option which I kind of liked was to have the RBridge attempt to > become bridge Root. And > become DRB if and only if it succeeds in being tree Root. We might want > to revisit that. I happened to > be talking to someone (who hasn't been participating in the WG, but > might be building this) who brought up > that solution as a suggestion instead of spraying with hellos. > > b) differently-configured access and trunk ports: I think all the > scenarios work. It is the DRB that decides > if it is an access port (and therefore prevents any through-traffic by > either setting the overload bit or not > creating a pseudonode). So it doesn't matter what the other RBs think > the port is. And if the DRB > thinks it is a trunk port, it will not assign any designated forwarders. > If the DRB thinks it's a "universal port" (both access and transit), and > some other RBridge believes > it is a trunk port, that other RBridge will not volunteer to be > designated forwarder. No problem. > If the other RBridge thinks it's an access port, then given that the DRB > doesn't claim it's an access port, > its decision is overridden, and it does have to forward. > > c) no nickname necessary if not ingress, egress, or tree root > > We decided this was a good thing in case nicknames became scarce. It > seems totally harmless. Just RB > doesn't include a TLV for nickname if it doesn't want a nickname. > > d) ESADI instances: I couldn't find the place in the spec you point to > (you said 4.1.2). I don't see a scalability > problem if endnodes for each VLAN are announced in separate > announcements. I think the notion of > calling it an "IS-IS instance" (my bad terminology) led to lots of > confusion, ranging from people thinking > that it meant totally separate per-VLAN topologies of the core, to ... > not sure what else. I think we've > decided not to call it an "instance" anymore, but just to redefine the > acronym "ESADI" to be "End System > Advertisement Information". One of the reasons to keep the announcements > in separate packets for > different VLANs is because of VLAN mapping. > > The scalability concerns people have raised for this involve sending > Hellos per VLAN for these ESADI "instances". > But there are no Hellos. There is, however, a CSNP for each VLAN-ESADI. > > e) you said: > >>> Item 10: Section 4.2.3.5 - New section -- I think that we are better >>> served with a P2P IIH > > Just to confirm on the mailing list what I asked at the meeting (since > sometimes > "off the top of people's head at a meeting" might be incorrect): > > I was worried about sending a P2P IIH and having it misinterpreted. Someone > said that P2P IIHs and multi-access IIHs are different PDU types. Is this > correct? > If so, (or if there is some other way of not getting confused by getting one > when > you are expecting the other), it seems OK, but we'd have to look through the > P2P IIH and make sure that all the TRILL information we need is there. I > suppose > there is no VLAN information needed, pseudonodes, or information about whether > it's > a trunk or access port. maybe there really is no TRILL information needed in > a P2P IIH... > > f) You said you were confused by this sentence: >>> Note that an RBridge RBn does not defer to the >>> DRB listed in a Hello, even if that claimed DRB is higher priority, >>> if the Hello was sent by an RBridge with lower priority than RBn. > > I think that's saying that RB1 might hear a Hello from RB2, wherein RB2 > announces > that RB2 thinks RB3 is DRB, and that RB1 should not defer to RB2 unless RB3 > actually hears Hellos from RB3. > That's kind of interesting -- maybe it should... > > I'm sending this in case my email fails, and will try to respond to the rest > of Ayan's comments later. > > Radia > > > > > >> Item 3: Section 2.3.1 - Spraying of hellos, scalability concerns, text >> is unclear Consider the following topology and the following scenarios. >> >> | | | >> RB1--------- RB2 ---------- RB3 >> | | | >> |p1 |p2 |p3 >> >> The Rbi's are connected on the top to a TRILL cloud consisting of only >> Rbridges (for ease of discussion). They are connected on the bottom to >> CE switches/network via ports p1, p2, and p3. >> >> Scenario 1: All ports (p1, p2, and p3) are configured to be access ports >> (as defined in Appendix A of the draft). >> In this case, Rbi's will spray with hellos on all VLANs configured on >> their respective ports. The intent is if a hello is received by other >> Rbi's and an "adjacency" can be formed, then we want to block ports to >> prevent loops. The intent is such a link should not get in the LSP-DB; >> this is inverse of the operation desired with a traditional-isis-hello. >> Only one port remains forwarding and the others are blocked; if so I >> could not figure out from the draft which one is forwarding (is >> system-id etc used as a tie?). Once this is blocked, it remains blocked >> till we "loose" the adjacency again. It is possible that the requirement >> will be to send in the order of 10,000s hellos/per sec per node. This >> solution of spraying poses scalability concerns for the protocol. Also, >> the announcement of the vlan list (however compressed) may not fit >> within the isis-hello-pdu. >> >> Scenario 2: All ports (p1, p2, and p3) are configured to be trunk ports >> (as defined in Appendix A of the draft). >> Once again, Rbi's spray hello on all VLANs. In this case, forming of >> adjacencies is desired, in the sense this links gets in the LSP-DB. Once >> a DRB is elected, only the DRB continues spraying with hellos such that >> future nodes can discover and join the designated vlan to send hellos. >> Nodes other than the DIS after the initial spraying will move to sending >> hellos on the designated vlan only. Question: What happens if the DRB >> does not capture all the vlans, for example RB1 became DRB, but has >> vlans 2,3 on p1 and the others p2 and p3, have vlan 2,3,4. Can a new >> RB4, with vlan 4 configured on it enter this Rbridge LAN and create >> issues? Can we have some text to clearly show the desired operation. >> >> Scenario 3: Some ports are configured to be trunk and some others access >> (could be due to mis-configuration or error in cabling) Not sure what is >> the desired behavior? Are we saying that "adjacency" must not be formed >> with hellos that have the access "AC" bit set, however, must be formed >> with others. If p1 is the only with AC set, then does it "block" or >> "forward" traffic? I believe that the above scenarios needs to be >> addressed in the TRILL base spec. >> >> >> Item 4: Section 3.7.3 - An RBridge that will not act as an ingress, >> egress, or tree root need not have a nickname. >> Do we really want this statement in the base spec ? What if it >> does vlan-mapping, etc. Can we just delete >> this statement from the dradt. >> >> Item 5: Section 4.1 - please replace on Ethernet links with (on >> multi-access links). I am hoping that we can be >> sensitive to running a P2P mode (configured albeit) on Ethernet >> links. >> >> Item 6: Section 4.1.2 - ESADI is a single instance or multiple instances >> per vlan as currently defined. I >> believe that I had raised scalability concerns with ESADI being >> multiple instances. >> >> Item 7: Section 4.1.3 - There is talk about TRILL-IS-IS Hellos and outer >> encapsulation. [This is to be >> removed as per the last call note 2]. >> >> Item 8: Section 4.2.2 - TRILL-IS-IS frames must be ALL-Rbridges >> multicast address (unicast address how?) >> Updates to this section are not in sync with 4.1.3 >> >> Item 9: Section 4.2.3.1 - one rbridge is elected DRB for LAN case, but >> in P2P case there should be no >> such thing. I believe that the confusion could be due to the >> fact >> the base spec talks about TRILL-IS-IS in terms of LAN IIHs, >> however, P2P IIHs (with a config option) >> need to be accounted. We want text in the base protocol spec >> that says that in the event a link >> is configured to be P2P, such DRB election is not needed (as per >> base IS-IS protocol). Also, >> with P2P mode configuration, there need not be any spraying of >> hellos. >> >> Item 10: Section 4.2.3.5 - New section -- I think that we are better >> served with a P2P IIH section in the draft. >> >> Item 11: Section 4.2.3.1.1 - Are Core IS-IS hellos tagged ? Maybe okay >> for LAN, but is this true for P2P >> >> Item 12: Section 4.2.3.1.1 - Last sentence ?? Not sure I follow this, >> can this be re-written please. >> >> Item 13: Section 4.2.3.1.2 - Wording of bullet 5 is unclear. >> >> Item 14: Section 4.2.3.1.2 - Based on feedback from the IS-IS WG should >> we remove this optimization (delete last 3 paras) >> >> Item 15: section 4.2.3.2 - (note 1) - designated vlan to be used for >> trill data frames, does this imply that >> vlans are getting tunneled with a different >> outer vlan-id. Just want to make this >> explicit. >> >> Item 16: Section 4.2.3.3 - (last note - should this must be the >> ext-ckt-id for P2P, and in a lan. This implies >> that we should mandate 3-way handshake for >> P2P links. >> >> Item 17: Section 4.2.3.4 - (note 5) - not announcing allows to choose >> all (see note 3 in the last call) >> >> Item 18: Section 4.3 - Distribution tree (see note 3 in last call and >> please see draft-ward) >> >> Item 19: Section 4.3.1 - Talk about parallel links and what needs to >> break them >> >> Item 20: Section 4.3.4 - (note 3 - how - it will hit the group address >> and go everywhere) >> >> Item 21: Section 4.4.1.2 - Second last paragraph - please change the >> last sentence. >> >> Item 22: Section 4.4.2.2 - the forwarding rbridge need not be a AF on >> the link (paragraph 2, consider a P2P case). >> Or make a statement, that on a P2P, rbridges >> are automatically AFs. >> >> Item 23: Section 4.5 needs more text on forwarding of various classes of >> multicast control plane packets >> some are forwarded using a special address while >> other are flooded. >> >> Item 24: Section 4.6.2 - Last paragraph, first sentence is not clear. >> >> Item 25: Section 4.6.3 - Not sure if mis-configuration detection being >> carried in the LSP is a good idea. >> Assuming that it stays there, I do not see any >> text on what to do when things are >> mis-configured. If this is just a log, I would >> suggest that we take this out-of-band >> and configuration mismatch issues be handled >> separately. >> >> Item 26: Section 4.7.1 - Text is confusing since we are talking about >> creating adjacencies, pseudo-node >> LSPs etc. Please see item 3 above and text >> needs to make the scenarios outlined >> there clearer. >> >> Item 27: Section 4.7.3.3 - Last sentence, do rbridges with access ports, >> run STP ? If not, why not? I am >> guessing that statement is talking about >> trunk ports; if so can we make that >> explicit. >> >> Item 28: Section A.2 - Solution 4 to problem 1- what optional feature? >> >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On >> Behalf Of Erik Nordmark >> Sent: Friday, November 07, 2008 8:48 AM >> To: Developing a hybrid router/bridge. >> Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt >> >> This message begins a working group last call on >> draft-ietf-trill-rbridge-protocol-10.txt. Because of the size of the >> document, it will run for three weeks until Wednesday, November 26th. >> >> There are three issues in connection with this draft that you may wish >> to note: >> 1. A method of doing VLAN mapping was discussed on the working group >> mailing list. This protocol draft is compatible with that method which >> has been written up in draft-perlman-trill-rbridge-vlan-mapping-00. This >> separate draft could be considered for adoption as a working group draft >> and be progressed separately or it could be considered as material to >> add to the protocol draft, perhaps as an appendix. >> 2. The protocol draft does incorporate a change in the encapsulation >> of TRILL IS-IS frames (they are no longer encapsulated but are always >> sent to a different multicast address) and a minor change in the >> encapsulation of TRILL ESADI frames (they have a different new inner >> multicast address). There was discussion of this on the mailing list but >> sufficiently little that it was hard to gauge working group opinion. >> 3. There was discussion on the mailing list of alternatives for >> distribution tree root selection and announcement but no changes along >> these lines were made in the draft. >> >> At least items 1 and 3 above are expected to be discussed at the working >> group meeting in Minneapolis. Should those discussions result in any >> changes to the base draft then we will separately last call those >> changes. >> >> Erik and Donald >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > From d3e3e3 at gmail.com Tue Jan 13 15:15:49 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 13 Jan 2009 18:15:49 -0500 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <496D1684.8080605@isi.edu> References: <496D1684.8080605@isi.edu> Message-ID: <1028365c0901131515g37e3d9fcqc1bb92a7c2894b93@mail.gmail.com> Hi, See below On Tue, Jan 13, 2009 at 5:32 PM, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Just a clarification: > > TRILL control or 802 control? > > Joe They are, in fact, 802 control frames. But the section being referred to is defining what the unqualified term "control frame" means in this document. > Ayan Banerjee wrote: > > Donald, > > > > I believe that the itemized list looks fine and I prefer that order. I was > > just pointing out that the test in the document before the itemized list has > > a different order than the itemized list order. To be specific please modify > > > > In this document, Layer 2 frames are divided into three categories, > > TRILL frames, control frames, and native frames, as follows: > > > > With > > > > In this document, Layer 2 frames are divided into three categories, > > control frames, TRILL frames, and native frames, as follows: OK, I hadn't quite understood your comment. I'll make the change you suggest. Thanks, Donald > > As I had mentioned, just an editing nit. > > > > Thanks, > > Ayan > > > > > > On 1/4/09 7:01 PM, "Donald Eastlake" wrote: > > > >> Hi Ayan, > >> > >> On Wed, Nov 26, 2008 at 1:48 PM, Ayan Banerjee (ayabaner) > >> wrote: > >>> ... > >>> > >>> Item 1: Section 1.3, can we change the order of control > >>> frame/trill-frame/native-frame (editing nits) > >> I don't think anyone else reponded to this. Of the five other > >> possible orders, which would you like? I put control frames first > >> because their definition is completely self contained. On the other hand > >> the definitions of TRILL and native frames have some cross referencing > >> and both currently refer to control frames. Of course, there are other ways > >> to re-word this... > >> > >>> ... > >> Thanks, > >> Donald > >> ============================= > >> Donald E. Eastlake 3rd +1-508-634-2066 (home) > >> 155 Beaver Street > >> Milford, MA 01757 USA > >> d3e3e3 at gmail.com > >> _______________________________________________ > >> rbridge mailing list > >> rbridge at postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkltFoQACgkQE5f5cImnZrt0FACfVLzeqxlEiZQPG6aiNrGq/xam > x8UAoOtGQYSLpMXUSSvvr/wYoVz+aFbj > =SdJO > -----END PGP SIGNATURE----- -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Thu Jan 15 07:51:23 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 15 Jan 2009 10:51:23 -0500 Subject: [rbridge] Drafts and RFC 5378 Message-ID: <1028365c0901150751v325d6602s78ba4bed3b0bd73d@mail.gmail.com> Russ Housley has asked that WG Chairs apprise their WG of the situation with regard to new draft postings and RFC 5378 "Rights Contributors Provide to the IETF Trust". I am doing so by forwarding the message below. This mailing list is, generally speaking, not the appropriate place for the discussion of this issue. It is being discussed on the IETF general list. =============================Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com > From: "Ed Juskevicius" > To: "'IETF Discussion'" , , > , , , > > Date: Thu, 8 Jan 2009 16:43:50 -0500 > Cc: 'Trustees' > Subject: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and > comments on a proposed Work-Around to the Pre-5378 Problem > > The purpose of this message is twofold: > > 1) To summarize the issues that some members of our community > have experienced since the publication of RFC 5378 in November 2008, > and > 2) To invite community review and discussion on a potential work-around > being considered by the IETF Trustees. > > Some I-D authors are having difficulty implementing RFC 5378. An > example of the difficulty is as follows: > > - an author wants to include pre-5378 content in a new submission > or contribution to the IETF, but > - s/he is not certain that all of the author(s) of the earlier > material have agreed to license it to the IETF Trust according > to RFC 5378. > > If an I-D author includes pre-5378 material in a new document, then s/he > must represent or warrant that all of the authors who created the > pre-5378 material have granted rights for that material to the IETF Trust. > If s/he cannot make this assertion, then s/he has a problem. > > This situation has halted the progression of some Internet-Drafts and > interrupted the publication of some RFCs. The Trustees of the IETF Trust > are investigating ways to implement a temporary work-around so that IETF > work can continue to progress. A permanent solution to this "pre-5378 > problem" may require an update to RFC 5378, for example new work by the > community to create a 5378-bis document. > > The remainder of this message provides an outline of the temporary work- > around being considered by the Trustees. > > RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the > authority to develop legend text for authors to use in situations where > they wish to limit the granting of rights to modify and prepare > derivatives of the documents they submit. The Trustees used this > authority in 2008 to develop and adopt the current "Legal Provisions > Relating to IETF Documents" which are posted at: > http://trustee.ietf.org/license-info/. > > The Trustees are now considering the creation of optional new legend text > which could be used by authors experiencing the "pre-5378 problem". > > The new legend text, if implemented, would do the following: > > a. Provide Authors and Contributors with a way to identify (to the > IETF Trust) that their contributions contain material from pre-5378 > documents for which RFC 5378 rights to modify the material outside > the IETF standards process may not have been granted, and > > b. Provide the IETF Trust and the community with a clear indication > of every document containing pre-5378 content and having the > "pre-5378 problem". > > So, how could the creation and use of some new legend text help people > work-around the pre-5378 problem? > > The proposed answer is as follows: > > 1. Anyone having a contribution with the "pre-5378" problem should add > new legend text to the contribution, to clearly flag that it includes > pre-5378 material for which all of the rights needed under RFC 5378 > may not have been granted, and > > 2. The IETF Trust will consider authors and contributors (with the > pre-5378 problem) to have met their RFC 5378 obligations if the > new legend text appears on their documents, and > > 3. Authors and contributors should only resort to adding the new > legend text to their documents (per #1) if they cannot develop > certainty that all of the author(s) of pre-5378 material in > their documents have agreed to license the pre-5378 content to > the IETF Trust according to RFC 5378. > > The proposed wording for the new legend text is now available for your > review and comments in section 6.c.iii of a draft revision to the > IETF Trust's "Legal Provisions Relating to IETF Documents" located at > http://trustee.ietf.org/policyandprocedures.html. > > Please note that the above document also contains new text in section 5.c > dealing with "License Limitations". > > If your review and feedback on this proposed work-around is positive, > then the new text may be adopted by the Trustees in early February 2009, > and then be published as an official revision to the Legal Provisions > document. If so adopted, Internet-Drafts with pre-5378 material may > advance within the Internet standards process and get published as RFCs > where otherwise qualified to do so. Unless covered by sections 6.c.i or > 6.c.ii, authors of documents in which there is no pre-5378 > material must provide a RFC 5378 license with no limitation on > modifications outside the IETF standards process. > > The IETF Trust will not grant the right to modify or prepare derivative > works of any specific RFC or other IETF Contribution outside the IETF > standards process until RFC 5378 rights pertaining to that document have > been obtained from all authors and after compliance by the IETF Trust > with RFC 5377. The Trustees will establish one or more mechanisms by > which authors of pre-5378 documents may grant RFC 5378 rights. > > The Trustees hereby invite your review, comments and suggestions on this > proposed work-around to the "pre-5378 problem". The period for this review > is 30 days. Microsoft WORD and PDF versions of the proposed revisions are > attached to this message. Copies are also available on the IETF Trust > website under the heading "DRAFT Policy and Procedures Being Developed" at: > http://trustee.ietf.org/policyandprocedures.html > > All feedback submitted before the end of February 7th will be considered by > the Trustees. A decision on whether to move forward with this proposal will > be made and communicated to you before the end of February 15th. > > Please give this your attention. > > Regards and Happy New Year ! > > Ed Juskevicius, on behalf of the IETF Trustees > edj.etc at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090115/fd1fd5bc/attachment.html From d3e3e3 at gmail.com Wed Jan 21 23:06:51 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 22 Jan 2009 02:06:51 -0500 Subject: [rbridge] VLAN Mapping -> WG Draft In-Reply-To: <1028365c0901070820q49061753w7f1e2dd796c44860@mail.gmail.com> References: <1028365c0901070820q49061753w7f1e2dd796c44860@mail.gmail.com> Message-ID: <1028365c0901212306m5b1fb16fw911df39fda229042@mail.gmail.com> There having been no objection, a WG Draft version of the VLAN mapping draft will be submitted. Thanks, Donald On Wed, Jan 7, 2009 at 11:20 AM, Donald Eastlake wrote: > Hi, > > The VLAN mapping draft > (draft-perlman-trill-rbridge-vlan-mapping-00.txt) has been out for > some time. It was discussed on the WG mailing list and at the last > meeting. Opinion seems to be generally favorable so, unless there are > significant objections and the ensuing discussion makes it clear that > the WG opposed this, we will be making it a WG draft. > > Donald & Erik > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090122/0335e4bb/attachment.html From harih at cisco.com Sat Jan 24 11:03:18 2009 From: harih at cisco.com (Hari Balasubramanian (harih)) Date: Sat, 24 Jan 2009 11:03:18 -0800 Subject: [rbridge] draft-ietf-trill-rbridge-protocol-11.txt interim draft In-Reply-To: <1028365c0901082033vffc0e34g9d8e271cb9b66517@mail.gmail.com> References: <1028365c0901082033vffc0e34g9d8e271cb9b66517@mail.gmail.com> Message-ID: <1CCF0A858F9B194FABEA71E9B65EA88B084DC9B5@xmb-sjc-214.amer.cisco.com> Hi All, I have been a long time lurker and behind-the-scenes contributor/reviewer of these TRILL documents. I really enjoyed the conversations & discussions both online & offline in the group and I have immensely enjoyed them. I have a few comments on the Version 11 of the draft. I have broadly classified them as typos/editorial issues and other issues. Thanks, Hari Typos & Editorial Issues: ############################## 1. Section 4.2.3.1.2 (Page 32) Do the last three paragraphs in this section really belong to the section which describes "TRILL IS-IS Hello Contents"? 2. Section 4.2.3.3 Under Loop avoidance, second Para, first line: "descrived" should be "described". 3. Section 4.4.2.3.1 (Page 45) First para of this section, fifth line: "know" should be "known". 4. Section 4.7.1 (Page 50) In the last para of Page 50, could not the sentence starting with "If the DRB asserts...." been better phrased? May be there is an "and" missing between "Rbridge access link" and "all Rbridge ports..." 5. Section 4.7.3.2 (Page 53) The first line in this section: "....seen out a port .." , should it not be "....seen at a port..." 6. General Comment: The draft references to other companion TRILL specs. Such sections include Section 3.5, Section 4.2.3.1.3 etc. It would have been nice to provide a reference to those specs in these places. Other Comments: ################## 7. Section 3.7 (Page 22) How should a Rbridge handle a packet which has the "reserved for future" and "permanently reserved" Rbridge nicknames in either the Ingress or Egress Rbridge Nickname fields? 8. Section 3.7.3 (Page 23): Here the spec says that a Rbridge that will not act as ingress, egress or tree root need not have a nickname. I think it is prudent to mandate that all Rbridges must have a nickname. When certain Rbridges do not have a nickname, I am concerned that any future debugging/diagnostic tools may not work well. Is there some real benefits as for a Rbridge not to have a nickname? 9. Section 4.2.3.3 (Page 33) Is root bridge change the only possible event which indicate a potential topology change in bridged networks? 10. Section 4.3.4 (Page 41) The spec says that the TRILL ESADI frames should be treated similar to non-IP-derived multicast addresses and be pruned on basis of Inner.VLAN_ID. Could not the TRILL ESADI frames be further pruned by a Rbridge on the basis of the state it could have built by listening/snooping on ESADI CSNPs etc? ie if a Rbridge knew that there are no other ESADI capable Rbridges for a given vlan behind its link, could it not choose to prune the ESADI packets on that link for that vlan? 11. Section 4.4.2.3.1 (Page 45) Is there a reason why a Rbridge should not prune, if it so chooses, a known unicast packet based on Inner.VLAN? > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake > Sent: Thursday, January 08, 2009 8:34 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] draft-ietf-trill-rbridge-protocol-11.txt > interim draft > > Hi, > > An interim protocol draft-ietf-trill-rbridge-protocol-11.txt > is being posted. It has changes which I believe resolve some > the of the WG Last Call comments but not all of them. A -12 > draft will be posted later resolving more those comments. > > draft-ietf-trill-rbridge-protocol-11.txt is being uploaded > partly so that IEEE 802.1 will have the latest to look at > during their interim meeting next week. (802.1 has been asked > to comment on the draft from the point of view of its effect > on the Ethernet service model.) > > Hopefully draft-ietf-trill-rbridge-protocol-11.txt will > appear in the internet-draft directories tomorrow. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From d3e3e3 at gmail.com Sun Jan 25 20:30:36 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 25 Jan 2009 23:30:36 -0500 Subject: [rbridge] draft-ietf-trill-rbridge-protocol-11.txt interim draft In-Reply-To: <1CCF0A858F9B194FABEA71E9B65EA88B084DC9B5@xmb-sjc-214.amer.cisco.com> References: <1028365c0901082033vffc0e34g9d8e271cb9b66517@mail.gmail.com> <1CCF0A858F9B194FABEA71E9B65EA88B084DC9B5@xmb-sjc-214.amer.cisco.com> Message-ID: <1028365c0901252030p76e834axd5c1c35f79738bcb@mail.gmail.com> Hi, See responses below... On Sat, Jan 24, 2009 at 2:03 PM, Hari Balasubramanian (harih) wrote: > > Hi All, > > I have been a long time lurker and behind-the-scenes > contributor/reviewer of these TRILL documents. I really enjoyed the > conversations & discussions both online & offline in the group and I > have immensely enjoyed them. > > I have a few comments on the Version 11 of the draft. I have broadly > classified them as typos/editorial issues and other issues. > > Thanks, > Hari > > Typos & Editorial Issues: > ############################## > > 1. Section 4.2.3.1.2 (Page 32) > > Do the last three paragraphs in this section really belong to the > section which describes "TRILL IS-IS Hello Contents"? Could be a separate section but does relate to Hello contents. > 2. Section 4.2.3.3 > Under Loop avoidance, second Para, first line: "descrived" should > be "described". Thanks. > 3. Section 4.4.2.3.1 (Page 45) > First para of this section, fifth line: "know" should be "known". OK. > 4. Section 4.7.1 (Page 50) > In the last para of Page 50, could not the sentence starting > with "If the DRB asserts...." been better phrased? May be there is an > "and" missing between "Rbridge access link" and "all Rbridge ports..." Indeed, there should be an "and" there. > 5. Section 4.7.3.2 (Page 53) > The first line in this section: "....seen out a port .." , > should it not be "....seen at a port..." Can't see that much difference. Perhaps more wordy but clearer would be to say "....seen in the BPDUs received at a port...". > 6. General Comment: > The draft references to other companion TRILL specs. Such > sections include Section 3.5, Section 4.2.3.1.3 etc. It would have been > nice to provide a reference to those specs in these places. I have no problem with that for things that are further along in the process than the protocol spec and probably other working group drafts that are behind the spec but it seems a bit of a stretch if its just a personal draft at this point... > Other Comments: > ################## > > > 7. Section 3.7 (Page 22) > How should a Rbridge handle a packet which has the "reserved for > future" and "permanently reserved" Rbridge nicknames in either the > Ingress or Egress Rbridge Nickname fields? They should be discarded if the egress nickname is one of these special values as that means an RBridge would not be able to tell how to forward the frame. It seems like the same should be true if the ingress RBridge is a special value ingress nickname as that at least makes it impossible to perform a Reverse Path Forwarding Check. Unless someone objections, some text will be added saying this. > 8. Section 3.7.3 (Page 23): > Here the spec says that a Rbridge that will not act as ingress, > egress or tree root need not have a nickname. I think it is prudent to > mandate that all Rbridges must have a nickname. When certain Rbridges do > not have a nickname, I am concerned that any future debugging/diagnostic > tools may not work well. Is there some real benefits as for a Rbridge > not to have a nickname? Since the System ID seems more stable than the nickname, I would think that debugging/diagnostic tools should use that. > 9. Section 4.2.3.3 (Page 33) > Is root bridge change the only possible event which indicate a > potential topology change in bridged networks? No, but it is the only topology change event that RBridges need to worry about. Think of it like this: Assume a bridged LAN connected to some RBridges. There are several different cases. If some links inside the bridge LAN go up/down and/or there is some reconfiguration of spanning tree, but connectivity as observed from outside the bridged LAN stays the same, why should connected RBridges care? If one or more bridges or links die in the bridged LAN, some end stations or RBridges may lose connectivity to the bridged LAN or the bridged LAN might partition into two or more pieces. This may orphan some end stations or temporarily interrupt service to some end stations or even cause the campus to partition, but all this seems safe. But, if links or bridges come up merging two bridged LAN, you could have two or more appointed forwarders for the same VLAN at the same time connected to the bridged LAN. This is, in general, disastrous, resulting in network meltdown. Note that this includes the case where one of the merged "bridged LANs" is a single bridge. > 10. Section 4.3.4 (Page 41) > The spec says that the TRILL ESADI frames should be treated > similar to non-IP-derived multicast addresses and be pruned on basis of > Inner.VLAN_ID. Could not the TRILL ESADI frames be further pruned by a > Rbridge on the basis of the state it could have built by > listening/snooping on ESADI CSNPs etc? ie if a Rbridge knew that there > are no other ESADI capable Rbridges for a given vlan behind its link, > could it not choose to prune the ESADI packets on that link for that > vlan? RBridges are required to report their ESADI participation in their LSP. So more pruning complexity for this case could be added. But, to minimize the burden on transit RBridges, it has not so far. > 11. Section 4.4.2.3.1 (Page 45) > Is there a reason why a Rbridge should not prune, if it so > chooses, a known unicast packet based on Inner.VLAN? Pruning only applies to distribution trees. Known unicast frames are just forwarded hop-by-hop to their egress RBridge. There is no tree to prune. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Internet-Drafts at ietf.org Mon Jan 26 14:00:01 2009 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 26 Jan 2009 14:00:01 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-vlan-mapping-00.txt Message-ID: <20090126220001.910B63A6B1A@core3.amsl.com> From d3e3e3 at gmail.com Mon Jan 26 20:34:15 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 26 Jan 2009 23:34:15 -0500 Subject: [rbridge] Distribution Trees determination and announcement In-Reply-To: <1028365c0901121843r5017a186y2bc74adbf63c4cec@mail.gmail.com> References: <1028365c0901121843r5017a186y2bc74adbf63c4cec@mail.gmail.com> Message-ID: <1028365c0901262034w25247cfej35a11ffab65e3641@mail.gmail.com> On actually changing the draft text as described below, it seems to me that it would be better to have each RBridge announce two different numbers in addition to a priority and list of nicknames: one number which is the number of trees all RBridges must calculate if the announcing RBridge is highest priority and a second number which is the number of different trees the announcing RBridge can use. If this second number is zero, then the announcing RBridge can use any of the trees being computed. Possible text is pasted at the far bottom of this message. Thanks, Donald On Mon, Jan 12, 2009 at 9:43 PM, Donald Eastlake wrote: > I have re-read the mailing list discussion at the end of October and > the presentation and minutes from the Minneapolis meeting on the topic > of distribution tree root determination and announcement in TRILL. > There seemed to be a clear desire for change although not complete > agreement on what change to make. I think a change to that described > below was the most preferred. > > Thanks, > Donald > > > Each RBridge announces in its LSP (a) a priority, (b) a number, and > (c) a list of RBridges in the campus. > > For the RBridge with the highest priority (ties in the announced > priority being broken by system ID): > The number announced by this RBridge is the number of > distribution trees all RBridges in the campus must also compute minus > 1. Assume that number is n-1. If the list being announced is empty, > the every RBridge computes a tree rooted at the n highest priority > RBridges. If the list has k entries where k is between 1 and n-1, > every RBridge computes a tree rooted at the k listed RBridges and > enough of the highest priority RBridges not on the list to compute n > trees. If k is greater than or equal to n, then every RBridge computes > a distribution tree rooted at the first n entries in the announced > list. The set of RBridges used as tree roots is considered to be > ordered starting with those in the advertised list, if any, followed > by those determined by priority with the highest priority first. > > When an ingress RBridge chooses a distribution tree root for a > multi-destination frame, and that RBridge is announcing that j trees > should be calculated, it must choose from among the first j (or n if j >> n) RBridges in the ordering of roots specified in the above > paragraph. If j is zero, it can choose any of the RBridges specified > above as distribution tree roots. > > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com In connection with distribution tree determination and selection, each RBridge RBn advertises in the core IS-IS link state database its priority to be chosen as a tree root, a second number k (related to the number of trees to be calculated), a third number j (related to the number of trees to be used by RBn), and an ordered list of RBridge nicknames. The uses of these data items are described below. The priority is a 16-bit unsigned integer that defaults, for a zero configuration RBridge to 0x8000. All RBridge in a campus can be ordered by priority with ties broken by system ID. Numerically lower priority numbers and system IDs are considered higher priority to be a tree root. The highest priority RBridge in the campus dictates the number of distribution trees every RBridges MUST calculate as one plus the second number advertised by that highest priority RBridge. The specific root RBridges for which trees are calculated are determined as follows: 1. Assume that the highest priority RBridge has dictated, through the value of the second number k that it advertises, that distribution trees be calculated for k roots. k is a 16-bit configurable unsigned integer that defaults, for a zero configuration RBridge, to 1. 2. Is the ordered list of nicknames advertised by the highest priority RBridge empty? If so, do 2.a below, if not, do 2.b. 2.a Take the highest priority k+1 nicknames from the ordered list of all campus RBridges and calculate trees rooted at them (or just at all the RBridges in the campus if there are k or fewer of them). 2.b Ignore any nicknames in the ordered list advertised by the highest priority bridge that do not appear in the campus. Take the remaining nicknames in that list and re-order the priority order list of all RBridges by placing these nicknames in the order they are advertised as if they were the highest priority RBridges. Then do 2.a immediately above but using this re-rdered list of all RBridges in the campus. Except during transient conditions, the above method will cause all RBridges to calculate distribution trees for the same set of roots. In order to determine Reverse Path Forwarding Check filters (see Section 4.3.1) for multi-destination frames, each RBridge needs to know what trees every other RBridge might use as root when it is constructing TRILL encapsulated frames. The tree roots that a particular RBridge RBm might use can be determined as follows: 1. Assume that the number j of different roots that RBm would like to choose from in indicated through the value of the third number j that RBm advertises. j is a 16-bit configurable unsigned integer that defaults, for a zero configuration RBridge, to 0. 2. Is the ordered list of nicknames advertised by RBm empty? If so, do 2.a below, if not, do 2.b. 2.a RBm can uses as tree roots only the first j RBridges in the ordered list resulting from the procedure given earlier in this section for determining what trees need be calculated except that, if j is zero or larger than the number of tree roots being calculated, RBm may choose from all trees being caculated for the campus. 2.b Ignore any nicknames in the ordered list advertised by RBm that are not the root of a tree being calculated by all RBridges in the campus. Take the remaining nicknames in that list and re-order the list being used in 2.a immediately above by placing these nicknames first in the order they are advertised by RBm. Then do 2.a immediately above but using this re-ordered list of tree roots. It is RECOMMENDED that RBridges prefer, when constructing TRILL encapsulated multi-destination frames, trees whose roots are low cost from the encapsulating RBridge and, among those with equal cost, to prefer those with higher priority to be a tree root.