From james.d.carlson at sun.com Mon Dec 1 06:15:29 2008 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 1 Dec 2008 09:15:29 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL> <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> Message-ID: <18739.61825.756225.655262@gargle.gargle.HOWL> Donald Eastlake writes: > > 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. Under what conditions would that be expected to happen? I suspect that one good reason to avoid bothering with such a feature on high-end switches is that the amount of buffering required to reach a 1 second delay at high line rates becomes prohibitive -- in other words, you'll ordinarily drop on queue entry well before that happens in all but pathological cases, so why bother caring? > > 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... We're not using STP here, though, so we don't need to back up its assurances. As for avoiding a too-old release, I don't think that's easy to avoid with modern hardware due to the funky 802 flow control mechanism. If the other end is having trouble, you can end up with a really old frame caught in your transmission craw. It'd require some fancy footwork in most implementations I've seen to detect that sort of edge case, reset, and restart. > 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. That 'one second delay' smells to me too much like the old IP TTL specification, and likely dates back to the same rules of thumb. I think that SHOULD is a fairly strong statement; it means that implementors who choose not to implement that feature need to have a clear explanation of why they don't, if they're going to try to follow the spirit of the RFC. I don't think it ought to be a SHOULD unless it's something that's required for interoperability in most cases, but can be avoided in a few. As 2119 says: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Do RBridge implementors really need to weigh the pros and cons of implementing the delay time check in order to achieve interoperability? MAY is closer to the intent of saying, "here's something that's common in this field and that may be helpful in an implementation, but that is not known to be required for the sake of interoperability of RBridges." -- 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 sgai at nuovasystems.com Mon Dec 1 07:59:57 2008 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 1 Dec 2008 07:59:57 -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: <34BDD2A93E5FD84594BB230DD6C18EA2072DDA88@nuova-ex1.hq.nuovaimpresa.com> Agreed -- Silvano -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Friday, November 28, 2008 9:37 PM To: Donald Eastlake Cc: rbridge at postel.org Subject: Re: [rbridge] MUST not send spanning tree BPDUs? 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 From d3e3e3 at gmail.com Mon Dec 1 09:55:23 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 1 Dec 2008 12:55:23 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <18739.61825.756225.655262@gargle.gargle.HOWL> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL> <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> <18739.61825.756225.655262@gargle.gargle.HOWL> Message-ID: <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> Hi Jim, On Mon, Dec 1, 2008 at 9:15 AM, James Carlson wrote: > Donald Eastlake writes: >> > 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. > > Under what conditions would that be expected to happen? Actually, I think I may have misstated what happens as you would want old frames discarded that were just sitting around in a queue, not just when they were de-queued. All you need is enough higher priority frames and low priority ones could be queued forever even with no link ever going down and no flow control impediments. > I suspect that one good reason to avoid bothering with such a feature > on high-end switches is that the amount of buffering required to reach > a 1 second delay at high line rates becomes prohibitive -- in other > words, you'll ordinarily drop on queue entry well before that happens > in all but pathological cases, so why bother caring? Hummm, it's not clear to me what the resolution of the maximum transit delay is... although 1 second is the default, the resolution could be small allowing it to be set to some number of milliseconds or something... As above, you could have a stream of, say, 1 Gbps higher priority frames going from port 1 to port 3 and one lower priority frame for port 3 that drifts in port 2 and this poor low priority frame could just sit in a queue for days and then pop out due to a hiccup in the high priority stream. I won't argue if you want to call that pathological but it doesn't seem good that it could happen. >> > 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... (As I recall, the 802.1 bridging model does not really admit that input queues can exist so any frame in an input queue is logically considered not to have been received yet by the bridge...) > We're not using STP here, though, so we don't need to back up its > assurances. The specific provisions in 802.1D-2004 include : "6.3.6 Frame lifetime The MAC Service mandates an upper bound to the transit delay experienced for a particular instance of communication. This maximum frame lifetime is necessary to ensure the correct operation of higher layer protocols. ..." "7.1.1 Relay A MAC Bridge relays individual MAC user data frames between the separate MACs of the bridged LANs connected to its Ports. The functions that support relaying frames and maintain QoS are as follows: ... l) Frame discard to ensure that a maximum bridge transit delay is not exceeded (6.3.6). ..." "7.7.3 Queuing frames ... A frame queued for transmission on a Port shall be removed from that queue if that is necessary to ensure that the maximum bridge transit delay (6.3.6, Table 7-3) will not be exceeded at the time at which the frame would subsequently be transmitted. ..." Similar provisions appear in 802.1Q-2005. > As for avoiding a too-old release, I don't think that's easy to avoid > with modern hardware due to the funky 802 flow control mechanism. If > the other end is having trouble, you can end up with a really old > frame caught in your transmission craw. It'd require some fancy > footwork in most implementations I've seen to detect that sort of edge > case, reset, and restart. > >> 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. > > That 'one second delay' smells to me too much like the old IP TTL > specification, and likely dates back to the same rules of thumb. > > I think that SHOULD is a fairly strong statement; it means that > implementors who choose not to implement that feature need to have a > clear explanation of why they don't, if they're going to try to follow > the spirit of the RFC. I don't think it ought to be a SHOULD unless > it's something that's required for interoperability in most cases, but > can be avoided in a few. As 2119 says: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Do RBridge implementors really need to weigh the pros and cons of > implementing the delay time check in order to achieve > interoperability? > > MAY is closer to the intent of saying, "here's something that's common > in this field and that may be helpful in an implementation, but that > is not known to be required for the sake of interoperability of > RBridges." Well, I'm OK with saying MAY. Since this is described in the 802.1 standards as being in the port output queue behavior, and since we now incorporate that by reference unless we say otherwise, one could argue that it is mandatory under the current draft. Unless people weigh in with other opinions, I'll change it to MAY. > 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 Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From james.d.carlson at sun.com Mon Dec 1 10:27:07 2008 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 1 Dec 2008 13:27:07 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL> <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> <18739.61825.756225.655262@gargle.gargle.HOWL> <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> Message-ID: <18740.11387.230356.593090@gargle.gargle.HOWL> Donald Eastlake writes: > On Mon, Dec 1, 2008 at 9:15 AM, James Carlson wrote: > > I suspect that one good reason to avoid bothering with such a feature > > on high-end switches is that the amount of buffering required to reach > > a 1 second delay at high line rates becomes prohibitive -- in other > > words, you'll ordinarily drop on queue entry well before that happens > > in all but pathological cases, so why bother caring? > > Hummm, it's not clear to me what the resolution of the maximum transit > delay is... although 1 second is the default, the resolution could be > small allowing it to be set to some number of milliseconds or > something... Actually, I wasn't talking about the resolution, but rather just the amount of buffering you'd need at a single priority level to queue across that much delay anywhere and not begin dropping. > As above, you could have a stream of, say, 1 Gbps higher priority > frames going from port 1 to port 3 and one lower priority frame for > port 3 that drifts in port 2 and this poor low priority frame could > just sit in a queue for days and then pop out due to a hiccup in the > high priority stream. I won't argue if you want to call that > pathological but it doesn't seem good that it could happen. Yes, I'd call that pathological, but, ok, point taken. > The specific provisions in 802.1D-2004 include : > "6.3.6 Frame lifetime > The MAC Service mandates an upper bound to the transit delay > experienced for a particular instance of > communication. This maximum frame lifetime is necessary to ensure the > correct operation of higher layer > protocols. ..." If there's no limit on the number of bridges that may be encountered in transit, and no limit on the speed-of-light delays between nodes, then I think there's little that this transit delay limit does to protect those upper layer protocols. It limits variance in some cases, at the cost of higher loss, but that's about it; it can't practically set any upper limit. (For a worst-case scenario, consider two adjacent nodes that are unable to use a shared link due to redundancy elsewhere in the network. Failure of that redundancy can bring up that low-latency link, and restoring the far-away link tears it down again. The variance in that case may be predictable if you know the entire topology, but it's arbitrarily large.) > Similar provisions appear in 802.1Q-2005. Yep; I saw them. I wasn't questioning whether they're there, but whether they do any real good. > Well, I'm OK with saying MAY. Since this is described in the 802.1 > standards as being in the port output queue behavior, and since we now > incorporate that by reference unless we say otherwise, one could argue > that it is mandatory under the current draft. Unless people weigh in > with other opinions, I'll change it to MAY. That seems fine. (If we're incorporating all of 802.1 by reference, do we need to restate much of 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 From d3e3e3 at gmail.com Mon Dec 1 11:32:46 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 1 Dec 2008 14:32:46 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <18740.11387.230356.593090@gargle.gargle.HOWL> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL> <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> <18739.61825.756225.655262@gargle.gargle.HOWL> <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> <18740.11387.230356.593090@gargle.gargle.HOWL> Message-ID: <1028365c0812011132t3be4eac9q991f2f923f937a34@mail.gmail.com> Hi Jim, On Mon, Dec 1, 2008 at 1:27 PM, James Carlson wrote: > Donald Eastlake writes: ... >> The specific provisions in 802.1D-2004 include : >> "6.3.6 Frame lifetime >> The MAC Service mandates an upper bound to the transit delay >> experienced for a particular instance of >> communication. This maximum frame lifetime is necessary to ensure the >> correct operation of higher layer >> protocols. ..." > > If there's no limit on the number of bridges that may be encountered > in transit, and no limit on the speed-of-light delays between nodes, > then I think there's little that this transit delay limit does to > protect those upper layer protocols. Seems like good points. I'm not aware of any hops limit for bridges like the 7 level limit for hubs. > It limits variance in some cases, at the cost of higher loss, but > that's about it; it can't practically set any upper limit. (For a > worst-case scenario, consider two adjacent nodes that are unable to > use a shared link due to redundancy elsewhere in the network. Failure > of that redundancy can bring up that low-latency link, and restoring > the far-away link tears it down again. The variance in that case may > be predictable if you know the entire topology, but it's arbitrarily > large.) > ... >> Well, I'm OK with saying MAY. Since this is described in the 802.1 >> standards as being in the port output queue behavior, and since we now >> incorporate that by reference unless we say otherwise, one could argue >> that it is mandatory under the current draft. Unless people weigh in >> with other opinions, I'll change it to MAY. > > That seems fine. (If we're incorporating all of 802.1 by reference, > do we need to restate much of it ... ?) Not much of it. But, since we are essentially incorporating a snapshot of the 802.1Q port processing below the EISS layer, I think we need to say how we differ from 802.1Q in that area. Currently, the protocol spec just says we differ for BPDUs and VLAN registration protocols. Although it seems like a minor difference in practice, if enforcement of a maximum bridge transit delay is a MAY rather than being mandatory as it is in 802.1, I think we should say so. Thanks, Donald > 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 ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From anoop at brocade.com Mon Dec 1 17:58:14 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 1 Dec 2008 17:58:14 -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: <4C94DE2070B172459E4F1EE14BD2364E023D9B5F@HQ-EXCH-5.corp.brocade.com> I agree about the "MUST NOT forward BPDUs" part. However, I think it should always be legal for an RBridge to generate BDPUs (although not a requirement). In many cases, this can help with loop detection on access ports. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Friday, November 28, 2008 9:37 PM > To: Donald Eastlake > Cc: rbridge at postel.org > Subject: Re: [rbridge] MUST not send spanning tree BPDUs? > > 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 > From anoop at brocade.com Mon Dec 1 18:20:04 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 1 Dec 2008 18:20:04 -0800 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com><18733.52215.806793.660780@gargle.gargle.HOWL><1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com><18739.61825.756225.655262@gargle.gargle.HOWL> <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E023D9B6D@HQ-EXCH-5.corp.brocade.com> I think it may be worth adding it as a MAY (or even a SHOULD). Bridges do actually implement this and it can happen due to starvation of service, either because of strict priority queueing (as pointed out by Donald) or because link-level flow control such as 802.3x is in use. For routers, according to RFC 1812 When a router forwards a packet, it MUST reduce the TTL by at least one. If it holds a packet for more than one second, it MAY decrement the TTL by one for each second. We know how many people implement the optional part :-), but at least the issue is discussed. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake > Sent: Monday, December 01, 2008 9:55 AM > To: James Carlson > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge > Transit Delay > > Hi Jim, > > On Mon, Dec 1, 2008 at 9:15 AM, James Carlson > wrote: > > Donald Eastlake writes: > >> > 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. > > > > Under what conditions would that be expected to happen? > > Actually, I think I may have misstated what happens as you would want > old frames discarded that were just sitting around in a queue, not > just when they were de-queued. > > All you need is enough higher priority frames and low priority ones > could be queued forever even with no link ever going down and no flow > control impediments. > > > I suspect that one good reason to avoid bothering with such > a feature > > on high-end switches is that the amount of buffering > required to reach > > a 1 second delay at high line rates becomes prohibitive -- in other > > words, you'll ordinarily drop on queue entry well before > that happens > > in all but pathological cases, so why bother caring? > > Hummm, it's not clear to me what the resolution of the maximum transit > delay is... although 1 second is the default, the resolution could be > small allowing it to be set to some number of milliseconds or > something... > > As above, you could have a stream of, say, 1 Gbps higher priority > frames going from port 1 to port 3 and one lower priority frame for > port 3 that drifts in port 2 and this poor low priority frame could > just sit in a queue for days and then pop out due to a hiccup in the > high priority stream. I won't argue if you want to call that > pathological but it doesn't seem good that it could happen. > > >> > 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... > > (As I recall, the 802.1 bridging model does not really admit that > input queues can exist so any frame in an input queue is logically > considered not to have been received yet by the bridge...) > > > We're not using STP here, though, so we don't need to back up its > > assurances. > > The specific provisions in 802.1D-2004 include : > "6.3.6 Frame lifetime > The MAC Service mandates an upper bound to the transit delay > experienced for a particular instance of > communication. This maximum frame lifetime is necessary to ensure the > correct operation of higher layer > protocols. ..." > > "7.1.1 Relay > A MAC Bridge relays individual MAC user data frames between the > separate MACs of the bridged LANs > connected to its Ports. The functions that support relaying frames and > maintain QoS are as follows: > ... > l) Frame discard to ensure that a maximum bridge transit delay is not > exceeded (6.3.6). > ..." > > "7.7.3 Queuing frames > ... > A frame queued for transmission on a Port shall be removed from that > queue if that is necessary to ensure > that the maximum bridge transit delay (6.3.6, Table 7-3) will not be > exceeded at the time at which the frame > would subsequently be transmitted. > ..." > > Similar provisions appear in 802.1Q-2005. > > > As for avoiding a too-old release, I don't think that's > easy to avoid > > with modern hardware due to the funky 802 flow control > mechanism. If > > the other end is having trouble, you can end up with a really old > > frame caught in your transmission craw. It'd require some fancy > > footwork in most implementations I've seen to detect that > sort of edge > > case, reset, and restart. > > > >> 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. > > > > That 'one second delay' smells to me too much like the old IP TTL > > specification, and likely dates back to the same rules of thumb. > > > > I think that SHOULD is a fairly strong statement; it means that > > implementors who choose not to implement that feature need to have a > > clear explanation of why they don't, if they're going to > try to follow > > the spirit of the RFC. I don't think it ought to be a SHOULD unless > > it's something that's required for interoperability in most > cases, but > > can be avoided in a few. As 2119 says: > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean > that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > Do RBridge implementors really need to weigh the pros and cons of > > implementing the delay time check in order to achieve > > interoperability? > > > > MAY is closer to the intent of saying, "here's something > that's common > > in this field and that may be helpful in an implementation, but that > > is not known to be required for the sake of interoperability of > > RBridges." > > Well, I'm OK with saying MAY. Since this is described in the 802.1 > standards as being in the port output queue behavior, and since we now > incorporate that by reference unless we say otherwise, one could argue > that it is mandatory under the current draft. Unless people weigh in > with other opinions, I'll change it to MAY. > > > 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 > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Mon Dec 1 18:27:32 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 1 Dec 2008 18:27:32 -0800 Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses In-Reply-To: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com> References: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E023D9B71@HQ-EXCH-5.corp.brocade.com> It probably wouldn't hurt, but I'm not sure that this is at all necessary. Other than the core IS-IS instance, all other frames have a TRILL header and we can control forwarding behavior using those contents (and we have already reserved NickName values for that purpose). In future, if we define anything that we don't want to be forwarded by RBridges, we can always force it to have the TRILL header. So we are not dependent on MAC addresses... Anoop ________________________________ From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake Sent: Wednesday, November 26, 2008 2:09 PM To: Developing a hybrid router/bridge. Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses 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/20081201/b5613b25/attachment.html From d3e3e3 at gmail.com Mon Dec 1 19:57:35 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 1 Dec 2008 22:57:35 -0500 Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E023D9B71@HQ-EXCH-5.corp.brocade.com> References: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E023D9B71@HQ-EXCH-5.corp.brocade.com> Message-ID: <1028365c0812011957i590f446cp2a3703929bd845ac@mail.gmail.com> Hi Anoop, On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani wrote: > It probably wouldn't hurt, but I'm not sure that this is at all necessary. > > Other than the core IS-IS instance, all other frames have a TRILL > header and we can control forwarding behavior using those contents > (and we have already reserved NickName values for that purpose). > In future, if we define anything that we don't want to be forwarded > by RBridges, we can always force it to have the TRILL header. > So we are not dependent on MAC addresses... You are probably right that you could figure out some way to do whatever you wanted with reserved nick names or other tweaking of the TRILL header but it might not be very simple or efficient. Just as an example, if you wanted to specify Provider RBridges that related to the current RBridge specification the same way Provider Bridges relate to customer Bridges, one obvious way to do this would include a new multicast address (All-Provider-IS-IS-RBridges?) for provider core IS-IS messages, they same way Provider Bridges use a different multicast address for their BPDUs and, as I understand it, simply forward customer Bridge BPDUs... This could alternatively be done as you suggest, but that would require encapsulating the Provider RBridge IS-IS messages with a funny TRILL Header and, I think, some people on this list really like dispatching on the multicast address and don't like encapsulating IS-IS... Donald > Anoop > > ________________________________ > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Donald Eastlake > Sent: Wednesday, November 26, 2008 2:09 PM > To: Developing a hybrid router/bridge. > Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses > > 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 From d3e3e3 at gmail.com Mon Dec 1 20:10:44 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 1 Dec 2008 23:10:44 -0500 Subject: [rbridge] Draft Minneapolis minutes uploaded Message-ID: <1028365c0812012010u7b23936bqf48d70d16307945@mail.gmail.com> Hi, Draft minutes of the TRILL WG meeting in Minneapolis last month have been uploaded and are available on the Meeting Materials page: https://datatracker.ietf.org/meeting/73/materials.html Corrections/comments welcome, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From anoop at brocade.com Mon Dec 1 23:31:39 2008 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 1 Dec 2008 23:31:39 -0800 Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses In-Reply-To: <1028365c0812011957i590f446cp2a3703929bd845ac@mail.gmail.com> References: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E023D9B71@HQ-EXCH-5.corp.brocade.com> <1028365c0812011957i590f446cp2a3703929bd845ac@mail.gmail.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E023D9BDA@HQ-EXCH-5.corp.brocade.com> Donald, With respect to the example you mention below... It is true that the BPDUs from C-VLAN Bridges are treated as data by S-VLAN Bridges, but they have an S-tag in them when transported over provider bridges. In our case, if we wanted to design such a hierarchy, we would have to depend on the TRILL header to separate traffic from different belonging to different "customers" including the control traffic. In other words, we would have no choice but to encapsulate the customer IS-IS frames with a TRILL header. In any case, as I stated earlier, I don't see it hurting anything to reserve the block of MAC addresses. Anoop > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3 at gmail.com] > Sent: Monday, December 01, 2008 7:58 PM > To: Anoop Ghanwani > Cc: Developing a hybrid router/bridge. > Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses > > Hi Anoop, > > On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani > wrote: > > It probably wouldn't hurt, but I'm not sure that this is at > all necessary. > > > > Other than the core IS-IS instance, all other frames have a TRILL > > header and we can control forwarding behavior using those contents > > (and we have already reserved NickName values for that purpose). > > In future, if we define anything that we don't want to be forwarded > > by RBridges, we can always force it to have the TRILL header. > > So we are not dependent on MAC addresses... > > You are probably right that you could figure out some way to do > whatever you wanted with reserved nick names or other tweaking of the > TRILL header but it might not be very simple or efficient. > > Just as an example, if you wanted to specify Provider RBridges that > related to the current RBridge specification the same way Provider > Bridges relate to customer Bridges, one obvious way to do this would > include a new multicast address (All-Provider-IS-IS-RBridges?) for > provider core IS-IS messages, they same way Provider Bridges use a > different multicast address for their BPDUs and, as I understand it, > simply forward customer Bridge BPDUs... > > This could alternatively be done as you suggest, but that would > require encapsulating the Provider RBridge IS-IS messages with a funny > TRILL Header and, I think, some people on this list really like > dispatching on the multicast address and don't like encapsulating > IS-IS... > > Donald > > > Anoop > > > > ________________________________ > > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On > > Behalf Of Donald Eastlake > > Sent: Wednesday, November 26, 2008 2:09 PM > > To: Developing a hybrid router/bridge. > > Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses > > > > 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 > From ddutt at cisco.com Tue Dec 2 09:23:03 2008 From: ddutt at cisco.com (Dinesh G Dutt) Date: Tue, 02 Dec 2008 09:23:03 -0800 Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E023D9BDA@HQ-EXCH-5.corp.brocade.com> References: <1028365c0811261408o459c3d19jc23b3235bf2f9ef4@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E023D9B71@HQ-EXCH-5.corp.brocade.com> <1028365c0812011957i590f446cp2a3703929bd845ac@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E023D9BDA@HQ-EXCH-5.corp.brocade.com> Message-ID: <49356EF7.8070105@cisco.com> To follow the analogy of SVLAN BPDUs and the behavior of CVLAN BPDUs in an SVLAN cloud, since the CVLAN BPDUs are treated as data by the SVLAN bridges, the SVLAN Rbridge would encapsulate the CVLAN IS-IS (which has a different MAC address than SVLAN IS-IS) in a TRILL header while transporting it through the provider RBridge cloud. This will work fine without having to reserve a bunch of MAC addresses. Dinesh Anoop Ghanwani wrote: > Donald, > > With respect to the example you mention below... > > It is true that the BPDUs from C-VLAN Bridges are > treated as data by S-VLAN Bridges, but they have > an S-tag in them when transported over provider > bridges. In our case, if we wanted to > design such a hierarchy, we would have to depend > on the TRILL header to separate traffic from > different belonging to different "customers" > including the control traffic. In other words, > we would have no choice but to encapsulate the > customer IS-IS frames with a TRILL header. > > In any case, as I stated earlier, I don't see > it hurting anything to reserve the block of MAC > addresses. > > Anoop > > >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3 at gmail.com] >> Sent: Monday, December 01, 2008 7:58 PM >> To: Anoop Ghanwani >> Cc: Developing a hybrid router/bridge. >> Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses >> >> Hi Anoop, >> >> On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani >> wrote: >> >>> It probably wouldn't hurt, but I'm not sure that this is at >>> >> all necessary. >> >>> Other than the core IS-IS instance, all other frames have a TRILL >>> header and we can control forwarding behavior using those contents >>> (and we have already reserved NickName values for that purpose). >>> In future, if we define anything that we don't want to be forwarded >>> by RBridges, we can always force it to have the TRILL header. >>> So we are not dependent on MAC addresses... >>> >> You are probably right that you could figure out some way to do >> whatever you wanted with reserved nick names or other tweaking of the >> TRILL header but it might not be very simple or efficient. >> >> Just as an example, if you wanted to specify Provider RBridges that >> related to the current RBridge specification the same way Provider >> Bridges relate to customer Bridges, one obvious way to do this would >> include a new multicast address (All-Provider-IS-IS-RBridges?) for >> provider core IS-IS messages, they same way Provider Bridges use a >> different multicast address for their BPDUs and, as I understand it, >> simply forward customer Bridge BPDUs... >> >> This could alternatively be done as you suggest, but that would >> require encapsulating the Provider RBridge IS-IS messages with a funny >> TRILL Header and, I think, some people on this list really like >> dispatching on the multicast address and don't like encapsulating >> IS-IS... >> >> Donald >> >> >>> Anoop >>> >>> ________________________________ >>> From: rbridge-bounces at postel.org >>> >> [mailto:rbridge-bounces at postel.org] On >> >>> Behalf Of Donald Eastlake >>> Sent: Wednesday, November 26, 2008 2:09 PM >>> To: Developing a hybrid router/bridge. >>> Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses >>> >>> 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 >>> > > _______________________________________________ > 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 From d3e3e3 at gmail.com Wed Dec 10 19:54:14 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 10 Dec 2008 22:54:14 -0500 Subject: [rbridge] Draft Minneapolis minutes uploaded In-Reply-To: <1028365c0812012010u7b23936bqf48d70d16307945@mail.gmail.com> References: <1028365c0812012010u7b23936bqf48d70d16307945@mail.gmail.com> Message-ID: <1028365c0812101954j42bbfe79t62ea0a421395c0c9@mail.gmail.com> Slightly expanded minutes have been uploaded. As before, corrections/comments welcome,Donald On Mon, Dec 1, 2008 at 11:10 PM, Donald Eastlake wrote: > Hi, > > Draft minutes of the TRILL WG meeting in Minneapolis last month have > been uploaded and are available on the Meeting Materials page: > > https://datatracker.ietf.org/meeting/73/materials.html > > Corrections/comments welcome, > 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/20081210/3f664e8c/attachment.html From d3e3e3 at gmail.com Wed Dec 10 21:02:34 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 11 Dec 2008 00:02:34 -0500 Subject: [rbridge] draft-eastlake-trill-rbridge-notes-01.txt Message-ID: <1028365c0812102102u1ba72318nccaf2907b70a2194@mail.gmail.com> An updated version of RBridge notes draft has been posted. Donald ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Rbridge Notes Author(s) : D. Eastlake 3rd Filename : draft-eastlake-trill-rbridge-notes-01.txt Pages : 20 Date : 2008-12-10 This document provides additional informational material related to RBridges, which are devices that implement the TRILL protocol. It is a supplement to the RBridges base protocol specification and includes discussion of tradeoffs in some features and configurations of RBridges. In addition, it provides a sketch of a proof that, with reasonable assumptions, persistent loops do not occur in a TRILL campus. A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-notes-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/20081211/f0b98e02/attachment.html From d3e3e3 at gmail.com Sun Dec 14 14:12:39 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 14 Dec 2008 17:12:39 -0500 Subject: [rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E023D9B6D@HQ-EXCH-5.corp.brocade.com> References: <1028365c0811261330g60d54735r732b7cad02caa450@mail.gmail.com> <18733.52215.806793.660780@gargle.gargle.HOWL> <1028365c0811281721u7064c68dm292f3891716a7c70@mail.gmail.com> <18739.61825.756225.655262@gargle.gargle.HOWL> <1028365c0812010955t7f0f1158se89bd966c5d905d6@mail.gmail.com> <4C94DE2070B172459E4F1EE14BD2364E023D9B6D@HQ-EXCH-5.corp.brocade.com> Message-ID: <1028365c0812141412u552a577p2c6234998a0916b1@mail.gmail.com> Hi, I plan to resolve this by adding a Maximum Transit Delay per RBridge configuration parameter and state that frames which have exceeded that time MAY be discarded. Donald On Mon, Dec 1, 2008 at 9:20 PM, Anoop Ghanwani wrote: > > I think it may be worth adding it as a MAY (or even a SHOULD). > Bridges do actually implement this and it can happen due to > starvation of service, either because of strict priority > queueing (as pointed out by Donald) or because link-level > flow control such as 802.3x is in use. > > For routers, according to RFC 1812 > > When a router forwards a packet, it MUST reduce the TTL by at least > one. If it holds a packet for more than one second, it MAY decrement > the TTL by one for each second. > > We know how many people implement the optional part :-), > but at least the issue is discussed. > > Anoop > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake >> Sent: Monday, December 01, 2008 9:55 AM >> To: James Carlson >> Cc: Developing a hybrid router/bridge. >> Subject: Re: [rbridge] draft protocol-10 WGLC Maximum Bridge >> Transit Delay >> >> Hi Jim, >> >> On Mon, Dec 1, 2008 at 9:15 AM, James Carlson >> wrote: >> > Donald Eastlake writes: >> >> > 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. >> > >> > Under what conditions would that be expected to happen? >> >> Actually, I think I may have misstated what happens as you would want >> old frames discarded that were just sitting around in a queue, not >> just when they were de-queued. >> >> All you need is enough higher priority frames and low priority ones >> could be queued forever even with no link ever going down and no flow >> control impediments. >> >> > I suspect that one good reason to avoid bothering with such >> a feature >> > on high-end switches is that the amount of buffering >> required to reach >> > a 1 second delay at high line rates becomes prohibitive -- in other >> > words, you'll ordinarily drop on queue entry well before >> that happens >> > in all but pathological cases, so why bother caring? >> >> Hummm, it's not clear to me what the resolution of the maximum transit >> delay is... although 1 second is the default, the resolution could be >> small allowing it to be set to some number of milliseconds or >> something... >> >> As above, you could have a stream of, say, 1 Gbps higher priority >> frames going from port 1 to port 3 and one lower priority frame for >> port 3 that drifts in port 2 and this poor low priority frame could >> just sit in a queue for days and then pop out due to a hiccup in the >> high priority stream. I won't argue if you want to call that >> pathological but it doesn't seem good that it could happen. >> >> >> > 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... >> >> (As I recall, the 802.1 bridging model does not really admit that >> input queues can exist so any frame in an input queue is logically >> considered not to have been received yet by the bridge...) >> >> > We're not using STP here, though, so we don't need to back up its >> > assurances. >> >> The specific provisions in 802.1D-2004 include : >> "6.3.6 Frame lifetime >> The MAC Service mandates an upper bound to the transit delay >> experienced for a particular instance of >> communication. This maximum frame lifetime is necessary to ensure the >> correct operation of higher layer >> protocols. ..." >> >> "7.1.1 Relay >> A MAC Bridge relays individual MAC user data frames between the >> separate MACs of the bridged LANs >> connected to its Ports. The functions that support relaying frames and >> maintain QoS are as follows: >> ... >> l) Frame discard to ensure that a maximum bridge transit delay is not >> exceeded (6.3.6). >> ..." >> >> "7.7.3 Queuing frames >> ... >> A frame queued for transmission on a Port shall be removed from that >> queue if that is necessary to ensure >> that the maximum bridge transit delay (6.3.6, Table 7-3) will not be >> exceeded at the time at which the frame >> would subsequently be transmitted. >> ..." >> >> Similar provisions appear in 802.1Q-2005. >> >> > As for avoiding a too-old release, I don't think that's >> easy to avoid >> > with modern hardware due to the funky 802 flow control >> mechanism. If >> > the other end is having trouble, you can end up with a really old >> > frame caught in your transmission craw. It'd require some fancy >> > footwork in most implementations I've seen to detect that >> sort of edge >> > case, reset, and restart. >> > >> >> 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. >> > >> > That 'one second delay' smells to me too much like the old IP TTL >> > specification, and likely dates back to the same rules of thumb. >> > >> > I think that SHOULD is a fairly strong statement; it means that >> > implementors who choose not to implement that feature need to have a >> > clear explanation of why they don't, if they're going to >> try to follow >> > the spirit of the RFC. I don't think it ought to be a SHOULD unless >> > it's something that's required for interoperability in most >> cases, but >> > can be avoided in a few. As 2119 says: >> > >> > 3. SHOULD This word, or the adjective "RECOMMENDED", mean >> that there >> > may exist valid reasons in particular circumstances to ignore a >> > particular item, but the full implications must be understood and >> > carefully weighed before choosing a different course. >> > >> > Do RBridge implementors really need to weigh the pros and cons of >> > implementing the delay time check in order to achieve >> > interoperability? >> > >> > MAY is closer to the intent of saying, "here's something >> that's common >> > in this field and that may be helpful in an implementation, but that >> > is not known to be required for the sake of interoperability of >> > RBridges." >> >> Well, I'm OK with saying MAY. Since this is described in the 802.1 >> standards as being in the port output queue behavior, and since we now >> incorporate that by reference unless we say otherwise, one could argue >> that it is mandatory under the current draft. Unless people weigh in >> with other opinions, I'll change it to MAY. >> >> > 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 >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-634-2066 (home) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3 at gmail.com >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Sun Dec 14 20:07:23 2008 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 14 Dec 2008 23:07:23 -0500 Subject: [rbridge] MUST not send spanning tree BPDUs? In-Reply-To: <49321DDF.2080608@cisco.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> <49321DDF.2080608@cisco.com> Message-ID: <1028365c0812142007q6e99058fwa4da1d277e2c0294@mail.gmail.com> Hi, I'll go ahead and change the draft, since that seems to be what most people want. But I don't consider it that big a deal for the following reason: If you wanted to send BPDUs despite the current prohibition, you would just say that you are implementing a virtual bridge connected between the RBridge port and the link. That way of thinking about it makes it crystal clear that RBridges don't participate as a single node in spanning tree. Saying that RBridges never forward BPDUs is good but a greater risk would be that once someone has their RBridge ports participating in spanning tree they might be tempted to connect the ports together so that the RBridge as a whole participated in spanning tree. This would result in a bigger spanning tree causing an increase in blocked ports, which would thereby become unavailable for use by TRILL, as well as longer spanning tree settling times, etc. Donald On Sun, Nov 30, 2008 at 12:00 AM, Dinesh G Dutt wrote: > 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 ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From touch at ISI.EDU Mon Dec 15 20:10:34 2008 From: touch at ISI.EDU (Joe Touch) Date: Mon, 15 Dec 2008 20:10:34 -0800 Subject: [rbridge] MUST not send spanning tree BPDUs? In-Reply-To: <1028365c0812142007q6e99058fwa4da1d277e2c0294@mail.gmail.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> <49321DDF.2080608@cisco.com> <1028365c0812142007q6e99058fwa4da1d277e2c0294@mail.gmail.com> Message-ID: <49472A3A.7000302@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Donald Eastlake wrote: > Hi, > > I'll go ahead and change the draft, since that seems to be what most > people want. But I don't consider it that big a deal for the following > reason: > If you wanted to send BPDUs despite the current prohibition, > you would just say that you are implementing a virtual bridge > connected between the RBridge port and the link. That way of thinking > about it makes it crystal clear that RBridges don't participate as a > single node in spanning tree. FWIW, this is the reason for the MUST NOT. I was a proponent of basically the perspective above; that an rbridge was a device distinct from a bridge that was compatible with bridges, not a superset of their functionality per se. Joe > On Sun, Nov 30, 2008 at 12:00 AM, Dinesh G Dutt wrote: >> 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 > ============================= > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklHKjoACgkQE5f5cImnZruEGQCeINqIN8WM14tr8j8/dLucVjUN 8RMAoJm6BT+qbbqLhkE1D5wK8BW6ocqG =JGYA -----END PGP SIGNATURE-----