From jeffpick at broadcom.com Wed Jul 1 10:53:34 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Wed, 1 Jul 2009 10:53:34 -0700 Subject: [rbridge] last call comment Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB0F@SJEXCHCCR02.corp.ad.broadcom.com> Section 4.5.1 "When building the tree number j, remember all possible equal cost parents for node N. After calculating the entire "tree" (actually, directed graph), for each node N, if N has "p" parents, then order the parents according to 7-byte ID. For tree j, choose N's parent as choice j mod p." I really dont like the idea of keeping all P parents, esp in an environment like fat tree where there may be dozens (64?) of upstream equal cost parents (times thousands of nodes). To require this will be a huge overhead. That said, we should at least say whether "order the parents" means starting with lowest or highest. Section 4.5.2 "In this case, R1-R2 adjacencies are ordered as follows, with the one "most preferred" adjacency being the one that R1 transmits to R2 on, and the one that R2 accepts traffic from R1 on:" The way I read this, the statement is meaningless, R1 and R2 both transmit to each other. So either the intent is to say R1 (or R2) is the RB closer to the root. Or the intent is to say that depending on whether traffic is flowing towards or away for the root, you may choose a different adjacency. Whichever interpretation is intended should be clarified. Section 4.5.2 "Most preferred are those established by P2P Hellos with tie- breaking among those based on preferring the one with the numerically highest Extended Circuit ID." According to rfc 5303, there is no concept of a shared extended circuit ID, only the ext cid advertised by each side. So this should be state which RBs ext cid is intended. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090701/fefe3935/attachment.html From jeffpick at broadcom.com Wed Jul 1 10:55:21 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Wed, 1 Jul 2009 10:55:21 -0700 Subject: [rbridge] last call comment Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> Section 4.5.1 "When building the tree number j, remember all possible equal cost parents for node N. After calculating the entire "tree" (actually, directed graph), for each node N, if N has "p" parents, then order the parents according to 7-byte ID. For tree j, choose N's parent as choice j mod p." I really dont like the idea of keeping all P parents, esp in an environment like fat tree where there may be dozens of upstream equal cost parents (times thousands of nodes). That said, we should at least say whether "order the parents" means starting with lowest or highest. Section 4.5.2 "In this case, R1-R2 adjacencies are ordered as follows, with the one "most preferred" adjacency being the one that R1 transmits to R2 on, and the one that R2 accepts traffic from R1 on:" The way I read this, the statement is meaningless, R1 and R2 both transmit to each other. So either the intent is to say R1 (or R2) is the RB closer to the root. Or the intent is to say that depending on whether traffic is flowing towards or away for the root, you may choose a different adjacency. Whichever interpretation is intended should be clarified. Section 4.5.2 Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090701/38d1e371/attachment.html From Radia.Perlman at sun.com Wed Jul 1 15:02:14 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 01 Jul 2009 15:02:14 -0700 Subject: [rbridge] last call comment In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <4A4BDCE6.1040806@sun.com> Well, if we want to allow load splitting with at least p trees, then we have to keep p parents. Alternatives to what is written, I think, are: a) keep as is: while computing the tree, keep all p parents. b) say that if p > j, then you only need to keep the top j choices of parent. (this is true, and might be a good clarification to put in) c) say that load splitting choices will never be more than, say, 5 (an architectural constant we will choose now and be stuck with forever), and then say that the top "5" choices of parents must be kept (so that the actual choice, for tree j, will be j mod 5). Choice b) does not affect the output-- it's just somewhat of an optimization for how to compute the trees. Would saying that be sufficient, or would you prefer that we actually limit the number of potential load splitting choices? Radia Jeff Pickering wrote: > > Section 4.5.1 > > > "When building the tree number j, remember all possible equal cost > > parents for node N. After calculating the entire "tree" (actually, > > directed graph), for each node N, if N has "p" parents, then order > > the parents according to 7-byte ID. For tree j, choose N's parent as > > choice j mod p." > > > > I really dont like the idea of keeping all P parents, esp in an > environment > > like fat tree where there may be dozens of upstream equal cost > parents (times thousands of nodes). > > That said, we should at least say whether "order the parents" > means starting with lowest or highest. > > > > > > Section 4.5.2 > > > > > > "In this case, R1-R2 adjacencies are ordered as follows, with > > the one "most preferred" adjacency being the one that R1 transmits > > to R2 on, and the one that R2 accepts traffic from R1 on:" > > > > > > The way I read this, the statement is meaningless, R1 and R2 > both transmit to each other. So > > either the intent is to say R1 (or R2) is the RB closer to the > root. Or the intent is to say that depending > > on whether traffic is flowing towards or away for the root, you > may choose a different adjacency. Whichever > > interpretation is intended should be clarified. > > > > Section 4.5.2 > > > > > > > > > > > > Jeff > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From jeffpick at broadcom.com Thu Jul 2 05:57:46 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Thu, 2 Jul 2009 05:57:46 -0700 Subject: [rbridge] last call comment In-Reply-To: <4A4BDCE6.1040806@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> <4A4BDCE6.1040806@sun.com> Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBB1@SJEXCHCCR02.corp.ad.broadcom.com> Radia, Please understand that I am coming from the perspective of data center applications where the heavily predominant architecture is one of a 3 tier fat tree with a radix of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2 for approximately 60% of the RBs (assuming top tier root placement which is what customers appear to want). I worry about the j mod p algorithm's impact on convergence times in this scenario. The algorithm provides no improvement in load sharing in this scenario either. And while I understand that writing a spec for a particular architecture is inappropriate (just look to What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p is really only ensured to help load sharing in the specific case of co-located roots or at least located very close together. In other cases, it may actually decrease load sharing. I understand your point that b) is no change and that it decreases at least some aspects of the increased storage/sorting that needs to be done. However, I would still prefer c) (5 seems realistic) because it limits the impact of optimizing for co/near located root case while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b). I someone wants to load share more than a new architectural constant, they can always do this using root placement. Or if there is a real problem with the constant, we can always make it configurable and place each RBs value in an LSP (we already have similar mechanisms). Jeff -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman at sun.com] Sent: Wednesday, July 01, 2009 6:02 PM To: Jeff Pickering Cc: rbridge at postel.org Subject: Re: [rbridge] last call comment Well, if we want to allow load splitting with at least p trees, then we have to keep p parents. Alternatives to what is written, I think, are: a) keep as is: while computing the tree, keep all p parents. b) say that if p > j, then you only need to keep the top j choices of parent. (this is true, and might be a good clarification to put in) c) say that load splitting choices will never be more than, say, 5 (an architectural constant we will choose now and be stuck with forever), and then say that the top "5" choices of parents must be kept (so that the actual choice, for tree j, will be j mod 5). Choice b) does not affect the output-- it's just somewhat of an optimization for how to compute the trees. Would saying that be sufficient, or would you prefer that we actually limit the number of potential load splitting choices? Radia Jeff Pickering wrote: > > Section 4.5.1 > > > "When building the tree number j, remember all possible equal cost > > parents for node N. After calculating the entire "tree" (actually, > > directed graph), for each node N, if N has "p" parents, then order > > the parents according to 7-byte ID. For tree j, choose N's parent as > > choice j mod p." > > > > I really dont like the idea of keeping all P parents, esp in an > environment > > like fat tree where there may be dozens of upstream equal cost > parents (times thousands of nodes). > > That said, we should at least say whether "order the parents" > means starting with lowest or highest. > > > > > > Section 4.5.2 > > > > > > "In this case, R1-R2 adjacencies are ordered as follows, with > > the one "most preferred" adjacency being the one that R1 transmits > > to R2 on, and the one that R2 accepts traffic from R1 on:" > > > > > > The way I read this, the statement is meaningless, R1 and R2 > both transmit to each other. So > > either the intent is to say R1 (or R2) is the RB closer to the > root. Or the intent is to say that depending > > on whether traffic is flowing towards or away for the root, you > may choose a different adjacency. Whichever > > interpretation is intended should be clarified. > > > > Section 4.5.2 > > > > > > > > > > > > Jeff > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From jeffpick at broadcom.com Thu Jul 2 06:33:19 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Thu, 2 Jul 2009 06:33:19 -0700 Subject: [rbridge] wglc comment - editorial Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBBE@SJEXCHCCR02.corp.ad.broadcom.com> Section 4.3.2 "If size X succeeds, and X > Sz, then RB1 advertises the largest tested X in RB1's LAN Hello, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP." Im assuming the LSP info described goes into a sub-tlv of the wide metrics ISN link. If so, should this be mentioned in section 4.2.4.4? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090702/3e96c9a0/attachment.html From Radia.Perlman at sun.com Thu Jul 2 20:50:52 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 02 Jul 2009 20:50:52 -0700 Subject: [rbridge] last call comment In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBB1@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> <4A4BDCE6.1040806@sun.com> <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBB1@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <4A4D801C.2050504@sun.com> It isn't me you have to convince. But a question...if there are that many paths, wouldn't people want to load-split on most of them? If we limit it to 5, then the 5 parents with highest ID at the 2nd tier will handle all the (multicast) traffic. I'd think that most of the traffic would be unicast, so it wouldn't really be a problem, but I suspect there are other people who would not be happy with a limit like 5. Radia Jeff Pickering wrote: > Radia, > > Please understand that I am coming from the perspective of data center applications > where the heavily predominant architecture is one of a 3 tier fat tree with a radix > of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2 > for approximately 60% of the RBs (assuming top tier root placement which is what > customers appear to want). I worry about the j mod p algorithm's impact on convergence > times in this scenario. > > The algorithm provides no improvement in load sharing in this scenario either. And while > I understand that writing a spec for a particular architecture is inappropriate (just look to > What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p > is really only ensured to help load sharing in the specific case of co-located roots or > at least located very close together. In other cases, it may actually decrease load sharing. > > I understand your point that b) is no change and that it decreases at least some aspects > of the increased storage/sorting that needs to be done. However, I would still prefer c) > (5 seems realistic) because it limits the impact of optimizing for co/near located root case > while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b). > > I someone wants to load share more than a new architectural constant, they can always do this > using root placement. Or if there is a real problem with the constant, we can always make it > configurable and place each RBs value in an LSP (we already have similar mechanisms). > > > Jeff > > > > -----Original Message----- > From: Radia Perlman [mailto:Radia.Perlman at sun.com] > Sent: Wednesday, July 01, 2009 6:02 PM > To: Jeff Pickering > Cc: rbridge at postel.org > Subject: Re: [rbridge] last call comment > > Well, if we want to allow load splitting with at least p trees, then we > have to keep p parents. > > Alternatives to what is written, I think, are: > > a) keep as is: while computing the tree, keep all p parents. > > b) say that if p > j, then you only need to keep the top j choices of > parent. (this > is true, and might be a good clarification to put in) > > c) say that load splitting choices will never be more than, say, 5 (an > architectural > constant we will choose now and be stuck with forever), and then say > that the top > "5" choices of parents must be kept (so that the actual choice, for tree > j, will > be j mod 5). > > Choice b) does not affect the output-- it's just somewhat of an > optimization for how > to compute the trees. > > Would saying that be sufficient, or would you prefer that we actually > limit the number of > potential load splitting choices? > > Radia > > > > Jeff Pickering wrote: > >> >> Section 4.5.1 >> >> >> "When building the tree number j, remember all possible equal cost >> >> parents for node N. After calculating the entire "tree" (actually, >> >> directed graph), for each node N, if N has "p" parents, then order >> >> the parents according to 7-byte ID. For tree j, choose N's parent as >> >> choice j mod p." >> >> >> >> I really dont like the idea of keeping all P parents, esp in an >> environment >> >> like fat tree where there may be dozens of upstream equal cost >> parents (times thousands of nodes). >> >> That said, we should at least say whether "order the parents" >> means starting with lowest or highest. >> >> >> >> >> >> Section 4.5.2 >> >> >> >> >> >> "In this case, R1-R2 adjacencies are ordered as follows, with >> >> the one "most preferred" adjacency being the one that R1 transmits >> >> to R2 on, and the one that R2 accepts traffic from R1 on:" >> >> >> >> >> >> The way I read this, the statement is meaningless, R1 and R2 >> both transmit to each other. So >> >> either the intent is to say R1 (or R2) is the RB closer to the >> root. Or the intent is to say that depending >> >> on whether traffic is flowing towards or away for the root, you >> may choose a different adjacency. Whichever >> >> interpretation is intended should be clarified. >> >> >> >> Section 4.5.2 >> >> >> >> >> >> >> >> >> >> >> >> Jeff >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > > > From d3e3e3 at gmail.com Thu Jul 2 21:02:08 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 3 Jul 2009 00:02:08 -0400 Subject: [rbridge] wglc comment - editorial In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBBE@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBBE@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <1028365c0907022102m32016cd9k3895d4edf22a2ead@mail.gmail.com> Hi Jeff, Your comment below on where the optional link size LSP information would go seems reasonable. I think it's also reasonable to mention this in 4.2.4.4. Thanks, Donald On Thu, Jul 2, 2009 at 9:33 AM, Jeff Pickering wrote: > > Section 4.3.2 > > > ?? "If size X succeeds, and X > Sz, then RB1 > > ?? advertises the largest tested X in RB1's LAN Hello, and RB1 MAY > > ?? advertise X as an attribute of the link to RB2 in RB1's LSP." > > > > > > Im assuming the LSP info described goes into a sub-tlv of the wide > > metrics ISN link. If so, should this be mentioned in section 4.2.4.4? > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > From d3e3e3 at gmail.com Thu Jul 2 21:30:23 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 3 Jul 2009 00:30:23 -0400 Subject: [rbridge] last call comment In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB0F@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB0F@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <1028365c0907022130u5e02b58ctb99f2766e492eb0a@mail.gmail.com> See partial response below... On Wed, Jul 1, 2009 at 1:53 PM, Jeff Pickering wrote: > > ... > > ???? Section 4.5.2 > > > ??????"In this case, R1-R2 adjacencies are ordered as follows, with > ????? the one "most preferred" adjacency being the one that R1 transmits > ????? to R2 on, and the one that R2 accepts traffic from R1 on:" > > ????? The way I read this, the statement is meaningless, R1 and R2 both > transmit to each other. So > ????? either the intent is to say R1 (or R2) is the RB closer to the root. > Or the intent is to say that depending > ????? on whether traffic is flowing towards or away for the root, you may > choose a different adjacency. Whichever > ????? interpretation is intended should be clarified. It's symmetric. This is all local to R1 and R2 and each should pick the same adjacency so it really makes no difference which way a particular frame is going or which of them is closer to the distribution tree root. The wording should be clarified. See other response below. > ??? Section 4.5.2 > > > ??? "Most preferred are those established by P2P Hellos with tie- > ????breaking among those based on preferring the one with the > ??? numerically highest Extended Circuit ID." > > ?????? According to rfc 5303, there is no concept of a shared extended > circuit ID, only the ext cid advertised by > ?????? each side. So this should be state which RBs ext cid is intended. Good observation. It should say something like "... the one for which the RBridge with the highest System-ID has assigned the numerically highest Extended Circuit ID." Also, it would probably be good to add RFC 5303 to the references. Note that this is symmetric. Both R1 and R2 will pick the same one of the parallel adjacencies to send to the other and to receive from the other. > ????? Jeff Thanks, Donald From jpickering at nc.rr.com Fri Jul 3 14:08:52 2009 From: jpickering at nc.rr.com (jeff pickering) Date: Fri, 03 Jul 2009 14:08:52 -0700 Subject: [rbridge] last call comment In-Reply-To: <4A4D801C.2050504@sun.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> <4A4BDCE6.1040806@sun.com> <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBB1@SJEXCHCCR02.corp.ad.broadcom.com> <4A4D801C.2050504@sun.com> Message-ID: <4A4E7364.7040609@nc.rr.com> Actually, by placing roots in differnt top tier groups, you guarantee that there are no overlapping paths in any tree. So by definition, you load balance maximally. Radia Perlman wrote: > It isn't me you have to convince. But a question...if there are that > many paths, wouldn't people want > to load-split on most of them? If we limit it to 5, then the 5 parents > with highest ID at the 2nd tier will > handle all the (multicast) traffic. > > I'd think that most of the traffic would be unicast, so it wouldn't > really be a problem, but I suspect > there are other people who would not be happy with a limit like 5. > > Radia > > > > > Jeff Pickering wrote: > >> Radia, >> >> Please understand that I am coming from the perspective of data center applications >> where the heavily predominant architecture is one of a 3 tier fat tree with a radix >> of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2 >> for approximately 60% of the RBs (assuming top tier root placement which is what >> customers appear to want). I worry about the j mod p algorithm's impact on convergence >> times in this scenario. >> >> The algorithm provides no improvement in load sharing in this scenario either. And while >> I understand that writing a spec for a particular architecture is inappropriate (just look to >> What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p >> is really only ensured to help load sharing in the specific case of co-located roots or >> at least located very close together. In other cases, it may actually decrease load sharing. >> >> I understand your point that b) is no change and that it decreases at least some aspects >> of the increased storage/sorting that needs to be done. However, I would still prefer c) >> (5 seems realistic) because it limits the impact of optimizing for co/near located root case >> while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b). >> >> I someone wants to load share more than a new architectural constant, they can always do this >> using root placement. Or if there is a real problem with the constant, we can always make it >> configurable and place each RBs value in an LSP (we already have similar mechanisms). >> >> >> Jeff >> >> >> >> -----Original Message----- >> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >> Sent: Wednesday, July 01, 2009 6:02 PM >> To: Jeff Pickering >> Cc: rbridge at postel.org >> Subject: Re: [rbridge] last call comment >> >> Well, if we want to allow load splitting with at least p trees, then we >> have to keep p parents. >> >> Alternatives to what is written, I think, are: >> >> a) keep as is: while computing the tree, keep all p parents. >> >> b) say that if p > j, then you only need to keep the top j choices of >> parent. (this >> is true, and might be a good clarification to put in) >> >> c) say that load splitting choices will never be more than, say, 5 (an >> architectural >> constant we will choose now and be stuck with forever), and then say >> that the top >> "5" choices of parents must be kept (so that the actual choice, for tree >> j, will >> be j mod 5). >> >> Choice b) does not affect the output-- it's just somewhat of an >> optimization for how >> to compute the trees. >> >> Would saying that be sufficient, or would you prefer that we actually >> limit the number of >> potential load splitting choices? >> >> Radia >> >> >> >> Jeff Pickering wrote: >> >> >>> >>> Section 4.5.1 >>> >>> >>> "When building the tree number j, remember all possible equal cost >>> >>> parents for node N. After calculating the entire "tree" (actually, >>> >>> directed graph), for each node N, if N has "p" parents, then order >>> >>> the parents according to 7-byte ID. For tree j, choose N's parent as >>> >>> choice j mod p." >>> >>> >>> >>> I really dont like the idea of keeping all P parents, esp in an >>> environment >>> >>> like fat tree where there may be dozens of upstream equal cost >>> parents (times thousands of nodes). >>> >>> That said, we should at least say whether "order the parents" >>> means starting with lowest or highest. >>> >>> >>> >>> >>> >>> Section 4.5.2 >>> >>> >>> >>> >>> >>> "In this case, R1-R2 adjacencies are ordered as follows, with >>> >>> the one "most preferred" adjacency being the one that R1 transmits >>> >>> to R2 on, and the one that R2 accepts traffic from R1 on:" >>> >>> >>> >>> >>> >>> The way I read this, the statement is meaningless, R1 and R2 >>> both transmit to each other. So >>> >>> either the intent is to say R1 (or R2) is the RB closer to the >>> root. Or the intent is to say that depending >>> >>> on whether traffic is flowing towards or away for the root, you >>> may choose a different adjacency. Whichever >>> >>> interpretation is intended should be clarified. >>> >>> >>> >>> Section 4.5.2 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Jeff >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >>> >> >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > From d3e3e3 at gmail.com Fri Jul 3 17:01:00 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 3 Jul 2009 20:01:00 -0400 Subject: [rbridge] TRILL Hello size: draft-ietf-trill-rbridge-protocol-13.txt Message-ID: <1028365c0907031701t298aa4e1t79a7e7ddbd00d3f6@mail.gmail.com> Unless I'm missing something, while this draft motivates the TRILL-Hello message and specifies much about it, it does not specify any size limit :-( I believe the following should be added near the beginning of Section 4.4.2: "TRILL-Hello frames MUST NOT exceed 1470 bytes in length and SHOULD NOT be padded." Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From d3e3e3 at gmail.com Fri Jul 3 20:43:15 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 3 Jul 2009 23:43:15 -0400 Subject: [rbridge] Consensus to remove "Other Multicast" bit? In-Reply-To: <4A392681.4070207@sun.com> References: <4A392681.4070207@sun.com> Message-ID: <1028365c0907032043q2009e662tf239d08015ce5e57@mail.gmail.com> There was no response to the message below and draft-ietf-trill-rbridge-protocol-13.txt was posted with the Other Multicast bit removed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Wed, Jun 17, 2009 at 1:23 PM, Erik Nordmark wrote: > > There has been some discussion about removing the Other Multicast bit on the > mailing list, with a few people wanting to see it removed and no-one arguing > to keep it. > > Since the Other Multicast bit was added to the base protocol > specification based on working group consensus, it makes sense to formally > ask for WG consensus regarding its removal. > > If you are in favor of keeping this bit, please > speak up now. Otherwise, we will conclude that the WG consensus has > changed. > > ? Erik and Donald > From Radia.Perlman at sun.com Sat Jul 4 00:07:06 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sat, 04 Jul 2009 00:07:06 -0700 Subject: [rbridge] TRILL Hello size: draft-ietf-trill-rbridge-protocol-13.txt In-Reply-To: <1028365c0907031701t298aa4e1t79a7e7ddbd00d3f6@mail.gmail.com> References: <1028365c0907031701t298aa4e1t79a7e7ddbd00d3f6@mail.gmail.com> Message-ID: <4A4EFF9A.1030402@sun.com> Right. It would be good to specify a maximum size limit of a TRILL-Hello message. Your suggestion of fixing it at 1470 seems reasonable. Radia Donald Eastlake wrote: > Unless I'm missing something, while this draft motivates the > TRILL-Hello message and specifies much about it, it does not specify > any size limit :-( > > I believe the following should be added near the beginning of Section 4.4.2: > "TRILL-Hello frames MUST NOT exceed 1470 bytes in length and SHOULD > NOT be padded." > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From jeffpick at broadcom.com Mon Jul 6 04:46:34 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Mon, 6 Jul 2009 04:46:34 -0700 Subject: [rbridge] wglc comments Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CD36@SJEXCHCCR02.corp.ad.broadcom.com> I think there are a couple of things not described that probably need it (pardon me if Ive read the doc too many times and missed something): - There should be something describing L1 ISIS only usage. - There should be something describing the set of LSPs to use for dist tree root choosing: ie, all LSPs or SPF reachable LSPs. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090706/86556678/attachment.html From d3e3e3 at gmail.com Mon Jul 6 20:55:34 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 6 Jul 2009 23:55:34 -0400 Subject: [rbridge] wglc comments In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CD36@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CD36@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <1028365c0907062055g4e3c565ei38479b847ffdda24@mail.gmail.com> See below On Mon, Jul 6, 2009 at 7:46 AM, Jeff Pickering wrote: > > I think there are a couple of things not described that probably need it > (pardon me if Ive read the doc too many times and missed something): > > - There should be something describing L1 ISIS only usage. That seems reasonable. Perhaps the first sentence in Section 4.2.3 ("All Rbridges must participate in the TRILL IS-IS instance.") should have "which constitutes a single Level 1 IS-IS area using the fixed area-ID zero" appended to it. > - There should be something describing the set of LSPs to use for > ??dist tree root choosing: ie, all LSPs or SPF reachable LSPs. Perhaps I'm confused. Are you saying that an RBridge campus could consist of multiple sets of RBridges such that there would be no SPF path between RBridges in different sets but where all RBridges would get all the LSPs? > Thanks, > Jeff > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > From jpickering at nc.rr.com Tue Jul 7 05:24:56 2009 From: jpickering at nc.rr.com (jeff pickering) Date: Tue, 07 Jul 2009 05:24:56 -0700 Subject: [rbridge] wglc comments In-Reply-To: <1028365c0907062055g4e3c565ei38479b847ffdda24@mail.gmail.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CD36@SJEXCHCCR02.corp.ad.broadcom.com> <1028365c0907062055g4e3c565ei38479b847ffdda24@mail.gmail.com> Message-ID: <4A533E98.6010109@nc.rr.com> Donald, It is certainly possible that an LSP sender can crash, links go down. The campus can get partitioned. Im just saying we should explicitly specify whats done in this case. The spec kind of implies that you use all LSPs which would mean a crashed sender could still win and specify itself as a root. Of course there is the separate issue of an LSP originator specifying a third party as root and that root could be unreachable. Jeff Donald Eastlake wrote: > See below > > On Mon, Jul 6, 2009 at 7:46 AM, Jeff Pickering wrote: > >> I think there are a couple of things not described that probably need it >> (pardon me if Ive read the doc too many times and missed something): >> >> - There should be something describing L1 ISIS only usage. >> > > That seems reasonable. Perhaps the first sentence in Section 4.2.3 > ("All Rbridges must participate in the TRILL IS-IS instance.") should > have "which constitutes a single Level 1 IS-IS area using the fixed > area-ID zero" appended to it. > > >> - There should be something describing the set of LSPs to use for >> dist tree root choosing: ie, all LSPs or SPF reachable LSPs. >> > > Perhaps I'm confused. Are you saying that an RBridge campus could > consist of multiple sets of RBridges such that there would be no SPF > path between RBridges in different sets but where all RBridges would > get all the LSPs? > > >> Thanks, >> Jeff >> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > > From jeffpick at broadcom.com Thu Jul 9 08:57:34 2009 From: jeffpick at broadcom.com (Jeff Pickering) Date: Thu, 9 Jul 2009 08:57:34 -0700 Subject: [rbridge] wglc question Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2D122@SJEXCHCCR02.corp.ad.broadcom.com> How do we handle a case where a piece of hardware physically only handles N trees, but root determination requires N+1? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090709/9b17931a/attachment.html From d3e3e3 at gmail.com Thu Jul 9 10:33:01 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 9 Jul 2009 13:33:01 -0400 Subject: [rbridge] wglc question In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2D122@SJEXCHCCR02.corp.ad.broadcom.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2D122@SJEXCHCCR02.corp.ad.broadcom.com> Message-ID: <1028365c0907091033k533e2cacs678a4d2d453fb266@mail.gmail.com> That's specified in the first part of Section 4.5 in draft -13. The number is limited by the smallest number of trees any RBridge advertises it can handle. The easiest way to find this text is to search for the typo "nomore" (should be "no more") :-) Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Jul 9, 2009 at 11:57 AM, Jeff Pickering wrote: > > How do we handle a case where a piece of hardware physically only handles N > trees, > but root determination requires N+1? > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > From ddutt at cisco.com Wed Jul 15 11:10:45 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Wed, 15 Jul 2009 11:10:45 -0700 Subject: [rbridge] last call comment In-Reply-To: <4A4E7364.7040609@nc.rr.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> <4A4BDCE6.1040806@sun.com> <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBB1@SJEXCHCCR02.corp.ad.broadcom.com> <4A4D801C.2050504@sun.com> <4A4E7364.7040609@nc.rr.com> Message-ID: <4A5E1BA5.5070009@cisco.com> Why can't we limit the number of parents you pick to the number of trees that need to be computed ? The network topology that you state Jeff is not as common as you're suggesting, though it is a popular one, Dinesh jeff pickering wrote: > Actually, by placing roots in differnt top tier groups, you guarantee > that there are no overlapping paths > in any tree. So by definition, you load balance maximally. > > Radia Perlman wrote: > >> It isn't me you have to convince. But a question...if there are that >> many paths, wouldn't people want >> to load-split on most of them? If we limit it to 5, then the 5 parents >> with highest ID at the 2nd tier will >> handle all the (multicast) traffic. >> >> I'd think that most of the traffic would be unicast, so it wouldn't >> really be a problem, but I suspect >> there are other people who would not be happy with a limit like 5. >> >> Radia >> >> >> >> >> Jeff Pickering wrote: >> >> >>> Radia, >>> >>> Please understand that I am coming from the perspective of data center applications >>> where the heavily predominant architecture is one of a 3 tier fat tree with a radix >>> of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2 >>> for approximately 60% of the RBs (assuming top tier root placement which is what >>> customers appear to want). I worry about the j mod p algorithm's impact on convergence >>> times in this scenario. >>> >>> The algorithm provides no improvement in load sharing in this scenario either. And while >>> I understand that writing a spec for a particular architecture is inappropriate (just look to >>> What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p >>> is really only ensured to help load sharing in the specific case of co-located roots or >>> at least located very close together. In other cases, it may actually decrease load sharing. >>> >>> I understand your point that b) is no change and that it decreases at least some aspects >>> of the increased storage/sorting that needs to be done. However, I would still prefer c) >>> (5 seems realistic) because it limits the impact of optimizing for co/near located root case >>> while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b). >>> >>> I someone wants to load share more than a new architectural constant, they can always do this >>> using root placement. Or if there is a real problem with the constant, we can always make it >>> configurable and place each RBs value in an LSP (we already have similar mechanisms). >>> >>> >>> Jeff >>> >>> >>> >>> -----Original Message----- >>> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >>> Sent: Wednesday, July 01, 2009 6:02 PM >>> To: Jeff Pickering >>> Cc: rbridge at postel.org >>> Subject: Re: [rbridge] last call comment >>> >>> Well, if we want to allow load splitting with at least p trees, then we >>> have to keep p parents. >>> >>> Alternatives to what is written, I think, are: >>> >>> a) keep as is: while computing the tree, keep all p parents. >>> >>> b) say that if p > j, then you only need to keep the top j choices of >>> parent. (this >>> is true, and might be a good clarification to put in) >>> >>> c) say that load splitting choices will never be more than, say, 5 (an >>> architectural >>> constant we will choose now and be stuck with forever), and then say >>> that the top >>> "5" choices of parents must be kept (so that the actual choice, for tree >>> j, will >>> be j mod 5). >>> >>> Choice b) does not affect the output-- it's just somewhat of an >>> optimization for how >>> to compute the trees. >>> >>> Would saying that be sufficient, or would you prefer that we actually >>> limit the number of >>> potential load splitting choices? >>> >>> Radia >>> >>> >>> >>> Jeff Pickering wrote: >>> >>> >>> >>>> >>>> Section 4.5.1 >>>> >>>> >>>> "When building the tree number j, remember all possible equal cost >>>> >>>> parents for node N. After calculating the entire "tree" (actually, >>>> >>>> directed graph), for each node N, if N has "p" parents, then order >>>> >>>> the parents according to 7-byte ID. For tree j, choose N's parent as >>>> >>>> choice j mod p." >>>> >>>> >>>> >>>> I really dont like the idea of keeping all P parents, esp in an >>>> environment >>>> >>>> like fat tree where there may be dozens of upstream equal cost >>>> parents (times thousands of nodes). >>>> >>>> That said, we should at least say whether "order the parents" >>>> means starting with lowest or highest. >>>> >>>> >>>> >>>> >>>> >>>> Section 4.5.2 >>>> >>>> >>>> >>>> >>>> >>>> "In this case, R1-R2 adjacencies are ordered as follows, with >>>> >>>> the one "most preferred" adjacency being the one that R1 transmits >>>> >>>> to R2 on, and the one that R2 accepts traffic from R1 on:" >>>> >>>> >>>> >>>> >>>> >>>> The way I read this, the statement is meaningless, R1 and R2 >>>> both transmit to each other. So >>>> >>>> either the intent is to say R1 (or R2) is the RB closer to the >>>> root. Or the intent is to say that depending >>>> >>>> on whether traffic is flowing towards or away for the root, you >>>> may choose a different adjacency. Whichever >>>> >>>> interpretation is intended should be clarified. >>>> >>>> >>>> >>>> Section 4.5.2 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Jeff >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>>> >>>> >>>> >>> >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From ayabaner at cisco.com Wed Jul 15 16:49:49 2009 From: ayabaner at cisco.com (Ayan Banerjee) Date: Wed, 15 Jul 2009 16:49:49 -0700 Subject: [rbridge] Last Call comments on draft-ietf-trill-rbridge-protocol-13.txt In-Reply-To: <4A5E1BA5.5070009@cisco.com> Message-ID: All, Please see attached comments on the Last Call for draft-ietf-trill-rbridge-protocol-13.txt: 1. Section 3.7.3 The last sentence of this section seems to give the impression that nicknames are LSP specific and node specific. "If it is desired for a pseudonode to be a tree root, the DRB MAY request one or more nicknames in the pseudonode LSP. " Can we please remove this sentence from this section? 2. Section 4.3.1 The default choice of 1470 bytes. If a host is connected to a Rbridge port, is this choice acceptable? 3. Section 4.4 I am hoping on some clarification of the design - say there are 3 Rbridges on the same "lan" with vlans enabled on them being Rbridge-A (Vlans 1, 2), Rbridge-B (Vlans 1, 3), Rbridge-C (Vlans 1, 2, and 3). If Rbridge-A becomes the DRB, then vlan-3 is isolated - is this accurate? In essence, whoever becomes the DRB decides on which vlans in the "lan" is active. Alternatively, let us assume there are number of nodes with vlans 1, 2, and a new node with enabled vlans 2, 3 got introduced that will become the DRB in the "lan"; will traffic that was flowing for vlan-1 be isolated - i.e., can the new-DRB appoint other nodes to be AF for vlan 1 - a vlan on which it is not enabled? It would be nice to have a small bring-up scenario (possibly in the appendix) to show the up down transitions from adjacencies, DRBs etc as and when the above scenario or any other scenario occurs. 4. Section 4.5.1 The number of trees to compute is based on what the root node states. If I understand this accurately, Rbridge-A will say say it wants 4 trees in the domain if it becomes root. Say it eventually, becomes the root, but there is a Rbridge-B that wants to compute no more than 2 trees. This number will now drop down to 2 - accurate? Also, if Rbridge-B is the only node that wants 2 trees and all others want 4 trees, this number will keep on oscillating if the adjacency to Rbridge-B keeps on flapping. It seems to me that we will be creating/deleting a number of trees in this scenario. 5. Section 4.9.1 This will not achieve what is being desired (transit traffic functionality, I presume) using IS-IS rules at this time. Can this paragraph be deleted? "In some cases even though the DRB has the "access port" flag set, the DRB MAY choose to create a pseudonode for the access port. In this case, the other RBridges report connectivity to the pseudonode in their LSP, but the DRB sets the "overload" flag in the pseudonode LSP." Thanks, Ayan From Radia.Perlman at sun.com Wed Jul 15 22:24:06 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 15 Jul 2009 22:24:06 -0700 Subject: [rbridge] Last Call comments on draft-ietf-trill-rbridge-protocol-13.txt In-Reply-To: References: Message-ID: <4A5EB976.7070108@sun.com> Ayan Banerjee wrote: > All, > > Please see attached comments on the Last Call for > draft-ietf-trill-rbridge-protocol-13.txt: > > 1. Section 3.7.3 > The last sentence of this section seems to give the impression that > nicknames are LSP specific and node specific. > "If it is desired for a pseudonode to be a tree root, the DRB MAY > request one or more nicknames in the pseudonode LSP. " > Can we please remove this sentence from this section? > Why remove it? There are cases where it is useful for a pseudonode to have a nickname. Are you just objecting to wording? > 2. Section 4.3.1 > The default choice of 1470 bytes. If a host is connected to a Rbridge port, > is this choice acceptable? > > 3. Section 4.4 > I am hoping on some clarification of the design - say there are 3 Rbridges > on the same "lan" with vlans enabled on them being Rbridge-A (Vlans 1, 2), > Rbridge-B (Vlans 1, 3), Rbridge-C (Vlans 1, 2, and 3). If Rbridge-A becomes > the DRB, then vlan-3 is isolated - is this accurate? I don't think so. It shouldn't be necessary for the DRB to be able to handle VLAN 3 -- it should be able to appoint RBC as designated forwarder for VLAN 3. > In essence, whoever > becomes the DRB decides on which vlans in the "lan" is active. > I think it only decides what is the designated VLAN, and decides who to appoint designated forwarder for other VLANs. > Alternatively, let us assume there are number of nodes with vlans 1, 2, and > a new node with enabled vlans 2, 3 got introduced that will become the DRB > in the "lan"; will traffic that was flowing for vlan-1 be isolated - i.e., > can the new-DRB appoint other nodes to be AF for vlan 1 - a vlan on which it > is not enabled? It would be nice to have a small bring-up scenario (possibly > in the appendix) to show the up down transitions from adjacencies, DRBs etc > as and when the above scenario or any other scenario occurs. > I think this is the same case you just talked about. I'm pretty sure that the DRB can appoint a designated forwarder for a VLAN that the DRB itself does not support. But an RBridge that can't talk on the designated VLAN will be isolated. > 4. Section 4.5.1 > The number of trees to compute is based on what the root node states. If I > understand this accurately, Rbridge-A will say say it wants 4 trees in the > domain if it becomes root. Say it eventually, becomes the root, but there is > a Rbridge-B that wants to compute no more than 2 trees. This number will now > drop down to 2 - accurate? Also, if Rbridge-B is the only node that wants 2 > trees and all others want 4 trees, this number will keep on oscillating if > the adjacency to Rbridge-B keeps on flapping. It seems to me that we will be > creating/deleting a number of trees in this scenario. > Yeah it's kind of ugly to have RBridges that can't support the number of trees the DRB would like. Not sure how to fix it though. > 5. Section 4.9.1 > This will not achieve what is being desired (transit traffic functionality, > I presume) using IS-IS rules at this time. Can this paragraph be deleted? > > "In some cases even though the DRB has the "access port" flag set, > the DRB MAY choose to create a pseudonode for the access port. In > this case, the other RBridges report connectivity to the > pseudonode in their LSP, but the DRB sets the "overload" flag in > the pseudonode LSP." > This is an obscure case that is indeed useful. I don't quite remember the example, but it has to do with bridges that do multilinking through two upstream nodes. Radia From ddutt at cisco.com Thu Jul 16 09:43:58 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 16 Jul 2009 09:43:58 -0700 Subject: [rbridge] Last Call comments on draft-ietf-trill-rbridge-protocol-13.txt In-Reply-To: <4A5EB976.7070108@sun.com> References: <4A5EB976.7070108@sun.com> Message-ID: <4A5F58CE.5090806@cisco.com> Radia Perlman wrote: > Ayan Banerjee wrote: > >> All, >> >> Please see attached comments on the Last Call for >> draft-ietf-trill-rbridge-protocol-13.txt: >> >> 1. Section 3.7.3 >> The last sentence of this section seems to give the impression that >> nicknames are LSP specific and node specific. >> "If it is desired for a pseudonode to be a tree root, the DRB MAY >> request one or more nicknames in the pseudonode LSP. " >> Can we please remove this sentence from this section? >> >> > > Why remove it? There are cases where it is useful for a pseudonode to > have a nickname. > Are you just objecting to wording? > What cases ? Dinesh -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From Radia.Perlman at sun.com Thu Jul 16 12:18:37 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 16 Jul 2009 12:18:37 -0700 Subject: [rbridge] Last Call comments on draft-ietf-trill-rbridge-protocol-13.txt In-Reply-To: <4A5F58CE.5090806@cisco.com> References: <4A5EB976.7070108@sun.com> <4A5F58CE.5090806@cisco.com> Message-ID: <4A5F7D0D.80204@sun.com> It had to do with two RBridges, R1, and R2, connected to the same edge cloud via a bridge B, where B has some weird feature where it has 3 ports say, one each to R1 and R2, and the other to a cloud of endnodes. B forwards traffic from the endnodes to *only one* of R1 and R2. B *never* forwards between R1 and R2. R1 and R2 know that this is going on (they've been configured). So the idea is that if the pseudonode associated with that cloud is given a nickname, then both R1 and R2 can act as encapsulator/decapsulators, and set the ingress nickname as the pseudonode. Then return traffic can go shortest path to either R1 or R2 since the actual egress is the LAN itself. But even though in the topology both R1 and R2 are connected to that LAN, they can't forward to each other, so luckily the IS-IS "overload" feature, which is already there, handles that case perfectly. There might have been other reasons why someone was asking for it to be optional to ask for a nickname for a pseudonode. Certainly seems easy not to go out of our way to preclude it. Radia Dinesh G Dutt wrote: > > > Radia Perlman wrote: >> Ayan Banerjee wrote: >> >>> All, >>> Please see attached comments on the Last Call for >>> draft-ietf-trill-rbridge-protocol-13.txt: >>> >>> 1. Section 3.7.3 >>> The last sentence of this section seems to give the impression that >>> nicknames are LSP specific and node specific. >>> "If it is desired for a pseudonode to be a tree root, the DRB MAY >>> request one or more nicknames in the pseudonode LSP. " >>> Can we please remove this sentence from this section? >>> >> >> Why remove it? There are cases where it is useful for a pseudonode to >> have a nickname. >> Are you just objecting to wording? >> > What cases ? > > Dinesh > From Radia.Perlman at sun.com Thu Jul 16 13:18:14 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Thu, 16 Jul 2009 13:18:14 -0700 Subject: [rbridge] Last Call comments on draft-ietf-trill-rbridge-protocol-13.txt In-Reply-To: <4A5F7D0D.80204@sun.com> References: <4A5EB976.7070108@sun.com> <4A5F58CE.5090806@cisco.com> <4A5F7D0D.80204@sun.com> Message-ID: <4A5F8B06.1030803@sun.com> Oh right. There was a much simpler reason for asking for a pseudonode to optionally be able to have a nickname -- that was because in some topologies a pseudonode might make a good tree root. Radia Radia Perlman wrote: > It had to do with two RBridges, R1, and R2, connected to the same edge > cloud via a bridge B, > where B has some weird feature where it has 3 ports say, one each to R1 > and R2, and the other to > a cloud of endnodes. B forwards traffic from the endnodes to *only one* > of R1 and R2. > B *never* forwards between > R1 and R2. R1 and R2 know that this is going on (they've been configured). > > So the idea is that if the pseudonode associated with that cloud is > given a nickname, then both R1 > and R2 can act as encapsulator/decapsulators, and set the ingress > nickname as the pseudonode. > Then return traffic can go shortest path to either R1 or R2 since the > actual egress is the LAN itself. > But even though in the topology both R1 and R2 are connected to that > LAN, they can't forward to > each other, so luckily the IS-IS "overload" feature, which is already > there, handles that case perfectly. > > There might have been other reasons why someone was asking for it to be > optional to ask for > a nickname for a pseudonode. Certainly seems easy not to go out of our > way to preclude it. > > Radia > > > Dinesh G Dutt wrote: > >> Radia Perlman wrote: >> >>> Ayan Banerjee wrote: >>> >>> >>>> All, >>>> Please see attached comments on the Last Call for >>>> draft-ietf-trill-rbridge-protocol-13.txt: >>>> >>>> 1. Section 3.7.3 >>>> The last sentence of this section seems to give the impression that >>>> nicknames are LSP specific and node specific. >>>> "If it is desired for a pseudonode to be a tree root, the DRB MAY >>>> request one or more nicknames in the pseudonode LSP. " >>>> Can we please remove this sentence from this section? >>>> >>>> >>> Why remove it? There are cases where it is useful for a pseudonode to >>> have a nickname. >>> Are you just objecting to wording? >>> >>> >> What cases ? >> >> Dinesh >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From jpickering at nc.rr.com Sat Jul 18 06:48:29 2009 From: jpickering at nc.rr.com (jeff pickering) Date: Sat, 18 Jul 2009 06:48:29 -0700 Subject: [rbridge] last call comment In-Reply-To: <4A5E1BA5.5070009@cisco.com> References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CB10@SJEXCHCCR02.corp.ad.broadcom.com> <4A4BDCE6.1040806@sun.com> <9793EC0A42D76D4EB2A8F94D77E2138893C4F2CBB1@SJEXCHCCR02.corp.ad.broadcom.com> <4A4D801C.2050504@sun.com> <4A4E7364.7040609@nc.rr.com> <4A5E1BA5.5070009@cisco.com> Message-ID: <4A61D2AD.1010401@nc.rr.com> Dinesh, After thinking about this some more, Ive decided I can live with the spec as is. Ive been able to come up with some spf optimizations that make life not quite so bad. Jeff Dinesh G Dutt wrote: > Why can't we limit the number of parents you pick to the number of trees > that need to be computed ? The network topology that you state Jeff is > not as common as you're suggesting, though it is a popular one, > > Dinesh > jeff pickering wrote: > >> Actually, by placing roots in differnt top tier groups, you guarantee >> that there are no overlapping paths >> in any tree. So by definition, you load balance maximally. >> >> Radia Perlman wrote: >> >> >>> It isn't me you have to convince. But a question...if there are that >>> many paths, wouldn't people want >>> to load-split on most of them? If we limit it to 5, then the 5 parents >>> with highest ID at the 2nd tier will >>> handle all the (multicast) traffic. >>> >>> I'd think that most of the traffic would be unicast, so it wouldn't >>> really be a problem, but I suspect >>> there are other people who would not be happy with a limit like 5. >>> >>> Radia >>> >>> >>> >>> >>> Jeff Pickering wrote: >>> >>> >>> >>>> Radia, >>>> >>>> Please understand that I am coming from the perspective of data center applications >>>> where the heavily predominant architecture is one of a 3 tier fat tree with a radix >>>> of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2 >>>> for approximately 60% of the RBs (assuming top tier root placement which is what >>>> customers appear to want). I worry about the j mod p algorithm's impact on convergence >>>> times in this scenario. >>>> >>>> The algorithm provides no improvement in load sharing in this scenario either. And while >>>> I understand that writing a spec for a particular architecture is inappropriate (just look to >>>> What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p >>>> is really only ensured to help load sharing in the specific case of co-located roots or >>>> at least located very close together. In other cases, it may actually decrease load sharing. >>>> >>>> I understand your point that b) is no change and that it decreases at least some aspects >>>> of the increased storage/sorting that needs to be done. However, I would still prefer c) >>>> (5 seems realistic) because it limits the impact of optimizing for co/near located root case >>>> while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b). >>>> >>>> I someone wants to load share more than a new architectural constant, they can always do this >>>> using root placement. Or if there is a real problem with the constant, we can always make it >>>> configurable and place each RBs value in an LSP (we already have similar mechanisms). >>>> >>>> >>>> Jeff >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Radia Perlman [mailto:Radia.Perlman at sun.com] >>>> Sent: Wednesday, July 01, 2009 6:02 PM >>>> To: Jeff Pickering >>>> Cc: rbridge at postel.org >>>> Subject: Re: [rbridge] last call comment >>>> >>>> Well, if we want to allow load splitting with at least p trees, then we >>>> have to keep p parents. >>>> >>>> Alternatives to what is written, I think, are: >>>> >>>> a) keep as is: while computing the tree, keep all p parents. >>>> >>>> b) say that if p > j, then you only need to keep the top j choices of >>>> parent. (this >>>> is true, and might be a good clarification to put in) >>>> >>>> c) say that load splitting choices will never be more than, say, 5 (an >>>> architectural >>>> constant we will choose now and be stuck with forever), and then say >>>> that the top >>>> "5" choices of parents must be kept (so that the actual choice, for tree >>>> j, will >>>> be j mod 5). >>>> >>>> Choice b) does not affect the output-- it's just somewhat of an >>>> optimization for how >>>> to compute the trees. >>>> >>>> Would saying that be sufficient, or would you prefer that we actually >>>> limit the number of >>>> potential load splitting choices? >>>> >>>> Radia >>>> >>>> >>>> >>>> Jeff Pickering wrote: >>>> >>>> >>>> >>>> >>>>> >>>>> Section 4.5.1 >>>>> >>>>> >>>>> "When building the tree number j, remember all possible equal cost >>>>> >>>>> parents for node N. After calculating the entire "tree" (actually, >>>>> >>>>> directed graph), for each node N, if N has "p" parents, then order >>>>> >>>>> the parents according to 7-byte ID. For tree j, choose N's parent as >>>>> >>>>> choice j mod p." >>>>> >>>>> >>>>> >>>>> I really dont like the idea of keeping all P parents, esp in an >>>>> environment >>>>> >>>>> like fat tree where there may be dozens of upstream equal cost >>>>> parents (times thousands of nodes). >>>>> >>>>> That said, we should at least say whether "order the parents" >>>>> means starting with lowest or highest. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Section 4.5.2 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> "In this case, R1-R2 adjacencies are ordered as follows, with >>>>> >>>>> the one "most preferred" adjacency being the one that R1 transmits >>>>> >>>>> to R2 on, and the one that R2 accepts traffic from R1 on:" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The way I read this, the statement is meaningless, R1 and R2 >>>>> both transmit to each other. So >>>>> >>>>> either the intent is to say R1 (or R2) is the RB closer to the >>>>> root. Or the intent is to say that depending >>>>> >>>>> on whether traffic is flowing towards or away for the root, you >>>>> may choose a different adjacency. Whichever >>>>> >>>>> interpretation is intended should be clarified. >>>>> >>>>> >>>>> >>>>> Section 4.5.2 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Jeff >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> rbridge mailing list >>>>> rbridge at postel.org >>>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >>> >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > From david.bond at iol.unh.edu Fri Jul 24 09:03:27 2009 From: david.bond at iol.unh.edu (David Michael Bond) Date: Fri, 24 Jul 2009 12:03:27 -0400 Subject: [rbridge] IS-IS Level and TRILL Question Message-ID: <007b01ca0c78$482f7900$d88e6b00$@bond@iol.unh.edu> Hello Everyone, I had a question regarding IS-IS and TRILL. My apologies if this has been brought up in the past. Recently the follow comment was made: Perhaps the first sentence in Section 4.2.3 ("All Rbridges must participate in the TRILL IS-IS instance.") should have "which constitutes a single Level 1 IS-IS area using the fixed area-ID zero" appended to it. My question is, is there anything preventing layer 2 TRILL IS-IS from being configured as multiple level domain such as layer 3 IS-IS? This would break "zero configuration" but if some campus wished to have this additional control is there any reason why this could not be done? I also realize that TRILL is not meant to be any larger than existing layer 2 networks. So there might not be the desire for that additional control. Thanks, David ~~~~~~~~~~~ David Bond Research and Development, Routing InterOperability Laboratory, University of New Hampshire From Radia.Perlman at sun.com Sat Jul 25 21:10:02 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sat, 25 Jul 2009 21:10:02 -0700 Subject: [rbridge] IS-IS Level and TRILL Question In-Reply-To: <007b01ca0c78$482f7900$d88e6b00$%bond@iol.unh.edu> References: <007b01ca0c78$482f7900$d88e6b00$%bond@iol.unh.edu> Message-ID: <4A6BD71A.3050702@sun.com> I like David's suggested wording. It is a clarification. As for whether we'd ever want mulilevel TRILL...I'm not sure how valuable multilevel TRILL would be since I think the nicknames have to be globally unique within the entire TRILL campus and there's no ability to aggregate endnode learning. So it's possible that a campus would run out of nicknames, or get overrun with unknown destination flooding or ARPs, long before there would be any benefit of moving to multiple levels of hierarchy. Radia David Michael Bond wrote: > Hello Everyone, > I had a question regarding IS-IS and TRILL. My apologies if this has been > brought up in the past. > > Recently the follow comment was made: > Perhaps the first sentence in Section 4.2.3 ("All Rbridges must > participate in the TRILL IS-IS instance.") should have "which constitutes a > single Level 1 IS-IS area using the fixed area-ID zero" appended to it. > > My question is, is there anything preventing layer 2 TRILL IS-IS from being > configured as multiple level domain such as layer 3 IS-IS? This would break > "zero configuration" but if some campus wished to have this additional > control is there any reason why this could not be done? I also realize that > TRILL is not meant to be any larger than existing layer 2 networks. So there > might not be the desire for that additional control. > > Thanks, > David > > ~~~~~~~~~~~ > David Bond > Research and Development, Routing > InterOperability Laboratory, University of New Hampshire > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From d3e3e3 at gmail.com Wed Jul 29 21:33:01 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 30 Jul 2009 00:33:01 -0400 Subject: [rbridge] Default Link Costs in base protocol -13 Message-ID: <1028365c0907292133s4a32319bg1b2f2069667bfd45@mail.gmail.com> Hi, I'm thinking that something like this should be added to item 1 in section 4.2.4.4 of the base protocol draft version -13: To facilitate efficient zero configuration operation, RBridges SHOULD, by default, set the cost of a link to one trillion (1,000,000,000,000) diviided by the RBridge port's bit rate rounded to the nearest value that will fit in the wide metric; for example, the cost for a link accessed by a 1Gbps port would default to 1,000. However, the cost MAY, by default, be increased if the link appears to be a bridged LAN. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From Radia.Perlman at sun.com Wed Jul 29 22:28:55 2009 From: Radia.Perlman at sun.com (Radia Perlman) Date: Wed, 29 Jul 2009 22:28:55 -0700 Subject: [rbridge] Default Link Costs in base protocol -13 In-Reply-To: <1028365c0907292133s4a32319bg1b2f2069667bfd45@mail.gmail.com> References: <1028365c0907292133s4a32319bg1b2f2069667bfd45@mail.gmail.com> Message-ID: <4A712F97.8050201@sun.com> No objection, though perhaps if there are only a few (say less than 10) different link speeds in common use, it might be useful to enumerate the default costs for each of those values. And, is it always obvious to a zero configuration Rbridge what speed each of its ports is? Radia Donald Eastlake wrote: > Hi, > > I'm thinking that something like this should be added to item 1 in > section 4.2.4.4 of the base protocol draft version -13: > > > To facilitate efficient zero configuration operation, RBridges SHOULD, > by default, set the cost of a link to one trillion (1,000,000,000,000) > diviided by the RBridge port's bit rate rounded to the nearest value > that will fit in the wide metric; for example, the cost for a > link accessed by a 1Gbps port would default to 1,000. However, the > cost MAY, by default, be increased if the link appears to be a bridged LAN. > > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From balajis at hcl.in Thu Jul 30 00:15:53 2009 From: balajis at hcl.in (Balaji Swaminathan) Date: Thu, 30 Jul 2009 12:45:53 +0530 Subject: [rbridge] ESADI question Message-ID: Hi, The ESADI information is carried in Level1 LSPs as a separate TLV. Will the ESADI information contain the MAC addresses of the non DRBs also OR is it not needed since the non-DRB information is exchanged using the other TLVs of the LSP? Thanks, Balaji. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090730/e86452c1/attachment.html From ddutt at cisco.com Thu Jul 30 08:22:29 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Thu, 30 Jul 2009 08:22:29 -0700 Subject: [rbridge] Default Link Costs in base protocol -13 In-Reply-To: <4A712F97.8050201@sun.com> References: <1028365c0907292133s4a32319bg1b2f2069667bfd45@mail.gmail.com> <4A712F97.8050201@sun.com> Message-ID: <4A71BAB5.3020108@cisco.com> Radia Perlman wrote: > No objection, though perhaps if there are only a few (say less than 10) > different link speeds in common use, > it might be useful to enumerate the default costs for each of those values. > Doesn't IS-IS specify something like this already ? If it didn't, I'd probably stay with the formula used by IEEE in computing the link cost in spanning tree protocol unless there is a strong reason to change it. Radia, it is not possible to enumerate primarily because of link aggregation because of which you can get various speeds. > And, is it always obvious to a zero configuration Rbridge what speed > each of its ports is? > Yes. Dinesh > Radia > > Donald Eastlake wrote: > >> Hi, >> >> I'm thinking that something like this should be added to item 1 in >> section 4.2.4.4 of the base protocol draft version -13: >> >> >> To facilitate efficient zero configuration operation, RBridges SHOULD, >> by default, set the cost of a link to one trillion (1,000,000,000,000) >> diviided by the RBridge port's bit rate rounded to the nearest value >> that will fit in the wide metric; for example, the cost for a >> link accessed by a 1Gbps port would default to 1,000. However, the >> cost MAY, by default, be increased if the link appears to be a bridged LAN. >> >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-634-2066 (home) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3 at gmail.com >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From mshand at cisco.com Thu Jul 30 09:22:29 2009 From: mshand at cisco.com (mike shand) Date: Thu, 30 Jul 2009 17:22:29 +0100 Subject: [rbridge] Default Link Costs in base protocol -13 In-Reply-To: <4A71BAB5.3020108@cisco.com> References: <1028365c0907292133s4a32319bg1b2f2069667bfd45@mail.gmail.com> <4A712F97.8050201@sun.com> <4A71BAB5.3020108@cisco.com> Message-ID: <4A71C8C5.3090104@cisco.com> Dinesh G Dutt wrote: > Radia Perlman wrote: > >> No objection, though perhaps if there are only a few (say less than 10) >> different link speeds in common use, >> it might be useful to enumerate the default costs for each of those values. >> >> > Doesn't IS-IS specify something like this already ? No it doesn't. > If it didn't, I'd > probably stay with the formula used by IEEE in computing the link cost > in spanning tree protocol unless there is a strong reason to change it. > That sounds reasonable Mike > Radia, it is not possible to enumerate primarily because of link > aggregation because of which you can get various speeds. > >> And, is it always obvious to a zero configuration Rbridge what speed >> each of its ports is? >> >> > Yes. > > Dinesh > >> Radia >> >> Donald Eastlake wrote: >> >> >>> Hi, >>> >>> I'm thinking that something like this should be added to item 1 in >>> section 4.2.4.4 of the base protocol draft version -13: >>> >>> >>> To facilitate efficient zero configuration operation, RBridges SHOULD, >>> by default, set the cost of a link to one trillion (1,000,000,000,000) >>> diviided by the RBridge port's bit rate rounded to the nearest value >>> that will fit in the wide metric; for example, the cost for a >>> link accessed by a 1Gbps port would default to 1,000. However, the >>> cost MAY, by default, be increased if the link appears to be a bridged LAN. >>> >>> >>> Thanks, >>> Donald >>> ============================= >>> Donald E. Eastlake 3rd +1-508-634-2066 (home) >>> 155 Beaver Street >>> Milford, MA 01757 USA >>> d3e3e3 at gmail.com >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >>> >> _______________________________________________ >> rbridge mailing list >> rbridge at postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> >> >> > > From vijayc at hcl.in Fri Jul 31 07:20:50 2009 From: vijayc at hcl.in (Vijayanand C) Date: Fri, 31 Jul 2009 19:50:50 +0530 Subject: [rbridge] separate ISIS instance for ESADI Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED0E5BB4CCD2@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> The draft-ietf-trill-rbridge-protocol states that Rbrdiges can participate in ESADI, but the means to do it for ISIS is not explicit in draft-isis-layer2. Specifically it is not clear whether the MAC-RI TLV constituting MAC reachability information should be sent in the regular Rbridge Level1 LSP as stated in the drat-isis-layer2 or ESADI frames should be part of a separate ISIS instance run specifically for that purpose as stated in draft-eastlake-trill-rbridge-isis, Regards Vijay DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090731/2b6f69e1/attachment.html From ddutt at cisco.com Fri Jul 31 08:29:59 2009 From: ddutt at cisco.com (Dinesh G Dutt) Date: Fri, 31 Jul 2009 08:29:59 -0700 Subject: [rbridge] separate ISIS instance for ESADI In-Reply-To: <66E3DDEEA70F0D469D1FFE238526B6ED0E5BB4CCD2@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <66E3DDEEA70F0D469D1FFE238526B6ED0E5BB4CCD2@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Message-ID: <4A730DF7.4050809@cisco.com> ESADI is not IS-IS. It uses the encodings of IS-IS, that's all, Dinesh Vijayanand C wrote: > The draft-ietf-trill-rbridge-protocol states that Rbrdiges can participate in ESADI, but the means to do it for ISIS is not explicit in draft-isis-layer2. Specifically it is not clear whether the MAC-RI TLV constituting MAC reachability information should be sent in the regular Rbridge Level1 LSP as stated in the drat-isis-layer2 or ESADI frames should be part of a separate ISIS instance run specifically for that purpose as stated in draft-eastlake-trill-rbridge-isis, > > Regards > Vijay > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > -- We make our world significant by the courage of our questions and by the depth of our answers. - Carl Sagan From d3e3e3 at gmail.com Fri Jul 31 08:40:13 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 31 Jul 2009 11:40:13 -0400 Subject: [rbridge] Default Link Costs in base protocol -13 In-Reply-To: <4A71C8C5.3090104@cisco.com> References: <1028365c0907292133s4a32319bg1b2f2069667bfd45@mail.gmail.com> <4A712F97.8050201@sun.com> <4A71BAB5.3020108@cisco.com> <4A71C8C5.3090104@cisco.com> Message-ID: <1028365c0907310840j40fbbe96m3473ce06276399ed@mail.gmail.com> The rule specified in IEEE 802.1D-2004 in Section 17.14 is twenty trillion (20,000,000,000,000) divided by the port speed in bits per second. The actual values given there are for the 32-bit cost field in RSTP BPDUs but for use in the 16-bit cost field of STP BPDUs, it says to just clip larger values at the maximum that will fit of 65,535. So it sounds like we should go with this formula but clipping larger values at the 16.777,214 value (2**24 - 2) that will fit into the 24-bit cost field of the extended IS-IS metric. (2**24 - 1 is a magic value in IS-IS which prohibits use of the link in SPF calculations.) This causes the cost to saturate for ports slower than about 1.2 million bps. This all sounds about right for 802.3 links, which is what we are aiming for, and is reasonably forward looking, although it would be inappropriate for wireless links, for example. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Jul 30, 2009 at 12:22 PM, mike shand wrote: > Dinesh G Dutt wrote: >> >> Radia Perlman wrote: >> >>> >>> No objection, though perhaps if there are only a few (say less than 10) >>> different link speeds in common use, >>> it might be useful to enumerate the default costs for each of those >>> values. >>> >> >> Doesn't IS-IS specify something like this already ? > > No it doesn't. >> >> ?If it didn't, I'd probably stay with the formula used by IEEE in >> computing the link cost in spanning tree protocol unless there is a strong >> reason to change it. >> > > That sounds reasonable > > ? Mike > >> Radia, it is not possible to enumerate primarily because of link >> aggregation because of which you can get various speeds. >> >>> >>> And, is it always obvious to a zero configuration Rbridge what speed each >>> of its ports is? >>> >> >> Yes. >> >> Dinesh >> >>> >>> Radia >>> >>> Donald Eastlake wrote: >>> >>>> >>>> Hi, >>>> >>>> I'm thinking that something like this should be added to item 1 in >>>> section 4.2.4.4 of the base protocol draft version -13: >>>> >>>> >>>> To facilitate efficient zero configuration operation, RBridges SHOULD, >>>> by default, set the cost of a link to one trillion (1,000,000,000,000) >>>> diviided by the RBridge port's bit rate rounded to the nearest value >>>> that will fit in the wide metric; for example, the cost for a >>>> link accessed by a 1Gbps port would default to 1,000. However, the >>>> cost MAY, by default, be increased if the link appears to be a bridged >>>> LAN. >>>> >>>> >>>> Thanks, >>>> Donald >>>> ============================= >>>> ?Donald E. Eastlake 3rd ? +1-508-634-2066 (home) >>>> ?155 Beaver Street >>>> ?Milford, MA 01757 USA >>>> ?d3e3e3 at gmail.com >>>> _______________________________________________ >>>> rbridge mailing list >>>> rbridge at postel.org >>>> http://mailman.postel.org/mailman/listinfo/rbridge >>>> >>> >>> _______________________________________________ >>> rbridge mailing list >>> rbridge at postel.org >>> http://mailman.postel.org/mailman/listinfo/rbridge >>> >>> >> >> > > From d3e3e3 at gmail.com Fri Jul 31 21:28:23 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 1 Aug 2009 00:28:23 -0400 Subject: [rbridge] ESADI question In-Reply-To: References: Message-ID: <1028365c0907312128p3fed5777i5afdb7d9bdba99be@mail.gmail.com> Hi, I don't quite understand your question. Are you talking about IS-IS DRBs or EASDI virtual link DRBs? In any case, what difference does being a DRB or non-DRB make? The EASDI LSPs distribute end stations MAC addresses, not RBridge MAC addresses. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Jul 30, 2009 at 3:15 AM, Balaji Swaminathan wrote: > Hi, > > ???? The ESADI information is carried in Level1 LSPs as a separate TLV. Will > the ESADI information contain the MAC addresses of the non DRBs also OR is > it not needed since the non-DRB information is exchanged using the other > TLVs of the LSP? > > Thanks, > Balaji.