From Donald.Eastlake at motorola.com Tue Oct 2 20:18:26 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 2 Oct 2007 23:18:26 -0400 Subject: [rbridge] Consensus Call: V-field reversion In-Reply-To: <3870C46029D1F945B1472F170D2D9790030B9103@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3A@de01exm64.ds.mot.com><46E00624.3060302@isi.edu> <3870C46029D1F945B1472F170D2D9790030B9103@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D9790031840B4@de01exm64.ds.mot.com> This consensus from the Chicago meeting has been confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, September 17, 2007 1:37 AM To: Joe Touch Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Right. (I'm generally using the somewhat less formal wording from the minutes in these consensus checks.) Thanks, Donald -----Original Message----- From: Joe Touch [mailto:touch at ISI.EDU] Sent: Thursday, September 06, 2007 9:53 AM To: Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: V-field reversion Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus at the Chicago meeting for a change from protocol draft -05: > > Eliminate different V field values and revert to two version bits > and two reserved bits with the previous provisions that this draft > specifies version zero, frames with an unknown version are > discarded, reserved bits MUST be zero and are ignored on receipt. Minor nit to avoid ambiguity: ...MUST be _set to_ zero... > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Tue Oct 2 20:23:58 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 2 Oct 2007 23:23:58 -0400 Subject: [rbridge] Consensus Call: MAC learning timers In-Reply-To: <3870C46029D1F945B1472F170D2D9790030B9100@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D979002FE7B3B@de01exm64.ds.mot.com> <46E00687.80507@isi.edu> <18144.5260.800390.204166@gargle.gargle.HOWL> <46E099E2.4030308@isi.edu> <18145.10990.755022.598448@gargle.gargle.HOWL> <46E15D01.50702@isi.edu><18145.37191.943519.790828@gargle.gargle.HOWL><46E1DEFC.9090502@isi.edu> <3870C46029D1F945B1472F170D2D9790030B9100@de01exm64.ds.mot.com> Message-ID: <3870C46029D1F945B1472F170D2D9790031840B7@de01exm64.ds.mot.com> The consensus at the Chicago meeting that the MAC address learning timers in Rbridges should follow the IEEE 802.1-2005 (Section 8.8.3) recommendations is confirmed. Donald & Erik -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Monday, September 17, 2007 1:37 AM To: Joe Touch; James Carlson Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: MAC learning timers It's just a recommendation in the IEEE 802.1Q-2005 Standard as quoted below. Donald >From IEEE 802.1Q-2005, Section 8.8.3, "Dynamic Filtering Entries", page 56: The ageing out of Dynamic Filtering Entries ensures that end stations that have been moved to a different part of the network will not be permanently prevented from receiving frames. It also takes account of changes in the active topology of the network that can cause end stations to appear to move from the point of view of the bridge; i.e., the path to those end stations subsequently lies through a different Bridge Port. The Ageing Time may be set by management (Clause 12). A range of applicable values and a recommended default is specified in Table 8-3; this is suggested to remove the need for explicit configuration in most cases. If the value of Ageing Time can be set by management, the Bridge shall have the capability to use values in the range specified, with a granularity of 1 s. Table 8-3-Ageing time parameter value Parameter Recommended Default Value Range Ageing Time 300.0 s. 10.0 - 1,000,000.0s NOTE 4-The granularity is specified in order to establish a common basis for the granularity expressed in the management operations defined in Clause 12, not to constrain the granularity of the actual timer supported by a conformant implementation. If the implementation supports a granularity other than 1 s, then it is possible that the value read back by management following a Set operation will not match the actual value expressed in the Set. -----Original Message----- From: Joe Touch [mailto:touch at ISI.EDU] Sent: Friday, September 07, 2007 7:30 PM To: James Carlson Cc: Eastlake III Donald-LDE008; Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: MAC learning timers James Carlson wrote: > Joe Touch writes: >> James Carlson wrote: >>> Instead, our role is to design TRILL, and specify what's _required_ to >>> make that work. Is there an issue here that, if someone had a good >>> reason to use some other set of defaults for these parameters, doing >>> so would break TRILL? >> I'm concerned about breaking the non-TRILL devices by TRILL behavior. If >> our caches have timeouts different from theirs, then the overall system >> won't be as plug-and-play -- or, more specifically, more 'replug-and-play'. >> >> That's why we're recommending IEEE values and defaults; that didn't come >> out of the blue. > > Yes, and that's precisely the reason to "recommend" those defaults -- > as in BCP 14 "SHOULD." I never did suggest that they came out of the > blue or that anyone ought to ignore them. > > However, as a matter of operating TRILL, they don't appear (to me at > least) to be key issues that will cause TRILL failure. That means > they're not a "MUST." That's fine. Let's hear what others think. I just want to make sure we're picking the right one and understanding what we're picking; I really didn't have an a-priori decision. Joe -- ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From Donald.Eastlake at motorola.com Tue Oct 2 20:24:30 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 2 Oct 2007 23:24:30 -0400 Subject: [rbridge] Consensus Check: Inner Multicast Address of TRILL IS-IS Frames Message-ID: <3870C46029D1F945B1472F170D2D9790031840B8@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Utilize a different multicast address ("All-IS-IS-RBridges"), allocated to RBridges, as the inner MAC destination address of TRILL IS-IS Frames. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Tue Oct 2 20:25:16 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 2 Oct 2007 23:25:16 -0400 Subject: [rbridge] Consensus Check: Egress processing of unicast not locally known Message-ID: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: Egress RBridges that receive a known unicast TRILL data frame whose inner destination address is not known locally should send the native form of the frame out on every link for which the RBridge is DRB for the frame's VLAN unless it knows that an end station with that MAC address could not be on that link. (For example, there is a layer-2 registration procedure for end stations on that link and the destination MAC address in question is not registered.) This is a local decision. No "error" message will be defined for this condition at this time. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik From Donald.Eastlake at motorola.com Tue Oct 2 20:26:38 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 2 Oct 2007 23:26:38 -0400 Subject: [rbridge] Consensus Check: Point to Point links Message-ID: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> This is a check via the mailing list to confirm or refute an apparent consensus from the minutes of the Chicago meeting for a change from protocol draft -05: If it is known that a link is a point to point link between two RBridges, then the outer header, if it is an Ethernet header, can have any source and/or destination addresses, those addresses will be ignored on receipt, and the outer VLAN tag can be omitted. If no particular controversy arises over this in the next two weeks, we will declare it to be the working group consensus. Thanks, Donald & Erik From eric.gray at ericsson.com Wed Oct 3 08:10:51 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 3 Oct 2007 10:10:51 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> Donald, Given that it is not crystal clear what you mean by "point to point link", I am not sure I agree with this, at least as you have worded it here. If you mean that the link is a full-duplex Ethernet link and the two end-points have some definitive mechansim for determining that they are the only entities using the link between them, there may be issues with doing this. For example, if the link is technically an Ethernet link, then it is not unlikely that one or the other devices may have multiple roles - i.e. - it may be both an RBridge for some frames and either a regular bridge or end station (for example, a router) for others. It's arguable that, in this case, the multi-role device is two (or more) separate entities - thus invalidating a "point to point" definition for this case (though only two distinct physical devices are connected via this link). Without a clear agreement between involved entities, this sort of "short-cut" addressing is likely to result in higher-level (slow path) processing of many (if not all) of the frames transiting the link for some implementations. Moreover, without an unambiguous determination of exactly when this would apply, it will not be unambiguously clear when a receiving implementation would have to switch to a "promiscuous listening" mode. I believe omission of the outer VLAN tag suffers from the same ambiguity. For instance, it is possible for two devices to have a "point to point" relationship within a VLAN context that would nto be the case without the VLAN context. Hence it appears we would have to be explicit in what we mean by "point to point" link and how we expect that the entities (RBridges) involved would be able to disambiguate this p2p status for any given link. If we are saying that two devices - using some means out of scope for our specification - are somehow aware of an unambiguous point-to-point relationship between them and can therefore use any MAC DA on transmission, and ignore it on receipt, we could make the same argument for virtually any encapsulation choice we might prefer. But, it would be as valid to observe that we don't need to specify what is - in essence - an out-of-context (mis)behavior between consenting implementations... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 11:27 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Wed Oct 3 09:41:13 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 3 Oct 2007 09:41:13 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7AFE32@HQ-EXCH-5.corp.brocade.com> I'm OK with this as long as the omission of the outer VLAN tag is a MAY rather than a MUST. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 8:27 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an > apparent consensus from the minutes of the Chicago meeting > for a change from protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From anoop at brocade.com Wed Oct 3 10:03:43 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 3 Oct 2007 10:03:43 -0700 Subject: [rbridge] Consensus Check: Egress processing of unicast not locallyknown In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7AFE55@HQ-EXCH-5.corp.brocade.com> I'm not sure why the case of "MAC address could not be on that link" needs to be called out at all. That is an access control issue. But I am OK with having it if someone really feels strongly about it. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 8:25 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Egress processing of > unicast not locallyknown > > This is a check via the mailing list to confirm or refute an > apparent consensus from the minutes of the Chicago meeting > for a change from protocol draft -05: > > Egress RBridges that receive a known unicast TRILL data frame whose > inner destination address is not known locally should send the > native form of the frame out on every link for which the RBridge > is DRB for the frame's VLAN unless it knows that an end station > with that MAC address could not be on that link. (For example, > there is a layer-2 registration procedure for end stations on that > link and the destination MAC address in question is not > registered.) This is a local decision. No "error" message will be > defined for this condition at this time. > > If no particular controversy arises over this in the next two > weeks, we will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From touch at ISI.EDU Wed Oct 3 10:16:28 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Oct 2007 10:16:28 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> Message-ID: <4703CE6C.7090306@isi.edu> Donald, et al., I concur with Eric. My concern is why we are defining behavior specific to pt-pt links for rbridges when they are not similarly defined for general 802.11 networks. If there is such a definition, we should point to it, but we should not create our own. There's no unique need. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/35eb9fd9/signature.bin From Caitlin.Bestler at neterion.com Wed Oct 3 11:17:42 2007 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Wed, 3 Oct 2007 14:17:42 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4703CE6C.7090306@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> Joe Touch wrote: > I concur with Eric. My concern is why we are defining behavior specific > to pt-pt links for rbridges when they are not similarly defined for > general 802.11 networks. > If there is such a definition, we should point to it, but we should not > create our own. There's no unique need. I can imagine several scenarios where there is a truly safe point-to-point link between two RBridges, and it is indeed safe for them to use a custom tunneling between them. What I don't see is why they need the specification to give them permission. If that link is *truly* and securely point-to-point they could just as easily declare themselves to be a single RBridge and said link to be a "inter-processor bus". When an RBridge is implemented on multiple processors the IETF does NOT specify the bus that connects them. So basically, whenever this sort of optimized encapsulation is valid there is no need to explicitly state so. If there is a need for the alternate encapsulation to be officially blessed then it probably means that it isn't safe to do it. If *nobody* else can see the optimized frames then who is there to complain that they are non-compliant? From eric.gray at ericsson.com Wed Oct 3 11:22:08 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 3 Oct 2007 13:22:08 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> Caitlin, Please see one comment below... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] > Sent: Wednesday, October 03, 2007 2:18 PM > To: Joe Touch; Eric Gray > Cc: Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > Importance: High > > > Joe Touch wrote: > > > I concur with Eric. My concern is why we are defining behavior > specific > > to pt-pt links for rbridges when they are not similarly defined for > > general 802.11 networks. > > > If there is such a definition, we should point to it, but we should > not > > create our own. There's no unique need. > > I can imagine several scenarios where there is a truly safe > point-to-point > link between two RBridges, and it is indeed safe for them to use a > custom > tunneling between them. > > What I don't see is why they need the specification to give them > permission. > > If that link is *truly* and securely point-to-point they could just as > easily > declare themselves to be a single RBridge and said link to be a > "inter-processor > bus". When an RBridge is implemented on multiple processors the IETF > does NOT > specify the bus that connects them. > > So basically, whenever this sort of optimized encapsulation is valid > there is > no need to explicitly state so. If there is a need for the alternate > encapsulation > to be officially blessed then it probably means that it isn't > safe to do > it. > > If *nobody* else can see the optimized frames then who is there to > complain > that they are non-compliant? Hence the reference to "consenting implementations" in my earlier mail. I get the sense that you're not disagreeing with either Joe or myself. > > > > From Donald.Eastlake at motorola.com Wed Oct 3 11:24:26 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 3 Oct 2007 14:24:26 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7AFE32@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E7AFE32@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D979003184318@de01exm64.ds.mot.com> That's reasonable. "can be omitted" implies MAY to me. Donald -----Original Message----- From: Anoop Ghanwani [mailto:anoop at brocade.com] Sent: Wednesday, October 03, 2007 12:41 PM To: Eastlake III Donald-LDE008; Rbridge at postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links I'm OK with this as long as the omission of the outer VLAN tag is a MAY rather than a MUST. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 8:27 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an > apparent consensus from the minutes of the Chicago meeting > for a change from protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Wed Oct 3 11:24:58 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 3 Oct 2007 14:24:58 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> Message-ID: <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> Hi Eric, I believe the generally understood meaning of point-to-point is a link with exactly two devices on it, in this case RBridges. It is true that one could always do this sort of thing outside the standards. But in Chicago the working group appeared to believe this was sufficiently important to say in the standard and, while the consensus in the room was not that detailed, I got the general impression that people would be favorable to, in a later management document, having a MIB variable that would enable one to configure an interface as being known point-to-point, possibly point-to-point, or prohibited from using this point-to-point outer address flexibility, or some such management configuration feature. There also seemed to have been at least some interest in an automated way of determining that an interface was point-to-point, perhaps based on the receive of 802.1AB frames all containing appropriate indications coupled with the receipt of no native frames. Point-to-point links are, in fact, very common in modern 802.3 networks. Donald -----Original Message----- From: Eric Gray [mailto:eric.gray at ericsson.com] Sent: Wednesday, October 03, 2007 11:11 AM To: Eastlake III Donald-LDE008; Rbridge at postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links Donald, Given that it is not crystal clear what you mean by "point to point link", I am not sure I agree with this, at least as you have worded it here. If you mean that the link is a full-duplex Ethernet link and the two end-points have some definitive mechansim for determining that they are the only entities using the link between them, there may be issues with doing this. For example, if the link is technically an Ethernet link, then it is not unlikely that one or the other devices may have multiple roles - i.e. - it may be both an RBridge for some frames and either a regular bridge or end station (for example, a router) for others. It's arguable that, in this case, the multi-role device is two (or more) separate entities - thus invalidating a "point to point" definition for this case (though only two distinct physical devices are connected via this link). Without a clear agreement between involved entities, this sort of "short-cut" addressing is likely to result in higher-level (slow path) processing of many (if not all) of the frames transiting the link for some implementations. Moreover, without an unambiguous determination of exactly when this would apply, it will not be unambiguously clear when a receiving implementation would have to switch to a "promiscuous listening" mode. I believe omission of the outer VLAN tag suffers from the same ambiguity. For instance, it is possible for two devices to have a "point to point" relationship within a VLAN context that would nto be the case without the VLAN context. Hence it appears we would have to be explicit in what we mean by "point to point" link and how we expect that the entities (RBridges) involved would be able to disambiguate this p2p status for any given link. If we are saying that two devices - using some means out of scope for our specification - are somehow aware of an unambiguous point-to-point relationship between them and can therefore use any MAC DA on transmission, and ignore it on receipt, we could make the same argument for virtually any encapsulation choice we might prefer. But, it would be as valid to observe that we don't need to specify what is - in essence - an out-of-context (mis)behavior between consenting implementations... -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, October 02, 2007 11:27 PM > To: Rbridge at postel.org > Subject: [rbridge] Consensus Check: Point to Point links > > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two > weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From touch at ISI.EDU Wed Oct 3 11:27:42 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Oct 2007 11:27:42 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> Message-ID: <4703DF1E.8020904@isi.edu> Eric Gray wrote: > Caitlin, ... > > I get the sense that you're not disagreeing with either Joe or > myself. I agree with the nuances Caitlin is raising; the conclusion is that this need not be in the spec, as far as we three appear to agree. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/a084c356/signature.bin From eric.gray at ericsson.com Wed Oct 3 12:10:04 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Wed, 3 Oct 2007 14:10:04 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B374C2@eusrcmw721.eamcs.ericsson.se> Donald, Perhaps all of these things are true. So what? The argument that a lot of people would like to do X could be used to do a lot of things. I'd like us to make maple walnut waffle-cones - possibly with caramel on top. Ummm, does that sound good! What does ANY of this have to do with TRILL? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Wednesday, October 03, 2007 2:25 PM > To: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Hi Eric, > > I believe the generally understood meaning of point-to-point is a link > with exactly two devices on it, in this case RBridges. > > It is true that one could always do this sort of thing outside the > standards. But in Chicago the working group appeared to > believe this was > sufficiently important to say in the standard and, while the consensus > in the room was not that detailed, I got the general impression that > people would be favorable to, in a later management document, having a > MIB variable that would enable one to configure an interface as being > known point-to-point, possibly point-to-point, or prohibited > from using > this point-to-point outer address flexibility, or some such management > configuration feature. There also seemed to have been at least some > interest in an automated way of determining that an interface was > point-to-point, perhaps based on the receive of 802.1AB frames all > containing appropriate indications coupled with the receipt > of no native > frames. > > Point-to-point links are, in fact, very common in modern > 802.3 networks. > > Donald > > -----Original Message----- > From: Eric Gray [mailto:eric.gray at ericsson.com] > Sent: Wednesday, October 03, 2007 11:11 AM > To: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > Donald, > > Given that it is not crystal clear what you mean by > "point to point link", I am not sure I agree with this, at > least as you have worded it here. > > If you mean that the link is a full-duplex Ethernet > link and the two end-points have some definitive mechansim > for determining that they are the only entities using the > link between them, there may be issues with doing this. > > For example, if the link is technically an Ethernet > link, then it is not unlikely that one or the other devices > may have multiple roles - i.e. - it may be both an RBridge > for some frames and either a regular bridge or end station > (for example, a router) for others. It's arguable that, in > this case, the multi-role device is two (or more) separate > entities - thus invalidating a "point to point" definition > for this case (though only two distinct physical devices > are connected via this link). > > Without a clear agreement between involved entities, > this sort of "short-cut" addressing is likely to result in > higher-level (slow path) processing of many (if not all) > of the frames transiting the link for some implementations. > Moreover, without an unambiguous determination of exactly > when this would apply, it will not be unambiguously clear > when a receiving implementation would have to switch to a > "promiscuous listening" mode. > > I believe omission of the outer VLAN tag suffers from > the same ambiguity. For instance, it is possible for two > devices to have a "point to point" relationship within a > VLAN context that would nto be the case without the VLAN > context. > > Hence it appears we would have to be explicit in what > we mean by "point to point" link and how we expect that the > entities (RBridges) involved would be able to disambiguate > this p2p status for any given link. > > If we are saying that two devices - using some means > out of scope for our specification - are somehow aware of an > unambiguous point-to-point relationship between them and can > therefore use any MAC DA on transmission, and ignore it on > receipt, we could make the same argument for virtually any > encapsulation choice we might prefer. But, it would be as > valid to observe that we don't need to specify what is - in > essence - an out-of-context (mis)behavior between consenting > implementations... > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, October 02, 2007 11:27 PM > > To: Rbridge at postel.org > > Subject: [rbridge] Consensus Check: Point to Point links > > > > This is a check via the mailing list to confirm or refute > an apparent > > consensus from the minutes of the Chicago meeting for a change from > > protocol draft -05: > > > > If it is known that a link is a point to point link between two > > RBridges, then the outer header, if it is an Ethernet header, can > > have any source and/or destination addresses, those > addresses will > > be ignored on receipt, and the outer VLAN tag can be omitted. > > > > If no particular controversy arises over this in the next two > > weeks, we > > will declare it to be the working group consensus. > > > > Thanks, > > Donald & Erik > > > > _______________________________________________ > > 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 ddutt at cisco.com Wed Oct 3 17:23:45 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 03 Oct 2007 17:23:45 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4703DF1E.8020904@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se> <4703DF1E.8020904@isi.edu> Message-ID: <47043291.5080201@cisco.com> The reason this is useful in the spec is that we can have interoperability. The situation is common enough that allowing interoperability simplifies implementations. Dinesh Joe Touch wrote: > Eric Gray wrote: > >> Caitlin, >> > ... > >> I get the sense that you're not disagreeing with either Joe or >> myself. >> > > I agree with the nuances Caitlin is raising; the conclusion is that this > need not be in the spec, as far as we three appear to agree. > > Joe > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 sgai at nuovasystems.com Wed Oct 3 21:15:48 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Wed, 3 Oct 2007 21:15:48 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <47043291.5080201@cisco.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> I totally agree with Dinesh -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Dinesh G Dutt > Sent: Wednesday, October 03, 2007 5:24 PM > To: Joe Touch > Cc: Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > The reason this is useful in the spec is that we can have > interoperability. The situation is common enough that allowing > interoperability simplifies implementations. > > Dinesh > Joe Touch wrote: > > Eric Gray wrote: > > > >> Caitlin, > >> > > ... > > > >> I get the sense that you're not disagreeing with either Joe or > >> myself. > >> > > > > I agree with the nuances Caitlin is raising; the conclusion is that this > > need not be in the spec, as far as we three appear to agree. > > > > Joe > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Wed Oct 3 22:05:56 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Oct 2007 22:05:56 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <470474B4.20901@isi.edu> I can't speak for others, but I'm completely lost on this point. Rbridge is defining a layer on top of ethernet. This pt-pt link stuff sounds like it's redefining the ethernet layer for a special case. Whether it's useful to have ethernet have a definition for a pt-pt case is not relevant to this WG, IMO. It seems at best out of scope, even if it is useful. Can anyone explain why this shouldn't be already handled by ethernet, and if it isn't, why we need to handle it as a special case here? Joe Silvano Gai wrote: > I totally agree with Dinesh > > -- Silvano > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On >> Behalf Of Dinesh G Dutt >> Sent: Wednesday, October 03, 2007 5:24 PM >> To: Joe Touch >> Cc: Rbridge at postel.org; Caitlin Bestler >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> The reason this is useful in the spec is that we can have >> interoperability. The situation is common enough that allowing >> interoperability simplifies implementations. >> >> Dinesh >> Joe Touch wrote: >>> Eric Gray wrote: >>> >>>> Caitlin, >>>> >>> ... >>> >>>> I get the sense that you're not disagreeing with either Joe or >>>> myself. >>>> >>> I agree with the nuances Caitlin is raising; the conclusion is that > this >>> need not be in the spec, as far as we three appear to agree. >>> >>> Joe >>> >>> >>> > ------------------------------------------------------------------------ >>> _______________________________________________ >>> 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 >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/44d93aba/signature.bin From sgai at nuovasystems.com Wed Oct 3 22:12:07 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Wed, 3 Oct 2007 22:12:07 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <470474B4.20901@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> Joe, The majority of RBridges will be deployed in backbone where they will be connected by point-to-point links. The classical case will be 10GE links (which are only full-duplex). There will be no bridges between them. What we are asking is a sentence that guarantees a simplified interoperability in this case. I don't see what harm it can do. -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Wednesday, October 03, 2007 10:06 PM > To: Silvano Gai > Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > I can't speak for others, but I'm completely lost on this point. Rbridge > is defining a layer on top of ethernet. This pt-pt link stuff sounds > like it's redefining the ethernet layer for a special case. > > Whether it's useful to have ethernet have a definition for a pt-pt case > is not relevant to this WG, IMO. It seems at best out of scope, even if > it is useful. > > Can anyone explain why this shouldn't be already handled by ethernet, > and if it isn't, why we need to handle it as a special case here? > > Joe > > Silvano Gai wrote: > > I totally agree with Dinesh > > > > -- Silvano > > > >> -----Original Message----- > >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > > On > >> Behalf Of Dinesh G Dutt > >> Sent: Wednesday, October 03, 2007 5:24 PM > >> To: Joe Touch > >> Cc: Rbridge at postel.org; Caitlin Bestler > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> The reason this is useful in the spec is that we can have > >> interoperability. The situation is common enough that allowing > >> interoperability simplifies implementations. > >> > >> Dinesh > >> Joe Touch wrote: > >>> Eric Gray wrote: > >>> > >>>> Caitlin, > >>>> > >>> ... > >>> > >>>> I get the sense that you're not disagreeing with either Joe or > >>>> myself. > >>>> > >>> I agree with the nuances Caitlin is raising; the conclusion is that > > this > >>> need not be in the spec, as far as we three appear to agree. > >>> > >>> Joe > >>> > >>> > >>> > > ------------------------------------------------------------------------ > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> rbridge mailing list > >> rbridge at postel.org > >> http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Wed Oct 3 22:25:32 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Oct 2007 22:25:32 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <4704794C.3080707@isi.edu> Silvano Gai wrote: > Joe, > > The majority of RBridges will be deployed in backbone where they will be > connected by point-to-point links. The classical case will be 10GE links > (which are only full-duplex). There will be no bridges between them. > > What we are asking is a sentence that guarantees a simplified > interoperability in this case. > > I don't see what harm it can do. I don't see the need to specify a new, non-ethernet link layer. If this maps to "point to point links can use encapsulation-only ethernet" (I'm familiar with such a thing; does it ignore addresses and use the MAC only for the CRC? if so, what is it called exactly?), and we can point to that, then there's no need for us to define it. If no such thing exists, then it might be useful to raise this in the IEEE. I don't see why it is more relevant to rbridges than to any other kind of bridge - for which pt-pt interconnections are also already used. Joe > > -- Silvano > > >> -----Original Message----- >> From: Joe Touch [mailto:touch at ISI.EDU] >> Sent: Wednesday, October 03, 2007 10:06 PM >> To: Silvano Gai >> Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> I can't speak for others, but I'm completely lost on this point. > Rbridge >> is defining a layer on top of ethernet. This pt-pt link stuff sounds >> like it's redefining the ethernet layer for a special case. >> >> Whether it's useful to have ethernet have a definition for a pt-pt > case >> is not relevant to this WG, IMO. It seems at best out of scope, even > if >> it is useful. >> >> Can anyone explain why this shouldn't be already handled by ethernet, >> and if it isn't, why we need to handle it as a special case here? >> >> Joe >> >> Silvano Gai wrote: >>> I totally agree with Dinesh >>> >>> -- Silvano >>> >>>> -----Original Message----- >>>> From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] >>> On >>>> Behalf Of Dinesh G Dutt >>>> Sent: Wednesday, October 03, 2007 5:24 PM >>>> To: Joe Touch >>>> Cc: Rbridge at postel.org; Caitlin Bestler >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links >>>> >>>> The reason this is useful in the spec is that we can have >>>> interoperability. The situation is common enough that allowing >>>> interoperability simplifies implementations. >>>> >>>> Dinesh >>>> Joe Touch wrote: >>>>> Eric Gray wrote: >>>>> >>>>>> Caitlin, >>>>>> >>>>> ... >>>>> >>>>>> I get the sense that you're not disagreeing with either Joe or >>>>>> myself. >>>>>> >>>>> I agree with the nuances Caitlin is raising; the conclusion is > that >>> this >>>>> need not be in the spec, as far as we three appear to agree. >>>>> >>>>> Joe >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/2a20358c/signature-0001.bin From sgai at nuovasystems.com Wed Oct 3 22:41:59 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Wed, 3 Oct 2007 22:41:59 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4704794C.3080707@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> <4704794C.3080707@isi.edu> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> Joe, Nobody is asking "to specify a new, non-ethernet link layer." We are just asking to have a reserved MAC address that means "the other end of the link". The frame is still 100% compliant with Ethernet. -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Wednesday, October 03, 2007 10:26 PM > To: Silvano Gai > Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Silvano Gai wrote: > > Joe, > > > > The majority of RBridges will be deployed in backbone where they will be > > connected by point-to-point links. The classical case will be 10GE links > > (which are only full-duplex). There will be no bridges between them. > > > > What we are asking is a sentence that guarantees a simplified > > interoperability in this case. > > > > I don't see what harm it can do. > > I don't see the need to specify a new, non-ethernet link layer. > > If this maps to "point to point links can use encapsulation-only > ethernet" (I'm familiar with such a thing; does it ignore addresses and > use the MAC only for the CRC? if so, what is it called exactly?), and we > can point to that, then there's no need for us to define it. > > If no such thing exists, then it might be useful to raise this in the > IEEE. I don't see why it is more relevant to rbridges than to any other > kind of bridge - for which pt-pt interconnections are also already used. > > Joe > > > > > -- Silvano > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch at ISI.EDU] > >> Sent: Wednesday, October 03, 2007 10:06 PM > >> To: Silvano Gai > >> Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> I can't speak for others, but I'm completely lost on this point. > > Rbridge > >> is defining a layer on top of ethernet. This pt-pt link stuff sounds > >> like it's redefining the ethernet layer for a special case. > >> > >> Whether it's useful to have ethernet have a definition for a pt-pt > > case > >> is not relevant to this WG, IMO. It seems at best out of scope, even > > if > >> it is useful. > >> > >> Can anyone explain why this shouldn't be already handled by ethernet, > >> and if it isn't, why we need to handle it as a special case here? > >> > >> Joe > >> > >> Silvano Gai wrote: > >>> I totally agree with Dinesh > >>> > >>> -- Silvano > >>> > >>>> -----Original Message----- > >>>> From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] > >>> On > >>>> Behalf Of Dinesh G Dutt > >>>> Sent: Wednesday, October 03, 2007 5:24 PM > >>>> To: Joe Touch > >>>> Cc: Rbridge at postel.org; Caitlin Bestler > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links > >>>> > >>>> The reason this is useful in the spec is that we can have > >>>> interoperability. The situation is common enough that allowing > >>>> interoperability simplifies implementations. > >>>> > >>>> Dinesh > >>>> Joe Touch wrote: > >>>>> Eric Gray wrote: > >>>>> > >>>>>> Caitlin, > >>>>>> > >>>>> ... > >>>>> > >>>>>> I get the sense that you're not disagreeing with either Joe or > >>>>>> myself. > >>>>>> > >>>>> I agree with the nuances Caitlin is raising; the conclusion is > > that > >>> this > >>>>> need not be in the spec, as far as we three appear to agree. > >>>>> > >>>>> Joe > >>>>> > >>>>> > >>>>> > > ------------------------------------------------------------------------ > >>>>> _______________________________________________ > >>>>> 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 > >>>> _______________________________________________ > >>>> rbridge mailing list > >>>> rbridge at postel.org > >>>> http://mailman.postel.org/mailman/listinfo/rbridge > > From touch at ISI.EDU Wed Oct 3 22:47:58 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Oct 2007 22:47:58 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> <4704794C.3080707@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <47047E8E.5040600@isi.edu> Silvano Gai wrote: > Joe, > > Nobody is asking "to specify a new, non-ethernet link layer." > > We are just asking to have a reserved MAC address that means "the other > end of the link". > > The frame is still 100% compliant with Ethernet. If regular ethernet and regular bridges don't need this, why do rbridges? (bridges are already connected by such pt-pt links) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/63bf8d38/signature.bin From sgai at nuovasystems.com Wed Oct 3 22:56:27 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Wed, 3 Oct 2007 22:56:27 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <47047E8E.5040600@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu> <47043291.5080201@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com> <470474B4.20901@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com> <4704794C.3080707@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> <47047E8E.5040600@isi.edu> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> Because Bridges are never addressed at the MAC layer, RBridges instead are! -- Silvano > -----Original Message----- > From: Joe Touch [mailto:touch at ISI.EDU] > Sent: Wednesday, October 03, 2007 10:48 PM > To: Silvano Gai > Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Silvano Gai wrote: > > Joe, > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > We are just asking to have a reserved MAC address that means "the other > > end of the link". > > > > The frame is still 100% compliant with Ethernet. > > If regular ethernet and regular bridges don't need this, why do rbridges? > > (bridges are already connected by such pt-pt links) > > Joe From ddutt at cisco.com Wed Oct 3 23:29:26 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 03 Oct 2007 23:29:26 -0700 Subject: [rbridge] Consensus Check: Egress processing of unicast not locally known In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> Message-ID: <47048846.5090605@cisco.com> Donald, This is different from existing IEEE 802.1D bridges. I'm OK with it, as long as it is a MAY and not a MUST or a SHOULD. I'm worried that misconfigurations and such can cause silent packet drops which can be hard to debug. Dinesh Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > Egress RBridges that receive a known unicast TRILL data frame whose > inner destination address is not known locally should send the > native form of the frame out on every link for which the RBridge > is DRB for the frame's VLAN unless it knows that an end station > with that MAC address could not be on that link. (For example, > there is a layer-2 registration procedure for end stations on that > link and the destination MAC address in question is not > registered.) This is a local decision. No "error" message will be > defined for this condition at this time. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > 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 ddutt at cisco.com Wed Oct 3 23:33:08 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 03 Oct 2007 23:33:08 -0700 Subject: [rbridge] Consensus Check: Egress processing of unicast not locallyknown In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7AFE55@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D9790031840B9@de01exm64.ds.mot.com> <4C94DE2070B172459E4F1EE14BD2364E7AFE55@HQ-EXCH-5.corp.brocade.com> Message-ID: <47048924.9040102@cisco.com> Anoop, Did you mean that in the example that he quoted the reason for dropping the frame was access control (such as 802.1x authenticated) ? To me access control is a very generic term that can also include things such as security ACLs. "Access Control" is orthogonal to forwarding. For example, I can have IP FIB entries or MAC table entries associated with a frame, but can drop a specific frame such as those going to "port 80" as part of access control. What Donald is specifying *seems* to be in addition to access control. Dinesh Anoop Ghanwani wrote: > I'm not sure why the case of "MAC address could > not be on that link" needs to be called out at all. > That is an access control issue. But I am OK > with having it if someone really feels strongly > about it. > > Anoop > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III >> Donald-LDE008 >> Sent: Tuesday, October 02, 2007 8:25 PM >> To: Rbridge at postel.org >> Subject: [rbridge] Consensus Check: Egress processing of >> unicast not locallyknown >> >> This is a check via the mailing list to confirm or refute an >> apparent consensus from the minutes of the Chicago meeting >> for a change from protocol draft -05: >> >> Egress RBridges that receive a known unicast TRILL data frame whose >> inner destination address is not known locally should send the >> native form of the frame out on every link for which the RBridge >> is DRB for the frame's VLAN unless it knows that an end station >> with that MAC address could not be on that link. (For example, >> there is a layer-2 registration procedure for end stations on that >> link and the destination MAC address in question is not >> registered.) This is a local decision. No "error" message will be >> defined for this condition at this time. >> >> If no particular controversy arises over this in the next two >> weeks, we will declare it to be the working group consensus. >> >> Thanks, >> Donald & Erik >> >> _______________________________________________ >> 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 From eric.gray at ericsson.com Thu Oct 4 05:23:33 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 4 Oct 2007 07:23:33 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B37906@eusrcmw721.eamcs.ericsson.se> Silvano, This is NOT AT ALL what Donald said. Having a reserved MAC address for the other end of a link is completely different from saying "any MAC address may be used and MUST be ignored on receipt." As for this - cleary different - proposal, I think it is quite reasonable, but almost certainly not something for us to do - HERE. As Joe points out, this is a general problem that should be addresses generally, rather than here and just for RBridges. This should be done via the IEEE. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > Sent: Thursday, October 04, 2007 1:42 AM > To: Joe Touch > Cc: Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Joe, > > Nobody is asking "to specify a new, non-ethernet link layer." > > We are just asking to have a reserved MAC address that means > "the other > end of the link". > > The frame is still 100% compliant with Ethernet. > > -- Silvano > > > -----Original Message----- > > From: Joe Touch [mailto:touch at ISI.EDU] > > Sent: Wednesday, October 03, 2007 10:26 PM > > To: Silvano Gai > > Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > > > > Silvano Gai wrote: > > > Joe, > > > > > > The majority of RBridges will be deployed in backbone where they > will be > > > connected by point-to-point links. The classical case will be 10GE > links > > > (which are only full-duplex). There will be no bridges > between them. > > > > > > What we are asking is a sentence that guarantees a simplified > > > interoperability in this case. > > > > > > I don't see what harm it can do. > > > > I don't see the need to specify a new, non-ethernet link layer. > > > > If this maps to "point to point links can use encapsulation-only > > ethernet" (I'm familiar with such a thing; does it ignore addresses > and > > use the MAC only for the CRC? if so, what is it called > exactly?), and > we > > can point to that, then there's no need for us to define it. > > > > If no such thing exists, then it might be useful to raise > this in the > > IEEE. I don't see why it is more relevant to rbridges than to any > other > > kind of bridge - for which pt-pt interconnections are also already > used. > > > > Joe > > > > > > > > -- Silvano > > > > > > > > >> -----Original Message----- > > >> From: Joe Touch [mailto:touch at ISI.EDU] > > >> Sent: Wednesday, October 03, 2007 10:06 PM > > >> To: Silvano Gai > > >> Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > > >> > > >> I can't speak for others, but I'm completely lost on this point. > > > Rbridge > > >> is defining a layer on top of ethernet. This pt-pt link stuff > sounds > > >> like it's redefining the ethernet layer for a special case. > > >> > > >> Whether it's useful to have ethernet have a definition > for a pt-pt > > > case > > >> is not relevant to this WG, IMO. It seems at best out of scope, > even > > > if > > >> it is useful. > > >> > > >> Can anyone explain why this shouldn't be already handled by > ethernet, > > >> and if it isn't, why we need to handle it as a special case here? > > >> > > >> Joe > > >> > > >> Silvano Gai wrote: > > >>> I totally agree with Dinesh > > >>> > > >>> -- Silvano > > >>> > > >>>> -----Original Message----- > > >>>> From: rbridge-bounces at postel.org > > > [mailto:rbridge-bounces at postel.org] > > >>> On > > >>>> Behalf Of Dinesh G Dutt > > >>>> Sent: Wednesday, October 03, 2007 5:24 PM > > >>>> To: Joe Touch > > >>>> Cc: Rbridge at postel.org; Caitlin Bestler > > >>>> Subject: Re: [rbridge] Consensus Check: Point to Point links > > >>>> > > >>>> The reason this is useful in the spec is that we can have > > >>>> interoperability. The situation is common enough that allowing > > >>>> interoperability simplifies implementations. > > >>>> > > >>>> Dinesh > > >>>> Joe Touch wrote: > > >>>>> Eric Gray wrote: > > >>>>> > > >>>>>> Caitlin, > > >>>>>> > > >>>>> ... > > >>>>> > > >>>>>> I get the sense that you're not disagreeing with > either Joe or > > >>>>>> myself. > > >>>>>> > > >>>>> I agree with the nuances Caitlin is raising; the conclusion is > > > that > > >>> this > > >>>>> need not be in the spec, as far as we three appear to agree. > > >>>>> > > >>>>> Joe > > >>>>> > > >>>>> > > >>>>> > > > > -------------------------------------------------------------- > ---------- > > >>>>> _______________________________________________ > > >>>>> 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 > > >>>> _______________________________________________ > > >>>> 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 eric.gray at ericsson.com Thu Oct 4 05:28:36 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 4 Oct 2007 07:28:36 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> Silvano, It is not exactly true that bridges are never addressed at the MAC layer. Consider, for example, how bridges are typically managed using SNMP, or HTML. However, the case is still general, because everything you say about RBridges - and the likelihood that they might be connected via P2P links - similarly applies to other devices (L2 end-stations, such as routers, for example. And objecting that it may (or may not) be easy for these devices to determine that a link is P2P is an argument that applies equally to RBridges. I think it is not possible at this point to argue that there is consensus to do this work here, in the TRILL working group. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > Sent: Thursday, October 04, 2007 1:56 AM > To: Joe Touch > Cc: Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Because Bridges are never addressed at the MAC layer, > RBridges instead are! > > -- Silvano > > > -----Original Message----- > > From: Joe Touch [mailto:touch at ISI.EDU] > > Sent: Wednesday, October 03, 2007 10:48 PM > > To: Silvano Gai > > Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > > > > Silvano Gai wrote: > > > Joe, > > > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > > > We are just asking to have a reserved MAC address that means "the > other > > > end of the link". > > > > > > The frame is still 100% compliant with Ethernet. > > > > If regular ethernet and regular bridges don't need this, why do > rbridges? > > > > (bridges are already connected by such pt-pt links) > > > > Joe > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Thu Oct 4 05:33:15 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 4 Oct 2007 07:33:15 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <47047E8E.5040600@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com> <47047E8E.5040600@isi.edu> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B3791B@eusrcmw721.eamcs.ericsson.se> Joe, While what Silvano says about bridges not (typically) being addressed by MAC address is true, and it is even more likely to be true for neighbor to neighbor communications, I agree that this is a general problem. I can hardly believe that this is the only example ever to come up of a layer-2 forwarding device wanting to have direct - neighbor to neighbor - protocol exchanges. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch > Sent: Thursday, October 04, 2007 1:48 AM > To: Silvano Gai > Cc: Rbridge at postel.org; Caitlin Bestler > Subject: Re: [rbridge] Consensus Check: Point to Point links > > * PGP Signed: 10/04/2007 at 07:47:58 AM > > > Silvano Gai wrote: > > Joe, > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > We are just asking to have a reserved MAC address that > means "the other > > end of the link". > > > > The frame is still 100% compliant with Ethernet. > > If regular ethernet and regular bridges don't need this, why > do rbridges? > > (bridges are already connected by such pt-pt links) > > Joe > > * Joe Touch > * 0x89A766BB (L) > > From sgai at nuovasystems.com Thu Oct 4 07:17:59 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 4 Oct 2007 07:17:59 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> A frame that is switched by a Bridge is NEVER addressed to the Bridge. An encapsulated frame that is switched by an RBridge is ALWAYS addressed to the RBridge. I understand management frames; it is not what we are discussing here. Using a reserved MAC address or ignoring the MAC address on point-to-point links achieves the same goal. Pick one, I don't care. This is a simple and effective solution; I don't understand the need to deny it. -- Silvano > -----Original Message----- > From: Eric Gray [mailto:eric.gray at ericsson.com] > Sent: Thursday, October 04, 2007 5:29 AM > To: Silvano Gai; Joe Touch > Cc: Rbridge at postel.org; Caitlin Bestler > Subject: RE: [rbridge] Consensus Check: Point to Point links > > Silvano, > > It is not exactly true that bridges are never addressed at the > MAC layer. Consider, for example, how bridges are typically managed > using SNMP, or HTML. > > However, the case is still general, because everything you say > about RBridges - and the likelihood that they might be connected via > P2P links - similarly applies to other devices (L2 end-stations, such > as routers, for example. And objecting that it may (or may not) be > easy for these devices to determine that a link is P2P is an argument > that applies equally to RBridges. > > I think it is not possible at this point to argue that there is > consensus to do this work here, in the TRILL working group. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai > > Sent: Thursday, October 04, 2007 1:56 AM > > To: Joe Touch > > Cc: Rbridge at postel.org; Caitlin Bestler > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Because Bridges are never addressed at the MAC layer, > > RBridges instead are! > > > > -- Silvano > > > > > -----Original Message----- > > > From: Joe Touch [mailto:touch at ISI.EDU] > > > Sent: Wednesday, October 03, 2007 10:48 PM > > > To: Silvano Gai > > > Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler > > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > > > > > > > > Silvano Gai wrote: > > > > Joe, > > > > > > > > Nobody is asking "to specify a new, non-ethernet link layer." > > > > > > > > We are just asking to have a reserved MAC address that means "the > > other > > > > end of the link". > > > > > > > > The frame is still 100% compliant with Ethernet. > > > > > > If regular ethernet and regular bridges don't need this, why do > > rbridges? > > > > > > (bridges are already connected by such pt-pt links) > > > > > > Joe > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > From Radia.Perlman at sun.com Thu Oct 4 08:50:34 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 04 Oct 2007 08:50:34 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> Message-ID: <47050BCA.5030003@sun.com> Personally, I need a reminder of what we are trying to accomplish with this before I can have any opinion. a) Is omitting the outer VLAN tag to save space? b) Why put in anything for destination address other than the MAC address of the next hop RBridge, or put in anything into the source address other than your own MAC address? It won't save space. So what does it gain? c) Is there any danger if an RBridge is confused about whether this is a pt-to-pt link or not? I can see the advantage of omitting the entire outer header if it is somehow absolutely known this is a pt-to-pt link, and both ends of the link understand this. But that isn't what's being proposed here. It seems to be only omitting the VLAN tag, and allowing insertion of random addresses into the source and destination fields in the outer header, if I'm reading it correctly. So anyway, clarification at this point would certainly help me. Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Caitlin.Bestler at neterion.com Thu Oct 4 09:58:09 2007 From: Caitlin.Bestler at neterion.com (Caitlin Bestler) Date: Thu, 4 Oct 2007 12:58:09 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77024E983F@nekter> Why wouldn't a "other end of the link" reserved MAC address be just as applicable for core Routers that are directly connected to each other point-to-point? From anoop at brocade.com Thu Oct 4 10:45:47 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Thu, 4 Oct 2007 10:45:47 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <47050BCA.5030003@sun.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 04, 2007 8:51 AM > To: Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Personally, I need a reminder of what we are trying to > accomplish with this before I can have any opinion. > > a) Is omitting the outer VLAN tag to save space? > b) Why put in anything for destination address other than the > MAC address of the next hop RBridge, or put in anything into > the source address other than your own MAC address? > It won't save space. So what does it gain? > c) Is there any danger if an RBridge is confused about > whether this is a pt-to-pt link or not? > > I can see the advantage of omitting the entire outer header > if it is somehow absolutely known this is a pt-to-pt link, > and both ends of the link understand this. That wouldn't work because there are other frames that will have to have MAC addresses, e.g. LACP, LLDP. > But that isn't > what's being proposed here. It seems to be only omitting the > VLAN tag, and allowing insertion of random addresses into the > source and destination fields in the outer header, if I'm > reading it correctly. I don't like the idea of random addresses (is it that a big a deal to set them correctly?), but as long as it's completely optional, I don't really care. [By the way, even though the proposal says that it can be random, it really can't because we have to say that they cannot be from the BPDU address space or things like LACP and LLDP will break.] Anoop From eric.gray at ericsson.com Thu Oct 4 12:08:52 2007 From: eric.gray at ericsson.com (Eric Gray) Date: Thu, 4 Oct 2007 14:08:52 -0500 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01B3802A@eusrcmw721.eamcs.ericsson.se> Anoop, Making it completely optional is a problem as well, and this is where I am having the most difficulty - particular with "random" addresses that require ignoring. The issue is that this is a wrong-way-around unilateral choice - i.e. - it is the sender that we say might have the option of doing this, but the receiver that has the complexity of supporting either way of doing it. If the entity making the choice was also the one having to pay for it, then I would agree that making it a choice would be okay. That does not seem to be the case! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani > Sent: Thursday, October 04, 2007 1:46 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > > Sent: Thursday, October 04, 2007 8:51 AM > > To: Eastlake III Donald-LDE008 > > Cc: Rbridge at postel.org > > Subject: Re: [rbridge] Consensus Check: Point to Point links > > > > Personally, I need a reminder of what we are trying to > > accomplish with this before I can have any opinion. > > > > a) Is omitting the outer VLAN tag to save space? > > b) Why put in anything for destination address other than the > > MAC address of the next hop RBridge, or put in anything into > > the source address other than your own MAC address? > > It won't save space. So what does it gain? > > c) Is there any danger if an RBridge is confused about > > whether this is a pt-to-pt link or not? > > > > I can see the advantage of omitting the entire outer header > > if it is somehow absolutely known this is a pt-to-pt link, > > and both ends of the link understand this. > > That wouldn't work because there are other frames that will > have to have MAC addresses, e.g. LACP, LLDP. > > > But that isn't > > what's being proposed here. It seems to be only omitting the > > VLAN tag, and allowing insertion of random addresses into the > > source and destination fields in the outer header, if I'm > > reading it correctly. > > I don't like the idea of random addresses (is it that > a big a deal to set them correctly?), but as long as > it's completely optional, I don't really care. > [By the way, even though the proposal says that it > can be random, it really can't because we have to > say that they cannot be from the BPDU address space > or things like LACP and LLDP will break.] > > Anoop > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Thu Oct 4 21:14:14 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 5 Oct 2007 00:14:14 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> Actually, although I'm not entirely sure, I believe that BPDUs, LLDP PDUs, etc., all start with an Ethertype which identifies them so, in principle, they could be made to work on a specially equipped point to point link with no outer MAC addresses. However, I don't think anyone has proposed that TRILL should consider omitting the outer MAC addresses except when that suggestion appears as part of a question asking why, if you want to do some optimization on a point-to-point link, you don't want to do even more optimization. Donald -----Original Message----- From: Anoop Ghanwani [mailto:anoop at brocade.com] Sent: Thursday, October 04, 2007 1:46 PM To: Radia Perlman; Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Thursday, October 04, 2007 8:51 AM > To: Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Personally, I need a reminder of what we are trying to > accomplish with this before I can have any opinion. > > a) Is omitting the outer VLAN tag to save space? > b) Why put in anything for destination address other than the > MAC address of the next hop RBridge, or put in anything into > the source address other than your own MAC address? > It won't save space. So what does it gain? > c) Is there any danger if an RBridge is confused about > whether this is a pt-to-pt link or not? > > I can see the advantage of omitting the entire outer header > if it is somehow absolutely known this is a pt-to-pt link, > and both ends of the link understand this. That wouldn't work because there are other frames that will have to have MAC addresses, e.g. LACP, LLDP. > But that isn't > what's being proposed here. It seems to be only omitting the > VLAN tag, and allowing insertion of random addresses into the > source and destination fields in the outer header, if I'm > reading it correctly. I don't like the idea of random addresses (is it that a big a deal to set them correctly?), but as long as it's completely optional, I don't really care. [By the way, even though the proposal says that it can be random, it really can't because we have to say that they cannot be from the BPDU address space or things like LACP and LLDP will break.] Anoop From Donald.Eastlake at motorola.com Thu Oct 4 21:24:16 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 5 Oct 2007 00:24:16 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <47050BCA.5030003@sun.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> Hi Radia, See below at @@@ -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman at sun.com] Sent: Thursday, October 04, 2007 11:51 AM To: Eastlake III Donald-LDE008 Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Personally, I need a reminder of what we are trying to accomplish with this before I can have any opinion. a) Is omitting the outer VLAN tag to save space? @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point link. b) Why put in anything for destination address other than the MAC address of the next hop RBridge, or put in anything into the source address other than your own MAC address? It won't save space. So what does it gain? @@@ While no one has given a really crisp response to that question, it is my impression that some believe it will make it possible to produce simpler, less expensive, or more efficient hardware for this case. c) Is there any danger if an RBridge is confused about whether this is a pt-to-pt link or not? @@@ I think there might be. And because of this and the extreme commonness of the point-to-point case, it may be reasonable to consider this in designing TRILL. For example, if a fixed MAC address were used (such as the unicast version of the All-Rbridges multicast address (just turn off the group bit)), then an interface receiving a frame with that source address would know there was a sender on the link who believes the link was point-to-point. If the receiver knows it is not point-to-point or is unwilling to handle such frames, it could take appropriate action. Also, Rbridge would know to never bother "learning" the location of that MAC address. @@@ Thanks, @@@ Donald I can see the advantage of omitting the entire outer header if it is somehow absolutely known this is a pt-to-pt link, and both ends of the link understand this. But that isn't what's being proposed here. It seems to be only omitting the VLAN tag, and allowing insertion of random addresses into the source and destination fields in the outer header, if I'm reading it correctly. So anyway, clarification at this point would certainly help me. Eastlake III Donald-LDE008 wrote: > This is a check via the mailing list to confirm or refute an apparent > consensus from the minutes of the Chicago meeting for a change from > protocol draft -05: > > If it is known that a link is a point to point link between two > RBridges, then the outer header, if it is an Ethernet header, can > have any source and/or destination addresses, those addresses will > be ignored on receipt, and the outer VLAN tag can be omitted. > > If no particular controversy arises over this in the next two weeks, we > will declare it to be the working group consensus. > > Thanks, > Donald & Erik > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Thu Oct 4 21:28:36 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 5 Oct 2007 00:28:36 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01B374C2@eusrcmw721.eamcs.ericsson.se> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D97900318431B@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCF01B374C2@eusrcmw721.eamcs.ericsson.se> Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD2C@de01exm64.ds.mot.com> Eric, Well, even if a consensus of the working group wanted to do maple walnut waffle-cones with caramel, there is a problem that, as far as I can see, that isn't in our Charter. But I think that this is related enough to TRILL, as I will explain, that it would be OK to include in our output if the working group wants to do so. 802.3-like interfaces for point-to-point use as indicated here can be practical for Rbridge but not for 802.1 bridges because of the characteristics of the TRILL protocol. In TRILL, the outer VLAN tag is just an artifact for getting to the next Rbridge (or Rbridges) for TRILL EtherType frames. In a point-to-point link between Rbridges, that tag and the outer MAC addresses are not logically necessary for TRILL frames. Then tag can be omitted and the addresses can be a value ignored on receipt. However, whether you could implenent this feature is influenced by the design of TRILL. For example, I believe the current protocol spec says that local sources/sinks of frames on an Rbridge (for example SNMP) are treated as if they were on a virtual port out of the Rbridge. That means that, between two Rbridges, such frames area always encapsulated, even if we has an Rbridge with a co-located management station talking to an SNMP implementtion in a second Rbridge just one point-to-point link away. If, in this case, such frames were sent in native form, it seems to me it would at least make it a more difficult to use, for example, a fixed MAC address interface or to correctly detect when the assumption that the interface in point-to-point is incorrect. Thus, even if this feature isn't mentioned in the TRILL effect, the difficulty and perhaps even the possibility of implementing it could be affected by details of the TRILL protocol. There is also the question of whether the use of such an interface for a link should be indicated in the Rbridge MIB, although if a fixed know MAC address were used, I believe that could simply be checked for in the MIB. Donald -----Original Message----- From: Eric Gray [mailto:eric.gray at ericsson.com] Sent: Wednesday, October 03, 2007 3:10 PM To: Eastlake III Donald-LDE008; Rbridge at postel.org Subject: RE: [rbridge] Consensus Check: Point to Point links Donald, Perhaps all of these things are true. So what? The argument that a lot of people would like to do X could be used to do a lot of things. I'd like us to make maple walnut waffle-cones - possibly with caramel on top. Ummm, does that sound good! What does ANY of this have to do with TRILL? -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Wednesday, October 03, 2007 2:25 PM > To: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Hi Eric, > > I believe the generally understood meaning of point-to-point is a link > with exactly two devices on it, in this case RBridges. > > It is true that one could always do this sort of thing outside the > standards. But in Chicago the working group appeared to > believe this was > sufficiently important to say in the standard and, while the consensus > in the room was not that detailed, I got the general impression that > people would be favorable to, in a later management document, having a > MIB variable that would enable one to configure an interface as being > known point-to-point, possibly point-to-point, or prohibited > from using > this point-to-point outer address flexibility, or some such management > configuration feature. There also seemed to have been at least some > interest in an automated way of determining that an interface was > point-to-point, perhaps based on the receive of 802.1AB frames all > containing appropriate indications coupled with the receipt > of no native > frames. > > Point-to-point links are, in fact, very common in modern > 802.3 networks. > > Donald > > -----Original Message----- > From: Eric Gray [mailto:eric.gray at ericsson.com] > Sent: Wednesday, October 03, 2007 11:11 AM > To: Eastlake III Donald-LDE008; Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > Donald, > > Given that it is not crystal clear what you mean by > "point to point link", I am not sure I agree with this, at > least as you have worded it here. > > If you mean that the link is a full-duplex Ethernet > link and the two end-points have some definitive mechansim > for determining that they are the only entities using the > link between them, there may be issues with doing this. > > For example, if the link is technically an Ethernet > link, then it is not unlikely that one or the other devices > may have multiple roles - i.e. - it may be both an RBridge > for some frames and either a regular bridge or end station > (for example, a router) for others. It's arguable that, in > this case, the multi-role device is two (or more) separate > entities - thus invalidating a "point to point" definition > for this case (though only two distinct physical devices > are connected via this link). > > Without a clear agreement between involved entities, > this sort of "short-cut" addressing is likely to result in > higher-level (slow path) processing of many (if not all) > of the frames transiting the link for some implementations. > Moreover, without an unambiguous determination of exactly > when this would apply, it will not be unambiguously clear > when a receiving implementation would have to switch to a > "promiscuous listening" mode. > > I believe omission of the outer VLAN tag suffers from > the same ambiguity. For instance, it is possible for two > devices to have a "point to point" relationship within a > VLAN context that would not be the case without the VLAN > context. > > Hence it appears we would have to be explicit in what > we mean by "point to point" link and how we expect that the > entities (RBridges) involved would be able to disambiguate > this p2p status for any given link. > > If we are saying that two devices - using some means > out of scope for our specification - are somehow aware of an > unambiguous point-to-point relationship between them and can > therefore use any MAC DA on transmission, and ignore it on > receipt, we could make the same argument for virtually any > encapsulation choice we might prefer. But, it would be as > valid to observe that we don't need to specify what is - in > essence - an out-of-context (mis)behavior between consenting > implementations... > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces at postel.org > > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > > Donald-LDE008 > > Sent: Tuesday, October 02, 2007 11:27 PM > > To: Rbridge at postel.org > > Subject: [rbridge] Consensus Check: Point to Point links > > > > This is a check via the mailing list to confirm or refute > an apparent > > consensus from the minutes of the Chicago meeting for a change from > > protocol draft -05: > > > > If it is known that a link is a point to point link between two > > RBridges, then the outer header, if it is an Ethernet header, can > > have any source and/or destination addresses, those > addresses will > > be ignored on receipt, and the outer VLAN tag can be omitted. > > > > If no particular controversy arises over this in the next two > > weeks, we > > will declare it to be the working group consensus. > > > > Thanks, > > Donald & Erik > > > > _______________________________________________ > > 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 Donald.Eastlake at motorola.com Thu Oct 4 21:29:44 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 5 Oct 2007 00:29:44 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77024E983F@nekter> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><941D5DCD8C42014FAF70FB7424686DCF01B370EA@eusrcmw721.eamcs.ericsson.se> <4703CE6C.7090306@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77024E9567@nekter> <941D5DCD8C42014FAF70FB7424686DCF01B373E8@eusrcmw721.eamcs.ericsson.se><4703DF1E.8020904@isi.edu><47043291.5080201@cisco.com><34BDD2A93E5FD84594BB230DD6C18EA2022DDB6D@nuova-ex1.hq.nuovaimpresa.com><470474B4.20901@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB82@nuova-ex1.hq.nuovaimpresa.com><4704794C.3080707@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB8E@nuova-ex1.hq.nuovaimpresa.com><47047E8E.5040600@isi.edu><34BDD2A93E5FD84594BB230DD6C18EA2022DDB9B@nuova-ex1.hq.nuovaimpresa.com><941D5DCD8C42014FAF70FB7424686DCF01B37911@eusrcmw721.eamcs.ericsson.se><34BDD2A93E5FD84594BB230DD6C18EA2022DDC14@nuova-ex1.hq.nuovaimpresa.com> <78C9135A3D2ECE4B8162EBDCE82CAD77024E983F@nekter> Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD2D@de01exm64.ds.mot.com> Hi Caitlin, It is my understanding that some IETF routing protocols do have special provisions for "un-numbered links" but by that they mean that IP addresses are not allocated for the ends of the links. This is a precedent for not allocating layer-N addresses for a layer-N protocol on a layer-N-point-to-point link, although in this case N=3. Layer-3 routing protocols generally aren't concerned with layer-2 addresses or even what layer-2 protocol is running on the link... Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler Sent: Thursday, October 04, 2007 12:58 PM To: Silvano Gai; Eric Gray; Joe Touch Cc: Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Why wouldn't a "other end of the link" reserved MAC address be just as applicable for core Routers that are directly connected to each other point-to-point? _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From sgai at nuovasystems.com Thu Oct 4 21:53:48 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Thu, 4 Oct 2007 21:53:48 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> I agree with Donald on all points. The saving comes from not having to maintain an adjacency table on high speed point-to-point links. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Eastlake III Donald-LDE008 > Sent: Thursday, October 04, 2007 9:24 PM > To: Radia Perlman > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Hi Radia, > > See below at @@@ > > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Thursday, October 04, 2007 11:51 AM > To: Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] Consensus Check: Point to Point links > > Personally, I need a reminder of what we are trying to accomplish with > this before I can have > any opinion. > > a) Is omitting the outer VLAN tag to save space? > > @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point > link. > > b) Why put in anything for destination address other than the MAC > address of the next hop > RBridge, or put in anything into the source address other than your own > MAC address? > It won't save space. So what does it gain? > > @@@ While no one has given a really crisp response to that question, it > is my impression that some believe it will make it possible to produce > simpler, less expensive, or more efficient hardware for this case. > > c) Is there any danger if an RBridge is confused about whether this is a > > pt-to-pt link or not? > > @@@ I think there might be. And because of this and the extreme > commonness of the point-to-point case, it may be reasonable to consider > this in designing TRILL. For example, if a fixed MAC address were used > (such as the unicast version of the All-Rbridges multicast address (just > turn off the group bit)), then an interface receiving a frame with that > source address would know there was a sender on the link who believes > the link was point-to-point. If the receiver knows it is not > point-to-point or is unwilling to handle such frames, it could take > appropriate action. Also, Rbridge would know to never bother "learning" > the location of that MAC address. > > @@@ Thanks, > @@@ Donald > > I can see the advantage of omitting the entire outer header if it is > somehow absolutely > known this is a pt-to-pt link, and both ends of the link understand > this. But that isn't what's > being proposed here. It seems to be only omitting the VLAN tag, and > allowing insertion of > random addresses into the source and destination fields in the outer > header, if I'm reading > it correctly. > > So anyway, clarification at this point would certainly help me. > > > Eastlake III Donald-LDE008 wrote: > > This is a check via the mailing list to confirm or refute an apparent > > consensus from the minutes of the Chicago meeting for a change from > > protocol draft -05: > > > > If it is known that a link is a point to point link between two > > RBridges, then the outer header, if it is an Ethernet header, can > > have any source and/or destination addresses, those addresses will > > be ignored on receipt, and the outer VLAN tag can be omitted. > > > > If no particular controversy arises over this in the next two weeks, > we > > will declare it to be the working group consensus. > > > > Thanks, > > Donald & Erik > > > > _______________________________________________ > > 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 ddutt at cisco.com Thu Oct 4 23:05:39 2007 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 04 Oct 2007 23:05:39 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> Message-ID: <4705D433.5010902@cisco.com> Hi Donald, BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM are identified by ethertype and there is supposedly a move to identify newer BPDUs using ethertype. The frames we're talking of sending with a fixed (or reserved) address are the data frames. BPDUs including IS-IS will use the regular MAC address. Dinesh Eastlake III Donald-LDE008 wrote: > Actually, although I'm not entirely sure, I believe that BPDUs, LLDP > PDUs, etc., all start with an Ethertype which identifies them so, in > principle, they could be made to work on a specially equipped point to > point link with no outer MAC addresses. However, I don't think anyone > has proposed that TRILL should consider omitting the outer MAC addresses > except when that suggestion appears as part of a question asking why, if > you want to do some optimization on a point-to-point link, you don't > want to do even more optimization. > > Donald > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Thursday, October 04, 2007 1:46 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> Sent: Thursday, October 04, 2007 8:51 AM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Personally, I need a reminder of what we are trying to >> accomplish with this before I can have any opinion. >> >> a) Is omitting the outer VLAN tag to save space? >> b) Why put in anything for destination address other than the >> MAC address of the next hop RBridge, or put in anything into >> the source address other than your own MAC address? >> It won't save space. So what does it gain? >> c) Is there any danger if an RBridge is confused about >> whether this is a pt-to-pt link or not? >> >> I can see the advantage of omitting the entire outer header >> if it is somehow absolutely known this is a pt-to-pt link, >> and both ends of the link understand this. >> > > That wouldn't work because there are other frames that will > have to have MAC addresses, e.g. LACP, LLDP. > > >> But that isn't >> what's being proposed here. It seems to be only omitting the >> VLAN tag, and allowing insertion of random addresses into the >> source and destination fields in the outer header, if I'm >> reading it correctly. >> > > I don't like the idea of random addresses (is it that > a big a deal to set them correctly?), but as long as > it's completely optional, I don't really care. > [By the way, even though the proposal says that it > can be random, it really can't because we have to > say that they cannot be from the BPDU address space > or things like LACP and LLDP will break.] > > Anoop > > _______________________________________________ > 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 touch at ISI.EDU Fri Oct 5 00:04:32 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 05 Oct 2007 00:04:32 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <4705E200.4060006@isi.edu> I do not understand the need to avoid a single entry per link. This is hyperoptimization at the expense of complexity, and isn't useful. Joe Silvano Gai wrote: > I agree with Donald on all points. > The saving comes from not having to maintain an adjacency table on high > speed point-to-point links. > > -- Silvano > >> -----Original Message----- >> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On >> Behalf Of Eastlake III Donald-LDE008 >> Sent: Thursday, October 04, 2007 9:24 PM >> To: Radia Perlman >> Cc: Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Hi Radia, >> >> See below at @@@ >> >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >> Sent: Thursday, October 04, 2007 11:51 AM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Personally, I need a reminder of what we are trying to accomplish with >> this before I can have >> any opinion. >> >> a) Is omitting the outer VLAN tag to save space? >> >> @@@ Yes. The outer VLAN tag does nothing for you on a point-to-point >> link. >> >> b) Why put in anything for destination address other than the MAC >> address of the next hop >> RBridge, or put in anything into the source address other than your > own >> MAC address? >> It won't save space. So what does it gain? >> >> @@@ While no one has given a really crisp response to that question, > it >> is my impression that some believe it will make it possible to produce >> simpler, less expensive, or more efficient hardware for this case. >> >> c) Is there any danger if an RBridge is confused about whether this is > a >> pt-to-pt link or not? >> >> @@@ I think there might be. And because of this and the extreme >> commonness of the point-to-point case, it may be reasonable to > consider >> this in designing TRILL. For example, if a fixed MAC address were used >> (such as the unicast version of the All-Rbridges multicast address > (just >> turn off the group bit)), then an interface receiving a frame with > that >> source address would know there was a sender on the link who believes >> the link was point-to-point. If the receiver knows it is not >> point-to-point or is unwilling to handle such frames, it could take >> appropriate action. Also, Rbridge would know to never bother > "learning" >> the location of that MAC address. >> >> @@@ Thanks, >> @@@ Donald >> >> I can see the advantage of omitting the entire outer header if it is >> somehow absolutely >> known this is a pt-to-pt link, and both ends of the link understand >> this. But that isn't what's >> being proposed here. It seems to be only omitting the VLAN tag, and >> allowing insertion of >> random addresses into the source and destination fields in the outer >> header, if I'm reading >> it correctly. >> >> So anyway, clarification at this point would certainly help me. >> >> >> Eastlake III Donald-LDE008 wrote: >>> This is a check via the mailing list to confirm or refute an > apparent >>> consensus from the minutes of the Chicago meeting for a change from >>> protocol draft -05: >>> >>> If it is known that a link is a point to point link between two >>> RBridges, then the outer header, if it is an Ethernet header, can >>> have any source and/or destination addresses, those addresses > will >>> be ignored on receipt, and the outer VLAN tag can be omitted. >>> >>> If no particular controversy arises over this in the next two weeks, >> we >>> will declare it to be the working group consensus. >>> >>> Thanks, >>> Donald & Erik >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071005/9e519f34/signature.bin From Donald.Eastlake at motorola.com Fri Oct 5 05:28:27 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Fri, 5 Oct 2007 08:28:27 -0400 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4705D433.5010902@cisco.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <4C94DE2070B172459E4F1EE14BD2364E7B018B@HQ-EXCH-5.corp.brocade.com> <3870C46029D1F945B1472F170D2D9790031CAD29@de01exm64.ds.mot.com> <4705D433.5010902@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D9790031CAD65@de01exm64.ds.mot.com> I don't see any inconsistency between your statement and my statement. Donald -----Original Message----- From: Dinesh G Dutt [mailto:ddutt at cisco.com] Sent: Friday, October 05, 2007 2:06 AM To: Eastlake III Donald-LDE008 Cc: Anoop Ghanwani; Rbridge at postel.org Subject: Re: [rbridge] Consensus Check: Point to Point links Hi Donald, BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM are identified by ethertype and there is supposedly a move to identify newer BPDUs using ethertype. The frames we're talking of sending with a fixed (or reserved) address are the data frames. BPDUs including IS-IS will use the regular MAC address. Dinesh Eastlake III Donald-LDE008 wrote: > Actually, although I'm not entirely sure, I believe that BPDUs, LLDP > PDUs, etc., all start with an Ethertype which identifies them so, in > principle, they could be made to work on a specially equipped point to > point link with no outer MAC addresses. However, I don't think anyone > has proposed that TRILL should consider omitting the outer MAC addresses > except when that suggestion appears as part of a question asking why, if > you want to do some optimization on a point-to-point link, you don't > want to do even more optimization. > > Donald > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop at brocade.com] > Sent: Thursday, October 04, 2007 1:46 PM > To: Radia Perlman; Eastlake III Donald-LDE008 > Cc: Rbridge at postel.org > Subject: RE: [rbridge] Consensus Check: Point to Point links > > > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> Sent: Thursday, October 04, 2007 8:51 AM >> To: Eastlake III Donald-LDE008 >> Cc: Rbridge at postel.org >> Subject: Re: [rbridge] Consensus Check: Point to Point links >> >> Personally, I need a reminder of what we are trying to >> accomplish with this before I can have any opinion. >> >> a) Is omitting the outer VLAN tag to save space? >> b) Why put in anything for destination address other than the >> MAC address of the next hop RBridge, or put in anything into >> the source address other than your own MAC address? >> It won't save space. So what does it gain? >> c) Is there any danger if an RBridge is confused about >> whether this is a pt-to-pt link or not? >> >> I can see the advantage of omitting the entire outer header >> if it is somehow absolutely known this is a pt-to-pt link, >> and both ends of the link understand this. >> > > That wouldn't work because there are other frames that will > have to have MAC addresses, e.g. LACP, LLDP. > > >> But that isn't >> what's being proposed here. It seems to be only omitting the >> VLAN tag, and allowing insertion of random addresses into the >> source and destination fields in the outer header, if I'm >> reading it correctly. >> > > I don't like the idea of random addresses (is it that > a big a deal to set them correctly?), but as long as > it's completely optional, I don't really care. > [By the way, even though the proposal says that it > can be random, it really can't because we have to > say that they cannot be from the BPDU address space > or things like LACP and LLDP will break.] > > Anoop > > _______________________________________________ > 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 anoop at brocade.com Fri Oct 5 09:52:55 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 5 Oct 2007 09:52:55 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4705E200.4060006@isi.edu> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com><47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> I agree with Joe on this point. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch > Sent: Friday, October 05, 2007 12:05 AM > To: Silvano Gai > Cc: Rbridge at postel.org; Radia Perlman > Subject: Re: [rbridge] Consensus Check: Point to Point links > > I do not understand the need to avoid a single entry per > link. This is hyperoptimization at the expense of complexity, > and isn't useful. > > Joe > > Silvano Gai wrote: > > I agree with Donald on all points. > > The saving comes from not having to maintain an adjacency table on > > high speed point-to-point links. > > > > -- Silvano > > > >> -----Original Message----- > >> From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] > > On > >> Behalf Of Eastlake III Donald-LDE008 > >> Sent: Thursday, October 04, 2007 9:24 PM > >> To: Radia Perlman > >> Cc: Rbridge at postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> Hi Radia, > >> > >> See below at @@@ > >> > >> -----Original Message----- > >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] > >> Sent: Thursday, October 04, 2007 11:51 AM > >> To: Eastlake III Donald-LDE008 > >> Cc: Rbridge at postel.org > >> Subject: Re: [rbridge] Consensus Check: Point to Point links > >> > >> Personally, I need a reminder of what we are trying to accomplish > >> with this before I can have any opinion. > >> > >> a) Is omitting the outer VLAN tag to save space? > >> > >> @@@ Yes. The outer VLAN tag does nothing for you on a > point-to-point > >> link. > >> > >> b) Why put in anything for destination address other than the MAC > >> address of the next hop RBridge, or put in anything into > the source > >> address other than your > > own > >> MAC address? > >> It won't save space. So what does it gain? > >> > >> @@@ While no one has given a really crisp response to that > question, > > it > >> is my impression that some believe it will make it possible to > >> produce simpler, less expensive, or more efficient > hardware for this case. > >> > >> c) Is there any danger if an RBridge is confused about > whether this > >> is > > a > >> pt-to-pt link or not? > >> > >> @@@ I think there might be. And because of this and the extreme > >> commonness of the point-to-point case, it may be reasonable to > > consider > >> this in designing TRILL. For example, if a fixed MAC address were > >> used (such as the unicast version of the All-Rbridges multicast > >> address > > (just > >> turn off the group bit)), then an interface receiving a frame with > > that > >> source address would know there was a sender on the link > who believes > >> the link was point-to-point. If the receiver knows it is not > >> point-to-point or is unwilling to handle such frames, it > could take > >> appropriate action. Also, Rbridge would know to never bother > > "learning" > >> the location of that MAC address. > >> > >> @@@ Thanks, > >> @@@ Donald > >> > >> I can see the advantage of omitting the entire outer > header if it is > >> somehow absolutely known this is a pt-to-pt link, and both ends of > >> the link understand this. But that isn't what's being > proposed here. > >> It seems to be only omitting the VLAN tag, and allowing > insertion of > >> random addresses into the source and destination fields in > the outer > >> header, if I'm reading it correctly. > >> > >> So anyway, clarification at this point would certainly help me. > >> > >> > >> Eastlake III Donald-LDE008 wrote: > >>> This is a check via the mailing list to confirm or refute an > > apparent > >>> consensus from the minutes of the Chicago meeting for a > change from > >>> protocol draft -05: > >>> > >>> If it is known that a link is a point to point link between two > >>> RBridges, then the outer header, if it is an Ethernet > header, can > >>> have any source and/or destination addresses, those addresses > > will > >>> be ignored on receipt, and the outer VLAN tag can be omitted. > >>> > >>> If no particular controversy arises over this in the next > two weeks, > >> we > >>> will declare it to be the working group consensus. > >>> > >>> Thanks, > >>> Donald & Erik > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > > From Radia.Perlman at sun.com Fri Oct 5 14:04:10 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 05 Oct 2007 14:04:10 -0700 Subject: [rbridge] Consensus Check: Point to Point links In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> References: <3870C46029D1F945B1472F170D2D9790031840BA@de01exm64.ds.mot.com> <47050BCA.5030003@sun.com> <3870C46029D1F945B1472F170D2D9790031CAD2B@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2022DE22D@nuova-ex1.hq.nuovaimpresa.com> <4705E200.4060006@isi.edu> <4C94DE2070B172459E4F1EE14BD2364E7B0451@HQ-EXCH-5.corp.brocade.com> Message-ID: <4706A6CA.1080207@sun.com> I also don't understand why this is important, but to the extent with which I do understand the implementation concern, how about instead of saying you can put whatever you want in source and destination, we instead define two constant MAC addresses, one that can always be used by an RBridge in the source field, say, RBridge-from-MAC, and another that can always be used in the destination field, say RBridge-to-MAC. So if you think it's a pt-to-pt link, and you don't want to keep track of the MAC address of your neighbor, you can fill out the outer header with those two MAC addresses. If you are confused and there are bridges on the link, nobody will get confused. If "RBridge-from-MAC" is used by multiple RBridges on the same layer 2 cloud, bridges will have confused caches about the lo