From mshand at cisco.com Fri May 1 01:42:33 2009 From: mshand at cisco.com (mike shand) Date: Fri, 01 May 2009 09:42:33 +0100 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FA122F.9020601@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C6559C062@SJEXCHCCR02.corp.ad.broadcom.com> <49FA122F.9020601@sun.com> Message-ID: <49FAB5F9.1090405@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090501/3ca4d8c9/attachment.html From mshand at cisco.com Fri May 1 01:43:51 2009 From: mshand at cisco.com (mike shand) Date: Fri, 01 May 2009 09:43:51 +0100 Subject: [rbridge] maximumPathSplits In-Reply-To: <49F9FFCA.8070407@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654EDC15@SJEXCHCCR02.corp.ad.broadcom.com> <49F9E217.1080802@cisco.com> <49F9FFCA.8070407@sun.com> Message-ID: <49FAB647.6030404@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090501/dd5405df/attachment.html From mshand at cisco.com Fri May 1 02:14:21 2009 From: mshand at cisco.com (mike shand) Date: Fri, 01 May 2009 10:14:21 +0100 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49F92740.6010900@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> Message-ID: <49FABD6D.8040704@cisco.com> On 30/04/2009 Radia Perlman wrote: > b) for information like the neighbor list that can be > arbitrarily large, figure out a way of encoding it in the > spirit of CSNPs, so that partial information can be included. > For instance, CNSPs say "this CSNP refers to all the LSPs from > IDs between x and y". We could do the same for the TRILL-Hellos, > as in "this TRILL-Hello neighbor list includes all neighbors > > with IDs between x and y". So how would this work? For the hellos do we still have to send both (all) fragments at the same rate in order to maintain the adjacencies? i.e. double the hello load? Or is it sufficient to update the holding time on the basis of receiving ANY fragment, even though it may not confirm two way connectivity with you becuase you are not mentioned in that fragment? Mike From james.d.carlson at Sun.COM Fri May 1 07:50:02 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 1 May 2009 10:50:02 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> Message-ID: <18939.3098.878722.81734@gargle.gargle.HOWL> Ali Sajassi (sajassi) writes: > Regarding your comment that loop can happen as the result of one-way > connectivity via partitioned VLAN, AFAIK DRB selection is done over > designated VLAN and if that VLAN is partitioned, then the bridged > network is partitioned because this VLAN is expected to be reachable via > all the access ports. And if the bridged network is partitioned, the it > is O.K. to have a DRB for each of the partitions. So, where is the loop? Suppose A and B are RBridges that are communicating over VLAN 1 as the primary VLAN. They're forwarding for VLANs 2, 3, and 4 as well. Now suppose that VLAN 1 becomes partitioned. Both can now become DRB. They are still forwarding for those other VLANs, though, and this potentially means we have two forwarders on the same VLAN, which leads to fatal forwarding loops. It's a problem that's specific to TRILL, because of the L2 work that it does. It's not something that would happen with an L3 protocol. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Radia.Perlman at sun.com Fri May 1 09:18:32 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 May 2009 09:18:32 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FABD6D.8040704@cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <49FABD6D.8040704@cisco.com> Message-ID: <49FB20D8.6080606@sun.com> Re (see below) Yes. You'd update the holding timer based on any fragment (not just the fragment in which your ID appears). It's not that big a deal to have your ID appear in the neighbor list less often, and assume that the state is the same as when you saw it last. We could have an optional second TLV in the TRILL-Hello that says "recent changes", that could list neighbors whose state has recently changed, and aren't in that fragment's range, as long as there aren't very many of them. Radia mike shand wrote: > On 30/04/2009 Radia Perlman wrote: >> b) for information like the neighbor list that can be >> arbitrarily large, figure out a way of encoding it in the >> spirit of CSNPs, so that partial information can be included. >> For instance, CNSPs say "this CSNP refers to all the LSPs from >> IDs between x and y". We could do the same for the TRILL-Hellos, >> as in "this TRILL-Hello neighbor list includes all neighbors >> >> with IDs between x and y". > So how would this work? For the hellos do we still have to send both > (all) fragments at the same rate in order to maintain the adjacencies? > i.e. double the hello load? Or is it sufficient to update the holding > time on the basis of receiving ANY fragment, even though it may not > confirm two way connectivity with you becuase you are not mentioned in > that fragment? > > > Mike > From mshand at cisco.com Fri May 1 09:21:11 2009 From: mshand at cisco.com (mike shand) Date: Fri, 01 May 2009 17:21:11 +0100 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <18939.3098.878722.81734@gargle.gargle.HOWL> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> Message-ID: <49FB2177.8050807@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090501/503247e1/attachment.html From james.d.carlson at Sun.COM Fri May 1 09:30:16 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 1 May 2009 12:30:16 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB2177.8050807@cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> Message-ID: <18939.9112.131115.893423@gargle.gargle.HOWL> mike shand writes: > > So does this mean that all these hellos need to be sent on all the > VLANs?
Yes, we do need to send Hellos (of a sort) on all of the configured VLANs. The Hellos sent on those other VLANs need not include as much information as the primary ones. There's more about this in the TRILL specification. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Radia.Perlman at sun.com Fri May 1 10:08:26 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 May 2009 10:08:26 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <18939.9112.131115.893423@gargle.gargle.HOWL> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> Message-ID: <49FB2C8A.6090206@sun.com> Re: What VLANs are which things sent on: As James Carlson says (below), there was a lot of controversy about which VLANs to send things on, with one extreme being "send on all VLANs" and the other being "send only on a single VLAN", and we finally worked out a compromise, and it's in the spec. But to summarize: The DRB "sprays" on lots of VLANs (the default being all the VLANs it is capable of communicating on, but it can be configured to send on fewer). The only information that needs to appear in the non-designated-VLAN TRILL-Hello is "ID, priority". Non-DRB sends only on the designated VLAN, plus any VLANs for which it is appointed designated forwarder. Not in the spec yet: MTU testing (probe, ack) would only be on the designated VLAN ********** Now a refinement that would be useful to discuss: While we're on the subject, one extra field that could make things even safer would be a TLV for "this is the (ID, priority) of who I think is DRB". Let's say R1 should be DRB based on (ID, priority). I'd suggest that if R2 hears R3's Hello on any VLAN (not necessarily the designated VLAN), then R2 may transmit a TRILL-Hello to inform R3 about R1 (in case for some reason R3 can't hear R1). The other possible safety thing is what was in Digital's bridge spec, and I'm not sure whether it made it into 802.1d, which is the "bad hello" mechanism. Translating that mechanism into TRILL, it would be that if R1 is DRB, and keeps hearing R2 claiming to be DRB, then R1 continues to try becoming DRB, but stops forwarding traffic to/from the link. I could imagine us either just ignoring these cases as too far-fetched to worry about, or incorporating these extra safety features on the theory that loops are really really bad and it's not that big a deal to do these things. Radia James Carlson wrote: > mike shand writes: > >> >> So does this mean that all these hellos need to be sent on all the >> VLANs?
>> > > Yes, we do need to send Hellos (of a sort) on all of the configured > VLANs. The Hellos sent on those other VLANs need not include as much > information as the primary ones. > > There's more about this in the TRILL specification. > > From sajassi at cisco.com Fri May 1 10:20:19 2009 From: sajassi at cisco.com (Ali Sajassi (sajassi)) Date: Fri, 1 May 2009 10:20:19 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <18939.3098.878722.81734@gargle.gargle.HOWL> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com><1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com><9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com><49F92740.6010900@sun.com><7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com><49FA2143.8070209@sun.com><7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> Message-ID: <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> James, If we need to send "protective hello" on each VLAN in order to monitor the connectivity of that VLAN over .1Q bridged network as described in section 4.2.4.2, then so be it (although I think we can do it more efficiently as I will talk in next paragraph). However, this is not the point that I am driving at. If you need to have two types of TRILL hellos messages (e.g., neighbor discovery vs.. protective), then that's O.K. My point is that we should be able to use the same IS-IS hello message with MTU padding for both because I don't think the frame size can exceed 1522 bytes !! (please refer to my email on scenarios for TRILL access/trunk ports regarding why it cannot exceed 1522). Now regarding more efficient mechanism for sending TRILL hellos. Two cases to consider: 1) .1Q network is running STP/RSTP: In this case, there is only a single active topology in the .1Q network and we can have a single VLAN that covers the entire active topology (e.g., VLAN 1). Then just monitoring this VLAN will be sufficient - e.g., if this VLAN is partitioned, then the network is partitioned and all the other VLANs are partitioned. In other words, in this scenario, there is no need to send protective hello messages (per VLAN). 2) .1Q network is running MSTP: In this case, there are several active topologies (one per MSTI). So, in this case, we can just have a single VLAN per MSTI that covers the entire active topology for that MSTI. If there are 2 or 3 MSTIs for 4K VLANs (which is typical), then you only need to monitor 2 or 3 VLANs rather than 4K VLANs. We should know the number of MSTIs because we have this info from BPDU in root-collision detection procedure. Cheers, Ali > -----Original Message----- > From: James Carlson [mailto:james.d.carlson at Sun.COM] > Sent: Friday, May 01, 2009 7:50 AM > To: Ali Sajassi (sajassi) > Cc: Radia Perlman; rbridge at postel.org > Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing > > Ali Sajassi (sajassi) writes: > > Regarding your comment that loop can happen as the result > of one-way > > connectivity via partitioned VLAN, AFAIK DRB selection is done over > > designated VLAN and if that VLAN is partitioned, then the bridged > > network is partitioned because this VLAN is expected to be > reachable > > via all the access ports. And if the bridged network is > partitioned, > > the it is O.K. to have a DRB for each of the partitions. > So, where is the loop? > > Suppose A and B are RBridges that are communicating over VLAN > 1 as the primary VLAN. They're forwarding for VLANs 2, 3, > and 4 as well. > > Now suppose that VLAN 1 becomes partitioned. Both can now become DRB. > They are still forwarding for those other VLANs, though, and > this potentially means we have two forwarders on the same > VLAN, which leads to fatal forwarding loops. > > It's a problem that's specific to TRILL, because of the L2 > work that it does. It's not something that would happen with > an L3 protocol. > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 > 781 442 1677 > From ddutt at cisco.com Fri May 1 10:25:35 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Fri, 01 May 2009 10:25:35 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB2C8A.6090206@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> Message-ID: <49FB308F.6000706@cisco.com> Radia, Radia Perlman wrote: > While we're on the subject, one extra field that could make things even > safer would > be a TLV for "this is the (ID, priority) of who I think is DRB". Let's > say R1 should be DRB > based on (ID, priority). > I'd suggest that if R2 hears > R3's Hello on any VLAN (not necessarily the designated VLAN), > then R2 may transmit a TRILL-Hello to inform R3 about R1 (in case > for some reason R3 can't hear R1). > The other possible safety thing is what was in Digital's bridge spec, > and I'm not sure whether it > made it into 802.1d, which is the "bad hello" mechanism. Translating > that mechanism into TRILL, it would > be that if R1 is DRB, and keeps hearing R2 claiming to be DRB, then R1 > continues to try becoming DRB, > but stops forwarding traffic to/from the link. > I'm happy if at least R1 stops forwarding traffic to/from the link, Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Fri May 1 10:31:54 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 May 2009 10:31:54 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> Message-ID: <49FB320A.5010006@sun.com> Re: two types of Hellos. This is where a lot of people have misunderstood me. We are *not* proposing two types of Hellos. Admittedly, that is what's in the latest version of the TRILL spec, but we are replacing that with some variant of what I said on the list a couple days ago. There will be no such thing as "protective Hellos". There is only a single type of periodic message, which we'll call TRILL-Hellos. There are also MTU probes, and MTU acks, but these are not periodic. Radia Ali Sajassi (sajassi) wrote: > James, > > If we need to send "protective hello" on each VLAN in order to monitor > the connectivity of that VLAN over .1Q bridged network as described in > section 4.2.4.2, then so be it (although I think we can do it more > efficiently as I will talk in next paragraph). However, this is not the > point that I am driving at. If you need to have two types of TRILL > hellos messages (e.g., neighbor discovery vs.. protective), then that's > O.K. From mshand at cisco.com Fri May 1 10:41:27 2009 From: mshand at cisco.com (mike shand) Date: Fri, 01 May 2009 18:41:27 +0100 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB2C8A.6090206@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> Message-ID: <49FB3447.90904@cisco.com> On 01/05/2009 Radia Perlman wrote: > ********** > Now a refinement that would be useful to discuss: > > While we're on the subject, one extra field that could make things even > safer would > > be a TLV for "this is the (ID, priority) of who I think is DRB". The LAN ID field in the IS-IS hello already tells you who the sender thinks is the DIS, but it doesn't include the priority. Instead it has the ID assigned by the DIS. Why would you want the priority? Mike From james.d.carlson at Sun.COM Fri May 1 11:08:05 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 1 May 2009 14:08:05 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB2C8A.6090206@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> Message-ID: <18939.14981.452559.967611@gargle.gargle.HOWL> Radia Perlman writes: > While we're on the subject, one extra field that could make things even > safer would > be a TLV for "this is the (ID, priority) of who I think is DRB". Let's That seems like a wise move to me. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From d3e3e3 at gmail.com Fri May 1 11:09:40 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 1 May 2009 14:09:40 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> Message-ID: <1028365c0905011109y2f92f1b3mfcdba9ae0987921f@mail.gmail.com> Hi Ali, On Thu, Apr 30, 2009 at 1:48 PM, Ali Sajassi (sajassi) wrote: > > Hi Radia, > > Thanks for the description of the solution. It was very nice and > concise. However, I'd like to get some clarification regarding the > scenario(s) in which such solution is required. > > The original problem was that the IS-IS hello messages can get lost over > 802.1Q (because of Eth frame size exceeding 1522 bytes) and thus > resulting in multiple AFs selection and creating loop over 802.1Q > network. This was unacceptable because TRILL was forming a loop over > 802.1Q network with standard-sized frame of 1522. I can think of three > scenarios that can be considered here: The loop was of shorter native frames. RBridge ports can implement 802.1AE or other protocols below the EISS layer that insert additional tags, including future protocols not yet devisee, so don't focus too sharply on some specific legnth. > 1) 802.1Q network is only used to transport native Ethernet packets > (e.g., Rbridge ports connected to 802.1Q network are configured as > access ports only). In this scenario, no TRILL encapsulated packets are > sent over the bridged network and thus IIHs that are sent over 802.1Q > network should not be padded with any consideration for TRILL header > overhead - e.g., IIHs needs only to get padded to 1500 bytes. > > In this scenario, since the padded IIHs adhere to 1500 byte-limit of > 802.1Q network, there is no issue with IIHs getting dropped by the > bridged network. The TRILL mechanism for DRB & AF selection and > root-bridge collision detect should work just fine and there should be > no transient loop created either in the bridged network or the TRILL > network. I don't know what you think you are implying by referring to the bridged LAN between RBridges as "802.1Q network" but it can consist of an abritrary mesh of arbitrarily configured repeaters, hubs, 802.1D, and 802.1Q bridges of various vintages with various feature sets variously configured and enabled/disabled. You seem to be suggesting padding all the "hellos" but this makes no sense to me. If they were guaranteed to get through, the padding was useless waste of bandwidth. If they don't get through, you have multiple appointed forwarders and your network can melt down. One reason they might not get through with padding are RBridge ports adding 802.1AE or other tags. You cannot be safe with padded "hellos" on any port that can receive or transmit native frames. > 2) 802.1Q network is only used as transit network for TRILL encapsulated > packets (e.g., Rbridge ports connected to 802.1Q network are configured > as trunk ports only). ?In this scenario, IIHs should get padded with > consideration for TRILL header overhead in mind which means if the > bridged network doesn't have support for bigger MTU, then these IIHs get > dropped. However, dropping of these IIHs doesn't cause any harm since > there is no access ports over this bridged network and all it means is > that TRILL nodes don't see each other over the bridged network and thus > they don't form adjacencies with each other. Since there is no access > ports and there is no AFs (Appointed Forwarders), there will be no loop > over this bridged network. I believe you are correct. TRILL encapsulated frames are safe. It is only native frames that are problematic. RBridge ports configured as P2P could just use IS-IS P2P Hellos. And ports configured as trunk ports could use padded padded "hellos" since the worst that would happen is that you have fewer LSP adjacencies. > 3) 802.1Q network can be used to transport both Native Ethernet packets > and TRILL encapsulated packets (e.g., Rbridge ports connected to 802.1Q > network are configured as both access and trunk ports). In this > scenario, IIHs MTU size should default to the one for access port - > e.g., without any consideration for TRILL header overhead. In other > words, it should work just like scenario-1. In such scenario, no IIHs > can get dropped over the 802.1Q network because the TRILL never pads > them to more than 1500 bytes of payload. For the reasons stated above, I disagree your description of the arbitrary bridged LAN between RBridges as "the 802.1Q network" and I do not believe your claim that no IS-IS Hellos can get dropped. > So, in summary, I cannot see how a loop can be formed using > standard-based 802.1Q frame size of 1522 based on the above three > scenarios. If you have some other scenario(s) in mind, can you describe > it or them. It should be noted that I am talking about standard 802.1Q > frame size for the above scenarios (and not jumbo frame size based on > 802.3as). In summary, any system attempting to operate in range of conditions that the current RBridge base protocol specificaiton addresses will be unreliable if "hellos" are padded on any RBridge port that can send/receive native frames. > Cheers, > Ali Thanks, Donald >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> Sent: Wednesday, April 29, 2009 9:21 PM >> To: rbridge at postel.org >> Subject: [rbridge] Proposed resolution of DRB election/MTU testing >> >> Moving to a new thread, since the "Why is MTU discovery >> important" thread was getting too long (and the subject line >> had nothing to do with most of the discussion). >> >> Hopefully we can quickly close the issue of DRB election/MTU >> discovery. >> And then finally close on the base protocol document... >> >> I was participating in an off-list >> group of people discussing the issue, which was useful in >> clarifying certain aspects. >> I will summarize the proposed solution. >> >> First, refreshing people as to what the issue is: >> >> The problem: The Hello protocol in IS-IS may elect multiple >> DRs, since routers ignore routers with whom they do not have >> 2-way connectivity. Somewhat orthogonally, IS-IS LAN Hellos >> are padded, to avoid forming adjacencies with neighbors that >> you can't speak the minimum acceptable size with. >> >> This behavior is fine for layer 3, but not for layer 2, where >> it will form loops if there are multiple DRBs. >> >> So ignoring this issue for TRILL is not an option. >> >> >> *********************** >> A bit of background on IS-IS >> >> IS-IS is modular, in that there are two sublayers, that in >> DECnet we called the "subnetwork independent sublayer" >> and the "subnetwork dependent sublayer". The subnetwork >> dependent sublayer has neighbor adjacency forming protocols >> for different types of links. >> >> What we are proposing for TRILL is support for a new type of >> link within IS-IS's "link dependent sublayer". This is for >> Ethernet links that are not explicitly pt-to-pt. >> >> What we need to accomplish with this protocol: >> >> a) elect exactly one DRB >> b) figure out what the campus-wide minimum MTU size, "S", is >> (to know what the minimum acceptable link MTU size is). LSP >> fragment sizes must not be larger than this minimum >> c) test neighbor-neighbor links to see if they support size S >> d) remove links from the topology that do not support the >> campus minimum size S >> >> ***************************** >> >> Electing exactly one DRB >> >> This will be based on periodic messages, which we'll call >> TRILL-Hellos, similar to IS-IS LAN Hellos, but they are >> different in two aspects: they are not padded, and election >> is based solely on (ID, priority), and not on whether >> connectivity is 2-way. In other words, R2 defers to R1 if R1 >> has higher (ID, priority), whether or not there is 2-way >> connectivity between R2 and R1. >> >> TRILL-Hellos must be periodic and frequent, so as to avoid >> having RBs not know about each other. They will be sent on >> the set of VLANs that the TRILL spec already says Hellos >> would be sent on. >> >> TRILL-Hellos contain all the same information that the TRILL >> spec already claims is in Hello messages. (other than the >> difference that they won't be padded). >> >> So basically, the changes in the TRILL spec so far are >> 1) rename Hello to "TRILL-Hello message" >> 2) do not pad the message >> 3) election will be based solely on the fields (ID, priority). >> >> Note: Although the neighbor list is included in a >> TRILL-Hello, (as it is in an IS-IS LAN Hello), it does not >> affect selection of DRB. >> But the neighbor list still needs to be there for all the >> RBridges to know which neighbors they have 2-way connectivity >> with, for the purpose of reporting links in LSPs. >> >> ******************************* >> >> figuring out what the campus-wide minimum MTU size is: >> >> This will be done based on a TLV in LSPs (which already >> exists in IS-IS -- the originatingLSPBufferSize, TLV 14). >> If that TLV is absent, >> it is the same as requesting "1470". The campus-wide minimum >> MTU size chosen is the smallest size "S" reported in any LSP. >> >> LSP fragments must not be bigger than S, and links that >> cannot support S will not appear in the topology (meaning, >> they will not be reported in LSPs) >> >> >> *************************************************** >> testing neighbor-neighbor links to ensure they support "S". >> >> We will have new messages: MTU probe, and MTU ack. Both are >> padded to size S. >> >> It will be optional whether and when to send an MTU probe, >> but mandatory to send an ack in response to receipt of an MTU >> probe. The ack is padded to the same size that the probe was >> padded to, and is unicast to the RBridge from which the probe >> was received. Probes may be unicast or multicast. They may be >> sent periodically (but far less frequently than DRB election >> messages). Or they might be sent only in response to an event >> such as hearing from a new neighbor RBridge. Both MTU probes >> and acks are sent only on the Designated VLAN. >> >> If R1 fails to get an ack from R2, R1 still reports R2 in its >> neighbor list, but with a flag saying "failed minimum MTU test". >> >> >> >> **************** >> Links that are not 2-way for any reason, including not >> supporting the minimum campus-wide MTU S, are not reported in LSPs. >> >> That means that if R1 is DRB, and it does not have 2-way >> connectivity to R2, R1 does not list R2 as a neighbor, in the >> pseudonode LSP. >> R2 does not report a link to the pseudonode. >> >> If neither R2 nor R3 are DRB, they both have 2-way >> connectivity to the DRB, but not to each other, then they do >> both report connectivity to the pseuodnode. However, if R2 >> receives a packet that needs to be forwarded to R3 across >> that link, R2 sends the packet to the DRB instead. (Note: >> This behavior is already specified in IS-IS) >> >> ******************* >> Concern was raised about the size of TRILL-hellos. Might they >> wind up being too big to fit? This concern would apply >> whether Hellos are padded or not. >> >> For instance, one topology >> people envision is a core that connects hundreds of customer >> sites into a giant Ethernet. The technology that creates the >> core is irrelevant to TRILL, other than having Ethernet-like >> characteristics, in terms of being multiaccess and supporting >> multicast. >> >> In that case, if the customer's Ethernet is running TRILL, >> the core would appear to TRILL to be a giant Ethernet with >> hundreds of neighbors. In other words, all the hundreds of >> RBridges connected to the core would see all of the other >> RBridges on the core as neighbors on this "link". >> >> IS-IS has carefully designed packet formats for LSPs and >> CSNPs, so that they can be arbitrarily large, transmitted in >> pieces, with each piece being able to be independently >> processed. For some reason though we didn't design Hellos >> that way. We should take the opportunity to design >> TRILL-Hello messages with that effect. >> >> There are some things in TRILL-Hellos that don't really need >> to be reported frequently (like which VLANs you support). And >> some things (like the neighbor list) that might wind up being >> too large to fit into a single packet. >> >> Other information (such as ID and priority) really should go >> in every TRILL-Hello. >> >> I'd suggest we do two things in the encoding of TRILL-Hellos >> >> a) figure out which fields can be left out some of the time, >> and specify that those fields, if absent, just mean they are >> absent, not, for instance, that you don't support any VLANs. >> >> b) for information like the neighbor list that can be >> arbitrarily large, figure out a way of encoding it in the >> spirit of CSNPs, so that partial information can be included. >> For instance, CNSPs say "this CSNP refers to all the LSPs >> from IDs between x and y". We could do the same for the >> TRILL-Hellos, as in "this TRILL-Hello neighbor list includes >> all neighbors with IDs between x and y". >> >> *********************************** >> >> Radia >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From james.d.carlson at Sun.COM Fri May 1 11:40:12 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 1 May 2009 14:40:12 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> Message-ID: <18939.16908.287067.198109@gargle.gargle.HOWL> Ali Sajassi (sajassi) writes: > point that I am driving at. If you need to have two types of TRILL > hellos messages (e.g., neighbor discovery vs.. protective), then that's As Radia said, we're evolving this, but, yes, that's essentially true. > O.K. My point is that we should be able to use the same IS-IS hello > message with MTU padding for both because I don't think the frame size > can exceed 1522 bytes !! (please refer to my email on scenarios for > TRILL access/trunk ports regarding why it cannot exceed 1522). Even if you don't exceed 1522, there can be problems. I observed problems with old gear in our lab that didn't support anything over 1500. There's no guaranteed-good magic number near or above 1500 that I know about that could possibly be used here. That's part of the point. Specifications are nice to have, and it's wonderful that someone is out there 'demanding' that everyone support at least 1522 octets in a message, but none of that actually forces this to be true. There are no specification police who will round up old gear and ship it to a detention facility. Thus, either we merely assert that certain minimums are required, and allow the system to fail miserably (and catastrophically) when confronted with something that's slightly out of spec *OR* we make the protocols protective of unknown conditions in a harsh world. I would like to see us opt for the latter. It's my experience that specification alone doesn't make it so. > 1) .1Q network is running STP/RSTP: In this case, there is only a single > active topology in the .1Q network and we can have a single VLAN that > covers the entire active topology (e.g., VLAN 1). Then just monitoring That's correct. We could. Doing so would demand that customers run their networks in a particular way to suit our application. Customers would be required to configure some particular VLAN to cover the entire L2 topology. I'd certainly like to see that happen. It'd be a great simplification. However, if you read through the list archives, you'll see that a substantial majority of the working group believes that forcing our collective will onto existing networks where people are expected to deploy RBridges will not in fact work. Instead, they won't deploy. And that'd be a problem. An equivalent alternative to this single-global-VLAN proposal is to require that all RBridges in a given L2 area be interconnected either by direct links or by repeaters alone, with no intervening bridges. Any STP-type bridges that exist must be on the outside of the RBridge cloud. That also solves the problem and is sufficient, but greatly constrains the deployment scenarios, particularly in the case where there's a backbone bridged network. > 2) .1Q network is running MSTP: In this case, there are several active > topologies (one per MSTI). So, in this case, we can just have a single > VLAN per MSTI that covers the entire active topology for that MSTI. If > there are 2 or 3 MSTIs for 4K VLANs (which is typical), then you only > need to monitor 2 or 3 VLANs rather than 4K VLANs. We should know the > number of MSTIs because we have this info from BPDU in root-collision > detection procedure. MSTP is unclear to me. I *think* all we really need to know is the core instance bridge ID ... but I could certainly be wrong. I haven't seen MSTP in use anywhere, and I have no code that supports it. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From d3e3e3 at gmail.com Fri May 1 11:42:59 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 1 May 2009 14:42:59 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> Message-ID: <1028365c0905011142v15edbb8em53a78397d158f074@mail.gmail.com> Hi Ali, On Fri, May 1, 2009 at 2:01 AM, Ali Sajassi (sajassi) wrote: > Hi Radia, > > Regarding your comment that loop can happen as the result of one-way > connectivity via partitioned VLAN, AFAIK DRB selection is done over > designated VLAN and if that VLAN is partitioned, then the bridged > network is partitioned because this VLAN is expected to be reachable via > all the access ports. And if the bridged network is partitioned, the it > is O.K. to have a DRB for each of the partitions. So, where is the loop? The DRB selection has to be done on more than "designated VLAN". What is the "designated VLAN" if all the N different RBridges with ports connected to an arbitrary bridged LAN are configured to want a different designated VLAN? The answer is that the DRB gets to dictate the designated VLAN. Exactly what VLANs which RBridges need to send "hellos" on was are area that the TRILL working group considered quite carefully. The set of VLANs specified in the current draft for protective hellos (which is the set of VLANs the one new "TRILL Hello" Radia suggested would be sent on) was the result. While you could send "hellos" on even more VLANs, a sketch of a proof that the set of VLANs specified in the current draft is safe is given in Section 4 of draft-eastlake-trill-rbridge-notes-01.txt (this is not a WG draft and has not been updated for the latest base protocol specification). > Besides, how does a partitioned VLAN result in a one-way connectivity > (in bridged network, it should result in a two-way disconnectivity). I'm not sure exactly what Radia meant but, as far as I know, if you don't turn on bridge VLAN ingress filtering, it is quite easy to configure a bridge port so that it acts as a VLAN diode, letting frames through one way and not the other for a particular VLAN or VLANs. The design of the protective hello mechanism in the current draft allows for arbitrary VLAN diodes in the arbitrary bridged LAN interconnecting a set of RBridges. > I have no desire to prolong this discussion; however, I am not clear of > the failure scenarios that warrant the modifications to IS-IS and I > would very much prefer to keep the things simple and don't modify IS-IS > if we don't have to. I agree with you that the proposed solution is more > flexible, I just don't see where and why such flexibility is needed. So, > under which of the following the loop is expected: There is a potential loop in TRILL whenever you have two RBridges ports, A and B, such that A can emit a native frame in VLAN x that will get to B but when A sends a hello in VLAN x, it does not get to B. > A) loss of connectivity over .1Q bridged network that supports standard > 1522 bytes frame size: I listed all the scenarios that I could think of > in my previous email (e.g., different combinations of access and trunk > ports) and showed that we won't have loops in any of those scenarios. In my response, I explained why I did not find your message persuasive. > B) loss of connectivity over .1Q bridged network that doesn't support > 1522 byte frame size (e.g., it only supports 1100 bytes). Is that the > scenario of interest ? If so, then this cannot happen because by > definition a .1Q network MUST support frame size of 1522 bytes. If it > doesn't support standard frame size, then loop can happen within that > .1Q network itself that runs MSTP. While I agree that it is reasonable to assume support of some minimal message size, there is no assumption that the arbitrary bridged LAN connecting RBridges is "a .1Q network". > C) loss of connectivity over .1Q bridge network because of one-way > connectivity - e.g., partitioned VLAN. This is what you mentioned in > this email and the question is how partition of designated VLAN will > result in loop. And how a one-way connectivity can happen in a bridged > network because if that can happen, then there will be a loop within the > bridged network that runs MSTP. It's not TRILL's problem whether or not bridges in the arbitrary bridge LAN between RBridges support MSTP or whether or not MSTP works when bridge ports are configured as VLAN diodes. I see no purpose in discussing this here. Thanks, Donald > So, I would appreciate if anyone can clearly describe a scenario in > which a loop can be created by TRILL over a bridge network. > > Regards, > Ali > > > > >> -----Original Message----- >> From: rbridge-bounces at postel.org >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> Sent: Thursday, April 30, 2009 3:08 PM >> To: rbridge at postel.org >> Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing >> >> Re: Ali Sajassi's question about how loops could form: >> >> To simplify, with any sort of one-way connectivity, the >> current IS-IS LAN Hello protocol says to ignore (for purpose >> of DR election) any router with which you don't have 2-way >> connectivity. >> >> One-way connectivity can happen due to lots of reasons -- not >> just MTU. >> For example, >> because of partitioned VLANs. >> >> So therefore, it's pretty clear that if you want only a >> single DRB, you need to defer to anyone you hear from (or >> about) with better (ID, priority). >> >> And separating out the MTU testing into a separate, optional, >> very infrequent protocol allows flexibility that might be >> very useful in data centers (actually measuring the MTU, not >> just saying yes/no). Plus if padded hellos are guaranteed to >> get through, you don't need to pad them. And if padding them >> might cause them not to get through, then you'll get loops. >> >> Radia >> >> >> >> >> ?(sajassi) wrote: >> > Hi Radia, >> > >> > Thanks for the description of the solution. It was very nice and >> > concise. However, I'd like to get some clarification regarding the >> > scenario(s) in which such solution is required. >> > >> > The original problem was that the IS-IS hello messages can get lost >> > over 802.1Q (because of Eth frame size exceeding 1522 >> bytes) and thus >> > resulting in multiple AFs selection and creating loop over 802.1Q >> > network. This was unacceptable because TRILL was forming a >> loop over >> > 802.1Q network with standard-sized frame of 1522. I can >> think of three >> > scenarios that can be considered here: >> > >> > 1) 802.1Q network is only used to transport native Ethernet packets >> > (e.g., Rbridge ports connected to 802.1Q network are configured as >> > access ports only). In this scenario, no TRILL encapsulated packets >> > are sent over the bridged network and thus IIHs that are sent over >> > 802.1Q network should not be padded with any consideration >> for TRILL >> > header overhead - e.g., IIHs needs only to get padded to 1500 bytes. >> > >> > In this scenario, since the padded IIHs adhere to 1500 >> byte-limit of >> > 802.1Q network, there is no issue with IIHs getting dropped by the >> > bridged network. The TRILL mechanism for DRB & AF selection and >> > root-bridge collision detect should work just fine and >> there should be >> > no transient loop created either in the bridged network or >> the TRILL >> > network. >> > >> > 2) 802.1Q network is only used as transit network for TRILL >> > encapsulated packets (e.g., Rbridge ports connected to >> 802.1Q network >> > are configured as trunk ports only). ?In this scenario, IIHs should >> > get padded with consideration for TRILL header overhead in >> mind which >> > means if the bridged network doesn't have support for >> bigger MTU, then >> > these IIHs get dropped. However, dropping of these IIHs >> doesn't cause >> > any harm since there is no access ports over this bridged >> network and >> > all it means is that TRILL nodes don't see each other over >> the bridged >> > network and thus they don't form adjacencies with each other. Since >> > there is no access ports and there is no AFs (Appointed >> Forwarders), >> > there will be no loop over this bridged network. >> > >> > 3) 802.1Q network can be used to transport both Native Ethernet >> > packets and TRILL encapsulated packets (e.g., Rbridge ports >> connected >> > to 802.1Q network are configured as both access and trunk >> ports). In >> > this scenario, IIHs MTU size should default to the one for >> access port >> > - e.g., without any consideration for TRILL header >> overhead. In other >> > words, it should work just like scenario-1. In such >> scenario, no IIHs >> > can get dropped over the 802.1Q network because the TRILL >> never pads >> > them to more than 1500 bytes of payload. >> > >> > So, in summary, I cannot see how a loop can be formed using >> > standard-based 802.1Q frame size of 1522 based on the above three >> > scenarios. If you have some other scenario(s) in mind, can you >> > describe it or them. It should be noted that I am talking about >> > standard 802.1Q frame size for the above scenarios (and not jumbo >> > frame size based on 802.3as). >> > >> > Cheers, >> > Ali >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: rbridge-bounces at postel.org >> >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >> >> Sent: Wednesday, April 29, 2009 9:21 PM >> >> To: rbridge at postel.org >> >> Subject: [rbridge] Proposed resolution of DRB election/MTU testing >> >> >> >> Moving to a new thread, since the "Why is MTU discovery important" >> >> thread was getting too long (and the subject line had >> nothing to do >> >> with most of the discussion). >> >> >> >> Hopefully we can quickly close the issue of DRB election/MTU >> >> discovery. >> >> And then finally close on the base protocol document... >> >> >> >> I was participating in an off-list >> >> group of people discussing the issue, which was useful in >> clarifying >> >> certain aspects. >> >> I will summarize the proposed solution. >> >> >> >> First, refreshing people as to what the issue is: >> >> >> >> The problem: The Hello protocol in IS-IS may elect multiple DRs, >> >> since routers ignore routers with whom they do not have 2-way >> >> connectivity. Somewhat orthogonally, IS-IS LAN Hellos are >> padded, to >> >> avoid forming adjacencies with neighbors that you can't speak the >> >> minimum acceptable size with. >> >> >> >> This behavior is fine for layer 3, but not for layer 2, >> where it will >> >> form loops if there are multiple DRBs. >> >> >> >> So ignoring this issue for TRILL is not an option. >> >> >> >> >> >> *********************** >> >> A bit of background on IS-IS >> >> >> >> IS-IS is modular, in that there are two sublayers, that in >> DECnet we >> >> called the "subnetwork independent sublayer" >> >> and the "subnetwork dependent sublayer". The subnetwork dependent >> >> sublayer has neighbor adjacency forming protocols for >> different types >> >> of links. >> >> >> >> What we are proposing for TRILL is support for a new type of link >> >> within IS-IS's "link dependent sublayer". This is for >> Ethernet links >> >> that are not explicitly pt-to-pt. >> >> >> >> What we need to accomplish with this protocol: >> >> >> >> a) elect exactly one DRB >> >> b) figure out what the campus-wide minimum MTU size, "S", >> is (to know >> >> what the minimum acceptable link MTU size is). LSP fragment sizes >> >> must not be larger than this minimum >> >> c) test neighbor-neighbor links to see if they support size S >> >> d) remove links from the topology that do not support the campus >> >> minimum size S >> >> >> >> ***************************** >> >> >> >> Electing exactly one DRB >> >> >> >> This will be based on periodic messages, which we'll call >> >> TRILL-Hellos, similar to IS-IS LAN Hellos, but they are >> different in >> >> two aspects: they are not padded, and election is based solely on >> >> (ID, priority), and not on whether connectivity is 2-way. In other >> >> words, R2 defers to R1 if R1 has higher (ID, priority), whether or >> >> not there is 2-way connectivity between R2 and R1. >> >> >> >> TRILL-Hellos must be periodic and frequent, so as to avoid >> having RBs >> >> not know about each other. They will be sent on the set of >> VLANs that >> >> the TRILL spec already says Hellos would be sent on. >> >> >> >> TRILL-Hellos contain all the same information that the TRILL spec >> >> already claims is in Hello messages. (other than the >> difference that >> >> they won't be padded). >> >> >> >> So basically, the changes in the TRILL spec so far are >> >> 1) rename Hello to "TRILL-Hello message" >> >> 2) do not pad the message >> >> 3) election will be based solely on the fields (ID, priority). >> >> >> >> Note: Although the neighbor list is included in a >> TRILL-Hello, (as it >> >> is in an IS-IS LAN Hello), it does not affect selection of DRB. >> >> But the neighbor list still needs to be there for all the >> RBridges to >> >> know which neighbors they have 2-way connectivity with, for the >> >> purpose of reporting links in LSPs. >> >> >> >> ******************************* >> >> >> >> figuring out what the campus-wide minimum MTU size is: >> >> >> >> This will be done based on a TLV in LSPs (which already exists in >> >> IS-IS -- the originatingLSPBufferSize, TLV 14). >> >> If that TLV is absent, >> >> it is the same as requesting "1470". The campus-wide >> minimum MTU size >> >> chosen is the smallest size "S" reported in any LSP. >> >> >> >> LSP fragments must not be bigger than S, and links that cannot >> >> support S will not appear in the topology (meaning, they >> will not be >> >> reported in LSPs) >> >> >> >> >> >> *************************************************** >> >> testing neighbor-neighbor links to ensure they support "S". >> >> >> >> We will have new messages: MTU probe, and MTU ack. Both >> are padded to >> >> size S. >> >> >> >> It will be optional whether and when to send an MTU probe, but >> >> mandatory to send an ack in response to receipt of an MTU >> probe. The >> >> ack is padded to the same size that the probe was padded >> to, and is >> >> unicast to the RBridge from which the probe was received. >> Probes may >> >> be unicast or multicast. They may be sent periodically >> (but far less >> >> frequently than DRB election messages). Or they might be >> sent only in >> >> response to an event such as hearing from a new neighbor RBridge. >> >> Both MTU probes and acks are sent only on the Designated VLAN. >> >> >> >> If R1 fails to get an ack from R2, R1 still reports R2 in its >> >> neighbor list, but with a flag saying "failed minimum MTU test". >> >> >> >> >> >> >> >> **************** >> >> Links that are not 2-way for any reason, including not >> supporting the >> >> minimum campus-wide MTU S, are not reported in LSPs. >> >> >> >> That means that if R1 is DRB, and it does not have 2-way >> connectivity >> >> to R2, R1 does not list R2 as a neighbor, in the pseudonode LSP. >> >> R2 does not report a link to the pseudonode. >> >> >> >> If neither R2 nor R3 are DRB, they both have 2-way connectivity to >> >> the DRB, but not to each other, then they do both report >> connectivity >> >> to the pseuodnode. However, if R2 receives a packet that >> needs to be >> >> forwarded to R3 across that link, R2 sends the packet to the DRB >> >> instead. (Note: >> >> This behavior is already specified in IS-IS) >> >> >> >> ******************* >> >> Concern was raised about the size of TRILL-hellos. Might >> they wind up >> >> being too big to fit? This concern would apply whether Hellos are >> >> padded or not. >> >> >> >> For instance, one topology >> >> people envision is a core that connects hundreds of customer sites >> >> into a giant Ethernet. The technology that creates the core is >> >> irrelevant to TRILL, other than having Ethernet-like >> characteristics, >> >> in terms of being multiaccess and supporting multicast. >> >> >> >> In that case, if the customer's Ethernet is running TRILL, >> the core >> >> would appear to TRILL to be a giant Ethernet with hundreds of >> >> neighbors. In other words, all the hundreds of RBridges >> connected to >> >> the core would see all of the other RBridges on the core >> as neighbors >> >> on this "link". >> >> >> >> IS-IS has carefully designed packet formats for LSPs and CSNPs, so >> >> that they can be arbitrarily large, transmitted in pieces, >> with each >> >> piece being able to be independently processed. For some reason >> >> though we didn't design Hellos that way. We should take the >> >> opportunity to design TRILL-Hello messages with that effect. >> >> >> >> There are some things in TRILL-Hellos that don't really need to be >> >> reported frequently (like which VLANs you support). And >> some things >> >> (like the neighbor list) that might wind up being too large to fit >> >> into a single packet. >> >> >> >> Other information (such as ID and priority) really should >> go in every >> >> TRILL-Hello. >> >> >> >> I'd suggest we do two things in the encoding of TRILL-Hellos >> >> >> >> a) figure out which fields can be left out some of the time, and >> >> specify that those fields, if absent, just mean they are >> absent, not, >> >> for instance, that you don't support any VLANs. >> >> >> >> b) for information like the neighbor list that can be arbitrarily >> >> large, figure out a way of encoding it in the spirit of CSNPs, so >> >> that partial information can be included. >> >> For instance, CNSPs say "this CSNP refers to all the LSPs from IDs >> >> between x and y". We could do the same for the TRILL-Hellos, as in >> >> "this TRILL-Hello neighbor list includes all neighbors with IDs >> >> between x and y". >> >> >> >> *********************************** >> >> >> >> Radia >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Radia.Perlman at sun.com Fri May 1 11:43:55 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 May 2009 11:43:55 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB3447.90904@cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> Message-ID: <49FB42EB.7050406@sun.com> Re: Mike Shand asking if we really need to say "I think the DRB's ID and priority is x,y", given that the IS-IS Hello contains the LAN ID. You really need priority too, otherwise, if R3 hears that R2 thinks that R1.17 is the LAN ID (aka "pseudonode ID"), R3 has no way of whether R1 should be higher priority or not. And I'm not sure we need to have anyone other than the DRB put in the LAN ID into their TRILL-Hello. What purpose does it serve? And as for whether R1's address is embedded in the LAN ID: I'd always intended that the LAN ID (the "pseudonode ID") could be any 7 byte quantity that is guaranteed to be campus-wide unique. A good way of choosing the LAN ID, if you are "R1", is to make the LAN ID "R1" followed by a byte to distinguish between up to 255 other links R1 might be DR on. But really, it just needs to be a unique 7 byte quantity (with 7th byte nonzero). Somehow it seemed to morph over the years into the top 6 bytes MUST be the system ID of the DR, right? Is there anything that depends on those 6 bytes being the system ID of the DR, or is it just folklore that it has to be the system ID of the DR? Radia mike shand wrote: > On 01/05/2009 Radia Perlman wrote: >> ********** >> Now a refinement that would be useful to discuss: >> >> While we're on the subject, one extra field that could make things >> even safer would >> >> be a TLV for "this is the (ID, priority) of who I think is DRB". > The LAN ID field in the IS-IS hello already tells you who the sender > thinks is the DIS, but it doesn't include the priority. Instead it has > the ID assigned by the DIS. Why would you want the priority? > > Mike > From ginsberg at cisco.com Fri May 1 11:43:08 2009 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Fri, 1 May 2009 11:43:08 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB20D8.6080606@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com><1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com><9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com><49F92740.6010900@sun.com> <49FABD6D.8040704@cisco.com> <49FB20D8.6080606@sun.com> Message-ID: > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Friday, May 01, 2009 9:19 AM > To: Mike Shand (mshand) > Cc: rbridge at postel.org > Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing > > Re (see below) > > Yes. You'd update the holding timer based on any fragment (not just the > fragment in > which your ID appears). It's not that big a deal to have your ID appear > in the neighbor > list less often, and assume that the state is the same as when you saw > it last. Hmmm...so if once I have confirmed two connectivity to neighbor A and I then update my hold timer whenever I receive a Hello from Neighbor A regardless of whether I am mentioned in the neighbor list included in the IIH, then when do I determine that two way connectivity is lost? You can't cheat on this. If the full set of neighbors are not being sent every time then you either have to: Lengthen the hold time for each neighbor so that we can continue to send hellos at the same rate. The down side of this is longer failure detection time. or Send hellos faster so that each neighbor is mentioned at least once per hello interval. The downside of this is increased hello overhead. > > We could have an optional second TLV in the TRILL-Hello that says > "recent changes", that could > list neighbors whose state has recently changed, and aren't in that > fragment's range, as long as there aren't very many of them. > I don't know that you need a second TLV, but I do think you would want to include a new neighbor in the hello every time during the adjacency bringup period in order to facilitate the establishment of the two way adjacency. Of course if two way connectivity is not established after some period of time then I suppose you would want to make room for other neighbors - which suggests that the SNP-like range identifier for neighbors in hellos may not be the solution. But, before working out all of these details, I would ask whether we believe the exhaustion of space in hellos is really going to be caused by having a large number of neighbors? The notion of having one campus-wide LAN would require a very large number of neighbors on each Rbridge and a very large number of hellos being sent campus-wide. This is not the best design for a robust network. There are, of course, other things (supported VLANs for instance) which TRILL requires which might cause hellos to exceed their capacity. Les > Radia > > > mike shand wrote: > > On 30/04/2009 Radia Perlman wrote: > >> b) for information like the neighbor list that can be > >> arbitrarily large, figure out a way of encoding it in the > >> spirit of CSNPs, so that partial information can be included. > >> For instance, CNSPs say "this CSNP refers to all the LSPs from > >> IDs between x and y". We could do the same for the TRILL-Hellos, > >> as in "this TRILL-Hello neighbor list includes all neighbors > >> > >> with IDs between x and y". > > So how would this work? For the hellos do we still have to send both > > (all) fragments at the same rate in order to maintain the adjacencies? > > i.e. double the hello load? Or is it sufficient to update the holding > > time on the basis of receiving ANY fragment, even though it may not > > confirm two way connectivity with you becuase you are not mentioned in > > that fragment? > > > > > > Mike > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From d3e3e3 at gmail.com Fri May 1 11:52:20 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 1 May 2009 14:52:20 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB2177.8050807@cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> Message-ID: <1028365c0905011152q1bf9f5e8ld4f37802e6003960@mail.gmail.com> The set of VLANs on which Hellos need to sent is specified in Section 4.2.4.2 "Hello VLAN Tagging", pages 34-36 of http://tools.ietf.org/id/draft-ietf-trill-rbridge-protocol-12.txt A sketch of a proof that that is a sufficient set of VLANs appears in Section 4 "No Persistent Loops", starting page 11 of http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-01.txt Thanks, Donald On Fri, May 1, 2009 at 12:21 PM, mike shand wrote: > James Carlson wrote: > > Ali Sajassi (sajassi) writes: > > > Regarding your comment that loop can happen as the result of one-way > connectivity via partitioned VLAN, AFAIK DRB selection is done over > designated VLAN and if that VLAN is partitioned, then the bridged > network is partitioned because this VLAN is expected to be reachable via > all the access ports. And if the bridged network is partitioned, the it > is O.K. to have a DRB for each of the partitions. So, where is the loop? > > > Suppose A and B are RBridges that are communicating over VLAN 1 as the > primary VLAN. They're forwarding for VLANs 2, 3, and 4 as well. > > Now suppose that VLAN 1 becomes partitioned. Both can now become DRB. > They are still forwarding for those other VLANs, though, and this > potentially means we have two forwarders on the same VLAN, which leads > to fatal forwarding loops. > > It's a problem that's specific to TRILL, because of the L2 work that > it does. It's not something that would happen with an L3 protocol. > > > > So does this mean that all these hellos need to be sent on all the VLANs? > > ??? Mike > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From ginsberg at cisco.com Fri May 1 12:15:37 2009 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Fri, 1 May 2009 12:15:37 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB42EB.7050406@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com><1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com><9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com><49F92740.6010900@sun.com><7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com><49FA2143.8070209@sun.com><7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com><18939.3098.878722.81734@gargle.gargle.HOWL><49FB2177.8050807@cisco.com><18939.9112.131115.893423@gargle.gargle.HOWL><49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> <49FB42EB.7050406@sun.com> Message-ID: > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Friday, May 01, 2009 11:44 AM > To: rbridge at postel.org > Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing > > Re: Mike Shand asking if we really need to say "I think the DRB's ID and > priority is x,y", given that > the IS-IS Hello contains the LAN ID. > > You really need priority too, otherwise, if R3 hears that R2 thinks that > R1.17 is the LAN ID (aka "pseudonode ID"), > R3 has no way of whether R1 should be higher priority or not. R3 would know this from the hellos it receives from R1.17. Or are you suggesting that R3 should take R2's word for it and override it's own internal logic as to who should be DRB even if it had not heard from R1? (I certainly hope not...) > > And I'm not sure we need to have anyone other than the DRB put in the > LAN ID into > their TRILL-Hello. What purpose does it serve? It serves as confirmation that all ISs have converged on their selection of the DIS/DRB and that each IS has correctly obtained the pseudo-node ID as selected/transmitted by the winner of the election. This is useful in debugging operational problems. > > And as for whether R1's address is embedded in the LAN ID: > I'd always intended that the LAN ID (the "pseudonode ID") could be any 7 > byte quantity that is guaranteed to > be campus-wide unique. A good way of choosing the LAN ID, if you are > "R1", is to make the LAN ID > "R1" followed by a byte to distinguish between up to 255 other links R1 > might be DR on. But > really, it just needs to be a unique 7 byte quantity (with 7th byte > nonzero). Somehow it seemed to morph over the years > into the top 6 bytes MUST be the system ID of the DR, right? Is there > anything that depends on those > 6 bytes being the system ID of the DR, or is it just folklore that it > has to be the system ID of the DR? The system ID is required to have exactly those properties i.e. it is required to be unique area wide at Level 1 and unique domain wide at Level 2. This is obviously necessary so as not to confuse the LSPs generated by two different systems. Les > > Radia > > > > > > mike shand wrote: > > On 01/05/2009 Radia Perlman wrote: > >> ********** > >> Now a refinement that would be useful to discuss: > >> > >> While we're on the subject, one extra field that could make things > >> even safer would > >> > >> be a TLV for "this is the (ID, priority) of who I think is DRB". > > The LAN ID field in the IS-IS hello already tells you who the sender > > thinks is the DIS, but it doesn't include the priority. Instead it has > > the ID assigned by the DIS. Why would you want the priority? > > > > Mike > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From james.d.carlson at Sun.COM Fri May 1 12:27:40 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 1 May 2009 15:27:40 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB42EB.7050406@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> <49FB42EB.7050406@sun.com> Message-ID: <18939.19756.469553.114509@gargle.gargle.HOWL> Radia Perlman writes: > nonzero). Somehow it seemed to morph over the years > into the top 6 bytes MUST be the system ID of the DR, right? Is there > anything that depends on those > 6 bytes being the system ID of the DR, or is it just folklore that it > has to be the system ID of the DR? I think it's the latter. I seem to recall implementations with very large numbers of links that used system ID for the first 255 and then had reserved IDs for the remainder. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From d3e3e3 at gmail.com Fri May 1 12:38:37 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 1 May 2009 15:38:37 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <7F115A41909B2641A9550322C4DF9D56CEAFF8@xmb-sjc-22d.amer.cisco.com> Message-ID: <1028365c0905011238u46c97b2cuc40f0f0a2efbf617@mail.gmail.com> Hi Ali, On Fri, May 1, 2009 at 1:20 PM, Ali Sajassi (sajassi) wrote: > > James, > > If we need to send "protective hello" on each VLAN in order to monitor > the connectivity of that VLAN over .1Q bridged network as described in > section 4.2.4.2, then so be it (although I think we can do it more > efficiently as I will talk in next paragraph). However, this is not the > point that I am driving at. If you need to have two types of TRILL > hellos messages (e.g., neighbor discovery vs.. protective), then that's > O.K. My point is that we should be able to use the same IS-IS hello > message with MTU padding for both because I don't think the frame size > can exceed 1522 bytes !! (please refer to my email on scenarios for > TRILL access/trunk ports regarding why it cannot exceed 1522). If the padded hellos would always get through, the padding did not good. If the padded hellos would not get through, your network melts down. Thus, padding hellos sent from ports that can send/receive native frames is useless. See my previous email on why I don't currently accept your assertions about 1522. > Now regarding more efficient mechanism for sending TRILL hellos. Two > cases to consider: > > 1) .1Q network is running STP/RSTP: In this case, there is only a single > active topology in the .1Q network and we can have a single VLAN that > covers the entire active topology (e.g., VLAN 1). Then just monitoring > this VLAN will be sufficient - e.g., if this VLAN is partitioned, then > the network is partitioned and all the other VLANs are partitioned. In > other words, in this scenario, there is no need to send protective hello > messages (per VLAN). I continue to think it is misleading to call the arbitrary mesh of an arbitrary combination of repeaters, hubs, 802.1D, and 802.1Q bridges of various vintages with various features enabled/disabled and variously configured "the .1Q network". Any VLAN or set of VLANs within this arbitrary bridged LAN which interconnects an arbitrary number of RBridge ports may be partitioned or may provide only one-way connectivity. And, in fact, whether they are partitioned and/or provide only one-way connectivity can be different for every pair of RBridge ports connected by this arbitrary bridged LAN. Layer 2 loops are so bad that the TRILL WG has decided it needs to do what it can to defend again configurations (even what some would call "mis-configurations") within arbitrary bridged LAN connecting RBridge ports. > 2) .1Q network is running MSTP: In this case, there are several active > topologies (one per MSTI). So, in this case, we can just have a single > VLAN per MSTI that covers the entire active topology for that MSTI. If > there are 2 or 3 MSTIs for 4K VLANs (which is typical), then you only > need to monitor 2 or 3 VLANs rather than 4K VLANs. We should know the > number of MSTIs because we have this info from BPDU in root-collision > detection procedure. As per my comment above for each of the "active topologies". In addition, it seems like a bad idea for TRILL to depend on intricacies of the more elaborate recent 802.1 BPDUs. As far as I know, 802.1 is continuing to extend and create new forms of BPDUs and I certainly think that fundamental features of the TRILL protocol such as loop safety should not depend on necessarily tracking all this and continually modifying TRILL to take it into account. Thanks, Donald > Cheers, > Ali > > > > >> -----Original Message----- >> From: James Carlson [mailto:james.d.carlson at Sun.COM] >> Sent: Friday, May 01, 2009 7:50 AM >> To: Ali Sajassi (sajassi) >> Cc: Radia Perlman; rbridge at postel.org >> Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing >> >> Ali Sajassi (sajassi) writes: >> > Regarding your comment that loop can happen as the result >> of one-way >> > connectivity via partitioned VLAN, AFAIK DRB selection is done over >> > designated VLAN and if that VLAN is partitioned, then the bridged >> > network is partitioned because this VLAN is expected to be >> reachable >> > via all the access ports. And if the bridged network is >> partitioned, >> > the it is O.K. to have a DRB for each of the partitions. >> So, where is the loop? >> >> Suppose A and B are RBridges that are communicating over VLAN >> 1 as the primary VLAN. ?They're forwarding for VLANs 2, 3, >> and 4 as well. >> >> Now suppose that VLAN 1 becomes partitioned. ?Both can now become DRB. >> They are still forwarding for those other VLANs, though, and >> this potentially means we have two forwarders on the same >> VLAN, which leads to fatal forwarding loops. >> >> It's a problem that's specific to TRILL, because of the L2 >> work that it does. ?It's not something that would happen with >> an L3 protocol. >> >> -- >> James Carlson, Solaris Networking >> >> Sun Microsystems / 35 Network Drive ? ? ? ?71.232W ? Vox +1 >> 781 442 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 ? 42.496N ? Fax +1 >> 781 442 1677 >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Radia.Perlman at sun.com Fri May 1 12:40:20 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 May 2009 12:40:20 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> <49FB42EB.7050406@sun.com> Message-ID: <49FB5024.9040103@sun.com> Les Ginsberg (ginsberg) wrote: > > >> R1.17 is the LAN ID (aka "pseudonode ID"), >> R3 has no way of whether R1 should be higher priority or not. >> > > R3 would know this from the hellos it receives from R1.17. > Or are you suggesting that R3 should take R2's word for it and override > it's own internal logic as to who should be DRB even if it had not heard > from R1? > (I certainly hope not...) > > R3 would not necessarily hear R1's TRILL-Hellos, so this is for the case where R3 can hear R2 and R1, but R3 can't hear R1. So yes, I was saying that we could have R2 tell R3 about R1. I didn't put that into the original proposal -- it's an additional safety mechanism, and what I hinted about when I said "R3 defers to any RBridge with higher ID and priority that R3 hears from or about". I don't feel strongly about this. There's trivial overhead to including the field in the TRILL-Hello. > > The system ID is required to have exactly those properties i.e. it is > required to be unique area wide at Level 1 and unique domain wide at > Level 2. This is obviously necessary so as not to confuse the LSPs > generated by two different systems. > > Les > > Of course the system ID has to be consistent and unique. I was talking about the LAN ID. There's no reason why R1 couldn't name a pseudonode any 7 byte quantity that had nonzero 7th byte, and top 6 bytes guaranteed not to be used by anyone else. So for instance, if R1 had MAC addresses R1a, R1b, R1c, ... on each of its links, and chose R1a as its system ID, there wasn't anything in the design of DECnet/IS-IS that depended on R1 choosing all its LAN ID's with top 6 bytes = R1a. Given that R1 "owns" MAC addresses R1b and R1c as well, it certainly could give LAN IDs of R1b.15 to one of its links, and R1c.12 to another, and R1a.15 to a third. Just so long as the 7 byte quantity is guaranteed unique within the campus. I was curious since several people have told me over the years (since DECnet) that the top 6 bytes *have to* be the system ID of the DR. I was wondering where that requirement came from, and whether it's just folklore, or whether there is now anything in IS-IS that would break if the top 6 bytes of a LAN ID were not equal to the system ID of the DR? Note that this question really doesn't have much to do with closing on the details of the proposal in this thread...I just am curious. Radia From jim.burrows at stellarswitches.com Fri May 1 12:45:46 2009 From: jim.burrows at stellarswitches.com (Jim Burrows) Date: Fri, 1 May 2009 15:45:46 -0400 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <49FABD6D.8040704@cisco.com> <49FB20D8.6080606@sun.com> Message-ID: <7ef3f0820905011245h6f09581cu2ab1b1835829af4f@mail.gmail.com> On Fri, May 1, 2009 at 2:43 PM, Les Ginsberg (ginsberg) wrote: > But, before working out all of these details, I would ask whether we > believe the exhaustion of space in hellos is really going to be caused > by having a large number of neighbors? The notion of having one > campus-wide LAN would require a very large number of neighbors on each > Rbridge and a very large number of hellos being sent campus-wide. This > is not the best design for a robust network. My answer is "absolutely... eventually". Remember that we're not merely designing to "make the protocols protective of unknown conditions in a harsh world" of today as James said, but for the harsh world of tomorrow, as well. There were discussions that I had 30+ years ago where people dismissed my concerns by telling me how much trouble it was to tap an Ethernet cable with a big heavy physical tap that drove a spike into the cable, and the "if they have physical access to your cable, you're doomed anyway", that come back to haunt us today as essentially the same protocol is used wirelessly. TRILL is trying to address shortcomings in the spanning tree design that is 25 years old. Inevitably, something we don't think of will cause a problem of the scope of the Beth Israel Deaconess crash, but it would be really good for us to postpone that as far into the future as possible. There are pretty plausible scenarios that suggest ways in which the number of neighbors can readily be huge, so I think we need to assume that we'll have to deal wit them. JimB. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090501/e4bab966/attachment.html From ginsberg at cisco.com Fri May 1 13:06:36 2009 From: ginsberg at cisco.com (Les Ginsberg (ginsberg)) Date: Fri, 1 May 2009 13:06:36 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB5024.9040103@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> <49FB42EB.7050406@sun.com> <49FB5024.9040103@sun.com> Message-ID: > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Friday, May 01, 2009 12:40 PM > To: Les Ginsberg (ginsberg) > Cc: rbridge at postel.org > Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing > > Les Ginsberg (ginsberg) wrote: > > > > > >> R1.17 is the LAN ID (aka "pseudonode ID"), > >> R3 has no way of whether R1 should be higher priority or not. > >> > > > > R3 would know this from the hellos it receives from R1.17. > > Or are you suggesting that R3 should take R2's word for it and override > > it's own internal logic as to who should be DRB even if it had not heard > > from R1? > > (I certainly hope not...) > > > > > R3 would not necessarily hear R1's TRILL-Hellos, so this is for the case > where R3 can hear R2 and R1, but R3 can't hear R1. Hmmm...too many R1s in that sentence. Did you mean R3 can hear R2 (but not R1) while all other interactions are fully transitive? > So yes, I was saying that we could have R2 tell R3 about R1. > I didn't put that into the original proposal -- it's an additional > safety mechanism, and what I hinted > about when I said "R3 defers to any RBridge with higher ID and priority > that R3 hears from or about". Please present a state machine which defines how DRB election should occur on R3 based upon the information R3 receives directly (i.e. ID, priority it receives directly from the originating ISs) and information R3 receives indirectly (i.e. ID, priority it receives from an IS other than the source ID). Please include a description of how this resolves ambiguous advertisements. > > I don't feel strongly about this. There's trivial overhead to including > the field in the TRILL-Hello. > > > > The system ID is required to have exactly those properties i.e. it is > > required to be unique area wide at Level 1 and unique domain wide at > > Level 2. This is obviously necessary so as not to confuse the LSPs > > generated by two different systems. > > > > Les > > > > > Of course the system ID has to be consistent and unique. I was talking > about the LAN ID. > There's no reason why R1 couldn't name a pseudonode any 7 byte quantity > that had > nonzero 7th byte, and top 6 bytes guaranteed not to be used by anyone > else. So for instance, > if R1 had MAC addresses R1a, R1b, R1c, ... on each of its links, and > chose R1a as its > system ID, there wasn't anything in the design of DECnet/IS-IS that > depended on R1 choosing > all its LAN ID's with top 6 bytes = R1a. Given that R1 "owns" MAC > addresses R1b and R1c as well, > it certainly could give LAN IDs of R1b.15 to one of its links, and > R1c.12 to another, > and R1a.15 to a third. Just so long as the 7 byte quantity is guaranteed > unique within the campus. Given that the LANID is also used as the pseudo-node ID in the pseudo-node LSPs generated for that LAN (and the IS neighbor advertisements in the non-pseudo-node LSPs), the selection would have to meet the same constraints as are placed on the systemID. So, yes - one could use two different MAC addresses as the first 6 octets of the LANID for two different circuits on which an IS is the DIS so long as both MAC addresses meet the systemid constraints - but why would you? It certainly would be more confusing to debug as the pseudo-node IDs would no longer have any obvious connection to the systemID of the system which generated them. Les > > I was curious since several people have told me over the years (since > DECnet) > that the top 6 bytes *have to* > be the system ID of the DR. I was wondering where that requirement came > from, and whether it's just folklore, or whether > there is now anything in IS-IS that would break if the top 6 bytes of a > LAN ID were not > equal to the system ID of the DR? > > Note that this question really doesn't have much to do with closing on > the details of the proposal in this thread...I just > am curious. > > Radia From Radia.Perlman at sun.com Fri May 1 14:54:36 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 01 May 2009 14:54:36 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <49FABD6D.8040704@cisco.com> <49FB20D8.6080606@sun.com> Message-ID: <49FB6F9C.9060708@sun.com> Re: Les Ginsberg asking about how R2 would notice R1 stopped hearing R2's Hellos if R2 wasn't in every TRILL-Hello. This is the same principle as the IS-IS CSNP encoding. The TRILL Hello would say: "This neighbor list is for neighbors between x and y". That means if your ID is < x or > y, then you don't look for yourself in (this) Hello. If your ID is between x and y, then it is relevant if you appear there or not. (And as Jim said, we need flags for saying whether x is the smallest ID, and y is the largest ID, but that's a detail...) Nbr list fragmentation does mean that if the neighbor list is fragmented into 4 pieces, that it would take R2 4 times as long to notice whether R1 can hear its Hellos, or that R1 stopped hearing its Hellos. So R1 has to adjust the holding timer based on how often each neighbor appears explicitly in a fragment. If we're worried about that (which I don't think we should be), we can either have the DRB send TRILL-Hellos on the Designated VLAN k times as often, if the neighbor list was in k fragments, or have the extra TLV that I was mentioning with the "recent changes". It's also somewhat important for non-DRBs R2 and R3 to know if they have connectivity to each other (if they don't, they need to forward to each other through the DRB), but this would be a rare enough case that if we lost data for awhile before noticing it, because R2's neighbor list is fragmented, I wouldn't think it important enough to worry about. It's just data that gets dropped -- no loops or anything. So at most I think we might want to recommend that the DRB transmit fragmented TRILL-Hellos more frequently, but I think even that is not that important. Radia From sgai at cisco.com Mon May 4 06:17:10 2009 From: sgai at cisco.com (sgai) Date: Mon, 04 May 2009 06:17:10 -0700 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49F92740.6010900@sun.com> Message-ID: Sorry to be late on replying to this thread, I support Radia's proposal -- Silvano On 4/29/09 9:21 PM, "Radia Perlman" wrote: > Moving to a new thread, since the "Why is MTU discovery important" thread > was getting too long (and the subject line had nothing to do with most > of the discussion). > > Hopefully we can quickly close the issue of DRB election/MTU discovery. > And then finally close on the base protocol document... > > I was participating in an off-list > group of people discussing the issue, which was useful in clarifying > certain aspects. > I will summarize the proposed solution. > > First, refreshing people as to what the issue is: > > The problem: The Hello protocol in IS-IS may elect multiple > DRs, since routers ignore routers with whom they do not have > 2-way connectivity. Somewhat orthogonally, IS-IS LAN > Hellos are padded, to avoid forming adjacencies with neighbors > that you can't speak the minimum acceptable size with. > > This behavior is fine for layer 3, but not for layer 2, where > it will form loops if there are multiple DRBs. > > So ignoring this issue for TRILL is not an option. > > > *********************** > A bit of background on IS-IS > > IS-IS is modular, in that there are two sublayers, that > in DECnet we called the "subnetwork independent sublayer" > and the "subnetwork dependent sublayer". The subnetwork > dependent sublayer has neighbor adjacency forming protocols > for different types of links. > > What we are proposing for TRILL is support for a new type > of link within IS-IS's "link dependent sublayer". This > is for Ethernet links that are not explicitly pt-to-pt. > > What we need to accomplish with this protocol: > > a) elect exactly one DRB > b) figure out what the campus-wide minimum MTU size, "S", is (to know > what the minimum acceptable link MTU size is). LSP fragment > sizes must not be larger than this minimum > c) test neighbor-neighbor links to see if they support size S > d) remove links from the topology that do not support the > campus minimum size S > > ***************************** > > Electing exactly one DRB > > This will be based on periodic messages, which we'll > call TRILL-Hellos, similar to IS-IS > LAN Hellos, but they are different in two aspects: they are > not padded, and election is based solely on (ID, priority), and > not on whether connectivity is 2-way. In other words, R2 > defers to R1 if R1 has higher (ID, priority), whether or > not there is 2-way connectivity between R2 and R1. > > TRILL-Hellos must be periodic and frequent, so as > to avoid having RBs not know about each other. They will be > sent on the set of VLANs that the TRILL spec already says Hellos > would be sent on. > > TRILL-Hellos contain all the same information > that the TRILL spec already claims is in Hello messages. (other > than the difference that they won't be padded). > > So basically, the changes in the TRILL spec so far are > 1) rename Hello to "TRILL-Hello message" > 2) do not pad the message > 3) election will be based solely on the fields (ID, priority). > > Note: Although the neighbor list is included in a TRILL-Hello, (as it is in > an IS-IS LAN Hello), it does not affect selection of DRB. > But the neighbor list still needs to be there > for all the RBridges to > know which neighbors they have 2-way connectivity with, for the > purpose of reporting links in LSPs. > > ******************************* > > figuring out what the campus-wide minimum MTU size is: > > This will be done based on a TLV in LSPs (which already > exists in IS-IS -- the originatingLSPBufferSize, TLV 14). > If that TLV is absent, > it is the same as requesting "1470". The campus-wide minimum MTU size > chosen is the smallest size "S" reported in any LSP. > > LSP fragments must not be bigger than S, and links that cannot > support S will not appear in the topology (meaning, they will not > be reported in LSPs) > > > *************************************************** > testing neighbor-neighbor links to ensure they support "S". > > We will have new messages: MTU probe, and MTU ack. Both > are padded to size S. > > It will be optional whether and when to send an MTU > probe, but mandatory to send an ack in response to receipt > of an MTU probe. The ack is padded to the same size that the > probe was padded to, and is unicast to the RBridge from > which the probe was received. Probes may be unicast or > multicast. They may be sent periodically (but far less > frequently than DRB election messages). Or they might be > sent only in response to an event such as hearing from > a new neighbor RBridge. Both MTU probes and acks are > sent only on the Designated VLAN. > > If R1 fails to get an ack from R2, R1 still reports R2 in > its neighbor list, but with a flag saying "failed minimum MTU test". > > > > **************** > Links that are not 2-way for any reason, including not > supporting the minimum campus-wide MTU S, are not reported in LSPs. > > That means that if R1 is DRB, and it does not have 2-way connectivity > to R2, R1 does not list R2 as a neighbor, in the pseudonode LSP. > R2 does not report a link to the pseudonode. > > If neither R2 nor R3 are DRB, they both have 2-way connectivity to > the DRB, but not to each other, then they do both report > connectivity to the pseuodnode. However, if R2 receives > a packet that needs to be forwarded to R3 across that link, R2 > sends the packet to the DRB instead. (Note: This behavior is > already specified in IS-IS) > > ******************* > Concern was raised about the size of TRILL-hellos. Might they wind up being > too big to fit? This concern would apply whether Hellos are padded > or not. > > For instance, one topology > people envision is a core that connects hundreds of customer sites > into a giant Ethernet. The technology that creates the core is > irrelevant to TRILL, other than having Ethernet-like characteristics, in > terms of being multiaccess and supporting multicast. > > In that case, if the customer's Ethernet > is running TRILL, the core would appear to TRILL to be a giant Ethernet with > hundreds of neighbors. In other words, all the hundreds of RBridges > connected to the core would see all of the other RBridges on the core > as neighbors on this "link". > > IS-IS has carefully designed packet formats for LSPs and CSNPs, so > that they can be arbitrarily large, transmitted in pieces, with each > piece being able to be independently processed. For some reason > though we didn't design Hellos that way. We should take the > opportunity to design TRILL-Hello messages with that effect. > > There are some things in TRILL-Hellos that don't really need to > be reported frequently (like which VLANs you support). And some things > (like the neighbor list) that might wind up being too large to fit > into a single packet. > > Other information (such as ID and priority) really should go in every > TRILL-Hello. > > I'd suggest we do two things in the encoding of TRILL-Hellos > > a) figure out which fields can be left out some of the time, > and specify that those fields, if absent, just mean they > are absent, not, for instance, that you don't support any VLANs. > > b) for information like the neighbor list that can be > arbitrarily large, figure out a way of encoding it in the > spirit of CSNPs, so that partial information can be included. > For instance, CNSPs say "this CSNP refers to all the LSPs from > IDs between x and y". We could do the same for the TRILL-Hellos, > as in "this TRILL-Hello neighbor list includes all neighbors > with IDs between x and y". > > *********************************** > > Radia > > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From Radia.Perlman at sun.com Mon May 4 22:31:59 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 04 May 2009 22:31:59 -0700 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames In-Reply-To: <92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> References: <48EFDA99.9070304@sun.com> <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com> <48F08FEA.1000302@cisco.com> <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com> <49A85BAB.9060703@sun.com> <18856.28188.700649.936645@gargle.gargle.HOWL> <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> <18859.58654.253695.410225@gargle.gargle.HOWL> <92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> Message-ID: <49FFCF4F.4090004@sun.com> Several people were not happy about the encapsulation of TRILL IS-IS frames in version 12. After talking to a bunch of people, here is a proposed compromise: The current spec says that the only thing differentiating a TRILL IS-IS frame from a layer 3 IS-IS is the outer MAC DA. There were objections based on: a) some links might not have DAs b) IS-IS's SAP encoding precludes jumbograms, which would be possible using an Ethertype c) not all control frames are multicast (e.g., MTU acks). So, after discussion with a bunch of people, it seems like the cleanest solution is to have a new Ethertype for layer 2 IS-IS. For TRILL IS-IS frames that are multicast, we'd still use a different multicast DA for TRILL IS-IS than layer 3 IS-IS, so there would be both the Ethertype and the multicast DA to distinguish them. For links that do not have DAs (like PPP), and for control packets that are unicast (like MTU acks), the Ethertype would distinguish. That would mean that TRILL IS-IS frames would look like: outer Ethernet header: . SA (obvious) . DA (if multicast, "All-IS-IS-RBridges", if unicast, the intended recipient) . VLAN (usually the Designated VLAN, other than extra TRILL-Hellos that need to be "sprayed") . new Ethertype = l2-IS-IS Then the TRILL IS-IS frame (LSP, CSNP, etc.) ESADI would be the same, other than having an outer Ethernet header with protocol type "TRILL", and a TRILL header. After the TRILL header the ESADI would look like the above. Radia From mshand at cisco.com Tue May 5 05:33:55 2009 From: mshand at cisco.com (mike shand) Date: Tue, 05 May 2009 13:33:55 +0100 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB5024.9040103@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> <49FB42EB.7050406@sun.com> <49FB5024.9040103@sun.com> Message-ID: <4A003233.3060607@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090505/654d1390/attachment.html From mshand at cisco.com Tue May 5 05:39:07 2009 From: mshand at cisco.com (mike shand) Date: Tue, 05 May 2009 13:39:07 +0100 Subject: [rbridge] Proposed resolution of DRB election/MTU testing In-Reply-To: <49FB42EB.7050406@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E213885C654ED9E9@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0904271348k731840e6nf9af2e9ba12f15bf@mail.gmail.com> <9793EC0A42D76D4EB2A8F94D77E213885C654EDB32@SJEXCHCCR02.corp.ad.broadcom.com> <49F92740.6010900@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAC54@xmb-sjc-22d.amer.cisco.com> <49FA2143.8070209@sun.com> <7F115A41909B2641A9550322C4DF9D56CEAF08@xmb-sjc-22d.amer.cisco.com> <18939.3098.878722.81734@gargle.gargle.HOWL> <49FB2177.8050807@cisco.com> <18939.9112.131115.893423@gargle.gargle.HOWL> <49FB2C8A.6090206@sun.com> <49FB3447.90904@cisco.com> <49FB42EB.7050406@sun.com> Message-ID: <4A00336B.8060807@cisco.com> On 01/05/2009 Radia Perlman wrote: > And I'm not sure we need to have anyone other than the DRB put in the > LAN ID into > > their TRILL-Hello. What purpose does it serve? It doesn't serve any purpose in the protocol (although I seem to remember you did originally have some idea of performing a consistancy check on this). But it is really useful for debugging weird problems by looking at what is on the wire, rather than having to rely on what may or may not be accurately reported in various routers' management interfaces. Mike From anoop at brocade.com Tue May 5 05:58:47 2009 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 5 May 2009 05:58:47 -0700 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-ISframes In-Reply-To: <49FFCF4F.4090004@sun.com> References: <48EFDA99.9070304@sun.com><1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com><48F08FEA.1000302@cisco.com><1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com><49A85BAB.9060703@sun.com><18856.28188.700649.936645@gargle.gargle.HOWL><4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com><18859.58654.253695.410225@gargle.gargle.HOWL><92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> <49FFCF4F.4090004@sun.com> Message-ID: <4C94DE2070B172459E4F1EE14BD2364E02F882D4@HQ-EXCH-5.corp.brocade.com> It looks like the only change being proposed is the use of a new Ethertype for TRILL IS-IS. Sounds like a reasonable proposal. Anoop > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Monday, May 04, 2009 10:32 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Proposed resolution: Re: encoding of > TRILL IS-ISframes > > Several people were not happy about the encapsulation of TRILL IS-IS > frames in > version 12. After talking to a bunch of people, here is a proposed > compromise: > > The current spec says that the only thing differentiating a > TRILL IS-IS > frame from a > layer 3 IS-IS is the outer MAC DA. There were objections based on: > a) some links might not have DAs > b) IS-IS's SAP encoding precludes jumbograms, which would be possible > using an Ethertype > c) not all control frames are multicast (e.g., MTU acks). > > So, after discussion with a bunch of people, > it seems like the cleanest solution is to have a new Ethertype for > layer 2 IS-IS. For TRILL IS-IS frames that are multicast, we'd still > use a different multicast DA for TRILL IS-IS than layer 3 IS-IS, so > there would be both the Ethertype and the multicast DA to > distinguish them. > > For links that do not have DAs (like PPP), and for control > packets that > are unicast (like MTU acks), the Ethertype would distinguish. > > That would mean that TRILL IS-IS frames would look like: > > outer Ethernet header: > . SA (obvious) > . DA (if multicast, "All-IS-IS-RBridges", if unicast, the intended > recipient) > . VLAN (usually the Designated VLAN, other than extra TRILL-Hellos > that need to be "sprayed") > . new Ethertype = l2-IS-IS > > Then the TRILL IS-IS frame (LSP, CSNP, etc.) > > ESADI would be the same, other than having an outer Ethernet > header with > protocol type "TRILL", and a TRILL header. After the TRILL header > the ESADI would look like the above. > > Radia > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Tue May 5 10:07:59 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 05 May 2009 10:07:59 -0700 Subject: [rbridge] Is it a problem to limit to 255, the # of links R1 can be DRB for? Message-ID: <4A00726F.8070005@sun.com> As Mike Shand pointed out, the IS-IS spec really does say that the 7 byte pseudonode ID has to have the top 6 bytes=system ID of the DR. So what would break if that was simply ignored? There are two ways that the restriction is used today in IS-IS: a) In the IS-IS spec (as Mike pointed out), it helps R1 recognize a pseudonode LSP that R1 had generated in a previous incarnation (before R1 crashed), so R1 knows it should purge it b) for general manageability, so it's clear which router generated pseudonode ID "R1.x" So...it seems like there are several choices at this point for TRILL: 1) assume the 255 link limit is not a problem, especially with pseudonode suppression, and keep the restriction that the 7-byte pseudonode ID has to have the top 6 bytes=the DRB's system ID 2) say that the top 6 bytes can be any 6-byte ID owned by the DRB, which still allows it to recognize its own LSPs, and makes the # of links it can be DRB for pretty much unlimited (it probably has a MAC address for each of its links) 3) allow the multicast form of the system ID (where the multicast bit is set), in addition to the regular system ID, which doubles the number of links R1 can be DRB for (and declare a pseudonode for) 4) change the format of LSP to have 8 byte IDs rather than 7. Radia From james.d.carlson at Sun.COM Tue May 5 10:49:53 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Tue, 5 May 2009 13:49:53 -0400 Subject: [rbridge] Is it a problem to limit to 255, the # of links R1 can be DRB for? In-Reply-To: <4A00726F.8070005@sun.com> References: <4A00726F.8070005@sun.com> Message-ID: <18944.31809.331270.486332@gargle.gargle.HOWL> Radia Perlman writes: > 1) assume the 255 link limit is not a problem, especially with pseudonode > suppression, and keep the restriction that the 7-byte pseudonode ID has > to have the top 6 bytes=the DRB's system ID > > 2) say that the top 6 bytes can be any 6-byte ID owned by the DRB, which > still allows it to recognize its own LSPs, and makes the # of links it > can be > DRB for pretty much unlimited (it probably has a MAC address for > each of its links) > > 3) allow the multicast form of the system ID (where the multicast > bit is set), in addition to the regular system ID, which doubles the > number of links R1 can be DRB for (and declare a pseudonode for) > > 4) change the format of LSP to have 8 byte IDs rather than 7. Both (1) and (2) sound good to me. (2) sounds fairly familiar. (Likely something we did back at IronBridge ...) I'm not sure I see a point for (3) over (2). As long as you're using something other than 'the' system ID, what you choose to use likely has no additional impact. Thus, trying to keep the address "similar" by making just one bit different probably isn't helpful. I wouldn't want to see (4) unless it were changed everywhere. Keeping a hack like that straight for just TRILL IS-IS would be difficult. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From erik.nordmark at sun.com Wed May 6 14:59:28 2009 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 06 May 2009 14:59:28 -0700 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames In-Reply-To: <49FFCF4F.4090004@sun.com> References: <48EFDA99.9070304@sun.com> <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com> <48F08FEA.1000302@cisco.com> <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com> <49A85BAB.9060703@sun.com> <18856.28188.700649.936645@gargle.gargle.HOWL> <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> <18859.58654.253695.410225@gargle.gargle.HOWL> <92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> <49FFCF4F.4090004@sun.com> Message-ID: <4A020840.4070007@sun.com> Radia Perlman wrote: > That would mean that TRILL IS-IS frames would look like: > > outer Ethernet header: > . SA (obvious) > . DA (if multicast, "All-IS-IS-RBridges", if unicast, the intended > recipient) > . VLAN (usually the Designated VLAN, other than extra TRILL-Hellos > that need to be "sprayed") > . new Ethertype = l2-IS-IS *If* an IS-IS frame can ever be less than the Ethernet minimum of 60 bytes, then there might be an issue here. L3 IS-IS using the 802.3 header with a length field in place of an Ethernet type can tell from that length field the actual size of the frame before the sender padded it out to 60. If TRILL IS-IS doesn't use the 802.3 length field then we'd need some other way to tell how large the frame was prior to padding to 60 bytes. (Other protocols, like IP, which uses an Ethernet type have their own length field so they don't need the 802.3 length field. I don't know if IS-IS has its own length field or whether it relies on the 802.3 length field.) Erik From Radia.Perlman at sun.com Wed May 6 18:20:32 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 06 May 2009 18:20:32 -0700 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames In-Reply-To: <4A020840.4070007@sun.com> References: <48EFDA99.9070304@sun.com> <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com> <48F08FEA.1000302@cisco.com> <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com> <49A85BAB.9060703@sun.com> <18856.28188.700649.936645@gargle.gargle.HOWL> <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> <18859.58654.253695.410225@gargle.gargle.HOWL> <92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> <49FFCF4F.4090004@sun.com> <4A020840.4070007@sun.com> Message-ID: <4A023760.10801@sun.com> Re: Erik pointing out that PDUs will have to be bigger than 60 bytes if we use an Ethertype for TRILL- IS-IS I'm not sure whether the minimum size constraint still exists when the technology isn't CSMA/CD (anyone know?), but it seems like we could say that if an RBridge wants to send any IS-IS PDU that would be smaller than 60 bytes, it has to include the padding TLV (TLV type 8) to make it be at least size 60. I believe that TLV can be included in any of the PDUs. (right?) Radia Erik Nordmark wrote: > Radia Perlman wrote: > > >> That would mean that TRILL IS-IS frames would look like: >> >> outer Ethernet header: >> . SA (obvious) >> . DA (if multicast, "All-IS-IS-RBridges", if unicast, the intended >> recipient) >> . VLAN (usually the Designated VLAN, other than extra TRILL-Hellos >> that need to be "sprayed") >> . new Ethertype = l2-IS-IS >> > > *If* an IS-IS frame can ever be less than the Ethernet minimum of 60 > bytes, then there might be an issue here. > > L3 IS-IS using the 802.3 header with a length field in place of an > Ethernet type can tell from that length field the actual size of the > frame before the sender padded it out to 60. > > If TRILL IS-IS doesn't use the 802.3 length field then we'd need some > other way to tell how large the frame was prior to padding to 60 bytes. > > (Other protocols, like IP, which uses an Ethernet type have their own > length field so they don't need the 802.3 length field. I don't know if > IS-IS has its own length field or whether it relies on the 802.3 length > field.) > > Erik > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From mshand at cisco.com Thu May 7 03:08:06 2009 From: mshand at cisco.com (mike shand) Date: Thu, 07 May 2009 11:08:06 +0100 Subject: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames In-Reply-To: <4A020840.4070007@sun.com> References: <48EFDA99.9070304@sun.com> <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com> <48F08FEA.1000302@cisco.com> <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com> <49A85BAB.9060703@sun.com> <18856.28188.700649.936645@gargle.gargle.HOWL> <4B77B4B9-257D-401C-98A2-3E565648B947@stellarswitches.com> <18859.58654.253695.410225@gargle.gargle.HOWL> <92B5AA64-105F-476E-965C-D01F0554377E@stellarswitches.com> <49FFCF4F.4090004@sun.com> <4A020840.4070007@sun.com> Message-ID: <4A02B306.1090902@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090507/8b4ef95f/attachment.html From ddutt at cisco.com Fri May 8 15:30:06 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Fri, 08 May 2009 15:30:06 -0700 Subject: [rbridge] Hop Count processing Message-ID: <4A04B26E.5090702@cisco.com> I'd like to modify the hop count processing in section 3.6 (of draft 12) slightly. The advantages of this alignment are: - Make it possible to implement something like L2 traceroute - Align it with what is done in other protocols such as IP and MPLS for development and operational simplicity. - Not forward a frame that will be dropped by the next hop. The existing text at the beginning of 3.6 is: The Hop Count field is a 6-bit unsigned integer. Each RBridge that is about to forward a TRILL data or ESADI frame MUST check this field and discard the frame if this field is zero. If this field is greater than or equal to 1, it MUST be decremented in the forwarded frame. The suggested replacement is: The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if either the Hop Count in the received frame is 0 or the Hop Count is decremented to 0. Comments ? Dinesh -- 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 Sat May 9 07:48:11 2009 From: touch at ISI.EDU (Joe Touch) Date: Sat, 09 May 2009 07:48:11 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A04B26E.5090702@cisco.com> References: <4A04B26E.5090702@cisco.com> Message-ID: <4A0597AB.1070909@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dinesh G Dutt wrote: > I'd like to modify the hop count processing in section 3.6 (of draft 12) > slightly. The advantages of this alignment are: > - Make it possible to implement something like L2 traceroute Bad idea. Keep in mind that this isn't L2 anything; it'd be *trill*. Even then, it seems nonsensical to support on 802 networks. > - Align it with what is done in other protocols such as IP and MPLS > for development and operational simplicity. > - Not forward a frame that will be dropped by the next hop. How do you know it won't be accepted by the next hop? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoFl6oACgkQE5f5cImnZrukrwCfRzvaPMqyDEI3w4k8fq4SRhdd lyYAn2/CO4tY/6bazrTNaGRjnmSvTHcJ =+8Kg -----END PGP SIGNATURE----- From sgai at cisco.com Sat May 9 08:17:49 2009 From: sgai at cisco.com (sgai) Date: Sat, 09 May 2009 08:17:49 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A0597AB.1070909@isi.edu> Message-ID: We ABSOLUTELY need to be able to support a "TRILL traceroute". Manageability and troubleshooting are mandatory requirements of any deployable solution -- Silvano On 5/9/09 7:48 AM, "Joe Touch" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dinesh G Dutt wrote: >> I'd like to modify the hop count processing in section 3.6 (of draft 12) >> slightly. The advantages of this alignment are: >> - Make it possible to implement something like L2 traceroute > > Bad idea. Keep in mind that this isn't L2 anything; it'd be *trill*. > Even then, it seems nonsensical to support on 802 networks. > >> - Align it with what is done in other protocols such as IP and MPLS >> for development and operational simplicity. >> - Not forward a frame that will be dropped by the next hop. > > How do you know it won't be accepted by the next hop? > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoFl6oACgkQE5f5cImnZrukrwCfRzvaPMqyDEI3w4k8fq4SRhdd > lyYAn2/CO4tY/6bazrTNaGRjnmSvTHcJ > =+8Kg > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Sat May 9 08:36:28 2009 From: touch at ISI.EDU (Joe Touch) Date: Sat, 09 May 2009 08:36:28 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: References: Message-ID: <4A05A2FC.6090709@isi.edu> sgai wrote: > We ABSOLUTELY need to be able to support a "TRILL traceroute". > Manageability and troubleshooting are mandatory requirements of any > deployable solution No, they clearly are not, since 802 lacks them. However, if you want a way to see all the trill components a message passes through, you need a few things: a) define a signalling protocol, ala ICMP, in which to send the 'hopcount exceeded' message exceeded b) you need source/dest addrs that don't change hop by hop, or full bidirectional path state in the trill nodes I reviewed the protocol doc (since things have changed a bit since I've been tracking in detail - not always for the better, AFAICT), which indicates that the outer addresses still change hop by hop. If all routing protocols supported by TRILL (will it ever be more than IS-IS?) have bidirectional tables, there *might* be a way home, but it's distinctly not like either MPLS (hard bidirectional state on the path) or like IP. In particular, if the inner source address has a different egress than ingress, then traceroute will not work. Traceroute will work, at best, AFAICT, *only* from trill nodes, and not always unless ingress=egress is enforced for inner addresses. This isn't about what is "wanted" or even "needed", but about what is possible. Joe > On 5/9/09 7:48 AM, "Joe Touch" wrote: > > > > Dinesh G Dutt wrote: >>>> I'd like to modify the hop count processing in section 3.6 (of draft 12) >>>> slightly. The advantages of this alignment are: >>>> - Make it possible to implement something like L2 traceroute > Bad idea. Keep in mind that this isn't L2 anything; it'd be *trill*. > Even then, it seems nonsensical to support on 802 networks. > >>>> - Align it with what is done in other protocols such as IP and MPLS >>>> for development and operational simplicity. >>>> - Not forward a frame that will be dropped by the next hop. > How do you know it won't be accepted by the next hop? > > Joe From ddutt at cisco.com Sat May 9 10:45:26 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Sat, 09 May 2009 10:45:26 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A05A2FC.6090709@isi.edu> References: <4A05A2FC.6090709@isi.edu> Message-ID: <4A05C136.6040706@cisco.com> Joe Touch wrote: > sgai wrote: > >> We ABSOLUTELY need to be able to support a "TRILL traceroute". >> Manageability and troubleshooting are mandatory requirements of any >> deployable solution >> > > No, they clearly are not, since 802 lacks them. > 802 doesn't lack them. Check out 802.1ag. They're designed for a spanning tree like solution. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From sgai at cisco.com Sat May 9 13:08:37 2009 From: sgai at cisco.com (sgai) Date: Sat, 09 May 2009 13:08:37 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A05A2FC.6090709@isi.edu> Message-ID: I am not proposing that the current TRILL protocol definition should include "TRILL traceroute". I just think it is a good idea to have the appropriate hooks to be able to develop it, to be competitive with IEEE 802.1ag. The text that Dinesh proposed achieves this goal. -- Silvano On 5/9/09 8:36 AM, "Joe Touch" wrote: > sgai wrote: >> We ABSOLUTELY need to be able to support a "TRILL traceroute". >> Manageability and troubleshooting are mandatory requirements of any >> deployable solution > > No, they clearly are not, since 802 lacks them. > > However, if you want a way to see all the trill components a message > passes through, you need a few things: > > a) define a signalling protocol, ala ICMP, in which to > send the 'hopcount exceeded' message exceeded > > b) you need source/dest addrs that don't change hop > by hop, or full bidirectional path state in the > trill nodes > > I reviewed the protocol doc (since things have changed a bit since I've > been tracking in detail - not always for the better, AFAICT), which > indicates that the outer addresses still change hop by hop. If all > routing protocols supported by TRILL (will it ever be more than IS-IS?) > have bidirectional tables, there *might* be a way home, but it's > distinctly not like either MPLS (hard bidirectional state on the path) > or like IP. > > In particular, if the inner source address has a different egress than > ingress, then traceroute will not work. Traceroute will work, at best, > AFAICT, *only* from trill nodes, and not always unless ingress=egress is > enforced for inner addresses. > > This isn't about what is "wanted" or even "needed", but about what is > possible. > > Joe > >> On 5/9/09 7:48 AM, "Joe Touch" wrote: >> >> >> >> Dinesh G Dutt wrote: >>>>> I'd like to modify the hop count processing in section 3.6 (of draft 12) >>>>> slightly. The advantages of this alignment are: >>>>> - Make it possible to implement something like L2 traceroute >> Bad idea. Keep in mind that this isn't L2 anything; it'd be *trill*. >> Even then, it seems nonsensical to support on 802 networks. >> >>>>> - Align it with what is done in other protocols such as IP and MPLS >>>>> for development and operational simplicity. >>>>> - Not forward a frame that will be dropped by the next hop. >> How do you know it won't be accepted by the next hop? >> >> Joe From d3e3e3 at gmail.com Sun May 10 18:32:40 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 10 May 2009 21:32:40 -0400 Subject: [rbridge] Is it a problem to limit to 255, the # of links R1 can be DRB for? In-Reply-To: <18944.31809.331270.486332@gargle.gargle.HOWL> References: <4A00726F.8070005@sun.com> <18944.31809.331270.486332@gargle.gargle.HOWL> Message-ID: <1028365c0905101832i6952a1f9re4de2a20d752579b@mail.gmail.com> I think it would be good to allow for more than 255 links and I support option 2. I also agree with Mike Shand that, for ease of debugging, that option shouldn't be used unless necessary. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Tue, May 5, 2009 at 1:49 PM, James Carlson wrote: > Radia Perlman writes: > > 1) assume the 255 link limit is not a problem, especially with pseudonode > > suppression, and keep the restriction that the 7-byte pseudonode ID has > > to have the top 6 bytes=the DRB's system ID > > > > 2) say that the top 6 bytes can be any 6-byte ID owned by the DRB, which > > still allows it to recognize its own LSPs, and makes the # of links it > > can be > > DRB for pretty much unlimited (it probably has a MAC address for > > each of its links) > > > > 3) allow the multicast form of the system ID (where the multicast > > bit is set), in addition to the regular system ID, which doubles the > > number of links R1 can be DRB for (and declare a pseudonode for) > > > > 4) change the format of LSP to have 8 byte IDs rather than 7. > > Both (1) and (2) sound good to me. (2) sounds fairly familiar. > (Likely something we did back at IronBridge ...) > > I'm not sure I see a point for (3) over (2). As long as you're using > something other than 'the' system ID, what you choose to use likely > has no additional impact. Thus, trying to keep the address "similar" > by making just one bit different probably isn't helpful. > > I wouldn't want to see (4) unless it were changed everywhere. Keeping > a hack like that straight for just TRILL IS-IS would be difficult. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090510/17d09cc2/attachment.html From james.d.carlson at sun.com Mon May 11 04:42:56 2009 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 11 May 2009 07:42:56 -0400 Subject: [rbridge] Hop Count processing In-Reply-To: <4A04B26E.5090702@cisco.com> References: <4A04B26E.5090702@cisco.com> Message-ID: <18952.3904.411488.291442@gargle.gargle.HOWL> Dinesh G Dutt writes: > The suggested replacement is: > > The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if either the Hop Count in the received frame is 0 or the Hop > Count is decremented to 0. I think I need more information on this proposal. I don't see how it helps with any sort of tracing work versus the existing logic. The existing logic looks something like this for receiving TRILL packets: if we're the destination then decapsulate and forward via L2 # note: ignore hop limit else if hop limit is zero then discard # note: this is where you'd implement tracing else decrement hop limit forward via nickname endif The new logic you're proposing seems to be this: if hop limit is zero then discard else if we're the destination then decapsulate and forward via L2 else decrement hop limit if hop limit is now zero then discard else forward via nickname endif endif Besides being slightly more complex, I don't see how the proposed new logic would do anything other than reduce the maximum radius of a TRILL network by 1. All that it appears to do is make zero an illegal value on the wire, where it was once legal as long as no more forwarding was needed (i.e., on the last hop). At a guess, the rationale for this proposal seems to be centered on the new check of the hop limit after the decrement in the forwarding case, but how is that new check beneficial? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Mon May 11 08:50:39 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Mon, 11 May 2009 08:50:39 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <18952.3904.411488.291442@gargle.gargle.HOWL> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> Message-ID: <4A08494F.7090902@cisco.com> James Carlson wrote: > if we're the destination then > decapsulate and forward via L2 > # note: ignore hop limit > This s the difference. How can I do anything like a traceroute if the frame is delivered when hop count is 0, but you've reached the destination ? BTW, this logic also complicates the processing of multi-destination frames when some Rbridges have access ports and inter-Rbridge links. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From james.d.carlson at sun.com Mon May 11 09:05:43 2009 From: james.d.carlson at sun.com (James Carlson) Date: Mon, 11 May 2009 12:05:43 -0400 Subject: [rbridge] Hop Count processing In-Reply-To: <4A08494F.7090902@cisco.com> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> Message-ID: <18952.19671.287999.763233@gargle.gargle.HOWL> Dinesh G Dutt writes: > James Carlson wrote: > > if we're the destination then > > decapsulate and forward via L2 > > # note: ignore hop limit > > > This s the difference. How can I do anything like a traceroute if the > frame is delivered when hop count is 0, but you've reached the > destination ? Ah, I think I see the problem you're pointing out now. It's in providing visibility to the last hop, and _assuming_ that the probe message sent isn't one that would trigger any response from the remote system. It'd be possible to define the tracing protocol such that it either doesn't need the old hop-limit trick (by using something more like RFC 1393 to record the actual path of a single message), or defining it to be a ping-like message that must elicit a reply that identifies the target system. If you assume that neither of those is done, and the decapsulating host never sends anything back, then I agree that your change is needed. > BTW, this logic also complicates the processing of > multi-destination frames when some Rbridges have access ports and > inter-Rbridge links. I'm not seeing it, but I'll take your word for it. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From mshand at cisco.com Tue May 12 03:34:39 2009 From: mshand at cisco.com (mike shand) Date: Tue, 12 May 2009 11:34:39 +0100 Subject: [rbridge] Is it a problem to limit to 255, the # of links R1 can be DRB for? In-Reply-To: <1028365c0905101832i6952a1f9re4de2a20d752579b@mail.gmail.com> References: <4A00726F.8070005@sun.com> <18944.31809.331270.486332@gargle.gargle.HOWL> <1028365c0905101832i6952a1f9re4de2a20d752579b@mail.gmail.com> Message-ID: <4A0950BF.2080002@cisco.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090512/63e4c949/attachment.html From Radia.Perlman at sun.com Tue May 12 12:57:54 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 12 May 2009 12:57:54 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <18952.19671.287999.763233@gargle.gargle.HOWL> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> Message-ID: <4A09D4C2.9050201@sun.com> I don't think this should be a big deal either way, and it would be nice to not leave this as an open issue. Dinesh's proposed wording change makes TRILL behave the same as IPv4 and IPv6, which seems reasonable. His proposed replacement text is this: "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if either the Hop Count in the received frame is 0 or the Hop Count is decremented to 0." I'm not sure the "dropped if the Hop Count in the received frame is 0" is necessary, if anyone is concerned about the extra cycle it would take to check the hop count both into and out of the the RBridge, but it's probably a bit safer in case the previous RBridge forgot to drop the packet after it decremented the TTL to 0. So I think we should either just take Dinesh's wording, or if anyone is unhappy about checking TTL twice, remove the "dropped if the Hop Count in the received frame is 0" clause. Or change it to a MAY, as in "As an additional precaution, an RBridge MAY check the hop count in a received frame and drop it if the hop count is 0". I suspect nobody will care, so we can just go with Dinesh's wording. Radia James Carlson wrote: > Dinesh G Dutt writes: > >> James Carlson wrote: >> >>> if we're the destination then >>> decapsulate and forward via L2 >>> # note: ignore hop limit >>> >>> >> This s the difference. How can I do anything like a traceroute if the >> frame is delivered when hop count is 0, but you've reached the >> destination ? >> > > Ah, I think I see the problem you're pointing out now. It's in > providing visibility to the last hop, and _assuming_ that the probe > message sent isn't one that would trigger any response from the remote > system. > > It'd be possible to define the tracing protocol such that it either > doesn't need the old hop-limit trick (by using something more like RFC > 1393 to record the actual path of a single message), or defining it to > be a ping-like message that must elicit a reply that identifies the > target system. > > If you assume that neither of those is done, and the decapsulating > host never sends anything back, then I agree that your change is > needed. > > >> BTW, this logic also complicates the processing of >> multi-destination frames when some Rbridges have access ports and >> inter-Rbridge links. >> > > I'm not seeing it, but I'll take your word for it. > > From james.d.carlson at Sun.COM Tue May 12 13:05:57 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Tue, 12 May 2009 16:05:57 -0400 Subject: [rbridge] Hop Count processing In-Reply-To: <4A09D4C2.9050201@sun.com> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> Message-ID: <18953.54949.937080.18755@gargle.gargle.HOWL> Radia Perlman writes: > I suspect nobody will care, so we can just go with Dinesh's wording. With the detailed rationale for the change, I'm happy enough with his wording and the extra check on entry. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From erik.nordmark at sun.com Wed May 13 13:33:05 2009 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 13 May 2009 13:33:05 -0700 Subject: [rbridge] FYI: CFP relevant to TRILL Message-ID: <4A0B2E81.1020602@sun.com> -------- Original Message -------- Subject: Re: Cfp relevant to TRILL Date: Wed, 13 May 2009 20:30:55 +0300 From: Jukka Manner To: Erik Nordmark , d3e3e3 at gmail.com References: <4A0A7F8D.5030606 at tkk.fi> <4A0AEB7A.3040909 at sun.com> BIPN'09 Call For Papers 1st IEEE Workshop on Below IP Networking (BIPN'09) in conjuction with Globecom 2009, Honolulu, Hawaii. http://www.bipn.org BIPN 2009 is soliciting original and previously unpublished papers addressing research challenges and advances towards metropolitan and wide area networking that work below the IP layer. Particular interest is in enhanced Ethernet technology in context with future access and Internet core networks and systems as well as advances in the label switching technologies. A common denominator is implementing carrier grade transport capabilities below IP. The role of IP in networks is undermined by numerous add-on solutions, many of which reside below IP in the stack. Add-ons provide resiliency, traffic engineering, quality of service, network virtualization, network hiding and edge to edge connectivity etc. Ethernet and MPLS footprints in networks are increasing. An industry trend is that from synchronous transmission, networks are moving to packet based transport based on 802.1 variants or IP/MPLS. Both Ethernet and MPLS are being turned into Carrier Grade transport technologies. The use of native Ethernet based control, signaling and management solutions in large operator and corporate networks will help to reduce costs while scaling networks to higher transport speeds and to carrier grade operator solutions. IP/MPLS transport is agnostic to underlying layers. Now the industry is seeking advice on the particular form of packet based transport technology and on what will be the role of IPv4 when unallocated address pools will soon be exhausted ? will it continue to serve as a routed protocol or will the responsibility for all end to end connectivity be delegated to below IP technology? In order to support different products, services, pricing or business models, etc. solutions must be open standard and flexible enough. New networking principles using enhanced Ethernet are being explored in several international efforts. The industry is developing the MPLS transport profile. The 1st IEEE Workshop on Below IP Networking (BIPN?09) provides a venue for academic and industrial research communities for exchanging ideas and experience on all aspects of below IP Networking. Papers that present work, validated by experimentation, simulations, or analysis, as well as position papers and papers discussing and comparing concepts, architectures and interfaces are solicited, on the topics including, but not limited to * intra and inter carrier path computation and routing below IP * intra and inter carrier protection and restoration below IP * intra and inter carrier OAM * below IP solutions for intra domain and inter carrier traffic engineering * new forwarding technologies * connection oriented and connectionless network services using packet transport * identities and addressing for enhanced Ethernet networks * mobility issues and mobility solutions for packet transport networks * scalability and implementation complexity of below IP networking solutions * quality of service in packet transport networks * network discovery below IP * IP vs End-2-End Ethernet * co-existence and interoperation of routed IP and routed Ethernet * positioning of native enhanced Ethernet against IP, MPLS, GMPLS and MPLS-TP * techno-economics of transport Ethernet, MPLS-TP and Internet by Ethernet Papers should be original material in the IEEE two column format limited to 6 pages. Important dates * Full paper submission: July 23rd 2009 * Notification of acceptance: August 28th 2009 * Final papers due: September 10th 2009 Submission implies the willingness of at least one of the authors to register and present the paper. Accepted papers must be presented at the workshop and will appear in the IEEE Explore. From ddutt at cisco.com Thu May 14 17:01:37 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 14 May 2009 17:01:37 -0700 Subject: [rbridge] Higher number is higher priority Message-ID: <4A0CB0E1.3000607@cisco.com> All, One another minor change. In spanning tree, lower number signifies higher priority whereas in IS-IS, higher number signifies higher priority (Radia tossed a coin with different results ? :). Given that Rbridges use IS-IS, I think we must follow the IS-IS logic and have higher numbers mean higher priority and not follow the .1Q bridges behavior. In the base protocol spec, there are a few places where this needs to be fixed, if there is no objection. One place that jumps at me is the end of section 4.3 in draft12. This also needs to be fixed in the L2 IS-IS document too. Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Thu May 14 18:30:29 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 14 May 2009 18:30:29 -0700 Subject: [rbridge] Higher number is higher priority In-Reply-To: <4A0CB0E1.3000607@cisco.com> References: <4A0CB0E1.3000607@cisco.com> Message-ID: <4A0CC5B5.2080608@sun.com> Yes, I agree. We should switch TRILL to be numerically higher priority=higher priority. And for historical interest -- I didn't flip coins. :-) IS-IS was designed before spanning tree, and the choice of numerically higher=higher priority was chosen because that's what any sane person would do. But for spanning tree, it worked out really nicely to consider the fields ("root bridge priority", "root bridge ID", "cost to root", "transmitting bridge priority", "transmitting bridge ID", "port ID") as a multiprecision number where for comparing whether one BPDU is "better" than another. Since "cost" obviously has to be "better" if it's smaller, it constrained all the other values to be "smaller is better". I wonder if it drives people managing bridges crazy to have to set the priority to be smaller to make it higher priority? Sorry about that...but it did make the description of "better Hello" really elegant. Radia Dinesh G Dutt wrote: > All, > > One another minor change. In spanning tree, lower number signifies > higher priority whereas in IS-IS, higher number signifies higher > priority (Radia tossed a coin with different results ? :). Given that > Rbridges use IS-IS, I think we must follow the IS-IS logic and have > higher numbers mean higher priority and not follow the .1Q bridges behavior. > > In the base protocol spec, there are a few places where this needs to be > fixed, if there is no objection. One place that jumps at me is the end > of section 4.3 in draft12. This also needs to be fixed in the L2 IS-IS > document too. > > Dinesh > > From Radia.Perlman at sun.com Thu May 14 22:28:04 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 14 May 2009 22:28:04 -0700 Subject: [rbridge] Question about reserved nicknames Message-ID: <4A0CFD64.9070502@sun.com> I notice there were some nicknames set aside as "reserved". What are RBridges supposed to do about reserved nicknames? Merely not request them, or check data packets, and drop packets with the TRILL header having either ingress or egress nickname field set as one of the reserved values? If the latter, what do people envision using reserved nicknames for in the future? Would such a use be compatible with existing RBridges discarding frames that use reserved nicknames? Radia From d3e3e3 at gmail.com Fri May 15 07:02:59 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 15 May 2009 10:02:59 -0400 Subject: [rbridge] Question about reserved nicknames In-Reply-To: <4A0CFD64.9070502@sun.com> References: <4A0CFD64.9070502@sun.com> Message-ID: <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> Hi Radia, The behavior you describe is what was intended for the reserved nicknames with the one minor exception that there is currently no requirement to examine the ingress nickname on receipt of a known unicast TRILL data frame. So an RBridge might not discard such a frame if the ingress nickname was a reserved value. Perhaps that should be a requirement. This was discussed on the list. Its really not much different from the extra reserved multicast bridging MAC addresses, which are dropped by any bridge which doesn't understand them, or the extra reserved multicast TRILL MAC addresses, which are dropped by and RBridge which doesn't understand them. Maybe the reserved nicknames will be helpful in handling control messages on links that don't have outside MAC addresses or somehow helpful in implementing "provider RBridges" if/when we want to do something like that. In any case, it is quite cheap to reserve them and, if we ever want the behavior of dropping such TRILL frames, that requirement has to be imposed from the beginning. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Fri, May 15, 2009 at 1:28 AM, Radia Perlman wrote: > I notice there were some nicknames set aside as "reserved". What are > RBridges > supposed to do about reserved nicknames? Merely not request them, or check > data packets, and drop > packets with the TRILL header having either ingress or egress nickname > field set as one of the reserved values? > > If the latter, what do people envision using reserved nicknames for in > the future? > Would such a use be compatible with existing RBridges discarding frames > that use reserved nicknames? > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From james.d.carlson at Sun.COM Fri May 15 07:38:16 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 15 May 2009 10:38:16 -0400 Subject: [rbridge] Question about reserved nicknames In-Reply-To: <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> References: <4A0CFD64.9070502@sun.com> <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> Message-ID: <18957.32344.765352.420046@gargle.gargle.HOWL> Donald Eastlake writes: > The behavior you describe is what was intended for the reserved > nicknames with the one minor exception that there is currently no > requirement to examine the ingress nickname on receipt of a known > unicast TRILL data frame. So an RBridge might not discard such a frame > if the ingress nickname was a reserved value. Perhaps that should be a > requirement. The behavior I'd suggest would be to ignore the ingress nickname on forwarding, and drop invalid ones only at egress. The rationale is that it'll be harder to deploy a future nickname- based protocol that requires forwarding if forwarding is disabled now. If forwarding is not desired in some future protocol, then the hop limit can always be used to prevent it. For the egress, of course, life is different: you must learn the ingress for the source based on the ingress nickname, and that means it can't be an "illegal" one. Some future protocol can (again) amend that behavior as needed. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From touch at ISI.EDU Fri May 15 09:10:52 2009 From: touch at ISI.EDU (Joe Touch) Date: Fri, 15 May 2009 09:10:52 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <18953.54949.937080.18755@gargle.gargle.HOWL> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> Message-ID: <4A0D940C.3070400@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Carlson wrote: > Radia Perlman writes: >> I suspect nobody will care, so we can just go with Dinesh's wording. If the goal is to make this work like IP, the wording needs correction. The original proposed wording is: - --- The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if either the Hop Count in the received frame is 0 or the Hop Count is decremented to 0. - --- In IP, the following is true: " A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it." I.e., the packet is dropped if the TTL is zero or one on receipt only if it is forwarded; if it is being 'accepted' (i.e., in this case, if the destination is the trill node doing the processing), then a TTL of zero is acceptable. It seems like the wording needs to include this second case... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNlAwACgkQE5f5cImnZrtOFgCg26uBmac6/MOCZUi6kujD95US SS0AoOMXl2d621TdpwgRIT5E2UHAhzur =kKG6 -----END PGP SIGNATURE----- From Radia.Perlman at sun.com Fri May 15 12:02:16 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 15 May 2009 12:02:16 -0700 Subject: [rbridge] Question about reserved nicknames In-Reply-To: <18957.32344.765352.420046@gargle.gargle.HOWL> References: <4A0CFD64.9070502@sun.com> <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> <18957.32344.765352.420046@gargle.gargle.HOWL> Message-ID: <4A0DBC38.4000302@sun.com> Ah. I'd been doing some last minute rereading of the spec and couldn't find what it said to do with reserved nicknames, but yes...the spec does explicitly says to drop if the egress nickname is unknown or reserved. So I'm glad that that is the behavior everyone wants. Radia James Carlson wrote: > Donald Eastlake writes: > >> The behavior you describe is what was intended for the reserved >> nicknames with the one minor exception that there is currently no >> requirement to examine the ingress nickname on receipt of a known >> unicast TRILL data frame. So an RBridge might not discard such a frame >> if the ingress nickname was a reserved value. Perhaps that should be a >> requirement. >> > > The behavior I'd suggest would be to ignore the ingress nickname on > forwarding, and drop invalid ones only at egress. > > The rationale is that it'll be harder to deploy a future nickname- > based protocol that requires forwarding if forwarding is disabled now. > If forwarding is not desired in some future protocol, then the hop > limit can always be used to prevent it. > > For the egress, of course, life is different: you must learn the > ingress for the source based on the ingress nickname, and that means > it can't be an "illegal" one. Some future protocol can (again) amend > that behavior as needed. > > From james.d.carlson at Sun.COM Fri May 15 14:03:10 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 15 May 2009 17:03:10 -0400 Subject: [rbridge] Question about reserved nicknames In-Reply-To: <4A0DBC38.4000302@sun.com> References: <4A0CFD64.9070502@sun.com> <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> <18957.32344.765352.420046@gargle.gargle.HOWL> <4A0DBC38.4000302@sun.com> Message-ID: <18957.55438.199580.780609@gargle.gargle.HOWL> Radia Perlman writes: > Ah. I'd been doing some last minute rereading of the spec and couldn't > find what it said to > do with reserved nicknames, but yes...the spec does explicitly says to > drop if the egress nickname is unknown > or reserved. So I'm glad that that is the behavior everyone wants. Right; but I don't think it says what to do with ingress nicknames. I think the right answer is: - MUST NOT send with a reserved nickname as ingress - MUST ignore ingress nickname when forwarding - MUST discard packets with reserved ingress nickname at egress node -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From d3e3e3 at gmail.com Fri May 15 16:56:41 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 15 May 2009 19:56:41 -0400 Subject: [rbridge] Question about reserved nicknames In-Reply-To: <18957.55438.199580.780609@gargle.gargle.HOWL> References: <4A0CFD64.9070502@sun.com> <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> <18957.32344.765352.420046@gargle.gargle.HOWL> <4A0DBC38.4000302@sun.com> <18957.55438.199580.780609@gargle.gargle.HOWL> Message-ID: <1028365c0905151656i632b9967i2f22cf4da2894fa1@mail.gmail.com> On Fri, May 15, 2009 at 5:03 PM, James Carlson wrote: > Radia Perlman writes: >> Ah. I'd been doing some last minute rereading of the spec and couldn't >> find what it said to >> do with reserved nicknames, but yes...the spec does explicitly says to >> drop if the egress nickname is unknown >> or reserved. So I'm glad that that is the behavior everyone wants. > > Right; but I don't think it says what to do with ingress nicknames. ?I > think the right answer is: > > ?- MUST NOT send with a reserved nickname as ingress > ?- MUST ignore ingress nickname when forwarding > ?- MUST discard packets with reserved ingress nickname at egress node That's fine for known unicast. But for multi-destination frames, if the ingress is a reserved value, you can't do the RFP check, so it would seem better to drop those. > James Carlson, Solaris Networking ? ? ? ? ? ? ? > Sun Microsystems / 35 Network Drive ? ? ? ?71.232W ? Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 ? 42.496N ? Fax +1 781 442 1677 Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From james.d.carlson at Sun.COM Mon May 18 06:01:57 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Mon, 18 May 2009 09:01:57 -0400 Subject: [rbridge] Question about reserved nicknames In-Reply-To: <1028365c0905151656i632b9967i2f22cf4da2894fa1@mail.gmail.com> References: <4A0CFD64.9070502@sun.com> <1028365c0905150702u41d1e6e6yc14723786d83ad61@mail.gmail.com> <18957.32344.765352.420046@gargle.gargle.HOWL> <4A0DBC38.4000302@sun.com> <18957.55438.199580.780609@gargle.gargle.HOWL> <1028365c0905151656i632b9967i2f22cf4da2894fa1@mail.gmail.com> Message-ID: <18961.23621.558004.754861@gargle.gargle.HOWL> Donald Eastlake writes: > On Fri, May 15, 2009 at 5:03 PM, James Carlson wrote: > > ?- MUST NOT send with a reserved nickname as ingress > > ?- MUST ignore ingress nickname when forwarding > > ?- MUST discard packets with reserved ingress nickname at egress node > > That's fine for known unicast. But for multi-destination frames, if > the ingress is a reserved value, you can't do the RFP check, so it > would seem better to drop those. Agreed. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From d3e3e3 at gmail.com Tue May 19 14:54:39 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 19 May 2009 17:54:39 -0400 Subject: [rbridge] Fwd: IETF Last Call: draft-ietf-opsawg-operations-and-management In-Reply-To: <604C72C023784318A97135CFF626C863@your029b8cecfe> References: <604C72C023784318A97135CFF626C863@your029b8cecfe> Message-ID: <1028365c0905191454u77dbeee1x9febd5902ed81381@mail.gmail.com> Since there has been some discussion of adding OAM features to or built on TRILL, people may be interested in the IETF last call below on a draft from the Operations and Management Area Working Group. Thanks, Donald ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: Sent: Tuesday, May 19, 2009 2:39 PM Subject: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: > > - 'Guidelines for Considering Operations and Management of New Protocols > ?and Protocol Extensions ' > ? as a BCP > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. ?Please send substantive comments to the > ietf at ietf.org mailing lists by 2009-06-02. Exceptionally, > comments may be sent to iesg at ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16452&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From rfc-editor at rfc-editor.org Tue May 19 14:55:27 2009 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Tue, 19 May 2009 14:55:27 -0700 (PDT) Subject: [rbridge] RFC 5556 on Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement Message-ID: <20090519215527.C65522B1C03@bosco.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 5556 Title: Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement Author: J. Touch, R. Perlman Status: Informational Date: May 2009 Mailbox: touch at isi.edu, Radia.Perlman at sun.com Pages: 17 Characters: 41657 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-trill-prob-06.txt URL: http://www.rfc-editor.org/rfc/rfc5556.txt Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. This memo provides information for the Internet community. This document is a product of the Transparent Interconnection of Lots of Links Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From d3e3e3 at gmail.com Tue May 19 17:07:25 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 19 May 2009 20:07:25 -0400 Subject: [rbridge] Hop Count processing In-Reply-To: <4A0D940C.3070400@isi.edu> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> <4A0D940C.3070400@isi.edu> Message-ID: <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> I'm fine with changing hop count processing to make it the same as IPv4 and IPv6 even it reduce the distance a TRILL encapsulated frame can go by 1 hop. Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Fri, May 15, 2009 at 12:10 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > James Carlson wrote: > > Radia Perlman writes: > >> I suspect nobody will care, so we can just go with Dinesh's wording. > > If the goal is to make this work like IP, the wording needs correction. > > The original proposed wording is: > > - --- > > The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if either the Hop Count in the received frame is 0 or the Hop > Count is decremented to 0. > > - --- > > In IP, the following is true: > > " A router MUST NOT discard a datagram just because it was received > with TTL equal to zero or one; if it is to the router and otherwise > valid, the router MUST attempt to receive it." > > I.e., the packet is dropped if the TTL is zero or one on receipt only if > it is forwarded; if it is being 'accepted' (i.e., in this case, if the > destination is the trill node doing the processing), then a TTL of zero > is acceptable. > > It seems like the wording needs to include this second case... > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoNlAwACgkQE5f5cImnZrtOFgCg26uBmac6/MOCZUi6kujD95US > SS0AoOMXl2d621TdpwgRIT5E2UHAhzur > =kKG6 > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090519/e527f40e/attachment.html From touch at ISI.EDU Wed May 20 07:41:57 2009 From: touch at ISI.EDU (Joe Touch) Date: Wed, 20 May 2009 07:41:57 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> <4A0D940C.3070400@isi.edu> <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> Message-ID: <4A1416B5.2040505@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Donald Eastlake wrote: > I'm fine with changing hop count processing to make it the same as IPv4 > and IPv6 even it reduce the distance a TRILL encapsulated frame can go > by 1 hop. My point is that you're not making it the same as IPv4 and IPv6. We need to recognize that TRILL ingress and egress devices are NOT forwarders -- they are "hosts"; they do NOT decrement the hopcount, and thus they do NOT drop packets once received regardless of hopcount. I.e., either we're going for IP behavior or not... Joe > On Fri, May 15, 2009 at 12:10 PM, Joe Touch > wrote: > > > > James Carlson wrote: >> Radia Perlman writes: >>> I suspect nobody will care, so we can just go with Dinesh's wording. > > If the goal is to make this work like IP, the wording needs correction. > > The original proposed wording is: > > --- > > The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if either the Hop Count in the received frame is 0 or the Hop > Count is decremented to 0. > > --- > > In IP, the following is true: > > " A router MUST NOT discard a datagram just because it was received > with TTL equal to zero or one; if it is to the router and otherwise > valid, the router MUST attempt to receive it." > > I.e., the packet is dropped if the TTL is zero or one on receipt only if > it is forwarded; if it is being 'accepted' (i.e., in this case, if the > destination is the trill node doing the processing), then a TTL of zero > is acceptable. > > It seems like the wording needs to include this second case... > > Joe _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge > ------------------------------------------------------------------------ > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUFrUACgkQE5f5cImnZrtobwCgvi9/4tP/EGSGjqXPOBmy2zY3 VrQAoLQs8H0QUmnsTvKJNWxt1QUqAWDU =SlcP -----END PGP SIGNATURE----- From d3e3e3 at gmail.com Wed May 20 07:47:33 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 20 May 2009 10:47:33 -0400 Subject: [rbridge] Hop Count processing In-Reply-To: <4A1416B5.2040505@isi.edu> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> <4A0D940C.3070400@isi.edu> <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> <4A1416B5.2040505@isi.edu> Message-ID: <1028365c0905200747m5936cf79q9d44a23f0abb7b01@mail.gmail.com> I agree. I was just stating my opinion and a relatively high level, rather than saying anything about the detailed wording. Donald On Wed, May 20, 2009 at 10:41 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Donald Eastlake wrote: >> I'm fine with changing hop count processing to make it the same as IPv4 >> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >> by 1 hop. > > My point is that you're not making it the same as IPv4 and IPv6. We need > to recognize that TRILL ingress and egress devices are NOT forwarders -- > they are "hosts"; they do NOT decrement the hopcount, and thus they do > NOT drop packets once received regardless of hopcount. > > I.e., either we're going for IP behavior or not... > > Joe > > >> On Fri, May 15, 2009 at 12:10 PM, Joe Touch > > wrote: >> >> >> >> James Carlson wrote: >>> Radia Perlman writes: >>>> I suspect nobody will care, so we can just go with Dinesh's wording. >> >> If the goal is to make this work like IP, the wording needs correction. >> >> The original proposed wording is: >> >> --- >> >> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >> dropped if either the Hop Count in the received frame is 0 or the Hop >> Count is decremented to 0. >> >> --- >> >> In IP, the following is true: >> >> " A router MUST NOT discard a datagram just because it was received >> ? with TTL equal to zero or one; if it is to the router and otherwise >> ? valid, the router MUST attempt to receive it." >> >> I.e., the packet is dropped if the TTL is zero or one on receipt only if >> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >> destination is the trill node doing the processing), then a TTL of zero >> is acceptable. >> >> It seems like the wording needs to include this second case... >> >> Joe > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoUFrUACgkQE5f5cImnZrtobwCgvi9/4tP/EGSGjqXPOBmy2zY3 > VrQAoLQs8H0QUmnsTvKJNWxt1QUqAWDU > =SlcP > -----END PGP SIGNATURE----- > From touch at ISI.EDU Wed May 20 07:52:25 2009 From: touch at ISI.EDU (Joe Touch) Date: Wed, 20 May 2009 07:52:25 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <1028365c0905200747m5936cf79q9d44a23f0abb7b01@mail.gmail.com> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> <4A0D940C.3070400@isi.edu> <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> <4A1416B5.2040505@isi.edu> <1028365c0905200747m5936cf79q9d44a23f0abb7b01@mail.gmail.com> Message-ID: <4A141929.8040006@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK. My point is that the idea that this reduces the hops traversed by 1 is the result of assuming that ingress/egress also decrement, which they should not. If they don't, then there is no reduction... Joe Donald Eastlake wrote: > I agree. I was just stating my opinion and a relatively high level, > rather than saying anything about the detailed wording. > > Donald > > On Wed, May 20, 2009 at 10:41 AM, Joe Touch wrote: > > > Donald Eastlake wrote: >>>> I'm fine with changing hop count processing to make it the same as IPv4 >>>> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >>>> by 1 hop. > My point is that you're not making it the same as IPv4 and IPv6. We need > to recognize that TRILL ingress and egress devices are NOT forwarders -- > they are "hosts"; they do NOT decrement the hopcount, and thus they do > NOT drop packets once received regardless of hopcount. > > I.e., either we're going for IP behavior or not... > > Joe > > >>>> On Fri, May 15, 2009 at 12:10 PM, Joe Touch >>> > wrote: >>>> >>>> >>>> >>>> James Carlson wrote: >>>>> Radia Perlman writes: >>>>>> I suspect nobody will care, so we can just go with Dinesh's wording. >>>> If the goal is to make this work like IP, the wording needs correction. >>>> >>>> The original proposed wording is: >>>> >>>> --- >>>> >>>> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >>>> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >>>> dropped if either the Hop Count in the received frame is 0 or the Hop >>>> Count is decremented to 0. >>>> >>>> --- >>>> >>>> In IP, the following is true: >>>> >>>> " A router MUST NOT discard a datagram just because it was received >>>> with TTL equal to zero or one; if it is to the router and otherwise >>>> valid, the router MUST attempt to receive it." >>>> >>>> I.e., the packet is dropped if the TTL is zero or one on receipt only if >>>> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >>>> destination is the trill node doing the processing), then a TTL of zero >>>> is acceptable. >>>> >>>> It seems like the wording needs to include this second case... >>>> >>>> Joe > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > >>>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUGSkACgkQE5f5cImnZrvjfgCgy7QohXABkIdkpAaN17I6EA1L LVEAoPruvXDetDCTH6ful8K+QWPBR+pI =ea3O -----END PGP SIGNATURE----- From ddutt at cisco.com Wed May 20 09:42:28 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 20 May 2009 09:42:28 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A1416B5.2040505@isi.edu> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> <4A0D940C.3070400@isi.edu> <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> <4A1416B5.2040505@isi.edu> Message-ID: <4A1432F4.80608@cisco.com> Joe, I don't understand what you're saying. Rbridges are like routers, more like MPLS than like IP in that the header is added/removed by the ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the same behavior that has been suggested which is no different from IPv6's wording. Dinesh Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Donald Eastlake wrote: > >> I'm fine with changing hop count processing to make it the same as IPv4 >> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >> by 1 hop. >> > > My point is that you're not making it the same as IPv4 and IPv6. We need > to recognize that TRILL ingress and egress devices are NOT forwarders -- > they are "hosts"; they do NOT decrement the hopcount, and thus they do > NOT drop packets once received regardless of hopcount. > > I.e., either we're going for IP behavior or not... > > Joe > > > >> On Fri, May 15, 2009 at 12:10 PM, Joe Touch > > wrote: >> >> >> >> James Carlson wrote: >> >>> Radia Perlman writes: >>> >>>> I suspect nobody will care, so we can just go with Dinesh's wording. >>>> >> If the goal is to make this work like IP, the wording needs correction. >> >> The original proposed wording is: >> >> --- >> >> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >> dropped if either the Hop Count in the received frame is 0 or the Hop >> Count is decremented to 0. >> >> --- >> >> In IP, the following is true: >> >> " A router MUST NOT discard a datagram just because it was received >> with TTL equal to zero or one; if it is to the router and otherwise >> valid, the router MUST attempt to receive it." >> >> I.e., the packet is dropped if the TTL is zero or one on receipt only if >> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >> destination is the trill node doing the processing), then a TTL of zero >> is acceptable. >> >> It seems like the wording needs to include this second case... >> >> Joe >> > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > >> ------------------------------------------------------------------------ >> > > >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoUFrUACgkQE5f5cImnZrtobwCgvi9/4tP/EGSGjqXPOBmy2zY3 > VrQAoLQs8H0QUmnsTvKJNWxt1QUqAWDU > =SlcP > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Wed May 20 09:51:52 2009 From: touch at ISI.EDU (Joe Touch) Date: Wed, 20 May 2009 09:51:52 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A1432F4.80608@cisco.com> References: <4A04B26E.5090702@cisco.com> <18952.3904.411488.291442@gargle.gargle.HOWL> <4A08494F.7090902@cisco.com> <18952.19671.287999.763233@gargle.gargle.HOWL> <4A09D4C2.9050201@sun.com> <18953.54949.937080.18755@gargle.gargle.HOWL> <4A0D940C.3070400@isi.edu> <1028365c0905191707x2b5ca33cn71fb8723497847e9@mail.gmail.com> <4A1416B5.2040505@isi.edu> <4A1432F4.80608@cisco.com> Message-ID: <4A143528.7020604@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dinesh G Dutt wrote: > Joe, > > I don't understand what you're saying. Rbridges are like routers, more > like MPLS than like IP in that the header is added/removed by the > ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the > same behavior that has been suggested which is no different from IPv6's > wording. Rbridge transits are like routers. Rbridge ingress/egresses are like hosts - just as are any tunnel endpoints, or anything that adds/removes headers (not just "swaps" them). IPv6 says (in RFC2460), about its hop limit: Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. Neither the ingress nor the egress *forward* the trill packet. Joe > Donald Eastlake wrote: > >>>> I'm fine with changing hop count processing to make it the same as IPv4 >>>> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >>>> by 1 hop. >>>> > > My point is that you're not making it the same as IPv4 and IPv6. We need > to recognize that TRILL ingress and egress devices are NOT forwarders -- > they are "hosts"; they do NOT decrement the hopcount, and thus they do > NOT drop packets once received regardless of hopcount. > > I.e., either we're going for IP behavior or not... > > Joe > > > >>>> On Fri, May 15, 2009 at 12:10 PM, Joe Touch >>> > wrote: >>>> >>>> >>>> >>>> James Carlson wrote: >>>> >>>>> Radia Perlman writes: >>>>> >>>>>> I suspect nobody will care, so we can just go with Dinesh's wording. >>>>>> >>>> If the goal is to make this work like IP, the wording needs correction. >>>> >>>> The original proposed wording is: >>>> >>>> --- >>>> >>>> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >>>> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >>>> dropped if either the Hop Count in the received frame is 0 or the Hop >>>> Count is decremented to 0. >>>> >>>> --- >>>> >>>> In IP, the following is true: >>>> >>>> " A router MUST NOT discard a datagram just because it was received >>>> with TTL equal to zero or one; if it is to the router and otherwise >>>> valid, the router MUST attempt to receive it." >>>> >>>> I.e., the packet is dropped if the TTL is zero or one on receipt only if >>>> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >>>> destination is the trill node doing the processing), then a TTL of zero >>>> is acceptable. >>>> >>>> It seems like the wording needs to include this second case... >>>> >>>> Joe >>>> > _______________________________________________ > 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 >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUNSgACgkQE5f5cImnZrtF4ACfXn5HNKLYf333Po+BqpgYEts9 Gf8AoM4Cl4390MtoDD7tcDp9+8eu6SQH =HXvb -----END PGP SIGNATURE----- From sgai at cisco.com Wed May 20 11:22:36 2009 From: sgai at cisco.com (sgai) Date: Wed, 20 May 2009 11:22:36 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A143528.7020604@isi.edu> Message-ID: Joe, The wordind says: " [Hop Count] is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame". If the frame goes out of an Egress Rbridge it is not TRILL encapsulated. So where is the issue? -- Silvano On 5/20/09 9:51 AM, "Joe Touch" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dinesh G Dutt wrote: >> Joe, >> >> I don't understand what you're saying. Rbridges are like routers, more >> like MPLS than like IP in that the header is added/removed by the >> ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the >> same behavior that has been suggested which is no different from IPv6's >> wording. > > Rbridge transits are like routers. > > Rbridge ingress/egresses are like hosts - just as are any tunnel > endpoints, or anything that adds/removes headers (not just "swaps" them). > > IPv6 says (in RFC2460), about its hop limit: > > Decremented by 1 by > each node that forwards the packet. The packet > is discarded if Hop Limit is decremented to > zero. > > Neither the ingress nor the egress *forward* the trill packet. > > Joe > > > >> Donald Eastlake wrote: >> >>>>> I'm fine with changing hop count processing to make it the same as IPv4 >>>>> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >>>>> by 1 hop. >>>>> >> >> My point is that you're not making it the same as IPv4 and IPv6. We need >> to recognize that TRILL ingress and egress devices are NOT forwarders -- >> they are "hosts"; they do NOT decrement the hopcount, and thus they do >> NOT drop packets once received regardless of hopcount. >> >> I.e., either we're going for IP behavior or not... >> >> Joe >> >> >> >>>>> On Fri, May 15, 2009 at 12:10 PM, Joe Touch >>>> > wrote: >>>>> >>>>> >>>>> >>>>> James Carlson wrote: >>>>> >>>>>> Radia Perlman writes: >>>>>> >>>>>>> I suspect nobody will care, so we can just go with Dinesh's wording. >>>>>>> >>>>> If the goal is to make this work like IP, the wording needs correction. >>>>> >>>>> The original proposed wording is: >>>>> >>>>> --- >>>>> >>>>> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >>>>> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >>>>> dropped if either the Hop Count in the received frame is 0 or the Hop >>>>> Count is decremented to 0. >>>>> >>>>> --- >>>>> >>>>> In IP, the following is true: >>>>> >>>>> " A router MUST NOT discard a datagram just because it was received >>>>> with TTL equal to zero or one; if it is to the router and otherwise >>>>> valid, the router MUST attempt to receive it." >>>>> >>>>> I.e., the packet is dropped if the TTL is zero or one on receipt only if >>>>> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >>>>> destination is the trill node doing the processing), then a TTL of zero >>>>> is acceptable. >>>>> >>>>> It seems like the wording needs to include this second case... >>>>> >>>>> Joe >>>>> >> _______________________________________________ >> 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 >>> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoUNSgACgkQE5f5cImnZrtF4ACfXn5HNKLYf333Po+BqpgYEts9 > Gf8AoM4Cl4390MtoDD7tcDp9+8eu6SQH > =HXvb > -----END PGP SIGNATURE----- > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Wed May 20 20:07:22 2009 From: touch at ISI.EDU (Joe Touch) Date: Wed, 20 May 2009 20:07:22 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: References: Message-ID: <4A14C56A.1000408@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The current wording (in 05) is: " A 6-bit unsigned integer. Each RBridge that is about to forward a frame to another RBridge MUST check this field and discard the frame if this field is zero. If this field is non-zero, it MUST be decremented in the forwarded frame." That is sufficient and correct. If the frame comes in as zero and needs to be forwarded, it is dropped. If the frame comes in as 1, it can be decremented and forwarded. If the destination is the next rbridge, then the frame is NOT discarded. There is no need to consider a "0 or 1" case, as was proposed. The "0 or 1" case would prevent a frame from reaching its destination if the hopcount exactly matched the path length, and there's no reason to do this. The suggested replacement is incorrect: "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if either the Hop Count in the received frame is 0 or the Hop Count is decremented to 0." This text incorrectly discards incoming frames that are 0 that are not forwarded. I.e., the _original_ text was correct as it stood in v05. Joe sgai wrote: > Joe, > > The wordind says: " [Hop Count] is decremented by 1 by each Rbridge that > forwards a TRILL encapsulated frame". > If the frame goes out of an Egress Rbridge it is not TRILL encapsulated. > > So where is the issue? > > -- Silvano > > > On 5/20/09 9:51 AM, "Joe Touch" wrote: > > > > Dinesh G Dutt wrote: >>>> Joe, >>>> >>>> I don't understand what you're saying. Rbridges are like routers, more >>>> like MPLS than like IP in that the header is added/removed by the >>>> ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the >>>> same behavior that has been suggested which is no different from IPv6's >>>> wording. > Rbridge transits are like routers. > > Rbridge ingress/egresses are like hosts - just as are any tunnel > endpoints, or anything that adds/removes headers (not just "swaps" them). > > IPv6 says (in RFC2460), about its hop limit: > > Decremented by 1 by > each node that forwards the packet. The packet > is discarded if Hop Limit is decremented to > zero. > > Neither the ingress nor the egress *forward* the trill packet. > > Joe > > > >>>> Donald Eastlake wrote: >>>> >>>>>>> I'm fine with changing hop count processing to make it the same as IPv4 >>>>>>> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >>>>>>> by 1 hop. >>>>>>> >>>> My point is that you're not making it the same as IPv4 and IPv6. We need >>>> to recognize that TRILL ingress and egress devices are NOT forwarders -- >>>> they are "hosts"; they do NOT decrement the hopcount, and thus they do >>>> NOT drop packets once received regardless of hopcount. >>>> >>>> I.e., either we're going for IP behavior or not... >>>> >>>> Joe >>>> >>>> >>>> >>>>>>> On Fri, May 15, 2009 at 12:10 PM, Joe Touch >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> James Carlson wrote: >>>>>>> >>>>>>>> Radia Perlman writes: >>>>>>>> >>>>>>>>> I suspect nobody will care, so we can just go with Dinesh's wording. >>>>>>>>> >>>>>>> If the goal is to make this work like IP, the wording needs correction. >>>>>>> >>>>>>> The original proposed wording is: >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >>>>>>> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >>>>>>> dropped if either the Hop Count in the received frame is 0 or the Hop >>>>>>> Count is decremented to 0. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> In IP, the following is true: >>>>>>> >>>>>>> " A router MUST NOT discard a datagram just because it was received >>>>>>> with TTL equal to zero or one; if it is to the router and otherwise >>>>>>> valid, the router MUST attempt to receive it." >>>>>>> >>>>>>> I.e., the packet is dropped if the TTL is zero or one on receipt only if >>>>>>> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >>>>>>> destination is the trill node doing the processing), then a TTL of zero >>>>>>> is acceptable. >>>>>>> >>>>>>> It seems like the wording needs to include this second case... >>>>>>> >>>>>>> Joe >>>>>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUxWkACgkQE5f5cImnZruwQQCgnnQr9IP5bJlnPnKEyvVUCfcd jSEAni9tIDTL3VGISfSkiow7a+oW8vs7 =VewP -----END PGP SIGNATURE----- From ddutt at cisco.com Wed May 20 21:53:53 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 20 May 2009 21:53:53 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A14C56A.1000408@isi.edu> References: <4A14C56A.1000408@isi.edu> Message-ID: <4A14DE61.4090502@cisco.com> Joe, I had requested the suggested text replacement to be: "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if the Hop Count is decremented to 0." This is similar to MPLS and IPv6. Dinesh Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The current wording (in 05) is: > > " A 6-bit unsigned integer. Each RBridge that is about to forward a > frame to another RBridge MUST check this field and discard the frame > if this field is zero. If this field is non-zero, it MUST be > decremented in the forwarded frame." > > That is sufficient and correct. > > If the frame comes in as zero and needs to be forwarded, it is dropped. > > If the frame comes in as 1, it can be decremented and forwarded. If the > destination is the next rbridge, then the frame is NOT discarded. > > There is no need to consider a "0 or 1" case, as was proposed. The "0 or > 1" case would prevent a frame from reaching its destination if the > hopcount exactly matched the path length, and there's no reason to do this. > > The suggested replacement is incorrect: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if either the Hop Count in the received frame is 0 or the Hop > Count is decremented to 0." > > This text incorrectly discards incoming frames that are 0 that are not > forwarded. I.e., the _original_ text was correct as it stood in v05. > > Joe > > > > > sgai wrote: > >> Joe, >> >> The wordind says: " [Hop Count] is decremented by 1 by each Rbridge that >> forwards a TRILL encapsulated frame". >> If the frame goes out of an Egress Rbridge it is not TRILL encapsulated. >> >> So where is the issue? >> >> -- Silvano >> >> >> On 5/20/09 9:51 AM, "Joe Touch" wrote: >> >> >> >> Dinesh G Dutt wrote: >> >>>>> Joe, >>>>> >>>>> I don't understand what you're saying. Rbridges are like routers, more >>>>> like MPLS than like IP in that the header is added/removed by the >>>>> ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the >>>>> same behavior that has been suggested which is no different from IPv6's >>>>> wording. >>>>> >> Rbridge transits are like routers. >> >> Rbridge ingress/egresses are like hosts - just as are any tunnel >> endpoints, or anything that adds/removes headers (not just "swaps" them). >> >> IPv6 says (in RFC2460), about its hop limit: >> >> Decremented by 1 by >> each node that forwards the packet. The packet >> is discarded if Hop Limit is decremented to >> zero. >> >> Neither the ingress nor the egress *forward* the trill packet. >> >> Joe >> >> >> >> >>>>> Donald Eastlake wrote: >>>>> >>>>> >>>>>>>> I'm fine with changing hop count processing to make it the same as IPv4 >>>>>>>> and IPv6 even it reduce the distance a TRILL encapsulated frame can go >>>>>>>> by 1 hop. >>>>>>>> >>>>>>>> >>>>> My point is that you're not making it the same as IPv4 and IPv6. We need >>>>> to recognize that TRILL ingress and egress devices are NOT forwarders -- >>>>> they are "hosts"; they do NOT decrement the hopcount, and thus they do >>>>> NOT drop packets once received regardless of hopcount. >>>>> >>>>> I.e., either we're going for IP behavior or not... >>>>> >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>>>>> On Fri, May 15, 2009 at 12:10 PM, Joe Touch >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> James Carlson wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Radia Perlman writes: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I suspect nobody will care, so we can just go with Dinesh's wording. >>>>>>>>>> >>>>>>>>>> >>>>>>>> If the goal is to make this work like IP, the wording needs correction. >>>>>>>> >>>>>>>> The original proposed wording is: >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 >>>>>>>> by each Rbridge that forwards a TRILL encapsulated frame. The frame is >>>>>>>> dropped if either the Hop Count in the received frame is 0 or the Hop >>>>>>>> Count is decremented to 0. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> In IP, the following is true: >>>>>>>> >>>>>>>> " A router MUST NOT discard a datagram just because it was received >>>>>>>> with TTL equal to zero or one; if it is to the router and otherwise >>>>>>>> valid, the router MUST attempt to receive it." >>>>>>>> >>>>>>>> I.e., the packet is dropped if the TTL is zero or one on receipt only if >>>>>>>> it is forwarded; if it is being 'accepted' (i.e., in this case, if the >>>>>>>> destination is the trill node doing the processing), then a TTL of zero >>>>>>>> is acceptable. >>>>>>>> >>>>>>>> It seems like the wording needs to include this second case... >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>> 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 >> > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoUxWkACgkQE5f5cImnZruwQQCgnnQr9IP5bJlnPnKEyvVUCfcd > jSEAni9tIDTL3VGISfSkiow7a+oW8vs7 > =VewP > -----END PGP SIGNATURE----- > > -- 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 Thu May 21 07:02:10 2009 From: touch at ISI.EDU (Joe Touch) Date: Thu, 21 May 2009 07:02:10 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A14DE61.4090502@cisco.com> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> Message-ID: <4A155EE2.2040306@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dinesh G Dutt wrote: > Joe, > > I had requested the suggested text replacement to be: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if the Hop Count is decremented to 0." I copied your suggested text from your original post from 5/8. Working with the above text, then the check needs to be: "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if the Hop Count is zero before or after it is decremented." All you have succeeded in achieving is a more complex test at the forwarder, and adding an ambiguity regarding packets with a hopcount of 0 and 1. E.g., a packet with a hopcount of 0 or 1 would go from an ingress to an egress just fine, and would arrive with the original hopcount. A packet needs a hopcount of N+1 to traverse N intermediate forwarding rbridges, i.e., hopcounts of [2..255] work. Packets that traverse intermediate forwarders will always arrive with a hopcount of 1 or higher. So packets can still arrive at egresses with hopcounts of [0..255]. The egress knows something special about packets with hopcounts of 0 - i.e., that they could not have traversed an intermediate forwarder. Why is that useful? > This is similar to MPLS and IPv6. What is the point of introducing this ambiguity? Just because IPv6 and MPLS got it wrong, why should we follow? Joe > Joe Touch wrote: > The current wording (in 05) is: > > " A 6-bit unsigned integer. Each RBridge that is about to forward a > frame to another RBridge MUST check this field and discard the frame > if this field is zero. If this field is non-zero, it MUST be > decremented in the forwarded frame." > > That is sufficient and correct. > > If the frame comes in as zero and needs to be forwarded, it is dropped. > > If the frame comes in as 1, it can be decremented and forwarded. If the > destination is the next rbridge, then the frame is NOT discarded. > > There is no need to consider a "0 or 1" case, as was proposed. The "0 or > 1" case would prevent a frame from reaching its destination if the > hopcount exactly matched the path length, and there's no reason to do > this. > > The suggested replacement is incorrect: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if either the Hop Count in the received frame is 0 or the Hop > Count is decremented to 0." > > This text incorrectly discards incoming frames that are 0 that are not > forwarded. I.e., the _original_ text was correct as it stood in v05. > > Joe > > > > > sgai wrote: > >>>> Joe, >>>> >>>> The wordind says: " [Hop Count] is decremented by 1 by each Rbridge that >>>> forwards a TRILL encapsulated frame". >>>> If the frame goes out of an Egress Rbridge it is not TRILL encapsulated. >>>> >>>> So where is the issue? >>>> >>>> -- Silvano >>>> >>>> >>>> On 5/20/09 9:51 AM, "Joe Touch" wrote: >>>> >>>> >>>> >>>> Dinesh G Dutt wrote: >>>> >>>>>>> Joe, >>>>>>> >>>>>>> I don't understand what you're saying. Rbridges are like routers, >>>>>>> more >>>>>>> like MPLS than like IP in that the header is added/removed by the >>>>>>> ingress/egress switch, not be end hosts. MPLS (RFC3032) specifies the >>>>>>> same behavior that has been suggested which is no different from >>>>>>> IPv6's >>>>>>> wording. >>>>>>> >>>> Rbridge transits are like routers. >>>> >>>> Rbridge ingress/egresses are like hosts - just as are any tunnel >>>> endpoints, or anything that adds/removes headers (not just "swaps" >>>> them). >>>> >>>> IPv6 says (in RFC2460), about its hop limit: >>>> >>>> Decremented by 1 by >>>> each node that forwards the packet. The packet >>>> is discarded if Hop Limit is decremented to >>>> zero. >>>> >>>> Neither the ingress nor the egress *forward* the trill packet. >>>> >>>> Joe >>>> >>>> >>>> >>>> >>>>>>> Donald Eastlake wrote: >>>>>>> >>>>>>> >>>>>>>>>> I'm fine with changing hop count processing to make it the same >>>>>>>>>> as IPv4 >>>>>>>>>> and IPv6 even it reduce the distance a TRILL encapsulated frame >>>>>>>>>> can go >>>>>>>>>> by 1 hop. >>>>>>>>>> >>>>>>> My point is that you're not making it the same as IPv4 and IPv6. >>>>>>> We need >>>>>>> to recognize that TRILL ingress and egress devices are NOT >>>>>>> forwarders -- >>>>>>> they are "hosts"; they do NOT decrement the hopcount, and thus >>>>>>> they do >>>>>>> NOT drop packets once received regardless of hopcount. >>>>>>> >>>>>>> I.e., either we're going for IP behavior or not... >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> On Fri, May 15, 2009 at 12:10 PM, Joe Touch >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> James Carlson wrote: >>>>>>>>>> >>>>>>>>>>> Radia Perlman writes: >>>>>>>>>>> >>>>>>>>>>>> I suspect nobody will care, so we can just go with Dinesh's >>>>>>>>>>>> wording. >>>>>>>>>>>> >>>>>>>>>> If the goal is to make this work like IP, the wording needs >>>>>>>>>> correction. >>>>>>>>>> >>>>>>>>>> The original proposed wording is: >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> The Hop Count field is a 6-bit unsigned integer. It is >>>>>>>>>> decremented by 1 >>>>>>>>>> by each Rbridge that forwards a TRILL encapsulated frame. The >>>>>>>>>> frame is >>>>>>>>>> dropped if either the Hop Count in the received frame is 0 or >>>>>>>>>> the Hop >>>>>>>>>> Count is decremented to 0. >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> In IP, the following is true: >>>>>>>>>> >>>>>>>>>> " A router MUST NOT discard a datagram just because it was >>>>>>>>>> received >>>>>>>>>> with TTL equal to zero or one; if it is to the router and >>>>>>>>>> otherwise >>>>>>>>>> valid, the router MUST attempt to receive it." >>>>>>>>>> >>>>>>>>>> I.e., the packet is dropped if the TTL is zero or one on >>>>>>>>>> receipt only if >>>>>>>>>> it is forwarded; if it is being 'accepted' (i.e., in this case, >>>>>>>>>> if the >>>>>>>>>> destination is the trill node doing the processing), then a TTL >>>>>>>>>> of zero >>>>>>>>>> is acceptable. >>>>>>>>>> >>>>>>>>>> It seems like the wording needs to include this second case... >>>>>>>>>> >>>>>>>>>> Joe >>>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoVXuIACgkQE5f5cImnZrsraACgvqY2vMNFcBLy7ylsO00gLIpn Z4sAnifQU9KMNmxW/8bwGFZbD3hyoWjT =j+Nj -----END PGP SIGNATURE----- From erik.nordmark at sun.com Thu May 21 10:36:03 2009 From: erik.nordmark at sun.com (Erik Nordmark) Date: Thu, 21 May 2009 10:36:03 -0700 Subject: [rbridge] No TRILL meeting in Stockholm Message-ID: <4A159103.7020505@sun.com> We seem to be making good progress resolving the remaining issues in the base protocol on the mailing list and I'm told that draft-ietf-trill-rbridge-protocol is being edited to capture the changes from the Hello padding discussion. While there are always things we could talk about, at this point we don't think we need to meet in Stockholm. Erik & Donald From Radia.Perlman at sun.com Thu May 28 15:37:05 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 28 May 2009 15:37:05 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A155EE2.2040306@isi.edu> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> Message-ID: <4A1F1211.9080001@sun.com> This was one issue I wasn't paying attention to, since it was not immediately obvious to me why anyone would care. I think I now understand the issue, and so let me explain it. Dinesh is arguing that in order to make something like traceroute work, you'd want something that behaves EXACTLY like a data packet (in case there is some bug with processing data packets), and can cause each hop to send an error report back. In order for that to work, TRILL has to do something that seems somewhat confusing -- if there are only two RBridges; R1 and R2, and ingress R1 is sending to egress R2, and wants the packet to be delivered to R2's endnode, R1 would have to set the TTL to 2. If we do that, then R1 can do a traceroute setting the TTL to 1 in order to get a "TTL expired" message from R2, and would have to set the TTL to 2 in order to allow the packet to actually be delivered to the endnodes. This is admittedly very confusing, and not really "architecturally pure", since the TRILL header itself only needs a TTL of 1 to reach the egress RBridge. But now that I understand the issue, and as a pragmatist, I sympathize with Dinesh. I can't think of any other way of making traceroute work, where ingress R1 can "ping" every hop along the path, with a packet that behaves exactly like a data packet. For instance, it might even be more elegant to have a special packet that travels along the path, and every RBridge that handles the packet sends back a "received your probe and forwarded it to the next hop" message. That way only a single management message gets all the RBridges along the path to send back messages. But the problem is, that is not *exactly* a data message, and it's possible that RBridges might route or handle such a packet differently from data packets, so it wouldn't be possible to find out what the issue is with the data packets. So I'm OK with doing what Dinesh wants, but the spec has to be really clear, because if I were implementing it I'd probably assume that R1 (ingress) should set the TTL to be the diameter of the core, rather than one more. Dinesh's suggested wording was: "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each Rbridge that forwards a TRILL encapsulated frame. The frame is dropped if the Hop Count is decremented to 0. " That wording is confusing, because technically, the egress RBridge does not forward the TRILL-encapsulated frame. It's no longer TRILL-encapsulated when the egress guy forwards it to the endnodes. So no simple wording is going to capture that. How about: "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 by each RBridge upon receipt, and the frame is dropped if the Hop Count is decremented to 0. Note that this means that the ingress RBridge must set the hop count to be at least one greater than the number of hops to the egress RBridge, in order for the egress RBridge to decapsulate and forward the packet to the attached endnodes." Note that this means that if R1 was sending a message to R2, and the only nodes in the world were R1 and R2, R1 would still have to set the TTL to 2 in order for R2 to process the packet. This could be thought of as R2 still being the egress RBridge, and the processing part of R2 being an "attached endnode". Radia From touch at ISI.EDU Thu May 28 17:35:37 2009 From: touch at ISI.EDU (Joe Touch) Date: Thu, 28 May 2009 17:35:37 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A1F1211.9080001@sun.com> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> Message-ID: <4A1F2DD9.5000909@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Radia, Radia Perlman wrote: > This was one issue I wasn't paying attention to, since it was not > immediately obvious to me why > anyone would care. I think I now understand the issue, and so let me > explain it. > > Dinesh is arguing that in order to make something like traceroute work, > you'd want something > that behaves EXACTLY like a data packet (in case there is some bug with > processing data packets), > and can cause each hop to send an error report back. Right - the question is whether it behaves exactly like an IPv6 packet or an IPv4 packet in this regard ;-) > In order for that > to work, TRILL has to do > something that seems somewhat confusing -- if there are only two > RBridges; R1 and R2, and ingress > R1 is sending to egress R2, and wants the packet to be delivered to R2's > endnode, R1 would have to > set the TTL to 2. Right - whereas in IPv4 the TTL could be 0, since there are no forwarding devices on the path. > If we do that, then R1 can do a traceroute setting the > TTL to 1 in order to > get a "TTL expired" message from R2, and would have to set the TTL to 2 > in order to allow > the packet to actually be delivered to the endnodes. Traceroute sends ping messages increases the TTL until it sees the destination; it doesn't start with a concept of what the TTL should be. It starts with TTL=1. Traceroute using the rules I proposed would reach the egress with a TTL=1, thus the first attempt (sending an ICMP ping ttl=1) would succeed because it would be responded with a ping response. > This is admittedly very confusing, and not really "architecturally > pure", since the TRILL header itself > only needs a TTL of 1 to reach the egress RBridge. Agreed. That's why I think that only forwarders should be checking the TTL at all, and why they should drop if incoming packets have a TTL=0, but should not drop if packets come in with TTL=1. I.e., ingress--egress reachable with TTL=0 ing--rb--egr reachable with TTL=1 ing--rb--rb--egr reachable with TTL=2 etc. > But now that I understand the issue, and as a pragmatist, I sympathize > with Dinesh. I can't think > of any other way of making traceroute work, where ingress R1 can "ping" > every hop along the path, > with a packet that behaves exactly like a data packet. The thing you're missing is only a ping facility. I'm guessing the goal here is to avoid the need for a ping facility, but without that how do you know you've reached the destination? > For instance, it > might even be more elegant > to have a special packet that travels along the path, and every RBridge > that handles the packet sends > back a "received your probe and forwarded it to the next hop" message. That, in IP, is "record route" (though it's recorded along the path). > That way only a single > management message gets all the RBridges along the path to send back > messages. But the problem > is, that is not *exactly* a data message, and it's possible that > RBridges might route or handle such > a packet differently from data packets, so it wouldn't be possible to > find out what the issue is with > the data packets. > > So I'm OK with doing what Dinesh wants, but the spec has to be really > clear, because if I were implementing > it I'd probably assume that R1 (ingress) should set the TTL to be the > diameter of the core, rather than one more. > > Dinesh's suggested wording was: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if the Hop Count is decremented to 0. " > > That wording is confusing, because technically, the egress RBridge does not > forward the TRILL-encapsulated frame. It's no longer TRILL-encapsulated when > the egress guy forwards it to the endnodes. Here's why Dinesh's wording is a problem ingress--egress TTL=0..63 -> packet accepted w/TTL=0..63 i.e., TTL unchanged ingr--rb--egr TTL=0 -> packet accepted w/TTL=63 0 63 63 ingr--rb--egr TTL=1 -> packet dropped at rb ingr--rb--egr TTL=2..63 -> packet accepted w/TTL=1..62 This is confusing. There are two ways to end up with TTL=63 at the destination, and one of them goes through an intervening rbridge. > So no simple wording is going to capture that. Why do you want something to happen at the egress? In traceroute, when you reach your destination (the egress here) you get a response from the ICMP PING, you don't get a "time exceeded". > How about: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each RBridge upon receipt, and the frame is dropped if the Hop Count is > decremented to 0. Note that this means that the ingress RBridge must set the > hop count to be at least one greater than the number of hops to the egress RBridge, > in order for the egress RBridge to decapsulate and forward the packet to the attached endnodes." What happens if you have the following? ingress--egress TTL=0 -> packet accepted w/TTL=63 0 63 ingress--egress TTL=1 -> packet dropped 1 0 (drop) ingress--egress TTL=2..63 -> packet accepted w/TTL=1..63 ingr--rb--egr TTL=0 -> packet accepted w/TTL=62 0 63 62 ingr--rb--egr TTL=1 -> packet dropped 1 0(drop) ingr--rb--egr TTL=2 -> packet dropped 2 1 0(drop) ingr--rb--egr TTL=3..63 -> packet accepted w/TTL=1..61 I find this very confusing as well. This is why I liked the idea of an IP-style count: "The Hop Count field is a 6-bit unsigned integer. A forwarding rbridge drops frames received with TTL=0, otherwise it decrements the TTL." ingr--rbridge TTL=0..63 -> packet accepted w/TTL=0..63 ingr--rb--egr TTL=0 -> packet dropped 0 (drop) ingr--rb--egr TTL=1..63 -> packet accepted w/TTL=0..62 This is quite simple and direct. The only thing that will never happen is that the egress will not respond with an ICMP "TTL exceeded" - it will (and should, IMO) respond with a ping response, which seems appropriate to me. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofLdkACgkQE5f5cImnZrsalwCgz4j4LUYR65hto/mm6n4ufaJc C5kAnRrYZdjQUqgDYriBRjJVUSS20Wyj =BNKC -----END PGP SIGNATURE----- From touch at ISI.EDU Thu May 28 17:35:37 2009 From: touch at ISI.EDU (Joe Touch) Date: Thu, 28 May 2009 17:35:37 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A1F1211.9080001@sun.com> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> Message-ID: <4A1F2DD9.5000909@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Radia, Radia Perlman wrote: > This was one issue I wasn't paying attention to, since it was not > immediately obvious to me why > anyone would care. I think I now understand the issue, and so let me > explain it. > > Dinesh is arguing that in order to make something like traceroute work, > you'd want something > that behaves EXACTLY like a data packet (in case there is some bug with > processing data packets), > and can cause each hop to send an error report back. Right - the question is whether it behaves exactly like an IPv6 packet or an IPv4 packet in this regard ;-) > In order for that > to work, TRILL has to do > something that seems somewhat confusing -- if there are only two > RBridges; R1 and R2, and ingress > R1 is sending to egress R2, and wants the packet to be delivered to R2's > endnode, R1 would have to > set the TTL to 2. Right - whereas in IPv4 the TTL could be 0, since there are no forwarding devices on the path. > If we do that, then R1 can do a traceroute setting the > TTL to 1 in order to > get a "TTL expired" message from R2, and would have to set the TTL to 2 > in order to allow > the packet to actually be delivered to the endnodes. Traceroute sends ping messages increases the TTL until it sees the destination; it doesn't start with a concept of what the TTL should be. It starts with TTL=1. Traceroute using the rules I proposed would reach the egress with a TTL=1, thus the first attempt (sending an ICMP ping ttl=1) would succeed because it would be responded with a ping response. > This is admittedly very confusing, and not really "architecturally > pure", since the TRILL header itself > only needs a TTL of 1 to reach the egress RBridge. Agreed. That's why I think that only forwarders should be checking the TTL at all, and why they should drop if incoming packets have a TTL=0, but should not drop if packets come in with TTL=1. I.e., ingress--egress reachable with TTL=0 ing--rb--egr reachable with TTL=1 ing--rb--rb--egr reachable with TTL=2 etc. > But now that I understand the issue, and as a pragmatist, I sympathize > with Dinesh. I can't think > of any other way of making traceroute work, where ingress R1 can "ping" > every hop along the path, > with a packet that behaves exactly like a data packet. The thing you're missing is only a ping facility. I'm guessing the goal here is to avoid the need for a ping facility, but without that how do you know you've reached the destination? > For instance, it > might even be more elegant > to have a special packet that travels along the path, and every RBridge > that handles the packet sends > back a "received your probe and forwarded it to the next hop" message. That, in IP, is "record route" (though it's recorded along the path). > That way only a single > management message gets all the RBridges along the path to send back > messages. But the problem > is, that is not *exactly* a data message, and it's possible that > RBridges might route or handle such > a packet differently from data packets, so it wouldn't be possible to > find out what the issue is with > the data packets. > > So I'm OK with doing what Dinesh wants, but the spec has to be really > clear, because if I were implementing > it I'd probably assume that R1 (ingress) should set the TTL to be the > diameter of the core, rather than one more. > > Dinesh's suggested wording was: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each Rbridge that forwards a TRILL encapsulated frame. The frame is > dropped if the Hop Count is decremented to 0. " > > That wording is confusing, because technically, the egress RBridge does not > forward the TRILL-encapsulated frame. It's no longer TRILL-encapsulated when > the egress guy forwards it to the endnodes. Here's why Dinesh's wording is a problem ingress--egress TTL=0..63 -> packet accepted w/TTL=0..63 i.e., TTL unchanged ingr--rb--egr TTL=0 -> packet accepted w/TTL=63 0 63 63 ingr--rb--egr TTL=1 -> packet dropped at rb ingr--rb--egr TTL=2..63 -> packet accepted w/TTL=1..62 This is confusing. There are two ways to end up with TTL=63 at the destination, and one of them goes through an intervening rbridge. > So no simple wording is going to capture that. Why do you want something to happen at the egress? In traceroute, when you reach your destination (the egress here) you get a response from the ICMP PING, you don't get a "time exceeded". > How about: > > "The Hop Count field is a 6-bit unsigned integer. It is decremented by 1 > by each RBridge upon receipt, and the frame is dropped if the Hop Count is > decremented to 0. Note that this means that the ingress RBridge must set the > hop count to be at least one greater than the number of hops to the egress RBridge, > in order for the egress RBridge to decapsulate and forward the packet to the attached endnodes." What happens if you have the following? ingress--egress TTL=0 -> packet accepted w/TTL=63 0 63 ingress--egress TTL=1 -> packet dropped 1 0 (drop) ingress--egress TTL=2..63 -> packet accepted w/TTL=1..63 ingr--rb--egr TTL=0 -> packet accepted w/TTL=62 0 63 62 ingr--rb--egr TTL=1 -> packet dropped 1 0(drop) ingr--rb--egr TTL=2 -> packet dropped 2 1 0(drop) ingr--rb--egr TTL=3..63 -> packet accepted w/TTL=1..61 I find this very confusing as well. This is why I liked the idea of an IP-style count: "The Hop Count field is a 6-bit unsigned integer. A forwarding rbridge drops frames received with TTL=0, otherwise it decrements the TTL." ingr--rbridge TTL=0..63 -> packet accepted w/TTL=0..63 ingr--rb--egr TTL=0 -> packet dropped 0 (drop) ingr--rb--egr TTL=1..63 -> packet accepted w/TTL=0..62 This is quite simple and direct. The only thing that will never happen is that the egress will not respond with an ICMP "TTL exceeded" - it will (and should, IMO) respond with a ping response, which seems appropriate to me. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofLdkACgkQE5f5cImnZrsalwCgz4j4LUYR65hto/mm6n4ufaJc C5kAnRrYZdjQUqgDYriBRjJVUSS20Wyj =BNKC -----END PGP SIGNATURE----- From Radia.Perlman at sun.com Fri May 29 13:45:35 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 29 May 2009 13:45:35 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A1F2DD9.5000909@isi.edu> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> Message-ID: <4A20496F.9010409@sun.com> Joe Touch wrote: > "The Hop Count field is a 6-bit unsigned integer. A forwarding rbridge > drops frames received with TTL=0, otherwise it decrements the TTL." > Yup. I like that wording even better. And the behavior will give the ability to do what traceroute does, and it also allows transmitting with TTL=number of hops to the egress RBridge, and reach the egress RBridge. Radia From Radia.Perlman at sun.com Fri May 29 14:24:19 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Fri, 29 May 2009 14:24:19 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A20496F.9010409@sun.com> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> <4A20496F.9010409@sun.com> Message-ID: <4A205283.80607@sun.com> Though, rereading that....I think it's even clearer if we remove the word "forwarding", so it would instead be: "The Hop Count field is a 6-bit unsigned integer. An Rbridge drops frames received with TTL=0, otherwise it decrements the TTL." Radia Perlman wrote: > Joe Touch wrote: > >> "The Hop Count field is a 6-bit unsigned integer. A forwarding rbridge >> drops frames received with TTL=0, otherwise it decrements the TTL." >> >> > Yup. I like that wording even better. And the behavior will give the > ability to do what traceroute > does, and it also allows transmitting with TTL=number of hops to the > egress RBridge, and > reach the egress RBridge. > > Radia > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From james.d.carlson at Sun.COM Fri May 29 14:52:05 2009 From: james.d.carlson at Sun.COM (James Carlson) Date: Fri, 29 May 2009 17:52:05 -0400 Subject: [rbridge] Hop Count processing In-Reply-To: <4A205283.80607@sun.com> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> <4A20496F.9010409@sun.com> <4A205283.80607@sun.com> Message-ID: <18976.22789.315890.979662@gargle.gargle.HOWL> Radia Perlman writes: > Though, rereading that....I think it's even clearer if we remove the > word "forwarding", so > it would instead be: > > "The Hop Count field is a 6-bit unsigned integer. An Rbridge > drops frames received with TTL=0, otherwise it decrements the TTL." Much better. The "forwarding" part is the qualifier most likely to confuse, and it doesn't actually change the meaning. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ddutt at cisco.com Fri May 29 15:41:13 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Fri, 29 May 2009 15:41:13 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <18976.22789.315890.979662@gargle.gargle.HOWL> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> <4A20496F.9010409@sun.com> <4A205283.80607@sun.com> <18976.22789.315890.979662@gargle.gargle.HOWL> Message-ID: <4A206489.7030902@cisco.com> I agree. This works for me, Dinesh James Carlson wrote: > Radia Perlman writes: > >> Though, rereading that....I think it's even clearer if we remove the >> word "forwarding", so >> it would instead be: >> >> "The Hop Count field is a 6-bit unsigned integer. An Rbridge >> drops frames received with TTL=0, otherwise it decrements the TTL." >> > > Much better. The "forwarding" part is the qualifier most likely to > confuse, and it doesn't actually change the meaning. > > -- 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 May 29 16:53:12 2009 From: touch at ISI.EDU (Joe Touch) Date: Fri, 29 May 2009 16:53:12 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A205283.80607@sun.com> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> <4A20496F.9010409@sun.com> <4A205283.80607@sun.com> Message-ID: <4A207568.9030109@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radia Perlman wrote: > Though, rereading that....I think it's even clearer if we remove the > word "forwarding", so > it would instead be: > > "The Hop Count field is a 6-bit unsigned integer. An Rbridge > drops frames received with TTL=0, otherwise it decrements the TTL." It is not any more or less clear; it just has a different behavior. ing-egr TTL=0 -> dropped at egr ing-egr TTL=1..63 -> arrive with TTL=0..62 ing-rb-egr TTL=0 -> dropped at rb ing-rb-egr TTL=1 -> dropped at egr ing-rb-egr TTL=2..63 -> arive with TTL=0..61 Given the complexity of the rest of the system, I don't understand why the concept of forwarding is considered difficult - it is needed to be understood anyway (see the second algorithm below). This wording only forces you to decrement the TTL of packets that have already arrived; its only feature is to render packets with TTL=0 useless to emit. Here's the algorithm: receive a packet if TTL=0 send an "ICMP hopcount exceeded" drop the packet (even though it has already arrived) else if it matches an interface then decapsulate it emit it out the indicated interface else forward the packet The only other thing this achieves is to have traceroute show you the destination twice - once when the packet arrives and is dropped, and a second time when the ICMP ping succeeds. > Radia Perlman wrote: >> Joe Touch wrote: >> >>> "The Hop Count field is a 6-bit unsigned integer. A forwarding rbridge >>> drops frames received with TTL=0, otherwise it decrements the TTL." Here's the algorithm -- note it has EXACTLY the same steps, just reverses the order in which the conditions are checked: receive a packet if it matches an interface then decapsulate it emit it out the indicated interface else if TTL=0 then send an "ICMP hopcount exceeded" drop the packet else decrement the TTL forward the packet IMO, this is clean. Joe >> Yup. I like that wording even better. And the behavior will give the >> ability to do what traceroute >> does, and it also allows transmitting with TTL=number of hops to the >> egress RBridge, and >> reach the egress RBridge. >> >> Radia >> >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkogdWgACgkQE5f5cImnZrsreQCggRVWdzafQyxMCCIbfcnHZiVk 5FsAoO3A/gcdz6lihBU20g9Kx1xAnpo6 =r7N7 -----END PGP SIGNATURE----- From touch at ISI.EDU Fri May 29 16:55:13 2009 From: touch at ISI.EDU (Joe Touch) Date: Fri, 29 May 2009 16:55:13 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <18976.22789.315890.979662@gargle.gargle.HOWL> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> <4A20496F.9010409@sun.com> <4A205283.80607@sun.com> <18976.22789.315890.979662@gargle.gargle.HOWL> Message-ID: <4A2075E1.7050801@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Carlson wrote: > Radia Perlman writes: >> Though, rereading that....I think it's even clearer if we remove the >> word "forwarding", so >> it would instead be: >> >> "The Hop Count field is a 6-bit unsigned integer. An Rbridge >> drops frames received with TTL=0, otherwise it decrements the TTL." > > Much better. The "forwarding" part is the qualifier most likely to > confuse, and it doesn't actually change the meaning. First, anyone who doesn't know what forwarding means is going to have a lot of problems implementing an rbridge. There are things it does with packets that terminate, and things it does with packets that forward. Forwarding is just a step that happens after you check whether a packet matches the addresses of the rbridge (and fails that match). Second, there are many more complex things than forwarding in the spec as well. Third, it not only changes the meaning, it changes the behavior. See the walkthrough in my previous mail. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkogdeEACgkQE5f5cImnZrswQACfU3j5BN3KRK0Mi4/kJP13R6d4 qOQAoM70VM4uLzkhOrhNh5RIU7kALjd0 =Psk5 -----END PGP SIGNATURE----- From touch at ISI.EDU Fri May 29 16:58:40 2009 From: touch at ISI.EDU (Joe Touch) Date: Fri, 29 May 2009 16:58:40 -0700 Subject: [rbridge] Hop Count processing In-Reply-To: <4A2075E1.7050801@isi.edu> References: <4A14C56A.1000408@isi.edu> <4A14DE61.4090502@cisco.com> <4A155EE2.2040306@isi.edu> <4A1F1211.9080001@sun.com> <4A1F2DD9.5000909@isi.edu> <4A20496F.9010409@sun.com> <4A205283.80607@sun.com> <18976.22789.315890.979662@gargle.gargle.HOWL> <4A2075E1.7050801@isi.edu> Message-ID: <4A2076B0.9040009@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: > > > James Carlson wrote: >> Radia Perlman writes: >>> Though, rereading that....I think it's even clearer if we remove the >>> word "forwarding", so >>> it would instead be: >>> >>> "The Hop Count field is a 6-bit unsigned integer. An Rbridge >>> drops frames received with TTL=0, otherwise it decrements the TTL." >> Much better. The "forwarding" part is the qualifier most likely to >> confuse, and it doesn't actually change the meaning. > > First, anyone who doesn't know what forwarding means is going to have a > lot of problems implementing an rbridge. There are things it does with > packets that terminate, and things it does with packets that forward. > Forwarding is just a step that happens after you check whether a packet > matches the addresses of the rbridge (and fails that match). > > Second, there are many more complex things than forwarding in the spec > as well. > > Third, it not only changes the meaning, it changes the behavior. See the > walkthrough in my previous mail. Oh, fourth (and really, wasn't this a goal?) - this would make the rbridge hopcount completely different from both IPv4 and IPv6 - BOTH of which define it exactly the way I did, FWIW - only *forwarders* check it and decrement it. > Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkogdrAACgkQE5f5cImnZrtDpwCdEqp9TUAO+pDnZlVC05L99Tx7 8XUAn2wo3hKzJE2blytx/Ahw6Eh0Ypfn =YrUn -----END PGP SIGNATURE-----