[rbridge] draft WG minutes
Vishwas at sinett.com (Vishwas Manral) Wed, 31 August 2005 17:02 UTC
From: "Vishwas at sinett.com"
Date: Wed, 31 Aug 2005 10:02:29 -0700
Subject: [rbridge] draft WG minutes
Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B278CA29@sinett-sbs.SiNett.LAN>
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 Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7VH4pk08782 for <rbridge@postel.org>; Wed, 31 Aug 2005 10:04:53 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5AE4E.1668E4A8" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 31 Aug 2005 10:02:29 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B278CA29@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: <BB6D74C75CC76A419B6D6FA7C38317B278CA29@sinett-sbs.SiNett.LAN> Thread-Topic: [rbridge] draft WG minutes Thread-Index: AcWuNs5SQOZxq+6fT82kPLdfasNFkwAFvcE0 From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: Re: [rbridge] draft WG minutes X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Aug 2005 17:06:03 -0000 Status: RO Content-Length: 42020 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AE4E.1668E4A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 ???? is me(Vishwas). =20 Besides "????: Are you considering something like MSDP like multiple = spanning trees per VLANs." is MSTP and not MSDP. =20 Thanks, Vishwas ________________________________ From: rbridge-bounces@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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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@postel.org http://www.postel.org/mailman/listinfo/rbridge ------_=_NextPart_001_01C5AE4E.1668E4A8 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ii4RAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAHwAAAFJFOiBbcmJyaWRnZV0gZHJh ZnQgV0cgbWludXRlcwCcCgEFgAMADgAAANUHCAAfAAoAAgAdAAMALwEBIIADAA4AAADVBwgAHwAK AAQALQADAEEBAQmAAQAhAAAAQTA4NTFFNTkyQ0IxMTU0NTg1RUYwOTlERTQ5MDQ5QTUAHAcBA5AG ALRGAAA3AAAAAwA2AAAAAABAADkAqHhZxU2uxQEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwABAAAA MgAAAGM9VVM7YT0gO3A9U0lORVRUO2w9U0lORVRULVNCUy0wNTA4MzExNzA0NDVaLTY2OTcAAAAe AEkAAQAAABsAAABbcmJyaWRnZV0gZHJhZnQgV0cgbWludXRlcwAAQABOAAABBoY0rsUBHgBaAAEA AAAbAAAAcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcAAAIBWwABAAAAUwAAAAAAAACBKx+kvqMQ GZ1uAN0BD1QCAAAAAHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnAFNNVFAAcmJyaWRnZS1ib3Vu Y2VzQHBvc3RlbC5vcmcAAAIBXAABAAAAIAAAAFNNVFA6UkJSSURHRS1CT1VOQ0VTQFBPU1RFTC5P UkcAHgBdAAEAAAAOAAAARXJpayBOb3JkbWFyawAAAAIBXgABAAAAQQAAAAAAAACBKx+kvqMQGZ1u AN0BD1QCAAAAAEVyaWsgTm9yZG1hcmsAU01UUABlcmlrLm5vcmRtYXJrQHN1bi5jb20AAAAAAgFf AAEAAAAbAAAAU01UUDpFUklLLk5PUkRNQVJLQFNVTi5DT00AAB4AZgABAAAABQAAAFNNVFAAAAAA HgBnAAEAAAAbAAAAcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcAAB4AaAABAAAABQAAAFNNVFAA AAAAHgBpAAEAAAAWAAAAZXJpay5ub3JkbWFya0BzdW4uY29tAAAAHgBwAAEAAAAbAAAAW3Jicmlk Z2VdIGRyYWZ0IFdHIG1pbnV0ZXMAAAIBcQABAAAAGwAAAAHFrjbOUkDmcavun0/NpDy3X2rDRZMA Bb3BNAAeAHQAAQAAACMAAABEZXZlbG9waW5nIGEgaHlicmlkIHJvdXRlci9icmlkZ2UuAAAeABoM AQAAAA8AAABWaXNod2FzIE1hbnJhbAAAHgAdDgEAAAAbAAAAW3JicmlkZ2VdIGRyYWZ0IFdHIG1p bnV0ZXMAAAIBCRABAAAA/z8AAPs/AABL9AAATFpGdV6Pl/sDAAoAcmNwZzEyNYIyA0NodG1sMQMw PwEDAfcKgAKkA+MCAGNowQrAc2V0MCAHEwKA/xADAFAEVghVB7IR1Q5RAwHdENcyBgAGwxHVMwRG ENlZEu9mNAPGEYo1EG8giwdtEdU2A8ZUYWgDcW8CgBHjCO8J9zseDw4wNe8fLx8BEeEMYGMAUAsJ AWRMMzYRYAulNCAQAir2XA6yAZBnFPAKoxHjJFgCNBTwPCFET0NUAFlQRSBIVE1MACBQVUJMSUMg gCItLy9XM0Mn8IhEVEQnBDMuMifwcEVOIj4lXST/KjExvjgmYCcSKX8qjy0AMyPw8SvgRUFELD0O 8S1fL98FK2Q2DvA8TUVUQcUHsEEy0D0iRwnwBJAUYXQFsCIXEE9OVE0pQFQzYAXhRXgQ8W70Z2UG UnYTMTWxAJACIAAgNi41LjY5NDg0LjApbjE/K3M3N0EmYFRJVExFLD40UQ7wW3JiBRBkNVBdDCBk M8ABgCBXRyCybQuAdXQHkCreNSZg/i85vzfvLLU7AT3wLr8tDwVBxDURYDxCT0RZR0E9I2FCX2c5 NiZgRChJViA7cD07cE9XCEFSZQtQeVRleBB0ODc4FPBkaXK6PUHgckEwQaMAISAAAM9IUQqxSUIQ 8FxxAyFItf8RYEQfRS9GNkgfSS9KOkF5XDY0ThpKbytkNCvBRkk0QSBmANBlPQcTIFEdgz0jMFUj IACQet1UMDJOCxgwAzBjE/ADsqMB0EpJSGksKuw1RkH+L1OyTglOF1BbAcBOFwqi91qYCoAq7DAu gShQRoBZ7/9ST0u/TM9N307vWs9RD1/v/1MvVD9VT1ZfV2xYf1mPX78FQbU4I/AmbmJzcOMCgGOX XCdhAUBlX1vP/1zfXe9e/3AvYR9iL2M/ZE//ct9mb3f/aI9pn2qva79XXX4/hdFGoAQgP9x5ZQeA KAJWBABod2FzKS7/bb9uz1qfc89033Xvdv9/r/95H3ovez98T31ffm9/f4CP/4GZgy+ENGzPiI+J n5vvcQ//ch+K/4wPjR+OL54vkE+RX/+Sb5N/lI+Vn5avpw+Yz5nfu5rvrmZCB5A7cAeRIq7v96/0 CqOBkyIHbSlhg6o90H2FPDqfT6BfoWoRcTVged8IYIIxAIEEgQuAZ7DwA3DFEUBovPJsaWs1YAXg 3ERQvcSGX4djdUHgBSD+bDVgujAAcAMANUAq7DKA3UORUqpZqxALgGUKga5XF6owCeAEIHATMVZM QbhOcy40EIYhBeBUvlDhAHBkIG5vBUC+Iohf/51/po/G78f/rG+i36PvpP//yv+nH6gvqT+qT6tf y9+tf//Q/6+asQ8B8ZufyZ/Kr9wP/7mfuq/MD80fzi/PP95P1t//1+/Y/6//2m+yH+k/tM+13/+2 77f63I/dn96v8x/0L+Hv/+L449/k7/b/9T/SH9Mv1D//1U/33+fv/L/qD+sf7C/tP18FL+9f8G/x f/0BVDUha/5zWG/2j/x/Dt8P7wJf4u//+d/67xLv/Q/+H/8vAD8BT/8TzwNvGO8FjwafB68gTwnP /wrfC+8M/8Swh+QRXxJvE3n/LC8T/xUPFh8XLy2fGU8aX+8bbxx/HY8znjImQiu1M88TNN814khS xBBhYkmjxdBHkD0tMSNsMThgkmM4YGpcwCBkYiRQ+H4gXz/yP7HDEzADw2o/Ot874h7PH98lbyH5 VGH+aCgxIv+EIiuAJG/fbcIwZzbbP6FJR0ZyKDC4/DmPhLAyEErqLfkgcmK84KBkZ2UtYrxAbidA AHNAcG9zdGVsji6CcL0QvIAgYmUOILpsuuBvuuC+zzviRbzglmsn0IJwZChAcmvBLx/CP8NMSd9K 71aHU2VuTnRMz03fu2dXZcXgOFAvMzEvSQAwt/A36DowMbvgTVQfVS9WP3dXT1hfDbVvWg9bH7tn RORldlCwb3C88kdQUf95O+JoeU+CT2C8QFCgcv4vT4TGjV7vX/9hD2IfWTjgdWJqZWNZ/2Tfu1iK W091XTZQcmFmxiD8V0dnT4dUvPBpMSqNat//a+8qnyuvMx92H3cvLi8vP/8wTzFfei97PzufNZo2 24Mf/3wFcQF8rCbhd/+D/4qaQ9D9geBQiN8sz4bPRY/aT9tf0YpgQW55vGFyxDBv8MZpvIHEEG8g dw4gxiArKmGRQGG8sC82YHNj6HVzc1zALznwxDHF4Mtz/4uSdVBwbj97j3yf/3ffmG+Zf5qP37/g z53fnu//n/+hD6IfuxxTQps/nE+dX/enX6hvw3ktrSCqL6s/qU8HrY+un8N5VFJJTEzvc7Gj/6UP uytNdVSWj4uDGEF1Z5XAxiA0LCD/XUKwX7Fvr3+5r7q/w3m2xt2LIGtZ0FFAk5BBu3BnP/m4NXRs KnBp771/u4/Cr9vDv33KQU/APaBhcBzGX//Hb8V/yf99nWaAyvBmoHNw/GJsJ7DI78z/yw/P79D/ Q33KU0s6ICJTKDBleycRNnBsk5DA34uSlBBnv7VQNlCUwCexUSFPwHSUEJ9nAnOgz4AqcHOgdGjW 8PZwTJDPcW3Sz9Pf0e+0D/+1H93/3w/gH+Ev4j+1v1CQ/9lBJ6BZ4GcgPaDXf4uDJvBtOEBpUKBv 8HWT4DZQb3+VsOeCwnzlH+YvDhAqMCA97dFz1tHa0Gby2tJJRfxURtuP3J/dr+r/7A/xz//y3/Pv 9P/2D+yv6B+Lkipg/1nglFOV4GnQDgFpUNbwlPL/R1DbEVBxXMFpIfFS/NHnon9pEefh2tCUwtbw +w+LkmP/KFDvX/Bv8X/4T/lfBD8FT/8GXwdvCH/5/ypAJvD9cemg/mjawwPAUJDCfwLPA98O3/8P 7xD/Ct8L7xRPFV8Wbxd/DxiP+h8Ab4TQUmVxdXc2cOdzlRBmU6BnIbNTLf8BkCbgz3FpA2by2xGU cJOw0ziAGn9hbRu6JuaKULD/b+EdX4uDPcAOcWbxEb8Sz/8T3xqvG78pPypPK18sby1//xxfIUbC YLOgU6BTcA3TIFDv/fJPkNlBILd3UQMk/4uSFnMe4D1haSjAdHkv/z3AUKCUQJQiDq8nzyjfOE// OV86by/fMO89vz7PP99A78tB/6X9UEyQZHVQMGch/5Xgc6BRwbNURRBv4Lcvi3Q/H4LnMcixU7CU Uc9QY2v/OB88Lz0/RA9FH02fTq9Pv+9Qz1HfUu9zVC1IUNdA1lD8bi1y1e3y2tJIrzZziyD5f7Au Iks/TE9NX1qvW7/9fdlSlcGzoOmScBxUz1Xf/f0xIDd4lGLa0iDO7eNYv7fpI2LQ2oBkk5DAsHcz Mv9cgF1/Xo9cn2FfYm9rn2yvf22/bs9v32MP2xGWMWCRLbQgarjCbiFg2wB1z3DvDnDa4Of/i3R5 R4BLL2ov/2s/eG95f9UP1hhgwMAh/8N/2cFmoHYY/aNW47kQDdBs/SGwZ2URlIB2v9iT2uB7T/98 X3pvch9zL4Yvhz+IT4lf34pvc88OYu4h2wBl/hAgkR0BkSANgM8wH7Fsb2//1fCUwYI/weLpoHg/ hL+Fz/eTL5Q/lUo9mQ+ZMJYPlx/9lSxDkRDWMJUQ/+A30Q3EA+8QnnAgODAyLjH/z7+bT5Ufnz+g T8472ZBoEPt2n8HERdqRwkDAEGEfjX89texRHuBLAEegzzF2aXxld9mCnrMOUdcgj7Buv+q/qG+1 7J5opX+ShHOiH/+jL6E/rI+tn7PftO+1/7cP/7gfuS+6P7tPRhrqUCZwRvD/q+DZoEex2tKeschw 6Xq9D/Mi71ZYZWazcWav+/X/0v/poO3xkv+yb7N/vS++P8mv/8q/y8/M383vzv/QD9EfRgv8KFP8 8NsB2WAfMZ20xU/nWcOr0MTAcynHT8hfyW//2O/Z/9sP00/UX95f32/gf7/hj+Kf46/kv+XPI/dC /VDHnaCdcMEwYm9iH8BYRc+qsqVAIbCr1SBiIODW7/uDNh8AJ4ABIJAfQGhwR7F5/gBvbR9y27/c z93cbf9+oIOv8M/dz+d/6I/1b/Z///eP+J/5r/q/+8/83wysSFH6acTgY+zPpoOr1ccv8/+P9Q8E HwUvBjtQYXUhsHudQCEQZNbAp1//r0X8Vj+qcJAxf5Ae8B9znrMoP/w/KaxPC99jP8HhWEEfwJ8C L6aSNwA1EJ2AZmbuQX5uRyFpDwf/Bg6vQ4DBd/8kkCG/ww8j2at0NADrsWRw/8Ug8sIVIR+BftCB oGhwf4H/kHBXgWhwEv+mksECdQBlgF5wA+8WT6Qf1sAnf7B2v2YQ63GQcGhAwWCrwXSnAP9YkDOQ ZbIZLxo/AQccNTUi/2ZAA9A3oXWQD08QX0X8Hm/fppJgwZAhGNCBAG8gbyF//wYskJUdNCOyZbVH IGCQgWHzLhJ/cHlwAfAdc0rwRyDmcH+wZkBtbe7BxS9Jlf1mAG0uXy9vBiyP5caQghA/ppDuwCOR poFHk2UyV0f3JV8mb66pJ5CxxQCqwUdh/39RZYFkoMTANS+mgzSmNs//N98GLHXTMrR2gClfKm+p fHOrdFhBbXUkYRzLgOBun4ChZWAY4NaTdmBpcD//H8ZEniFB30LvBixUUkm8TEyPoDpACiClYGI/ 4N+m8IEgFFBHMDHBd+qBRa/LRr+pfE1ocHF11kBLA/dYMsaQf1F5ZYB/cKVAaOD/S59n0+rQZZBN L04/BixlMl/sFkrKgWDG4VHQcyOCY+/usKaRxpNWYSelYFHQ7tD/r4WCDxPW8v9ZnwYdCpBlsvxl eJAQAfDG4B2QUh9TL7mpfE9iqvA/gNhAeTMS/icY8ZCTj+UccByASnAlIn8eIVHQHk9X5UHPYj8X b1T+RjrTZNGmgDTxIF9tjwYfd3DPcd+kX2QKz2ZPqXxG9w5ApvCBYEle1F+RdFAU0L8t4Z4ixpNr H6aSVmJzq/D/gKFYUq+FUPAlIXOvdL/x7//rcY/gkHB99DSnNoI/d+tSe3wfLWNHZT94H65tq1Ux /zMRwXAkYbFPf/+BDxzSMcQ/XRHAo8HhOnHAsMGgaG7/M8JVODMQhK/t5Q4FM9Ad8PkpIGJtxuCK T4tfWr/vcOcYocFwNRBvd6w/hx95Hv8OgetSVUYzEFuZErF7/1fl2x4AcrBpSTDvcHdQopLP95Pf cswU0HDy0F1BxqJdYf1pMXCCYSUvPK/D+6EUnh//ny9yz6X/pw8JXXcPl88rf/2cD312oCAAHcBq 8Osl7Bb/DnLywMAQwIZM4ErBMuPskn8+g1Dw7sCoz6nfp+zWUHL/aFBqcjUfAxsOY8DFHAFKw/tF gJ2xclbdo4/D+0zgGPH/KMEyUVVQX4IzYexQcJ+1P++n37+vwL/BylMcgD6ht+8jsBNRQHdicn3A Z2V/DwKsD60fZ10+0DsmQVAtfwoQHcDy0JZhHfDrUj7Qd/9vdMXvAznCj8OfOO0ytJa/v8kvEWwK ADsBwZAjwGw+oPHrNElBQjGQojBkQTJTz5IxwZAUgGhQZHVKMV+R7mzvUFbfV+VmKGDvv9A/35Tf W7fSr9O/EWxMW+9LYf00MHTYUR2RQYAeILfA7FD/QYAlBMGQhF+FZ2+C2r/bz/fBrL5iZJB0v3/n T8Gf6e/76v/sCj3vz+/w7M/t36rt/SAAYrMAg8BRIBxxQYJKU/vkv1gDco8AXTABsOLQFNC/8Q/y H+vv96/4v/nJRceA7mvIH99/EWxFFIBfkA5U+yUBt8BkUUDacFB5ElKzRH8cQbGC9W+FslXhVXEY 8VT8QkTpv/t/+Y/97/7/CE//CV8Kbwt/DI8Nnw6vD78Qz/8R3xLvE/8VDxYfFy8YP9S+/34hAWMg IF+PTGZWMEFQ90D/BpBpdyiRXTDebxsv4I3Y0b+icrHCMaAeD4Wy1hF16WH/2p8G3wfvIN8h7xl/ Kd8q7/8r/y0PLh8vLzA/MU8yXzNv/zR/NY82nzevOL+uDySvWBL9zAMvRYAA0gXfJ38ojz///0EP Qh87DzwfRW9Gf0ePSJ//Sa9Kv0vPTN9N707/UA9RH59SL1M/VE9VXzzqKFN7Qb89r4Wy0jCzEINB 4hMpQt/fQ+9E/1yvXb9eyVKJ4YWw7brwU4Jh0mBy/b9YH4g8+ll9cXB+IZ0gmxCyJKGD/x9xAlRa X4Wy6UGEEqVgng//YH+gL5owstGDMyC/ZH+IPN5DkjF9Yo7gBXF1t8ChgP+OYswRtzBtS6IBxb9p R4Mw72pfa29enIOSP24vbz882/5XoZKDQQNg0jCKIMuhceDvHdCDMMxBc6NzmzC68ORx/3KhgzDj 0HPvkTay0HWPdp/fbH9th3jPed+IPEhzsuRx/7CwfbWboX4EjqPdwdIx9DL3sOKbr5EYeYBfgW9e nKHQ//TxHdECgbGA1jH1Tbw/pJv/AWOw1Y9Rs3DiMoQfhS/gjP5BiMSIweNgsLCKHx8UfDb/i6+M v+htfNhyNInhc6OIVP+JPMzguuGO9Jev2iKPVJPM/5pvm39fb6Lf/I/9n5S/PK7OVH4T4+NzhW1h agAggf/kMR3Ry4NiodqBn9C3sLrhPwOfWzYgA6Tfpe+2XWF5+9dyh2Inc8FzoH3mbV+ob7upf72H Satj2PAgkCdzgv9iwR3frzaj4NcjsA+xH9zf+8tAx4Bn5EHLUeLxy0W0b/+7j7yfpA/BP8JPYd+o H7Zv/7d9if+hBSZAiZK5gHNAh/T+d7PSc8EkcJM2j7+Qz5HY/4iyyp/aItjC13HD/8UPgn//wF/T T9Rfw4/XT9hfp5/H///JD3t0zQetRrMHiCTRD/Zj9HJivsBkH8EBgc1x2kD/kXDOH88vkdjM8Nmv 2r/YzP0AwHN8wa3iAWT3QLM14f/x9mNCT0bWn+hf2L/tr//uv8Y/x0/d35XPiMFxUqyx7x9QAMCz QrmAY3LQieDNUuXvoHesIXJrfoEBJ+v//6Elk2Ptf/GP75/8H/0v2+//ZlCIcLVf9Q967yYwc8A+ wO+sgX2zIGHrsmZzEGchPqB9H8As+g+hFD8hJjB84C3/PqDrsHhx5ZDnT///1O5n4LeTcCQBvvFt Z/CTcC0/IJEdsDgwMp9RdHf5kP5r++8LT/4PD38Qj/LP899vA388rwffPsFJZ2Hr0GT9IGAnnbVy 2gegPyD48Bpw+czia24cEZJ5El8TbxF8/48gZyEYz/sqoc8erxFvIv//JA8BPxXfFu+3j7iSknYN Ufe/gupwr8BlD08m3yTvLg+zLx8wKkpv698+lFRn4P9ikCkfKi+qP5cyiMFb0AXR+79QGmFjAn82 zysus7LL4flxMFdHzRXrIKwwl3E+QX44NB908/mQMO8x/zAMMd/qMTnxh/SJcLQBdQ5wrNX9kzY7 zYAJIGfxGpIcQYgC/zovOz837znSPw9/tYngQI/vQZ+Nzc0FuXFk+HLj03VB/mK5gL8iiSbkEnGQ c0KXUR+PrZh2dQBikKyAZWN0/+tQLc9M/y/uSfJRD0XVrKHOY82wrFHrsmFwr9BigMhhYmkv4HR5 Rv9ID/8X71KfNWAdj1V/L+5TuljW/79QkzBm9Ouy1d9bP1xPkef+U3VRv4Rykl3v0iNkAY+Q/19v YH9hjoiSU9c5sRssHLB/B0FX3mU/Zk9c/2lPmNBT/0X3jyBq32vvvZ6do7lEduDv+UDgUQcE5CFi 4FCIMkbf63Ivcz5FrdBprZG5ccvh/6xydD+YsgnwUGAdb3cfeC/fOdNFwLjbRoUGh2xa3YJf/4Nv MN+H7yfvKP98nzwvGiO/WmCuP5iUB4B7RPgwbJiw/1qxB6C4UIqQGyBUbY4Pjx93PSBRYG/Sc2Ly HALnMCfvGyCJ74r/iQxnuzH38w8CY64fgIZtb3YNgvmBd/+5MgaRrFDqcL7AWoDrhXAf/5gPmR9h jVIx679TP1RPoV/Pom+J36cvqD1DaL7ABzDaaZCRSBtQUbFhjS+Uv/8rPvhRv2A+oLh0zPGoQOrC /5t/Su6X/6ov1O9kr62vrr/fBRc9kbAzo6O/8XOoIJ6B7Qegd3lRhQFt6xB+wA2S3x1TGxG5gLJf S4Nvs9+07/t4bqPgdxthRFDqoA7Gt4/vuJ+vTxp0HKNpaKLMwj5Bv1mgqCAgoDmgUbAHoGItIf9/ j4CV6xC/T8BfYY1j4IDA/+Oh0NHgYGiRWmDloOqQww//yz/MT6i/0G/Rf4yvxC/FP/3m40hEcRtA ILH7sQ2y7UEfx1LJX0uDzfJqoSBleP9aMgYQsJHHssKW1h/ln9JP99Nf1G+jNXPnMIDQx+IcsL/I xC2QWRIgoESQOWBmWRD/2m+zVqX/4U/iX+dP6F+rT/+sVNYP1x8rPpNTyNOWourg/GxrDYJacC0S wkvln4DCv88/6s/r31cleiCe9mTHYD5mOOFZYLtwDbFPgWFj/+SRUfE+cHowLMFEMdXgwrD/sKJ7 M6PvIez1b/Z/Ti0ag//k8VoWRFD1X/8P6V8CbwN/r9UP7e/u/3NrUA5gcA2C+0SgG+BkpeCe9vw/ gMIVcv9RsIDQ+RAtgM8AfsCGMAwh/25wu9Gjoseys88GT4Oeu9D/RkKxU1AwGypKL4B4epLDn+cJ n0keLLRmYW8wsJEiRv/IAQhQPhD9/xF/BF2BA5CR/2JrFW+Awi2weqAtsKXAG7H/Fw8YH9gunYNQ MBr22cJkQ/piCFBkkhAb/x0PBGxvYD/jYQ/2xqWxUyBPpRMgeedEYIDQseAgMrGTktF6Qv8UXgI/ KE8EXy/PMN/sj+2f8yMfJC8gQfEDb9JPgSvf//1DIdBSMS3ALUJQEc4AbyD/8idu+jKvM78eHRbP Nw84H+ussJeAZU9Qcm+wDL+Ahi0UWygtkaVaKRuBYWb/WMY93z7vMczkkBtgu9F+8f/CWsfxRP+A wpBQsIAvn0n/DzG/T09QX1FqPz8gSvugUPIBczY/Qj9nbYUxYxH3aFJL8fmQchth8li231Yf/1cv c6+AOxoAn1dSL1M/UUz/n/caQcbSemCff3k0vSJ/IPfk8f2BIiBkW29cf12PXp/0fVWgYGlu0JMw kIFgb39hf2KNf1F7YkSQH3t/QW3/PBHxQMkhZICtAaXfbK9tv/dSD3Kvc75SDwFp34CzupAfpZFV z2f/GS5E0ElFVP/aIJLwC7AB4LCCFSC7cMbS/3VQ+sAujIECdL91z0sdzwD/hYBbEDwAyMR4DxZz HwIbwf8VIDwAZu96v3vPhTaTIccT/ChDDtGxsJ3RshFIAVjQ/z3PgL+Bz4LVvCH6ASAfyjb/oGDn AUEAZs+Gr7mfl1ElUP2fUWULkJ+w+cKQtdnC9QL/vOL974wPwU8aEpE/3t+6B++I9o8/kEzZwmmb AGTBY8FP+JS9If2AKuJtb5RxYd+zsLsgkS+SPxksT5aPl5/hc804MDIupVBEkGuQ/7DEnR+zZPvD vSHCgLCA5Ok35uPIx7ygZ6LwAVJnb/5vSO+lj5iusbBzsLygWkT/Dsiof/005JAh0B9s8lRIoP/H QKok9RKZ35rvufhEsaR/+64fc81srOCoYPvFTMoq8f+xn5BCxxOZk2Xx5JCwYJZBfXPQeIONtj+b y78hsGNv/7hfuW+6f/IEZYUqYCuwlfg/yRFEkL0PkEKr0mTAdCf/oEJmoY6hZcDKEdmhRLLDwP9k scMvxD8//0EOzK/Nv3Svi9A/0U1W+iBoIEtZMPMh0E7wYTpYsCHQ+HRNXw8N2FrgioCjUEwyVlD+ TqfiKySoJPumWqDKENI//9NP0VxjwPpQrGAmVg5GZaP/1u+QQg7Bn8I8YEiQ+aGZk/8e89jDoW+i f+/+qCPa39vv/5i+xvIujxpCoMCPD/Rn+ZHuc5BA+4MfUHn6UJ8x5sD/0UG/38Dvt3z6k+Yf5y/o P/888LDpq3Lir+O/k08TcesP/5AzlFMlsbLzsOk8tJXy9UPv8V/yb9FcRGFzqvDiT/ZP//df5XP9 cDlSTMBEsFVAfeD/+P+pjUvwSMGquACPAZ/kzu8rI/zP/d/RXHcqYDmzJyDltFF1lkF1cMfSq9Ba oMhhdWNIQGN5yD/JSPOfEdjFTDPY48nwL4Aq4v+UUgrvC/+Yvt6RjiguI1pu/CAtoFJrkBAv4JUD qXey9wd/CI+jjWYTjxSfSx6z0P9u4ESQExUlonFAqpBMUW7gOzzw2JFjJfCrE27gcnb/fWAEf5Ak ZIEkkExBgzEY8j4nhSA5kR7fH+9uDWF5/5/UZcETEdFQnuEOMoox0UD/+OAj5iTvkEJjwURwcRBl 8P998Bu/HM+H33AiSKOskSePfyifbg1ZMpSljrKqc0wgZ/8PMPuiO4Eqgd8vBUq+xGRo/y8P7y+3 hxMRbuEy7zP/Fa//6oH/8C7ePt8/79IvQr9DzX0EUlTtYN6wea8wD/e8Vf//8H2DOI9Ok/DS7VNZ kCPw/yaAZF9jwSIwF4DKEavQLED/y7CtD0W/DP4EEt5yS8+QQvxhcJTQfWFw0EOwfTBBr99RP0PP Vh9XL1g6TZBAqGDRR/B3bnPLsHlIT0lf/fe8QzJzExGKUI4RywY6f/+yK2UXXN88D1h/WY9an2Xj 71UbY49kn7d4aV6wvqV+EuX/8GbO0GNpTyPwwxMQvieqkWGvOZWoUbQUYWY/P2dPWBzpji7/Xd8x H3knX+rhqvSrtCdRThBsDeB539bP7A11P3ZP97xMyfJxP/dyT839YGNqjiFgrmL/ao//a5+38Hov VN+fATcwTfHaEv8iMagw3rB/X4BvWBysRN6AzmwPAOywn8BzZuzg1TLfyhGHT9fz2WAksHJccFXv /4ufWA+RP5JPRv1cz30f5M3frCZ5sBjxjfOhQGSeoeGS/1Og6aCesbFS2JE2ow3xjx//OXiUH5Uv kzyDdZEPoC+TL9eiz6PfpOpFLqBrl0+YX//3v/jC+lOb+7QdnZ+QRIWw/74Q4YIZAAA/qa+qv/hy pa//pr+kzKwZvsLeW3kUFvC7cf/78bDPsd+rDK5v7CLlpU9h//EDyiHw4HjAEaGz77T/3P32eDZg 2FBuKrQ6Im0g7BH/I5Pecb9vwH+kz8R/xY/GmXw/P6jvup/kzryPcCkg/mx5gdiRNjWv8Y2B+3Eq w/9ToGFAJJDtYCaxbMETEfjC/3EvyE80/g9gE2Ds4K14zY/77CLtoG7s4C5IFrnQMt5B9/VSIjI3 AWX/we1QxmLSn//Tr8aK2bXQI9gp1o+QQxbWP6Kf3B/GX+Gf4q+n7yBC/xGCw/N4Y3kwabD7ICrB dEKecIRDDjEkYhekU1Dff/17JXT8MiIwr/Hkf+WPQC/vOBJwgSqyw+NvvxH8QMPVnxhAN3BcYCth 7GNzP8p//8uPXvrzD/Qfu7/rP5pAT5HlK/BvBsEvY64D7Q/uH//jnJsiBmHCkC6gjpE145zD/wYB JxAioQbgboHQdrfCI0D+bWCR98D430zUBgPs//xPv6E/g543smk8MlUEQGxwpT/hbwSv448KLws/ DEooTX/sgN9vJdabsE8hjlGQkCn/DQ8OHwwvEr8Tz0cPSB/2v//3zzHzT5FOIE/BuDDD1HSA/ysQ m9IrEXUAbWKvsRBPOXX/JvCNkCxAJsEY4RWPFp9oXe9tINBxkIEsIGfVgBIjuY//Gi8bPxxFz1LP UCrAuIDPQP/fQMPF0LGuT3sUT9EpMQN/eyHPIt8idQB5YaxBAWAi/wn/LT8UnzAvMT/mvyUvJj/9 XvtSjaJuQyhJz5FhMeDh/zIgm8EqX5BKHbSvsF/iAED/Mw80H8GPz1C+UFAQL/8/L38yH0HvQv+W XzZvN39fCkX/ABDyUXmBkIGJknSA0kE7X/WINXRFYGO+oNlBeTIksfveQXCwY23wibASAW7gVd+/ Rb9Dz0/vUP81P+ewVCSw/9IgrSJPgtoiveVwxExviFP+Y60gABFNt0/PU99R71qf/1uvRw9IH0kv mYu31HswuDD/QXFZcNWA2hH6cB0yGNCNsP95IHmAHPBZZVgfTXxgv4Wv/1z/Xg9fH41FJDxaX2vv XH+/by9wP1UPYK9hv5ltJ4PQ/0tC1XG/IcPzZl/r877ggnDzdSCJQUFEgpDscD3CcsD7sAB5cHe+ UBzwiODaYNC1/m1yH3Mv7y4dY28Pfo9xL/+BL4I/X745Nk5SeZ/OlHlwvyRwWkAd8i9m3gAodmIG sN+bcCvTnUC347hweAnvhP8vgw+Mr42/jstBBuB4IPZawrLnsE/eIIgPeqN8wb8IZdog2uEp1Oni vqBlm1D/t8EgQoqSiVOwAJwxHNDwMI/PkI+fkK+OvHVwZAdBf9GRIKJML3pnmRDDt9IQYX/wMP+g AGEp5dAyr7Hwo27+LY6SaE9pX48PmP+aD/3l8/EwHZFtb9FQ0MGcj2dz/2VBIGCMj6R/jq+pL6o/ dF//oN92fydN/8F7tABAt7YIC3+o/60Pqx+0n7Wvkd7nsFnPm8KnT+wC2tB1J9JAtpD/TAEgEU9A JHCVsf+jl0WU2f9OgSkRHbO3f7iPtpy8ct5ht8/gEjAgQHqnD+vGZuyA/7RvwO+2j8W/xs+uT69f sG//d43SQMeQTgDp5Fcz2VEccv88wt9CHhDY0Ady8v/M7yc8/lf/sRxhxA/XkwCk0XzJbznKfyBM +oDwk8VRIHb8b2wcwAFAWjLFj9e/x6/321/cb916PeE/4WDeP99P/d1cUulSEcAHctTP6+SVoL86 sU5gfQIGoSAQPMBs+z8/43/dT+j/6g/K33tgZ2GP6uA5kpdBiqNUQkQJkH9OYAjwxX3SX9NvVjAI gGz/fGH0EeZPEXSm4U9AHIGXwv/ltuvf7O/q//Ev8j/5v/rP//vfG8PQ8dojnmLnz/0fod//J3ie YZNveoaSoFlwvbEIQHcc8CAROvBl8O/+Lyc8QfxuefdP+F/5bwe/CM8NH/8OLw8/G8OMUdFA1mBL kbzD/7z0AJoE//Wl6HMHfxGPJz+3HEM+AEsRcx6Ce7ByV5D/F28DDxAPCz8MTx4fGC8ZP88hbyJ/ SiuL0UlTJ2ATausVj+dSZFZAZr3zlPCAoe5knsCowTnQd56w2y8fb/8gfyt/LI8tnySfJa8w7zH/ /zMP1EK/ULJwz2HRQJUQkqD4IDAtz2CcEZvhijCz4HsE3+c1cBpwm6F8Y1fSbf2/UHWU8C5fL28w fzRvNX//Pj8/T0BfGgNuKxdfQq8ZfPwoU3xBOR/1pJvAT1JWgv4pO8883z3vSw9MH+CP4Z/3Tg9P H00pUBbl0OfL3FLv31P/Tc9XP+SOi2Bp0FBIv/XnUlAacGw7YcvfRn9Hjf/PkkoPWX9aj1ifXt9f 72Uv/2Y/Z09oX2lvan9rj2yfba8fbr9vz3Dfce/N7Uhvd/9cj9Xkv1CewHUAv1CTAX0h/Xwxc9av Y39kj3m/es973/90L3U/fy+AP4FPgl+Db4R//4WPhp+Hr4i/ic+K34vvdb9/dsLPYZKg51A4/+c0 0UBk/G5v9jF+oMVRXiBFInmP/32ffq+Ub5V/lo+OT49fmd//mu+b/50Pnh+fL6A/oU+iX/+jb6R/ pY+mn4/fkOW90CrQvzfhkb/V87Kww3Cz4HO/3/+YT5lfqM+p37C/sc+y37Pv/7T/tg+3H7gvuT+6 T7tfvG//vX++j7+fwK/N7cKfw6/OC/otJ1BQrG+tf66Pr5+wr//F78b/zU/OX89v0H/Rj9Kf/9Ov 1L/Vz9bf1+/Y/9oP2x9/3C/dP8Tf30/gX8gHkzBu/i3In8mvyr/Lz8zf53/oj+npmFZhBuFLGzA6 cPRgTmHvEHbCABAgeTsgIA5rkzB24Aa0VkxBTv0asmxEoHkRkTAGtOVfOiLkUkLz8GRneW/rH+wv //LP899bX1xgXl/i3xl+YhDvG2HmsBRwrAB2rFAUkRrQ30SHFGBFb/ovGXxJ/Ebw7/86Iv1B9NAU svXP9t/07PTB/Gst5xA6ohbf/q//vxoDIk5VMCBqdecQICKz7zAnUCdtXCQ4gGI7Mf8qQDihFMFh YAGfOhM6IA0AvG15A48En+xd75IiK09fD9/03xJvE38UikGsQHjcIFoUUBRQ7gBGVSALoP8OsCq0 BtEq0HjxOIAMwe/Qf/JUDLH8MQ0vDjN40DsgbuZj/PEM0GlyFU8WXxD/ck47UGVt7+AZwO8wcL8q AgrzGnLyNkSCFGBjJ9Df/KDwURpyG4+SxS07EOcQ/nMSPx6/FF8mLyc/+A/5Hx8IzzZMGEBVgCI7 c3VwrnCTsDdROpBmRMBjJA/7OhMw4W4tkDChJf8qDygf7zN/NI8Xju4AU6vh7jiTUH5j8mAj8PCA XfD885Ohd/1JwGTyvzdfNW88Pz1PK0/37gAxb0nCQwxwVcDt4AcBv1xweKtIUOcAMGBV4CD9gGRl KeHPJmHtoC25Jvt2Ge6RJw6BkzAK0AMheGH/Px9ALx/f77AHvy1v4P9Cv6B9TG9va1WRdzLg/3kx R1CrwmFi7yoOciMOSg//Sx9BPfJFTV9Ob94fWO9Z/zNPzzHrKEP9gGIgbnX/ePJhqniQOeF48vCA eIBF8f8g8P2wXQABMBnw5y9WHz4t/1LQMmEG8nisXm8yY+2wJTD974IpM09j/z4vaY9qn2uqukRr cG8sX1yPqrxNYmd9UpNheIDwgPwxRHBowS3/ILNEnGd/MnIBRP1BCwD98H9sb21/a4z84BnACwBE YWf98ABiDHBEjGlfeM9rf3zP833ffuooTZOwdY9oZWCZfil/r4C/fs+FX4Zvh3lFHSKQa2+vcL8u fSBxdY8i0GEDYSEacmR5bkdQ+zExj6B0/dFF4FqADMAhsFcaUIMPMnNoB0B1YnAg0DgwMi6I8Hga UiGw/4gviT+HTGJUkBCUQO1R8FH/dBEycObRRBElMO1AHTBFkP0HIG+HMDM9jE+NX+4gJcHPkP8y YweAAWJtb/zhmU//R1+rB++Dk6+Uv5XPYoEHgO9FwZ6fn6+rB2dzYGEhWB//oh+jL4fPqZ+qryvf mc+a3+teLzIneVJgaKvvrP+rD/ez/7UPOK9PYiGk8SEAcyH/YSJEq+bwQ/RhEZk/sE8APP5TkpDy gSNisj8ycgryts9/t99lHhhQI1BE4xqB8AB3HY6hIJJxI2AlMElELvu6EwcxYhhQC6AhsRszGzP/ xiXAT+ZjYmLB38Lvtez9QWeeQLqSMnBpbBli/NBh3c4gYcdBReAlMGb94I6B/1/wzjCo38t/td/Q L9E/ri//rz+9vwA9WoDF0EkiyN8ycv9R8GGSRHBFI2jC8jUaUEli/3QRxyTP/9QP0h/d397vuQ/3 1m/XfwBLWSLQDBQ7kURhe9nvMnJzYZHO8USbGlBp//xG/UC8r+UP+z6PYTDxym//4b/fzRtAMEGl AgFAO+Ai4AfngufvMnJFQ01QLfeX8BqSUmBrIUHrT+xf5h1/OmFSUS9gGWDf0CN08mFy/xlgztDG Me7f7+/MnRmBGFD7IuAC8HTF0CVg8v8yY9zQ/zrQqM/7P9+/AA8BH9U/1k9/9m/YbgrQOtDcABoA IuBp75CCJbDFkQIAa1O0MrQOcf9zJBpyYJEbbzJUkHNVDwP//wIN8mGeEPVvB1/Yf9zRGlD/2YHA IPkTRHA60MZRYlAYsPeOsTFA9KEt9OUaUPIQ6rV/DK//U/kkDl8PbwIcAgBj/Gx1OtGPQjCTxpBJ wCLg/8XQL2Hx4QwTxjcZ7xr/Ah/3H+8g/4H6UzqgVCAYD4P//4UPI68hvyhvKX8qi3KgU0D+YcTg OaBiUJNgBk8Sv3HM+lFgMGNR0I6GEa8wP+1v7yYvdqN1YLpkZGD0x5JzYf+X8B5xdqCYsCtfLG8q fI9C6E1BQ0nAZO6AmKHnAP85jzqfKn89zz7fBU8zHzQv/+YvNj92o+dCwZI5M9tTknH/Jg6mH6B7 3NL5FsGwgsIOIf/HcRSzQJ9Brz+8l8KQZOmB/4+wNi92lGkCH69Pjz+vVF//VW8tn8TgQ+9E/xPN YqHyoP/PgOqQUnAJoJ3h7pC/0Hcx5/nQUgMl1GFwxxGXMmHQ/xYQUn+zJfhx2zBXP1hPO6/7xaCz kHJ1AlQvY59WT2aP/2efQt9ar1u/Rg+TRMeC8hL/k2HbYXPALmHHgmDvSEP90N/IknrwXiH5Q2yA c7wgSTH/juNpb2p/ZL+WkM6hxTJoYP/BsGZfde9of3kfei+Kb2zPv23fCH4Xz3JqzlDE0Gbq4Of5 U6hwXjF1cArQjyDHYP/OoTiju8EdY5JwCsH9YHv//30Pexwl4fKgjxWCzydDCkD9SUBieEH0of/f iC96/40//45Pa59sr4A/bs9HAYcBCeL5c3BmZi5g9LDPssWh6VD/b+CklM1x58/a1e6SjR+RL8+P P5rvm//i/yBChGBNkv8VIDjRUZJ0FsVFhraKI2/g/cggdsUymR+zQg4vnq+fv/uMROlybx0QODLy oergzjF9/7FjfwDNcIKg6sSl0Gz+cJq/pv+c36v/rQ8k++5A/mnygKRvJz8oT6/fre+0j1O1n7aq VGnHcFOl0HDdYJFkk3+UjzFMQaFkJeG+YxYQtoAVofoCCWFmCaH/pD9htrgQhcALUAlSFlD4wN9R wbdvuH+2jLPAcqQgvsDvCtBzIGBACrA/wp/Dr7aP58bPx9+SfyBXvnEWEMow/8ig+OFegYKRUkBf IjggwC/7pXbbwCcKwc0m2/K+wLPh/9yQwm/Kf8uPCyGXUs5j0GLedoXB+fDpcTixbergFoH7XdBI 8C3nM87PpYTVox2x/QowZzLg+MCrz9MPyK/aX9/bb7mtuy+8PzFMQudRZeH/3DAXUvLCScDXA+px 4lAy4POK0PHRbifXr2HUpdBh8PeyIFHVPQUs3T/eT3cPOGHvSPA4gfTgYDBk1xLaL+mP/9xP7P/u D8vf4G/hfzUu1aOfir9httcR1nI4EHku+MD/79/w7+7/+S/6P9+NFJJwA28fQHFRwkCYAHeqANYw ct9e0BlAYnCFsYpRdy7xv1KPHxRHD/e2gnNEb1P7///9DxB9CjDWYQD0+M8FTwZf/whfCW9+H38g zPCCc4QRCmD/H0EyoqKiOMBJwQIxC/CW1OMCj7NTZW9wB5EQOQFy/wtfDG/EvU5QEoCikk4h0BO/ SYEdQqKRqgCqgApQdmChDxNkv1L2n2G2SUdNUPczD/Q/MUw/HoATzxTfCn/XHu8f/yEJRCDAb/Mv HJ/zNS+qYmZh1tFz00mgYAC/opHk4xtCFrlxnwN2bpdg/mdeoL8BOFEAESG/Is/EvT8BcXFQb8IX VDyzOIFJUPYtEFEYwWQITy4/IM8yj/8znw2fJQ8mH1zbKt9h8ifx/Re1MnQBl1BgodGAmLGkAv/k QBhy0TC/1HSRMNk7r2Hy/6IwNW82fzSMMb9CT0NfNO+/Ri9HP7GEs5qKIg+xdZaA/7RfSZ9Hr00/ Tk8j/zi/Oc//XNwp0kB/YfLkMV3AshCikv9icJaA5aKkAGAA66HkMs5zz/giG49Ub/VMRXh4saKS PxbGUB9RL0QNKdLsMGlk/wCwKr+aBdngWPMY0G/0hrH9qUFtRY9ff08vZT9mT/If78zjZzBztIWw a6GhLIEZov+qYWOiWm9bf/VMzQFiT+bzv2QB5aKE4g9g67BYoHeKkz9oH2kvZzyqgZhw67B5ZfPk 0amAIGqEQAHQa7/OZP++YWOUcK+D07OgbEDOY21//26PgV5zf3SPiV4O1XjWd2P9vpBwzlIHoXaE 5DIpzHm//3rEYePkEORBvmB+z3/fZzz/B+DNsHe2WKBsIKFRZQ+If/9nL4vfjO9qX1NffL/1TLqg PwPjvmEAE4U/99SjIXMt8FZMQU4Yhs2w55FE4H/WuB6vj7+Nz5m/ms+gDiD+Wpugm6CSD5Mf9U/V swHlV5X/V6QQMGO0Ejv/MCf/siAHkGQC69HCQOUxe6+hT/9VfRgTe0CHX52PLz+VFLOT/8WwbLOk L6U7wkATkM5V/5L/PQKLr6vvm6+yX7NvkP+gP9+oX6JeKqEqoXcwbXbwGDL945Bs+EG+Ya8vGwKt 5bhQ/HNjguDZYXMjAHBdgbIv/7Y/tE/AT8FfN6+4n7mvb6zvzoJZJAFR65J5A+Bj5NCQw70vGwJt aXh0eJLnkfNhxhCiUkJh1JmPxC/CPf/Jb7vzYbeLMVZfveiEz8cG9GFtx7omoonSo2OTzn//z4/C P9lf2m9SXh6Aa2A889+jcVMwvEQQg1gyeiyg5BC+YuNx0/8bAkAwG1BB5WJ/u/lyddw/3U91nXMD sPBr+Q/CYWIBsgGgleDgMQ/y/3sE4d9Bg8AP5c/bP+uv7L//3m/fcdXfx49VjD/UzfZ5Rf+LMTEC hG/WD9cfJ5Su7xHm/5+wXYVhxe6f76/m/ilw6QL3WKJ4xYcga9kv/e/trwF/8wKPxW8gT790l1n6 nxsC/xgjKXASZYpyPvGVwCggl7L/4BBZkj23BF8FbwN8exF3MP/KAKdP8w+ULdKyinKCIVmS+wjf vjNlvxBygSggEG/4v//X/BOlKMEDUMyA6WFzXw3f+wNeewBvuECZQliReDADYP8QXxFvOs8Ujzzh Qc8bXwNf/yMPJB8lK/HQ34HRgHLBeSHn6CLolVMwbi2YyjCweSE/irZMcYPQRREhX+LUUEz+UyX/ Jw+JnZkG648vbyUPfzIvMz8Gnx5/H4+ibWzwJ+89YTmAFbA/wHnkIpj3u8D/0oAuIocALN96w6Pg NQ82H380Lz9fQG+e7ThPOV+iXEH3o4JiAEFAcrDwD9FGoBAh/mWHAKZgo2KmZC4iPGkUH/299mxZ 8K6QMf9DL2COo2L/6UJ24aOReVGDkkkBRX8XT/+696bBAQB5coIh45EP8Qsg/+ORmMFLz8xDMX9N /08PQc9/WP9aD/FlRW9Gf6lvqnUnh5WwyraC8HJ1Z2cK0f2CIHR5IHLBeDCw4M1wvCD/DMBWT+sU dzBNEaXRUf9TD39av1vPXN9oxIMwSxDMgHrvZiMeb1+fOm9uhwCLMcqC/nfg0OljeIDR8IcgVSHg Qd+HEndjZJ/MQ3hCYWkvaj//5v074YPQsNABT3U/Wl937/94/0RvbP9uD8icCAG+kxnU8xoCGbBM MlViviHpYJiR/6ph4BByj+Lifh9nn/nK0oX/8bCYAOAQgTN6z3vf5v6ms8mCmmVpvkBMM4N/sC/+ eVg/id9534/PkN8oPfHv/38PR37M0cqCLEbgc7wXkaDxc/FNU0RWMJrDjX9XZ+8Kwpcg4NCgAWeS r5O/kcz/YuBjoIKRLKELs4+fnx+Rv/+iP6NPt3+V75b/9B/KgTuC7x4A92+99qFxLc31nYehBP8K cIeD9fQrwqUfpi+kPEuCf62yC7Js76l/bw8pcWGwY39x4Kxv4uIIg4HCu7OPIGz5CyBmabTAmcSk IEuBY+D/ZjOhcbBvsX+kPHFiog+87/+kL79fwG+U70hRcTDSwcsffz6VrhQAs7nRrAT2ywAEd/+6 YEkQ9SL8dMI/w0/BXD0R8/UibGBkZGMz6JFjMcYv/wnji+EMwCygCrBI4eSg9wD9wUBjzyBiATuR qCCoMOhy/+Nw6dAskb8vy+/BT9N/1I//p1+ob7U/tk5NIEoBxg8JxPxxdfzAbK/af9uPE0DRo/+D M7nQVQLkZefDK3rWX9dv39V89bAaEwsxLHBnZm0Jpv2BMHLSII7w3w/gH6qNSfD7gXAZcWf3MIFw DGArgsfw/4FwCpVmUfUi1VAd0bdw5I//5Z8O/49AuiHojy3ijtAskf8d0O3SACLIw8d1yRbzBgEC /yvg00/xH9Vv+B/5L8R/6l8/62+APMfyKhTzjy3jVFW/uZFxMIhQd7z/HwAvSGJy/ymSybBjAAVg KgUHUUmQd7//+//6Dwi/Cc/Yn/4/BO+2TOZGS5FisGZlydAB7y3iv1EAjHCvQWGAj0BwsHlIcZ/F oyvxAUPSZhJCYnnjUL8i7wyfCq33gIFSVUFmTSD/j0CvUD7xKmESb9A1O1WsBB+5IxdhSHH04D0w QUMtfQqgLR5RmhEWzxffCrxh/3FQjHBkUbohjABQld0frVX70QDPAW337yAvCq8lfyaP/zdP4fBx EMgBr5CBcIy0YqDpSLFkYa9QcwdhgWEHIdxhY9HAbDCDJHLHda/AfmMjf9BDVXF0LylfJ21X+kcv Ei40UA7/EA+YHwch3fMRZLowcQGdsHMHINBg/8pC3oYIjzH/J2853zrvO/r8TG8O3zV/270vbwLy b+DPyDMvQLnRLeB0dfMzZEL/OXHkQVVxykJLUIxxrCJJYP/Qwc3VPL89zzvct6CMcaGA/y0hi+GD bxw30iI5FyVPSO9PO89OX09vUHpKb88gVP+BQLegP+9A/+xuzkEHkhoh7m33kM8gJNFkVJBsQGKB /3EBjLASQNBgS9/QVUaTyeG/ykBRP1JPUFzHcPMga67D/+fiLzDFwUdTcQFjgHEQyVDfd0CIUDR/ Vd+2TE9QUBVE+mzJMGtLv3N1WJKaw52w71w/XU8hT1AwYwfQumCPYb8eA0XRZLpnFWVvMGRyt6D7 jADqEXXSIDReaF9pb1Ev/3BfKm8rcWGfYq+2Xrn08xHnmiDN8SvBc2s42xrzudH/YLFtHwLyImGF 4MfCLwQfD/9zT8zvIuJ5MWEwOMFgwLpQ//TgYY92r3e7gh+DL+E86hC/jyAsMO+wLhC5krpQZ27w /6wv0BYH8rd0LyG54OP1b0+fft9xb4xPjV+OalBhnRD/dZ+F/1bvr8ChQQhgJSAjUf9q8O/AWPDk UtJB7tAjTyRZ/2Cw6dDKIC8iGiCzYc8gq5H/LABZUGd/kC+OPcfwWVEjMP9NMYtF4yUR8ZpSWaAB sI4i/4H/k29B/5ev0HBXwl9glbP7OIDHxnSan5uvGO8Z9Jdg/zP0K9J5UH0BRyMapqnxbvH/t2Hn oJ4Cox8cVTPiyfKlz/+m30oNiBCBQNMRndUiIdEA/y3gylBhfa7/sA+PH7PPdG+PdX+hD3efylFJ RVM0AP3SIC3jECMwzy/QNJZhYJT/ylFK5aAfuh+7L1/4re+2n/+3r+gBgcFuoSKhmlCZMFlQ/juA xJdv0DRGnLK/xL+03//Kv8vP/T7+L8CvAE8BUe5Dv1lRTTNEwi8TFVMHIWPu8P9bsPNfHCfMoHng w3Ltgc2fz86vXl5lMONhdXC/r9H/9cHMMvMBdkRi47C+47JB/mTj0IDR2GHWFu3A1o9uFP8UgdxP 3V+HDS1gHiB7I6owf9i/2c/MvGcUZPF5Me/AM3wgKCIhFBFuYi0gmNYp/+NP5F9jri4A4a8cRQhR 62H9RnFw9NCfgi0gvvGaj+gP/6fevxFs4RpxeeAH1JcDX4W/JT/zf8yf95/4r/m7VrJhq++vWxNL qiBwxyBsP9//7W+UfxRRS3GV4i6AlpXUY/8uU0eEvyc0bwCvoi/9/1tA/lktYPqP+5/5rIvS6khr ov/fYSxGSuUa8vIhYMGkoS5E/wifinX3fwsf+Z8SPxNPFFreLRgQFR8WLxQ8XxtPHF9/HSoYTxlf FDwuphCPZoNh/2sBRvEUEFuQHj8fTyBfLtKmQEcgiFFsLp8QZyPPpyTfFD8F2zxBWvRo1NAIZj0i WCB0cDov1C93LTAuJ0gvIwKkkFxuLyOCKfCZwC8mxSKvKSkoAIHAxyBkKAJmqPADKfBbkHtIWVBF UuBMSU5LICy/Lc8u3Ex9fTBhqPBycwYwXPBjZjFckkApwJ0IMl9/M28u+QcXBwcU8DnvFO458d9A PC9BKSAn7yj/Kg8FPek1PqEvRk9OVP8++Tp/B3BbAkLYP/ha8z//VfAGNz1CUD2eMCvBL9hESVZC L0ZPZzsBWxMTSq9LvzU4PVFCT0ReWT2d30BM709xNz1RSChUTUw+8H1RoAAeADUQAQAAAD8AAAA8 QkI2RDc0Qzc1Q0M3NkE0MTlCNkQ2RkE3QzM4MzE3QjI3OENBMjlAc2luZXR0LXNicy5TaU5ldHQu TEFOPgAAHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAABKAAAAUgBF ACUAMwBBACAAWwByAGIAcgBpAGQAZwBlAF0AIABkAHIAYQBmAHQAIABXAEcAIABtAGkAbgB1AHQA ZQBzAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMKh4WcVNrsUBQAAIMKwydxZOrsUBAwDeP69vAAAD APE/CQQAAB4A+D8BAAAADwAAAFZpc2h3YXMgTWFucmFsAAACAfk/AQAAAF0AAAAAAAAA3KdAyMBC EBq0uQgAKy/hggEAAAAAAAAAL089U0lORVRUL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQ L0NOPVJFQ0lQSUVOVFMvQ049VklTSFdBUwAAAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3Ry YXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/k BAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAAAAgAAABWSVNIV0FTAB4A MUABAAAACAAAAFZJU0hXQVMAHgAyQAEAAAAbAAAAcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcA AB4AM0ABAAAAFgAAAGVyaWsubm9yZG1hcmtAc3VuLmNvbQAAAB4AOEABAAAACAAAAFZJU0hXQVMA HgA5QAEAAAACAAAALgAAAAMAdkD/////CwApAAAAAAALACMAAAAAAAMABhAweU/pAwAHEFAzAAAD ABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASEksPz8/P0lTTUUoVklTSFdBUylCRVNJREVTIj8/ Pz86QVJFWU9VQ09OU0lERVJJTkdTT01FVEhJTkdMSUtFTVNEUExJS0VNVUxUSVBMRVNQQU5OSU5H VFJFRVNQRVJWTEFOUwAAAAACAX8AAQAAAD8AAAA8QkI2RDc0Qzc1Q0M3NkE0MTlCNkQ2RkE3QzM4 MzE3QjI3OENBMjlAc2luZXR0LXNicy5TaU5ldHQuTEFOPgAAOzk= ------_=_NextPart_001_01C5AE4E.1668E4A8-- Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7VEplk21360 for <rbridge@postel.org>; Wed, 31 Aug 2005 07:51:48 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j7VEpfKw020924; Wed, 31 Aug 2005 10:51:42 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03461; Wed, 31 Aug 2005 10:51:41 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <R3MGZKR6>; Wed, 31 Aug 2005 10:51:40 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0C885E30@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" <Eric.Gray@marconi.com> To: "Erik Nordmark (E-mail)" <erik.nordmark@sun.com> Date: Wed, 31 Aug 2005 10:51:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: eric.gray@marconi.com Cc: "'Developing a hybrid router/bridge.'" <rbridge@postel.org> Subject: Re: [rbridge] draft WG minutes X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Aug 2005 14:52:25 -0000 Status: RO Content-Length: 18877 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@postel.org --> [mailto:rbridge-bounces@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@postel.org --> http://www.postel.org/mailman/listinfo/rbridge --> Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7VE1lk05172 for <rbridge@postel.org>; Wed, 31 Aug 2005 07:01:48 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7VE1lTW005065 for <rbridge@postel.org>; Wed, 31 Aug 2005 08:01:47 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5.Beta0+Sun/8.13.5.Beta0) with ESMTP id j7VE1jPo450208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2005 07:01:46 -0700 (PDT) Message-ID: <4315B84A.9030304@sun.com> Date: Wed, 31 Aug 2005 07:01:46 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: [rbridge] draft WG minutes X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 31 Aug 2005 14:02:30 -0000 Status: RO Content-Length: 16205 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. --- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7TEvmk26860 for <rbridge@postel.org>; Mon, 29 Aug 2005 07:57:48 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0ILZ003DGO85A800@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 29 Aug 2005 07:57:41 -0700 (PDT) Received: from sun.com ([129.150.24.164]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0ILZ00LKWO84FN00@mail.sunlabs.com> for rbridge@postel.org; Mon, 29 Aug 2005 07:57:41 -0700 (PDT) Date: Mon, 29 Aug 2005 07:57:38 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <BB6D74C75CC76A419B6D6FA7C38317B2984AF1@sinett-sbs.SiNett.LAN> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <43132262.5080002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <BB6D74C75CC76A419B6D6FA7C38317B2984AF1@sinett-sbs.SiNett.LAN> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 29 Aug 2005 14:58:08 -0000 Status: RO Content-Length: 2754 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@postel.org [mailto:rbridge-bounces@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@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7T9MKk15257 for <rbridge@postel.org>; Mon, 29 Aug 2005 02:22:20 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 29 Aug 2005 02:23:36 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2984AF1@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Doubts about Rbridge Thread-Index: AcWqlQ1ekVdn1mgkQzKjvT1mgcj6gAB5WTeQ From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7T9MKk15257 Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 29 Aug 2005 09:23:09 -0000 Status: RO Content-Length: 1765 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@postel.org [mailto:rbridge-bounces@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 Received: from imail4.gazeta.pl (imail4.gazeta.pl [193.42.231.135]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7T8mRk05590 for <rbridge@postel.org>; Mon, 29 Aug 2005 01:48:28 -0700 (PDT) Received: from poczta.gazeta.pl (unverified [172.20.25.75]) by (imail4.gazeta.pl) with ESMTP id 35282718 for <rbridge@postel.org>; Mon, 29 Aug 2005 10:48:17 +0200 Received: from ew10 (unverified [172.20.26.240]) by av.gazeta.pl (av.gazeta.pl) with ESMTP id 488874 for <rbridge@postel.org>; Mon, 29 Aug 2005 10:48:15 +0200 Message-ID: <15396086.1125305297383.JavaMail.webadm@ew10> Date: Mon, 29 Aug 2005 10:48:17 +0200 (CEST) From: Wojtek Paprowicz <quasarus@gazeta.pl> To: rbridge@postel.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-mailer: (c)Agora mailer (v4.00) Organization: Agora S.A. X-IP: 192.35.17.15 X-Complaints-To: abuse@gazeta.pl X-URL: http://www.gazeta.pl X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: quasarus@gazeta.pl Subject: [rbridge] Convergence time X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 29 Aug 2005 08:49:07 -0000 Status: RO Content-Length: 488 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 Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7T4iRk01077 for <rbridge@postel.org>; Sun, 28 Aug 2005 21:44:29 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sun, 28 Aug 2005 21:45:40 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2984AD1@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Summary 1 of load-balancing rbridges Thread-Index: AcWfh5/r6s/yMxAySOCoPKoToktvMQMzAdpw From: "Vishwas Manral" <Vishwas@sinett.com> To: "Joe Touch" <touch@ISI.EDU> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7T4iRk01077 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@sun.com Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 29 Aug 2005 04:45:14 -0000 Status: RO Content-Length: 2813 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@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Alia Atlas > Sent: Thursday, August 11, 2005 11:43 PM > To: Radia.Perlman@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----- Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7QN92h17456 for <rbridge@postel.org>; Fri, 26 Aug 2005 16:09:02 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.226.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7QN92WR005703 for <rbridge@postel.org>; Fri, 26 Aug 2005 17:09:02 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5.Beta0+Sun/8.13.5.Beta0) with ESMTP id j7QN91BT813156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2005 16:09:01 -0700 (PDT) Message-ID: <430FA10D.8050002@sun.com> Date: Fri, 26 Aug 2005 16:09:01 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B290E4F6@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E4F6@sinett-sbs.SiNett.LAN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 26 Aug 2005 23:09:45 -0000 Status: RO Content-Length: 1215 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 Received: from [192.168.1.45] (pool-141-158-231-93.phil.east.verizon.net [141.158.231.93]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7K5XXf28681; Fri, 19 Aug 2005 22:33:33 -0700 (PDT) Message-ID: <4306C0A7.6070603@isi.edu> Date: Fri, 19 Aug 2005 22:33:27 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B290E7B4@sinett-sbs.SiNett.LAN> <42FD190A.8070100@isi.edu> <17158.40303.329224.208278@localhost.localdomain> In-Reply-To: <17158.40303.329224.208278@localhost.localdomain> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF7BE77102D8A05CFF274DEBD" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 20 Aug 2005 05:36:04 -0000 Status: RO Content-Length: 1363 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF7BE77102D8A05CFF274DEBD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------enigF7BE77102D8A05CFF274DEBD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBsCnE5f5cImnZrsRAvz7AJ0X92dvIXmGMLswaSChKHlCNizyzwCfbXak p7lg3CcOyKUsNM0j9gruqG8= =tv4T -----END PGP SIGNATURE----- --------------enigF7BE77102D8A05CFF274DEBD-- Received: from dino.dnsalias.com (S010600e02994cd40.vc.shawcable.net [24.80.250.228]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7K33Nf27409 for <rbridge@postel.org>; Fri, 19 Aug 2005 20:03:23 -0700 (PDT) Received: by dino.dnsalias.com (Postfix, from userid 1000) id 9E5CA11F360; Fri, 19 Aug 2005 20:03:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17158.40303.329224.208278@localhost.localdomain> Date: Fri, 19 Aug 2005 20:03:11 -0700 To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FD190A.8070100@isi.edu> References: <BB6D74C75CC76A419B6D6FA7C38317B290E7B4@sinett-sbs.SiNett.LAN> <42FD190A.8070100@isi.edu> X-Mailer: VM 7.07 under Emacs 21.3.1 From: stephen@dino.dnsalias.com (Stephen J. Bevan) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: stephen@dino.dnsalias.com Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 20 Aug 2005 03:03:27 -0000 Status: RO Content-Length: 380 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. Received: from [192.168.1.45] (pool-71-105-95-19.lsanca.dsl-w.verizon.net [71.105.95.19]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7DIEVf01712; Sat, 13 Aug 2005 11:14:31 -0700 (PDT) Message-ID: <42FE3881.6040104@isi.edu> Date: Sat, 13 Aug 2005 11:14:25 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> <C11B162F-3A2E-4169-9A2E-9E7E811348A4@castlepoint.net> In-Reply-To: <C11B162F-3A2E-4169-9A2E-9E7E811348A4@castlepoint.net> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7844C583B93AFFC7575ED1D4" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 13 Aug 2005 18:15:21 -0000 Status: RO Content-Length: 1744 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7844C583B93AFFC7575ED1D4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------enig7844C583B93AFFC7575ED1D4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/jiBE5f5cImnZrsRAiMyAKCFYT06cN6VQAUdNNzy3X5yOoWImgCfeVXQ xl7FM10FMiWVSHGCig8Vj9g= =Vl6p -----END PGP SIGNATURE----- --------------enig7844C583B93AFFC7575ED1D4-- Received: from mail.castlepoint.net (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7DAB3f29150 for <rbridge@postel.org>; Sat, 13 Aug 2005 03:11:03 -0700 (PDT) Received: from [172.16.15.1] (unknown [172.16.15.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.castlepoint.net (Postfix) with ESMTP id D1ED8426E6 for <rbridge@postel.org>; Sat, 13 Aug 2005 04:11:02 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <42FD1AF9.2010100@isi.edu> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <C11B162F-3A2E-4169-9A2E-9E7E811348A4@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante <shane@castlepoint.net> Date: Sat, 13 Aug 2005 04:10:59 -0600 To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-Mailer: Apple Mail (2.733) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: shane@castlepoint.net Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 13 Aug 2005 10:11:52 -0000 Status: RO Content-Length: 893 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 > <mime-attachment> Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7D88Hf06018 for <rbridge@postel.org>; Sat, 13 Aug 2005 01:08:17 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sat, 13 Aug 2005 01:09:34 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E868@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Summary 1 of load-balancing rbridges Thread-Index: AcWfinYqNqm8fQz0RVqSUXTYJHfppAAU358g From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7D88Hf06018 Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Sat, 13 Aug 2005 08:09:00 -0000 Status: RO Content-Length: 2687 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@postel.org [mailto:rbridge-bounces@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 <touch@ISI.EDU> 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@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CMgDf10214; Fri, 12 Aug 2005 15:42:13 -0700 (PDT) Message-ID: <42FD25C9.6050106@isi.edu> Date: Fri, 12 Aug 2005 15:42:17 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <20050812172132.11BA4136C82@aharp.ittns.northwestern.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 22:42:51 -0000 Status: RO Content-Length: 1288 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Kristoff wrote: > On Fri, 12 Aug 2005 16:29:09 +0100 > Mike Hughes <mike@linx.net> 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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CLx5f26547; Fri, 12 Aug 2005 14:59:05 -0700 (PDT) Message-ID: <42FD1BAD.4070600@isi.edu> Date: Fri, 12 Aug 2005 14:59:09 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch <touch@ISI.EDU> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <42FD1AF9.2010100@isi.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 21:59:52 -0000 Status: RO Content-Length: 1751 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: > > > John Kristoff wrote: > >>>On Thu, 11 Aug 2005 14:40:33 -0700 >>>Joe Touch <touch@ISI.EDU> 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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CLu5f25973; Fri, 12 Aug 2005 14:56:05 -0700 (PDT) Message-ID: <42FD1AF9.2010100@isi.edu> Date: Fri, 12 Aug 2005 14:56:09 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 21:56:50 -0000 Status: RO Content-Length: 1350 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Kristoff wrote: > On Thu, 11 Aug 2005 14:40:33 -0700 > Joe Touch <touch@ISI.EDU> 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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CLlnf23699; Fri, 12 Aug 2005 14:47:49 -0700 (PDT) Message-ID: <42FD190A.8070100@isi.edu> Date: Fri, 12 Aug 2005 14:47:54 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral <Vishwas@sinett.com> References: <BB6D74C75CC76A419B6D6FA7C38317B290E7B4@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E7B4@sinett-sbs.SiNett.LAN> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@sun.com Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 21:48:50 -0000 Status: RO Content-Length: 3693 -----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@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of Alia Atlas > Sent: Thursday, August 11, 2005 11:43 PM > To: Radia.Perlman@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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CHtof16980; Fri, 12 Aug 2005 10:55:50 -0700 (PDT) Message-ID: <42FCE2AA.1060006@isi.edu> Date: Fri, 12 Aug 2005 10:55:54 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <42FC9B83.1030600@cisco.com> In-Reply-To: <42FC9B83.1030600@cisco.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] questions on optimizing multicast X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 17:56:59 -0000 Status: RO Content-Length: 2429 -----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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CHcef12308 for <rbridge@postel.org>; Fri, 12 Aug 2005 10:38:40 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 37so654995wra for <rbridge@postel.org>; Fri, 12 Aug 2005 10:38:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Rfe84ch058jwh1rgiLORFUm776P3lMKRXEDZ+OZhPJ3HCDD19v3BpGiW3UeKhzY8dbiannyXJE3hLjciV4zRAVT5Nxwo6BxFVQMCZ0RsVbIDlCrY7E9uqD+ynH5pCOAko+RQE5k2LVO9zTc0hFPPiwhEUGDFJV4mBx0qEQHKkBE= Received: by 10.54.3.18 with SMTP id 18mr545360wrc; Fri, 12 Aug 2005 10:38:35 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Fri, 12 Aug 2005 10:38:35 -0700 (PDT) Message-ID: <6280db5205081210387b749e12@mail.gmail.com> Date: Fri, 12 Aug 2005 10:38:35 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E7B8@sinett-sbs.SiNett.LAN> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <BB6D74C75CC76A419B6D6FA7C38317B290E7B8@sinett-sbs.SiNett.LAN> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7CHcef12308 Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 17:39:16 -0000 Status: RO Content-Length: 1255 Hi Vishwas, On 8/11/05, Vishwas Manral <Vishwas@sinett.com> 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 Received: from aharp.ittns.northwestern.edu (aharp.ittns.northwestern.edu [129.105.153.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CHLbf07827 for <rbridge@postel.org>; Fri, 12 Aug 2005 10:21:37 -0700 (PDT) Received: from localhost.localdomain (aharp [127.0.0.1]) by aharp.ittns.northwestern.edu (smtpd) with ESMTP id 11BA4136C82 for <rbridge@postel.org>; Fri, 12 Aug 2005 12:21:32 -0500 (CDT) Date: Fri, 12 Aug 2005 12:21:32 -0500 From: John Kristoff <jtk@northwestern.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <53B74F39D903B10C7A2380A8@Mike_HP.linx.net> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050812172132.11BA4136C82@aharp.ittns.northwestern.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jtk@northwestern.edu Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 17:21:47 -0000 Status: RO Content-Length: 730 On Fri, 12 Aug 2005 16:29:09 +0100 Mike Hughes <mike@linx.net> 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 Received: from weathered.linx.net (weathered.linx.net [195.66.232.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CFTRf04258 for <rbridge@postel.org>; Fri, 12 Aug 2005 08:29:27 -0700 (PDT) Received: from [195.66.233.123] (helo=Mike_HP.linx.net) by weathered.linx.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 1E3bTD-0007Us-00 for rbridge@postel.org; Fri, 12 Aug 2005 16:29:19 +0100 Date: Fri, 12 Aug 2005 16:29:09 +0100 From: Mike Hughes <mike@linx.net> To: rbridge@postel.org Message-ID: <53B74F39D903B10C7A2380A8@Mike_HP.linx.net> In-Reply-To: <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-Mailer: Mulberry/3.1.6 (Win32) X-NCC-RegID: uk.linx MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mike@linx.net Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 15:30:06 -0000 Status: RO Content-Length: 1070 --On 12 August 2005 09:43 -0500 John Kristoff <jtk@northwestern.edu> 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@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" Received: from aharp.ittns.northwestern.edu (aharp.ittns.northwestern.edu [129.105.153.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CEi1f21276 for <rbridge@postel.org>; Fri, 12 Aug 2005 07:44:01 -0700 (PDT) Received: from localhost.localdomain (aharp [127.0.0.1]) by aharp.ittns.northwestern.edu (smtpd) with ESMTP id F3A4A136C82 for <rbridge@postel.org>; Fri, 12 Aug 2005 09:43:55 -0500 (CDT) Date: Fri, 12 Aug 2005 09:43:55 -0500 From: John Kristoff <jtk@northwestern.edu> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FBC5D1.4090408@isi.edu> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <20050812144355.F3A4A136C82@aharp.ittns.northwestern.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: jtk@northwestern.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7CEi1f21276 Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 14:44:47 -0000 Status: RO Content-Length: 538 On Thu, 11 Aug 2005 14:40:33 -0700 Joe Touch <touch@ISI.EDU> 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 Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7CCqUf21891 for <rbridge@postel.org>; Fri, 12 Aug 2005 05:52:30 -0700 (PDT) Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 12 Aug 2005 18:27:42 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7CCpobe016783 for <rbridge@postel.org>; Fri, 12 Aug 2005 12:52:14 GMT Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Aug 2005 18:22:21 +0530 Received: from [10.77.202.135] ([10.77.202.135]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Aug 2005 18:22:20 +0530 Message-ID: <42FC9B83.1030600@cisco.com> Date: Fri, 12 Aug 2005 18:22:19 +0530 From: Ganesh CS <gsankara@cisco.com> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2005 12:52:20.0934 (UTC) FILETIME=[AD9A1E60:01C59F3C] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gsankara@cisco.com Subject: [rbridge] questions on optimizing multicast X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 12:52:46 -0000 Status: RO Content-Length: 1446 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 Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7C4R0f12390 for <rbridge@postel.org>; Thu, 11 Aug 2005 21:27:00 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 11 Aug 2005 21:28:16 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E7B8@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] load-balancing rbridges Thread-Index: AcWetHf4uFb31aCuS9yKA9CBdOURfgAQQjEg From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7C4R0f12390 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 04:27:49 -0000 Status: RO Content-Length: 2530 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@postel.org [mailto:rbridge-bounces@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 <riw@cisco.com> 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 Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7C4CTf08727 for <rbridge@postel.org>; Thu, 11 Aug 2005 21:12:29 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 11 Aug 2005 21:13:43 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E7B4@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Summary 1 of load-balancing rbridges Thread-Index: AcWeokAt6OpjbnTHTOC3avcZl+lTJgAT5KZg From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org>, <Radia.Perlman@sun.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7C4CTf08727 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2005 04:13:12 -0000 Status: RO Content-Length: 2441 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@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Alia Atlas Sent: Thursday, August 11, 2005 11:43 PM To: Radia.Perlman@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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BMJof01844; Thu, 11 Aug 2005 15:19:50 -0700 (PDT) Message-ID: <42FBCF0A.6050108@isi.edu> Date: Thu, 11 Aug 2005 15:19:54 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <1123798064.14955.133.camel@thunk> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 22:20:46 -0000 Status: RO Content-Length: 1441 -----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----- Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BM85f28136 for <rbridge@postel.org>; Thu, 11 Aug 2005 15:08:05 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7BM7kx7019974; Thu, 11 Aug 2005 16:07:46 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7BM7k5K017689; Thu, 11 Aug 2005 18:07:46 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7BM7jnZ016139; Thu, 11 Aug 2005 18:07:45 -0400 (EDT) From: Bill Sommerfeld <sommerfeld@sun.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FBC681.4070409@isi.edu> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1123798064.14955.133.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 11 Aug 2005 18:07:45 -0400 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: sommerfeld@sun.com Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 22:08:47 -0000 Status: RO Content-Length: 764 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BLicf20338; Thu, 11 Aug 2005 14:44:38 -0700 (PDT) Message-ID: <42FBC6C9.3020702@isi.edu> Date: Thu, 11 Aug 2005 14:44:41 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <6280db52050811132055711a18@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 21:45:15 -0000 Status: RO Content-Length: 1010 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/11/05, Spencer Dawkins <spencer@mcsr-labs.org> 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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BLhPf19994; Thu, 11 Aug 2005 14:43:25 -0700 (PDT) Message-ID: <42FBC681.4070409@isi.edu> Date: Thu, 11 Aug 2005 14:43:29 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> In-Reply-To: <6280db5205081111506c19d2bb@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 21:43:48 -0000 Status: RO Content-Length: 831 -----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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BLeTf19250; Thu, 11 Aug 2005 14:40:30 -0700 (PDT) Message-ID: <42FBC5D1.4090408@isi.edu> Date: Thu, 11 Aug 2005 14:40:33 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin <zinin@psg.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <1499440946.20050811115706@psg.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@sun.com Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 21:40:57 -0000 Status: RO Content-Length: 1256 -----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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BLa8f17666; Thu, 11 Aug 2005 14:36:09 -0700 (PDT) Message-ID: <42FBC4CC.5020200@isi.edu> Date: Thu, 11 Aug 2005 14:36:12 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White <riw@cisco.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <42FB9D30.6030300@cisco.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@sun.com Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 21:37:23 -0000 Status: RO Content-Length: 3234 -----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@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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BKcBf00464; Thu, 11 Aug 2005 13:38:11 -0700 (PDT) Message-ID: <42FBB736.6010607@isi.edu> Date: Thu, 11 Aug 2005 13:38:14 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [rbridge] slides from IETF63 posted to website X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 20:39:10 -0000 Status: RO Content-Length: 442 -----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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BKRVf26839 for <rbridge@postel.org>; Thu, 11 Aug 2005 13:27:31 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so470487wri for <rbridge@postel.org>; Thu, 11 Aug 2005 13:27:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bWnDc/ECkdsjt3l/bD92cr5FWEfUu9dxyekiQWqFaWWclUzzkHhZDiKxIJlXrAQKIATtNpB5OYs5lhuoHW02p/FRJwys6Euvn0FsCFuel9GpzkPCk9NUrLd5hz8Dm1/p4a31eMTHwmIVcKzEyVJcHt6SC/NuFflO49PSSKrUYFg= Received: by 10.54.160.5 with SMTP id i5mr1435953wre; Thu, 11 Aug 2005 13:27:25 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Thu, 11 Aug 2005 13:27:25 -0700 (PDT) Message-ID: <6280db520508111327ba54dac@mail.gmail.com> Date: Thu, 11 Aug 2005 13:27:25 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FBAB23.8070605@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7BKRVf26839 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 20:27:47 -0000 Status: RO Content-Length: 1537 On 8/11/05, Russ White <riw@cisco.com> 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 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BKKOf24935 for <rbridge@postel.org>; Thu, 11 Aug 2005 13:20:24 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so468859wri for <rbridge@postel.org>; Thu, 11 Aug 2005 13:20:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HQdcTB84T+r0n3++RN+WOXcrTtG0wsQbtlNwfiLCIiCYQCoZgn2r6p7dj8JN1s+4oiaJosAa4fcDPliQcXAQxfKaxLDwKtDKYL/52LlElBT1BE2cQ7grZpBkMx3GoLABIVvMWCZC9yrHpjV6GCFHJSrUWFA9nVNPmpjztDkYir0= Received: by 10.54.34.20 with SMTP id h20mr1450403wrh; Thu, 11 Aug 2005 13:20:15 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Thu, 11 Aug 2005 13:20:15 -0700 (PDT) Message-ID: <6280db52050811132055711a18@mail.gmail.com> Date: Thu, 11 Aug 2005 13:20:15 -0700 From: Alia Atlas <akatlas@gmail.com> To: spencer@mcsr-labs.org, "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FBA92B.8000004@mcsr-labs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7BKKOf24935 Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 20:20:45 -0000 Status: RO Content-Length: 512 On 8/11/05, Spencer Dawkins <spencer@mcsr-labs.org> 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 Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BJl5f14052 for <rbridge@postel.org>; Thu, 11 Aug 2005 12:47:05 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2005 12:47:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,100,1122879600"; d="scan'208"; a="5655479:sNHT23178788" Received: from russpc (rtp-vpn3-624.cisco.com [10.82.218.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BJknT7017797; Thu, 11 Aug 2005 15:46:57 -0400 (EDT) Received: from [10.82.218.115] by russpc (PGP Universal service); Thu, 11 Aug 2005 15:46:57 -0500 X-PGP-Universal: processed; by russpc on Thu, 11 Aug 2005 15:46:57 -0500 Message-ID: <42FBAB23.8070605@cisco.com> Date: Thu, 11 Aug 2005 15:46:43 -0400 From: Russ White <riw@cisco.com> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> In-Reply-To: <6280db5205081111506c19d2bb@mail.gmail.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 19:47:45 -0000 Status: RO Content-Length: 4488 -----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@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvurMREdu7FIVPTkEQJRIACcDOSohI3mw9dIGGCmbj3+uDRtzk8An1tf Q2eUpqwqag6J0gmbKikEDqy9 =Sh63 -----END PGP SIGNATURE----- Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BJcPf11161 for <rbridge@postel.org>; Thu, 11 Aug 2005 12:38:25 -0700 (PDT) Received: from [127.0.0.1] (unknown[65.104.224.98]) by comcast.net (sccrmhc13) with ESMTP id <2005081119381901300kf6gke>; Thu, 11 Aug 2005 19:38:19 +0000 Message-ID: <42FBA92B.8000004@mcsr-labs.org> Date: Thu, 11 Aug 2005 14:38:19 -0500 From: Spencer Dawkins <spencer@mcsr-labs.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> <6280db5205081111506c19d2bb@mail.gmail.com> In-Reply-To: <6280db5205081111506c19d2bb@mail.gmail.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: spencer@mcsr-labs.org Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: spencer@mcsr-labs.org, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 19:38:42 -0000 Status: RO Content-Length: 1390 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Alia Atlas wrote:<br> <blockquote cite="mid6280db5205081111506c19d2bb@mail.gmail.com" type="cite"> <pre wrap="">Hi Russ, On 8/11/05, Russ White <a class="moz-txt-link-rfc2396E" href="mailto:riw@cisco.com"><riw@cisco.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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: </pre> </blockquote> <pre wrap=""><!----> I think that we do care about out of order packets.</pre> </blockquote> Sorry, still synchronizing - what we're talking about is introducing additional misordering, right?<br> <br> 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...<br> <br> Spencer<br> </body> </html> Received: from psg.com (mailnull@psg.com [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BIvLf29055 for <rbridge@postel.org>; Thu, 11 Aug 2005 11:57:21 -0700 (PDT) Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3IEx-0002Ti-JD; Thu, 11 Aug 2005 18:57:19 +0000 Date: Thu, 11 Aug 2005 11:57:06 -0700 From: Alex Zinin <zinin@psg.com> X-Priority: 3 (Normal) Message-ID: <1499440946.20050811115706@psg.com> To: Alia Atlas <akatlas@gmail.com> In-Reply-To: <6280db52050811111261beb2ef@mail.gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: zinin@psg.com Cc: "Developing a hybrid router/bridge." <rbridge@postel.org>, Radia.Perlman@sun.com, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Alex Zinin <zinin@psg.com>, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 18:57:44 -0000 Status: RO Content-Length: 1947 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@postel.org > http://www.postel.org/mailman/listinfo/rbridge Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BIp4f26702 for <rbridge@postel.org>; Thu, 11 Aug 2005 11:51:04 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so447084wri for <rbridge@postel.org>; Thu, 11 Aug 2005 11:50:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mNU0HyPne3BocjxtNVNsrqKO6fhZfkJi0mb/+mIo67xAgSgvhDSOfrUfDzwN1IjTyy+I1UDrenhB7K1q9rgEi4cjdmNpwBAskKprxIjLVDNR1ztQq8DLcpYEis+20WiXGu2MQZwcvk491psRSH31b5kKUPnZzTz5flHPkIOiH7A= Received: by 10.54.34.20 with SMTP id h20mr1402293wrh; Thu, 11 Aug 2005 11:50:59 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Thu, 11 Aug 2005 11:50:59 -0700 (PDT) Message-ID: <6280db5205081111506c19d2bb@mail.gmail.com> Date: Thu, 11 Aug 2005 11:50:59 -0700 From: Alia Atlas <akatlas@gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FB6D3C.6090607@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FB6D3C.6090607@cisco.com> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7BIp4f26702 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 18:51:43 -0000 Status: RO Content-Length: 4056 Hi Russ, On 8/11/05, Russ White <riw@cisco.com> 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 Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BIlWf25545 for <rbridge@postel.org>; Thu, 11 Aug 2005 11:47:32 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2005 14:47:27 -0400 X-IronPort-AV: i="3.96,100,1122868800"; d="scan'208"; a="66184683:sNHT32162644" Received: from russpc (rtp-vpn3-624.cisco.com [10.82.218.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BIlJT7003205; Thu, 11 Aug 2005 14:47:24 -0400 (EDT) Received: from [10.82.218.115] by russpc (PGP Universal service); Thu, 11 Aug 2005 14:47:24 -0500 X-PGP-Universal: processed; by russpc on Thu, 11 Aug 2005 14:47:24 -0500 Message-ID: <42FB9D30.6030300@cisco.com> Date: Thu, 11 Aug 2005 14:47:12 -0400 From: Russ White <riw@cisco.com> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <6280db52050811111261beb2ef@mail.gmail.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: Radia.Perlman@sun.com, Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 18:48:15 -0000 Status: RO Content-Length: 2932 -----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@postel.org > http://www.postel.org/mailman/listinfo/rbridge - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQvudPBEdu7FIVPTkEQIQ8ACg8BKy0m2cgBfXSQvpiS7NEZVfhpcAoMeS iB5gt5zMk+HA5VM0erc0siV0 =DC2c -----END PGP SIGNATURE----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BIGJf15248 for <rbridge@postel.org>; Thu, 11 Aug 2005 11:16:20 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so438634wri for <rbridge@postel.org>; Thu, 11 Aug 2005 11:16:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ac22eLf3ywOUPNvIqChkj6mVzK4M5vNYlLBRfl7Du/tQOg9eSAgQsk+TwX456+7WBM8SWhIJoR5I4kXRgw+uFwrhb7viiTSD5DnMXXFL7mMUp8+ZJaHle+EvEExKcI7vuGX4VXds29jA6e/2anVVW/x1MVm9D0KpbB7Vm27QlCg= Received: by 10.54.151.4 with SMTP id y4mr1389628wrd; Thu, 11 Aug 2005 11:16:14 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Thu, 11 Aug 2005 11:16:13 -0700 (PDT) Message-ID: <6280db52050811111653f1f02a@mail.gmail.com> Date: Thu, 11 Aug 2005 11:16:14 -0700 From: Alia Atlas <akatlas@gmail.com> To: Radia.Perlman@sun.com, "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FAE575.6050306@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7BIGJf15248 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 18:16:44 -0000 Status: RO Content-Length: 1380 On 8/10/05, Radia Perlman <Radia.Perlman@sun.com> 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 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BICuf14364 for <rbridge@postel.org>; Thu, 11 Aug 2005 11:12:56 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so437783wri for <rbridge@postel.org>; Thu, 11 Aug 2005 11:12:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fgUplDSJnkWNFc0b99AlHLeJ6cOClwmLx//l8CEqJkX/yQqPd7R+k3h5Ai2T+QCgkc86StH3ErFyy1P3jY5O/+WGuWHKqB+v/HlCLpyn0uBqyCUFQRh0PHb+MSn4CjuEwHsCCKurvt7IRsi9Z2bPmBBQG4W+b3zFC8lW2SUBmkg= Received: by 10.54.49.72 with SMTP id w72mr1381504wrw; Thu, 11 Aug 2005 11:12:50 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Thu, 11 Aug 2005 11:12:50 -0700 (PDT) Message-ID: <6280db52050811111261beb2ef@mail.gmail.com> Date: Thu, 11 Aug 2005 11:12:50 -0700 From: Alia Atlas <akatlas@gmail.com> To: Radia.Perlman@sun.com, "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FAE575.6050306@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7BICuf14364 Cc: Joe Touch <touch@ISI.EDU> Subject: [rbridge] Summary 1 of load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 18:13:44 -0000 Status: RO Content-Length: 1459 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 Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7BFMpf21411 for <rbridge@postel.org>; Thu, 11 Aug 2005 08:22:51 -0700 (PDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2005 11:22:46 -0400 X-IronPort-AV: i="3.96,100,1122868800"; d="scan'208"; a="66152268:sNHT31258808" Received: from russpc (rtp-vpn3-624.cisco.com [10.82.218.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7BFMgQm013319; Thu, 11 Aug 2005 11:22:43 -0400 (EDT) Received: from [10.82.218.115] by russpc (PGP Universal service); Thu, 11 Aug 2005 11:22:43 -0500 X-PGP-Universal: processed; by russpc on Thu, 11 Aug 2005 11:22:43 -0500 Message-ID: <42FB6D3C.6090607@cisco.com> Date: Thu, 11 Aug 2005 11:22:36 -0400 From: Russ White <riw@cisco.com> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> In-Reply-To: <6280db5205081014091509a0c6@mail.gmail.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: riw@cisco.com Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 15:23:42 -0000 Status: RO Content-Length: 2740 -----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@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----- Received: from weathered.linx.net (weathered.linx.net [195.66.232.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7B9SMf14630 for <rbridge@postel.org>; Thu, 11 Aug 2005 02:28:23 -0700 (PDT) Received: from [217.158.213.217] (helo=Mike_HP.smashing.net) by weathered.linx.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 1E39MF-0003Zu-00 for rbridge@postel.org; Thu, 11 Aug 2005 10:28:15 +0100 Date: Thu, 11 Aug 2005 10:28:55 +0100 From: Mike Hughes <mike@linx.net> To: rbridge@postel.org Message-ID: <B0A16521C915B5CCA51BDBA2@Mike_HP.smashing.net> X-Mailer: Mulberry/3.1.6 (Win32) X-NCC-RegID: uk.linx MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mike@linx.net Subject: [rbridge] load balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 09:28:42 -0000 Status: RO Content-Length: 2558 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@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7B6ETf17790 for <rbridge@postel.org>; Wed, 10 Aug 2005 23:14:29 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 10 Aug 2005 23:15:43 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E6EE@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] load-balancing rbridges Thread-Index: AcWeOTDSFyO5ZGDCTmOKXVfc7hCFVQAAjCww From: "Vishwas Manral" <Vishwas@sinett.com> To: <Radia.Perlman@Sun.COM>, "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7B6ETf17790 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 06:14:43 -0000 Status: RO Content-Length: 3711 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@postel.org [mailto:rbridge-bounces@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 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7B5hJf17317 for <rbridge@postel.org>; Wed, 10 Aug 2005 22:43:19 -0700 (PDT) Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7B5hIvW002484 for <rbridge@postel.org>; Wed, 10 Aug 2005 23:43:18 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IL100201LL5I2@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rbridge@postel.org; Thu, 11 Aug 2005 01:43:18 -0400 (EDT) Received: from Sun.COM (sr1-umpk-06.SFBay.Sun.COM [129.146.11.166]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IL1006I7MK5XK@bur-mail2.east.sun.com>; Thu, 11 Aug 2005 01:43:18 -0400 (EDT) Date: Wed, 10 Aug 2005 22:43:17 -0700 From: Radia Perlman <Radia.Perlman@Sun.COM> In-reply-to: <6280db5205081016397f9c1774@mail.gmail.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <42FAE575.6050306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Radia.Perlman@Sun.COM, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2005 05:43:43 -0000 Status: RO Content-Length: 2920 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 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7ANdHf14338 for <rbridge@postel.org>; Wed, 10 Aug 2005 16:39:17 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so262463wri for <rbridge@postel.org>; Wed, 10 Aug 2005 16:39:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BeAu/ZpdjibLrhriTedRODDgUxcD95GQMR50OzHO6iJsgtyRGIuE3Gt3Fybv7fixoy3r92FonwYP6bzzx0Bb3xlehjlwRvQIrXSlGLediQolyohqalO6o1dAJ0P2ZqMS/hSl6D/MMX9r3/R/y/EkPwVdQzI72OfQeQonVC+wiKs= Received: by 10.54.47.74 with SMTP id u74mr823079wru; Wed, 10 Aug 2005 16:39:11 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 16:39:11 -0700 (PDT) Message-ID: <6280db5205081016397f9c1774@mail.gmail.com> Date: Wed, 10 Aug 2005 16:39:11 -0700 From: Alia Atlas <akatlas@gmail.com> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <42FA897B.9060400@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7ANdHf14338 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 23:39:41 -0000 Status: RO Content-Length: 2913 On 8/10/05, Joe Touch <touch@isi.edu> 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7ANAnf05551; Wed, 10 Aug 2005 16:10:49 -0700 (PDT) Message-ID: <42FA897B.9060400@isi.edu> Date: Wed, 10 Aug 2005 16:10:51 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <6280db520508101601ef1bd79@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 23:11:43 -0000 Status: RO Content-Length: 3689 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch <touch@isi.edu> 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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AN20f02825 for <rbridge@postel.org>; Wed, 10 Aug 2005 16:02:00 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so256196wri for <rbridge@postel.org>; Wed, 10 Aug 2005 16:01:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dEngDmXKtAAIcV4fxnFuuhYLTNGKrMU67FVHgYAqYiDcRF88OxOgjJ3r7k9vdJNzcsVTzv3E1e9QQLvxBlAE0ZofN11oeWhyvYOphCnuDsoRvW+yOO6hgZV9uRDyhfP0wHQLZ9xps4Cj/aF1N8zQRDqrCn14NkOJH/0baRZWOf4= Received: by 10.54.21.9 with SMTP id 9mr796813wru; Wed, 10 Aug 2005 16:01:54 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 16:01:54 -0700 (PDT) Message-ID: <6280db520508101601ef1bd79@mail.gmail.com> Date: Wed, 10 Aug 2005 16:01:54 -0700 From: Alia Atlas <akatlas@gmail.com> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <42FA84A5.5090108@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7AN20f02825 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 23:02:37 -0000 Status: RO Content-Length: 2473 On 8/10/05, Joe Touch <touch@isi.edu> 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AMoAf29416; Wed, 10 Aug 2005 15:50:10 -0700 (PDT) Message-ID: <42FA84A5.5090108@isi.edu> Date: Wed, 10 Aug 2005 15:50:13 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> In-Reply-To: <6280db52050810154377cb464b@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 22:50:40 -0000 Status: RO Content-Length: 1463 -----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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AMhdf27323 for <rbridge@postel.org>; Wed, 10 Aug 2005 15:43:39 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so253687wri for <rbridge@postel.org>; Wed, 10 Aug 2005 15:43:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t+CeaL4CJLDw54fgRUPibL214OxJdsFo/idunlM62CoXKrDGfrUl1A56EgtU0huIgwem3RruNxNGy8r7AMZHF1SFkRss91QxXzLsHuwaQNgyk5bj8+PrvYeCCw/PofmJfWTH69LC7xQuhqin1E700mEhBv0zzDypjCqi6T7G4HE= Received: by 10.54.57.32 with SMTP id f32mr772750wra; Wed, 10 Aug 2005 15:43:34 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 15:43:34 -0700 (PDT) Message-ID: <6280db52050810154377cb464b@mail.gmail.com> Date: Wed, 10 Aug 2005 15:43:34 -0700 From: Alia Atlas <akatlas@gmail.com> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <42FA7FE4.9030500@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <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> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7AMhdf27323 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 22:44:42 -0000 Status: RO Content-Length: 2663 On 8/10/05, Joe Touch <touch@isi.edu> 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AMTrf23019; Wed, 10 Aug 2005 15:29:53 -0700 (PDT) Message-ID: <42FA7FE4.9030500@isi.edu> Date: Wed, 10 Aug 2005 15:29:56 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> <6280db520508101518f77382e@mail.gmail.com> In-Reply-To: <6280db520508101518f77382e@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 22:31:22 -0000 Status: RO Content-Length: 5411 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch <touch@isi.edu> 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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AMKif20300 for <rbridge@postel.org>; Wed, 10 Aug 2005 15:20:44 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so250277wri for <rbridge@postel.org>; Wed, 10 Aug 2005 15:20:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XTdIz2WTtbDfPNY0k/yRPnx1Esl/0/Rx+J7lD9FY4Tu7epCo7KcSZtMC7xA7KdQeK4dkeLADCkJfFwVv3T47jdsMx1DdbiL7X2Zsbeapc/kfzHo0xAKI+Nl37NX6sze9WFAj1TH9w93vucdysYi2scA7JUaCGmnF4D5RDhk1Ay0= Received: by 10.54.6.3 with SMTP id 3mr765698wrf; Wed, 10 Aug 2005 15:20:39 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 15:20:38 -0700 (PDT) Message-ID: <6280db52050810152018eeb588@mail.gmail.com> Date: Wed, 10 Aug 2005 15:20:38 -0700 From: Alia Atlas <akatlas@gmail.com> To: spencer@mcsr-labs.org, "Developing a hybrid router/bridge." <rbridge@postel.org> In-Reply-To: <42FA7631.2010101@mcsr-labs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA7631.2010101@mcsr-labs.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7AMKif20300 Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 22:21:40 -0000 Status: RO Content-Length: 1232 On 8/10/05, Spencer Dawkins <spencer@mcsr-labs.org> 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 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AMIFf19738 for <rbridge@postel.org>; Wed, 10 Aug 2005 15:18:15 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so249904wri for <rbridge@postel.org>; Wed, 10 Aug 2005 15:18:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DSjYdLXu560mZfW8Ozx2g63MIWt1T6GHmywJmg4f416bWjG0J8oX4r7fNxeuUIuMybqKYOXuRCMzvFN0Z6qF6Q8CW66rLRFn+R1ilnXV22eVxLqXrUjrOXyC05svTcNeCH7STlJV9SQbLHC6zkzXbDLPAweupwq/4fKYDywT/xw= Received: by 10.54.34.61 with SMTP id h61mr762867wrh; Wed, 10 Aug 2005 15:18:09 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 15:18:09 -0700 (PDT) Message-ID: <6280db520508101518f77382e@mail.gmail.com> Date: Wed, 10 Aug 2005 15:18:09 -0700 From: Alia Atlas <akatlas@gmail.com> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <42FA6F9D.2000601@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA6F9D.2000601@isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7AMIFf19738 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 22:18:40 -0000 Status: RO Content-Length: 4309 On 8/10/05, Joe Touch <touch@isi.edu> 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AM3jf15964; Wed, 10 Aug 2005 15:03:45 -0700 (PDT) Message-ID: <42FA79C3.3010801@isi.edu> Date: Wed, 10 Aug 2005 15:03:47 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: spencer@mcsr-labs.org References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> <42FA7631.2010101@mcsr-labs.org> In-Reply-To: <42FA7631.2010101@mcsr-labs.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 22:04:40 -0000 Status: RO Content-Length: 1350 -----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----- Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7ALmkf11895 for <rbridge@postel.org>; Wed, 10 Aug 2005 14:48:46 -0700 (PDT) Received: from [127.0.0.1] (unknown[65.104.224.98]) by comcast.net (sccrmhc14) with ESMTP id <2005081021483701400cd9o9e>; Wed, 10 Aug 2005 21:48:38 +0000 Message-ID: <42FA7631.2010101@mcsr-labs.org> Date: Wed, 10 Aug 2005 16:48:33 -0500 From: Spencer Dawkins <spencer@mcsr-labs.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> In-Reply-To: <6280db5205081014091509a0c6@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: spencer@mcsr-labs.org Cc: Joe Touch <touch@ISI.EDU> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: spencer@mcsr-labs.org, "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 21:49:41 -0000 Status: RO Content-Length: 853 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7ALKRf03888; Wed, 10 Aug 2005 14:20:27 -0700 (PDT) Message-ID: <42FA6F9D.2000601@isi.edu> Date: Wed, 10 Aug 2005 14:20:29 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> <6280db5205081014091509a0c6@mail.gmail.com> In-Reply-To: <6280db5205081014091509a0c6@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 21:20:49 -0000 Status: RO Content-Length: 5301 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch <touch@isi.edu> wrote: > >>Alia Atlas wrote: >> >>>On 8/10/05, Joe Touch <touch@isi.edu> wrote: >>> >>> >>>>Alia Atlas <akatlas@gmail.com> 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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AL9Qf01079 for <rbridge@postel.org>; Wed, 10 Aug 2005 14:09:26 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 37so242717wra for <rbridge@postel.org>; Wed, 10 Aug 2005 14:09:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j9lkpKEB6dnZiIKIoOuEoJyCJyiNYayg3swe33HWMATXhsj7URNuaMURWocnXTCNbgVBHPCv7QfL8JY8jqlqbZ60ntu9e1C/dPxHPqX9BwCJHlO1aYe2jbOVW5A01rKGNkATUuuhnaF2VSHltlMxjB0mNF1y6BDdG+5H2FFJqVE= Received: by 10.54.57.77 with SMTP id f77mr579475wra; Wed, 10 Aug 2005 14:09:18 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 14:09:18 -0700 (PDT) Message-ID: <6280db5205081014091509a0c6@mail.gmail.com> Date: Wed, 10 Aug 2005 14:09:18 -0700 From: Alia Atlas <akatlas@gmail.com> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <42FA678D.7050101@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> <42FA678D.7050101@isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7AL9Qf01079 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 21:10:04 -0000 Status: RO Content-Length: 4133 On 8/10/05, Joe Touch <touch@isi.edu> wrote: > Alia Atlas wrote: > > On 8/10/05, Joe Touch <touch@isi.edu> wrote: > > > >>Alia Atlas <akatlas@gmail.com> 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AKk3f24842; Wed, 10 Aug 2005 13:46:03 -0700 (PDT) Message-ID: <42FA678D.7050101@isi.edu> Date: Wed, 10 Aug 2005 13:46:05 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas <akatlas@gmail.com> References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> <6280db5205081011205bb0acc0@mail.gmail.com> In-Reply-To: <6280db5205081011205bb0acc0@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: Re: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 20:47:08 -0000 Status: RO Content-Length: 2763 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas wrote: > On 8/10/05, Joe Touch <touch@isi.edu> wrote: > >>Alia Atlas <akatlas@gmail.com> 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----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AIKQf16279 for <rbridge@postel.org>; Wed, 10 Aug 2005 11:20:26 -0700 (PDT) Received: by wproxy.gmail.com with SMTP id 55so201041wri for <rbridge@postel.org>; Wed, 10 Aug 2005 11:20:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pqE0KKUEvpnhn/tsJYdl1lwVZFDLX7b9YFOTU/i2Vf0B7Jgx06W6wrCVHFMC9F1Pn5QurbxwIHU+Ruk2ehBdDxmMj8f1haDl3B2kvmK3CBKK8xUM3w7OLMlpZfBeJmnr0GLIPISjnREWZZcRiPtrR6TMk4wvK1UR2omBm9WQVsE= Received: by 10.54.3.8 with SMTP id 8mr635792wrc; Wed, 10 Aug 2005 11:20:20 -0700 (PDT) Received: by 10.54.148.6 with HTTP; Wed, 10 Aug 2005 11:20:20 -0700 (PDT) Message-ID: <6280db5205081011205bb0acc0@mail.gmail.com> Date: Wed, 10 Aug 2005 11:20:20 -0700 From: Alia Atlas <akatlas@gmail.com> To: Joe Touch <touch@ISI.EDU> In-Reply-To: <42FA41C6.3060009@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <mailman.7945.1123695908.7320.rbridge@postel.org> <42FA41C6.3060009@isi.edu> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: akatlas@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7AIKQf16279 Cc: "Developing a hybrid router/bridge." <rbridge@postel.org> Subject: [rbridge] load-balancing rbridges X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 18:20:38 -0000 Status: RO Content-Length: 1531 On 8/10/05, Joe Touch <touch@isi.edu> wrote: > Alia Atlas <akatlas@gmail.com> 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7AI4qf11356; Wed, 10 Aug 2005 11:04:52 -0700 (PDT) Message-ID: <42FA41C6.3060009@isi.edu> Date: Wed, 10 Aug 2005 11:04:54 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <mailman.7945.1123695908.7320.rbridge@postel.org> In-Reply-To: <mailman.7945.1123695908.7320.rbridge@postel.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: akatlas@gmail.com Subject: Re: [rbridge] Auto-discard notification X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 18:05:57 -0000 Status: RO Content-Length: 1186 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alia Atlas <akatlas@gmail.com> 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----- Received: from [192.168.1.45] (pool-71-105-95-19.lsanca.dsl-w.verizon.net [71.105.95.19]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7ADJOf16108; Wed, 10 Aug 2005 06:19:24 -0700 (PDT) Message-ID: <42F9FED5.1090707@isi.edu> Date: Wed, 10 Aug 2005 06:19:17 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B290E60C@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E60C@sinett-sbs.SiNett.LAN> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B9E9E617FE2B5BCD3F68661" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 13:19:39 -0000 Status: RO Content-Length: 12016 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B9E9E617FE2B5BCD3F68661 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, >=20 > I miss the point regarding the "Type" field not required. "EtherType" f= ield in the Ethernet header is used to tell the type of packet above Ethe= rnet. >=20 > 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).=20 >=20 > Thanks, > Vishwas > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@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 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Vishwas Manral wrote: >=20 >>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= =2E\ >=20 >=20 > 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. >=20 > Inside the rbridge, the rbridge forwarding takes over. Keep in mind tha= t > 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. >=20 > 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. >=20 >=20 >>Besides is there a reason to not have a "type" field in the shim header= ? >=20 >=20 > 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, th= e > rbridge replaces the vlan/protocol ID structure with its own set of > addresses which are sufficient for its forwarding. >=20 > Joe >=20 >=20 >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@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)=20 >>The existing bridges (switches) already do IGMP snooping, to limit mult= icast traffic. That scenario would break. >> >>A lot of existing layer-2 devices do firewall functionality. Firewall f= unctionality in the silicon may not work with Rbridges coming in. >> >>Maybe I am missing the point altogether. >> >>Thanks, >>Vishwas >>-----Original Message----- >>From: rbridge-bounces@postel.org [mailto:rbridge-bounces@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=20 >>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=20 >>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=20 >>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=20 >>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=20 >>basic bridge in the >>core, it would indeed not recognize an IGMP packet, but that's the=20 >>behavior we want. It would >>just think it was forwarding vanilla multicast...it would be the=20 >>RBridges deciding what IP multicast >>packets should be forwarded across which links, and intervening bridges= =20 >>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 coex= isting properly with normal bridges/ switches. >>> >>>The rbridge document aims to add a new shim header after the layer-2 h= eader. The draft states that "A packet in transit must look to ordinary b= ridges like an ordinary layer 2 packet." However switches (in the silicon= itself) these days are more intelligent and do deep packet processing (f= or example for a basic firewall functionality/ IGMP snooping etc). As the= new ether Type would be unidentifiable, this would result in a wrong beh= avior (example a basic filtering for wrong IP header length check would f= ail here). However the rbridge protocol defined in such a case will not w= ork 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@postel.org [mailto:rbridge-bounces@postel.org] O= n 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=20 >>>with an A-rooted tree (towards B) >>>vs a B-rooted tree (towards A), at least if we do a straightforward=20 >>>calculation of spanning trees. I think trying >>>to accomplish symmetric routes might >>>require source/destination pair route computation. So hopefully we won= 't=20 >>>require symmetric routes. >>> >>>Radia >>> >>> >>> >>>Guillermo Ib=E1=F1ez wrote: >>> >>> >>> >>> >>> >>>>Guillermo Ib=E1=F1ez wrote: >>>>This is my feedback on the "how many spanning trees" issue. >>>> >>>> >>>>Radia Perlman wrote: >>>> >>>> >>>> >>>> =20 >>>> >>>> >>>> >>>>>It would be nice to get opinions on remaining issues, and I think ea= ch >>>>>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 c= an=20 >>>>>calculate >>>>>as many as we want without further protocol messages. The possibilit= ies are: >>>>> >>>>>a) one spanning tree: This is simplest, obviously.=20 >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>> >>>>The poor performance in the core for multicast is an important argume= nt=20 >>>>against it. Other possibilities should exist, at least as an option. >>>> >>>> >>>> >>>> =20 >>>> >>>> >>>> >>>>>b) one per VLAN: How it would work:each RBridge announces, in its li= nk state info, which VLANs that >>>>>RBridge is attached to. To calculate a spanning tree for VLAN A, th= e=20 >>>>>RBridges=20 >>>>>(all of them...not just those attached to VLAN A) choose the RBridge= ,=20 >>>>>RA, that >>>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree i= s=20 >>>>>calculated >>>>>with RA as root. THat spanning tree is pruned so that only branches = that=20 >>>>>reach >>>>>other VLAN A links survive. >>>>> >>>>>Why bother: If only a few links are VLAN A, then this allows more=20 >>>>>optimal delivery >>>>>of multicast/unknown frames within the VLAN A broadcast domain. >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>> >>>>It seems that with this implementation compatibility (interoperabili= ty)=20 >>>>with bridges running Multiple Spanning Tree Protocol (MSTP) is=20 >>>>excluded. If bridges running MSTP exist in the campus network, they= =20 >>>>must be confined in one or several MST regions with their specific=20 >>>>VLAN-to-spanning tree instance mappings and, like happens with STP o= r=20 >>>>RSTP, the trees will end at the region boundary with an rbridge. This= =20 >>>>means that there could coexist "regions" running MSTP with their own = >>>>VLANs and multiple spanning trees inside the region, these regions=20 >>>>inserted between rbridges that use another type (range or IDs) of VLA= Ns.=20 >>>>My understanding is then that the only VLANs capable of traversing th= e=20 >>>>campus end-to-end would be the VLANs handled by Rbridges, as the othe= r=20 >>>>would be stopped by Rbridges if they are not known by them.=20 >>>> >>>>c) one per RBridge >>>> >>>> >>>> >>>> =20 >>>> >>>> >>>> >>>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then th= is=20 >>>>>allows >>>>>optimal delivery from source to the receivers of a particular multic= ast. >>>>> >>>>>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 RBrid= ges=20 >>>>>and packets >>>>>have to be sent over a spanning tree rather than on the shortest pat= h=20 >>>>>=20 >>>>> >>>>> =20 >>>>> >>>> >>>>>from S to D. >>>> >>>> >>>> =20 >>>> >>>> >>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>> >>>>One tree per bridge is very efficient together with IGMP snooping,=20 >>>>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=20 >>>>together with the MAC address learning mechanism. In other words:=20 >>>>assuming a core formed by rbridges, using an spaning tree per rbridg= e=20 >>>>may be enough to perform all the routing via minimum paths. This=20 >>>>requires that the address learning mechanism works over the trees (t= he=20 >>>>trees coincide in opposite directions A to B and B to A, a tricky iss= ue=20 >>>>when path costs can be equal). So it seems that there is some=20 >>>>overlapping or overkillling using multiple spanning trees for=20 >>>>broadcast/multicast and Dijkstra routing for unicast and simplificati= ons=20 >>>>are possible. >>>> >>>> >>>> >>>> =20 >>>> >>>> >>>> >>>>>******** >>>>>I personally don't have strong opinions on this. If only a miniscule= =20 >>>>>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 a= ll=20 >>>>>those trees >>>>>in advance just in case, or only computing one when necessary? >>>>> >>>>>Radia >>>>> >>>>> =20 >>>>> >=20 >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge --------------enig8B9E9E617FE2B5BCD3F68661 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+f7VE5f5cImnZrsRAtanAJ9rEyLYfRReNgwYlbOFiwxz1OOb7gCgwEtR Gz+fb0IqLpsmc9IeUIR5oS0= =sGs5 -----END PGP SIGNATURE----- --------------enig8B9E9E617FE2B5BCD3F68661-- Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7A6pEf15376 for <rbridge@postel.org>; Tue, 9 Aug 2005 23:51:14 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 9 Aug 2005 23:52:26 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E617@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLANs and type field Thread-Index: AcWdC3Te/YklFSJBRkWgMQannkHMyQAbBObQ From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7A6pEf15376 Subject: Re: [rbridge] VLANs and type field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 06:51:36 -0000 Status: RO Content-Length: 2714 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@postel.org [mailto:rbridge-bounces@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 Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7A6D9f07214 for <rbridge@postel.org>; Tue, 9 Aug 2005 23:13:09 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 9 Aug 2005 23:14:14 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E60C@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Doubts about Rbridge Thread-Index: AcWdAWMhBWLxPm/PSpSAo12Zedn3hAAb6V+w From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j7A6D9f07214 Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Wed, 10 Aug 2005 06:14:02 -0000 Status: RO Content-Length: 10119 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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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 >>>> >>>> >>>> Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j79Kfsf12298 for <rbridge@postel.org>; Tue, 9 Aug 2005 13:41:54 -0700 (PDT) Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel10.hp.com (Postfix) with ESMTP id 1C1D01724 for <rbridge@postel.org>; Tue, 9 Aug 2005 13:41:54 -0700 (PDT) Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 13:40:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Aug 2005 13:40:58 -0700 Message-ID: <83AB0942FD087D499DF2DD5CEE1B61330226A606@cacexc06.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] VLANs and type field Thread-Index: AcWdCq9K1d7NLPHEQB2s/KIz6zIfeAAF0zBQ From: "Ghanwani, Anoop" <anoop.ghanwani@hp.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-OriginalArrivalTime: 09 Aug 2005 20:40:59.0629 (UTC) FILETIME=[A66939D0:01C59D22] X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: anoop.ghanwani@hp.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j79Kfsf12298 Subject: Re: [rbridge] VLANs and type field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 20:42:33 -0000 Status: RO Content-Length: 285 > 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 Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j79HdBf14547 for <rbridge@postel.org>; Tue, 9 Aug 2005 10:39:11 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IKY008KLUD6YJ00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Tue, 09 Aug 2005 10:39:06 -0700 (PDT) Received: from sun.com ([129.150.24.164]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IKY00328UD5C800@mail.sunlabs.com> for rbridge@postel.org; Tue, 09 Aug 2005 10:39:06 -0700 (PDT) Date: Tue, 09 Aug 2005 10:39:09 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <BB6D74C75CC76A419B6D6FA7C38317B290E536@sinett-sbs.SiNett.LAN> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <42F8EA3D.7060002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <BB6D74C75CC76A419B6D6FA7C38317B290E536@sinett-sbs.SiNett.LAN> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: [rbridge] VLANs and type field X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 17:39:33 -0000 Status: RO Content-Length: 2334 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 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j79GU2f20803; Tue, 9 Aug 2005 09:30:02 -0700 (PDT) Message-ID: <42F8DA18.6080801@isi.edu> Date: Tue, 09 Aug 2005 09:30:16 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B290E4F6@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E4F6@sinett-sbs.SiNett.LAN> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 16:30:42 -0000 Status: RO Content-Length: 8996 -----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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@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----- Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j79GNQf18747; Tue, 9 Aug 2005 09:23:26 -0700 (PDT) Message-ID: <42F8D88C.2080307@isi.edu> Date: Tue, 09 Aug 2005 09:23:40 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B290E536@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E536@sinett-sbs.SiNett.LAN> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 16:24:17 -0000 Status: RO Content-Length: 9976 -----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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@postel.org > http://www.postel.org/mailman/listinfo/rbridge > > > _______________________________________________ > rbridge mailing list > rbridge@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----- Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j79BLbf24055 for <rbridge@postel.org>; Tue, 9 Aug 2005 04:21:37 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 9 Aug 2005 04:22:46 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E536@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] Doubts about Rbridge Thread-Index: AcWcOLNucM6pToWKRA+y4xxFUnTt1wAZx+iwAA0kt7A= From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j79BLbf24055 Subject: Re: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 11:23:12 -0000 Status: RO Content-Length: 8174 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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j795IIf23925 for <rbridge@postel.org>; Mon, 8 Aug 2005 22:18:18 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 8 Aug 2005 22:19:15 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E4F6@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Doubts about Rbridge Thread-Index: AcWcOLNucM6pToWKRA+y4xxFUnTt1wAZx+iw From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j795IIf23925 Subject: [rbridge] Doubts about Rbridge X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 05:19:02 -0000 Status: RO Content-Length: 7555 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@postel.org [mailto:rbridge-bounces@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@postel.org [mailto:rbridge-bounces@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 >>> >>> >>> Received: from [70.212.238.152] (152.sub-70-212-238.myvzw.com [70.212.238.152]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j791IGf24182; Mon, 8 Aug 2005 18:18:16 -0700 (PDT) Message-ID: <42F8044E.50909@isi.edu> Date: Mon, 08 Aug 2005 18:18:06 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B290E43E@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B290E43E@sinett-sbs.SiNett.LAN> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5CD9DB6C2C9A5EB78E3DCFB" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] How many spanning trees? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 09 Aug 2005 01:18:37 -0000 Status: RO Content-Length: 7013 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5CD9DB6C2C9A5EB78E3DCFB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vishwas Manral wrote: > Hi Radia, >=20 > I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches. >=20 > 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 ordinar= y > 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 woul= d > 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@postel.org [mailto:rbridge-bounces@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? >=20 > You are right that paths will not be the same from A to B as from B to = A=20 > with an A-rooted tree (towards B) > vs a B-rooted tree (towards A), at least if we do a straightforward=20 > calculation of spanning trees. I think trying > to accomplish symmetric routes might > require source/destination pair route computation. So hopefully we won'= t=20 > require symmetric routes. >=20 > Radia >=20 >=20 >=20 > Guillermo Ib=E1=F1ez wrote: >=20 >=20 >>Guillermo Ib=E1=F1ez wrote: >>This is my feedback on the "how many spanning trees" issue. >> >> >>Radia Perlman wrote: >> >>=20 >> >> >>>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= =20 >>>calculate >>>as many as we want without further protocol messages. The possibilitie= s are: >>> >>>a) one spanning tree: This is simplest, obviously.=20 >>> >>> =20 >>> >> >>The poor performance in the core for multicast is an important argument= =20 >>against it. Other possibilities should exist, at least as an option. >> >>=20 >> >> >>>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=20 >>>(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 th= at=20 >>>reach >>>other VLAN A links survive. >>> >>>Why bother: If only a few links are VLAN A, then this allows more=20 >>>optimal delivery >>>of multicast/unknown frames within the VLAN A broadcast domain. >>> >>> >>> =20 >>> >> >>It seems that with this implementation compatibility (interoperability= )=20 >>with bridges running Multiple Spanning Tree Protocol (MSTP) is=20 >>excluded. If bridges running MSTP exist in the campus network, they=20 >>must be confined in one or several MST regions with their specific=20 >>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=20 >>means that there could coexist "regions" running MSTP with their own=20 >>VLANs and multiple spanning trees inside the region, these regions=20 >>inserted between rbridges that use another type (range or IDs) of VLANs= =2E=20 >>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.=20 >> >>c) one per RBridge >> >>=20 >> >> >>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this= =20 >>>allows >>>optimal delivery from source to the receivers of a particular multicas= t. >>> >>>Another reason is that it minimizes out of order delivery of packets i= n the >>>case when S it talking to D, and initially D is unknown by the RBridge= s=20 >>>and packets >>>have to be sent over a spanning tree rather than on the shortest path = >>> =20 >>> >> >>>from S to D. >>=20 >> >> >>> >>> =20 >>> >> >>One tree per bridge is very efficient together with IGMP snooping,=20 >>assuming a core of rbridges. The plus point is that in this case the=20 >>multiple trees can also perform routing of unicast traffic, if used=20 >>together with the MAC address learning mechanism. In other words:=20 >>assuming a core formed by rbridges, using an spaning tree per rbridge = >>may be enough to perform all the routing via minimum paths. This=20 >>requires that the address learning mechanism works over the trees (the= =20 >>trees coincide in opposite directions A to B and B to A, a tricky issue= =20 >>when path costs can be equal). So it seems that there is some=20 >>overlapping or overkillling using multiple spanning trees for=20 >>broadcast/multicast and Dijkstra routing for unicast and simplification= s=20 >>are possible. >> >>=20 >> >> >>>******** >>>I personally don't have strong opinions on this. If only a miniscule=20 >>>amount of >>>the traffic is multicast/unknown, then one spanning tree seems good=20 >>>enough. If >>>there's high volume IP-derived multicast applications, then perhaps on= e per >>>RBridge would be worth it. >>> >>>So I guess I'd be inclined to either just have one spanning tree, or o= ne per >>>ingress RBridge. >>> >>>And if we did one per ingress RBridge, would it be worth computing all= =20 >>>those trees >>>in advance just in case, or only computing one when necessary? >>> >>>Radia >>> >=20 >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://www.postel.org/mailman/listinfo/rbridge --------------enigD5CD9DB6C2C9A5EB78E3DCFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+ARPE5f5cImnZrsRAujXAKDjkqpnut7x4kAq0fVPtCHq+/aRTQCgzPLv cdUHUXmGlO5m+A9tfPlvILw= =wzG5 -----END PGP SIGNATURE----- --------------enigD5CD9DB6C2C9A5EB78E3DCFB-- Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j78GSWf21964 for <rbridge@postel.org>; Mon, 8 Aug 2005 09:28:32 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IKW008DNWFD5B00@mail-mta.sfvic.sunlabs.com> for rbridge@postel.org; Mon, 08 Aug 2005 09:28:25 -0700 (PDT) Received: from sun.com ([129.150.24.164]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IKW001ZKWFCI700@mail.sunlabs.com> for rbridge@postel.org; Mon, 08 Aug 2005 09:28:25 -0700 (PDT) Date: Mon, 08 Aug 2005 09:28:29 -0700 From: Radia Perlman <Radia.Perlman@sun.com> In-reply-to: <BB6D74C75CC76A419B6D6FA7C38317B290E43E@sinett-sbs.SiNett.LAN> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Message-id: <42F7882D.7030109@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en References: <BB6D74C75CC76A419B6D6FA7C38317B290E43E@sinett-sbs.SiNett.LAN> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: radia.perlman@sun.com Subject: Re: [rbridge] How many spanning trees? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 08 Aug 2005 16:29:58 -0000 Status: RO Content-Length: 7096 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@postel.org [mailto:rbridge-bounces@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@postel.org >http://www.postel.org/mailman/listinfo/rbridge > > Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j78Ccsf17220 for <rbridge@postel.org>; Mon, 8 Aug 2005 05:39:00 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 8 Aug 2005 05:40:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B290E43E@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] How many spanning trees? Thread-Index: AcV8Alkw18GZj+qPTSaI1/Kd7N6wTQf+Be8Q From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j78Ccsf17220 Subject: Re: [rbridge] How many spanning trees? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 08 Aug 2005 12:39:52 -0000 Status: RO Content-Length: 5485 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@postel.org [mailto:rbridge-bounces@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 >> Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j74Aadf22830 for <rbridge@postel.org>; Thu, 4 Aug 2005 03:36:41 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C598E0.624BA546" Date: Thu, 4 Aug 2005 03:34:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B278C9FC@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: <BB6D74C75CC76A419B6D6FA7C38317B278C9FC@sinett-sbs.SiNett.LAN> Thread-Topic: Private VLAN support thread-index: AcV8Alkw18GZj+qPTSaI1/Kd7N6wTQc3a1kQ From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: [rbridge] Private VLAN support X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Thu, 04 Aug 2005 10:37:02 -0000 Status: RO Content-Length: 5212 This is a multi-part message in MIME format. ------_=_NextPart_001_01C598E0.624BA546 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Radia, =20 Here is the link to Private VLAN http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-03.txt =20 The question is do we intend to support backward compatibility with all = features running on switches and actually deployed but not standardized? =20 Thanks, Vishwas =20 =20 ------_=_NextPart_001_01C598E0.624BA546 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiMKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAFQAAAFByaXZhdGUgVkxBTiBzdXBw b3J0AGkHAQWAAwAOAAAA1QcIAAQAAwAiAAAABAARAQEggAMADgAAANUHCAAEAAMAJAAiAAQANQEB CYABACEAAABDNEM1NEQ3NjI1NTVENjQwODJGMTIxQUVDNEREMDI1QgAlBwEDkAYAUAwAADcAAAAD ADYAAAAAAEAAOQAUb5cG4JjFAR4APQABAAAAAQAAAAAAAAACAUcAAQAAADEAAABjPVVTO2E9IDtw PVNJTkVUVDtsPVNJTkVUVC1TQlMtMDUwODA0MTAzNjMzWi01MjcAAAAAHgBJAAEAAAAnAAAAUmU6 IFtyYnJpZGdlXSBIb3cgbWFueSBzcGFubmluZyB0cmVlcz8AAEAATgCAl4WSAHzFAR4AWgABAAAA GwAAAHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnAAACAVsAAQAAAFMAAAAAAAAAgSsfpL6jEBmd bgDdAQ9UAgAAAAByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZwBTTVRQAHJicmlkZ2UtYm91bmNl c0Bwb3N0ZWwub3JnAAACAVwAAQAAACAAAABTTVRQOlJCUklER0UtQk9VTkNFU0BQT1NURUwuT1JH AB4AXQABAAAADgAAAFJhZGlhIFBlcmxtYW4AAAACAV4AAQAAAEEAAAAAAAAAgSsfpL6jEBmdbgDd AQ9UAgAAAABSYWRpYSBQZXJsbWFuAFNNVFAAUmFkaWEuUGVybG1hbkBzdW4uY29tAAAAAAIBXwAB AAAAGwAAAFNNVFA6UkFESUEuUEVSTE1BTkBTVU4uQ09NAAAeAGYAAQAAAAUAAABTTVRQAAAAAB4A ZwABAAAAGwAAAHJicmlkZ2UtYm91bmNlc0Bwb3N0ZWwub3JnAAAeAGgAAQAAAAUAAABTTVRQAAAA AB4AaQABAAAAFgAAAFJhZGlhLlBlcmxtYW5Ac3VuLmNvbQAAAB4AcAABAAAAFQAAAFByaXZhdGUg VkxBTiBzdXBwb3J0AAAAAAIBcQABAAAAGwAAAAHFfAJZMNfBmY/qj00miNfynezesE0HN2tZEAAe AHQAAQAAACMAAABEZXZlbG9waW5nIGEgaHlicmlkIHJvdXRlci9icmlkZ2UuAAAeABoMAQAAAA8A AABWaXNod2FzIE1hbnJhbAAAHgAdDgEAAAAVAAAAUHJpdmF0ZSBWTEFOIHN1cHBvcnQAAAAAAgEJ EAEAAAC0BQAAsAUAAIMVAABMWkZ1V+jjCwMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD 4wIAY2jBCsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2fkS72Y0A8YR hRHjCO8J9/Y7Gh8OMDUbPxsREeEMYM5jAFALCQFkMzYRYAulZDQgEAIqXA6yAZBnLxTwCqMR4yBo NBTwPCEARE9DVFlQRSAASFRNTCBQVUIATElDICItLy+IVzNDJABEVEQjFAgzLjIkAEVOIj7nIW0h DyZBMTgicCMiJY8bJp8pEDMgACfwRUFEXyhNDvEpbyvvJ3Q2DvA8UE1FVEEHsEEu4D1MIkcJ8ASQ YXQFsCLRFxBPTlQlUFQvcAXhREV4EPFuZ2UGUnYPEzExwQCQAiAgNi41gC42OTQ0LjAlfhMtTyeD NzcicFRJVBRMRShONA7wUmU6UCBbcmIFEGQxYF2NIxBvB+ADgXkgcwqwJm4DADFQIHQJ0XM/9Sbu NSJwLzXPM/8oxTcRLzrAKs8pHz6UNRFgPEI4T0RZPg0fcT8vZzlCNiJwRElWIDfAPTE3wE9XQTdA C1B5VEhleHQ1gDk3OqBk6GlyPT6wcj4APnMAIT4gAABFMQqxRiIQ8Fxx/wMhRZURYEDvQf9DBkT/ Rg9zRxo+STY0SvpHTyd0NCUn0UYwUSBmANBlPcUHEyAZkz0jMFIDOKB0aXpREDJK6xgwAzBjTxPw A7IB0EcpSGkH8GGpSnBhLCb8NUMRL1CS/0rpSvdNOwHASvcKolfYCoD9JvwwKpEkYENQVy9PL0if /0mvSr9Lz1gPTe9dL1APURZ/Un9ThFQ9Vb9Wz1z/PoU4cSAAJm5iOLACgGDXXPwnYQFAYp9ZD1of Wy9cP/9sP15fX29gf2GPbu9jr3QP/2XPZt9n71RcBJAxcAQAOTCqaDFwbAuAazkwbyNgPQUQdi/g MXA8rHV1Vkz8QU5pz2rfV99v33Dvcf//cw97v3Uvdj93T3hfeW96f797j3yffa9+v2jfbLw8LxA1 CqNoHKBmL3AOsHRwajokAHeaYC4IkAAwLnkFsGcvC4CCQASgEUAtJmQv0AGAcy+bwy1zQQBwamli LXCCBC1idgtgbi0wJQAM0HSnJXFS+giQbGQ+QmafQKELgHN0e0gi4VIjoHxOSyPQmf+bD5wfnS8i fxkwAfGfQBEgPrBT0QBQdf9HGqDfoe+i/6QPir+Lwas/5YvOOSJhL0E7PoTvhf//hw+IH4kvij+t D4xfjW+Of/+Pj5Cfka+Sv5PPlN+V75b//2m/sA+2P2zvbf+8D7J/s4//tJ/En8Wvt8+437nvuv/I X7+9H81/vz/AT8FfwmlUgUFecQpQn/AyQoEBZIHQdxOA4ahBbmSBsnN1cC5wGcGCb87jYgDQa3db CxFRgW0KsNqAYgMQaW50OJAD8IEwIAdAAyBmzmUv4AhwB5FydTjkMlH9A+F0EPAHkQBw27AA0OAA P9+ROJDcj87yAQALUG95kQmAIGJ1BUBubwVAz5/w4aELEdexZD/DH8Qv/7EvyS/KP8tPzF/VD85/ z4//0J/Rr9K/08/U39Xv1v/YD//CL+XP5t/5L8Zvx3/oP+lP/+pf62/7b+2P7p/vr/C/8c//8t/z 7wRP9g/3H/gv2Yg4cPxrc1Wv+r/nv/+/AM8B3/8C7wufBQ8GHwcvCD8JTwpfXwtvDH8Njw6f+L5W gQBo/d4QcxEfEi8TPxRPFV8Wb/8XfyAvGZ8arxu/HM8d3x7v/x//IQ8iHyMv+M8lvybPOR///Q/+ HygvKT8qTytfO18tf/8ujy+fMK8xvzLPM99EPzX//zcPOB9Lnzo/Q088Xz1vPn//P49An0GvQr9S v1kPWh9bLxdFT16/gsY1TQEvQk+8RFmu7a6QYG9i8TeuoVBIVE1MTpB9ZSAeADUQAQAAAD8AAAA8 QkI2RDc0Qzc1Q0M3NkE0MTlCNkQ2RkE3QzM4MzE3QjI3OEM5RkNAc2luZXR0LXNicy5TaU5ldHQu TEFOPgAAHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAAAyAAAAUABy AGkAdgBhAHQAZQAgAFYATABBAE4AIABzAHUAcABwAG8AcgB0AC4ARQBNAEwAAAAAAAsA9hAAAAAA QAAHMBRvlwbgmMUBQAAIMFbzWWLgmMUBAwDeP69vAAADAPE/CQQAAB4A+D8BAAAADwAAAFZpc2h3 YXMgTWFucmFsAAACAfk/AQAAAF0AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089U0lO RVRUL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049VklTSFdB UwAAAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA 3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAA AAAAAwAeQAAAAAAeADBAAQAAAAgAAABWSVNIV0FTAB4AMUABAAAACAAAAFZJU0hXQVMAHgAyQAEA AAAbAAAAcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcAAB4AM0ABAAAAFgAAAFJhZGlhLlBlcmxt YW5Ac3VuLmNvbQAAAB4AOEABAAAACAAAAFZJU0hXQVMAHgA5QAEAAAACAAAALgAAAAMAdkD///// CwApAAAAAAALACMAAAAAAAMABhBb/8Y2AwAHEOwAAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABl AAAASElSQURJQSxIRVJFSVNUSEVMSU5LVE9QUklWQVRFVkxBTkhUVFA6Ly9XV1dJRVRGT1JHL0lO VEVSTkVULURSQUZUUy9EUkFGVC1TQU5KSUItUFJJVkFURS1WTEFOLTAzVFhUVAAAAAACAX8AAQAA AD8AAAA8QkI2RDc0Qzc1Q0M3NkE0MTlCNkQ2RkE3QzM4MzE3QjI3OEM5RkNAc2luZXR0LXNicy5T aU5ldHQuTEFOPgAA7bU= ------_=_NextPart_001_01C598E0.624BA546-- Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j72HsVf22941 for <rbridge@postel.org>; Tue, 2 Aug 2005 10:54:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5978B.38B8A3BF" Date: Tue, 2 Aug 2005 10:54:25 -0700 Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B278C9E8@sinett-sbs.SiNett.LAN> X-MS-Has-Attach: X-MS-TNEF-Correlator: <BB6D74C75CC76A419B6D6FA7C38317B278C9E8@sinett-sbs.SiNett.LAN> Thread-Topic: [rbridge] Updated TRILL agenda Thread-Index: AcWXhvREdNc8GvdtShyRxAUbFEjMZgAAxrJl From: "Vishwas Manral" <Vishwas@sinett.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: vishwas@sinett.com Subject: Re: [rbridge] Updated TRILL agenda X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 02 Aug 2005 17:54:39 -0000 Status: RO Content-Length: 8312 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5978B.38B8A3BF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 One small typo, the draft name is draft-perlman-rbridge-03.txt =20 Thanks, Vishwas ________________________________ From: rbridge-bounces@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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Room: Room 342 CHAIR: Erik Nordmark <erik.nordmark@sun.com> AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes <http://www.ietf.org/html.charters/trill-charter.html> 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 <draft-perlman-rbridge-rbridge-03.txt> Goal: Enumerate and discuss open issues Accept as WG document? =20 =20 ------_=_NextPart_001_01C5978B.38B8A3BF Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhoRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAIwAAAFJFOiBbcmJyaWRnZV0gVXBk YXRlZCBUUklMTCBhZ2VuZGEAlgsBBYADAA4AAADVBwgAAgAKADYAGQACAEEBASCAAwAOAAAA1QcI AAIACgA2ABkAAgBBAQEJgAEAIQAAADNFNEJBM0U3MDVCQzJBNEE5OTJFQzU0RTRBMjNDRUJEAHIH AQOQBgB0EgAANwAAAAMANgAAAAAAQAA5AL+juDiLl8UBHgA9AAEAAAAFAAAAUkU6IAAAAAACAUcA AQAAADMAAABjPVVTO2E9IDtwPVNJTkVUVDtsPVNJTkVUVC1TQlMtMDUwODAyMTc1NDI1Wi0xNjc2 NAAAHgBJAAEAAAAfAAAAW3JicmlkZ2VdIFVwZGF0ZWQgVFJJTEwgYWdlbmRhAABAAE4AACNki4SX xQEeAFoAAQAAABsAAAByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZwAAAgFbAAEAAABTAAAAAAAA AIErH6S+oxAZnW4A3QEPVAIAAAAAcmJyaWRnZS1ib3VuY2VzQHBvc3RlbC5vcmcAU01UUAByYnJp ZGdlLWJvdW5jZXNAcG9zdGVsLm9yZwAAAgFcAAEAAAAgAAAAU01UUDpSQlJJREdFLUJPVU5DRVNA UE9TVEVMLk9SRwAeAF0AAQAAAA4AAABFcmlrIE5vcmRtYXJrAAAAAgFeAAEAAABBAAAAAAAAAIEr H6S+oxAZnW4A3QEPVAIAAAAARXJpayBOb3JkbWFyawBTTVRQAGVyaWsubm9yZG1hcmtAc3VuLmNv bQAAAAACAV8AAQAAABsAAABTTVRQOkVSSUsuTk9SRE1BUktAU1VOLkNPTQAAHgBmAAEAAAAFAAAA U01UUAAAAAAeAGcAAQAAABsAAAByYnJpZGdlLWJvdW5jZXNAcG9zdGVsLm9yZwAAHgBoAAEAAAAF AAAAU01UUAAAAAAeAGkAAQAAABYAAABlcmlrLm5vcmRtYXJrQHN1bi5jb20AAAAeAHAAAQAAAB8A AABbcmJyaWRnZV0gVXBkYXRlZCBUUklMTCBhZ2VuZGEAAAIBcQABAAAAGwAAAAHFl4b0RHTXPBr3 bUockcQFGxRIzGYAAMayZQAeAHQAAQAAACMAAABEZXZlbG9waW5nIGEgaHlicmlkIHJvdXRlci9i cmlkZ2UuAAAeABoMAQAAAA8AAABWaXNod2FzIE1hbnJhbAAAHgAdDgEAAAAfAAAAW3JicmlkZ2Vd IFVwZGF0ZWQgVFJJTEwgYWdlbmRhAAACAQkQAQAAAKwLAACoCwAAeTMAAExaRnV9v4MnAwAKAHJj cGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUO UQMB3RDXMgYABsMR1TMERhDZWRLvZjQQbxF7NQPGVHxhaANxAoAR4wjvCfc7exwfDjA1HT8dERHh DGBjZwBQCwkBZDM2EWALpTSyIBACKlwOsgGQZxTwFwqjEeMiaDQU8DwhRABPQ1RZUEUgSABUTUwg UFVCTABJQyAiLS8vV0QzQyYARFREJRQzhC4yJgBFTiI+I23zIw8oQTE4JHAlIiePKJ+NKxAzIgAp 8EVBRCpNLw7xK28t7yl0Ng7wPE0oRVRBB7BBMOA9IqZHCfAEkGF0BbAiFxBoT05UJ1BUMXAF4UWi eBjhbmdlBlJ2EzEHM8EAkAIgIDYuNS7ANjk0NC4wJ34vTwkpgzc3JHBUSVRMikUqTjQO8FtyYgUQ gmQzYF0gVXBkMeDjCYAasFJJTCVQKxAJ8Os6ACjuNSRwLzfPNf8qxV85ETxALM8rH0AUNRFgPHBC T0RZP40hcUCvZ4Q5NiRwRElWIDmAgj05gE9XQVJlC1CAeVRleHQ5OQHQoUSQZGlyPUAwcj+A+z/z ACEgAABGsQqxR6IY4PxccQMhRxURYEJvQ39Ehs9Gf0ePSJo/yTY0THpIz5UpdDQp0UYyUSBmANAU ZT0HEyAbkz0jMNVTgyAAkHpSkDJMaxgwPQMwYxPwA7IB0EipSGnqLCj8NUSRL1ISTGlMd39OuwHA THcKolj4CoAo/DD/LJEmYETQWE9Qr0ofSy9MP/9NT1kvT29eT1GPUpZT/1UEX1W9Vt9X714fQAU4 IgAmMG5ic3ACgGH3XCf+YQFAY79aL1s/XE9dX21f/19/YI9hn2KvcA9kz3UvZu93Z/9pD1XbTzGw f2AAwGxBAyB0eXBvLIJgaI0zcGQx0AGAIG5hB4D/IhxVMXazBABtv27Pb9qDE1QtcASQbAOBLTlV LfYwJwAM0HRq72v/WP9w//9yD3MfdC9833ZPd194b3l//3qPe598r32/fs9/32n/if//iw+dX4W/ hs+Mb41/jo+Pn/+fn5G/ks+T35Tvlf+XD5gfX6h/mj+bT5xfr9ZUMzFr/nNWz57vi++j76T/pg+n H/+vz6k/qk+rX6xvrX+uj6+fL7Cvsb+yz1WuVgQAaHd+YYUsth+8TykaMJBB4VL3wEnBAAuAZQqB zA+ES7gfZ7kvuj9EgkhSgmABoEljOvBF4D0tMcdcAFBxiQDgcWoMYGxkYgMw+H4gX9cS1tHOg9JD zt//vY7Cv8PPxN/F6RrExu9U8n88IJzvoM1B8MBL1sHgZ0ZtA2E600wkYS/iCrdpIJOI9gbgdW5S gHNAgpCSczogbC4FsGcgNFHUYmUY8GzA0G/A0M+ftb5CRQUQawewBbBkAMD8cmvMn82vzr/hL+I/ 7dRfBmACMOPv5P/mB1QKUCBsOC8nIAHQMDwgu0A6/0ZBMUDrP+xP7V/ub+9/tHXOb/Ev8j/mB0Rl M8AbsD5wC4DoIN5w6R++Qmh5Tzli5oAIYDogci85ZC4/9S/2P/dP+F/5b/CFdWL4amVj8R/7/+X4 OU86Vf/+f75COsQBHwIvAz/J/8sP/w+fDa8Ov7fP0a/Sv7r/Eb//3E4ZLxo/2T/TTxw8278eL/va SwgwUBQqIrEPWiB/Gt/fxbfen9Xhs/0x0G6h4CLA3fDxINSwAGFTEG4xsAcQwzRC6OFMb3RzLFMP INe1EAtfIrMoCwMpEu8T/w8PPy9vMH8xiVRIVVIQU0RBWYKwQXVn8nXnsCA0grAtfyLCG9D0MzDV EDI34DI/M08xXD49O188KjhfOW8xXFJvw+PBQCMgMzQyPT8+Tw8xX0FPQl9DaUNIQUl+UkBw6mM2 fyLC6rYEDyY7LgCiCTxDeIiA6oAubqnqxUBz5zAuUxBtSb/6Z0raPkN/RI9Fn0+/UM/DUd9S4kFH RU41gAc8f1P/VQ9TH1efWK0rYQAwZHZ1LAOCsEOCMkffIsJm++gA8NBj6nDocLUtoY+inv9f32Dv Yf9jD2QfZS9mP2dP/2hfaW9qf2uPbJ9tr26/b8//cN9x76KeXb9I23P/dQ9zP/95D3ofey98P31P fl9/b4B//4GPgp+Dr4S/hc+G34fvdd/99HFtWKAAUcm9Wn9bj7TwXQAQQQzDdt8is0LJoGj//hGN j46fWL+TL5Q/lUn9oOeU8P3AKrBibOdgKHDUgP50NgCJ/4sPiT+af5uPnJ//na+ev5/PoN91/5Ff Iu2jn/+hz6cfqC+pP6pPq1+sb61//66Pr5+wr7G/ss+z37Tvtf//tw+lf6aPuN+577gfvW++f/+/ j8Cfwa/Cv8PPxN/F78b//8gPyR/KL8s/zE+6v3d/eI//zq/M39Kv07/Uz9Xf1u/X///ZD9of2y/c P91P3l/fb+B//+GP4p/zoTfAjQ+Wj5ef439XSn9LigQfQbwUaCsQZgQ9IuVAdHA6Ly+id+8wLmll FyAu0hBsZy/lQk1QaLxAAGFzqi9csGldkC3wVS7lQqYiKOzvcGxk0NJm8xAD6WA2EHtIWVBFUuBM SU5LIO6/78/w33nx4X19KZHzEPaQLgBc4GNmMVx1XaDsSPSve/W/9s9sHI8lqh0fB6pB/+iQ6l9O r/8f5//pDwMvBD//BU9HAEBA0iAFcJngLCLQv6G8QndpdGgrUEUL4MAgODAyLjEA3+Tf/+MPDM8N 3w7vD/8RD9COEw//ET8VPxZPF18Ybxl/Go8bn/8crx2/Hs8f3yDvIf8jDyQfFyUvFO+8BkWSkHRs Yf5rBZEmjyefJc8rnyyvLb//Ls8v3zDvMf8zDzQfNS82P/83TzhfOW86f+XP5t8G/wgPGTwTR29d gEdgRGlznmOaAJmgKV+8Qm9wXRL3maBfEu5wdvpw+lA//0EPbwWPRo9Hn0ipUFzAmXFt95mzTKCQ 4HSQc0PfvEK8QOv7UAuQZV0Ade5wPG89f/87r1AfUS9SP1NPVF9Vb1Z//1ePWJ9Zryi/0S/SP1wP XR//YA9hH2IvYz9kT2VfZm9nf/9oj2mfaq9rv2zPbd9u72///V3jMj9vSd9K70KfQ69Etrt0kEhS LEWQSGCQoGXzkPp0RbA/dN9170h/e498n8F9qVJlcXVp7nBNIn+ZoAoBTGB0kJLBeK+8M3DjTGB7 EGNvbJofck9wf/+E/4YPhx+IL4k/ik+LX4xv/41/jo+Pn5Cvkb9d317vX///lB+ST5gfmS+aP5tP nF+db/+ef5+PoJ+hr6K/o8+k36Xv96b/qA8/QDV0X37vf/93j/94n3mver+tH64vqK+zz7TfU0wV hFMgZIRgdU0jLZWCEHBNMCCwEHN1rID/sH8qU6kfqi+oX7zPvd++7/+//8EPwh/DL8Q/xU/GX8dv X8h/yY/Kn8uvqv9Q+6Bs/5eQCh+8H85vz3/Nr9N/1I//1Z/Wr9e/2M/Z39rv2//dD7/eH98v4D/h T+JflaQ1tg3/KiasP7bPt9/jfwGiKeDlCYY86vj4UGFmdC26cBHQwy1yYvvwZGdlge73MDMudHh0 65/fAe/rL+k/6k+vaEXoQE0g/+4w/IBNbyoXssCwJLpp8v//9A/qv+Pv5P/8L/0//k//X/8AbwF/ Ao8DnwSvBb8GzwffhwjvCf+V4EFjY2VFMPP24LsAV0f3L/g0ucWzHYI1+qEvRk9OVPr5/wx38tDs 5ipCEtj7+Coz+//pKaY3MhGxUPrw+bsTYenSL2c28UA8F7Hs5/nQcxYP+jQ0OPqwEeJMwGmQemU9 MhpbZnN0Mf8bHxEvEj8fDwvvCh4TjxSf/xWvFr8XzxjfGe8a/xwPHR//Hi8fPyBPIV8ibyN/JI8l ny8mrzM/KM/6NDArgS9EfElWMi85LyofPg8PFzXBLhEvQk9EWSk9OlALP89CUTcxsUhUTUwF+vB9 RIAeADUQAQAAAD8AAAA8QkI2RDc0Qzc1Q0M3NkE0MTlCNkQ2RkE3QzM4MzE3QjI3OEM5RThAc2lu ZXR0LXNicy5TaU5ldHQuTEFOPgAAHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4MjIAAAsA8hABAAAA HwDzEAEAAABSAAAAUgBFACUAMwBBACAAWwByAGIAcgBpAGQAZwBlAF0AIABVAHAAZABhAHQAZQBk ACAAVABSAEkATABMACAAYQBnAGUAbgBkAGEALgBFAE0ATAAAAAAACwD2EAAAAABAAAcw7Y8MD4qX xQFAAAgwbY/EOIuXxQEDAN4/r28AAAMA8T8JBAAAHgD4PwEAAAAPAAAAVmlzaHdhcyBNYW5yYWwA AAIB+T8BAAAAXQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1TSU5FVFQvT1U9RklS U1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJRU5UUy9DTj1WSVNIV0FTAAAAAB4A+j8B AAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5 CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAA AB4AMEABAAAACAAAAFZJU0hXQVMAHgAxQAEAAAAIAAAAVklTSFdBUwAeADJAAQAAABsAAAByYnJp ZGdlLWJvdW5jZXNAcG9zdGVsLm9yZwAAHgAzQAEAAAAWAAAAZXJpay5ub3JkbWFya0BzdW4uY29t AAAAHgA4QAEAAAAIAAAAVklTSFdBUwAeADlAAQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsA IwAAAAAAAwAGECcZHOsDAAcQagMAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISSxPTkVT TUFMTFRZUE8sVEhFRFJBRlROQU1FSVNEUkFGVC1QRVJMTUFOLVJCUklER0UtMDNUWFRUSEFOS1Ms VklTSFdBU0ZST006UkJSSURHRS1CT1VOQ0VTQFBPU1RFTE9SAAAAAAIBfwABAAAAPwAAADxCQjZE NzRDNzVDQzc2QTQxOUI2RDZGQTdDMzgzMTdCMjc4QzlFOEBzaW5ldHQtc2JzLlNpTmV0dC5MQU4+ AABEwQ== ------_=_NextPart_001_01C5978B.38B8A3BF-- Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j72H5uf05571 for <rbridge@postel.org>; Tue, 2 Aug 2005 10:05:56 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j72H5t1d026998 for <rbridge@postel.org>; Tue, 2 Aug 2005 10:05:56 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j72H5rPp826701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2005 10:05:55 -0700 (PDT) Message-ID: <42EFA81E.5070304@sun.com> Date: Tue, 02 Aug 2005 10:06:38 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: [rbridge] Updated TRILL agenda X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 02 Aug 2005 17:06:38 -0000 Status: RO Content-Length: 801 Transparent Interconnection of Lots of Links (TRILL) THURSDAY, August 4, 1030-1230 ============================== Room: Room 342 CHAIR: Erik Nordmark <erik.nordmark@sun.com> AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes <http://www.ietf.org/html.charters/trill-charter.html> 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 <draft-perlman-rbridge-rbridge-03.txt> Goal: Enumerate and discuss open issues Accept as WG document? Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j72H25f03854 for <rbridge@postel.org>; Tue, 2 Aug 2005 10:02:05 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j72H25r3022375 for <rbridge@postel.org>; Tue, 2 Aug 2005 11:02:05 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j72H22IG824685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2005 10:02:04 -0700 (PDT) Message-ID: <42EFA737.5040202@sun.com> Date: Tue, 02 Aug 2005 10:02:47 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B28A29EF@sinett-sbs.SiNett.LAN> <42EF953F.5060402@pi.se> In-Reply-To: <42EF953F.5060402@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: Re: [rbridge] name of the mailing list? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 02 Aug 2005 17:02:38 -0000 Status: RO Content-Length: 229 Loa Andersson wrote: > since the working group name is trill, are there any plans to > change the name of the mailing list? > > trill@ietf.org would be good I'll work with the secretariat to have such a thing setup. Erik Received: from [86.255.27.179] (open-27-179.ietf63.ietf.org [86.255.27.179]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j72GgQf26142; Tue, 2 Aug 2005 09:42:26 -0700 (PDT) Message-ID: <42EFA26F.4010508@isi.edu> Date: Tue, 02 Aug 2005 09:42:23 -0700 From: Joe Touch <touch@ISI.EDU> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B28A29EF@sinett-sbs.SiNett.LAN> <42EF953F.5060402@pi.se> In-Reply-To: <42EF953F.5060402@pi.se> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig54BE50948C4C4714209596E3" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [rbridge] name of the mailing list? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 02 Aug 2005 16:43:05 -0000 Status: RO Content-Length: 1158 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig54BE50948C4C4714209596E3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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@ietf.org would be good > > /Loa > --------------enig54BE50948C4C4714209596E3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC76JvE5f5cImnZrsRAnfeAJ9vxPhSSNNQgeS8VdCbpAQ2jwrAbwCgpb+7 ub94CmM4Bz9ZzRvFnb02TJc= =1lHb -----END PGP SIGNATURE----- --------------enig54BE50948C4C4714209596E3-- Received: from smtp.testbed.se ([80.86.78.228]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j72Fn2f05099 for <rbridge@postel.org>; Tue, 2 Aug 2005 08:49:02 -0700 (PDT) Received: from open-26-238.ietf63.ietf.org ([86.255.26.238]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Dzz0b-0001Wu-Ky for rbridge@postel.org; Tue, 02 Aug 2005 17:48:53 +0200 Message-ID: <42EF953F.5060402@pi.se> Date: Tue, 02 Aug 2005 17:46:07 +0200 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Developing a hybrid router/bridge." <rbridge@postel.org> References: <BB6D74C75CC76A419B6D6FA7C38317B28A29EF@sinett-sbs.SiNett.LAN> In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B28A29EF@sinett-sbs.SiNett.LAN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "fw.testbed.se", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: since the working group name is trill, are there any plans to change the name of the mailing list? trill@ietf.org would be good /Loa [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 AWL AWL: From: address is in the auto white-list X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: loa@pi.se Subject: [rbridge] name of the mailing list? X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Tue, 02 Aug 2005 15:49:38 -0000 Status: RO Content-Length: 425 since the working group name is trill, are there any plans to change the name of the mailing list? trill@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@acreo.se loa@pi.se Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j71DBZf15038 for <rbridge@postel.org>; Mon, 1 Aug 2005 06:11:35 -0700 (PDT) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j71DL98O028843 for <rbridge@postel.org>; Mon, 1 Aug 2005 06:21:10 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j71DI8kY012612 for <rbridge@postel.org>; Mon, 1 Aug 2005 08:18:09 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <NWCP7J87>; Mon, 1 Aug 2005 09:11:29 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810A3B5791@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> To: "Developing a hybrid router/bridge." <rbridge@postel.org> Date: Mon, 1 Aug 2005 09:11:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: donald.eastlake@motorola.com Subject: Re: [rbridge] Draft trill agenda X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 01 Aug 2005 13:12:32 -0000 Status: RO Content-Length: 1849 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@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Erik Nordmark Sent: Monday, August 01, 2005 5:34 AM To: rbridge@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 <erik.nordmark@sun.com> AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes <http://www.ietf.org/html.charters/trill-charter.html> 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 <draft-perlman-rbridge-rbridge-03.txt> Goal: Enumerate and discuss open issue Accept as WG document? _______________________________________________ rbridge mailing list rbridge@postel.org http://www.postel.org/mailman/listinfo/rbridge Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j719Xmf09884 for <rbridge@postel.org>; Mon, 1 Aug 2005 02:33:48 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j719Xl3t011033 for <rbridge@postel.org>; Mon, 1 Aug 2005 02:33:47 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j719Xj24344259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2005 02:33:47 -0700 (PDT) Message-ID: <42EDECA5.9060300@sun.com> Date: Mon, 01 Aug 2005 02:34:29 -0700 From: Erik Nordmark <erik.nordmark@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rbridge@postel.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: erik.nordmark@sun.com Subject: [rbridge] Draft trill agenda X-BeenThere: rbridge@postel.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "Developing a hybrid router/bridge." <rbridge@postel.org> List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org> List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe> List-Archive: <http://www.postel.org/pipermail/rbridge> List-Post: <mailto:rbridge@postel.org> List-Help: <mailto:rbridge-request@postel.org?subject=help> List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe> X-List-Received-Date: Mon, 01 Aug 2005 09:34:34 -0000 Status: RO Content-Length: 919 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 <erik.nordmark@sun.com> AGENDA: Introduction, Call for Scribes, Nordmark 05 minutes and Agenda Bashing Deliverables status Nordmark 10 minutes <http://www.ietf.org/html.charters/trill-charter.html> 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 <draft-perlman-rbridge-rbridge-03.txt> Goal: Enumerate and discuss open issue Accept as WG document?
- [rbridge] draft WG minutes Erik Nordmark
- [rbridge] draft WG minutes Gray, Eric
- [rbridge] draft WG minutes Vishwas Manral