From Internet-Drafts at ietf.org Mon Nov 3 15:30:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 3 Nov 2008 15:30:01 -0800 (PST) Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-10.txt Message-ID: <20081103233001.4556528C3AD@core3.amsl.com> From d3e3e3 at gmail.com Tue Nov 4 09:54:39 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 4 Nov 2008 12:54:39 -0500 Subject: [rbridge] draft-eastlake-trill-rbridge-isis-02.txt Message-ID: <1028365c0811040954t23d9f9b6xe28b6ff7288ab9ab@mail.gmail.com> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RBridges: Use of IS-IS Author(s) : D. Eastlake 3rd, R. Perlman, D. Dutt Filename : draft-eastlake-trill-rbridge-isis-02.txt Pages : 19 Date : 2008-11-3 RBridges implement the TRILL protocol, which in turn makes use of an extended version of the IS-IS (Intermediate System to Intermediate System) routing protocol to determine topology and frame forwarding and for the distribution and synchronization of data. RBridges provide optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and multipathing for both unicast and multicast traffic. Rbridges also support VLANs. This document specifies some details of IS-IS PDUs used in TRILL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-isis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From erik.nordmark at sun.com Fri Nov 7 08:48:07 2008 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri, 07 Nov 2008 08:48:07 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt Message-ID: <49147147.50605@sun.com> 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 From iesg-secretary at ietf.org Mon Nov 17 13:38:09 2008 From: iesg-secretary at ietf.org (The IESG) Date: Mon, 17 Nov 2008 13:38:09 -0800 (PST) Subject: [rbridge] Last Call: draft-ietf-trill-prob (Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement) to Informational RFC Message-ID: <20081117213809.57DC828C0F3@core3.amsl.com> The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2008-12-01. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14771&rfc_flag=0 From d3e3e3 at gmail.com Mon Nov 17 20:01:22 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 17 Nov 2008 23:01:22 -0500 Subject: [rbridge] Minneapolis Presentations Message-ID: <1028365c0811172001g79d17de9oe09971413e916aad@mail.gmail.com> Hi, All of the presentations given at today's TRILL WG meeting have been uploaded/updated on the Meeting Materials page at https://datatracker.ietf.org/meeting/73/materials.html. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From erik.nordmark at sun.com Thu Nov 20 16:31:11 2008 From: erik.nordmark at sun.com (Erik Nordmark) Date: Thu, 20 Nov 2008 16:31:11 -0800 Subject: [rbridge] Merging of draft-eastlake-trill-rbridge-isis and draft-ward-l2isis Message-ID: <4926014F.1090000@sun.com> The allocation of IS-IS code-points and the specification of encoding for information in IS-IS to support Layer-2 routing were discussed in the TRILL and ISIS working group meetings earlier this week. There were also presentations in the ISIS working group meeting on TRILL and on IEEE 802.1aq. (The IEEE 802.1aq project has expanded to include Layer-2 use of IS-IS.) The conclusion was that the existing draft-eastlake-trill-rbridge-isis draft should be merged into draft-ward-l2isis and corrected and, in addition, the IEEE 802.1aq requirements should also be merged into the resulting "kitchen sink" document which would be processed as an ISIS working group document. The plan is that Ayan Banerjee, a current author of ward-l2isis, and Donald Eastlake would be two of the co-authors of the resulting document. People should indicate sometime in the next week if they object to this plan. If there are no objections we will request that ISIS make this a WG document. Erik and Donald From mshand at cisco.com Wed Nov 26 10:18:29 2008 From: mshand at cisco.com (mike shand) Date: Wed, 26 Nov 2008 18:18:29 +0000 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <49147147.50605@sun.com> References: <49147147.50605@sun.com> Message-ID: <492D92F5.4000902@cisco.com> I have reviewed the draft from the viewpoint of IS-IS, and I have the following comments. In view of the dependency on IS-IS protocol encoding AND protocol operation changes, I believe it is important that we get agreement with the IS-IS WG on those aspects that affect the operation of the IS-IS protocol before this draft is set in stone. The points where I believe some discussion between the working groups is required include, but may not be limited to, the items I have enumerated below. 1. The problem of IIH space limitations (typically a maximum of < 1500 octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed. Even if some range based compression is used there is the possibility of pathological distributions of VLAN ids (e.g. just the odd ones) causing problems. There needs to be some guidance on what limitations this may impose etc. 2. The number of IIHs required to be sent when large numbers of VLANs are in use (4.2.3.1.1) is of some concern. Again there needs to be some discussion of what impact this may have in terms of limiting the scaleability of the protocol, and whether such limitations are acceptable. 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be verified by the IS-IS WG. In addition the last bullet needs some further explanation as to what aspect "already provided in IS-IS" is being referenced. IS-IS will normally only elect a single DIS in such circumstances, but there is no provision for disabling forwarding as is implied here. 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS WG. In particular the mechanism of setting the mapping detected bit in the next 5 hellos seems dangerous, since such messages could be lost in the looping which would ensue when mapping was configured. This should either be latched until reset, or at the very least latched until it is detected that it has been actioned by the DRB. 5. It is not clear how the existing VLAN mapping detection will interoperate with the proposed VLAN mapping extensions discussed in Minneapolis. 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID USUALLY by appending another octet to the 6 octet system ID owned by the DRB. This suggests that the possibility of some other way is intended. If so this needs to be described. 7. The second para of 4.2.4.1 (ESADI participation) needs some rational for the sending of CSNPs by the non-DRB. 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is not IS-IS NSAP..." What does this mean? Mike Erik Nordmark wrote: > 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 > > From ayabaner at cisco.com Wed Nov 26 10:48:40 2008 From: ayabaner at cisco.com (Ayan Banerjee (ayabaner)) Date: Wed, 26 Nov 2008 10:48:40 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt References: <49147147.50605@sun.com> Message-ID: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> All, Please see attached comments to the last call on draft-ietf-trill-rbridge-protocol-10.txt. Thanks, Ayan ------------------------------------------------------------------------ ----------------------- Item 1: Section 1.3, can we change the order of control frame/trill-frame/native-frame (editing nits) Item 2: Section 2.1 has reference to ESADI as an IS-IS instance. I believe we said that this is no longer an IS-IS protocol. Can we please update the draft accordingly. 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 From d3e3e3 at gmail.com Wed Nov 26 11:05:18 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 26 Nov 2008 14:05:18 -0500 Subject: [rbridge] draft-eastlake-trill-rbridge-options-01.txt Message-ID: <1028365c0811261105t523f02cdpc1e5537518c6f0d4@mail.gmail.com> - *To*: i-d-announce at ietf.org - *Subject*: I-D ACTION:draft-eastlake-trill-rbridge-options-01.txt - *From*: Internet-Drafts at ietf.org - *Date*: Mon, 24 Nov 2008 14:45:02 -0800 (PST) - *List-archive*: - *List-id*: Internet Draft Announcements only ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Rbridges: TRILL Header Options Author(s) : D. Eastlake 3rd Filename : draft-eastlake-trill-rbridge-options-01.txt Pages : 17 Date : 2008-11-24 The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-10.txt, specifies minimal hooks for options. This draft more fully describes the format for options and an initial set of options. A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-01.txt Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081126/78998138/attachment.html From ginsberg at cisco.com Wed Nov 26 11:25:18 2008 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Wed, 26 Nov 2008 11:25:18 -0800 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <492D92F5.4000902@cisco.com> References: <49147147.50605@sun.com> <492D92F5.4000902@cisco.com> Message-ID: In support of Mike's comments, I would also suggest we look at this in the context of the recent agreement that draft-ward-l2isis be the home for all L2 IS-IS extensions. We therefore want to minimize the overlap between the architecture document and draft-ward-l2isis so as to avoid even the appearance of diverging specifications. It may make sense for the architecture document to discuss the required functionality at a high level, but currently there is considerable text which specifies the procedural extensions of an L2-IS-IS instance - and that clearly is the province of draft-ward-l2isis. So in addition to working out the technical issues on points Mike describes below, the architecture document needs to be revised in such a way as to not duplicate or be in conflict with the protocol extensions draft as it develops. Les > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Mike Shand (mshand) > Sent: Wednesday, November 26, 2008 10:18 AM > To: Erik Nordmark > Cc: rbridge at postel.org > Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt > > I have reviewed the draft from the viewpoint of IS-IS, and I have the > following comments. In view of the dependency on IS-IS protocol encoding > AND protocol operation changes, I believe it is important that we get > agreement with the IS-IS WG on those aspects that affect the operation > of the IS-IS protocol before this draft is set in stone. > > The points where I believe some discussion between the working groups is > required include, but may not be limited to, the items I have enumerated > below. > > 1. The problem of IIH space limitations (typically a maximum of < 1500 > octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed. > Even if some range based compression is used there is the possibility of > pathological distributions of VLAN ids (e.g. just the odd ones) causing > problems. There needs to be some guidance on what limitations this may > impose etc. > > 2. The number of IIHs required to be sent when large numbers of VLANs > are in use (4.2.3.1.1) is of some concern. Again there needs to be some > discussion of what impact this may have in terms of limiting the > scaleability of the protocol, and whether such limitations are acceptable. > > 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be > verified by the IS-IS WG. In addition the last bullet needs some further > explanation as to what aspect "already provided in IS-IS" is being > referenced. IS-IS will normally only elect a single DIS in such > circumstances, but there is no provision for disabling forwarding as is > implied here. > > 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS > WG. In particular the mechanism of setting the mapping detected bit in > the next 5 hellos seems dangerous, since such messages could be lost in > the looping which would ensue when mapping was configured. This should > either be latched until reset, or at the very least latched until it is > detected that it has been actioned by the DRB. > > 5. It is not clear how the existing VLAN mapping detection will > interoperate with the proposed VLAN mapping extensions discussed in > Minneapolis. > > 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID > USUALLY by appending another octet to the 6 octet system ID owned by the > DRB. This suggests that the possibility of some other way is intended. > If so this needs to be described. > > 7. The second para of 4.2.4.1 (ESADI participation) needs some rational > for the sending of CSNPs by the non-DRB. > > 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is > not IS-IS NSAP..." What does this mean? > > > Mike > > > Erik Nordmark wrote: > > 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 Wed Nov 26 13:30:58 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 26 Nov 2008 16:30:58 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay Message-ID: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> I've reviewed the draft and will be posting a few suggested changes. This is the first. 802.1 bridges have a Maximum Bridge Transit Delay. They are required to discard frames that have been inside the bridge for longer than this time. It is configurable with a recommended value of 1 second and maximum value of 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a sentence or two to indicate that RBridges have this parameter configurable per RBridge and enforce a maximum RBridge transit delay. 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/20081126/28529927/attachment.html From d3e3e3 at gmail.com Wed Nov 26 14:08:37 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 26 Nov 2008 17:08:37 -0500 Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses Message-ID: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com> Hi, When TRILL started, it had only one multicast address: All-RBridges. Then it was decided that encapsulated IS-IS frames would have an Inner.MacDA of All-IS-IS-RBridges and there were two. Now there are three multicast address: (1) IS-IS frames are not longer encapsulated and All-IS-IS-RBridges is their Outer.MacDA, (2) All-RBridges is the Outer.MacDA for ESADI and multi-destination data frames, and (3) All-ESADI-RBridges is the Inner.MacDA for ESADI frames. I don't think we are going to need any more than these three multicast addresses for the Base Protocol Specification but multicast addresses are cheap. 802.1 initially allocated itself a block of 16 addresses for bridging and link protocols (see, for example, 802.1D-2004 Figure 7-10 or the more recent 802.1Q-2005 Table 8-1) with the defined behavior being that a bridge was required to drop any frame sent to one of these addresses if the bridge did not understand the protocol(s) indicated by that address. This sort of behavior has to be specified at the beginning. Once you start shipping devices that are transparent to some addresses, you can't practically later say they have to drop them if they don't know the protocol(s) associated with those addresses. (This behavior for bridges has been somewhat modified for more recent complicated cases like provider bridging.) So, I propose that, when we apply, we get a block of 16 addresses with the ones listed in the first paragraph above being the first three addresses in this block and the remaining 13 being reserved for future use. And that the protocol specification require RBridges to drop frames with Outer.MacDA being any of these 13 addresses (unless the RBridge understands some future use of that address). 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/20081126/f404af2a/attachment.html From d3e3e3 at gmail.com Wed Nov 26 14:26:33 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 26 Nov 2008 17:26:33 -0500 Subject: [rbridge] draft protocol-10 WGLC Security Considerations BPDU/Hello DoS addition Message-ID: <1028365c0811261426m12b34f4bx8cf08cf6c6c0b2b5@mail.gmail.com> This is the last of my three comments on the draft. I propose to add a section to the Security Considerations of the protocol-10 draft as pasted at the end of this message. Comments welcome. Thanks,Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com The TRILL protocol requires that an appointed forwarder on an RBridge port be temporarily inhibited if it sees a Hello from another RBridge claiming to be the appointed forwarder or sees a root bridge change out that port. Thus it would seem that forged BPDUs showing repeated root bridge changes and forged Hellos with the Appointed Forwarder flag set could represent a significant denial of service attack. However, the situation is not as bad as it seems. The best defense against forged Hellos or other IS-IS messages is the use of IS-IS security [RFC5304]. Rogue end-stations would not normally have access to the required IS-IS keying material needed to forge authenticatible messages. Authentication similar to IS-IS security is usually unavailable for BPDUs. However, it is also the case that in typical modern wired LANs, all the links are point-to-point. If you have an all RBridged campus, then the worst that an end-station can do by forging BPDUs is to deny itself service. This could be either through falsely inhibiting the forwarding of native frames by the RBridge to which it is connected or by falsely activating the optional decapsulation check (see Section 4.2.3.3). However, when an RBridge campus contains bridged LANs, those bridged LANs appear to any connected RBridges to be multi-access links. The forging of BPDUs by an end-station attached to such a bridged LAN could affect service to other end-stations attached to the bridged LAN. Note that bridges do not forward BPDUs but process them, although this processing may result in the issuance of further BPDUs. Thus, for an end-station to forge BPDUs to cause continuing changes in the root bridge as seen by an RBridge through intervening bridges would typically require it to cause root bridge thrashing throughout the bridged LAN which would be disruptive even in the absence of RBridges. Some bridges can be configured to ignore BPDUs on particular ports and RBridges can be configured not to inhibit appointed forwarding on a port; however, such configuration should be used with caution as it can be unsafe. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081126/0dfc3115/attachment.html From james.d.carlson at sun.com Wed Nov 26 14:21:43 2008 From: james.d.carlson at sun.com (James Carlson) Date: Wed, 26 Nov 2008 17:21:43 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> Message-ID: <18733.52215.806793.660780@gargle.gargle.HOWL> Donald Eastlake writes: > I've reviewed the draft and will be posting a few suggested changes. This is > the first. > 802.1 bridges have a Maximum Bridge Transit Delay. They are required to > discard frames that have been inside the bridge for longer than this time. > It is configurable with a recommended value of 1 second and maximum value of > 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a > sentence or two to indicate that RBridges have this parameter configurable > per RBridge and enforce a maximum RBridge transit delay. Do modern bridges actually _implement_ such a feature, or do they just have a knob labeled "Maximum Bridge Transit Delay" that's connected to nothing underneath? I can imagine flushing Ethernet output queues if link status goes down and stays down for more than a second, thus blocking timely output, but tracking internal timestamps on individual packets seems like a wasted effort to me, and may not even be feasible with modern hardware. I'm inclined to say "no" to this, just on the basis that I cannot see how it would serve any real purpose. It looks like a spec for the sake of a spec. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From d3e3e3 at gmail.com Fri Nov 28 07:28:14 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 28 Nov 2008 10:28:14 -0500 Subject: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt In-Reply-To: <492D92F5.4000902@cisco.com> References: <49147147.50605@sun.com> <492D92F5.4000902@cisco.com> Message-ID: <1028365c0811280728k544d61a2s4c6c5ab2d83e91a8@mail.gmail.com> Hi Mike, Thanks for your comments, responses below... On Wed, Nov 26, 2008 at 1:18 PM, mike shand wrote: > >... > > 1. The problem of IIH space limitations (typically a maximum of < 1500 > octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed. > Even if some range based compression is used there is the possibility of > pathological distributions of VLAN ids (e.g. just the odd ones) causing > problems. There needs to be some guidance on what limitations this may > impose etc. That's a reasonable point. The Hello contents are in 4.2.3.1.2. The only bulky items are 3 (enabled VLANs) and 6 (appointed forwarders). Item 3 is usually present and relates, so to speak, to the configuration of the 802.1Q part of the RBridge port and so could be pretty arbitrary. For that reason, draft-eastlake-trill-isis proposes that it be bit encoded so it can't take too much more than 512 bytes (in the worst case it takes three TLVs/sub-TLVs to fit the data). Item 6 is only in the DRB's Hello but you may want to specify VLANs for each of several other RBridges if you are load sharing the forwarding function. This obviously won't fit in the general case and there should be a comment to that effect. On the other hand, I don't see this as a big problem. The DRB appointing some other RBridge as forwarder for one or more VLANs or blocks of VLANs is just an optimization. Its probably OK, in my opinion, if the DRB can't do such appointments with complete generality due to the Hello frame size limit. I think some discussion of this should be added as you suggest. > 2. The number of IIHs required to be sent when large numbers of VLANs > are in use (4.2.3.1.1) is of some concern. Again there needs to be some > discussion of what impact this may have in terms of limiting the > scaleability of the protocol, and whether such limitations are acceptable. There was considerable discussion in the TRILL WG on the number of Hellos to be sent. Some wanted Hellos to always be sent on all VLANs, considerably more than the default specified in this protocol specification draft. Some wanted fewer Hellos, possibly just Hellos on the Designated VLAN. However, fewer Hellos are not safe in general unless you also use the optional decapsulation check. See Sections 3.2 of http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt (However, note that that draft has not been updated for the latest changes in the protocol draft; I'm working on a -01). > 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be > verified by the IS-IS WG. In addition the last bullet needs some further > explanation as to what aspect "already provided in IS-IS" is being > referenced. IS-IS will normally only elect a single DIS in such > circumstances, but there is no provision for disabling forwarding as is > implied here. TRILL loop avoidance is unrelated to IS-IS routing loop avoidance. TRILL loop avoidance is just about minimizing the probability that a frame which is decapsulated by one RBridge port onto a link will be picked up and re-encapsulated by another RBridge port connected to that link (where a link may be a bridged LAN). In fact, the sketch of a proof that persistent loops do not occur in RBridge campuses, which appears in Section 4 of http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt (which, as I mention above, is out of date and needs to be updated), simply assumes that there are no persistent IS-IS routing loops (and no persistent loops within any bridged LANs). So, while I welcome any review and intelligent comment, given that TRILL loop avoidance is unrelated to IS-IS routing loop avoidance, it is not clear to me why the TRILL loop avoidance mechanisms need to be blessed by the IS-IS WG. On your second point concerning the last bullet point in Section 4.2.3.3, I think you are correct to question it. It seems superfluous and a little confused. As I understand it, TRILL IS-IS Hellos injected by the same RBridge into a link through different ports are distinguished by their source MAC addresses. In any case, it would be plausible that, under some circumstances, the DRB would want to appoint as a forwarder some other of its own port's that are attached to the same link. This might seem like an odd and useless thing to do if you imagine the link as a hunk of classic Ethernet cable but, in fact, the ports may be connected to different areas of an arbitrarily complex bridged LAN. In any case, I think this last bullet point item should simply be deleted. > 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS > WG. In particular the mechanism of setting the mapping detected bit in > the next 5 hellos seems dangerous, since such messages could be lost in > the looping which would ensue when mapping was configured. This should > either be latched until reset, or at the very least latched until it is > detected that it has been actioned by the DRB. The TRILL VLAN mapping detection is only there for TRILL loop avoidance. A mapping of VLAN X to Y inside a link is only a problem if different RBridge ports are appointed forwarder for X and Y on that link. That's why, by default, RBridges send Hellos on a port in all VLANs for which they are appointed forwarder for that port. If a VLAN-X frame is decapsulated onto a link and picked up and re-encapsulated as a VLAN-Y frame, while you're not there yet, you have taken a big step towards having a loop. (A second link doing VLAN Y to X mapping and one broadcast frame and you're sunk...) But having it latch until the DRB acknowledges it seems like a reasonable idea. > 5. It is not clear how the existing VLAN mapping detection will > interoperate with the proposed VLAN mapping extensions discussed in > Minneapolis. TRILL VLAN mapping detection concerns mapping that is occurring between RBridges on a path that includes an initial RBridge port below the EISS interface, a link which may be a bridged LAN, and a final RBridge port below the EISS interface. On the other hand, the VLAN mapping extension in http://tools.ietf.org/id/draft-perlman-trill-rbridge-vlan-mapping-00.txt that was discussed in Minneapolis provides for VLAN mapping in the core of the cut-set RBridges between two regions. As far as I can see, these two kinds of VLAN mapping are orthogonal. > 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID > USUALLY by appending another octet to the 6 octet system ID owned by the > DRB. This suggests that the possibility of some other way is intended. > If so this needs to be described. Probably Radia should answer this one. However, if the assertion in that section that "The only constraint is that the 7-octet ID be unique within the campus, and that the 7th octet be nonzero." is not correct, then the section needs to be re-written. However, if that assertion is correct, I see no reason why the method used by any particular DRB to determine the campus-unique 7-octet ID needs to be discussed or described. There are a number of obvious ways to do this which generally leverage off the global uniqueness of MAC addresses. > 7. The second para of 4.2.4.1 (ESADI participation) needs some rational > for the sending of CSNPs by the non-DRB. Another item probably for Radia...but as I recall the idea is that participants, other than the DRB, know they should be getting a CSNP occasionally. If they don't get one in a long enough time, they send one on the theory it might help and can't hurt. > 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is > not IS-IS NSAP..." What does this mean? The wording is poor... You get to 4.4.2.1 on receipt of a frame addressed to All-IS-IS-RBridges. You want to discard the frame if it isn't an IS-IS frame. The "frame protocol" is the Ethertype or SNAP SAP 5-octet protocol or the LSAPs... anyway, I think this is just trying to say that it must be an IS-IS frame encoded in the usual LLC way even if there is currently or in the future an IS-IS Ethertype or the like... i.e., if there is now, or in the future, some other way of encoding the IS-IS protocol in a frame, RBridges need not support it. > Mike Thanks again for the comments, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Radia.Perlman at sun.com Fri Nov 28 14:58:11 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 28 Nov 2008 14:58:11 -0800 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: <49307783.9010504@sun.com> 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 Radia.Perlman at sun.com Fri Nov 28 15:26:53 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 28 Nov 2008 15:26:53 -0800 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: <49307E3D.6070400@sun.com> 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" > 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) > I think that the optimization is particularly valuable when IS-IS is operating in layer 2. And it doesn't add complexity, so I see no downside to this. > 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. > Yes. The inner and outer VLAN tags are unrelated on encapsualted frames. I thought the spec was clear about this. > 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) > 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 > > 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. > 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... > 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... > 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"? > 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. > Adding optional information into LSPs to detect misconfiguration, and not saying what to do as a result of this information, was a compromise. One could have RBridges act on the information, or have some sort of management tool that looks through things for misconfigurations. Seems like a good idea and mostly harmless. > > 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. > The sentence is >>"Except for this optional capability, >> RBridges MUST NOT send spanning tree BPDUs." I don't remember that. Why did we put that in? I might make an independent note about this... From Radia.Perlman at sun.com Fri Nov 28 15:31:19 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 28 Nov 2008 15:31:19 -0800 Subject: [rbridge] MUST not send spanning tree BPDUs? In-Reply-To: <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> Message-ID: <49307F47.3050405@sun.com> The spec currently says (in section 4.7.3.3 Transmission of BPDUs) RBridges MAY support a capability for sending spanning tree BPDUs for the purpose of attempting to force a bridged LAN to partition as discussed in Section A.3.3. Except for this optional capability, RBridges MUST NOT send spanning tree BPDUs. I don't remember any discussion on saying that RBridges MUST NOT send BPDUs. I remember at one point requiring it, and saying that an RBridge is DRB if and only if it is the Spanning tree Root. (I still would prefer that, by the way -- makes all the controversial per VLAN Hellos unnecessary). I remember it being removed from the spec (because of complexity with n versions of spanning tree, and links with no bridges, perhaps, where the spanning tree messages would be unnecessary overhead), but I don't remember any reason to say RBridges MUST NOT sent BPDUs. Anyone else remember? Thanks, Radia From d3e3e3 at gmail.com Fri Nov 28 17:21:56 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 28 Nov 2008 20:21:56 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <18733.52215.806793.660780@gargle.gargle.HOWL> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL> Message-ID: <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> Hi Jim, See below... On Wed, Nov 26, 2008 at 5:21 PM, James Carlson wrote: > Donald Eastlake writes: >> I've reviewed the draft and will be posting a few suggested changes. This is >> the first. >> 802.1 bridges have a Maximum Bridge Transit Delay. They are required to >> discard frames that have been inside the bridge for longer than this time. >> It is configurable with a recommended value of 1 second and maximum value of >> 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a >> sentence or two to indicate that RBridges have this parameter configurable >> per RBridge and enforce a maximum RBridge transit delay. > > Do modern bridges actually _implement_ such a feature, or do they just > have a knob labeled "Maximum Bridge Transit Delay" that's connected to > nothing underneath? It is my impression that low end 802.1D bridges don't implement this but mid and high end 802.1Q bridges do. Typically, when a frame is received, a control block is created with the VLAN, priority, time of receipt, and other control information. When a frame is de-queued for transmission, the time is checked and frame discarded if it is too old. This time check doesn't need to be, and probably isn't, extremely accurate. > I can imagine flushing Ethernet output queues if link status goes down > and stays down for more than a second, thus blocking timely output, > but tracking internal timestamps on individual packets seems like a > wasted effort to me, and may not even be feasible with modern > hardware. > > I'm inclined to say "no" to this, just on the basis that I cannot see > how it would serve any real purpose. It looks like a spec for the > sake of a spec. In bridges, I think it is required to back up the assurances of Spanning Tree Protocol. I think bridges also flush the output queue and any input queue associated with a port when the port goes down. Generally, it seems like good hygiene not to keep a frame for a long time and then release it... > James Carlson, Solaris Networking > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 It would certainly be easy enough to make this a SHOULD rather than being mandatory the way it is in 802.1, not that people seem to pay that much attention to what is mandatory in 802.1. But perhaps it really isn't necessary for RBridges... Anyone else have an opinion on 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 Fri Nov 28 18:01:29 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 28 Nov 2008 21:01:29 -0500 Subject: [rbridge] MUST not send spanning tree BPDUs? In-Reply-To: <49307F47.3050405@sun.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307F47.3050405@sun.com> Message-ID: <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com> Hi Radia, See below... On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman wrote: > The spec currently says (in section 4.7.3.3 Transmission of BPDUs) > > RBridges MAY support a capability for sending spanning tree BPDUs for > the purpose of attempting to force a bridged LAN to partition as > discussed in Section A.3.3. Except for this optional capability, > RBridges MUST NOT send spanning tree BPDUs. > > > I don't remember any discussion on saying that RBridges MUST NOT send > BPDUs. I remember > at one point requiring it, and saying that an RBridge is DRB if and only > if it is the Spanning tree Root. > (I still would prefer that, by the way -- makes all the controversial > per VLAN Hellos > unnecessary). > > I remember it being removed from the spec (because of complexity with n > versions of > spanning tree, and links with no bridges, perhaps, where the spanning > tree messages would > be unnecessary overhead), but I don't remember any reason to say > RBridges MUST NOT sent > BPDUs. I suspect it used to say "do not" in the sense that there is no RBridge reason for an RBridge port to send spanning tree BPDUs except for the optional bridge LAN partitioning feature described in Section A.3.3. In some pass to upgrade to IETF implementation key words, it probably got changed when it didn't necessarily need to be. The only problem I can see with dropping this is that it might marginally increase the chance someone would erroneously try to build spanning trees through an RBridge. Donald > Anyone else remember? > > Thanks, > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Radia.Perlman at sun.com Fri Nov 28 21:36:42 2008 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 28 Nov 2008 21:36:42 -0800 Subject: [rbridge] MUST not send spanning tree BPDUs? In-Reply-To: <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307F47.3050405@sun.com> <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com> Message-ID: <4930D4EA.7020005@sun.com> Yeah. I think we should either drop the sentence, or say "MAY generate BPDUs, but MUST NOT forward BPDUs from one link to another". Radia Donald Eastlake wrote: > Hi Radia, > > See below... > > On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman wrote: > >> The spec currently says (in section 4.7.3.3 Transmission of BPDUs) >> >> RBridges MAY support a capability for sending spanning tree BPDUs for >> the purpose of attempting to force a bridged LAN to partition as >> discussed in Section A.3.3. Except for this optional capability, >> RBridges MUST NOT send spanning tree BPDUs. >> >> >> I don't remember any discussion on saying that RBridges MUST NOT send >> BPDUs. I remember >> at one point requiring it, and saying that an RBridge is DRB if and only >> if it is the Spanning tree Root. >> (I still would prefer that, by the way -- makes all the controversial >> per VLAN Hellos >> unnecessary). >> >> I remember it being removed from the spec (because of complexity with n >> versions of >> spanning tree, and links with no bridges, perhaps, where the spanning >> tree messages would >> be unnecessary overhead), but I don't remember any reason to say >> RBridges MUST NOT sent >> BPDUs. >> > > I suspect it used to say "do not" in the sense that there is no > RBridge reason for an RBridge port to send spanning tree BPDUs except > for the optional bridge LAN partitioning feature described in Section > A.3.3. In some pass to upgrade to IETF implementation key words, it > probably got changed when it didn't necessarily need to be. The only > problem I can see with dropping this is that it might marginally > increase the chance someone would erroneously try to build spanning > trees through an RBridge. > > Donald > > >> Anyone else remember? >> >> Thanks, >> >> Radia >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > ============================= > 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 ddutt at cisco.com Sat Nov 29 21:00:15 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sat, 29 Nov 2008 21:00:15 -0800 Subject: [rbridge] MUST not send spanning tree BPDUs? In-Reply-To: <4930D4EA.7020005@sun.com> References: <49147147.50605@sun.com> <4C76BEA6DA349A4EBE240D97BBE4546404C57CCD@xmb-sjc-22b.amer.cisco.com> <49307F47.3050405@sun.com> <1028365c0811281801p57cb2212qb723528e23cc7772@mail.gmail.com> <4930D4EA.7020005@sun.com> Message-ID: <49321DDF.2080608@cisco.com> I strongly agree with dropping the sentence and adding the "MUST NOT forward" piece, Dinesh Radia Perlman wrote: > Yeah. I think we should either drop the sentence, or say "MAY generate > BPDUs, > but MUST NOT forward BPDUs from > one link to another". > > Radia > > Donald Eastlake wrote: > >> Hi Radia, >> >> See below... >> >> On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman wrote: >> >> >>> The spec currently says (in section 4.7.3.3 Transmission of BPDUs) >>> >>> RBridges MAY support a capability for sending spanning tree BPDUs for >>> the purpose of attempting to force a bridged LAN to partition as >>> discussed in Section A.3.3. Except for this optional capability, >>> RBridges MUST NOT send spanning tree BPDUs. >>> >>> >>> I don't remember any discussion on saying that RBridges MUST NOT send >>> BPDUs. I remember >>> at one point requiring it, and saying that an RBridge is DRB if and only >>> if it is the Spanning tree Root. >>> (I still would prefer that, by the way -- makes all the controversial >>> per VLAN Hellos >>> unnecessary). >>> >>> I remember it being removed from the spec (because of complexity with n >>> versions of >>> spanning tree, and links with no bridges, perhaps, where the spanning >>> tree messages would >>> be unnecessary overhead), but I don't remember any reason to say >>> RBridges MUST NOT sent >>> BPDUs. >>> >>> >> I suspect it used to say "do not" in the sense that there is no >> RBridge reason for an RBridge port to send spanning tree BPDUs except >> for the optional bridge LAN partitioning feature described in Section >> A.3.3. In some pass to upgrade to IETF implementation key words, it >> probably got changed when it didn't necessarily need to be. The only >> problem I can see with dropping this is that it might marginally >> increase the chance someone would erroneously try to build spanning >> trees through an RBridge. >> >> Donald >> >> >> >>> Anyone else remember? >>> >>> Thanks, >>> >>> Radia >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> ============================= >> 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 > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan