From Internet-Drafts at ietf.org Mon Jan 4 10:30:01 2010 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 4 Jan 2010 10:30:01 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-options-00.txt Message-ID: <20100104183001.DE1533A6804@core3.amsl.com> From Radia.Perlman at Sun.COM Wed Jan 6 15:49:57 2010 From: Radia.Perlman at Sun.COM (Radia Perlman) Date: Wed, 06 Jan 2010 15:49:57 -0800 Subject: [rbridge] multiple ports on same link In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893CC24CC94@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893CC24CC94@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <4B4521A5.200@sun.com> Yes, I agree we need such a portId in the hello. Additionally, we might say something like: "If on port pa, you see a Hello with System ID=yours and port = pb, then if pb> pa, stop transmitting anything (including Hellos) on pa (until Listen Time expires on port pa)." Perhaps at some point someone might want to have an implementation that load splits encapsulation/decapsulation (based on VLANs) among such parallel ports, but as long as doing that is invisible to the other RBridges on the link, I don't think we need to specify how to do that. So I think either should do a) just add the field portID in the hello, and not say anything more b) or, in addition to adding the field, saying to stop transmitting anything on all but one of such parallel ports, with something like the wording above. Radia Jeff Pickering wrote: > > > > RB1 might have > > one set of ports, say { p1, p2, p3 } on one link, and another set of > > ports { p4, p5 } on a second link, and yet other ports, say p6, p7, > > p8, that are each on distinct links. Let us call a set of ports on > > the same link as a "port group". > > > > Ports dont know which port group they are in a-priori since this is > determined > > by external connectivity. Port group membership can only be determined by > > examination of received pdus. > > But since the hello pdus sent out all ports are currently identical, > (if all > > ports have the same mac, which is most common), there is no way for a > port to > > determine which "port group" it is in. > > If we add a portId, like in a bpdu, to the trill hello this problem > could be solved. > > The spec currently doesnt mention such an identifier. What is the > thinking here? > > > > Jeff > > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From jrrivers at cumulusnetworks.com Wed Jan 6 19:51:10 2010 From: jrrivers at cumulusnetworks.com (JR Rivers) Date: Wed, 6 Jan 2010 19:51:10 -0800 Subject: [rbridge] multiple ports on same link In-Reply-To: <4B4521A5.200@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893CC24CC94@SJEXCHCCR02.corp.ad.broadcom.com> <4B4521A5.200@sun.com> Message-ID: <904694BA-DF4A-419A-B5CF-79B997C43BF4@cumulusnetworks.com> Seems like you'd just add the portId... that way the parallel links can be used as part of the ECMP. Clearly, if there is 802.3ad trunking occurring on the links, they would be reported as a single logical link. JR On Jan 6, 2010, at 3:49 PM, Radia Perlman wrote: > Yes, I agree we need such a portId in the hello. > > Additionally, we might say something like: > > "If on port pa, you see a Hello with System ID=yours and port = pb, > then if pb> pa, stop > transmitting anything (including Hellos) on pa (until Listen Time > expires on port pa)." > > Perhaps at some point someone might want to have an implementation that > load splits encapsulation/decapsulation (based on VLANs) among such parallel ports, > but as long as doing that is invisible to the other RBridges on the link, I don't > think we need to specify how to do that. > > So I think either should do > > a) just add the field portID in the hello, and not say anything more > b) or, in addition to adding the field, saying to stop transmitting > anything on all but one of such parallel ports, with something like > the wording above. > > Radia > > > > > > Jeff Pickering wrote: >> >> >> >> RB1 might have >> >> one set of ports, say { p1, p2, p3 } on one link, and another set of >> >> ports { p4, p5 } on a second link, and yet other ports, say p6, p7, >> >> p8, that are each on distinct links. Let us call a set of ports on >> >> the same link as a "port group". >> >> >> >> Ports dont know which port group they are in a-priori since this is >> determined >> >> by external connectivity. Port group membership can only be determined by >> >> examination of received pdus. >> >> But since the hello pdus sent out all ports are currently identical, >> (if all >> >> ports have the same mac, which is most common), there is no way for a >> port to >> >> determine which "port group" it is in. >> >> If we add a portId, like in a bpdu, to the trill hello this problem >> could be solved. >> >> The spec currently doesnt mention such an identifier. What is the >> thinking here? >> >> >> >> Jeff >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Fri Jan 8 13:31:30 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 8 Jan 2010 16:31:30 -0500 Subject: [rbridge] multiple ports on same link In-Reply-To: <4B4521A5.200@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893CC24CC94@SJEXCHCCR02.corp.ad.broadcom.com> <4B4521A5.200@sun.com> Message-ID: <1028365c1001081331o3f479814y3dd4a9290f345d5f@mail.gmail.com> To be specific, I suggest adding an item to the list of data which must be included in a TRILL Hello (Section 4.4.2) such as: "A 16-bit port ID assigned by the sending RBridge to the port the TRILL-Hello is sent on such that no two ports of that RBridge have the same port ID." Then adding at the end of Section 4.4.4: "If an RBridge has more than one port connected to a link and those ports have the same MAC address, they can be distinguished by the port ID contain in TRILL-Hellos." Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Wed, Jan 6, 2010 at 6:49 PM, Radia Perlman wrote: > Yes, I agree we need such a portId in the hello. > > Additionally, we might say something like: > > "If on port pa, you see a Hello with System ID=yours and port = pb, > then if pb> pa, stop > transmitting anything (including Hellos) on pa (until Listen Time > expires on port pa)." > > Perhaps at some point someone might want to have an implementation that > load splits encapsulation/decapsulation (based on VLANs) among such > parallel ports, > but as long as doing that is invisible to the other RBridges on the link, I > don't > think we need to specify how to do that. > > So I think either should do > > a) just add the field portID in the hello, and not say anything more > b) or, in addition to adding the field, saying to stop transmitting > anything on all but one of such parallel ports, with something like > the wording above. > > Radia > > > > > > Jeff Pickering wrote: > > > > > > > > RB1 might have > > > > one set of ports, say { p1, p2, p3 } on one link, and another set of > > > > ports { p4, p5 } on a second link, and yet other ports, say p6, p7, > > > > p8, that are each on distinct links. Let us call a set of ports on > > > > the same link as a "port group". > > > > > > > > Ports dont know which port group they are in a-priori since this is > > determined > > > > by external connectivity. Port group membership can only be determined by > > > > examination of received pdus. > > > > But since the hello pdus sent out all ports are currently identical, > > (if all > > > > ports have the same mac, which is most common), there is no way for a > > port to > > > > determine which "port group" it is in. > > > > If we add a portId, like in a bpdu, to the trill hello this problem > > could be solved. > > > > The spec currently doesnt mention such an identifier. What is the > > thinking here? > > > > > > > > Jeff > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100108/e0f66386/attachment.html From d3e3e3 at gmail.com Sun Jan 10 12:53:33 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 10 Jan 2010 15:53:33 -0500 Subject: [rbridge] Fwd: Gen-ART review of draft-ietf-trill-rbridge-protocol-14 In-Reply-To: <1028365c1001101249w7d98396aq3369dbb6ddaf2797@mail.gmail.com> References: <274D46DDEB9F2244B2F1EA66B3FF54BC0611A892@de01exm70.ds.mot.com> <1028365c1001101249w7d98396aq3369dbb6ddaf2797@mail.gmail.com> Message-ID: <1028365c1001101253l3402c20ese9ea2e862abeafb2@mail.gmail.com> Hi, We received a GenART (General Area Review Team) review and, wearing my hat a document editor, I have responded as below. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com ---------- Forwarded message ---------- From: Donald Eastlake Date: Sun, Jan 10, 2010 at 3:49 PM Subject: Re: Gen-ART review of draft-ietf-trill-rbridge-protocol-14 To: McCann Peter-A001034 Cc: gen-art at ietf.org, draft-ietf-trill-rbridge-protocol.all at tools.ietf.org Hi Peter, Thanks for the detailed review. See below, On Thu, Jan 7, 2010 at 3:13 PM, McCann Peter-A001034 < pete.mccann at motorola.com> wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html > ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-trill-rbridge-protocol-14 > Reviewer: Pete McCann > Review Date: 2010-01-08 > IETF LC End Date: 2010-01-11 > IESG Telechat date: unknown > > Summary: Basically ready, a few minor issues & nits. > > Major issues: None. > Thanks! > Minor issues: > > Section 4.1.4: > This text seems to imply that the FCS of the inner, native frame is > removed and only a single FCS covering the encapsulated frame is > generated. However, it is not quite clear to me which behavior > is intended. Could you add text to clarify? > You are correct in your interpretation. I suggest adding, after the first sentence of the first paragarph in 4.1.4, the following: "Thus, when a frame is encapsulated, the original FCS is not included but is discarded." > Section 4.5: > The k trees are ordered from 1 to k, with up to k of the s trees > advertised by RB1 given tree numbers 1 through s, respectively, and > any remaining trees given numbers in order of priority. > Is this worded correctly? Should it say: > The k trees are ordered from 1 to k, with up to s of the k trees > advertised by RB1 given tree numbers 1 through s, respectively, and > any remaining trees given numbers in order of priority. > The wording is certainly confusing. There are a total of k trees campus wide. RB1 can advertise a list of trees to calculate which could be a list of less than k, exactly k, or more than k. s is the number of trees to calculate advertised by RB1. The numbering of a tree is significant for some multipathing computations. There is also a priority ordering of all possible trees, but the list of trees to calculate advertised by RB1 overrides that priority ordering. So, if is k less than or equal to s, then the first k trees advertised by RB1 are calculated and numbered 1 through k. If k > s, then all trees advertised by RB1 are calculated and numbered 1 through s. And an additional (s - k) tree are calculated and numbered s+1 ... through k. Which trees are computed is actually explained above the text you mention. The text you mention is just about tree numbering / ordering. I suggest replacing the paragraph just before the 4.5.1 section heading with the following: "The k trees calculated for a campus are ordered and numbered from 1 to k. In addition to advertising the number k, RB1 might explicitly advertise a set of s trees by providing a list of s nicknames that are the root of the trees. - If s == k, then the trees are numbered in the order of RB1 advertises them. - If s == 0, then the trees are numbered in order of decreasing priority. For example, if RB1 advertises only that k=2, then the highest priority tree is number 1 and the 2nd highest priority tree is number 2. - If s < k, then those advertised by RB1 are numbered from 1 in the order advertised. Then the remainder are chosen by priority order from among the remaining possible trees with the numbering continuing. For example, if RB1 advertises k=4, advertises {Tx, Ty} as the nicknames of the root of the trees, and the campus wide priority ordering of trees in decreasing order is Ty > Ta > Tc > Tb > Tx, the numbering will be as follows: Tx is 1 and Ty is 2 since that is the order they are advertised in by RB1. Then Ta is 3 and Tc is 4 because they are the highest priority trees that have not already been numbered." Section 4.5.5: > The bullets in this section say, "forwarded onto > adjacencies in the nickname1 tree" but don't explicitly > say that you shouldn't forward onto the adjacency on which > the packet arrived. > Yes. Since it seems like it would be a bit verbose to add this qualification in the many cases where there are references to adjacencies in this bulleted list, I suggest the following. Replace the ":" at the end of the first sentence in 4.5.5 with a period and add the following sentence after it: "References to adjacencies below do not include the adjacency on which a frame was received." > Section 7.2: > Have you made arrangements with IEEE to get these values? They > normally charge a fee for new Ethertypes. > We are presently working on the applications, but they have not been submitted. Our understanding is that it is the policy of the IEEE RAC (Registration Authority Committee) to, on a case-by-case basis, grant code points for standards use to standards development organizations free of charge. For one type of allocation, a standards use multicast address, they even have a standard form to use for this purpose: http://standards.ieee.org/regauth/registry_stdgroupmac.html > Nits/editorial comments: > On the items below, unless I comment otherwise, I agree. > Section 3.5: > > To ensure backward compatible safe operation, when Op-Length is non- > zero indicating that options are present, the top two bits of the > first octet of the options area are specified as follows: > > +------+------+----+----+----+----+----+----+ > | CHbH | CItE | Reserved | > +------+------+----+----+----+----+----+----+ > > Figure 3.2: Options Area Initial Flags Octet > > The diagram shows a 6-bit Reserved field, but the text says "the top > two bits ... are specified". The text doesn't mention the Reserved > field after this. Should you specify that Reserved is set to zero > at Ingress, copied on Transit, and ignored on Egress, like you did > in Section 3.3? And in that case say "the first byte"? > The idea is to push as much as possible off to a different draft and only put in the minimum hooks in the main protocol document. That different draft is now a working group document at http://tools.ietf.org/html/draft-ietf-trill-rbridge-options-00 I suggest that, at the beginning of the third paragraph below the above figure, the first sentence be changed so that instead of starting "Options will be further specified in other documents...", it would start "Options, including the meaning of the bits labeled as Reserved in Figure 3.2, will be further specified in other documents...". > Section 3.7.2: > This simplifies end node learning > Missing a period here? There is also a blank line after this one, > is something else missing? > Yes, there is a missing period. But I've checked and nothing else is missing. > Section 4.1.2: > TRILL data frame with the associated VLAN ID and priority placed in > the Inner.VLAN information. > Should it also copy the C bit? > No, as specified above in the draft, the C bit is always zero in TRILL. > Section 4.2.4.3: > in the VLAN for which it is appointed > Missing period? > Yes. > 30 second > SHOULD BE: > 30 seconds > > Section 4.5: > as describe below > SHOULD BE: > as described below > > Section 4.6.2.4: > know unicast > SHOULD BE: > known unicast > > Section 4.8.1: > to not learn > SHOULD BE: > not to learn > I don't actually see anything wrong with the current wording but I'm willing to change it. > Section 4.9.1: > ports an > enabled. > SHOULD BE: > ports are > enabled. > > Section 4.9.2: > There is a reference to Figure 4.7 but the figure in this section is > labeled 4.5. > Good catch, thanks. > Section 6: > Layer 2 bridging in not inherently secure. > SHOULD BE: > Layer 2 bridging is not inherently secure. > > Section 6.2: > although this processing > SHOULD BE: > and this processing > I think the current wording is better. > Appendix B: > on such as link as it > SHOULD BE: > on such a link as it > Thanks! Donald ============================= 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/20100110/269c8026/attachment.html From d3e3e3 at gmail.com Sun Jan 17 17:49:18 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 17 Jan 2010 20:49:18 -0500 Subject: [rbridge] 'IANA Considerations for Network Layer Protocol Identifiers' to BCP Message-ID: <1028365c1001171749w44fe018fy9cc990c8cdc6db98@mail.gmail.com> The BCP mentioned below memorializes the allocation of 0xC0 as the NLPID for TRILL. Although not directly referenced in the TRILL base protocol, this would be used, for example, in the IS-IS Protocols Supported TLV. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com ---------- Forwarded message ---------- From: The IESG Date: Wed, Jan 13, 2010 at 1:40 PM Subject: Protocol Action: 'IANA Considerations for Network Layer Protocol Identifiers' to BCP To: IETF-Announce Cc: Internet Architecture Board , RFC Editor < rfc-editor at rfc-editor.org> The IESG has approved the following document: - 'IANA Considerations for Network Layer Protocol Identifiers ' as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-nlpid-iana-considerations-04.txt Technical Summary Network Layer Protcol IDs (NLPIDs) are used in a number of protocols that the IETF has specified or is extending. Examples include the NBMA Next Hop Resolution Protocol and the IS-IS Protocols Supported TLV. The registry of these values is maintained by ISO/IEC. This document provides the IANA Considerations procedures for originating and documenting the allocation of an NLPID from within the IETF. Working Group Summary This document was not produced by an IETF working group but is supported by a clear consensus of the community of interest. Document Quality The document has been reviewed by the IETF TRILL and IS-IS working group chairs, the Internet and Routing ADs, the IETF Chair, the Editor of IEEE P802.1aq, IANA, the IETF Liaison to ISO/IEC JTC1 SC6, and other technical experts. Document quality is high. Personnel Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. Please add the following to the first paragraph in Section 2.3 "One byte code points are assigned to TRILL and IEEE 802.1aq as they are intended for use within the IS-IS Protocols Supported TLV [RFC1195]." 2. In Section 3: OLD: As long as code points are available, IANA will allocate additional values when required by an IETF Standards Action. NEW: As long as code points are available, IANA will allocate additional values when required by applying IETF Review policy as per [RFC5226]. 3. Move [TRILL] from Informative to Normative References _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100117/cb2e2b2a/attachment.html From d3e3e3 at gmail.com Mon Jan 18 18:25:46 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 18 Jan 2010 21:25:46 -0500 Subject: [rbridge] test message Message-ID: <1028365c1001181825h46dc932av19a4125325113dfc@mail.gmail.com> Test message, please ignore. Donald ============================= 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/20100118/bd3979cc/attachment.html From d3e3e3 at gmail.com Sat Jan 16 16:30:15 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 16 Jan 2010 19:30:15 -0500 Subject: [rbridge] Protocol Action: 'IANA Considerations for Network Layer Protocol Identifiers' to BCP In-Reply-To: <1028365c1001131104j5b1e2b32nf4125ad32ae5aa86@mail.gmail.com> References: <20100113184014.685E83A69F4@core3.amsl.com> <1028365c1001131104j5b1e2b32nf4125ad32ae5aa86@mail.gmail.com> Message-ID: <1028365c1001161630o2393ade8nff6a35b93d1322fb@mail.gmail.com> The BCP mentioned below memorializes the allocation of 0xC0 as the NLPID for TRILL. Although not directly referenced in the TRILL base protocol, this would be used, for example, in the IS-IS Protocols Supported TLV. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com ---------- Forwarded message ---------- From: The IESG Date: Wed, Jan 13, 2010 at 1:40 PM Subject: Protocol Action: 'IANA Considerations for Network Layer Protocol Identifiers' to BCP To: IETF-Announce Cc: Internet Architecture Board , RFC Editor < rfc-editor at rfc-editor.org> The IESG has approved the following document: - 'IANA Considerations for Network Layer Protocol Identifiers ' as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-nlpid-iana-considerations-04.txt Technical Summary Network Layer Protcol IDs (NLPIDs) are used in a number of protocols that the IETF has specified or is extending. Examples include the NBMA Next Hop Resolution Protocol and the IS-IS Protocols Supported TLV. The registry of these values is maintained by ISO/IEC. This document provides the IANA Considerations procedures for originating and documenting the allocation of an NLPID from within the IETF. Working Group Summary This document was not produced by an IETF working group but is supported by a clear consensus of the community of interest. Document Quality The document has been reviewed by the IETF TRILL and IS-IS working group chairs, the Internet and Routing ADs, the IETF Chair, the Editor of IEEE P802.1aq, IANA, the IETF Liaison to ISO/IEC JTC1 SC6, and other technical experts. Document quality is high. Personnel Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. Please add the following to the first paragraph in Section 2.3 "One byte code points are assigned to TRILL and IEEE 802.1aq as they are intended for use within the IS-IS Protocols Supported TLV [RFC1195]." 2. In Section 3: OLD: As long as code points are available, IANA will allocate additional values when required by an IETF Standards Action. NEW: As long as code points are available, IANA will allocate additional values when required by applying IETF Review policy as per [RFC5226]. 3. Move [TRILL] from Informative to Normative References _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100116/aba4c19d/attachment.html From erik.nordmark at sun.com Wed Jan 20 11:10:33 2010 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 20 Jan 2010 11:10:33 -0800 Subject: [rbridge] Fwd: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol Message-ID: <4B575529.8020606@sun.com> -------- Original Message -------- Subject: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol Date: Wed, 20 Jan 2010 00:24:05 -0800 (PST) From: Pasi Eronen To: iesg at ietf.org CC: trill-chairs at tools.ietf.org, draft-ietf-trill-rbridge-protocol at tools.ietf.org Discuss: I have reviewed draft-ietf-trill-rbridge-protocol-14, and have one questions that I'd like to discuss before recommending approval of the document: Section 4.7 says "RBridges do not need to announce themselves as listeners to the All-Snoopers multicast group (the group used for MRD reports [RFC4541]), because the IP multicast address for that group is in the range where all frames sent to that IP multicast addresses must be broadcast." Isn't this true only for IPv4, but not IPv6? (RFC 4541 seems to broadcast 224.0.0.106, but not FF02::6A) Comment: I found the document surprisingly well-written and easy to understand (despite the complex topic). From d3e3e3 at gmail.com Wed Jan 20 12:22:05 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 20 Jan 2010 15:22:05 -0500 Subject: [rbridge] Fwd: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol In-Reply-To: <4B575529.8020606@sun.com> References: <4B575529.8020606@sun.com> Message-ID: <1028365c1001201222n6a13133cy9354df7dc0a247c2@mail.gmail.com> See below, On Wed, Jan 20, 2010 at 2:10 PM, Erik Nordmark wrote: > > -------- Original Message -------- > Subject: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol > Date: Wed, 20 Jan 2010 00:24:05 -0800 (PST) > From: Pasi Eronen > To: iesg at ietf.org > CC: trill-chairs at tools.ietf.org, > draft-ietf-trill-rbridge-protocol at tools.ietf.org > > Discuss: > I have reviewed draft-ietf-trill-rbridge-protocol-14, and have one > questions that I'd like to discuss before recommending approval of > the document: > > Section 4.7 says "RBridges do not need to announce themselves as > listeners to the All-Snoopers multicast group (the group used for MRD > reports [RFC4541]), because the IP multicast address for that group is > in the range where all frames sent to that IP multicast addresses must > be broadcast." > > Isn't this true only for IPv4, but not IPv6? (RFC 4541 seems to > broadcast 224.0.0.106, but not FF02::6A) > I've looked at the relevant RFCs and I believe Pasi is correct. It should say something like "RBridges does not need to announce themselves as listeners to the IPv4 All-Snoopers multicast group (the group used for MRD reports [RFC4541]), because the IPv4 multicast address for that group is in the range where all frames sent to that IP multicast addresses must be broadcast. However, RBridges the implement IPv6 derived multicast optimization MUST announce themselves as listeners to the IPv6 All-Snoopers multicast group." Does any have a problem with that wording? > Comment: > I found the document surprisingly well-written and easy to > understand (despite the complex topic). > Thanks, Donald ============================= 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/20100120/cc270af7/attachment.html From d3e3e3 at gmail.com Wed Jan 20 13:00:48 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 20 Jan 2010 16:00:48 -0500 Subject: [rbridge] Fwd: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol In-Reply-To: <1028365c1001201222n6a13133cy9354df7dc0a247c2@mail.gmail.com> References: <4B575529.8020606@sun.com> <1028365c1001201222n6a13133cy9354df7dc0a247c2@mail.gmail.com> Message-ID: <1028365c1001201300y329eeb65j81e5ffcf3c1ff86d@mail.gmail.com> Sorry for a couple of typos fixed below... On Wed, Jan 20, 2010 at 3:22 PM, Donald Eastlake wrote: > See below, > > On Wed, Jan 20, 2010 at 2:10 PM, Erik Nordmark wrote: >> >> -------- Original Message -------- >> Subject: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol >> Date: Wed, 20 Jan 2010 00:24:05 -0800 (PST) >> From: Pasi Eronen >> To: iesg at ietf.org >> CC: trill-chairs at tools.ietf.org, >> draft-ietf-trill-rbridge-protocol at tools.ietf.org >> >> Discuss: >> I have reviewed draft-ietf-trill-rbridge-protocol-14, and have one >> questions that I'd like to discuss before recommending approval of >> the document: >> >> Section 4.7 says "RBridges do not need to announce themselves as >> listeners to the All-Snoopers multicast group (the group used for MRD >> reports [RFC4541]), because the IP multicast address for that group is >> in the range where all frames sent to that IP multicast addresses must >> be broadcast." >> >> Isn't this true only for IPv4, but not IPv6? (RFC 4541 seems to >> broadcast 224.0.0.106, but not FF02::6A) >> > > > I've looked at the relevant RFCs and I believe Pasi is correct. It should > say something like > > "RBridges does not need to announce themselves as listeners to the IPv4 > All-Snoopers multicast > does -> do > group (the group used for MRD reports [RFC4541]), because the IPv4 > multicast address for that group is in the range where all frames sent to > that IP multicast addresses must be broadcast. However, RBridges the > implement IPv6 derived multicast optimization MUST announce > the -> that > themselves as listeners to the IPv6 All-Snoopers multicast group." > > Does any have a problem with that wording? > > >> Comment: >> I found the document surprisingly well-written and easy to >> understand (despite the complex topic). >> > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > Thanks, Donald -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100120/fadd4cc7/attachment.html From d3e3e3 at gmail.com Thu Jan 21 08:15:49 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 21 Jan 2010 11:15:49 -0500 Subject: [rbridge] Fwd: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol In-Reply-To: <1028365c1001201300y329eeb65j81e5ffcf3c1ff86d@mail.gmail.com> References: <4B575529.8020606@sun.com> <1028365c1001201222n6a13133cy9354df7dc0a247c2@mail.gmail.com> <1028365c1001201300y329eeb65j81e5ffcf3c1ff86d@mail.gmail.com> Message-ID: <1028365c1001210815u64629879p441dda2e39b8fc9e@mail.gmail.com> Hi, I've received a comment that MRD (multicast router discovery) is actually specified in RFC 4286. Also, the "MUST announce" should depend on whether an RBridge is actually doing IPv6 multicast optimization, not just on whether the RBridge has implemented it. Incorporating these changes, the text would read: "RBridges do not need to announce themselves as listeners to the IPv4 All-Snoopers multicast group (the group used for MRD reports [RFC4286]), because the IPv4 multicast address for that group is in the range where all frames sent to that IP multicast addresses must be broadcast (see [RFC4541], Section 2.1.2). However, RBridges that are performing IPv6 derived multicast optimization MUST announce themselves as listeners to the IPv6 All-Snoopers multicast group." Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Wed, Jan 20, 2010 at 4:00 PM, Donald Eastlake wrote: > Sorry for a couple of typos fixed below... > > On Wed, Jan 20, 2010 at 3:22 PM, Donald Eastlake wrote: > >> See below, >> >> On Wed, Jan 20, 2010 at 2:10 PM, Erik Nordmark wrote: >>> >>> -------- Original Message -------- >>> Subject: DISCUSS and COMMENT: draft-ietf-trill-rbridge-protocol >>> Date: Wed, 20 Jan 2010 00:24:05 -0800 (PST) >>> From: Pasi Eronen >>> To: iesg at ietf.org >>> CC: trill-chairs at tools.ietf.org, >>> draft-ietf-trill-rbridge-protocol at tools.ietf.org >>> >>> Discuss: >>> I have reviewed draft-ietf-trill-rbridge-protocol-14, and have one >>> questions that I'd like to discuss before recommending approval of >>> the document: >>> >>> Section 4.7 says "RBridges do not need to announce themselves as >>> listeners to the All-Snoopers multicast group (the group used for MRD >>> reports [RFC4541]), because the IP multicast address for that group is >>> in the range where all frames sent to that IP multicast addresses must >>> be broadcast." >>> >>> Isn't this true only for IPv4, but not IPv6? (RFC 4541 seems to >>> broadcast 224.0.0.106, but not FF02::6A) >>> >> >> >> I've looked at the relevant RFCs and I believe Pasi is correct. It should >> say something like >> >> "RBridges does not need to announce themselves as listeners to the IPv4 >> All-Snoopers multicast >> > > does -> do > > >> group (the group used for MRD reports [RFC4541]), because the IPv4 >> multicast address for that group is in the range where all frames sent to >> that IP multicast addresses must be broadcast. However, RBridges the >> implement IPv6 derived multicast optimization MUST announce >> > > the -> that > > >> themselves as listeners to the IPv6 All-Snoopers multicast group." >> >> Does any have a problem with that wording? >> >> >>> Comment: >>> I found the document surprisingly well-written and easy to >>> understand (despite the complex topic). >>> >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-634-2066 (home) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3 at gmail.com >> > > Thanks, > Donald > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100121/7708a173/attachment.html From Internet-Drafts at ietf.org Fri Jan 22 16:15:02 2010 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri, 22 Jan 2010 16:15:02 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-15.txt Message-ID: <20100123001502.4B32C3A690F@core3.amsl.com> From d3e3e3 at gmail.com Sat Jan 23 08:34:58 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 23 Jan 2010 11:34:58 -0500 Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-15.txt In-Reply-To: <20100123001502.4B32C3A690F@core3.amsl.com> References: <20100123001502.4B32C3A690F@core3.amsl.com> Message-ID: <1028365c1001230834oaaf96f2q76f085ab1ee4e359@mail.gmail.com> Hi, The changes between -14 and -15 of the base protocol specification are relatively minor and are listed in the Change History section of the draft. The three most significant are the following, the first two of which are technical changes: - Addition of a Port ID in the TRILL Hello as mentioned at http://www.postel.org/pipermail/rbridge/2010-January/003854.html - Change related to announcing membership in the IPv6 All-Snoopers group as mentioned at http://www.postel.org/pipermail/rbridge/2010-January/003862.html - Addition of a normative reference to the draft-ietf-isis-layer2 draft in two places. Thanks, Donald On Fri, Jan 22, 2010 at 7:15 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transparent Interconnection of Lots of > Links Working Group of the IETF. > > Title : Rbridges: Base Protocol Specification > Author(s) : D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani, R. > Perlman > Filename : draft-ietf-trill-rbridge-protocol-15.txt > Pages : 113 > Date : 2010-1-22 > > RBridges provide optimal pair-wise forwarding without configuration, > safe forwarding even during periods of temporary loops, and support > for multipathing of both unicast and multicast traffic. They achieve > these goals using IS-IS routing and encapsulation of traffic with a > header that includes a hop count. > > RBridges are compatible with previous IEEE 802.1 customer bridges as > well as IPv4 and IPv6 routers and end nodes. They are as invisible to > current IP routers as bridges are and, like routers, they terminate > the bridge spanning tree protocol. > > The design supports VLANs and optimization of the distribution of > multi-destination frames based on VLAN and IP derived multicast > groups. It also allows unicast forwarding tables at transit RBridges > to be sized according to the number of RBridges (rather than the > number of end nodes), which allows their forwarding tables to be > substantially smaller than in conventional customer bridges. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-15.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100123/2e0e51bf/attachment.html From david.bond at iol.unh.edu Thu Jan 28 08:46:20 2010 From: david.bond at iol.unh.edu (David Michael Bond) Date: Thu, 28 Jan 2010 11:46:20 -0500 Subject: [rbridge] Draft Ordering Clarification Message-ID: <000901caa039$6afa5090$40eef1b0$@bond@iol.unh.edu> Hello Everyone, I had a question about the current draft. Consider section 4.5.1. This section says "After calculating the entire "tree" (actually, directed graph), for each node N, if N has "p" parents, then order the parents according to 7-octet IS-IS ID." I assume this ordering is low to high but the draft should probably clarify this. I suggest wording it "After calculating the entire "tree" (actually, directed graph), for each node N, if N has "p" parents, then order the parents ***ascending*** according to 7-octet IS-IS ID." My change highlighted with ***. Thanks, David David Bond???????????????? .~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~. .University of New Hampshire????????????????????? . .??? - InterOperability Laboratory ???????????????. .??????? Research and Development Software Eng.? ?. . Routing & Bridge Functions Consortiums . .??? - Computer Science PhD Student ???????? ??? . . 121 Technology Drive, Suite 2, Durham NH, 03824 . . (O) 1-603-862-3525 (M) 1-603-845-7514 . .~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~.? From d3e3e3 at gmail.com Fri Jan 29 12:17:34 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 29 Jan 2010 15:17:34 -0500 Subject: [rbridge] Draft Ordering Clarification In-Reply-To: <-4166893862794107503@unknownmsgid> References: <-4166893862794107503@unknownmsgid> Message-ID: <1028365c1001291217o3fe03f53o82bf8a4aa977f25c@mail.gmail.com> Hi David, I agree. In fact, perhaps it should says "... ascending according to 7-octet IS-IS ID treated as an unsigned integer." There may be one or two other places where it would be good to say that the IS-IS system ID is an unsigned integer. For example, at the end of the first paragraph of 4.2.5.1. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Jan 28, 2010 at 11:46 AM, David Michael Bond wrote: > Hello Everyone, > I had a question about the current draft. Consider section 4.5.1. This > section says "After calculating the entire "tree" (actually, directed > graph), for each node N, if N has "p" parents, then order the parents > according to 7-octet IS-IS ID." I assume this ordering is low to high but > the draft should probably clarify this. I suggest wording it "After > calculating the entire "tree" (actually, directed graph), for each node N, > if N has "p" parents, then order the parents ***ascending*** according to > 7-octet IS-IS ID." My change highlighted with ***. > Thanks, > David > > > David Bond > .~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~. > .University of New Hampshire . > . - InterOperability Laboratory . > . Research and Development Software Eng. . > . Routing & Bridge Functions Consortiums . > . - Computer Science PhD Student . > . 121 Technology Drive, Suite 2, Durham NH, 03824 . > . (O) 1-603-862-3525 (M) 1-603-845-7514 . > .~~~~~.~~~~~.~~~~~.~~~~~~.~~~~~~.~~~~~.~~~~~.~~~~~. > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100129/0edb6e07/attachment.html From zebrose at alum.mit.edu Sat Jan 30 18:38:56 2010 From: zebrose at alum.mit.edu (Kate Zebrose) Date: Sat, 30 Jan 2010 21:38:56 -0500 Subject: [rbridge] TRILL MIB Message-ID: Anil, Thank you for your input on the MIB. I have included specific responses below with my initials, but for the most part your input is great. Regarding the IS-IS protocol, I did look at RFC4444 for this MIB, but have not had experience with it otherwise. I agree it would be helpful if we could find someone with IS-IS experience to help with the MIB. I would be happy to look at your version when it is available. - Kate Zebrose from Anil Rijhsinghani to Donald Eastlake , Radia Perlman , Kate Zebrose , Erik Nordmark date Tue, Jan 26, 2010 at 10:01 AM subject TRILL MIB mailed-by charter.net Hi, Based on my reading of the TRILL-14 spec and the MIB published by Kate and Don, as well as the latest Bridge MIBs (RFCs 4188 and 4363), several objects need to be added, roughly described below: - TRILL version supported KZ-sounds good, should we have MIB version as well? - Designated VLAN - used; desired; priority - Appointed VLAN-x forwarder list - Distribution trees: Root priority; how many in use; desired number; max computable; tree numbers and nicknames; trees used at ingress - ESADI: supported or not; per-VLAN enable; ESADI virtual link DRB; MAC addresses; confidence - Filtering Database new objects (to existing Bridge MIB): Nickname of associated Rbridge; Confidence level; how was MAC address learned - Port state new: Inhibited KZ- oops, I was suppose to add this after a long port state discussion, it looks like I left it off. I will forward an email on this topic I got from Donald that you might find helpful. - STP: BPDUs received/detected; Root; number of root changes - Announcing-VLANs set - Inhibition time KZ - is this different from the aging time? - List of root bridges for VLAN-x - TRILL neighbor list - IGMP/MLD/MRD learned info - Pseudonode: suppressed flag; anything else not covered by IS-IS - MTU - desired; per-link; campus-wide; Number of tries before fail; Failed MTU test flag - Enable/disable learning per-VLAN/per-port/native/TRILL - VLAN mapping - counters (new per-port): RPF checks failed; hop-counts exceeded; TRILL frames received; TRILL frames transmitted - ECMP: unicast/multicast enable/disable (what else?) In addition, several objects in this MIB appear to be redundant, based on existing bridge MIBs and Interface MIB, in which there's a lot of management information relevant to Rbridges. I'll try to address each of these, with a pointer to where they are in other MIBs. -KZ - I tried to reference objects in existing MIBs rather than create new objects. When I see your draft I will see if there were reasons I didn't think I could use existing objects. Further, configuration support will be added, as in the existing bridge and other MIBs. SNMPv3 config has support for encryption/authentication and is used widely, however even if a vendor or customer decide to use a different mechanism to configure, this MIB will contain the configurable objects. I'll also plan to write up descriptions of all the parts of existing bridges MIBs applicable to Rbridges, and which aren't. This is required anyway in the text up front, "Relationship to other MIBs". As part of this, I'm running into things not part of standard IS-IS which need to be clarified. For example, what's the frequency of ESADI PDUs? TRILL Hellos? If configurable, they need to be in the MIB. The volume of hellos may be quite high, especially with a large number of VLANs. I haven't studied the IS-IS MIB (RFC4444) to find exactly what portions of it are fully applicable to TRILL; what isn't; and what needs to supplemented. I'd suggest that Kate, or someone else familiar with the IS-IS protocol and MIB, look into that piece if possible. KZ- I tried to address this issue in section 6.3 where I reviewed the IS-IS MIB and detailed what I thought was required and how it needed to be modified. I'll work on adding support for the above and should have a version out by end of next week. Please let me know of any comments. I'm sure we'll rev this a few times as we get through some discussion on it. Regards, Anil