From erik.nordmark at sun.com Mon Aug 1 02:34:29 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Mon, 01 Aug 2005 02:34:29 -0700 Subject: [rbridge] Draft trill agenda Message-ID: <42EDECA5.9060300@sun.com> Any agenda bashing on the list? Note that the TRILL charter says we will work with IEEE 802.1 and L2VPN, but we don't have any specific items reflected in the meeting agenda on that yet. Erik Transparent Interconnection of Lots of Links (TRILL) THURSDAY, August 4, 1030-1230 ============================== Room: Room 342 CHAIR: Erik Nordmark AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes Problem statement and architecture Nordmark 20 minutes Goal: Discuss outline, find editor? Requirements on routing protocols Nordmark 15 minutes Goal: Discuss outline, find editor? Protocol document - open issues Perlman 50 minutes Goal: Enumerate and discuss open issue Accept as WG document? From Donald.Eastlake at motorola.com Mon Aug 1 06:11:27 2005 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Mon, 1 Aug 2005 09:11:27 -0400 Subject: [rbridge] Draft trill agenda Message-ID: <62173B970AE0A044AED8723C3BCF23810A3B5791@ma19exm01.e6.bcs.mot.com> Basically, there are three mechanisms that I can think of for TRILL working with the IEEE 802.1 WG (or perhaps its Interworking Task Group which handles bridging). 1. Liaisons: we could appoint a person as liaison to them and/or they could appoint a person as liaison to us. 2. Document reviews: we occasionally send them a document and ask for comments and/or they send us a document for our comments. 3. Joint teleconferences/meetings. There is nothing mutually exclusive about these so we could combine them. They are roughly in order of increasing effort. Donald -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark Sent: Monday, August 01, 2005 5:34 AM To: rbridge at postel.org Subject: [rbridge] Draft trill agenda Any agenda bashing on the list? Note that the TRILL charter says we will work with IEEE 802.1 and L2VPN, but we don't have any specific items reflected in the meeting agenda on that yet. Erik Transparent Interconnection of Lots of Links (TRILL) THURSDAY, August 4, 1030-1230 ============================== Room: Room 342 CHAIR: Erik Nordmark AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes Problem statement and architecture Nordmark 20 minutes Goal: Discuss outline, find editor? Requirements on routing protocols Nordmark 15 minutes Goal: Discuss outline, find editor? Protocol document - open issues Perlman 50 minutes Goal: Enumerate and discuss open issue Accept as WG document? _______________________________________________ rbridge mailing list rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge From loa at pi.se Tue Aug 2 08:46:07 2005 From: loa at pi.se (Loa Andersson) Date: Tue, 02 Aug 2005 17:46:07 +0200 Subject: [rbridge] name of the mailing list? In-Reply-To: References: Message-ID: <42EF953F.5060402@pi.se> since the working group name is trill, are there any plans to change the name of the mailing list? trill at ietf.org would be good /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson at acreo.se loa at pi.se From touch at ISI.EDU Tue Aug 2 09:42:23 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 02 Aug 2005 09:42:23 -0700 Subject: [rbridge] name of the mailing list? In-Reply-To: <42EF953F.5060402@pi.se> References: <42EF953F.5060402@pi.se> Message-ID: <42EFA26F.4010508@isi.edu> This isn't the only IETF WG that has a name that doesn't match that of the WG. FYI, right now, I maintain the mailing list and web pages (www.postel.org/rbridge). Not that it's critical, but I also don't think it's possible to move either the list of subscribers or the current archive. Joe Loa Andersson wrote: > since the working group name is trill, are there any plans to > change the name of the mailing list? > > trill at ietf.org would be good > > /Loa > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/rbridge/attachments/20050802/70b7c3c5/signature.bin From erik.nordmark at sun.com Tue Aug 2 10:02:47 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Tue, 02 Aug 2005 10:02:47 -0700 Subject: [rbridge] name of the mailing list? In-Reply-To: <42EF953F.5060402@pi.se> References: <42EF953F.5060402@pi.se> Message-ID: <42EFA737.5040202@sun.com> Loa Andersson wrote: > since the working group name is trill, are there any plans to > change the name of the mailing list? > > trill at ietf.org would be good I'll work with the secretariat to have such a thing setup. Erik From erik.nordmark at sun.com Tue Aug 2 10:06:38 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Tue, 02 Aug 2005 10:06:38 -0700 Subject: [rbridge] Updated TRILL agenda Message-ID: <42EFA81E.5070304@sun.com> Transparent Interconnection of Lots of Links (TRILL) THURSDAY, August 4, 1030-1230 ============================== Room: Room 342 CHAIR: Erik Nordmark AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes Coordination with IEEE 802.1 Eastlake 10 minutes Goal: Discuss options for review. Problem statement and architecture Nordmark 20 minutes Goal: Discuss outline, find editor? Requirements on routing protocols Nordmark 15 minutes Goal: Discuss outline, find editor? Protocol document - open issues Perlman 50 minutes Goal: Enumerate and discuss open issues Accept as WG document? From Vishwas at sinett.com Tue Aug 2 10:54:25 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Tue, 2 Aug 2005 10:54:25 -0700 Subject: [rbridge] Updated TRILL agenda Message-ID: Hi, One small typo, the draft name is draft-perlman-rbridge-03.txt Thanks, Vishwas ________________________________ From: rbridge-bounces at postel.org on behalf of Erik Nordmark Sent: Tue 8/2/2005 10:06 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Updated TRILL agenda Transparent Interconnection of Lots of Links (TRILL) THURSDAY, August 4, 1030-1230 ============================== Room: Room 342 CHAIR: Erik Nordmark AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes Coordination with IEEE 802.1 Eastlake 10 minutes Goal: Discuss options for review. Problem statement and architecture Nordmark 20 minutes Goal: Discuss outline, find editor? Requirements on routing protocols Nordmark 15 minutes Goal: Discuss outline, find editor? Protocol document - open issues Perlman 50 minutes Goal: Enumerate and discuss open issues Accept as WG document? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4963 bytes Desc: not available Url : http://www.postel.org/pipermail/rbridge/attachments/20050802/01aa56dc/attachment.bin From Vishwas at sinett.com Thu Aug 4 03:34:00 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Thu, 4 Aug 2005 03:34:00 -0700 Subject: [rbridge] Private VLAN support Message-ID: Hi Radia, Here is the link to Private VLAN http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-03.txt The question is do we intend to support backward compatibility with all features running on switches and actually deployed but not standardized? Thanks, Vishwas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3377 bytes Desc: not available Url : http://www.postel.org/pipermail/rbridge/attachments/20050804/39dd51af/attachment.bin From Vishwas at sinett.com Mon Aug 8 05:40:01 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Mon, 8 Aug 2005 05:40:01 -0700 Subject: [rbridge] How many spanning trees? Message-ID: Hi Radia, I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. I know of existing switches which do both of the above. Do let me know where I am missing the point? Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Tuesday, June 28, 2005 10:14 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] How many spanning trees? You are right that paths will not be the same from A to B as from B to A with an A-rooted tree (towards B) vs a B-rooted tree (towards A), at least if we do a straightforward calculation of spanning trees. I think trying to accomplish symmetric routes might require source/destination pair route computation. So hopefully we won't require symmetric routes. Radia Guillermo Ib??ez wrote: >Guillermo Ib??ez wrote: >This is my feedback on the "how many spanning trees" issue. > > >Radia Perlman wrote: > > > >>It would be nice to get opinions on remaining issues, and I think each >>issue should be in a different email thread, so I'm starting one. >> >>How many spanning >>trees should RBridges compute? Given the link state database, they can >>calculate >>as many as we want without further protocol messages. The possibilities are: >> >>a) one spanning tree: This is simplest, obviously. >> >> >> >The poor performance in the core for multicast is an important argument >against it. Other possibilities should exist, at least as an option. > > > >>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>RBridges >>(all of them...not just those attached to VLAN A) choose the RBridge, >>RA, that >>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>calculated >>with RA as root. THat spanning tree is pruned so that only branches that >>reach >>other VLAN A links survive. >> >>Why bother: If only a few links are VLAN A, then this allows more >>optimal delivery >>of multicast/unknown frames within the VLAN A broadcast domain. >> >> >> >> > >It seems that with this implementation compatibility (interoperability) >with bridges running Multiple Spanning Tree Protocol (MSTP) is >excluded. If bridges running MSTP exist in the campus network, they >must be confined in one or several MST regions with their specific >VLAN-to-spanning tree instance mappings and, like happens with STP or >RSTP, the trees will end at the region boundary with an rbridge. This >means that there could coexist "regions" running MSTP with their own >VLANs and multiple spanning trees inside the region, these regions >inserted between rbridges that use another type (range or IDs) of VLANs. >My understanding is then that the only VLANs capable of traversing the >campus end-to-end would be the VLANs handled by Rbridges, as the other >would be stopped by Rbridges if they are not known by them. > >c) one per RBridge > > > >>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>allows >>optimal delivery from source to the receivers of a particular multicast. >> >>Another reason is that it minimizes out of order delivery of packets in the >>case when S it talking to D, and initially D is unknown by the RBridges >>and packets >>have to be sent over a spanning tree rather than on the shortest path >> >> >>from S to D. > > >> >> >> >> >One tree per bridge is very efficient together with IGMP snooping, >assuming a core of rbridges. The plus point is that in this case the >multiple trees can also perform routing of unicast traffic, if used >together with the MAC address learning mechanism. In other words: >assuming a core formed by rbridges, using an spaning tree per rbridge >may be enough to perform all the routing via minimum paths. This >requires that the address learning mechanism works over the trees (the >trees coincide in opposite directions A to B and B to A, a tricky issue >when path costs can be equal). So it seems that there is some >overlapping or overkillling using multiple spanning trees for >broadcast/multicast and Dijkstra routing for unicast and simplifications >are possible. > > > >>******** >>I personally don't have strong opinions on this. If only a miniscule >>amount of >>the traffic is multicast/unknown, then one spanning tree seems good >>enough. If >>there's high volume IP-derived multicast applications, then perhaps one per >>RBridge would be worth it. >> >>So I guess I'd be inclined to either just have one spanning tree, or one per >>ingress RBridge. >> >>And if we did one per ingress RBridge, would it be worth computing all >>those trees >>in advance just in case, or only computing one when necessary? >> >>Radia >> From Radia.Perlman at sun.com Mon Aug 8 09:28:29 2005 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 08 Aug 2005 09:28:29 -0700 Subject: [rbridge] How many spanning trees? In-Reply-To: References: Message-ID: <42F7882D.7030109@sun.com> Re: Vishwas's question about encapsulation hiding the true nature of packets from possible intervening bridges (since the subject line would be otherwise misleading). Are all these things written down someplace? I find it frustrating to design around undocumented proprietary behavior (such as NATs). But anyway... I'd think firewalling wouldn't be that much of a problem. We wouldn't need a basic bridge in the core to be doing firewall...that could/should be done by an RBridge. Except if there were a basic bridge between the endnodes and the first RBridge, which is a natural place to put a firewall---then the basic bridge would see packets exactly as today and be able to do the same firewalling with no problem. As for IGMP...it would be the RBridges doing the IGMP snooping. For a basic bridge in the core, it would indeed not recognize an IGMP packet, but that's the behavior we want. It would just think it was forwarding vanilla multicast...it would be the RBridges deciding what IP multicast packets should be forwarded across which links, and intervening bridges should just forward. Can think of any other bridge idiosyncrasies we should think about? Thanks, Radia Vishwas Manral wrote: >Hi Radia, > >I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. > >The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. > >I know of existing switches which do both of the above. Do let me know where I am missing the point? > >Thanks, >Vishwas >-----Original Message----- >From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >Sent: Tuesday, June 28, 2005 10:14 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] How many spanning trees? > >You are right that paths will not be the same from A to B as from B to A >with an A-rooted tree (towards B) >vs a B-rooted tree (towards A), at least if we do a straightforward >calculation of spanning trees. I think trying >to accomplish symmetric routes might >require source/destination pair route computation. So hopefully we won't >require symmetric routes. > >Radia > > > >Guillermo Ib??ez wrote: > > > >>Guillermo Ib??ez wrote: >>This is my feedback on the "how many spanning trees" issue. >> >> >>Radia Perlman wrote: >> >> >> >> >> >>>It would be nice to get opinions on remaining issues, and I think each >>>issue should be in a different email thread, so I'm starting one. >>> >>>How many spanning >>>trees should RBridges compute? Given the link state database, they can >>>calculate >>>as many as we want without further protocol messages. The possibilities are: >>> >>>a) one spanning tree: This is simplest, obviously. >>> >>> >>> >>> >>> >>The poor performance in the core for multicast is an important argument >>against it. Other possibilities should exist, at least as an option. >> >> >> >> >> >>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>RBridges >>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>RA, that >>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>calculated >>>with RA as root. THat spanning tree is pruned so that only branches that >>>reach >>>other VLAN A links survive. >>> >>>Why bother: If only a few links are VLAN A, then this allows more >>>optimal delivery >>>of multicast/unknown frames within the VLAN A broadcast domain. >>> >>> >>> >>> >>> >>> >>It seems that with this implementation compatibility (interoperability) >>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>excluded. If bridges running MSTP exist in the campus network, they >>must be confined in one or several MST regions with their specific >>VLAN-to-spanning tree instance mappings and, like happens with STP or >>RSTP, the trees will end at the region boundary with an rbridge. This >>means that there could coexist "regions" running MSTP with their own >>VLANs and multiple spanning trees inside the region, these regions >>inserted between rbridges that use another type (range or IDs) of VLANs. >>My understanding is then that the only VLANs capable of traversing the >>campus end-to-end would be the VLANs handled by Rbridges, as the other >>would be stopped by Rbridges if they are not known by them. >> >>c) one per RBridge >> >> >> >> >> >>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>allows >>>optimal delivery from source to the receivers of a particular multicast. >>> >>>Another reason is that it minimizes out of order delivery of packets in the >>>case when S it talking to D, and initially D is unknown by the RBridges >>>and packets >>>have to be sent over a spanning tree rather than on the shortest path >>> >>> >>> >>> >>>from S to D. >> >> >> >> >>> >>> >>> >>> >>One tree per bridge is very efficient together with IGMP snooping, >>assuming a core of rbridges. The plus point is that in this case the >>multiple trees can also perform routing of unicast traffic, if used >>together with the MAC address learning mechanism. In other words: >>assuming a core formed by rbridges, using an spaning tree per rbridge >>may be enough to perform all the routing via minimum paths. This >>requires that the address learning mechanism works over the trees (the >>trees coincide in opposite directions A to B and B to A, a tricky issue >>when path costs can be equal). So it seems that there is some >>overlapping or overkillling using multiple spanning trees for >>broadcast/multicast and Dijkstra routing for unicast and simplifications >>are possible. >> >> >> >> >> >>>******** >>>I personally don't have strong opinions on this. If only a miniscule >>>amount of >>>the traffic is multicast/unknown, then one spanning tree seems good >>>enough. If >>>there's high volume IP-derived multicast applications, then perhaps one per >>>RBridge would be worth it. >>> >>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>ingress RBridge. >>> >>>And if we did one per ingress RBridge, would it be worth computing all >>>those trees >>>in advance just in case, or only computing one when necessary? >>> >>>Radia >>> >>> >>> > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://www.postel.org/mailman/listinfo/rbridge > > From touch at ISI.EDU Mon Aug 8 18:18:06 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 08 Aug 2005 18:18:06 -0700 Subject: [rbridge] How many spanning trees? In-Reply-To: References: Message-ID: <42F8044E.50909@isi.edu> Vishwas Manral wrote: > Hi Radia, > > I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. > > The rbridge document aims to add a new shim header after the layer-2 > header. The draft states that "A packet in transit must look to ordinary > bridges like an ordinary layer 2 packet." However switches (in the > silicon itself) these days are more intelligent and do deep packet > processing (for example for a basic firewall functionality/ IGMP > snooping etc). As the new ether Type would be unidentifiable, this would > result in a wrong behavior (example a basic filtering for wrong IP > header length check would fail here). However the rbridge protocol > defined in such a case will not work properly. Bridges should continue to bridge ethertypes that they do not know how to parse a-priori, otherwise they are not ethernet bridge devices. The rest of what you're describing are optional optimizations, which indeed will not occur for rbridge'd packets inside the campus. Joe > I know of existing switches which do both of the above. Do let me > know where I am missing the point? > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Tuesday, June 28, 2005 10:14 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] How many spanning trees? > > You are right that paths will not be the same from A to B as from B to A > with an A-rooted tree (towards B) > vs a B-rooted tree (towards A), at least if we do a straightforward > calculation of spanning trees. I think trying > to accomplish symmetric routes might > require source/destination pair route computation. So hopefully we won't > require symmetric routes. > > Radia > > > > Guillermo Ib??ez wrote: > > >>Guillermo Ib??ez wrote: >>This is my feedback on the "how many spanning trees" issue. >> >> >>Radia Perlman wrote: >> >> >> >> >>>It would be nice to get opinions on remaining issues, and I think each >>>issue should be in a different email thread, so I'm starting one. >>> >>>How many spanning >>>trees should RBridges compute? Given the link state database, they can >>>calculate >>>as many as we want without further protocol messages. The possibilities are: >>> >>>a) one spanning tree: This is simplest, obviously. >>> >>> >>> >> >>The poor performance in the core for multicast is an important argument >>against it. Other possibilities should exist, at least as an option. >> >> >> >> >>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>RBridges >>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>RA, that >>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>calculated >>>with RA as root. THat spanning tree is pruned so that only branches that >>>reach >>>other VLAN A links survive. >>> >>>Why bother: If only a few links are VLAN A, then this allows more >>>optimal delivery >>>of multicast/unknown frames within the VLAN A broadcast domain. >>> >>> >>> >>> >> >>It seems that with this implementation compatibility (interoperability) >>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>excluded. If bridges running MSTP exist in the campus network, they >>must be confined in one or several MST regions with their specific >>VLAN-to-spanning tree instance mappings and, like happens with STP or >>RSTP, the trees will end at the region boundary with an rbridge. This >>means that there could coexist "regions" running MSTP with their own >>VLANs and multiple spanning trees inside the region, these regions >>inserted between rbridges that use another type (range or IDs) of VLANs. >>My understanding is then that the only VLANs capable of traversing the >>campus end-to-end would be the VLANs handled by Rbridges, as the other >>would be stopped by Rbridges if they are not known by them. >> >>c) one per RBridge >> >> >> >> >>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>allows >>>optimal delivery from source to the receivers of a particular multicast. >>> >>>Another reason is that it minimizes out of order delivery of packets in the >>>case when S it talking to D, and initially D is unknown by the RBridges >>>and packets >>>have to be sent over a spanning tree rather than on the shortest path >>> >>> >> >>>from S to D. >> >> >> >>> >>> >>> >> >>One tree per bridge is very efficient together with IGMP snooping, >>assuming a core of rbridges. The plus point is that in this case the >>multiple trees can also perform routing of unicast traffic, if used >>together with the MAC address learning mechanism. In other words: >>assuming a core formed by rbridges, using an spaning tree per rbridge >>may be enough to perform all the routing via minimum paths. This >>requires that the address learning mechanism works over the trees (the >>trees coincide in opposite directions A to B and B to A, a tricky issue >>when path costs can be equal). So it seems that there is some >>overlapping or overkillling using multiple spanning trees for >>broadcast/multicast and Dijkstra routing for unicast and simplifications >>are possible. >> >> >> >> >>>******** >>>I personally don't have strong opinions on this. If only a miniscule >>>amount of >>>the traffic is multicast/unknown, then one spanning tree seems good >>>enough. If >>>there's high volume IP-derived multicast applications, then perhaps one per >>>RBridge would be worth it. >>> >>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>ingress RBridge. >>> >>>And if we did one per ingress RBridge, would it be worth computing all >>>those trees >>>in advance just in case, or only computing one when necessary? >>> >>>Radia >>> > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/rbridge/attachments/20050808/fda0377d/signature.bin From Vishwas at sinett.com Mon Aug 8 22:19:15 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Mon, 8 Aug 2005 22:19:15 -0700 Subject: [rbridge] Doubts about Rbridge Message-ID: Hi Radia, (PS: I am changing the subject line) The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break. A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in. Maybe I am missing the point altogether. Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Monday, August 08, 2005 9:58 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] How many spanning trees? Re: Vishwas's question about encapsulation hiding the true nature of packets from possible intervening bridges (since the subject line would be otherwise misleading). Are all these things written down someplace? I find it frustrating to design around undocumented proprietary behavior (such as NATs). But anyway... I'd think firewalling wouldn't be that much of a problem. We wouldn't need a basic bridge in the core to be doing firewall...that could/should be done by an RBridge. Except if there were a basic bridge between the endnodes and the first RBridge, which is a natural place to put a firewall---then the basic bridge would see packets exactly as today and be able to do the same firewalling with no problem. As for IGMP...it would be the RBridges doing the IGMP snooping. For a basic bridge in the core, it would indeed not recognize an IGMP packet, but that's the behavior we want. It would just think it was forwarding vanilla multicast...it would be the RBridges deciding what IP multicast packets should be forwarded across which links, and intervening bridges should just forward. Can think of any other bridge idiosyncrasies we should think about? Thanks, Radia Vishwas Manral wrote: >Hi Radia, > >I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. > >The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. > >I know of existing switches which do both of the above. Do let me know where I am missing the point? > >Thanks, >Vishwas >-----Original Message----- >From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >Sent: Tuesday, June 28, 2005 10:14 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] How many spanning trees? > >You are right that paths will not be the same from A to B as from B to A >with an A-rooted tree (towards B) >vs a B-rooted tree (towards A), at least if we do a straightforward >calculation of spanning trees. I think trying >to accomplish symmetric routes might >require source/destination pair route computation. So hopefully we won't >require symmetric routes. > >Radia > > > >Guillermo Ib??ez wrote: > > > >>Guillermo Ib??ez wrote: >>This is my feedback on the "how many spanning trees" issue. >> >> >>Radia Perlman wrote: >> >> >> >> >> >>>It would be nice to get opinions on remaining issues, and I think each >>>issue should be in a different email thread, so I'm starting one. >>> >>>How many spanning >>>trees should RBridges compute? Given the link state database, they can >>>calculate >>>as many as we want without further protocol messages. The possibilities are: >>> >>>a) one spanning tree: This is simplest, obviously. >>> >>> >>> >>> >>> >>The poor performance in the core for multicast is an important argument >>against it. Other possibilities should exist, at least as an option. >> >> >> >> >> >>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>RBridges >>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>RA, that >>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>calculated >>>with RA as root. THat spanning tree is pruned so that only branches that >>>reach >>>other VLAN A links survive. >>> >>>Why bother: If only a few links are VLAN A, then this allows more >>>optimal delivery >>>of multicast/unknown frames within the VLAN A broadcast domain. >>> >>> >>> >>> >>> >>> >>It seems that with this implementation compatibility (interoperability) >>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>excluded. If bridges running MSTP exist in the campus network, they >>must be confined in one or several MST regions with their specific >>VLAN-to-spanning tree instance mappings and, like happens with STP or >>RSTP, the trees will end at the region boundary with an rbridge. This >>means that there could coexist "regions" running MSTP with their own >>VLANs and multiple spanning trees inside the region, these regions >>inserted between rbridges that use another type (range or IDs) of VLANs. >>My understanding is then that the only VLANs capable of traversing the >>campus end-to-end would be the VLANs handled by Rbridges, as the other >>would be stopped by Rbridges if they are not known by them. >> >>c) one per RBridge >> >> >> >> >> >>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>allows >>>optimal delivery from source to the receivers of a particular multicast. >>> >>>Another reason is that it minimizes out of order delivery of packets in the >>>case when S it talking to D, and initially D is unknown by the RBridges >>>and packets >>>have to be sent over a spanning tree rather than on the shortest path >>> >>> >>> >>> >>>from S to D. >> >> >> >> >>> >>> >>> >>> >>One tree per bridge is very efficient together with IGMP snooping, >>assuming a core of rbridges. The plus point is that in this case the >>multiple trees can also perform routing of unicast traffic, if used >>together with the MAC address learning mechanism. In other words: >>assuming a core formed by rbridges, using an spaning tree per rbridge >>may be enough to perform all the routing via minimum paths. This >>requires that the address learning mechanism works over the trees (the >>trees coincide in opposite directions A to B and B to A, a tricky issue >>when path costs can be equal). So it seems that there is some >>overlapping or overkillling using multiple spanning trees for >>broadcast/multicast and Dijkstra routing for unicast and simplifications >>are possible. >> >> >> >> >> >>>******** >>>I personally don't have strong opinions on this. If only a miniscule >>>amount of >>>the traffic is multicast/unknown, then one spanning tree seems good >>>enough. If >>>there's high volume IP-derived multicast applications, then perhaps one per >>>RBridge would be worth it. >>> >>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>ingress RBridge. >>> >>>And if we did one per ingress RBridge, would it be worth computing all >>>those trees >>>in advance just in case, or only computing one when necessary? >>> >>>Radia >>> >>> >>> From Vishwas at sinett.com Tue Aug 9 04:22:46 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Tue, 9 Aug 2005 04:22:46 -0700 Subject: [rbridge] Doubts about Rbridge Message-ID: Hi Radia, Would "Protocol VLAN's" work with rbridges? With the etherType pointing to the Rbridge and not the protocol above I think it would not. Besides is there a reason to not have a "type" field in the shim header? Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Vishwas Manral Sent: Tuesday, August 09, 2005 10:49 AM To: Developing a hybrid router/bridge. Subject: [rbridge] Doubts about Rbridge Hi Radia, (PS: I am changing the subject line) The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break. A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in. Maybe I am missing the point altogether. Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Monday, August 08, 2005 9:58 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] How many spanning trees? Re: Vishwas's question about encapsulation hiding the true nature of packets from possible intervening bridges (since the subject line would be otherwise misleading). Are all these things written down someplace? I find it frustrating to design around undocumented proprietary behavior (such as NATs). But anyway... I'd think firewalling wouldn't be that much of a problem. We wouldn't need a basic bridge in the core to be doing firewall...that could/should be done by an RBridge. Except if there were a basic bridge between the endnodes and the first RBridge, which is a natural place to put a firewall---then the basic bridge would see packets exactly as today and be able to do the same firewalling with no problem. As for IGMP...it would be the RBridges doing the IGMP snooping. For a basic bridge in the core, it would indeed not recognize an IGMP packet, but that's the behavior we want. It would just think it was forwarding vanilla multicast...it would be the RBridges deciding what IP multicast packets should be forwarded across which links, and intervening bridges should just forward. Can think of any other bridge idiosyncrasies we should think about? Thanks, Radia Vishwas Manral wrote: >Hi Radia, > >I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. > >The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. > >I know of existing switches which do both of the above. Do let me know where I am missing the point? > >Thanks, >Vishwas >-----Original Message----- >From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >Sent: Tuesday, June 28, 2005 10:14 PM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] How many spanning trees? > >You are right that paths will not be the same from A to B as from B to A >with an A-rooted tree (towards B) >vs a B-rooted tree (towards A), at least if we do a straightforward >calculation of spanning trees. I think trying >to accomplish symmetric routes might >require source/destination pair route computation. So hopefully we won't >require symmetric routes. > >Radia > > > >Guillermo Ib??ez wrote: > > > >>Guillermo Ib??ez wrote: >>This is my feedback on the "how many spanning trees" issue. >> >> >>Radia Perlman wrote: >> >> >> >> >> >>>It would be nice to get opinions on remaining issues, and I think each >>>issue should be in a different email thread, so I'm starting one. >>> >>>How many spanning >>>trees should RBridges compute? Given the link state database, they can >>>calculate >>>as many as we want without further protocol messages. The possibilities are: >>> >>>a) one spanning tree: This is simplest, obviously. >>> >>> >>> >>> >>> >>The poor performance in the core for multicast is an important argument >>against it. Other possibilities should exist, at least as an option. >> >> >> >> >> >>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>RBridges >>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>RA, that >>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>calculated >>>with RA as root. THat spanning tree is pruned so that only branches that >>>reach >>>other VLAN A links survive. >>> >>>Why bother: If only a few links are VLAN A, then this allows more >>>optimal delivery >>>of multicast/unknown frames within the VLAN A broadcast domain. >>> >>> >>> >>> >>> >>> >>It seems that with this implementation compatibility (interoperability) >>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>excluded. If bridges running MSTP exist in the campus network, they >>must be confined in one or several MST regions with their specific >>VLAN-to-spanning tree instance mappings and, like happens with STP or >>RSTP, the trees will end at the region boundary with an rbridge. This >>means that there could coexist "regions" running MSTP with their own >>VLANs and multiple spanning trees inside the region, these regions >>inserted between rbridges that use another type (range or IDs) of VLANs. >>My understanding is then that the only VLANs capable of traversing the >>campus end-to-end would be the VLANs handled by Rbridges, as the other >>would be stopped by Rbridges if they are not known by them. >> >>c) one per RBridge >> >> >> >> >> >>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>allows >>>optimal delivery from source to the receivers of a particular multicast. >>> >>>Another reason is that it minimizes out of order delivery of packets in the >>>case when S it talking to D, and initially D is unknown by the RBridges >>>and packets >>>have to be sent over a spanning tree rather than on the shortest path >>> >>> >>> >>> >>>from S to D. >> >> >> >> >>> >>> >>> >>> >>One tree per bridge is very efficient together with IGMP snooping, >>assuming a core of rbridges. The plus point is that in this case the >>multiple trees can also perform routing of unicast traffic, if used >>together with the MAC address learning mechanism. In other words: >>assuming a core formed by rbridges, using an spaning tree per rbridge >>may be enough to perform all the routing via minimum paths. This >>requires that the address learning mechanism works over the trees (the >>trees coincide in opposite directions A to B and B to A, a tricky issue >>when path costs can be equal). So it seems that there is some >>overlapping or overkillling using multiple spanning trees for >>broadcast/multicast and Dijkstra routing for unicast and simplifications >>are possible. >> >> >> >> >> >>>******** >>>I personally don't have strong opinions on this. If only a miniscule >>>amount of >>>the traffic is multicast/unknown, then one spanning tree seems good >>>enough. If >>>there's high volume IP-derived multicast applications, then perhaps one per >>>RBridge would be worth it. >>> >>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>ingress RBridge. >>> >>>And if we did one per ingress RBridge, would it be worth computing all >>>those trees >>>in advance just in case, or only computing one when necessary? >>> >>>Radia >>> >>> >>> _______________________________________________ rbridge mailing list rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Tue Aug 9 09:23:40 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 09 Aug 2005 09:23:40 -0700 Subject: [rbridge] Doubts about Rbridge In-Reply-To: References: Message-ID: <42F8D88C.2080307@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vishwas Manral wrote: > Hi Radia, > > Would "Protocol VLAN's" work with rbridges? With the etherType > pointing to the Rbridge and not the protocol above I think it would not.\ The different VLANs would need to be identified at the rbridge ingress, and mapped to different rbridge egress IDs, which would then map to different forwarding tables accordingly. Inside the rbridge, the rbridge forwarding takes over. Keep in mind that looking inside an rbridge is (and should be) like looking inside a bridge. Bridges inside the campus would no longer see the protocol vlan tags or any other vlan tags per se - they'd just see the rbridge tags, which is all they should see. Note that protocol vlans or other vlans can work inside the campus between other bridges, but aren't really participating in the rbridge internal forwarding structure. > Besides is there a reason to not have a "type" field in the shim header? The only reason to have it is because it's needed; the only reason to need it would be if rbridges would forward differently on their basis, or expect bridges inside the campus to to so. However, as per above, the rbridge replaces the vlan/protocol ID structure with its own set of addresses which are sufficient for its forwarding. Joe > > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Vishwas Manral > Sent: Tuesday, August 09, 2005 10:49 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Doubts about Rbridge > > Hi Radia, > > (PS: I am changing the subject line) > The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break. > > A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in. > > Maybe I am missing the point altogether. > > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Monday, August 08, 2005 9:58 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] How many spanning trees? > > Re: Vishwas's question about encapsulation hiding the true nature of > packets from possible intervening > bridges (since the subject line would be otherwise misleading). > > Are all these things written down someplace? I find it frustrating to > design around undocumented > proprietary behavior (such as NATs). But anyway... > > I'd think firewalling wouldn't be that much of a problem. We wouldn't > need a basic bridge in the core > to be doing firewall...that could/should be done by an RBridge. Except > if there were a basic bridge between > the endnodes and the first RBridge, which is a natural place to > put a firewall---then the basic bridge would see packets exactly as > today and > be able to do the same firewalling with no problem. > > As for IGMP...it would be the RBridges doing the IGMP snooping. For a > basic bridge in the > core, it would indeed not recognize an IGMP packet, but that's the > behavior we want. It would > just think it was forwarding vanilla multicast...it would be the > RBridges deciding what IP multicast > packets should be forwarded across which links, and intervening bridges > should just forward. > > Can think of any other bridge idiosyncrasies we should think about? > > Thanks, > > Radia > > Vishwas Manral wrote: > > >>Hi Radia, >> >>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. >> >>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. >> >>I know of existing switches which do both of the above. Do let me know where I am missing the point? >> >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >>Sent: Tuesday, June 28, 2005 10:14 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] How many spanning trees? >> >>You are right that paths will not be the same from A to B as from B to A >>with an A-rooted tree (towards B) >>vs a B-rooted tree (towards A), at least if we do a straightforward >>calculation of spanning trees. I think trying >>to accomplish symmetric routes might >>require source/destination pair route computation. So hopefully we won't >>require symmetric routes. >> >>Radia >> >> >> >>Guillermo Ib??ez wrote: >> >> >> >> >>>Guillermo Ib??ez wrote: >>>This is my feedback on the "how many spanning trees" issue. >>> >>> >>>Radia Perlman wrote: >>> >>> >>> >>> >>> >>> >>>>It would be nice to get opinions on remaining issues, and I think each >>>>issue should be in a different email thread, so I'm starting one. >>>> >>>>How many spanning >>>>trees should RBridges compute? Given the link state database, they can >>>>calculate >>>>as many as we want without further protocol messages. The possibilities are: >>>> >>>>a) one spanning tree: This is simplest, obviously. >>>> >>>> >>>> >>>> >>>> >>> >>>The poor performance in the core for multicast is an important argument >>>against it. Other possibilities should exist, at least as an option. >>> >>> >>> >>> >>> >>> >>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>>RBridges >>>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>>RA, that >>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>>calculated >>>>with RA as root. THat spanning tree is pruned so that only branches that >>>>reach >>>>other VLAN A links survive. >>>> >>>>Why bother: If only a few links are VLAN A, then this allows more >>>>optimal delivery >>>>of multicast/unknown frames within the VLAN A broadcast domain. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>It seems that with this implementation compatibility (interoperability) >>>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>>excluded. If bridges running MSTP exist in the campus network, they >>>must be confined in one or several MST regions with their specific >>>VLAN-to-spanning tree instance mappings and, like happens with STP or >>>RSTP, the trees will end at the region boundary with an rbridge. This >>>means that there could coexist "regions" running MSTP with their own >>>VLANs and multiple spanning trees inside the region, these regions >>>inserted between rbridges that use another type (range or IDs) of VLANs. >>>My understanding is then that the only VLANs capable of traversing the >>>campus end-to-end would be the VLANs handled by Rbridges, as the other >>>would be stopped by Rbridges if they are not known by them. >>> >>>c) one per RBridge >>> >>> >>> >>> >>> >>> >>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>>allows >>>>optimal delivery from source to the receivers of a particular multicast. >>>> >>>>Another reason is that it minimizes out of order delivery of packets in the >>>>case when S it talking to D, and initially D is unknown by the RBridges >>>>and packets >>>>have to be sent over a spanning tree rather than on the shortest path >>>> >>>> >>>> >>>> >>> >>>>from S to D. >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>> >>>One tree per bridge is very efficient together with IGMP snooping, >>>assuming a core of rbridges. The plus point is that in this case the >>>multiple trees can also perform routing of unicast traffic, if used >>>together with the MAC address learning mechanism. In other words: >>>assuming a core formed by rbridges, using an spaning tree per rbridge >>>may be enough to perform all the routing via minimum paths. This >>>requires that the address learning mechanism works over the trees (the >>>trees coincide in opposite directions A to B and B to A, a tricky issue >>>when path costs can be equal). So it seems that there is some >>>overlapping or overkillling using multiple spanning trees for >>>broadcast/multicast and Dijkstra routing for unicast and simplifications >>>are possible. >>> >>> >>> >>> >>> >>> >>>>******** >>>>I personally don't have strong opinions on this. If only a miniscule >>>>amount of >>>>the traffic is multicast/unknown, then one spanning tree seems good >>>>enough. If >>>>there's high volume IP-derived multicast applications, then perhaps one per >>>>RBridge would be worth it. >>>> >>>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>>ingress RBridge. >>>> >>>>And if we did one per ingress RBridge, would it be worth computing all >>>>those trees >>>>in advance just in case, or only computing one when necessary? >>>> >>>>Radia >>>> >>>> >>>> > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+NiME5f5cImnZrsRAl3EAKCySOo+d/I67eL+cs6Rvf3EoB3ubgCfQ0i+ /DJULWicdxcteQuIdsy+sM8= =Mtq9 -----END PGP SIGNATURE----- From touch at ISI.EDU Tue Aug 9 09:30:16 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 09 Aug 2005 09:30:16 -0700 Subject: [rbridge] Doubts about Rbridge In-Reply-To: References: Message-ID: <42F8DA18.6080801@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vishwas Manral wrote: > Hi Radia, > > (PS: I am changing the subject line) > The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break. The inside of the rbridge would limit multicast in other ways, e.g., using different trees for each mcast group and limiting tree participation at the ingress/egress nodes. Inside the rbridge, however, there would be no IGMP header to examine anymore, because it's not necessary. > A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in. Definitely. Anyone putting a firewall inside an rbridge campus would have problems - but that seems correct. > Maybe I am missing the point altogether. Two concepts may help: 1) IMO, an rbridge campus should act like a single bridge device to the outside world 2) an rbridge campus should be more efficient than replacing it with a set of conventional bridges Most of your questions are answered, IMO, by considering #1 rather than #2. Joe > > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Monday, August 08, 2005 9:58 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] How many spanning trees? > > Re: Vishwas's question about encapsulation hiding the true nature of > packets from possible intervening > bridges (since the subject line would be otherwise misleading). > > Are all these things written down someplace? I find it frustrating to > design around undocumented > proprietary behavior (such as NATs). But anyway... > > I'd think firewalling wouldn't be that much of a problem. We wouldn't > need a basic bridge in the core > to be doing firewall...that could/should be done by an RBridge. Except > if there were a basic bridge between > the endnodes and the first RBridge, which is a natural place to > put a firewall---then the basic bridge would see packets exactly as > today and > be able to do the same firewalling with no problem. > > As for IGMP...it would be the RBridges doing the IGMP snooping. For a > basic bridge in the > core, it would indeed not recognize an IGMP packet, but that's the > behavior we want. It would > just think it was forwarding vanilla multicast...it would be the > RBridges deciding what IP multicast > packets should be forwarded across which links, and intervening bridges > should just forward. > > Can think of any other bridge idiosyncrasies we should think about? > > Thanks, > > Radia > > Vishwas Manral wrote: > > >>Hi Radia, >> >>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. >> >>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. >> >>I know of existing switches which do both of the above. Do let me know where I am missing the point? >> >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >>Sent: Tuesday, June 28, 2005 10:14 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] How many spanning trees? >> >>You are right that paths will not be the same from A to B as from B to A >>with an A-rooted tree (towards B) >>vs a B-rooted tree (towards A), at least if we do a straightforward >>calculation of spanning trees. I think trying >>to accomplish symmetric routes might >>require source/destination pair route computation. So hopefully we won't >>require symmetric routes. >> >>Radia >> >> >> >>Guillermo Ib??ez wrote: >> >> >> >> >>>Guillermo Ib??ez wrote: >>>This is my feedback on the "how many spanning trees" issue. >>> >>> >>>Radia Perlman wrote: >>> >>> >>> >>> >>> >>> >>>>It would be nice to get opinions on remaining issues, and I think each >>>>issue should be in a different email thread, so I'm starting one. >>>> >>>>How many spanning >>>>trees should RBridges compute? Given the link state database, they can >>>>calculate >>>>as many as we want without further protocol messages. The possibilities are: >>>> >>>>a) one spanning tree: This is simplest, obviously. >>>> >>>> >>>> >>>> >>>> >>> >>>The poor performance in the core for multicast is an important argument >>>against it. Other possibilities should exist, at least as an option. >>> >>> >>> >>> >>> >>> >>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>>RBridges >>>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>>RA, that >>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>>calculated >>>>with RA as root. THat spanning tree is pruned so that only branches that >>>>reach >>>>other VLAN A links survive. >>>> >>>>Why bother: If only a few links are VLAN A, then this allows more >>>>optimal delivery >>>>of multicast/unknown frames within the VLAN A broadcast domain. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>It seems that with this implementation compatibility (interoperability) >>>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>>excluded. If bridges running MSTP exist in the campus network, they >>>must be confined in one or several MST regions with their specific >>>VLAN-to-spanning tree instance mappings and, like happens with STP or >>>RSTP, the trees will end at the region boundary with an rbridge. This >>>means that there could coexist "regions" running MSTP with their own >>>VLANs and multiple spanning trees inside the region, these regions >>>inserted between rbridges that use another type (range or IDs) of VLANs. >>>My understanding is then that the only VLANs capable of traversing the >>>campus end-to-end would be the VLANs handled by Rbridges, as the other >>>would be stopped by Rbridges if they are not known by them. >>> >>>c) one per RBridge >>> >>> >>> >>> >>> >>> >>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>>allows >>>>optimal delivery from source to the receivers of a particular multicast. >>>> >>>>Another reason is that it minimizes out of order delivery of packets in the >>>>case when S it talking to D, and initially D is unknown by the RBridges >>>>and packets >>>>have to be sent over a spanning tree rather than on the shortest path >>>> >>>> >>>> >>>> >>> >>>>from S to D. >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>> >>>One tree per bridge is very efficient together with IGMP snooping, >>>assuming a core of rbridges. The plus point is that in this case the >>>multiple trees can also perform routing of unicast traffic, if used >>>together with the MAC address learning mechanism. In other words: >>>assuming a core formed by rbridges, using an spaning tree per rbridge >>>may be enough to perform all the routing via minimum paths. This >>>requires that the address learning mechanism works over the trees (the >>>trees coincide in opposite directions A to B and B to A, a tricky issue >>>when path costs can be equal). So it seems that there is some >>>overlapping or overkillling using multiple spanning trees for >>>broadcast/multicast and Dijkstra routing for unicast and simplifications >>>are possible. >>> >>> >>> >>> >>> >>> >>>>******** >>>>I personally don't have strong opinions on this. If only a miniscule >>>>amount of >>>>the traffic is multicast/unknown, then one spanning tree seems good >>>>enough. If >>>>there's high volume IP-derived multicast applications, then perhaps one per >>>>RBridge would be worth it. >>>> >>>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>>ingress RBridge. >>>> >>>>And if we did one per ingress RBridge, would it be worth computing all >>>>those trees >>>>in advance just in case, or only computing one when necessary? >>>> >>>>Radia >>>> >>>> >>>> > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+NoXE5f5cImnZrsRAqSBAKCqtolOetO+RIr8jSpTW4xBum3WPgCfVr7u Siu0Cfc4pLJJCNZVuua1V/s= =hTxS -----END PGP SIGNATURE----- From Radia.Perlman at sun.com Tue Aug 9 10:39:09 2005 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 09 Aug 2005 10:39:09 -0700 Subject: [rbridge] VLANs and type field In-Reply-To: References: Message-ID: <42F8EA3D.7060002@sun.com> Re: Vishwas's question about VLANs (I'm changing the subject line to be more explicit), and the "protocol type" question later If I understand your question... >>Vishwas Manral wrote: >>Would "Protocol VLAN's" work with rbridges? With the etherType pointing to the Rbridge >>and not the protocol above I think it would not. It is our intent that VLANs work with RBridges. The way it would work is that the VLAN tag would be in the inner header, and ignored by the intermediate RBridges while the packet is in transit. So there would be a core infrastructure that can forward any packet from any VLAN, but the links upon which endnodes reside would be configured (as they are today) with VLAN numbers. The first RBridge, if it is configured to add a VLAN tag of "VLAN A" to a packet from port p, will add the VLAN tag to the inner header (just like a bridge would do today), and then look up the egress RBridge, put the ID of the egress RBridge in the shim header, and then put on the encapsulation header. Intermediate bridges would not see this as a VLAN packet...just an ordinary packet delivered hop by hop to each RBridge. The final RBridge would remove the VLAN tag before sending it to the final endnode (just as a bridge would do today). If there were a bridge between the source endnode and the first RBridge, and that bridge is configured to insert a VLAN tag, then that bridge would do exactly as it does today, and the first RBridge would not add a VLAN tag, but would still add the shim and encapsulation header. In this way packets can transit any intermediate RBridge-RBridge link regardless of which VLAN the inner packet is marked with. And I think that is the behavior that is wanted. The RBridges have to ensure that a VLAN A packet is not delivered to an endnode on a link marked as not allowing VLAN A traffic, but it's OK to transit such a link provided that endnodes don't see the packet (which they wouldn't if it has the encapsulation header. ******************* As for the other question... >Vishwas Manral wrote: >>Besides is there a reason to not have a "type" field in the shim header? Not sure why that would be needed. What would you want to use that for? The type of the original packet is preserved already (with the original frame, inside the shim header). Radia From anoop.ghanwani at hp.com Tue Aug 9 13:40:58 2005 From: anoop.ghanwani at hp.com (Ghanwani, Anoop) Date: Tue, 9 Aug 2005 13:40:58 -0700 Subject: [rbridge] VLANs and type field Message-ID: <83AB0942FD087D499DF2DD5CEE1B61330226A606@cacexc06.americas.cpqcorp.net> > Intermediate bridges would not see this as a VLAN packet...just an > ordinary packet delivered hop by hop to > each RBridge. Just to clarify, does this mean that all Q-bridges interconnecting rbridges would essentially be in the same VLAN (i.e. a single broadcast domain)? Anoop From Vishwas at sinett.com Tue Aug 9 23:14:14 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Tue, 9 Aug 2005 23:14:14 -0700 Subject: [rbridge] Doubts about Rbridge Message-ID: Hi Joe, I miss the point regarding the "Type" field not required. "EtherType" field in the Ethernet header is used to tell the type of packet above Ethernet. When traversing an rbridge we loose the information of the packet above, because we replace the etherType by the rbridge type. How will we know what is the etherType when a packet inner header (after the shim header) needs to be looked into (L3 switching needs to be done). Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch Sent: Tuesday, August 09, 2005 9:54 PM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Doubts about Rbridge -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vishwas Manral wrote: > Hi Radia, > > Would "Protocol VLAN's" work with rbridges? With the etherType > pointing to the Rbridge and not the protocol above I think it would not.\ The different VLANs would need to be identified at the rbridge ingress, and mapped to different rbridge egress IDs, which would then map to different forwarding tables accordingly. Inside the rbridge, the rbridge forwarding takes over. Keep in mind that looking inside an rbridge is (and should be) like looking inside a bridge. Bridges inside the campus would no longer see the protocol vlan tags or any other vlan tags per se - they'd just see the rbridge tags, which is all they should see. Note that protocol vlans or other vlans can work inside the campus between other bridges, but aren't really participating in the rbridge internal forwarding structure. > Besides is there a reason to not have a "type" field in the shim header? The only reason to have it is because it's needed; the only reason to need it would be if rbridges would forward differently on their basis, or expect bridges inside the campus to to so. However, as per above, the rbridge replaces the vlan/protocol ID structure with its own set of addresses which are sufficient for its forwarding. Joe > > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Vishwas Manral > Sent: Tuesday, August 09, 2005 10:49 AM > To: Developing a hybrid router/bridge. > Subject: [rbridge] Doubts about Rbridge > > Hi Radia, > > (PS: I am changing the subject line) > The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break. > > A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in. > > Maybe I am missing the point altogether. > > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Monday, August 08, 2005 9:58 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] How many spanning trees? > > Re: Vishwas's question about encapsulation hiding the true nature of > packets from possible intervening > bridges (since the subject line would be otherwise misleading). > > Are all these things written down someplace? I find it frustrating to > design around undocumented > proprietary behavior (such as NATs). But anyway... > > I'd think firewalling wouldn't be that much of a problem. We wouldn't > need a basic bridge in the core > to be doing firewall...that could/should be done by an RBridge. Except > if there were a basic bridge between > the endnodes and the first RBridge, which is a natural place to > put a firewall---then the basic bridge would see packets exactly as > today and > be able to do the same firewalling with no problem. > > As for IGMP...it would be the RBridges doing the IGMP snooping. For a > basic bridge in the > core, it would indeed not recognize an IGMP packet, but that's the > behavior we want. It would > just think it was forwarding vanilla multicast...it would be the > RBridges deciding what IP multicast > packets should be forwarded across which links, and intervening bridges > should just forward. > > Can think of any other bridge idiosyncrasies we should think about? > > Thanks, > > Radia > > Vishwas Manral wrote: > > >>Hi Radia, >> >>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. >> >>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. >> >>I know of existing switches which do both of the above. Do let me know where I am missing the point? >> >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >>Sent: Tuesday, June 28, 2005 10:14 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] How many spanning trees? >> >>You are right that paths will not be the same from A to B as from B to A >>with an A-rooted tree (towards B) >>vs a B-rooted tree (towards A), at least if we do a straightforward >>calculation of spanning trees. I think trying >>to accomplish symmetric routes might >>require source/destination pair route computation. So hopefully we won't >>require symmetric routes. >> >>Radia >> >> >> >>Guillermo Ib??ez wrote: >> >> >> >> >>>Guillermo Ib??ez wrote: >>>This is my feedback on the "how many spanning trees" issue. >>> >>> >>>Radia Perlman wrote: >>> >>> >>> >>> >>> >>> >>>>It would be nice to get opinions on remaining issues, and I think each >>>>issue should be in a different email thread, so I'm starting one. >>>> >>>>How many spanning >>>>trees should RBridges compute? Given the link state database, they can >>>>calculate >>>>as many as we want without further protocol messages. The possibilities are: >>>> >>>>a) one spanning tree: This is simplest, obviously. >>>> >>>> >>>> >>>> >>>> >>> >>>The poor performance in the core for multicast is an important argument >>>against it. Other possibilities should exist, at least as an option. >>> >>> >>> >>> >>> >>> >>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>>RBridges >>>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>>RA, that >>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>>calculated >>>>with RA as root. THat spanning tree is pruned so that only branches that >>>>reach >>>>other VLAN A links survive. >>>> >>>>Why bother: If only a few links are VLAN A, then this allows more >>>>optimal delivery >>>>of multicast/unknown frames within the VLAN A broadcast domain. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>It seems that with this implementation compatibility (interoperability) >>>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>>excluded. If bridges running MSTP exist in the campus network, they >>>must be confined in one or several MST regions with their specific >>>VLAN-to-spanning tree instance mappings and, like happens with STP or >>>RSTP, the trees will end at the region boundary with an rbridge. This >>>means that there could coexist "regions" running MSTP with their own >>>VLANs and multiple spanning trees inside the region, these regions >>>inserted between rbridges that use another type (range or IDs) of VLANs. >>>My understanding is then that the only VLANs capable of traversing the >>>campus end-to-end would be the VLANs handled by Rbridges, as the other >>>would be stopped by Rbridges if they are not known by them. >>> >>>c) one per RBridge >>> >>> >>> >>> >>> >>> >>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>>allows >>>>optimal delivery from source to the receivers of a particular multicast. >>>> >>>>Another reason is that it minimizes out of order delivery of packets in the >>>>case when S it talking to D, and initially D is unknown by the RBridges >>>>and packets >>>>have to be sent over a spanning tree rather than on the shortest path >>>> >>>> >>>> >>>> >>> >>>>from S to D. >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>> >>>One tree per bridge is very efficient together with IGMP snooping, >>>assuming a core of rbridges. The plus point is that in this case the >>>multiple trees can also perform routing of unicast traffic, if used >>>together with the MAC address learning mechanism. In other words: >>>assuming a core formed by rbridges, using an spaning tree per rbridge >>>may be enough to perform all the routing via minimum paths. This >>>requires that the address learning mechanism works over the trees (the >>>trees coincide in opposite directions A to B and B to A, a tricky issue >>>when path costs can be equal). So it seems that there is some >>>overlapping or overkillling using multiple spanning trees for >>>broadcast/multicast and Dijkstra routing for unicast and simplifications >>>are possible. >>> >>> >>> >>> >>> >>> >>>>******** >>>>I personally don't have strong opinions on this. If only a miniscule >>>>amount of >>>>the traffic is multicast/unknown, then one spanning tree seems good >>>>enough. If >>>>there's high volume IP-derived multicast applications, then perhaps one per >>>>RBridge would be worth it. >>>> >>>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>>ingress RBridge. >>>> >>>>And if we did one per ingress RBridge, would it be worth computing all >>>>those trees >>>>in advance just in case, or only computing one when necessary? >>>> >>>>Radia >>>> >>>> >>>> From Vishwas at sinett.com Tue Aug 9 23:52:26 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Tue, 9 Aug 2005 23:52:26 -0700 Subject: [rbridge] VLANs and type field Message-ID: Hi Radia/ Joe, I got the use of the "type" field. The original packet is still saved so is the type field in the header. Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Tuesday, August 09, 2005 11:09 PM To: Developing a hybrid router/bridge. Subject: [rbridge] VLANs and type field Re: Vishwas's question about VLANs (I'm changing the subject line to be more explicit), and the "protocol type" question later If I understand your question... >>Vishwas Manral wrote: >>Would "Protocol VLAN's" work with rbridges? With the etherType pointing to the Rbridge >>and not the protocol above I think it would not. It is our intent that VLANs work with RBridges. The way it would work is that the VLAN tag would be in the inner header, and ignored by the intermediate RBridges while the packet is in transit. So there would be a core infrastructure that can forward any packet from any VLAN, but the links upon which endnodes reside would be configured (as they are today) with VLAN numbers. The first RBridge, if it is configured to add a VLAN tag of "VLAN A" to a packet from port p, will add the VLAN tag to the inner header (just like a bridge would do today), and then look up the egress RBridge, put the ID of the egress RBridge in the shim header, and then put on the encapsulation header. Intermediate bridges would not see this as a VLAN packet...just an ordinary packet delivered hop by hop to each RBridge. The final RBridge would remove the VLAN tag before sending it to the final endnode (just as a bridge would do today). If there were a bridge between the source endnode and the first RBridge, and that bridge is configured to insert a VLAN tag, then that bridge would do exactly as it does today, and the first RBridge would not add a VLAN tag, but would still add the shim and encapsulation header. In this way packets can transit any intermediate RBridge-RBridge link regardless of which VLAN the inner packet is marked with. And I think that is the behavior that is wanted. The RBridges have to ensure that a VLAN A packet is not delivered to an endnode on a link marked as not allowing VLAN A traffic, but it's OK to transit such a link provided that endnodes don't see the packet (which they wouldn't if it has the encapsulation header. ******************* As for the other question... >Vishwas Manral wrote: >>Besides is there a reason to not have a "type" field in the shim header? Not sure why that would be needed. What would you want to use that for? The type of the original packet is preserved already (with the original frame, inside the shim header). Radia From touch at ISI.EDU Wed Aug 10 06:19:17 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 06:19:17 -0700 Subject: [rbridge] Doubts about Rbridge In-Reply-To: References: Message-ID: <42F9FED5.1090707@isi.edu> Vishwas, Inside the rbridge, for traffic entering the rbridge via ingress/egress, the only switching decisions being made are between rbridge ingress and egress. As a result, the only 'ethertype' that is relevant is the rbridge shim. Inside the rbridge, there is no need for L2-style 'peeking' into L3 headers to do optimizations; that would be done at the ingress to direct traffic to different egresses or multicast trees. Joe Vishwas Manral wrote: > Hi Joe, > > I miss the point regarding the "Type" field not required. "EtherType" field in the Ethernet header is used to tell the type of packet above Ethernet. > > When traversing an rbridge we loose the information of the packet above, because we replace the etherType by the rbridge type. How will we know what is the etherType when a packet inner header (after the shim header) needs to be looked into (L3 switching needs to be done). > > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch > Sent: Tuesday, August 09, 2005 9:54 PM > To: Developing a hybrid router/bridge. > Subject: Re: [rbridge] Doubts about Rbridge > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Vishwas Manral wrote: > >>Hi Radia, >> >>Would "Protocol VLAN's" work with rbridges? With the etherType >>pointing to the Rbridge and not the protocol above I think it would not.\ > > > The different VLANs would need to be identified at the rbridge ingress, > and mapped to different rbridge egress IDs, which would then map to > different forwarding tables accordingly. > > Inside the rbridge, the rbridge forwarding takes over. Keep in mind that > looking inside an rbridge is (and should be) like looking inside a > bridge. Bridges inside the campus would no longer see the protocol vlan > tags or any other vlan tags per se - they'd just see the rbridge tags, > which is all they should see. > > Note that protocol vlans or other vlans can work inside the campus > between other bridges, but aren't really participating in the rbridge > internal forwarding structure. > > >>Besides is there a reason to not have a "type" field in the shim header? > > > The only reason to have it is because it's needed; the only reason to > need it would be if rbridges would forward differently on their basis, > or expect bridges inside the campus to to so. However, as per above, the > rbridge replaces the vlan/protocol ID structure with its own set of > addresses which are sufficient for its forwarding. > > Joe > > >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Vishwas Manral >>Sent: Tuesday, August 09, 2005 10:49 AM >>To: Developing a hybrid router/bridge. >>Subject: [rbridge] Doubts about Rbridge >> >>Hi Radia, >> >>(PS: I am changing the subject line) >>The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break. >> >>A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in. >> >>Maybe I am missing the point altogether. >> >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >>Sent: Monday, August 08, 2005 9:58 PM >>To: Developing a hybrid router/bridge. >>Subject: Re: [rbridge] How many spanning trees? >> >>Re: Vishwas's question about encapsulation hiding the true nature of >>packets from possible intervening >>bridges (since the subject line would be otherwise misleading). >> >>Are all these things written down someplace? I find it frustrating to >>design around undocumented >>proprietary behavior (such as NATs). But anyway... >> >>I'd think firewalling wouldn't be that much of a problem. We wouldn't >>need a basic bridge in the core >>to be doing firewall...that could/should be done by an RBridge. Except >>if there were a basic bridge between >>the endnodes and the first RBridge, which is a natural place to >>put a firewall---then the basic bridge would see packets exactly as >>today and >>be able to do the same firewalling with no problem. >> >>As for IGMP...it would be the RBridges doing the IGMP snooping. For a >>basic bridge in the >>core, it would indeed not recognize an IGMP packet, but that's the >>behavior we want. It would >>just think it was forwarding vanilla multicast...it would be the >>RBridges deciding what IP multicast >>packets should be forwarded across which links, and intervening bridges >>should just forward. >> >>Can think of any other bridge idiosyncrasies we should think about? >> >>Thanks, >> >>Radia >> >>Vishwas Manral wrote: >> >> >> >>>Hi Radia, >>> >>>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. >>> >>>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly. >>> >>>I know of existing switches which do both of the above. Do let me know where I am missing the point? >>> >>>Thanks, >>>Vishwas >>>-----Original Message----- >>>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman >>>Sent: Tuesday, June 28, 2005 10:14 PM >>>To: Developing a hybrid router/bridge. >>>Subject: Re: [rbridge] How many spanning trees? >>> >>>You are right that paths will not be the same from A to B as from B to A >>>with an A-rooted tree (towards B) >>>vs a B-rooted tree (towards A), at least if we do a straightforward >>>calculation of spanning trees. I think trying >>>to accomplish symmetric routes might >>>require source/destination pair route computation. So hopefully we won't >>>require symmetric routes. >>> >>>Radia >>> >>> >>> >>>Guillermo Ib??ez wrote: >>> >>> >>> >>> >>> >>>>Guillermo Ib??ez wrote: >>>>This is my feedback on the "how many spanning trees" issue. >>>> >>>> >>>>Radia Perlman wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>It would be nice to get opinions on remaining issues, and I think each >>>>>issue should be in a different email thread, so I'm starting one. >>>>> >>>>>How many spanning >>>>>trees should RBridges compute? Given the link state database, they can >>>>>calculate >>>>>as many as we want without further protocol messages. The possibilities are: >>>>> >>>>>a) one spanning tree: This is simplest, obviously. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>The poor performance in the core for multicast is an important argument >>>>against it. Other possibilities should exist, at least as an option. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that >>>>>RBridge is attached to. To calculate a spanning tree for VLAN A, the >>>>>RBridges >>>>>(all of them...not just those attached to VLAN A) choose the RBridge, >>>>>RA, that >>>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is >>>>>calculated >>>>>with RA as root. THat spanning tree is pruned so that only branches that >>>>>reach >>>>>other VLAN A links survive. >>>>> >>>>>Why bother: If only a few links are VLAN A, then this allows more >>>>>optimal delivery >>>>>of multicast/unknown frames within the VLAN A broadcast domain. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>It seems that with this implementation compatibility (interoperability) >>>>with bridges running Multiple Spanning Tree Protocol (MSTP) is >>>>excluded. If bridges running MSTP exist in the campus network, they >>>>must be confined in one or several MST regions with their specific >>>>VLAN-to-spanning tree instance mappings and, like happens with STP or >>>>RSTP, the trees will end at the region boundary with an rbridge. This >>>>means that there could coexist "regions" running MSTP with their own >>>>VLANs and multiple spanning trees inside the region, these regions >>>>inserted between rbridges that use another type (range or IDs) of VLANs. >>>>My understanding is then that the only VLANs capable of traversing the >>>>campus end-to-end would be the VLANs handled by Rbridges, as the other >>>>would be stopped by Rbridges if they are not known by them. >>>> >>>>c) one per RBridge >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this >>>>>allows >>>>>optimal delivery from source to the receivers of a particular multicast. >>>>> >>>>>Another reason is that it minimizes out of order delivery of packets in the >>>>>case when S it talking to D, and initially D is unknown by the RBridges >>>>>and packets >>>>>have to be sent over a spanning tree rather than on the shortest path >>>>> >>>>> >>>>> >>>>> >>>> >>>>>from S to D. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>One tree per bridge is very efficient together with IGMP snooping, >>>>assuming a core of rbridges. The plus point is that in this case the >>>>multiple trees can also perform routing of unicast traffic, if used >>>>together with the MAC address learning mechanism. In other words: >>>>assuming a core formed by rbridges, using an spaning tree per rbridge >>>>may be enough to perform all the routing via minimum paths. This >>>>requires that the address learning mechanism works over the trees (the >>>>trees coincide in opposite directions A to B and B to A, a tricky issue >>>>when path costs can be equal). So it seems that there is some >>>>overlapping or overkillling using multiple spanning trees for >>>>broadcast/multicast and Dijkstra routing for unicast and simplifications >>>>are possible. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>******** >>>>>I personally don't have strong opinions on this. If only a miniscule >>>>>amount of >>>>>the traffic is multicast/unknown, then one spanning tree seems good >>>>>enough. If >>>>>there's high volume IP-derived multicast applications, then perhaps one per >>>>>RBridge would be worth it. >>>>> >>>>>So I guess I'd be inclined to either just have one spanning tree, or one per >>>>>ingress RBridge. >>>>> >>>>>And if we did one per ingress RBridge, would it be worth computing all >>>>>those trees >>>>>in advance just in case, or only computing one when necessary? >>>>> >>>>>Radia >>>>> >>>>> >>>>> > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/rbridge/attachments/20050810/f0175730/signature-0001.bin From touch at ISI.EDU Wed Aug 10 11:04:54 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 11:04:54 -0700 Subject: [rbridge] Auto-discard notification In-Reply-To: References: Message-ID: <42FA41C6.3060009@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > > Joe, > > What about peeking into the L3 header in order to do load-balancing? > This is common for doing load-balancing for ECMP. As I understand it, > an rbridge can have several equal-cost paths to the egress rbridge > indicated by the frame. Presumably, the same concerns about > re-ordering micro-flows apply here as for IP. > > Alia Agreed; we could use alternate addresses for a single egress, where each used a different path, to achieve this. I.e., the 'peeking' would be at the ingress only, at least that's my impression. We want to avoid peeking elsewhere if possible, especially because it won't occur on conventional bridges inside the campus due to the inclusion of the shim header. The rbridges inside are intended to have enough information from just the shim header to operate, but may also peek ahead, though. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+kHGE5f5cImnZrsRAhTtAJ96wzVQi+CaIqz98g497M0/rzH6aQCfaJEw M9ZM0kMBpxbvl+/O8CJLIWs= =4ayt -----END PGP SIGNATURE----- From akatlas at gmail.com Wed Aug 10 11:20:20 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 11:20:20 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA41C6.3060009@isi.edu> References: <42FA41C6.3060009@isi.edu> Message-ID: <6280db5205081011205bb0acc0@mail.gmail.com> On 8/10/05, Joe Touch wrote: > Alia Atlas wrote: > > > > Joe, > > > > What about peeking into the L3 header in order to do load-balancing? > > This is common for doing load-balancing for ECMP. As I understand it, > > an rbridge can have several equal-cost paths to the egress rbridge > > indicated by the frame. Presumably, the same concerns about > > re-ordering micro-flows apply here as for IP. > > > > Alia > > Agreed; we could use alternate addresses for a single egress, where each > used a different path, to achieve this. I.e., the 'peeking' would be at > the ingress only, at least that's my impression. > > We want to avoid peeking elsewhere if possible, especially because it > won't occur on conventional bridges inside the campus due to the > inclusion of the shim header. The rbridges inside are intended to have > enough information from just the shim header to operate, but may also > peek ahead, though. Would a convential bridge have multiple paths to select between? I would be concerned about using alternate addresses; this implies knowledge on the number of different equal-cost paths available at each point in the campus. Possibly the ingress rbridge could compute a hash value that is then forwarded as part of the shim header & is then used as input along the way. For instance, with MPLS, if the packet underneath the MPLS shim header is not IP, then some equipment can do a hash on the label stack for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt). Alia From touch at ISI.EDU Wed Aug 10 13:46:05 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 13:46:05 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081011205bb0acc0@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> Message-ID: <42FA678D.7050101@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch wrote: > >>Alia Atlas wrote: >> >>>Joe, >>> >>>What about peeking into the L3 header in order to do load-balancing? >>>This is common for doing load-balancing for ECMP. As I understand it, >>>an rbridge can have several equal-cost paths to the egress rbridge >>>indicated by the frame. Presumably, the same concerns about >>>re-ordering micro-flows apply here as for IP. >>> >>>Alia >> >>Agreed; we could use alternate addresses for a single egress, where each >>used a different path, to achieve this. I.e., the 'peeking' would be at >>the ingress only, at least that's my impression. >> >>We want to avoid peeking elsewhere if possible, especially because it >>won't occur on conventional bridges inside the campus due to the >>inclusion of the shim header. The rbridges inside are intended to have >>enough information from just the shim header to operate, but may also >>peek ahead, though. > > Would a convential bridge have multiple paths to select between? I would expect not, since it should be using the sole spanning tree. > I would be concerned about using alternate addresses; this implies > knowledge on the number of different equal-cost paths available at > each point in the campus. We can - and probably need to - assign different addresses for each interface on an egress. We could certainly assign different ones if desired, i.e., as aliases. When multiple equal-cost paths exist, the entries can be split out in the forwarding table. The ingress already needs to know which egress rbridge to pick; if there are aliases, it can select them on a per-flow basis. This doesn't depend on equal cost paths at every decision point in the campus, at least AFAICT. > Possibly the ingress rbridge could compute a hash value that is then > forwarded as part of the shim header & is then used as input along the > way. For instance, with MPLS, if the packet underneath the MPLS shim > header is not IP, then some equipment can do a hash on the label stack > for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt). > > Alia- The hard part is what the hash would depend on - IP address, transport port, etc.? We might consider that, though, if it's supported for MPLS. Or we can have the rbridges peek at the headers beyond the shim; as you note, it won't matter for conventional bridges inside the rbridge (which wouldn't look even inside the shim) anyway. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+meNE5f5cImnZrsRAqemAJ9w8T7EbekhnH7qBqfSFyBpCpXn9QCfXNnK 85tElHKwgjDWhjlf36FXSrw= =mgK3 -----END PGP SIGNATURE----- From akatlas at gmail.com Wed Aug 10 14:09:18 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 14:09:18 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA678D.7050101@isi.edu> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> Message-ID: <6280db5205081014091509a0c6@mail.gmail.com> On 8/10/05, Joe Touch wrote: > Alia Atlas wrote: > > On 8/10/05, Joe Touch wrote: > > > >>Alia Atlas wrote: > >> > >>>Joe, > >>> > >>>What about peeking into the L3 header in order to do load-balancing? > >>>This is common for doing load-balancing for ECMP. As I understand it, > >>>an rbridge can have several equal-cost paths to the egress rbridge > >>>indicated by the frame. Presumably, the same concerns about > >>>re-ordering micro-flows apply here as for IP. > >>> > >>>Alia > >> > >>Agreed; we could use alternate addresses for a single egress, where each > >>used a different path, to achieve this. I.e., the 'peeking' would be at > >>the ingress only, at least that's my impression. > >> > >>We want to avoid peeking elsewhere if possible, especially because it > >>won't occur on conventional bridges inside the campus due to the > >>inclusion of the shim header. The rbridges inside are intended to have > >>enough information from just the shim header to operate, but may also > >>peek ahead, though. > > > > Would a convential bridge have multiple paths to select between? > > I would expect not, since it should be using the sole spanning tree. So then the question is confined to how does an rbridge do load-balancing. It seems like there are two possibilities that we're discussing. Either the mid-point rbridge needs to be able to peek past the shim header, the encapsulated MAC addresses, and find the IP header, determine if it is an IP header, and then compute some hash on that, or the ingress rbridge needs to do the same and somehow indicate its hash downstream. > > I would be concerned about using alternate addresses; this implies > > knowledge on the number of different equal-cost paths available at > > each point in the campus. > > We can - and probably need to - assign different addresses for each > interface on an egress. We could certainly assign different ones if > desired, i.e., as aliases. When multiple equal-cost paths exist, the > entries can be split out in the forwarding table. The ingress already > needs to know which egress rbridge to pick; if there are aliases, it can > select them on a per-flow basis. Why do we need to assign different addresses for each interface on an egress?? Wouldn't the egress rbridge receive the frame, remove the encapsulation, and then decide which local interface to forward the frame on based upon the remaining frame? I'm confused by your suggestions for the per-path aliases; doesn't that require the the midpoint rbridge know what path is intended for a particular alias? The midpoint rbridge will still receive a frame and need to decide which of the multiple equal-cost paths it needs to be sent upon. Could you clarify with an example? > This doesn't depend on equal cost paths at every decision point in the > campus, at least AFAICT. > > > Possibly the ingress rbridge could compute a hash value that is then > > forwarded as part of the shim header & is then used as input along the > > way. For instance, with MPLS, if the packet underneath the MPLS shim > > header is not IP, then some equipment can do a hash on the label stack > > for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt). > > > > Alia- > > The hard part is what the hash would depend on - IP address, transport > port, etc.? We might consider that, though, if it's supported for MPLS. > Or we can have the rbridges peek at the headers beyond the shim; as you > note, it won't matter for conventional bridges inside the rbridge (which > wouldn't look even inside the shim) anyway. Well, what the hash depends on doesn't necessarily have to be specified. I believe there's a BCP about this for IP forwarding; I believe that recommends using the IP src/dest and UDP/TCP ports (if available). This is generally supported (at least to the IP src/dest level) for IP and for MPLS. I think that isolating the complexity of doing the hash to the ingress rbridge might be preferable. It depends on the forwarding path & how much knowing the ethertype=rbridge & therefore being able to avoid this helps. Alia From touch at ISI.EDU Wed Aug 10 14:20:29 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 14:20:29 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081014091509a0c6@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> Message-ID: <42FA6F9D.2000601@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch wrote: > >>Alia Atlas wrote: >> >>>On 8/10/05, Joe Touch wrote: >>> >>> >>>>Alia Atlas wrote: >>>> >>>> >>>>>Joe, >>>>> >>>>>What about peeking into the L3 header in order to do load-balancing? >>>>>This is common for doing load-balancing for ECMP. As I understand it, >>>>>an rbridge can have several equal-cost paths to the egress rbridge >>>>>indicated by the frame. Presumably, the same concerns about >>>>>re-ordering micro-flows apply here as for IP. >>>>> >>>>>Alia >>>> >>>>Agreed; we could use alternate addresses for a single egress, where each >>>>used a different path, to achieve this. I.e., the 'peeking' would be at >>>>the ingress only, at least that's my impression. >>>> >>>>We want to avoid peeking elsewhere if possible, especially because it >>>>won't occur on conventional bridges inside the campus due to the >>>>inclusion of the shim header. The rbridges inside are intended to have >>>>enough information from just the shim header to operate, but may also >>>>peek ahead, though. >>> >>>Would a convential bridge have multiple paths to select between? >> >>I would expect not, since it should be using the sole spanning tree. > > > So then the question is confined to how does an rbridge do > load-balancing. It seems like there are two possibilities that we're > discussing. Either the mid-point rbridge needs to be able to peek > past the shim header, the encapsulated MAC addresses, and find the IP > header, determine if it is an IP header, and then compute some hash on > that, or the ingress rbridge needs to do the same and somehow indicate > its hash downstream. Yes, those are the two alternatives IMO. >>>I would be concerned about using alternate addresses; this implies >>>knowledge on the number of different equal-cost paths available at >>>each point in the campus. >> >>We can - and probably need to - assign different addresses for each >>interface on an egress. We could certainly assign different ones if >>desired, i.e., as aliases. When multiple equal-cost paths exist, the >>entries can be split out in the forwarding table. The ingress already >>needs to know which egress rbridge to pick; if there are aliases, it can >>select them on a per-flow basis. > > Why do we need to assign different addresses for each interface on an > egress?? Wouldn't the egress rbridge receive the frame, remove the > encapsulation, and then decide which local interface to forward the > frame on based upon the remaining frame? I'm speaking of multiple interfaces on the campus-side of the egress, or aliases to the single interface on the campus-side. The addresses can then used for path differentiation in the routing algorithm. > I'm confused by your suggestions for the per-path aliases; doesn't > that require the the midpoint rbridge know what path is intended for a > particular alias? Yes - that would mean that different aliases would have different paths. That's one version of the solution that could work. > The midpoint rbridge will still receive a frame > and need to decide which of the multiple equal-cost paths it needs to > be sent upon. Could you clarify with an example? I'm expecting that it could have different forwarding entries for the different aliases for the egress. The net effect is to use the egress address as a both the egress and the flow ID. >>This doesn't depend on equal cost paths at every decision point in the >>campus, at least AFAICT. >> >> >>>Possibly the ingress rbridge could compute a hash value that is then >>>forwarded as part of the shim header & is then used as input along the >>>way. For instance, with MPLS, if the packet underneath the MPLS shim >>>header is not IP, then some equipment can do a hash on the label stack >>>for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt). >>> >>>Alia- >> >>The hard part is what the hash would depend on - IP address, transport >>port, etc.? We might consider that, though, if it's supported for MPLS. >>Or we can have the rbridges peek at the headers beyond the shim; as you >>note, it won't matter for conventional bridges inside the rbridge (which >>wouldn't look even inside the shim) anyway. > > Well, what the hash depends on doesn't necessarily have to be > specified. I believe there's a BCP about this for IP forwarding; I > believe that recommends using the IP src/dest and UDP/TCP ports (if > available). This is generally supported (at least to the IP src/dest > level) for IP and for MPLS. > > I think that isolating the complexity of doing the hash to the ingress > rbridge might be preferable. It depends on the forwarding path & how > much knowing the ethertype=rbridge & therefore being able to avoid > this helps. > > Alia And the complexity of the routing algorithm that can separate the aliases at rbridge forwarding tables inside the campus as well. It may be cheaper to just have them peek and keep flows separate themselves. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+m+dE5f5cImnZrsRAiczAJ954GHwZA69WhRtVluIxLjRGtivpACcDNu5 2rnE3taxmfIiqr1MsadfWrE= =3aWa -----END PGP SIGNATURE----- From spencer at mcsr-labs.org Wed Aug 10 14:48:33 2005 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 10 Aug 2005 16:48:33 -0500 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081014091509a0c6@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> Message-ID: <42FA7631.2010101@mcsr-labs.org> Alia Atlas wrote: > > >Well, what the hash depends on doesn't necessarily have to be >specified. I believe there's a BCP about this for IP forwarding; I >believe that recommends using the IP src/dest and UDP/TCP ports (if >available). This is generally supported (at least to the IP src/dest >level) for IP and for MPLS. > >I think that isolating the complexity of doing the hash to the ingress >rbridge might be preferable. It depends on the forwarding path & how >much knowing the ethertype=rbridge & therefore being able to avoid >this helps. > >Alia > I'm still catching up on RBRIDGE, but one point here is that it's a sender's decision which path gets used (based on using one path, selecting based on hashes, or phases of the moon), and the receiver has to be able to accept packets on any path - did I get this right? Thanks, Spencer From touch at ISI.EDU Wed Aug 10 15:03:47 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 15:03:47 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA7631.2010101@mcsr-labs.org> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA7631.2010101@mcsr-labs.org> Message-ID: <42FA79C3.3010801@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Spencer Dawkins wrote: > Alia Atlas wrote: > >> >> >> Well, what the hash depends on doesn't necessarily have to be >> specified. I believe there's a BCP about this for IP forwarding; I >> believe that recommends using the IP src/dest and UDP/TCP ports (if >> available). This is generally supported (at least to the IP src/dest >> level) for IP and for MPLS. >> >> I think that isolating the complexity of doing the hash to the ingress >> rbridge might be preferable. It depends on the forwarding path & how >> much knowing the ethertype=rbridge & therefore being able to avoid >> this helps. >> >> Alia >> > > I'm still catching up on RBRIDGE, but one point here is that it's a > sender's decision which path gets used (based on using one path, > selecting based on hashes, or phases of the moon), and the receiver has > to be able to accept packets on any path - did I get this right? IMO, yes. The only refinement I'd make to your summary is your use of 'the sender': the sender = source switching node i.e., not the E2E source Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+nnDE5f5cImnZrsRAsgZAKCiVoWjavQcnnHjjB6Qn24ylkvFXgCg66l9 nje+jPgPvqdY/ekNruQU+HE= =FQDU -----END PGP SIGNATURE----- From akatlas at gmail.com Wed Aug 10 15:18:09 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 15:18:09 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA6F9D.2000601@isi.edu> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> Message-ID: <6280db520508101518f77382e@mail.gmail.com> On 8/10/05, Joe Touch wrote: > >>>I would be concerned about using alternate addresses; this implies > >>>knowledge on the number of different equal-cost paths available at > >>>each point in the campus. > >> > >>We can - and probably need to - assign different addresses for each > >>interface on an egress. We could certainly assign different ones if > >>desired, i.e., as aliases. When multiple equal-cost paths exist, the > >>entries can be split out in the forwarding table. The ingress already > >>needs to know which egress rbridge to pick; if there are aliases, it can > >>select them on a per-flow basis. > > > > Why do we need to assign different addresses for each interface on an > > egress?? Wouldn't the egress rbridge receive the frame, remove the > > encapsulation, and then decide which local interface to forward the > > frame on based upon the remaining frame? > > I'm speaking of multiple interfaces on the campus-side of the egress, or > aliases to the single interface on the campus-side. The addresses can > then used for path differentiation in the routing algorithm. > > > I'm confused by your suggestions for the per-path aliases; doesn't > > that require the the midpoint rbridge know what path is intended for a > > particular alias? > > Yes - that would mean that different aliases would have different paths. > That's one version of the solution that could work. I guess I am picturing a relatively standard SPF algorithm. All aliases advertised by an rbridge would have the same destination sink-tree. As a midpoint rbridge, how would I decide which path to use for which alias? Do I randomly sprinkle the aliases among the paths? > > The midpoint rbridge will still receive a frame > > and need to decide which of the multiple equal-cost paths it needs to > > be sent upon. Could you clarify with an example? > > I'm expecting that it could have different forwarding entries for the > different aliases for the egress. The net effect is to use the egress > address as a both the egress and the flow ID. Right. What I'm missing is the logic in the SPF algorithm that detemines what the forwarding entries should be. Also, this increases the forwarding entry space necessary as a consequence of the complexity of the campus and the number of aliases... > >>This doesn't depend on equal cost paths at every decision point in the > >>campus, at least AFAICT. > >> > >> > >>>Possibly the ingress rbridge could compute a hash value that is then > >>>forwarded as part of the shim header & is then used as input along the > >>>way. For instance, with MPLS, if the packet underneath the MPLS shim > >>>header is not IP, then some equipment can do a hash on the label stack > >>>for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt). > >>> > >>>Alia- > >> > >>The hard part is what the hash would depend on - IP address, transport > >>port, etc.? We might consider that, though, if it's supported for MPLS. > >>Or we can have the rbridges peek at the headers beyond the shim; as you > >>note, it won't matter for conventional bridges inside the rbridge (which > >>wouldn't look even inside the shim) anyway. > > > > Well, what the hash depends on doesn't necessarily have to be > > specified. I believe there's a BCP about this for IP forwarding; I > > believe that recommends using the IP src/dest and UDP/TCP ports (if > > available). This is generally supported (at least to the IP src/dest > > level) for IP and for MPLS. > > > > I think that isolating the complexity of doing the hash to the ingress > > rbridge might be preferable. It depends on the forwarding path & how > > much knowing the ethertype=rbridge & therefore being able to avoid > > this helps. > > > > Alia > > And the complexity of the routing algorithm that can separate the > aliases at rbridge forwarding tables inside the campus as well. It may > be cheaper to just have them peek and keep flows separate themselves. I agree. I think I'd prefer something based on the hashing; then the question is whether one needs independent hashing or whether there's an advantage to doing it at the ingress. Doing it at the ingress could give a bit of control (maybe some flows don't care about re-ordering) and might limit the required logic to the non-campus facing ports. Alia From akatlas at gmail.com Wed Aug 10 15:20:38 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 15:20:38 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA7631.2010101@mcsr-labs.org> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA7631.2010101@mcsr-labs.org> Message-ID: <6280db52050810152018eeb588@mail.gmail.com> On 8/10/05, Spencer Dawkins wrote: > Alia Atlas wrote: > > > > > > >Well, what the hash depends on doesn't necessarily have to be > >specified. I believe there's a BCP about this for IP forwarding; I > >believe that recommends using the IP src/dest and UDP/TCP ports (if > >available). This is generally supported (at least to the IP src/dest > >level) for IP and for MPLS. > > > >I think that isolating the complexity of doing the hash to the ingress > >rbridge might be preferable. It depends on the forwarding path & how > >much knowing the ethertype=rbridge & therefore being able to avoid > >this helps. > > > >Alia > > > > I'm still catching up on RBRIDGE, but one point here is that it's a > sender's decision which path gets used (based on using one path, > selecting based on hashes, or phases of the moon), and the receiver has > to be able to accept packets on any path - did I get this right? Certainly the receiver has to be able to accept packets on any path. As to the sender determining the path, well, for some flexibility in determining, yes. The sender at least gets to determine the flow (either explicitly by a hash or such or implicitly by including the relevant packet). Alia From touch at ISI.EDU Wed Aug 10 15:29:56 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 15:29:56 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db520508101518f77382e@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> Message-ID: <42FA7FE4.9030500@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch wrote: > > >>>>>I would be concerned about using alternate addresses; this implies >>>>>knowledge on the number of different equal-cost paths available at >>>>>each point in the campus. >>>> >>>>We can - and probably need to - assign different addresses for each >>>>interface on an egress. We could certainly assign different ones if >>>>desired, i.e., as aliases. When multiple equal-cost paths exist, the >>>>entries can be split out in the forwarding table. The ingress already >>>>needs to know which egress rbridge to pick; if there are aliases, it can >>>>select them on a per-flow basis. >>> >>>Why do we need to assign different addresses for each interface on an >>>egress?? Wouldn't the egress rbridge receive the frame, remove the >>>encapsulation, and then decide which local interface to forward the >>>frame on based upon the remaining frame? >> >>I'm speaking of multiple interfaces on the campus-side of the egress, or >>aliases to the single interface on the campus-side. The addresses can >>then used for path differentiation in the routing algorithm. >> >> >>>I'm confused by your suggestions for the per-path aliases; doesn't >>>that require the the midpoint rbridge know what path is intended for a >>>particular alias? >> >>Yes - that would mean that different aliases would have different paths. >>That's one version of the solution that could work. > > I guess I am picturing a relatively standard SPF algorithm. All > aliases advertised by an rbridge would have the same destination > sink-tree. But they ought to have different next-hops at some point inside the campus, or there wouldn't be alternate paths. The different next-hops show up as different forwarding entries. > As a midpoint rbridge, how would I decide which path to > use for which alias? Do I randomly sprinkle the aliases among the > paths? If you have only one outgoing nexthop, both alises would forward there and there would be no multipath. If you have multiple next-hops, you would assign one to each of the aliases and enter both into your forwarding table. >>>The midpoint rbridge will still receive a frame >>>and need to decide which of the multiple equal-cost paths it needs to >>>be sent upon. Could you clarify with an example? >> >>I'm expecting that it could have different forwarding entries for the >>different aliases for the egress. The net effect is to use the egress >>address as a both the egress and the flow ID. > > Right. What I'm missing is the logic in the SPF algorithm that > detemines what the forwarding entries should be. Also, this increases > the forwarding entry space necessary as a consequence of the > complexity of the campus and the number of aliases... Yes, but the complexity is there anyway. Either way there needs to be one entry per egress/path pair, i.e., for multiple nexthops to an egress, there need to be multiple entries anyway. >>>>This doesn't depend on equal cost paths at every decision point in the >>>>campus, at least AFAICT. >>>> >>>> >>>> >>>>>Possibly the ingress rbridge could compute a hash value that is then >>>>>forwarded as part of the shim header & is then used as input along the >>>>>way. For instance, with MPLS, if the packet underneath the MPLS shim >>>>>header is not IP, then some equipment can do a hash on the label stack >>>>>for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt). >>>>> >>>>>Alia- >>>> >>>>The hard part is what the hash would depend on - IP address, transport >>>>port, etc.? We might consider that, though, if it's supported for MPLS. >>>>Or we can have the rbridges peek at the headers beyond the shim; as you >>>>note, it won't matter for conventional bridges inside the rbridge (which >>>>wouldn't look even inside the shim) anyway. >>> >>>Well, what the hash depends on doesn't necessarily have to be >>>specified. I believe there's a BCP about this for IP forwarding; I >>>believe that recommends using the IP src/dest and UDP/TCP ports (if >>>available). This is generally supported (at least to the IP src/dest >>>level) for IP and for MPLS. >>> >>>I think that isolating the complexity of doing the hash to the ingress >>>rbridge might be preferable. It depends on the forwarding path & how >>>much knowing the ethertype=rbridge & therefore being able to avoid >>>this helps. >>> >>>Alia >> >>And the complexity of the routing algorithm that can separate the >>aliases at rbridge forwarding tables inside the campus as well. It may >>be cheaper to just have them peek and keep flows separate themselves. > > I agree. I think I'd prefer something based on the hashing; then the > question is whether one needs independent hashing or whether there's > an advantage to doing it at the ingress. Doing it at the ingress > could give a bit of control (maybe some flows don't care about > re-ordering) and might limit the required logic to the non-campus > facing ports. It also makes some of the interior rbridge logic simpler; note that the ingress/egress complexity is different than the interior rbridge complexity already. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+n/kE5f5cImnZrsRAmwbAKCFQDCQpY75XhYEZrdZH5l1pxGbOwCgwMrc +EsRZOfAnnBPld2EqlKY/oU= =JMT9 -----END PGP SIGNATURE----- From akatlas at gmail.com Wed Aug 10 15:43:34 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 15:43:34 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA7FE4.9030500@isi.edu> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> Message-ID: <6280db52050810154377cb464b@mail.gmail.com> On 8/10/05, Joe Touch wrote: > > I guess I am picturing a relatively standard SPF algorithm. All > > aliases advertised by an rbridge would have the same destination > > sink-tree. > > But they ought to have different next-hops at some point inside the > campus, or there wouldn't be alternate paths. The different next-hops > show up as different forwarding entries. The sink-tree looks the same for all aliases. It's not really quite a tree, because an rbridge can be connected by multiple links (those being the ecmp points). > > As a midpoint rbridge, how would I decide which path to > > use for which alias? Do I randomly sprinkle the aliases among the > > paths? > > If you have only one outgoing nexthop, both alises would forward there > and there would be no multipath. If you have multiple next-hops, you > would assign one to each of the aliases and enter both into your > forwarding table. This seems to me to require storing some state about the assignment of next-hops to aliases for when new aliases are learned and when the topology changes. I agree that it is possible, but it seems somewhat messy to me. > > Right. What I'm missing is the logic in the SPF algorithm that > > detemines what the forwarding entries should be. Also, this increases > > the forwarding entry space necessary as a consequence of the > > complexity of the campus and the number of aliases... > > Yes, but the complexity is there anyway. Either way there needs to be > one entry per egress/path pair, i.e., for multiple nexthops to an > egress, there need to be multiple entries anyway. The number of aliases isn't tuned to the different number of next-hops at a particular midpoint rbridge. Also, there's a difference between increasing the addresses known and the size of the resulting forwarding result. One grows your look-up structure while the other is merely more memory. Also, the former requires the resources from the whole campus. In the latter case, each rbridge can make decisions about what degree and number of ecmp next-hops to support. > > I agree. I think I'd prefer something based on the hashing; then the > > question is whether one needs independent hashing or whether there's > > an advantage to doing it at the ingress. Doing it at the ingress > > could give a bit of control (maybe some flows don't care about > > re-ordering) and might limit the required logic to the non-campus > > facing ports. > > It also makes some of the interior rbridge logic simpler; note that the > ingress/egress complexity is different than the interior rbridge > complexity already. Ok. Did we just converge? :-) Alia From touch at ISI.EDU Wed Aug 10 15:50:13 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 15:50:13 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db52050810154377cb464b@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> Message-ID: <42FA84A5.5090108@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: ... >>>I agree. I think I'd prefer something based on the hashing; then the >>>question is whether one needs independent hashing or whether there's >>>an advantage to doing it at the ingress. Doing it at the ingress >>>could give a bit of control (maybe some flows don't care about >>>re-ordering) and might limit the required logic to the non-campus >>>facing ports. >> >>It also makes some of the interior rbridge logic simpler; note that the >>ingress/egress complexity is different than the interior rbridge >>complexity already. > > Ok. Did we just converge? :-) > > Alia Subject to "this is an optimization", I think so. But since it's an optimization, I haven't given it very deep thought. I was hoping the interior of the system would do 'multipath routing to an egress' the same way that IP networks can/do. Which is why peeking inside the IP header at interior rbridges might be more appropriate, come to think of it. But I don't have enough experience with that - it might be useful for others with multipath routing experience to chime in. IMO, the goal is to reuse existing solutions as much as possible here... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+oSlE5f5cImnZrsRAk8RAKCi2fE7W94qjIJRSq1tTYNJM6RsrgCfQA71 JffNKkGozBWpAIYsbD6meQQ= =/pw4 -----END PGP SIGNATURE----- From akatlas at gmail.com Wed Aug 10 16:01:54 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 16:01:54 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA84A5.5090108@isi.edu> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> Message-ID: <6280db520508101601ef1bd79@mail.gmail.com> On 8/10/05, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Alia Atlas wrote: > ... > >>>I agree. I think I'd prefer something based on the hashing; then the > >>>question is whether one needs independent hashing or whether there's > >>>an advantage to doing it at the ingress. Doing it at the ingress > >>>could give a bit of control (maybe some flows don't care about > >>>re-ordering) and might limit the required logic to the non-campus > >>>facing ports. > >> > >>It also makes some of the interior rbridge logic simpler; note that the > >>ingress/egress complexity is different than the interior rbridge > >>complexity already. > > > > Ok. Did we just converge? :-) > > > > Alia > > Subject to "this is an optimization", I think so. But since it's an > optimization, I haven't given it very deep thought. Sure :-) > I was hoping the interior of the system would do 'multipath routing to > an egress' the same way that IP networks can/do. Which is why peeking > inside the IP header at interior rbridges might be more appropriate, > come to think of it. But I don't have enough experience with that - it > might be useful for others with multipath routing experience to chime in. I've got a fair amount of router forwarding path experience; I don't have as much on the ethernet bridging side. More comments are always useful :-) > IMO, the goal is to reuse existing solutions as much as possible here... Yes, I agree. The problem is that no hardware is used to digging that far into the packet, as far as I know. In the back of my mind is the following. First, assume that the shim header has the structure of an MPLS shim header. Second, assume that the egress rbridge is represented by an MPLS label. (For now, let's not worry about the label distribution pieces yet or the multicast/broadcast where the ingress rbridge is needed.) Third, what is underneath the shim header is not an IP packet & will not be identified as one. So, for hardware that supports, say, MPLS pseudo-wires, the frame would be forwarded based on a hash of the MPLS label stack. This implies that the ingress rbridge could put a hash as the inner label (under the egress rbridge label) & the good load-balancing could happen. Of course, this assumes that the egress rbridge can pop off the 2 labels and that the inner label isn't actually ever used for forwarding, but that seems somewhat reasonable to me. Thoughts? Alia From touch at ISI.EDU Wed Aug 10 16:10:51 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 10 Aug 2005 16:10:51 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db520508101601ef1bd79@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> Message-ID: <42FA897B.9060400@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >> >> >>Alia Atlas wrote: >>... >> >>>>>I agree. I think I'd prefer something based on the hashing; then the >>>>>question is whether one needs independent hashing or whether there's >>>>>an advantage to doing it at the ingress. Doing it at the ingress >>>>>could give a bit of control (maybe some flows don't care about >>>>>re-ordering) and might limit the required logic to the non-campus >>>>>facing ports. >>>> >>>>It also makes some of the interior rbridge logic simpler; note that the >>>>ingress/egress complexity is different than the interior rbridge >>>>complexity already. >>> >>>Ok. Did we just converge? :-) >>> >>>Alia >> >>Subject to "this is an optimization", I think so. But since it's an >>optimization, I haven't given it very deep thought. > > > Sure :-) > > >>I was hoping the interior of the system would do 'multipath routing to >>an egress' the same way that IP networks can/do. Which is why peeking >>inside the IP header at interior rbridges might be more appropriate, >>come to think of it. But I don't have enough experience with that - it >>might be useful for others with multipath routing experience to chime in. > > > I've got a fair amount of router forwarding path experience; I don't > have as much on the ethernet bridging side. More comments are always > useful :-) > > >>IMO, the goal is to reuse existing solutions as much as possible here... > > > Yes, I agree. The problem is that no hardware is used to digging that > far into the packet, as far as I know. > > In the back of my mind is the following. First, assume that the shim > header has the structure of an MPLS shim header. Second, assume that > the egress rbridge is represented by an MPLS label. (For now, let's > not worry about the label distribution pieces yet or the > multicast/broadcast where the ingress rbridge is needed.) > > Third, what is underneath the shim header is not an IP packet & will > not be identified as one. But anything we can't parse we can't assign to a specific flow, unless we send all such things to a single default path. Otherwise those packets will be reordered. > So, for hardware that supports, say, MPLS > pseudo-wires, the frame would be forwarded based on a hash of the MPLS > label stack. This implies that the ingress rbridge could put a hash > as the inner label (under the egress rbridge label) & the good > load-balancing could happen. The only flows you will have a hash for are those that the ingress can parse, i.e., those with an inner IP/transport header. If the ingress can parse them sufficiently to create a hash, then so can the interior rbridge nodes. The only difference is that the interior nodes need to go past the shim header, but that's just an offset. > Of course, this assumes that the egress rbridge can pop off the 2 > labels and that the inner label isn't actually ever used for > forwarding, but that seems somewhat reasonable to me. > > Thoughts? I'm not sure what it buys to do the hash only at the ingress vs. at the interior nodes. Both have the same amount of info. It doesn't seem to hurt anything; it trades edge complexity for interior (which is good) but costs bandwidth by making the shim larger (which is bad). Seems like a toss-up to me... Joe > > Alia -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+ol7E5f5cImnZrsRAhXjAJ9Nlu4xxaJxYpiO+rajs9O8b6pjNACcC8Ob hKc0l/BDyZuKH6gK3gxvLqQ= =E3lT -----END PGP SIGNATURE----- From akatlas at gmail.com Wed Aug 10 16:39:11 2005 From: akatlas at gmail.com (Alia Atlas) Date: Wed, 10 Aug 2005 16:39:11 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FA897B.9060400@isi.edu> References: <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> Message-ID: <6280db5205081016397f9c1774@mail.gmail.com> On 8/10/05, Joe Touch wrote: > >>IMO, the goal is to reuse existing solutions as much as possible here... > > > > > > Yes, I agree. The problem is that no hardware is used to digging that > > far into the packet, as far as I know. > > > > In the back of my mind is the following. First, assume that the shim > > header has the structure of an MPLS shim header. Second, assume that > > the egress rbridge is represented by an MPLS label. (For now, let's > > not worry about the label distribution pieces yet or the > > multicast/broadcast where the ingress rbridge is needed.) > > > > Third, what is underneath the shim header is not an IP packet & will > > not be identified as one. > > But anything we can't parse we can't assign to a specific flow, unless > we send all such things to a single default path. Otherwise those > packets will be reordered. I am assuming that the ingress is capable of doing more parsing. For instance, the ingress gets the frame before encapsulation & can use current peeking technology to look inside it. > > So, for hardware that supports, say, MPLS > > pseudo-wires, the frame would be forwarded based on a hash of the MPLS > > label stack. This implies that the ingress rbridge could put a hash > > as the inner label (under the egress rbridge label) & the good > > load-balancing could happen. > > The only flows you will have a hash for are those that the ingress can > parse, i.e., those with an inner IP/transport header. If the ingress can > parse them sufficiently to create a hash, then so can the interior > rbridge nodes. The only difference is that the interior nodes need to go > past the shim header, but that's just an offset. First, the question is whether one is trading off the interior complexity for the edge. It's certainly possible for the interior to have to dig further down, and maybe that's necessary for the broadcast/multicast, but if it is avoidable, that might be good. Getting past the shim header may or may not be completely trivial. It depends on the forwarding path architecture. For instance, once could store most of the frame & only pass the beginning to the hardware that makes a forwarding decision. > > Of course, this assumes that the egress rbridge can pop off the 2 > > labels and that the inner label isn't actually ever used for > > forwarding, but that seems somewhat reasonable to me. > > > > Thoughts? > > I'm not sure what it buys to do the hash only at the ingress vs. at the > interior nodes. Both have the same amount of info. It doesn't seem to > hurt anything; it trades edge complexity for interior (which is good) > but costs bandwidth by making the shim larger (which is bad). Seems like > a toss-up to me... For bw, we're talking an extra 32 bits. I think of it as more a question of complexity in implementation for the interior nodes & how much functionality can be preserved. Alia From Radia.Perlman at Sun.COM Wed Aug 10 22:43:17 2005 From: Radia.Perlman at Sun.COM (Radia Perlman) Date: Wed, 10 Aug 2005 22:43:17 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081016397f9c1774@mail.gmail.com> References: <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> Message-ID: <42FAE575.6050306@Sun.COM> I'm travelling, so don't have too much time for email, and notice this very long thread. I suspect more people than just me would appreciate if it one of you would summarize the conclusions of this thread so far. In skimming...some comments... traditional bridges and traditional IP routers forward based solely on destination address. However, routers can keep multiple paths to the destination, and choose between them based on some other criteria. One story I sometimes tell is that, fresh out of school, I could throw around queing theory and prove that you'd get better network utilization if you did path-splitting (presumably, round-robin). Then Dave Clark pointed out that this makes life hard for layer 4... packets get arbitrarily out of order, it's hard to measure round trip delay, it's hard to figure out MTU size, etc. So then I switched to advocating, if you keep multiple paths, to deterministically choose the path so that the same flow will always go the same way. I think that's how routers tend to be implemented today...each router can independently do some sort of hash based on source address, perhaps ports, perhaps TOS information, and use the hash to make a selection from the equal (or almost-equal) cost paths. Bridges really can't load-split, unless you do something (like what has been suggested and possibly deployed) of having different spanning trees for different types of packets, where all the bridges know somehow which type of packet, and therefore, which spanning tree, the packet belongs on. MPLS though allows multiple paths to be set up between A and B (where "A" is presumably a router, or something that is MPLS-aware), and allows A to decide which path to send it on. A has complete control. Once it selects the MPLS path, the packet's journey is completely determined. So, I'm not sure whether I'm being helpful here because I'm having trouble understanding this thread (as I said, I need Joe or Alia to summarize), but what I'm saying is that there are two ways of doing path splitting; one where someone close to the source determines the remaining path (which requires something like MPLS), and the other where each router along the way independently chooses among different paths. You *might* be able to have an upstream router add advice to the header for downstream routers to choose which path to use, but if you're going to do that, it seems better to just use MPLS. I might be completely off-base on this thread, in which case ignore my comment, but please, if one of you would be willing to summarize the thread, I and others will be quite grateful. Oh, and if you do, can you make the subject line "Summary 1 of load-balancing bridges" (then if there is another flurry of messages, someone can add a "summary 2" note, with the theory that if a thread has a "summary" note, you can catch up by starting at the most recent "summary" note. Thanks, Radia From Vishwas at sinett.com Wed Aug 10 23:15:43 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Wed, 10 Aug 2005 23:15:43 -0700 Subject: [rbridge] load-balancing rbridges Message-ID: Hi, When we do Link aggregation (LACP), we already to load-balancing between Ethernet links (though this is between about parallel links - which would be one link to STP currently). As Radia said in current implementations, we do it on a flow basis. Load balancing criteria currently used are source address, destination address, and address pairs, TCP, UDP ports and even five-tuple based(there is a default criteria based on layer-2 alone, if for example we have fragments and cannot get the port numbers). Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman Sent: Thursday, August 11, 2005 11:13 AM To: Developing a hybrid router/bridge. Cc: Joe Touch Subject: Re: [rbridge] load-balancing rbridges I'm travelling, so don't have too much time for email, and notice this very long thread. I suspect more people than just me would appreciate if it one of you would summarize the conclusions of this thread so far. In skimming...some comments... traditional bridges and traditional IP routers forward based solely on destination address. However, routers can keep multiple paths to the destination, and choose between them based on some other criteria. One story I sometimes tell is that, fresh out of school, I could throw around queing theory and prove that you'd get better network utilization if you did path-splitting (presumably, round-robin). Then Dave Clark pointed out that this makes life hard for layer 4... packets get arbitrarily out of order, it's hard to measure round trip delay, it's hard to figure out MTU size, etc. So then I switched to advocating, if you keep multiple paths, to deterministically choose the path so that the same flow will always go the same way. I think that's how routers tend to be implemented today...each router can independently do some sort of hash based on source address, perhaps ports, perhaps TOS information, and use the hash to make a selection from the equal (or almost-equal) cost paths. Bridges really can't load-split, unless you do something (like what has been suggested and possibly deployed) of having different spanning trees for different types of packets, where all the bridges know somehow which type of packet, and therefore, which spanning tree, the packet belongs on. MPLS though allows multiple paths to be set up between A and B (where "A" is presumably a router, or something that is MPLS-aware), and allows A to decide which path to send it on. A has complete control. Once it selects the MPLS path, the packet's journey is completely determined. So, I'm not sure whether I'm being helpful here because I'm having trouble understanding this thread (as I said, I need Joe or Alia to summarize), but what I'm saying is that there are two ways of doing path splitting; one where someone close to the source determines the remaining path (which requires something like MPLS), and the other where each router along the way independently chooses among different paths. You *might* be able to have an upstream router add advice to the header for downstream routers to choose which path to use, but if you're going to do that, it seems better to just use MPLS. I might be completely off-base on this thread, in which case ignore my comment, but please, if one of you would be willing to summarize the thread, I and others will be quite grateful. Oh, and if you do, can you make the subject line "Summary 1 of load-balancing bridges" (then if there is another flurry of messages, someone can add a "summary 2" note, with the theory that if a thread has a "summary" note, you can catch up by starting at the most recent "summary" note. Thanks, Radia From mike at linx.net Thu Aug 11 02:28:55 2005 From: mike at linx.net (Mike Hughes) Date: Thu, 11 Aug 2005 10:28:55 +0100 Subject: [rbridge] load balancing rbridges Message-ID: Hi folks, Still catching up on what's been going on with rbridge, and I missed Paris because of Summer hols. As someone who runs a network for where rbridges would be an ideal solution to a raft of architectural nags, I'm starting to follow things with interest. Thinking about load balancing, I think we've already asserted the need to prevent evils like packet re-ordering for a traffic flow across the topology. When running my plain old ethernet campus network (around Docklands in London, for those who don't know), I came across issues (5 years ago) trying to do even the most basic loadsharing across a point-to-point GE link agg. Circuits in a link-agg group would become over-subscribed, while others remained heavily under utilised. This was mostly because vendors were not peeking deeply enough into the frame/packet to create a worthwhile hash. They were often just doing L2 dest, ingress port (aagh!) or L2 src/dest hashing - and variants of this such as partial L2 src/dest or ingress port/L2 dest. In my network, it's a relatively small number of end stations sourcing a large amount of traffic - around 200 stations sourcing over 30G of traffic today - there was a need to look deeper in the packet to make a workable hash, because of the restricted "gene pool" at L2. After enough beating up from myself (and some other IX operators, and probably others elsewhere that I never met), all the larger 10GE switch vendors are now doing better hashing, usually based on the L3/4 header information as well. This often works for them, in their architectures, because it's still only one CAM cycle for them - because of the (unused, in our case) L3 functionality built into the boxes, they are reading the L3 info, but usually doing nothing with it if the box is working L2-only. In short, I'm agreeing with those who say that you need to look inside the payload header to generate the hash for ECMP sharing. This should give you a reasonable balance of traffic, and keep flows running along the same path through the network. That hash should be done by the ingress rbridge, and not touched by the intermediate nodes in the topology, unless there is a topology change while the frame is transiting the network. I think you've got to "peek" down into the payload, because of the likelihood of a limited gene pool at the L2 MAC and rbridge MAC/shim layers. Thanks, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From riw at cisco.com Thu Aug 11 08:22:36 2005 From: riw at cisco.com (Russ White) Date: Thu, 11 Aug 2005 11:22:36 -0400 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081014091509a0c6@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> Message-ID: <42FB6D3C.6090607@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So then the question is confined to how does an rbridge do > load-balancing. It seems like there are two possibilities that we're > discussing. Either the mid-point rbridge needs to be able to peek > past the shim header, the encapsulated MAC addresses, and find the IP > header, determine if it is an IP header, and then compute some hash on > that, or the ingress rbridge needs to do the same and somehow indicate > its hash downstream. Okay, I hate to do this, but I think we need to back up a bit, and make certain we understand the problems and complexities here. :-) Suppose we have this: A---B---C---D---(destination) +---E---+ Here, we have two different paths from the entry rbridge to the exit rbridge. It's easy enough for B to compute two different paths to D, and load share between those two paths--in fact, it doesn't much matter how B goes about doing this, in terms of flow, etc, unless we want to worry about out of order packets (which we might). This is a completely different problem from this: A---B---C---+ | +--(destination D---+ Which is that there are two paths to the destination, but B isn't aware of this. It seems like the solution proposed is for A to build a hash and include it in the shim header, so that B will forward some amount of traffic over the link to C, and some amount to D, load sharing the traffic. This seems like it's not really needed (?), since A is actually going to be able to encap the traffic to C or D directly, so A could just change the destination shim destination in the header on every other packet (or based on flows) so the traffic takes different paths through B to reach the destination. Does this make sense, or did I lose it (it's been known to happen, I know....)? :-) I'm not certain we need any additional information in the shim header to handle this (?). We do need to be careful about out of order packets, though, I think. I know most layer 3 switching mechanisms rely on per flow information to channel all information in a single flow along the same path, while channeling other flows along other paths. That's also possible here, if you allow the entry rbridge to peek at the layer 3 information, or even by just sorting out based on destination layer 2 address beyond the exit point, as long as you assume some sort of "correct" or "well ordered" destination address spread on the destination network. :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvttQxEdu7FIVPTkEQLJuQCfWqH5U9Ws0joXK7R/LppCZ9cA0LoAnA5p X/fI4qu87pwvZeXeFPL4zY3/ =0TLt -----END PGP SIGNATURE----- From akatlas at gmail.com Thu Aug 11 11:12:50 2005 From: akatlas at gmail.com (Alia Atlas) Date: Thu, 11 Aug 2005 11:12:50 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <42FAE575.6050306@Sun.COM> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> Message-ID: <6280db52050811111261beb2ef@mail.gmail.com> As per Radia's request, here's my best effort at a summarization. The introduction of rbridges implies that rbridges will need to do load-balancing among equal-cost paths. To avoid reordering at Layer 4, it is very desirable (even necessary) to have the rbridges able to identify the micro-flows. There are 3 possible ways of doing this that were discussed. (1) Each rbridge peeks under the rbridge shim header & encapsulated MAC frame to the (potentially) IP packet underneath. If there is an IP packet, then an identification as to the micro-flow is made and the frame is forwarded based on the micro-flow. Behavior if there isn't an IP packet hasn't been discussed. (2) The ingress rbridge determines the micro-flow and marks the frame with a micro-flow tag in some way. Interior (or midpoint) rbridges can use this tag to identify the micro-flow instead of having to peek underneath the rbridge shim header. This is an optimization of (1) that reduces the complexity of interior rbridges at the cost of additional header size. (3)Each egress rbridge could have a number of aliases. The ingress rbridge identifies a micro-flow & forwards the frame to a particular alias, indicating a path. There are some issues here with number of paths, handling addresses connected to multiple egress rbridges, etc. Option (2) seems promising, but whether it is the correct trade-off versus (1) needs more discussion and input. Please comment. :-) Alia From akatlas at gmail.com Thu Aug 11 11:16:14 2005 From: akatlas at gmail.com (Alia Atlas) Date: Thu, 11 Aug 2005 11:16:14 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FAE575.6050306@Sun.COM> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> Message-ID: <6280db52050811111653f1f02a@mail.gmail.com> On 8/10/05, Radia Perlman wrote: > MPLS though allows multiple paths to be set up between A and B (where > "A" is presumably a router, or something that is MPLS-aware), and > allows A to decide which path to send it on. A has complete control. Once > it selects the MPLS path, the packet's journey is completely determined. MPLS actually has 2 models. In the first LDP model, MPLS behaves just like IP; each router does the load-balancing among the equal-cost paths itself. In the second TE model, the ingress explicitly creates paths (LSPs) and then can load-balance among those paths. > So, I'm not sure whether I'm being helpful here because I'm having trouble > understanding this thread (as I said, I need Joe or Alia to summarize), > but what I'm saying is that there are two ways of doing path splitting; > one where someone close to the source determines the remaining path > (which requires something like MPLS), and the other where each > router along the way independently chooses among different paths. > You *might* be able to have an upstream router add advice to the header > for downstream routers to choose which path to use, but if you're > going to do that, it seems better to just use MPLS. The trick with MPLS TE is that the head-end explicitly sets up the paths ahead of time. Do we want to go there? I didn't think so. Alia From riw at cisco.com Thu Aug 11 11:47:12 2005 From: riw at cisco.com (Russ White) Date: Thu, 11 Aug 2005 14:47:12 -0400 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <6280db52050811111261beb2ef@mail.gmail.com> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> Message-ID: <42FB9D30.6030300@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The introduction of rbridges implies that rbridges will need to do > load-balancing among equal-cost paths. To avoid reordering at Layer > 4, it is very desirable (even necessary) to have the rbridges able to > identify the micro-flows. There are 3 possible ways of doing this > that were discussed. There are actually two different issues with load sharing: A) There are two equal cost paths through the rbridges backbone to any given exit point along the edge). B) A specific destination MAC address is reachable through two exit points, both with equal cost, through the rbridge cloud. A needs to be addressed. B doesn't, as it's an issue the ingress rbridge should be hanlding. > (1) Each rbridge peeks under the rbridge shim header & encapsulated > MAC frame to the (potentially) IP packet underneath. If there is an > IP packet, then an identification as to the micro-flow is made and the > frame is forwarded based on the micro-flow. Behavior if there isn't > an IP packet hasn't been discussed. > > (2) The ingress rbridge determines the micro-flow and marks the frame > with a micro-flow tag in some way. Interior (or midpoint) rbridges > can use this tag to identify the micro-flow instead of having to peek > underneath the rbridge shim header. This is an optimization of (1) > that reduces the complexity of interior rbridges at the cost of > additional header size. 1 is the correct solution, I think. In fact, I would say this is "implementation dependant," and the only language the draft actually needs is something like: If an rbridge loads shares over two different paths to reach a single exit rbridge, it MUST do so in a way that prevents redordering of packets within a flow. This MAY be done by examining a larger part of the header of the packet within the shim header to correctly segregate multiple flows. I think that would about cover it, really. It doesn't matter if every rbridge in the network does the separation in a different way, as long as each one uses the same mechanism consistently. :-) Russ > > (3)Each egress rbridge could have a number of aliases. The ingress > rbridge identifies a micro-flow & forwards the frame to a particular > alias, indicating a path. There are some issues here with number of > paths, handling addresses connected to multiple egress rbridges, etc. > > Option (2) seems promising, but whether it is the correct trade-off > versus (1) needs more discussion and input. Please comment. :-) > > Alia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvudPBEdu7FIVPTkEQIQ8ACg8BKy0m2cgBfXSQvpiS7NEZVfhpcAoMeS iB5gt5zMk+HA5VM0erc0siV0 =DC2c -----END PGP SIGNATURE----- From akatlas at gmail.com Thu Aug 11 11:50:59 2005 From: akatlas at gmail.com (Alia Atlas) Date: Thu, 11 Aug 2005 11:50:59 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FB6D3C.6090607@cisco.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> Message-ID: <6280db5205081111506c19d2bb@mail.gmail.com> Hi Russ, On 8/11/05, Russ White wrote: > Okay, I hate to do this, but I think we need to back up a bit, and make > certain we understand the problems and complexities here. :-) Suppose we > have this: > > > A---B---C---D---(destination) > +---E---+ > > Here, we have two different paths from the entry rbridge to the exit > rbridge. It's easy enough for B to compute two different paths to D, and > load share between those two paths--in fact, it doesn't much matter how > B goes about doing this, in terms of flow, etc, unless we want to worry > about out of order packets (which we might). This is a completely > different problem from this: I think that we do care about out of order packets. > A---B---C---+ > | +--(destination > D---+ > > Which is that there are two paths to the destination, but B isn't aware > of this. It seems like the solution proposed is for A to build a hash > and include it in the shim header, so that B will forward some amount of > traffic over the link to C, and some amount to D, load sharing the > traffic. This seems like it's not really needed (?), since A is actually > going to be able to encap the traffic to C or D directly, so A could > just change the destination shim destination in the header on every > other packet (or based on flows) so the traffic takes different paths > through B to reach the destination. Whether A computes a hash and includes it in the shim header is orthogonal to the two cases that you've described. In the latter case, A must be the ingress rbridge. A will have 2 next-hops; the first will be given an egress rbridge of C and the second will be given an egress rbridge of D. A will load-balance among them. To B, these will look like frames to separate destinations. Incidentally, this second scenario appears to assume that the same MAC address can be connected to multiple rbridges. Is this realistic? I think I can see it for a bridge that is connected to both & has hosts behind the bridge. > Does this make sense, or did I lose it (it's been known to happen, I > know....)? :-) > > I'm not certain we need any additional information in the shim header to > handle this (?). We do need to be careful about out of order packets, > though, I think. I know most layer 3 switching mechanisms rely on per > flow information to channel all information in a single flow along the > same path, while channeling other flows along other paths. That's also > possible here, if you allow the entry rbridge to peek at the layer 3 > information, or even by just sorting out based on destination layer 2 > address beyond the exit point, as long as you assume some sort of > "correct" or "well ordered" destination address spread on the > destination network. It's worrying about the out of order packets that is the issue. The question is whether every rbridge in the path has to peek at the layer 3 information - or whether it can be done once at the ingress & the results noted. I believe that there are three advantages with the latter. First, it reduces the complexity of the behavior requried by the interior. Second, I believe that there is existing hardware that could possibly properly load-balance based on the shim header (if it looked like an MPLS shim), without forwarding path modifications. (This isn't to claim that no hw changes would be necessary for multicast/broadcast...) Third, having the ingress compute the hash opens the possibilities for intelligent hash generation and interaction with applications. For instance, imagine that some flows care about in-order & some don't - or not as much. An ingress rbridge could be configured to recognize the latter and use different hash values, to improve the throughput. Even if the flow does care about mis-ordering, the ingress rbridge could be configured to explicitly ensure that certain flows don't have hash collisions. In other words, one could put more intelligence at the edge to enable smarter behaviors and simplify the interior complexity. Alia From zinin at psg.com Thu Aug 11 11:57:06 2005 From: zinin at psg.com (Alex Zinin) Date: Thu, 11 Aug 2005 11:57:06 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <6280db52050811111261beb2ef@mail.gmail.com> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> Message-ID: <1499440946.20050811115706@psg.com> Alia, When I looked at it a couple of months ago, it seemed possible to hash based on the original src+dst MAC addresses. This makes it L3/4-agnostic and still gives sufficient traffic dispersion. -- Alex http://www.psg.com/~zinin Thursday, August 11, 2005, 11:12:50 AM, Alia Atlas wrote: > As per Radia's request, here's my best effort at a summarization. > The introduction of rbridges implies that rbridges will need to do > load-balancing among equal-cost paths. To avoid reordering at Layer > 4, it is very desirable (even necessary) to have the rbridges able to > identify the micro-flows. There are 3 possible ways of doing this > that were discussed. > (1) Each rbridge peeks under the rbridge shim header & encapsulated > MAC frame to the (potentially) IP packet underneath. If there is an > IP packet, then an identification as to the micro-flow is made and the > frame is forwarded based on the micro-flow. Behavior if there isn't > an IP packet hasn't been discussed. > (2) The ingress rbridge determines the micro-flow and marks the frame > with a micro-flow tag in some way. Interior (or midpoint) rbridges > can use this tag to identify the micro-flow instead of having to peek > underneath the rbridge shim header. This is an optimization of (1) > that reduces the complexity of interior rbridges at the cost of > additional header size. > (3)Each egress rbridge could have a number of aliases. The ingress > rbridge identifies a micro-flow & forwards the frame to a particular > alias, indicating a path. There are some issues here with number of > paths, handling addresses connected to multiple egress rbridges, etc. > Option (2) seems promising, but whether it is the correct trade-off > versus (1) needs more discussion and input. Please comment. :-) > Alia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge From spencer at mcsr-labs.org Thu Aug 11 12:38:19 2005 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 11 Aug 2005 14:38:19 -0500 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081111506c19d2bb@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> Message-ID: <42FBA92B.8000004@mcsr-labs.org> An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/rbridge/attachments/20050811/3552a689/attachment.html From riw at cisco.com Thu Aug 11 12:46:43 2005 From: riw at cisco.com (Russ White) Date: Thu, 11 Aug 2005 15:46:43 -0400 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081111506c19d2bb@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> Message-ID: <42FBAB23.8070605@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think that we do care about out of order packets. Yes, I do, too. > Incidentally, this second scenario appears to assume that the same MAC > address can be connected to multiple rbridges. Is this realistic? I > think I can see it for a bridge that is connected to both & has hosts > behind the bridge. I don't know, I just threw the case up to clarify (I hope). >>I'm not certain we need any additional information in the shim header to >>handle this (?). We do need to be careful about out of order packets, >>though, I think. I know most layer 3 switching mechanisms rely on per >>flow information to channel all information in a single flow along the >>same path, while channeling other flows along other paths. That's also >>possible here, if you allow the entry rbridge to peek at the layer 3 >>information, or even by just sorting out based on destination layer 2 >>address beyond the exit point, as long as you assume some sort of >>"correct" or "well ordered" destination address spread on the >>destination network. > > It's worrying about the out of order packets that is the issue. The > question is whether every rbridge in the path has to peek at the layer > 3 information - or whether it can be done once at the ingress & the > results noted. I believe that there are three advantages with the > latter. > > First, it reduces the complexity of the behavior requried by the > interior. Second, I believe that there is existing hardware that > could possibly properly load-balance based on the shim header (if it > looked like an MPLS shim), without forwarding path modifications. > (This isn't to claim that no hw changes would be necessary for > multicast/broadcast...) > > Third, having the ingress compute the hash opens the possibilities for > intelligent hash generation and interaction with applications. For > instance, imagine that some flows care about in-order & some don't - > or not as much. An ingress rbridge could be configured to recognize > the latter and use different hash values, to improve the throughput. > Even if the flow does care about mis-ordering, the ingress rbridge > could be configured to explicitly ensure that certain flows don't have > hash collisions. > > In other words, one could put more intelligence at the edge to enable > smarter behaviors and simplify the interior complexity. Certainly--but if you put the hash at the ingress side, then you've essentially limited the ability of a specific implementation to hash differently for different load sharing characteristics. For instance, suppose that in one environment, you want to load share based on just the destination mac address, but in others, you might need to go deeper. Do you specify to always go deeper, and always eat the cost at the ingress rbridge, even though different devices might or might not need these capabilities? To give a specific example--if you say you should always load share based on the destination ip address, then what if all the packets are destinted to a single server, from all sorts of different hosts? So, you add the source ip address into the hash, making the hash more expensive at the ingress edge. But now, add a NAT on the destination end, and you have to add in the destination port. Add a NAT on the source end, and you have to add in the source port. At what point does this stop? Or do we just say: "The ingress edge rbridge should compute a 32 bit hash across some locally determined set of fields, and send that in the shim header?" I suppose it's possible to put the field in, and mark it for a specific purpose, but not actually specify how to choose which link to use based on it, or what specific hash to use to fill it in (?). Now, on the other hand, we're concerned about the forwarding asics in these bridges, and whether or not they could handle doiong the hashes locally. I think that depends on the type of equipment we're thinking will actually be playing the part of an rbridge. Most routers today can look at least back to the port numbers to do hashes for load sharing, so the current asics used in routers can do this sort of thing. Does that make it any less of an issue? :-) Russ - -- riw at cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvurMREdu7FIVPTkEQJRIACcDOSohI3mw9dIGGCmbj3+uDRtzk8An1tf Q2eUpqwqag6J0gmbKikEDqy9 =Sh63 -----END PGP SIGNATURE----- From akatlas at gmail.com Thu Aug 11 13:20:15 2005 From: akatlas at gmail.com (Alia Atlas) Date: Thu, 11 Aug 2005 13:20:15 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FBA92B.8000004@mcsr-labs.org> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> <42FBA92B.8000004@mcsr-labs.org> Message-ID: <6280db52050811132055711a18@mail.gmail.com> On 8/11/05, Spencer Dawkins wrote: > Sorry, still synchronizing - what we're talking about is introducing > additional misordering, right? > > I wouldn't ask, but I have gotten sucked into some link layers that try to > deliver in-order, which ALSO tortures TCP because of apparent round-trip > variation while the receiver waits for a retransmission to forward in > order... Yes, just concerned about introducing additional misordering! The other hadn't even occurred to me. Alia From akatlas at gmail.com Thu Aug 11 13:27:25 2005 From: akatlas at gmail.com (Alia Atlas) Date: Thu, 11 Aug 2005 13:27:25 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FBAB23.8070605@cisco.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> <42FBAB23.8070605@cisco.com> Message-ID: <6280db520508111327ba54dac@mail.gmail.com> On 8/11/05, Russ White wrote: > > Or do we just say: "The ingress edge rbridge should compute a 32 bit > hash across some locally determined set of fields, and send that in the > shim header?" I suppose it's possible to put the field in, and mark it > for a specific purpose, but not actually specify how to choose which > link to use based on it, or what specific hash to use to fill it in (?). This is what I was picturing. I.e. the ingress does the intelligent packet-crawling & puts a hash (of whatever size agreed) in the header. Then rbridges could use that hash instead of crawling through the packet. > Now, on the other hand, we're concerned about the forwarding asics in > these bridges, and whether or not they could handle doiong the hashes > locally. I think that depends on the type of equipment we're thinking > will actually be playing the part of an rbridge. Most routers today can > look at least back to the port numbers to do hashes for load sharing, so > the current asics used in routers can do this sort of thing. Does that > make it any less of an issue? Certainly current routers can do it - and, if Alex's suggestion that just considering the original src/dest MAC is enough, they could be enhanced look at that as well. But we're not talking routers - but bridges and they may have different cost points. If we're willing to require new hardware at every hop for processing incoming frames and outgoing frames (within the campus as well as to/from hosts), then it's not an issue. Alia From touch at ISI.EDU Thu Aug 11 13:38:14 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 Aug 2005 13:38:14 -0700 Subject: [rbridge] slides from IETF63 posted to website Message-ID: <42FBB736.6010607@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Available at: http://www.postel.org/rbridge/trill-ietf63 these are linked off the main rbridge site: http://www.postel.org/rbridge Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+7c2E5f5cImnZrsRAovoAJ0b1IajpUg794yRTHdjhilWnX+ujgCeOlpD rpov1regh+nG9vek2ivTYio= =tVnH -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Aug 11 14:36:12 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 Aug 2005 14:36:12 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <42FB9D30.6030300@cisco.com> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <42FB9D30.6030300@cisco.com> Message-ID: <42FBC4CC.5020200@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Russ White wrote: > > >>>The introduction of rbridges implies that rbridges will need to do >>>load-balancing among equal-cost paths. To avoid reordering at Layer >>>4, it is very desirable (even necessary) to have the rbridges able to >>>identify the micro-flows. There are 3 possible ways of doing this >>>that were discussed. > > > There are actually two different issues with load sharing: > > A) There are two equal cost paths through the rbridges backbone to any > given exit point along the edge). > > B) A specific destination MAC address is reachable through two exit > points, both with equal cost, through the rbridge cloud. > > A needs to be addressed. B doesn't, as it's an issue the ingress rbridge > should be hanlding. > > >>>(1) Each rbridge peeks under the rbridge shim header & encapsulated >>>MAC frame to the (potentially) IP packet underneath. If there is an >>>IP packet, then an identification as to the micro-flow is made and the >>>frame is forwarded based on the micro-flow. Behavior if there isn't >>>an IP packet hasn't been discussed. >>> >>>(2) The ingress rbridge determines the micro-flow and marks the frame >>>with a micro-flow tag in some way. Interior (or midpoint) rbridges >>>can use this tag to identify the micro-flow instead of having to peek >>>underneath the rbridge shim header. This is an optimization of (1) >>>that reduces the complexity of interior rbridges at the cost of >>>additional header size. > > > 1 is the correct solution, I think. In fact, I would say this is > "implementation dependant," and the only language the draft actually > needs is something like: > > If an rbridge loads shares over two different paths to reach a single > exit rbridge, it MUST do so in a way that prevents redordering of > packets within a flow. This MAY be done by examining a larger part of > the header of the packet within the shim header to correctly segregate > multiple flows. I actually prefer this solution. It leaves the shim shorter, and I don't see a real need to simplify this part of the operation of the internal rbridges. > I think that would about cover it, really. It doesn't matter if every > rbridge in the network does the separation in a different way, as long > as each one uses the same mechanism consistently. > > :-) > > Russ > > > >>>(3)Each egress rbridge could have a number of aliases. The ingress >>>rbridge identifies a micro-flow & forwards the frame to a particular >>>alias, indicating a path. There are some issues here with number of >>>paths, handling addresses connected to multiple egress rbridges, etc. >>> >>>Option (2) seems promising, but whether it is the correct trade-off >>>versus (1) needs more discussion and input. Please comment. :-) >>> >>>Alia >>>_______________________________________________ >>>rbridge mailing list >>>rbridge at postel.org >>>http://www.postel.org/mailman/listinfo/rbridge > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+8TME5f5cImnZrsRAqEIAKCGWjj2tk3U0qpfdL+yhkmSnhs0SgCgsUUV KpkSCkXscd1esbGaJ1mbo4g= =eWv1 -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Aug 11 14:40:33 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 Aug 2005 14:40:33 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <1499440946.20050811115706@psg.com> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> Message-ID: <42FBC5D1.4090408@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Zinin wrote: > Alia, > > When I looked at it a couple of months ago, it seemed possible to hash > based on the original src+dst MAC addresses. This makes it L3/4-agnostic > and still gives sufficient traffic dispersion. That won't help allow internal dispersion of flows between two hosts, which may be useful to allow higher cross-section bandwidth. I.e., consider a 100mbps flow that goes a---b / \ src--ingres---c d---egress---dst \ / e---f If the links a---b and e---f are needed by other cross-campus traffic, the sum of a---b/e---f may be the only way that the src--dst pair can achieve 100mbps. However, all flows between them will be between the same src/dst MAC. That's when it would be useful to peek into not only the IP, but also transport headers to mux across the pair of paths without reordering within a transport connection. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+8XRE5f5cImnZrsRAvRwAJ0clABywG4kS5rGrsWxw8Tw9SW0twCePVWb YkeE34YJaMSkdEPA690oges= =35PK -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Aug 11 14:43:29 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 Aug 2005 14:43:29 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db5205081111506c19d2bb@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> Message-ID: <42FBC681.4070409@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: ... > >>A---B---C---+ >> | +--(destination >> D---+ >> ... > Incidentally, this second scenario appears to assume that the same MAC > address can be connected to multiple rbridges. Is this realistic? I > think I can see it for a bridge that is connected to both & has hosts > behind the bridge. This doesn't make sense to me either. IMO, the spanning tree on the right side (outside the campus) would dictate that only one of C or D would be considered the egress for the destination. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+8aBE5f5cImnZrsRAtoaAKDgCqJUp/541DhsQwIH2ROlAIy4RwCg4ZF2 xTABw1CPn2xRVg4H0fooRBA= =YzAn -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Aug 11 14:44:41 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 Aug 2005 14:44:41 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <6280db52050811132055711a18@mail.gmail.com> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> <42FBA92B.8000004@mcsr-labs.org> <6280db52050811132055711a18@mail.gmail.com> Message-ID: <42FBC6C9.3020702@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/11/05, Spencer Dawkins wrote: > >> Sorry, still synchronizing - what we're talking about is introducing >>additional misordering, right? >> >> I wouldn't ask, but I have gotten sucked into some link layers that try to >>deliver in-order, which ALSO tortures TCP because of apparent round-trip >>variation while the receiver waits for a retransmission to forward in >>order... > > > Yes, just concerned about introducing additional misordering! The > other hadn't even occurred to me. There are many reasons not to multipath TCP inside a link, if possible: - reordering - inconsistent RTTs - incosistent loss/collision rates - inconsistent BW Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+8bJE5f5cImnZrsRAnl9AJ9cSt9vlGUwiNjEosEJe9xuBt5IMACfZtHg eHW9lr8A2BQql1qkpY4ZklM= =L0/m -----END PGP SIGNATURE----- From sommerfeld at sun.com Thu Aug 11 15:07:45 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Thu, 11 Aug 2005 18:07:45 -0400 Subject: [rbridge] load-balancing rbridges In-Reply-To: <42FBC681.4070409@isi.edu> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> <42FBC681.4070409@isi.edu> Message-ID: <1123798064.14955.133.camel@thunk> On Thu, 2005-08-11 at 17:43, Joe Touch wrote: > > Incidentally, this second scenario appears to assume that the same MAC > > address can be connected to multiple rbridges. Is this realistic? I > > think I can see it for a bridge that is connected to both & has hosts > > behind the bridge. > > This doesn't make sense to me either. IMO, the spanning tree on the > right side (outside the campus) would dictate that only one of C or D > would be considered the egress for the destination. Maybe I'm misunderstanding the topology diagrams but I'd hope that there would be some way for a host to be "multihomed" into an rbridge-based network in a way which provided for load-balancing. (perhaps the host would need to implement a "stub" rbridge?) - Bill From touch at ISI.EDU Thu Aug 11 15:19:54 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 Aug 2005 15:19:54 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: <1123798064.14955.133.camel@thunk> References: <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> <42FBC681.4070409@isi.edu> <1123798064.14955.133.camel@thunk> Message-ID: <42FBCF0A.6050108@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: > On Thu, 2005-08-11 at 17:43, Joe Touch wrote: > >>>Incidentally, this second scenario appears to assume that the same MAC >>>address can be connected to multiple rbridges. Is this realistic? I >>>think I can see it for a bridge that is connected to both & has hosts >>>behind the bridge. >> >>This doesn't make sense to me either. IMO, the spanning tree on the >>right side (outside the campus) would dictate that only one of C or D >>would be considered the egress for the destination. > > Maybe I'm misunderstanding the topology diagrams but I'd hope that there > would be some way for a host to be "multihomed" into an rbridge-based > network in a way which provided for load-balancing. > (perhaps the host would need to implement a "stub" rbridge?) Rbridges provide additional internal bandwidth via multipath routing, but outside the campus they're limited to existing ethernet bridging capabilities. AFAIK, there's no way to multihome a single ethernet MAC on a single L2 subnet to use two different bridges as part of the path - that violates spanning tree (presuming spanning tree, of course). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+88KE5f5cImnZrsRAkqeAJ9EupsRFEYdz0QKQSqgOcz59RMAoQCgpDaP Hpbi/JlOXzR13q9tOyFI5Vg= =UVtg -----END PGP SIGNATURE----- From Vishwas at sinett.com Thu Aug 11 21:13:43 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Thu, 11 Aug 2005 21:13:43 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges Message-ID: Hi, There are two things that need to be considered: - 1. When there are fragments we cannot get the Layer-4 information (flow reordering can happen - unless we keep states). 2. Not all packets may have layer-4 information; some could be applications running over Layer-2/ Layer-3. Currently different switches can use different criteria for doing load balancing. However if the criteria is a tag in the header it becomes easier and more consistent (like flow id). I am not sure if we want to define a criterion for load balancing; we can however have a field in the header for the same (and let the ingress node decide the criteria, which could be configurable). Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Alia Atlas Sent: Thursday, August 11, 2005 11:43 PM To: Radia.Perlman at sun.com; Developing a hybrid router/bridge. Cc: Joe Touch Subject: [rbridge] Summary 1 of load-balancing rbridges As per Radia's request, here's my best effort at a summarization. The introduction of rbridges implies that rbridges will need to do load-balancing among equal-cost paths. To avoid reordering at Layer 4, it is very desirable (even necessary) to have the rbridges able to identify the micro-flows. There are 3 possible ways of doing this that were discussed. (1) Each rbridge peeks under the rbridge shim header & encapsulated MAC frame to the (potentially) IP packet underneath. If there is an IP packet, then an identification as to the micro-flow is made and the frame is forwarded based on the micro-flow. Behavior if there isn't an IP packet hasn't been discussed. (2) The ingress rbridge determines the micro-flow and marks the frame with a micro-flow tag in some way. Interior (or midpoint) rbridges can use this tag to identify the micro-flow instead of having to peek underneath the rbridge shim header. This is an optimization of (1) that reduces the complexity of interior rbridges at the cost of additional header size. (3)Each egress rbridge could have a number of aliases. The ingress rbridge identifies a micro-flow & forwards the frame to a particular alias, indicating a path. There are some issues here with number of paths, handling addresses connected to multiple egress rbridges, etc. Option (2) seems promising, but whether it is the correct trade-off versus (1) needs more discussion and input. Please comment. :-) Alia From Vishwas at sinett.com Thu Aug 11 21:28:16 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Thu, 11 Aug 2005 21:28:16 -0700 Subject: [rbridge] load-balancing rbridges Message-ID: Hi Alia, > If we're willing to require new hardware at every hop for > processing incoming frames and outgoing frames (within the > campus as well as to/from hosts), then it's not an issue. The current hardware (if you mean ASIC's) will not work as desired anyway because of issues I have brought up earlier. A simple thing like VLAN itself is decided based on deeper packet inspection (can be at each hop) and that will break with a new header coming in (mind you a VLAN aware network, need not necessarily be sending VLAN tags). Only when we already have a VLAN tag and no deeper packet inspection is ever required (it is done on most switching ASIC's) will the Rbridge scenario work with existing hardware. Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Alia Atlas Sent: Friday, August 12, 2005 1:57 AM To: Developing a hybrid router/bridge. Cc: Joe Touch Subject: Re: [rbridge] load-balancing rbridges On 8/11/05, Russ White wrote: > > Or do we just say: "The ingress edge rbridge should compute a 32 bit > hash across some locally determined set of fields, and send that in the > shim header?" I suppose it's possible to put the field in, and mark it > for a specific purpose, but not actually specify how to choose which > link to use based on it, or what specific hash to use to fill it in (?). This is what I was picturing. I.e. the ingress does the intelligent packet-crawling & puts a hash (of whatever size agreed) in the header. Then rbridges could use that hash instead of crawling through the packet. > Now, on the other hand, we're concerned about the forwarding asics in > these bridges, and whether or not they could handle doiong the hashes > locally. I think that depends on the type of equipment we're thinking > will actually be playing the part of an rbridge. Most routers today can > look at least back to the port numbers to do hashes for load sharing, so > the current asics used in routers can do this sort of thing. Does that > make it any less of an issue? Certainly current routers can do it - and, if Alex's suggestion that just considering the original src/dest MAC is enough, they could be enhanced look at that as well. But we're not talking routers - but bridges and they may have different cost points. If we're willing to require new hardware at every hop for processing incoming frames and outgoing frames (within the campus as well as to/from hosts), then it's not an issue. Alia From gsankara at cisco.com Fri Aug 12 05:52:19 2005 From: gsankara at cisco.com (Ganesh CS) Date: Fri, 12 Aug 2005 18:22:19 +0530 Subject: [rbridge] questions on optimizing multicast Message-ID: <42FC9B83.1030600@cisco.com> Hi Radia, I have the following questions on optimizing multicast 1. Currently 224.0.0.1 is used to reach all the routers in the local segment and 224.0.0.2 is used to reach all hosts in the local segment. With rbridges will the behaviour be retained ? Because I find it increasingly difficult to accomplish this using Rbridges. Roughly we may have to build '2n' multicast distribution trees for 'n' subnets. Are we going to provide equivalent functionality ? 2. Currently when an IGMP is initiated by a node it will reach all routers in the same subnet. We looking at something similar i.e. till an rbridge is reached kind-of behaviour in case of mixed (rbridge + legacy bridge) environments. Right ? 3. Do we account for the actual distance between rbridges in case of mixed bridge environments before selecting a designated multicast forwarding rbridge for a set of nodes ? 4. On cross-VLAN delivery, there is a issue of multicast scoping vs efficient multicast delivery. If at all we require scoping then we should go for VLAN based delivery and if scoping is not at all important typically for a high volume multicast streams like video streams efficient multicast delivery should be the goal. Is VLAN based scoping really useful in rbridge scenarios ? What are the other mechanisms for scoping that we propose ? One I could see is the ttl based scoping. 5. How do we coexist with IP multicast routing domains ? -Ganesh From jtk at northwestern.edu Fri Aug 12 07:43:55 2005 From: jtk at northwestern.edu (John Kristoff) Date: Fri, 12 Aug 2005 09:43:55 -0500 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <42FBC5D1.4090408@isi.edu> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> Message-ID: <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> On Thu, 11 Aug 2005 14:40:33 -0700 Joe Touch wrote: > That's when it would be useful to peek into not only the IP, but also > transport headers to mux across the pair of paths without reordering > within a transport connection. >From an operational perspective I'd prefer Alex's suggestion to use MAC addresses as the flow hash for load balancing. It seems much simpler and seems to solve most of the problem. Separate tools or other protocols can be used to achieve more perfect load balancing if it is needed. John From mike at linx.net Fri Aug 12 08:29:09 2005 From: mike at linx.net (Mike Hughes) Date: Fri, 12 Aug 2005 16:29:09 +0100 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> Message-ID: <53B74F39D903B10C7A2380A8@Mike_HP.linx.net> --On 12 August 2005 09:43 -0500 John Kristoff wrote: > From an operational perspective I'd prefer Alex's suggestion to use > MAC addresses as the flow hash for load balancing. >From my operational perspective, MAC-based load-balancing just *isn't* good enough, especially if you're dealing with a reasonable volume of pre-aggregated traffic. (I've already sent my gory details, and I know I'm not alone - though willing to accept being in a minority.) > Separate tools or other protocols can be used to achieve more perfect load > balancing if it is needed. If rbridge will be doing MAC-based load-balancing across equal cost paths, and nothing more intelligent than that, then an "on/off" control knob needs to be provided for in the specification. Otherwise, don't do it at all, and leave it to other protocols - if a job is worth doing, let's do it well. Cheers, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From jtk at northwestern.edu Fri Aug 12 10:21:32 2005 From: jtk at northwestern.edu (John Kristoff) Date: Fri, 12 Aug 2005 12:21:32 -0500 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <53B74F39D903B10C7A2380A8@Mike_HP.linx.net> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> <53B74F39D903B10C7A2380A8@Mike_HP.linx.net> Message-ID: <20050812172132.11BA4136C82@aharp.ittns.northwestern.edu> On Fri, 12 Aug 2005 16:29:09 +0100 Mike Hughes wrote: > >From my operational perspective, MAC-based load-balancing just > >*isn't* good > enough, especially if you're dealing with a reasonable volume of > pre-aggregated traffic. (I've already sent my gory details, and I know > I'm not alone - though willing to accept being in a minority.) Fair enough. It just seems to me the added complexity of peeking into upper layers may be problematic, but we live in an increasingly complex network environment these days. I think I could envision similar problems that Joe described in the diagram with MAC-based flow load sharing when having to peek at the upper layers. For instance, call his dst a VPN box. John From akatlas at gmail.com Fri Aug 12 10:38:35 2005 From: akatlas at gmail.com (Alia Atlas) Date: Fri, 12 Aug 2005 10:38:35 -0700 Subject: [rbridge] load-balancing rbridges In-Reply-To: References: Message-ID: <6280db5205081210387b749e12@mail.gmail.com> Hi Vishwas, On 8/11/05, Vishwas Manral wrote: > Hi Alia, > > > If we're willing to require new hardware at every hop for > > processing incoming frames and outgoing frames (within the > > campus as well as to/from hosts), then it's not an issue. > The current hardware (if you mean ASIC's) will not work as desired > anyway because of issues I have brought up earlier. Which ones? I agree that none of this lets bridges handle link aggregation where the bridges & link-aggregate are between two rbridges. > A simple thing like VLAN itself is decided based on deeper packet > inspection (can be at each hop) and that will break with a new header > coming in (mind you a VLAN aware network, need not necessarily be > sending VLAN tags). As I understand it, this is only needed for the multicast/broadcast case, because in the unicast case, the packet is adddressed to the egress rbridge. > Only when we already have a VLAN tag and no deeper packet inspection is > ever required (it is done on most switching ASIC's) will the Rbridge > scenario work with existing hardware. I agree that deep packet inspection is done on most switching ASICs today - but this is will introduce a need to look deeper with some variability. Alia From touch at ISI.EDU Fri Aug 12 10:55:54 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 12 Aug 2005 10:55:54 -0700 Subject: [rbridge] questions on optimizing multicast In-Reply-To: <42FC9B83.1030600@cisco.com> References: <42FC9B83.1030600@cisco.com> Message-ID: <42FCE2AA.1060006@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ganesh CS wrote: > Hi Radia, > I have the following questions on optimizing multicast > > 1. Currently 224.0.0.1 is used to reach all the routers in the local > segment and 224.0.0.2 is used to reach all hosts in the local segment. > With rbridges will the behaviour be retained ? Yes. Note that on an rbridge, like any L2, the default would be that both map to broadcast ;-) > Because I find it > increasingly difficult to accomplish this using Rbridges. Roughly we may > have to build '2n' multicast distribution trees for 'n' subnets. Are we > going to provide equivalent functionality ? There ought to be exactly two such trees for each vlan. I don't see how this applies to subnets unless they're mapped to vlans. > 2. Currently when an IGMP is initiated by a node it will reach all > routers in the same subnet. We looking at something similar i.e. till an > rbridge is reached kind-of behaviour in case of mixed (rbridge + legacy > bridge) environments. Right ? Yes. > 3. Do we account for the actual distance between rbridges in case of > mixed bridge environments before selecting a designated multicast > forwarding rbridge for a set of nodes ? Internally, the rbridge can run any multicast protocol, and use that to make the decision of which rbridge to forward for a set of nodes. > 4. On cross-VLAN delivery, there is a issue of multicast scoping vs > efficient multicast delivery. If at all we require scoping then we > should go for VLAN based delivery and if scoping is not at all important > typically for a high volume multicast streams like video streams > efficient multicast delivery should be the goal. Is VLAN based scoping > really useful in rbridge scenarios ? What are the other mechanisms for > scoping that we propose ? One I could see is the ttl based scoping. Keep in mind that an rbridge campus is a single LAN; AFAIK, there is no scoping inside a single LAN. I > 5. How do we coexist with IP multicast routing domains ? INSIDE rbridges may run multicast routing, but to the outside they look like an L2. I'm not sure how to map your question to that context... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/OKqE5f5cImnZrsRAtN6AJ4yQZOQWYbfjk6SqfMUZ9tHnQKizQCg3eCX VURnjJYmKgTLKRFfIDJNxeo= =7i9f -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Aug 12 14:47:54 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 12 Aug 2005 14:47:54 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: References: Message-ID: <42FD190A.8070100@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vishwas Manral wrote: > Hi, > > There are two things that need to be considered: - > > 1. When there are fragments we cannot get the Layer-4 information (flow > reordering can happen - unless we keep states). That's not new for rbridges. Again, it seems useful not to have rbridges try to solve every problem under the sun, but rather only the ones it creates ;-) > 2. Not all packets may have layer-4 information; some could be > applications running over Layer-2/ Layer-3. > > Currently different switches can use different criteria for doing load > balancing. However if the criteria is a tag in the header it becomes > easier and more consistent (like flow id). That just moves the problem to tag assignment, which may reduce complexity for inner (non ingress/egress) rbridges, but does so at the expense of a larger shim header. It does not matter if different switches use different criteria for load balancing, though - it matters only that each switch is consistent. That's sufficient to avoid reordering throughout. > I am not sure if we want to define a criterion for load balancing; we > can however have a field in the header for the same (and let the ingress > node decide the criteria, which could be configurable). I still do not see the particular utility of reinventing MPLS-ish tags in the shim header; if you want MPLS, you can use that. If not, then let the interior rbridges decide how they want to handle load balancing themselves. None of the peeking we're talking about is extraordinarily complex. Joe > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Alia Atlas > Sent: Thursday, August 11, 2005 11:43 PM > To: Radia.Perlman at sun.com; Developing a hybrid router/bridge. > Cc: Joe Touch > Subject: [rbridge] Summary 1 of load-balancing rbridges > > As per Radia's request, here's my best effort at a summarization. > > The introduction of rbridges implies that rbridges will need to do > load-balancing among equal-cost paths. To avoid reordering at Layer > 4, it is very desirable (even necessary) to have the rbridges able to > identify the micro-flows. There are 3 possible ways of doing this > that were discussed. > > (1) Each rbridge peeks under the rbridge shim header & encapsulated > MAC frame to the (potentially) IP packet underneath. If there is an > IP packet, then an identification as to the micro-flow is made and the > frame is forwarded based on the micro-flow. Behavior if there isn't > an IP packet hasn't been discussed. > > (2) The ingress rbridge determines the micro-flow and marks the frame > with a micro-flow tag in some way. Interior (or midpoint) rbridges > can use this tag to identify the micro-flow instead of having to peek > underneath the rbridge shim header. This is an optimization of (1) > that reduces the complexity of interior rbridges at the cost of > additional header size. > > (3)Each egress rbridge could have a number of aliases. The ingress > rbridge identifies a micro-flow & forwards the frame to a particular > alias, indicating a path. There are some issues here with number of > paths, handling addresses connected to multiple egress rbridges, etc. > > Option (2) seems promising, but whether it is the correct trade-off > versus (1) needs more discussion and input. Please comment. :-) > > Alia > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/RkJE5f5cImnZrsRAg59AKDFePy1mjGYu5IPU8INyxdxKb4eagCgt8lb 2xPCt/DPZV8kjVfQQWJzEJs= =MYR+ -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Aug 12 14:56:09 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 12 Aug 2005 14:56:09 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> Message-ID: <42FD1AF9.2010100@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Kristoff wrote: > On Thu, 11 Aug 2005 14:40:33 -0700 > Joe Touch wrote: > > >>That's when it would be useful to peek into not only the IP, but also >>transport headers to mux across the pair of paths without reordering >>within a transport connection. > > >>From an operational perspective I'd prefer Alex's suggestion to use > MAC addresses as the flow hash for load balancing. It seems much > simpler and seems to solve most of the problem. Separate tools or > other protocols can be used to achieve more perfect load balancing > if it is needed. Load balancing by looking at IP and TCP headers is already common and solves the problem at hand (avoiding reordering within a transport protocol). MAC-based load balancing, besides not helping with the case I cited, also fails for systems with multiple NICs that stripe a single transport across multiple interfaces (e.g., channel bonding). Granted, they're sort of 'asking for it', but it seems OK to use a fairly common technique if it solves this problem too. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/Rr5E5f5cImnZrsRAmvkAKCk3fEhVE1rZFvm7dPwyCuDjoqNUACguk2M 1mGxfA3LGvlJ8+GWTAB2yJI= =Pra0 -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Aug 12 14:59:09 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 12 Aug 2005 14:59:09 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <42FD1AF9.2010100@isi.edu> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> <42FD1AF9.2010100@isi.edu> Message-ID: <42FD1BAD.4070600@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: > > > John Kristoff wrote: > >>>On Thu, 11 Aug 2005 14:40:33 -0700 >>>Joe Touch wrote: >>> >>> >>> >>>>That's when it would be useful to peek into not only the IP, but also >>>>transport headers to mux across the pair of paths without reordering >>>>within a transport connection. >>> >>> >>>>From an operational perspective I'd prefer Alex's suggestion to use >>>MAC addresses as the flow hash for load balancing. It seems much >>>simpler and seems to solve most of the problem. Separate tools or >>>other protocols can be used to achieve more perfect load balancing >>>if it is needed. > > > Load balancing by looking at IP and TCP headers is already common and > solves the problem at hand (avoiding reordering within a transport > protocol). > > MAC-based load balancing, besides not helping with the case I cited, > also fails for systems with multiple NICs that stripe a single transport > across multiple interfaces (e.g., channel bonding). Granted, they're > sort of 'asking for it', but it seems OK to use a fairly common > technique if it solves this problem too. > > Joe PS - one final thought. We don't really need to spec any of this per se, IMO. We can mention that per-MAC or per-transportflow is fine, and that we leave it up to the rbridge implementation to decide which to support. Again, so long as it's consistent within a single rbridge device it need not be coordinated at all. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/RutE5f5cImnZrsRAudFAJwKL3IMpxQCAt/WkQeVyPiXiFAHRwCdGG0w SfZ31FjCoDlRU7Fq5fzZVX8= =0+31 -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Aug 12 15:42:17 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 12 Aug 2005 15:42:17 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <20050812172132.11BA4136C82@aharp.ittns.northwestern.edu> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> <53B74F39D903B10C7A2380A8@Mike_HP.linx.net> <20050812172132.11BA4136C82@aharp.ittns.northwestern.edu> Message-ID: <42FD25C9.6050106@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Kristoff wrote: > On Fri, 12 Aug 2005 16:29:09 +0100 > Mike Hughes wrote: > > >>>From my operational perspective, MAC-based load-balancing just >> >>>*isn't* good >> >>enough, especially if you're dealing with a reasonable volume of >>pre-aggregated traffic. (I've already sent my gory details, and I know >>I'm not alone - though willing to accept being in a minority.) > > > Fair enough. It just seems to me the added complexity of peeking into > upper layers may be problematic, but we live in an increasingly complex > network environment these days. I think I could envision similar > problems that Joe described in the diagram with MAC-based flow load > sharing when having to peek at the upper layers. For instance, call > his dst a VPN box. > > John Yeah - at some level, the aggregation is obfuscated by other layers. The goal is to avoid reordering transport, but if there's no transport visible there's (by definition) nothing you can do. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/SXJE5f5cImnZrsRApE4AKDTbvT2E2NH9Q6btLtaxeL4DKsGPACaAxG4 v9KXO6qEbDh9WAxzIJLgOgM= =gZi2 -----END PGP SIGNATURE----- From Vishwas at sinett.com Sat Aug 13 01:09:34 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Sat, 13 Aug 2005 01:09:34 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges Message-ID: Joe, One small thought. > PS - one final thought. We don't really need to spec any of > this per se, IMO. We can mention that per-MAC or per-transportflow > is fine, and that we leave it up to the rbridge implementation to > decide which to support. Again, so long as it's consistent within a > single rbridge device it need not be coordinated at all. I agree we do not need to put the criteria for load balancing in the spec. It would be ok to discuss it however. In my view it should be configureable. Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch Sent: Saturday, August 13, 2005 3:29 AM To: Joe Touch Cc: Developing a hybrid router/bridge. Subject: Re: [rbridge] Summary 1 of load-balancing rbridges -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: > > > John Kristoff wrote: > >>>On Thu, 11 Aug 2005 14:40:33 -0700 >>>Joe Touch wrote: >>> >>> >>> >>>>That's when it would be useful to peek into not only the IP, but also >>>>transport headers to mux across the pair of paths without reordering >>>>within a transport connection. >>> >>> >>>>From an operational perspective I'd prefer Alex's suggestion to use >>>MAC addresses as the flow hash for load balancing. It seems much >>>simpler and seems to solve most of the problem. Separate tools or >>>other protocols can be used to achieve more perfect load balancing >>>if it is needed. > > > Load balancing by looking at IP and TCP headers is already common and > solves the problem at hand (avoiding reordering within a transport > protocol). > > MAC-based load balancing, besides not helping with the case I cited, > also fails for systems with multiple NICs that stripe a single transport > across multiple interfaces (e.g., channel bonding). Granted, they're > sort of 'asking for it', but it seems OK to use a fairly common > technique if it solves this problem too. > > Joe PS - one final thought. We don't really need to spec any of this per se, IMO. We can mention that per-MAC or per-transportflow is fine, and that we leave it up to the rbridge implementation to decide which to support. Again, so long as it's consistent within a single rbridge device it need not be coordinated at all. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/RutE5f5cImnZrsRAudFAJwKL3IMpxQCAt/WkQeVyPiXiFAHRwCdGG0w SfZ31FjCoDlRU7Fq5fzZVX8= =0+31 -----END PGP SIGNATURE----- _______________________________________________ rbridge mailing list rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge From shane at castlepoint.net Sat Aug 13 03:10:59 2005 From: shane at castlepoint.net (Shane Amante) Date: Sat, 13 Aug 2005 04:10:59 -0600 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <42FD1AF9.2010100@isi.edu> References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> <42FD1AF9.2010100@isi.edu> Message-ID: Joe, On Aug 12, 2005, at 3:56 PM, Joe Touch wrote: [ snip ] > MAC-based load balancing, besides not helping with the case I cited, > also fails for systems with multiple NICs that stripe a single transport > across multiple interfaces (e.g., channel bonding). Granted, they're > sort of 'asking for it', but it seems OK to use a fairly common > technique if it solves this problem too. I was just curious if you could be more specific as to what you're referring to in the above? I'm aware of MLPPP that is used to stripe packets across multiple, underlying component circuits in the bundle. However, I'm not aware of (Ethernet) NIC's and/or protocols that can also provide the same capability on media other than TDM circuit. Could you elaborate on vendors/NIC's, (if such a thing exists and I'm not misunderstanding you)? Thanks, -shane > From touch at ISI.EDU Sat Aug 13 11:14:25 2005 From: touch at ISI.EDU (Joe Touch) Date: Sat, 13 Aug 2005 11:14:25 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: References: <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> <42FA7FE4.9030500@isi.edu> <6280db52050810154377cb464b@mail.gmail.com> <42FA84A5.5090108@isi.edu> <6280db520508101601ef1bd79@mail.gmail.com> <42FA897B.9060400@isi.edu> <6280db5205081016397f9c1774@mail.gmail.com> <42FAE575.6050306@Sun.COM> <6280db52050811111261beb2ef@mail.gmail.com> <1499440946.20050811115706@psg.com> <42FBC5D1.4090408@isi.edu> <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> <42FD1AF9.2010100@isi.edu> Message-ID: <42FE3881.6040104@isi.edu> Shane Amante wrote: > Joe, > > On Aug 12, 2005, at 3:56 PM, Joe Touch wrote: > > [ snip ] > > > MAC-based load balancing, besides not helping with the case I cited, > > also fails for systems with multiple NICs that stripe a single > transport > > across multiple interfaces (e.g., channel bonding). Granted, they're > > sort of 'asking for it', but it seems OK to use a fairly common > > technique if it solves this problem too. > > I was just curious if you could be more specific as to what you're > referring to in the above? I'm aware of MLPPP that is used to stripe > packets across multiple, underlying component circuits in the > bundle. However, I'm not aware of (Ethernet) NIC's and/or protocols > that can also provide the same capability on media other than TDM > circuit. Could you elaborate on vendors/NIC's, (if such a thing > exists and I'm not misunderstanding you)? I'm not aware of vendor-provided solutions that do this, but rather installed configurations that do. Some are in the grid community. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/rbridge/attachments/20050813/9a5d82ee/signature.bin From stephen at dino.dnsalias.com Fri Aug 19 20:03:11 2005 From: stephen at dino.dnsalias.com (Stephen J. Bevan) Date: Fri, 19 Aug 2005 20:03:11 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <42FD190A.8070100@isi.edu> References: <42FD190A.8070100@isi.edu> Message-ID: <17158.40303.329224.208278@localhost.localdomain> Joe Touch writes: > It does not matter if different switches use different criteria for > load balancing, though - it matters only that each switch is > consistent. True, but if one can arrange for the switches to, optionally, use the same criteria then it opens up the possiblity of doing split multi-link trunking (to use Nortel's term for this) in a vendor neutral manner. From touch at ISI.EDU Fri Aug 19 22:33:27 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 19 Aug 2005 22:33:27 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges In-Reply-To: <17158.40303.329224.208278@localhost.localdomain> References: <42FD190A.8070100@isi.edu> <17158.40303.329224.208278@localhost.localdomain> Message-ID: <4306C0A7.6070603@isi.edu> Stephen J. Bevan wrote: > Joe Touch writes: > > It does not matter if different switches use different criteria for > > load balancing, though - it matters only that each switch is > > consistent. > > True, but if one can arrange for the switches to, optionally, use the > same criteria then it opens up the possiblity of doing split > multi-link trunking (to use Nortel's term for this) in a vendor > neutral manner. Wouldn't that happen as the result of a consistent, multi-path routing protocol? I.e., what I'm proposing is that switches MAY use local criteria for balancing or supporting multipath, but MAY also use a coordinated system if they agree to. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/rbridge/attachments/20050819/4f48acf8/signature.bin From erik.nordmark at sun.com Fri Aug 26 16:09:01 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Fri, 26 Aug 2005 16:09:01 -0700 Subject: [rbridge] Doubts about Rbridge In-Reply-To: References: Message-ID: <430FA10D.8050002@sun.com> Vishwas Manral wrote: > Hi Radia, > > (PS: I am changing the subject line) The existing bridges (switches) > already do IGMP snooping, to limit multicast traffic. That scenario > would break. > > A lot of existing layer-2 devices do firewall functionality. Firewall > functionality in the silicon may not work with Rbridges coming in. Sorry for the late response. It seems like there are two places that are interesting to look at for both of these issues: 1. Between the hosts/routers and the first rbridge 2. The path between rbridges At #1, the packets remain unmodified, this any bridge functionality that peeks into higher-layer headers would work just as it does today. So I don't see how anything could break there. At #2, the packets are encapsulated in an rbridge header. Thus any bridges between the rbridges that look for higher level headers will not find them unless they are taught to skip the rbridge headers. (The same issues presumably apply for other encapsulations, be it mac-in-mac, q-in-q, or something else.) At #2 IGMP/MLD snooping might not be critical; assuming that the rbridges do IGMP/MLD snooping the result would be to limit the flooding of multicast packets. Erik From Vishwas at sinett.com Sun Aug 28 21:45:40 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Sun, 28 Aug 2005 21:45:40 -0700 Subject: [rbridge] Summary 1 of load-balancing rbridges Message-ID: Hi Joe, > I still do not see the particular utility of reinventing > MPLS-ish tags in the shim header; if you want MPLS, you can use > that. If not, then let the interior rbridges decide how they want > to handle load balancing themselves. None of the peeking we're > talking about is extraordinarily complex. I think the idea was more like a Flow label in IPv6 and not the MPLS label (which needs to be pre-signaled and is also used for forwarding). That said; I figured in the IPv6 implementation report http://www.ietf.org/IESG/Implementations/ipv6-implementations.txt few implementations support Flow Label (the document unfortunately is not dated). Maybe someone else can clarify if that is right? Thanks, Vishwas > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Alia Atlas > Sent: Thursday, August 11, 2005 11:43 PM > To: Radia.Perlman at sun.com; Developing a hybrid router/bridge. > Cc: Joe Touch > Subject: [rbridge] Summary 1 of load-balancing rbridges > > As per Radia's request, here's my best effort at a summarization. > > The introduction of rbridges implies that rbridges will need to do > load-balancing among equal-cost paths. To avoid reordering at Layer > 4, it is very desirable (even necessary) to have the rbridges able to > identify the micro-flows. There are 3 possible ways of doing this > that were discussed. > > (1) Each rbridge peeks under the rbridge shim header & encapsulated > MAC frame to the (potentially) IP packet underneath. If there is an > IP packet, then an identification as to the micro-flow is made and the > frame is forwarded based on the micro-flow. Behavior if there isn't > an IP packet hasn't been discussed. > > (2) The ingress rbridge determines the micro-flow and marks the frame > with a micro-flow tag in some way. Interior (or midpoint) rbridges > can use this tag to identify the micro-flow instead of having to peek > underneath the rbridge shim header. This is an optimization of (1) > that reduces the complexity of interior rbridges at the cost of > additional header size. > > (3)Each egress rbridge could have a number of aliases. The ingress > rbridge identifies a micro-flow & forwards the frame to a particular > alias, indicating a path. There are some issues here with number of > paths, handling addresses connected to multiple egress rbridges, etc. > > Option (2) seems promising, but whether it is the correct trade-off > versus (1) needs more discussion and input. Please comment. :-) > > Alia > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/RkJE5f5cImnZrsRAg59AKDFePy1mjGYu5IPU8INyxdxKb4eagCgt8lb 2xPCt/DPZV8kjVfQQWJzEJs= =MYR+ -----END PGP SIGNATURE----- From quasarus at gazeta.pl Mon Aug 29 01:48:17 2005 From: quasarus at gazeta.pl (Wojtek Paprowicz) Date: Mon, 29 Aug 2005 10:48:17 +0200 (CEST) Subject: [rbridge] Convergence time Message-ID: <15396086.1125305297383.JavaMail.webadm@ew10> Hi everybody, I was wondering if convergence is a case in RBRIDGE idea. Taking into concideration, that currently RBRIDGEs run ISIS, I think it should be. How do you think should be the timers set in order to achieve results similar to SDH? The default timers will not do the trick. On the other hand, we cannot lower e.g. helloInterval too much. The timers are also crucial for node/link failures and failure recovery times. Be grateful for your opinions. Regards, Wojtek Paprowicz From Vishwas at sinett.com Mon Aug 29 02:23:36 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Mon, 29 Aug 2005 02:23:36 -0700 Subject: [rbridge] Doubts about Rbridge Message-ID: Hi Erik, One part you may have missed out is the action taken as a result of seeing the other header. As the Outer Ethernet Header is changed, Protocol VLAN too may have problems which are based on EtherType. Similarly as Source MAC Address is changed Mac-Based VLAN will not work. Thanks, Vishwas -----Original Message----- From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark Sent: Saturday, August 27, 2005 4:39 AM To: Developing a hybrid router/bridge. Subject: Re: [rbridge] Doubts about Rbridge Vishwas Manral wrote: > Hi Radia, > > (PS: I am changing the subject line) The existing bridges (switches) > already do IGMP snooping, to limit multicast traffic. That scenario > would break. > > A lot of existing layer-2 devices do firewall functionality. Firewall > functionality in the silicon may not work with Rbridges coming in. Sorry for the late response. It seems like there are two places that are interesting to look at for both of these issues: 1. Between the hosts/routers and the first rbridge 2. The path between rbridges At #1, the packets remain unmodified, this any bridge functionality that peeks into higher-layer headers would work just as it does today. So I don't see how anything could break there. At #2, the packets are encapsulated in an rbridge header. Thus any bridges between the rbridges that look for higher level headers will not find them unless they are taught to skip the rbridge headers. (The same issues presumably apply for other encapsulations, be it mac-in-mac, q-in-q, or something else.) At #2 IGMP/MLD snooping might not be critical; assuming that the rbridges do IGMP/MLD snooping the result would be to limit the flooding of multicast packets. Erik From Radia.Perlman at sun.com Mon Aug 29 07:57:38 2005 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 29 Aug 2005 07:57:38 -0700 Subject: [rbridge] Doubts about Rbridge In-Reply-To: References: Message-ID: <43132262.5080002@sun.com> Just like with regular bridges, the first bridge or RBridge will insert the VLAN header into the inner header. So if it's MAC-based, the first bridge or RBridge will do that. Then the outer header is only to carry it between the RBridges. At that point, RBridges only look at VLAN in order to decide whether they can optimize by not forwarding it down a branch of the ingress-RBridge-spanning tree. The inner header is still available for inspection by RBridges. Bridges in the core won't see the VLAN tag, but they don't need to...they are only forwarding in the tiny universe of the link between two adjacent RBridges. And finally, the last RBridge removes the outer header and shim, and the VLAN tag, before forwarding onto the last link. Radia Vishwas Manral wrote: >Hi Erik, > >One part you may have missed out is the action taken as a result of >seeing the other header. > >As the Outer Ethernet Header is changed, Protocol VLAN too may have >problems which are based on EtherType. Similarly as Source MAC Address >is changed Mac-Based VLAN will not work. > >Thanks, >Vishwas >-----Original Message----- >From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On >Behalf Of Erik Nordmark >Sent: Saturday, August 27, 2005 4:39 AM >To: Developing a hybrid router/bridge. >Subject: Re: [rbridge] Doubts about Rbridge > >Vishwas Manral wrote: > > >>Hi Radia, >> >>(PS: I am changing the subject line) The existing bridges (switches) >>already do IGMP snooping, to limit multicast traffic. That scenario >>would break. >> >>A lot of existing layer-2 devices do firewall functionality. Firewall >>functionality in the silicon may not work with Rbridges coming in. >> >> > >Sorry for the late response. > >It seems like there are two places that are interesting to look at for >both of these issues: >1. Between the hosts/routers and the first rbridge >2. The path between rbridges > >At #1, the packets remain unmodified, this any bridge functionality that > >peeks into higher-layer headers would work just as it does today. >So I don't see how anything could break there. > >At #2, the packets are encapsulated in an rbridge header. Thus any >bridges between the rbridges that look for higher level headers will not > >find them unless they are taught to skip the rbridge headers. (The same >issues presumably apply for other encapsulations, be it mac-in-mac, >q-in-q, or something else.) > >At #2 IGMP/MLD snooping might not be critical; assuming that the >rbridges do IGMP/MLD snooping the result would be to limit the flooding >of multicast packets. > > Erik > >_______________________________________________ >rbridge mailing list >rbridge at postel.org >http://www.postel.org/mailman/listinfo/rbridge > > From erik.nordmark at sun.com Wed Aug 31 07:01:46 2005 From: erik.nordmark at sun.com (Erik Nordmark) Date: Wed, 31 Aug 2005 07:01:46 -0700 Subject: [rbridge] draft WG minutes Message-ID: <4315B84A.9030304@sun.com> Any corrections to what was said/discussed/agreed upon? Erik --- TRILL WG Minutes August 4, 2005 Minutes taken by Alia Atlas. Agenda: Deliverables: Erik Nordmark: "Some fairly tight dates on getting at least the problem statement and architecture document. This is something the IETF wants to see. There was a proposed outline sent around that we can share with the list. Requirements for a TRILL-capable routing protocol & select existing protocols. Work with appropriate routing wg on suitability/extensions. Produce a set of TRILL specs for standards track. draft-perlman-rbridge is the start." Russ White: The extensions to the routing protocols is already a work in progress - just not published yet. Erik Nordmark: When that gets published as a draft, will go to the list so people can have a look at it. ==================== Coordination with IEEE 802.1: Donald Eastlake: Quick overview on 802.1 liaison. IEEE 802.1 is custodian of the 802 Architecture & defines what it is. (See presentation slides) Bernard Aboba is the overall liaison but there's plenty of room for more specific liaisons. Paul Congdon: Vice chair for 802.1(??). There is a big difference in IEEE as well & 802.1 operates more informally than many 802 groups. Don't vote on each little thing & operate on consensus. While we do have a formal voting process, we do typically accept comments from people who aren't part of the WG & I've never seen outside comments not processed. 802.1 is much more informal and a relationship with TRILL should be straightforward. My questions is when you talk about the liaison relationship, it wasn't clear what you'd want 802.1 to be doing explicitly. Obviously, we'll have people attending anyway as IETF participants. Donald: First, I want to agree with what you said about 802.1 being more open about comments from outside the WG. In 802.11, which is more formal, if there are technical questions, the chair can submit them as his own. For the question, the liaisons at a minimum would report what was happening & report Paul: Dorothy is the liaison for most of the wireless, but I've been serving as liaison for the 802.1 related work & will continue to do so. Steve Drawbridge(??): One of the co-authors on the new IETF liaison process. Part involves the IAB appointing an individual to look after the liaison. Liaison relationship actually means something in the IETF context. ==================== Problem statement and architecture Erik: Editor for this draft should be here, but person is still TBD. Put this up to encourage people on it. Looking for a volunteer author/editor. (See presentation) Richard Spencer: You put a list of what could be considered requirements. Can you tell us where those requirements have come from? What enterprise customers have said these meet their requirements? Have they said that these are the problems that they want to be solved & this is the solutions? Are there any enterprise customers here that have these problems that need to be solved? Erik: These things have made it into the charter based on people saying they've had these requirements. I think it's hard to pinpoint the origin of all of these requirements. Richard: It seems to me that we have a solution & are looking requirements. Erik: We have a charter saying that the rbridge is a start & we discussed this during the BOF. Richard: Are you intending to create a new market for this solution. Erik: Yes. Whatever it said on the first page, shortest-path frame routing in multi-hop 802 network. Richard: If we don't have requirements, how do we know this is the best solution? Erik: I think this is out of scope. Joe Touch: There are several docs. I've seen WG have as many as 8 or 10 docs that lead up to the solution; shouldn't do that. The doc that we have to date is a combo of a problem statement and architecture. The problem statement should include the applicability. The architecture should also list the requirements. Some of those listed are architectural requirements, not problem statements. Shouldn't be that hard to take a first stab at that. Easier to see it from the docs; it's hard to do that on the fly. Erik: If we can get that clarity, I agree. I'm not sure how we're going to work on moving forward on describing the problem statement and the architecture. Christian Huitema: I really think we need to work on the requirements. When I read these slides, what's missing is the ref to the wireless networks. I don't know if that was deliberate, but it is a large area of campus networks. Erik: Had question in BOF if targeted explicitly at wireless & answer was no, but could be useful there. Christian: I agree but I'm talking about the wireless networks. Taking the differences into account makes it likely that the solution won't be applicable. Erik: Popping up, during the charter discussion, decided that we didn't need a requirements doc first. This is fairly solutions driven from an architecture perspective. Having a solution in the rbridge means that we don't need a year or 2 to write a requirements doc. Christian: Agree not to spend 2 years arguing about requirements first. However, the requirements (or architecture) draft should consider the wireless as well. ?? Jenkins: Share some concerns about the requirements. The problem statement isn't a problem statement that is to be solved. Until I can see that, architecture seems a bit premature. Russ White: The IETF typically doesn't take requirements from customers, but from vendors. The vendors I know (Cisco for one) has customers who are interested. We have people interested in working on this & vendors interested in implementing this so we move ahead. On 802.11, I think that this will be useful there, but it might be good to limit the discussion scope architecture about how this works & then look at the wireless as we know this is coming next & commit to looking at that and working on it, but let's solve what's on the table first. Vach Kompella: Speaking as chair of L2VPN, I don't think that there's enough in the charter that distinguishes this from L2VPN. I think that a requirements doc is more necessary than you imagine & then make that discussion here. We did have a scope discussion about work here versus L2VPN. I agree with Joe that this could be useful. I don't want to get hung up on bureaucracy, but in L2VPN, L3VPN, etc. we have the customers write the requirements - so I disagree with Russ. Of course, we have a smaller set of clueful service providers, so I'm not saying that we need to go find clueful enterprises. There should be some people who will sign on and say that this is a problem & we see the issues. Joe Touch: Usually when you include a problem statement, it's bundled with the applicability. Mark Townsley: Could we focus on the problem statement & applicability & if this isn't sufficient, then we'll think about a requirements doc. They're useful, but not always necessary. Let's focus just on the problem statement & applicability inside that, which might help satisfy Vach's concerns. Joe: It might also help address the question of who wants this problem. Erik: We did have the question about how this compares to L2VPN. We did have this in the charter, but took out. I think it makes sense in explaining this as part of the ??: I think a lot of people are missing the obvious, if we did a survey about how many enterprise customers are in here, well everyone in here are enterprise customers. Erik: But if they're building equipment to serve the SP network, are they thinking of those or of their own networks? It's good b/c this helps clarify some of what I've been missing in terms of what the problem statement and applicability should talk about. (More presentation) Joe Touch: There's a bunch of threats that don't come to mind, such as misconfiguration. There's a lot longer list of things under the "do no harm". Erik: Right, there's a lot of robustness concerns that could be exploited. Joe: Even not considered as attackers but rather accidentally. Erik: Traditionally, we think about active attackers. Joe: In the architecture, go through both active attackers & misconfigurations. Erik: I'm not sure if the security ADs would agree with calling them threats. Joe: Right, but the first do no harm is a lot broader than the text. Alex Zinin: On scalability, one thing to keep in mind is the frequency of updates, such as start of the day when things are coming on-line & hosts moving around. Erik: That would be in the applicability. Alex: Yes, you'd need to define what is the scalability range that you're optimizing for. Erik: I'd like to see this as a concise document? What's missing? Looking for volunteers.. ==================== Requirements on routing protocols Erik: Again, this is a TBD author. Trill will provide a requirements doc for the routing protocols & then select which to use. Any extensions needed to the routing protocol. There's been some work & an ISIS extensions draft is already underway. Want to enable 0-touch, so can operate without manual configuration. (See presentation) ==================== Protocol document: Radia Perlman: (see presentation) How many spanning trees? How to learn endnode information? How to handle multicast - IP multicast - non-IP multicast Vach Kompella: How do you know which VLANs belong to which RBridges? Radia: That would have to be configured. It would be in the link-state protocol. Not just "hi I'm Radia, but also these are my VLANs". Alex Zinin: From my understanding, the bridges that announce their VLAN membership is just the RBridges connected to the end-hosts. Radia: All the RBridges support traffic transport. Alex: So how do you decide where to forward? Radia: Calculate a spanning tree (assume one) & you're not in any VLANs. Look downstream to see which VLANs are connected to the RBridges. (Continuing presentation showing why one might want separate spanning trees per VLAN). Dino: Might want to say what a per-VLAN spanning tree would be used versus a global spanning tree. (More presentation) Erik: A question on the dynamic nature of this, through 802.11x, this might attach to a particular access point. Hosts could move & VLANs might come & go on RBridges. Radia: yeah Alex: One comment on spanning tree calculation. Suggested just selecting the lowest router ID. One problem is that that router might be momentarily unavailable or frequently. Radia: If we're doing a tree per RBridge, not a problem. Alex: Yes, but for a single spanning tree, it would be. The draft has some words for ECMP-tie breakers. You really need to worry about bundles between nodes. Radia: It depends if those links are transparent to the rest of the world. If not, we'd need a deterministic tie-breaker, so would need to include the port ID as well as the router ID. (Second presentation) Michael Smith: Quick question. The recommendation is to still pass the MAC addresses Radia: Yes, but just passing around & not need to store them if not part of the same VLAN. Michael: I was quite encouraged by the second approach where you do the learning. Radia: Yes, this is something which is better suited to discussion on the mailing list. Erik: It would be useful to write up an email to see the pros and cons on the possibilities. Radia: Yes, and if sufficiently long, might be a draft. Alex: Before we start discussing the pros and cons, having the possible solutions fully described would help. (Third presentation) Tim Shepherd: Are we concerned about defending against denial of service attacks? Radia: We certainly could say that there's a certain percentage of traffic that's available to multicast - but that's orthogonal. Tim: But earlier, for unicast, if one hasn't heard of the address, then it is broadcast. Radia: That's the case today... Tim: If this tech allows larger domains without routers, could DoS whole domain... Erik: Would be interesting to understand if people understand with snooping if there are things delivered without the IGMP. ??? Dino: They default to dropping, if IGMP snooping is configured on all switches, if the MAC is IP-derived. Erik: There are 2 different behaviors depending on if the MAC is IP-derived. (presentation continues) Dino: IGMP forwarding doesn't happen for that case. Existing snooping IGMP bridges don't have this problem. Radia: We need to make sure they don't. We haven't written down the design yet, so just need to make sure that we don't break that. It could be that we just copy the design for IGMP snooping bridges, or we may need to do more. Radia: Should we allow cross-VLAN delivery of IP multicast? Alex Zinin: That's a router function; I'd leave it alone. I think we should preserve the functionality that is there. Radia: This is something else we should discuss on the list. Erik: What happens when you have a mixture of bridges and RBridges? What happens when some bridges do IGMP snooping & some don't? Dino??: There's nothing standardized, but MAGMA has something written down talking about how not to break it. Dino??: If the RBridges don't do the IGMP snooping & the existing bridges do, how does that work? Erik: On the cross-VLAN thing, people may deploy VLANs for different reasons. Some may be for security & some may be to limit the broadcast domain. This ???: When we talk about non-IP multicast, we need to consider MPLS multicast. Erik: They're specifying multicast in MPLS, but Alex: As a general response, let's leave MPLS multicast for later. It's not yet a done deal & it won't be as easy as IP multicast. Dino: I think we'll have a struggle between management isolation & optimization. Then, do you want to support both or just make a decision? Alex: We could limit it to L2 as part of this & then some nodes could do it as part of their L3 functionality. ????: Are you considering something like MSDP like multiple spanning trees per VLANs. Radia: If you're doing per-RBridge spanning trees, then don't need for per-VLAN. Then which VLAN it is is only filtering information per port. ????: Assume a bridge that is doing IGMP snooping, how will the bridge in the middle be able to interoperate since we're adding a header. Radia: That's a question. Since this isn't written down, we need to get the design correct. It'd be good if we had people on the list who really understood how IGMP bridge snooping really worked. ????: What about MTU issues? Have we thought about those? Radia: For a few years, I always assumed that adding a few bytes would be fatal, but now they're doing VLAN tags and MAC-in-MAC so apparently it's not a problem. Erik: So at end of the agenda, should we accept this rbridge doc as a WG doc... Are we ready to answer the question? Loa: This doc is actually mentioned as the starting point in the charter, so is there a question. Joe Touch: It might be more productive to offer to start with breaking the document into two pieces. One that looks more like an applicability and one that looks like an architecture... Erik: The only reason to ask the question now is to rename the doc so it's easier to find. Second step is figuring out which docs we need. Paul: It does seem a bit odd to adopt a protocol doc before you even have other docs written or even outlined. It makes sense that it would be a WG doc at some point, but not sure whether the WG will consider other approaches. Erik: The IESG re-wrote it into the charter. The document will definitely evolve; it's a starting point. ?????: What we have here is a doc that we clearly think will be broken up. 2 revs down the road, it'll clearly go away. Sounds to me like at least 3 (apps, arch, protocol). Once those are spun out, then we can talk about adopting them. Vach Kompella: It also seems odd to have this in the charter... You need at least one rev of the charter now, to take this out. --- From Eric.Gray at marconi.com Wed Aug 31 07:51:39 2005 From: Eric.Gray at marconi.com (Gray, Eric) Date: Wed, 31 Aug 2005 10:51:39 -0400 Subject: [rbridge] draft WG minutes Message-ID: <313680C9A886D511A06000204840E1CF0C885E30@whq-msgusr-02.pit.comms.marconi.com> Erik, It's "Steve Trowbridge", not "Drawbridge"... The comment ("??") about "missing the obvious" was me. "Dino" is D. Farinacci (for anyone that does not know him). --> -----Original Message----- --> From: rbridge-bounces at postel.org --> [mailto:rbridge-bounces at postel.org]On --> Behalf Of Erik Nordmark --> Sent: Wednesday, August 31, 2005 10:02 AM --> To: Developing a hybrid router/bridge. --> Subject: [rbridge] draft WG minutes --> --> --> --> Any corrections to what was said/discussed/agreed upon? --> --> Erik --> --> --- --> --> TRILL WG Minutes August 4, 2005 --> --> Minutes taken by Alia Atlas. --> --> Agenda: --> --> Deliverables: --> --> Erik Nordmark: "Some fairly tight dates on getting at least --> the problem --> statement and architecture document. This is something the IETF --> wants to see. There was a proposed outline sent around --> that we can --> share with the list. --> --> Requirements for a TRILL-capable routing protocol & --> select existing --> protocols. Work with appropriate routing wg on --> suitability/extensions. --> --> Produce a set of TRILL specs for standards track. --> draft-perlman-rbridge is the start." --> --> Russ White: The extensions to the routing protocols is --> already a work in --> progress - just not published yet. --> --> Erik Nordmark: When that gets published as a draft, will go to the --> list so people can have a look at it. --> --> ==================== --> Coordination with IEEE 802.1: --> --> Donald Eastlake: Quick overview on 802.1 liaison. IEEE 802.1 is --> custodian of the 802 Architecture & defines what it is. --> (See presentation slides) --> --> Bernard Aboba is the overall liaison but there's --> plenty of room for --> more --> specific liaisons. --> --> Paul Congdon: Vice chair for 802.1(??). There is a big --> difference in --> IEEE as well & 802.1 operates more informally than many 802 groups. --> Don't vote on each little thing & operate on consensus. While we do --> have a formal voting process, we do typically accept comments from --> people who aren't part of the WG & I've never seen outside comments --> not processed. 802.1 is much more informal and a relationship with --> TRILL should be straightforward. My questions is when you --> talk about --> the liaison relationship, it wasn't clear what you'd want --> 802.1 to be --> doing explicitly. Obviously, we'll have people attending anyway as --> IETF participants. --> --> Donald: First, I want to agree with what you said about 802.1 being --> more open about comments from outside the WG. In 802.11, which is --> more formal, if there are technical questions, the chair can submit --> them as his own. For the question, the liaisons at a minimum would --> report what was happening & report --> --> Paul: Dorothy is the liaison for most of the wireless, but --> I've been --> serving as liaison for the 802.1 related work & will --> continue to do so. --> --> Steve Drawbridge(??): One of the co-authors on the new IETF liaison --> process. Part involves the IAB appointing an individual to --> look after --> the liaison. Liaison relationship actually means something --> in the IETF --> context. --> --> ==================== --> Problem statement and architecture --> --> Erik: Editor for this draft should be here, but person is --> still TBD. --> Put this up to encourage people on it. Looking for --> a volunteer --> author/editor. --> --> (See presentation) --> --> Richard Spencer: You put a list of what could be considered --> requirements. Can you tell us where those requirements have come --> from? What enterprise customers have said these meet their --> requirements? Have they said that these are the problems that they --> want to be solved & this is the solutions? Are there any enterprise --> customers here that have these problems that need to be solved? --> --> Erik: These things have made it into the charter based on people --> saying they've had these requirements. I think it's hard --> to pinpoint --> the origin of all of these requirements. --> --> Richard: It seems to me that we have a solution & are looking --> requirements. --> --> Erik: We have a charter saying that the rbridge is a start & we --> discussed this during the BOF. --> --> Richard: Are you intending to create a new market for this --> solution. --> --> Erik: Yes. Whatever it said on the first page, shortest-path frame --> routing in multi-hop 802 network. --> --> Richard: If we don't have requirements, how do we know this is the --> best solution? --> --> Erik: I think this is out of scope. --> --> Joe Touch: There are several docs. I've seen WG have as --> many as 8 or --> 10 docs that lead up to the solution; shouldn't do that. --> The doc that --> we have to date is a combo of a problem statement and architecture. --> The problem statement should include the applicability. The --> architecture should also list the requirements. Some of --> those listed --> are architectural requirements, not problem statements. --> Shouldn't be --> that hard to take a first stab at that. Easier to see it from the --> docs; it's hard to do that on the fly. --> --> Erik: If we can get that clarity, I agree. I'm not sure how we're --> going to work on moving forward on describing the problem statement --> and the architecture. --> --> Christian Huitema: I really think we need to work on the --> requirements. When I read these slides, what's missing is --> the ref to --> the wireless networks. I don't know if that was --> deliberate, but it is --> a large area of campus networks. --> --> Erik: Had question in BOF if targeted explicitly at wireless & --> answer was no, but could be useful there. --> --> Christian: I agree but I'm talking about the wireless networks. --> Taking the differences into account makes it likely that --> the solution --> won't be applicable. --> --> Erik: Popping up, during the charter discussion, decided that we --> didn't need a requirements doc first. This is fairly --> solutions driven --> from an architecture perspective. Having a solution in the rbridge --> means that we don't need a year or 2 to write a requirements doc. --> --> Christian: Agree not to spend 2 years arguing about requirements --> first. However, the requirements (or architecture) draft should --> consider the wireless as well. --> --> ?? Jenkins: Share some concerns about the requirements. --> The problem --> statement isn't a problem statement that is to be solved. --> Until I can --> see that, architecture seems a bit premature. --> --> Russ White: The IETF typically doesn't take requirements from --> customers, but from vendors. The vendors I know (Cisco for one) has --> customers who are interested. We have people interested in --> working on --> this & vendors interested in implementing this so we move ahead. On --> 802.11, I think that this will be useful there, but it might be good --> to limit the discussion scope architecture about how this --> works & then --> look at the wireless as we know this is coming next & commit to --> looking at that and working on it, but let's solve what's --> on the table --> first. --> --> Vach Kompella: Speaking as chair of L2VPN, I don't think --> that there's --> enough in the charter that distinguishes this from L2VPN. I think --> that a requirements doc is more necessary than you imagine --> & then make --> that discussion here. We did have a scope discussion about --> work here --> versus L2VPN. I agree with Joe that this could be useful. I don't --> want to get hung up on bureaucracy, but in L2VPN, L3VPN, --> etc. we have --> the customers write the requirements - so I disagree with Russ. Of --> course, we have a smaller set of clueful service providers, --> so I'm not --> saying that we need to go find clueful enterprises. There should be --> some people who will sign on and say that this is a problem & we see --> the issues. --> --> Joe Touch: Usually when you include a problem statement, --> it's bundled --> with the applicability. --> --> Mark Townsley: Could we focus on the problem statement & --> applicability & if this isn't sufficient, then we'll think about a --> requirements doc. They're useful, but not always necessary. Let's --> focus just on the problem statement & applicability inside --> that, which --> might help satisfy Vach's concerns. --> --> Joe: It might also help address the question of who wants this --> problem. --> --> Erik: We did have the question about how this compares to --> L2VPN. We --> did have this in the charter, but took out. I think it --> makes sense in --> explaining this as part of the --> --> ??: I think a lot of people are missing the obvious, if we did a --> survey about how many enterprise customers are in here, --> well everyone --> in here are enterprise customers. --> --> Erik: But if they're building equipment to serve the SP network, are --> they thinking of those or of their own networks? It's --> good b/c this --> helps clarify some of what I've been missing in terms of what the --> problem statement and applicability should talk about. --> --> (More presentation) --> --> Joe Touch: There's a bunch of threats that don't come to mind, such --> as misconfiguration. There's a lot longer list of things under the --> "do no harm". --> --> Erik: Right, there's a lot of robustness concerns that could be --> exploited. --> --> Joe: Even not considered as attackers but rather accidentally. --> --> Erik: Traditionally, we think about active attackers. --> --> Joe: In the architecture, go through both active attackers & --> misconfigurations. --> --> Erik: I'm not sure if the security ADs would agree with --> calling them --> threats. --> --> Joe: Right, but the first do no harm is a lot broader than the text. --> --> Alex Zinin: On scalability, one thing to keep in mind is --> the frequency of --> updates, such as start of the day when things are coming on-line & --> hosts moving around. --> --> Erik: That would be in the applicability. --> --> Alex: Yes, you'd need to define what is the scalability range that --> you're optimizing for. --> --> Erik: I'd like to see this as a concise document? What's missing? --> Looking for volunteers.. --> --> ==================== --> Requirements on routing protocols --> --> Erik: Again, this is a TBD author. Trill will provide a --> requirements --> doc for the routing protocols & then select which to use. Any --> extensions needed to the routing protocol. There's been --> some work & --> an ISIS extensions draft is already underway. --> --> Want to enable 0-touch, so can operate without manual --> configuration. (See presentation) --> --> ==================== --> Protocol document: --> --> Radia Perlman: (see presentation) --> How many spanning trees? --> --> How to learn endnode information? --> --> How to handle multicast --> - IP multicast --> - non-IP multicast --> --> Vach Kompella: How do you know which VLANs belong to which RBridges? --> --> Radia: That would have to be configured. It would be in the --> link-state protocol. Not just "hi I'm Radia, but also these are my --> VLANs". --> --> Alex Zinin: From my understanding, the bridges that announce their --> VLAN membership is just the RBridges connected to the end-hosts. --> --> Radia: All the RBridges support traffic transport. --> --> Alex: So how do you decide where to forward? --> --> Radia: Calculate a spanning tree (assume one) & you're not in any --> VLANs. Look downstream to see which VLANs are connected to the --> RBridges. (Continuing presentation showing why one might want --> separate spanning trees per VLAN). --> --> Dino: Might want to say what a per-VLAN spanning tree would be used --> versus a global spanning tree. --> --> (More presentation) --> --> Erik: A question on the dynamic nature of this, through --> 802.11x, this --> might attach to a particular access point. Hosts could move & VLANs --> might come & go on RBridges. --> --> Radia: yeah --> --> Alex: One comment on spanning tree calculation. Suggested just --> selecting the lowest router ID. One problem is that that --> router might --> be momentarily unavailable or frequently. --> --> Radia: If we're doing a tree per RBridge, not a problem. --> --> Alex: Yes, but for a single spanning tree, it would be. The draft --> has some words for ECMP-tie breakers. You really need to --> worry about --> bundles between nodes. --> --> Radia: It depends if those links are transparent to the rest of the --> world. If not, we'd need a deterministic tie-breaker, so --> would need to --> include the port ID as well as the router ID. --> --> (Second presentation) --> --> Michael Smith: Quick question. The recommendation is to still pass --> the MAC addresses --> --> Radia: Yes, but just passing around & not need to store them if not --> part of the same VLAN. --> --> Michael: I was quite encouraged by the second approach where you do --> the learning. --> --> Radia: Yes, this is something which is better suited to --> discussion on --> the mailing list. --> --> Erik: It would be useful to write up an email to see the pros and --> cons on the possibilities. --> --> Radia: Yes, and if sufficiently long, might be a draft. --> --> Alex: Before we start discussing the pros and cons, having the --> possible solutions fully described would help. --> --> (Third presentation) --> --> Tim Shepherd: Are we concerned about defending against denial of --> service attacks? --> --> Radia: We certainly could say that there's a certain percentage of --> traffic that's available to multicast - but that's orthogonal. --> --> Tim: But earlier, for unicast, if one hasn't heard of the address, --> then it is broadcast. --> --> Radia: That's the case today... --> --> Tim: If this tech allows larger domains without routers, could DoS --> whole domain... --> --> Erik: Would be interesting to understand if people understand with --> snooping if there are things delivered without the IGMP. ??? --> --> Dino: They default to dropping, if IGMP snooping is --> configured on all --> switches, if the MAC is IP-derived. --> --> Erik: There are 2 different behaviors depending on if the MAC is --> IP-derived. --> --> (presentation continues) --> --> Dino: IGMP forwarding doesn't happen for that case. --> Existing snooping --> IGMP bridges don't have this problem. --> --> Radia: We need to make sure they don't. We haven't written down the --> design yet, so just need to make sure that we don't break that. It --> could be that we just copy the design for IGMP snooping --> bridges, or we --> may need to do more. --> --> Radia: Should we allow cross-VLAN delivery of IP multicast? --> --> Alex Zinin: That's a router function; I'd leave it alone. --> I think we --> should preserve the functionality that is there. --> --> Radia: This is something else we should discuss on the list. --> --> Erik: What happens when you have a mixture of bridges and RBridges? --> What happens when some bridges do IGMP snooping & some don't? --> --> Dino??: There's nothing standardized, but MAGMA has --> something written --> down talking about how not to break it. --> --> Dino??: If the RBridges don't do the IGMP snooping & the --> existing bridges --> do, how does that work? --> --> Erik: On the cross-VLAN thing, people may deploy VLANs for different --> reasons. Some may be for security & some may be to limit the --> broadcast domain. This --> --> ???: When we talk about non-IP multicast, we need to consider MPLS --> multicast. --> --> Erik: They're specifying multicast in MPLS, but --> --> Alex: As a general response, let's leave MPLS multicast for later. --> It's not yet a done deal & it won't be as easy as IP multicast. --> --> Dino: I think we'll have a struggle between management isolation & --> optimization. Then, do you want to support both or just make a --> decision? --> --> Alex: We could limit it to L2 as part of this & then some --> nodes could --> do it as part of their L3 functionality. --> --> ????: Are you considering something like MSDP like --> multiple spanning --> trees per VLANs. --> --> Radia: If you're doing per-RBridge spanning trees, then don't need --> for per-VLAN. Then which VLAN it is is only filtering --> information per --> port. --> --> ????: Assume a bridge that is doing IGMP snooping, how will --> the bridge --> in the middle be able to interoperate since we're adding a header. --> --> Radia: That's a question. Since this isn't written down, --> we need to --> get the design correct. It'd be good if we had people on --> the list who --> really understood how IGMP bridge snooping really worked. --> --> ????: What about MTU issues? Have we thought about those? --> --> Radia: For a few years, I always assumed that adding a few bytes --> would be fatal, but now they're doing VLAN tags and MAC-in-MAC so --> apparently it's not a problem. --> --> Erik: So at end of the agenda, should we accept this --> rbridge doc as a --> WG doc... Are we ready to answer the question? --> --> Loa: This doc is actually mentioned as the starting point in the --> charter, so is there a question. --> --> Joe Touch: It might be more productive to offer to start with --> breaking the document into two pieces. One that looks more like an --> applicability and one that looks like an architecture... --> --> Erik: The only reason to ask the question now is to rename --> the doc so --> it's easier to find. Second step is figuring out which --> docs we need. --> --> Paul: It does seem a bit odd to adopt a protocol doc --> before you even --> have other docs written or even outlined. It makes sense that it --> would be a WG doc at some point, but not sure whether the WG will --> consider other approaches. --> --> Erik: The IESG re-wrote it into the charter. The document will --> definitely evolve; it's a starting point. --> --> ?????: What we have here is a doc that we clearly think will be --> broken up. 2 revs down the road, it'll clearly go away. --> Sounds to me --> like at least 3 (apps, arch, protocol). Once those are --> spun out, then --> we can talk about adopting them. --> --> Vach Kompella: It also seems odd to have this in the --> charter... You --> need at least one rev of the charter now, to take this out. --> --> --- --> _______________________________________________ --> rbridge mailing list --> rbridge at postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> From Vishwas at sinett.com Wed Aug 31 10:02:29 2005 From: Vishwas at sinett.com (Vishwas Manral) Date: Wed, 31 Aug 2005 10:02:29 -0700 Subject: [rbridge] draft WG minutes Message-ID: Hi, ???? is me(Vishwas). Besides "????: Are you considering something like MSDP like multiple spanning trees per VLANs." is MSTP and not MSDP. Thanks, Vishwas ________________________________ From: rbridge-bounces at postel.org on behalf of Erik Nordmark Sent: Wed 8/31/2005 7:01 AM To: Developing a hybrid router/bridge. Subject: [rbridge] draft WG minutes Any corrections to what was said/discussed/agreed upon? Erik --- TRILL WG Minutes August 4, 2005 Minutes taken by Alia Atlas. Agenda: Deliverables: Erik Nordmark: "Some fairly tight dates on getting at least the problem statement and architecture document. This is something the IETF wants to see. There was a proposed outline sent around that we can share with the list. Requirements for a TRILL-capable routing protocol & select existing protocols. Work with appropriate routing wg on suitability/extensions. Produce a set of TRILL specs for standards track. draft-perlman-rbridge is the start." Russ White: The extensions to the routing protocols is already a work in progress - just not published yet. Erik Nordmark: When that gets published as a draft, will go to the list so people can have a look at it. ==================== Coordination with IEEE 802.1: Donald Eastlake: Quick overview on 802.1 liaison. IEEE 802.1 is custodian of the 802 Architecture & defines what it is. (See presentation slides) Bernard Aboba is the overall liaison but there's plenty of room for more specific liaisons. Paul Congdon: Vice chair for 802.1(??). There is a big difference in IEEE as well & 802.1 operates more informally than many 802 groups. Don't vote on each little thing & operate on consensus. While we do have a formal voting process, we do typically accept comments from people who aren't part of the WG & I've never seen outside comments not processed. 802.1 is much more informal and a relationship with TRILL should be straightforward. My questions is when you talk about the liaison relationship, it wasn't clear what you'd want 802.1 to be doing explicitly. Obviously, we'll have people attending anyway as IETF participants. Donald: First, I want to agree with what you said about 802.1 being more open about comments from outside the WG. In 802.11, which is more formal, if there are technical questions, the chair can submit them as his own. For the question, the liaisons at a minimum would report what was happening & report Paul: Dorothy is the liaison for most of the wireless, but I've been serving as liaison for the 802.1 related work & will continue to do so. Steve Drawbridge(??): One of the co-authors on the new IETF liaison process. Part involves the IAB appointing an individual to look after the liaison. Liaison relationship actually means something in the IETF context. ==================== Problem statement and architecture Erik: Editor for this draft should be here, but person is still TBD. Put this up to encourage people on it. Looking for a volunteer author/editor. (See presentation) Richard Spencer: You put a list of what could be considered requirements. Can you tell us where those requirements have come from? What enterprise customers have said these meet their requirements? Have they said that these are the problems that they want to be solved & this is the solutions? Are there any enterprise customers here that have these problems that need to be solved? Erik: These things have made it into the charter based on people saying they've had these requirements. I think it's hard to pinpoint the origin of all of these requirements. Richard: It seems to me that we have a solution & are looking requirements. Erik: We have a charter saying that the rbridge is a start & we discussed this during the BOF. Richard: Are you intending to create a new market for this solution. Erik: Yes. Whatever it said on the first page, shortest-path frame routing in multi-hop 802 network. Richard: If we don't have requirements, how do we know this is the best solution? Erik: I think this is out of scope. Joe Touch: There are several docs. I've seen WG have as many as 8 or 10 docs that lead up to the solution; shouldn't do that. The doc that we have to date is a combo of a problem statement and architecture. The problem statement should include the applicability. The architecture should also list the requirements. Some of those listed are architectural requirements, not problem statements. Shouldn't be that hard to take a first stab at that. Easier to see it from the docs; it's hard to do that on the fly. Erik: If we can get that clarity, I agree. I'm not sure how we're going to work on moving forward on describing the problem statement and the architecture. Christian Huitema: I really think we need to work on the requirements. When I read these slides, what's missing is the ref to the wireless networks. I don't know if that was deliberate, but it is a large area of campus networks. Erik: Had question in BOF if targeted explicitly at wireless & answer was no, but could be useful there. Christian: I agree but I'm talking about the wireless networks. Taking the differences into account makes it likely that the solution won't be applicable. Erik: Popping up, during the charter discussion, decided that we didn't need a requirements doc first. This is fairly solutions driven from an architecture perspective. Having a solution in the rbridge means that we don't need a year or 2 to write a requirements doc. Christian: Agree not to spend 2 years arguing about requirements first. However, the requirements (or architecture) draft should consider the wireless as well. ?? Jenkins: Share some concerns about the requirements. The problem statement isn't a problem statement that is to be solved. Until I can see that, architecture seems a bit premature. Russ White: The IETF typically doesn't take requirements from customers, but from vendors. The vendors I know (Cisco for one) has customers who are interested. We have people interested in working on this & vendors interested in implementing this so we move ahead. On 802.11, I think that this will be useful there, but it might be good to limit the discussion scope architecture about how this works & then look at the wireless as we know this is coming next & commit to looking at that and working on it, but let's solve what's on the table first. Vach Kompella: Speaking as chair of L2VPN, I don't think that there's enough in the charter that distinguishes this from L2VPN. I think that a requirements doc is more necessary than you imagine & then make that discussion here. We did have a scope discussion about work here versus L2VPN. I agree with Joe that this could be useful. I don't want to get hung up on bureaucracy, but in L2VPN, L3VPN, etc. we have the customers write the requirements - so I disagree with Russ. Of course, we have a smaller set of clueful service providers, so I'm not saying that we need to go find clueful enterprises. There should be some people who will sign on and say that this is a problem & we see the issues. Joe Touch: Usually when you include a problem statement, it's bundled with the applicability. Mark Townsley: Could we focus on the problem statement & applicability & if this isn't sufficient, then we'll think about a requirements doc. They're useful, but not always necessary. Let's focus just on the problem statement & applicability inside that, which might help satisfy Vach's concerns. Joe: It might also help address the question of who wants this problem. Erik: We did have the question about how this compares to L2VPN. We did have this in the charter, but took out. I think it makes sense in explaining this as part of the ??: I think a lot of people are missing the obvious, if we did a survey about how many enterprise customers are in here, well everyone in here are enterprise customers. Erik: But if they're building equipment to serve the SP network, are they thinking of those or of their own networks? It's good b/c this helps clarify some of what I've been missing in terms of what the problem statement and applicability should talk about. (More presentation) Joe Touch: There's a bunch of threats that don't come to mind, such as misconfiguration. There's a lot longer list of things under the "do no harm". Erik: Right, there's a lot of robustness concerns that could be exploited. Joe: Even not considered as attackers but rather accidentally. Erik: Traditionally, we think about active attackers. Joe: In the architecture, go through both active attackers & misconfigurations. Erik: I'm not sure if the security ADs would agree with calling them threats. Joe: Right, but the first do no harm is a lot broader than the text. Alex Zinin: On scalability, one thing to keep in mind is the frequency of updates, such as start of the day when things are coming on-line & hosts moving around. Erik: That would be in the applicability. Alex: Yes, you'd need to define what is the scalability range that you're optimizing for. Erik: I'd like to see this as a concise document? What's missing? Looking for volunteers.. ==================== Requirements on routing protocols Erik: Again, this is a TBD author. Trill will provide a requirements doc for the routing protocols & then select which to use. Any extensions needed to the routing protocol. There's been some work & an ISIS extensions draft is already underway. Want to enable 0-touch, so can operate without manual configuration. (See presentation) ==================== Protocol document: Radia Perlman: (see presentation) How many spanning trees? How to learn endnode information? How to handle multicast - IP multicast - non-IP multicast Vach Kompella: How do you know which VLANs belong to which RBridges? Radia: That would have to be configured. It would be in the link-state protocol. Not just "hi I'm Radia, but also these are my VLANs". Alex Zinin: From my understanding, the bridges that announce their VLAN membership is just the RBridges connected to the end-hosts. Radia: All the RBridges support traffic transport. Alex: So how do you decide where to forward? Radia: Calculate a spanning tree (assume one) & you're not in any VLANs. Look downstream to see which VLANs are connected to the RBridges. (Continuing presentation showing why one might want separate spanning trees per VLAN). Dino: Might want to say what a per-VLAN spanning tree would be used versus a global spanning tree. (More presentation) Erik: A question on the dynamic nature of this, through 802.11x, this might attach to a particular access point. Hosts could move & VLANs might come & go on RBridges. Radia: yeah Alex: One comment on spanning tree calculation. Suggested just selecting the lowest router ID. One problem is that that router might be momentarily unavailable or frequently. Radia: If we're doing a tree per RBridge, not a problem. Alex: Yes, but for a single spanning tree, it would be. The draft has some words for ECMP-tie breakers. You really need to worry about bundles between nodes. Radia: It depends if those links are transparent to the rest of the world. If not, we'd need a deterministic tie-breaker, so would need to include the port ID as well as the router ID. (Second presentation) Michael Smith: Quick question. The recommendation is to still pass the MAC addresses Radia: Yes, but just passing around & not need to store them if not part of the same VLAN. Michael: I was quite encouraged by the second approach where you do the learning. Radia: Yes, this is something which is better suited to discussion on the mailing list. Erik: It would be useful to write up an email to see the pros and cons on the possibilities. Radia: Yes, and if sufficiently long, might be a draft. Alex: Before we start discussing the pros and cons, having the possible solutions fully described would help. (Third presentation) Tim Shepherd: Are we concerned about defending against denial of service attacks? Radia: We certainly could say that there's a certain percentage of traffic that's available to multicast - but that's orthogonal. Tim: But earlier, for unicast, if one hasn't heard of the address, then it is broadcast. Radia: That's the case today... Tim: If this tech allows larger domains without routers, could DoS whole domain... Erik: Would be interesting to understand if people understand with snooping if there are things delivered without the IGMP. ??? Dino: They default to dropping, if IGMP snooping is configured on all switches, if the MAC is IP-derived. Erik: There are 2 different behaviors depending on if the MAC is IP-derived. (presentation continues) Dino: IGMP forwarding doesn't happen for that case. Existing snooping IGMP bridges don't have this problem. Radia: We need to make sure they don't. We haven't written down the design yet, so just need to make sure that we don't break that. It could be that we just copy the design for IGMP snooping bridges, or we may need to do more. Radia: Should we allow cross-VLAN delivery of IP multicast? Alex Zinin: That's a router function; I'd leave it alone. I think we should preserve the functionality that is there. Radia: This is something else we should discuss on the list. Erik: What happens when you have a mixture of bridges and RBridges? What happens when some bridges do IGMP snooping & some don't? Dino??: There's nothing standardized, but MAGMA has something written down talking about how not to break it. Dino??: If the RBridges don't do the IGMP snooping & the existing bridges do, how does that work? Erik: On the cross-VLAN thing, people may deploy VLANs for different reasons. Some may be for security & some may be to limit the broadcast domain. This ???: When we talk about non-IP multicast, we need to consider MPLS multicast. Erik: They're specifying multicast in MPLS, but Alex: As a general response, let's leave MPLS multicast for later. It's not yet a done deal & it won't be as easy as IP multicast. Dino: I think we'll have a struggle between management isolation & optimization. Then, do you want to support both or just make a decision? Alex: We could limit it to L2 as part of this & then some nodes could do it as part of their L3 functionality. ????: Are you considering something like MSDP like multiple spanning trees per VLANs. Radia: If you're doing per-RBridge spanning trees, then don't need for per-VLAN. Then which VLAN it is is only filtering information per port. ????: Assume a bridge that is doing IGMP snooping, how will the bridge in the middle be able to interoperate since we're adding a header. Radia: That's a question. Since this isn't written down, we need to get the design correct. It'd be good if we had people on the list who really understood how IGMP bridge snooping really worked. ????: What about MTU issues? Have we thought about those? Radia: For a few years, I always assumed that adding a few bytes would be fatal, but now they're doing VLAN tags and MAC-in-MAC so apparently it's not a problem. Erik: So at end of the agenda, should we accept this rbridge doc as a WG doc... Are we ready to answer the question? Loa: This doc is actually mentioned as the starting point in the charter, so is there a question. Joe Touch: It might be more productive to offer to start with breaking the document into two pieces. One that looks more like an applicability and one that looks like an architecture... Erik: The only reason to ask the question now is to rename the doc so it's easier to find. Second step is figuring out which docs we need. Paul: It does seem a bit odd to adopt a protocol doc before you even have other docs written or even outlined. It makes sense that it would be a WG doc at some point, but not sure whether the WG will consider other approaches. Erik: The IESG re-wrote it into the charter. The document will definitely evolve; it's a starting point. ?????: What we have here is a doc that we clearly think will be broken up. 2 revs down the road, it'll clearly go away. Sounds to me like at least 3 (apps, arch, protocol). Once those are spun out, then we can talk about adopting them. Vach Kompella: It also seems odd to have this in the charter... You need at least one rev of the charter now, to take this out. --- _______________________________________________ rbridge mailing list rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 18335 bytes Desc: not available Url : http://www.postel.org/pipermail/rbridge/attachments/20050831/6e10a870/attachment-0001.bin