[Isis-wg] ISIS WG Closing (work to LSR)
As I expect you have seen, the charter for the Link-State Routing (lsr) WG has been approved and the lsr WG now exists. All subscribers to the isis-wg mailing list have been subscribed to the lsr mailing list. ISIS WG drafts that are already in the RFC Editor's queue will remain as being published from the ISIS WG - but follow-up will be to the lsr mailing list. All ISIS WG drafts have been migrated to the lsr WG and appear on the data-tracker. In the LSR datatracker (on the About tab under Additional Links), there are links to both the OSPF and ISIS datatracker, so that published RFCs and individual drafts can easily be located. I would like to again thank Hannes Gredler for his years of service as ISIS WG Chair. Regards, Alia ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Hi Jeffrey, Yes, I was rushing & may have mangled the terminology in the final bit. The routing layer 8-bit field can be from the IGP Algorithm registry. Thanks for catching it & for your willingness to write this up more clearly! Regards, Aka On Feb 21, 2018 10:05 AM, "Jeffrey (Zhaohui) Zhang" wrote: > Hi Alia, > > > > Thanks for articulating it very clearly, and bring out the issue of having > a clear specification on the interaction. > > > > I need one clarification from you though – is it possible that the you > actually meant BART when you said BARM, and vice versa, in the following? > > > > -- > > With that, the BART can be exactly the IGP Algorithms registry. > > All the IGP Algorithms are available. For the 2 currently defined, the > constraints are empty. > > > > For the BARM, all the necessary constraints can be applied first. > > > > To define a code-point for BARM, the following information is necessary: > >i) Constraints > >ii) Can constraints be additive (default yes unless specified > otherwise) > >iii) What is the algorithm - or is it "empty" > > - > > > > I’ll try to work with Les on the text to specify the interaction. > > > > Jeffrey > > > > *From:* Alia Atlas [mailto:akat...@gmail.com] > *Sent:* Wednesday, February 21, 2018 9:45 AM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* IJsbrand Wijnands (iwijnand) ; > ext-arkadiy.gu...@thomsonreuters.com ; > b...@ietf.org; IJsbrand Wijnands ; isis-wg@ietf.org; Eric > Rosen > *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions > and draft-ietf-bier-ospf-extensions > > > > First, I greatly appreciate the rapid education I have gotten on why the > different aspects of this are important. > > > > Let us explore some details on the plan for an 8-bit BART and an 8-bit > BARM that are independent. Jeffrey, > > I really appreciate your bringing this option to the list. It simplifies > the option B idea of subtypes away and there > > seems to be a good amount of interest in it. > > > > My concern is that we specify adequately how the codepoints in BART and > BARM interact. > > > > One of the challenges with doing so has been, IMHO, a bit of terminology > where we are describing these as > > algorithms but in fact these are tuples consisting of a set of constraints > and a base algorithm. > > > > BART is the BIER layer's constraints (BC) and algorithm (BA). Let us > describe this as BART = (BC, BA). > > > > BARM is the Routing layer's constraints (RC) and algorithm (RA). Let us > describe this as BARM = (RC, RA). > > > > Let me give some concrete examples. > > > > Consider a case of BART=4 which is known to mean (prune non-BIER routers, > use SPF). > > BARM = 200, which is known to mean (prune links with BW <10G, use SPF) > > > > It is desirable to have an outcome that is (prune non-BIER routers and > links with BW < 10G, use SPF). > > > > This can work algorithmically because the constraints are the types that > we've seen before for RSVP-TE. > > > > What I think we need to make the independent 8-bit BART plus 8-bit BARM > work is a clear specification > > of the interaction. I think that is: > > > > Start with the topology Topology. > > 1) Apply the constraints represented by the BART BC(Topology) > > 2) Apply the constraints represented by the BARM RC(BC(Topology)) > > 3) Select the algorithm A as follows: use BA or if BA is "empty", use RA. > > Run A on RC(BC(Topology)) to get the next-hops and information for the > BIFT. > > > > Key points on the algorithm aspect are: > > a) BIER is the higher layer, so it is assumed to know better which > algorithm should be used. > > b) It is possible for BA to be "empty" (as the BARM=0 case discussed) so > that the algorithm > > falls through to whatever is RA. > > > > With that, the BART can be exactly the IGP Algorithms registry. > > All the IGP Algorithms are available. For the 2 currently defined, the > constraints are empty. > > > > For the BARM, all the necessary constraints can be applied first. > > > > To define a code-point for BARM, the following information is necessary: > >i) Constraints > >ii) Can constraints be additive (default yes unless specified > otherwise) > >iii) What is the algorithm - or is it "empty" > > > > I am bringing forth this description now because I am concerned that the > interaction be
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
First, I greatly appreciate the rapid education I have gotten on why the different aspects of this are important. Let us explore some details on the plan for an 8-bit BART and an 8-bit BARM that are independent. Jeffrey, I really appreciate your bringing this option to the list. It simplifies the option B idea of subtypes away and there seems to be a good amount of interest in it. My concern is that we specify adequately how the codepoints in BART and BARM interact. One of the challenges with doing so has been, IMHO, a bit of terminology where we are describing these as algorithms but in fact these are tuples consisting of a set of constraints and a base algorithm. BART is the BIER layer's constraints (BC) and algorithm (BA). Let us describe this as BART = (BC, BA). BARM is the Routing layer's constraints (RC) and algorithm (RA). Let us describe this as BARM = (RC, RA). Let me give some concrete examples. Consider a case of BART=4 which is known to mean (prune non-BIER routers, use SPF). BARM = 200, which is known to mean (prune links with BW <10G, use SPF) It is desirable to have an outcome that is (prune non-BIER routers and links with BW < 10G, use SPF). This can work algorithmically because the constraints are the types that we've seen before for RSVP-TE. What I think we need to make the independent 8-bit BART plus 8-bit BARM work is a clear specification of the interaction. I think that is: Start with the topology Topology. 1) Apply the constraints represented by the BART BC(Topology) 2) Apply the constraints represented by the BARM RC(BC(Topology)) 3) Select the algorithm A as follows: use BA or if BA is "empty", use RA. Run A on RC(BC(Topology)) to get the next-hops and information for the BIFT. Key points on the algorithm aspect are: a) BIER is the higher layer, so it is assumed to know better which algorithm should be used. b) It is possible for BA to be "empty" (as the BARM=0 case discussed) so that the algorithm falls through to whatever is RA. With that, the BART can be exactly the IGP Algorithms registry. All the IGP Algorithms are available. For the 2 currently defined, the constraints are empty. For the BARM, all the necessary constraints can be applied first. To define a code-point for BARM, the following information is necessary: i) Constraints ii) Can constraints be additive (default yes unless specified otherwise) iii) What is the algorithm - or is it "empty" I am bringing forth this description now because I am concerned that the interaction between BARM and BART is not adequately defined to be published - but I see the strong interest in this as the solution and, from my understanding of the problem, agree. Please comment ASAP. Jeffrey & Les, is this something that you can turn into clear text for the drafts? Regards, Alia On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang wrote: > To make it absolutely clear using an example: even with > it is still that the two fields are independent of each other. > > This particular combination means “apply BART 1” to “Flexible-Algo 200”, > where “Flexible-Algo 200” could be “exclude red links”, while “BART 1” > could be “skip BIER incapable routers”. > > > > This is a very practical and concrete example showing the advantage of > having two separate fields. Other ways could be used to achieve the same > result, but they’re more cumbersome. > > > > Jeffrey > > > > *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *IJsbrand > Wijnands (iwijnand) > *Sent:* Wednesday, February 21, 2018 8:40 AM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* b...@ietf.org; isis-wg@ietf.org; IJsbrand Wijnands ; > ext-arkadiy.gu...@thomsonreuters.com ; > Eric Rosen > *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions > and draft-ietf-bier-ospf-extensions > > > > > > > > Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours. > > > > Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0. > > > > Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP. > > > > Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and > v.s., if BART is used, BARM will just be 0. > > > > Thx, > > > > Ice. > > > > > > THx, > > > > Ice. > > > > > > Jeffrey > > > > Registry Algorithm a.k.a as BARM then ... Without this section we would be > mandating that BARM is always an IGP algorithm or FA so basically it would > mandate IGP > > > > Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the > people on the list who are of the opinion that aligning with IGP is > important. > > > > Algorithm registry as the only option to perform a calculation making BART > possibly pretty much useless ... Having a registry being mapped 1:1 into > another registry known > > > > Ice: I don't understand why you are saying this. If BARM is 0, BART is all > yours. Its unfortunate that a large part of the discussion is dominated by > perceived functionality in
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Hi Acee, Thanks for your feedback. I appreciate and agree with the perspective. Regards, Alia On Tue, Feb 20, 2018 at 1:36 PM, Acee Lindem (acee) wrote: > Hi Alia, > I support Peter's position on the draft. While I believe at 8 bit space is > more than enough to support variations of the BIER algorithm for the > foreseeable future, I think reaching consensus is more critical than the > precise encoding. > > Thanks, > Acee > > On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" < > isis-wg-boun...@ietf.org on behalf of ppse...@cisco.com> wrote: > > Hi Alia, > > 1. I see a benefit in having the BIER a way to map to any of the IGP > algorithms. Simply because IGPs already provide paths to all nodes in > the domain and BIER can simply use these paths instead of computing > its own. > > 2. Not sure if people plan to deploy the BIER in a model where it does > its own topology related computations, independent of IGPs. If they do, > I'm not objecting that. > > The encoding of the BAR though must be done in a way that it easily > supports both (1) and (2). > > my 2c, > Peter > > > > On 19/02/18 22:51 , Alia Atlas wrote: > > As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and > > draft-ietf-bier-ospf-extensions-12, I have been following the > discussion > > on the mailing list with interest. > > > > I have not seen clear consensus for any change. > > > > Let me be clear on what I see the options are from the discussion. > Then > > I'll elaborate > > a bit on how you can express your perspective most usefully. > > > > 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, > > only value 0 is specified. The drafts do not have an IANA registry - > > with the expectation that one will be created when the first > additional > > use is clear. It is possible that there will be objections from the > > IESG to progressing without an IANA registry. Given the lack of > clarity > > for future use-cases and after discussion, I decided not to force one > > after my AD review - but I will not push back against having a BIER > IANA > > registry if raised by others. > > > > 2) Option B: Add a BAR sub-type of 8 bits. This would modify the > > current TLVs. > > Define an IANA registry for the BAR type. The meaning of the BAR > > sub-type derives > > from the BAR type. We can debate over the registration policy > for > > the BAR type. > > > > 3) Option C: Change the BAR field to be 16 bits and define an IANA > > registry. Part of the range can be FCFS with Expert Review, part > can be > > Specification Required, and part can be IETF Consensus. > > > > 4) Option D: At some point in the future, if there is an actual > > understood and documented need, a BAR sub-type could be added a > > sub-TLV. The length of the BAR sub-type could be determined when the > > sub-TLV is defined. > > > > Given > > > >a) option D exists > >b) there is currently only one defined value for BAR > >c) I do not see strong consensus for change to one particular > other > > option > > > > I see no current reason for a change and I certainly see absolutely > no > > reason for > > a delay in progressing the documents. > > > > I do want to be clear about what the WG wants to do on this issue. > > Therefore, here is > > my following request. > > > > Please send your feedback to the mailing list as follows: > > > > IF you prefer or can accept the current status, please say so. No > more > > justification > > or reasoning is required. I just don't want the bulk of folks who are > > content to be > > overlooked by those suggesting change. > > > > IF you prefer or can accept the current status, but think there > should > > be an IANA registry > > as is usual for managing code-points, please say so. No more > > justification is needed. > > > > IF you prefer Option B, C, and/or D, please say so with your > > explanation. More technical depth than "'we might need it" would be > > helpful; the availability of sub-TLVs already > > provides future proofing. > > > > IF you have a clear tec
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Hi Peter, Thanks very much for the feedback. On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak wrote: > Hi Alia, > > 1. I see a benefit in having the BIER a way to map to any of the IGP > algorithms. Simply because IGPs already provide paths to all nodes in the > domain and BIER can simply use these paths instead of computing its own. > Makes sense. > 2. Not sure if people plan to deploy the BIER in a model where it does its > own topology related computations, independent of IGPs. If they do, I'm not > objecting that. > That is what I'm hearing as a requirement. The encoding of the BAR though must be done in a way that it easily > supports both (1) and (2). > There's the rub :-) The challenge seems to be when there are BIER-specific constraints and also other more generic constraints. Regards, Alia my 2c, > Peter > > > > > On 19/02/18 22:51 , Alia Atlas wrote: > >> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and >> draft-ietf-bier-ospf-extensions-12, I have been following the discussion >> on the mailing list with interest. >> >> I have not seen clear consensus for any change. >> >> Let me be clear on what I see the options are from the discussion. Then >> I'll elaborate >> a bit on how you can express your perspective most usefully. >> >> 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, >> only value 0 is specified. The drafts do not have an IANA registry - >> with the expectation that one will be created when the first additional >> use is clear. It is possible that there will be objections from the >> IESG to progressing without an IANA registry. Given the lack of clarity >> for future use-cases and after discussion, I decided not to force one >> after my AD review - but I will not push back against having a BIER IANA >> registry if raised by others. >> >> 2) Option B: Add a BAR sub-type of 8 bits. This would modify the >> current TLVs. >> Define an IANA registry for the BAR type. The meaning of the BAR >> sub-type derives >> from the BAR type. We can debate over the registration policy for >> the BAR type. >> >> 3) Option C: Change the BAR field to be 16 bits and define an IANA >> registry. Part of the range can be FCFS with Expert Review, part can be >> Specification Required, and part can be IETF Consensus. >> >> 4) Option D: At some point in the future, if there is an actual >> understood and documented need, a BAR sub-type could be added a >> sub-TLV. The length of the BAR sub-type could be determined when the >> sub-TLV is defined. >> >> Given >> >>a) option D exists >>b) there is currently only one defined value for BAR >>c) I do not see strong consensus for change to one particular other >> option >> >> I see no current reason for a change and I certainly see absolutely no >> reason for >> a delay in progressing the documents. >> >> I do want to be clear about what the WG wants to do on this issue. >> Therefore, here is >> my following request. >> >> Please send your feedback to the mailing list as follows: >> >> IF you prefer or can accept the current status, please say so. No more >> justification >> or reasoning is required. I just don't want the bulk of folks who are >> content to be >> overlooked by those suggesting change. >> >> IF you prefer or can accept the current status, but think there should >> be an IANA registry >> as is usual for managing code-points, please say so. No more >> justification is needed. >> >> IF you prefer Option B, C, and/or D, please say so with your >> explanation. More technical depth than "'we might need it" would be >> helpful; the availability of sub-TLVs already >> provides future proofing. >> >> IF you have a clear technical objection to why the Current Status is not >> acceptable, >> please express that - with clear details. >> >> IF you feel that additional code-points should be allocated in a BAR >> IANA Registry or >> have thoughts on the appropriate policy, please say so with your >> explanation for what >> those should be. >> >> Unless I see clear and strong consensus for something other than the >> Current Status, >> that will remain. >> >> IF there is clear and strong consensus for Option B, C, or D, or adding >> an IANA registry with particular values, then it will be possible to >> have a change up through this Weds night - with a 1 week WGL
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Thanks for the feedback. There is one additional aspect here that I think needs further clarification and discussion. In the current proposed charter, the first work-item says "Operation of BIER in non-congruent topologies, i.e. topologies where not all routers are BIER capable can also be addressed." The newly posted individual draft-zzhang-bier-algorithm-00 suggests having an algorithm which is doing an SPF after removing from the topology any non-BIER capable routers. This is an example of a BIER-specific constraint. The individual flex-algo drafts also support adding constraints (similar to the familiar constraints from RSVP-TE). I believe that the need for BIER-specific constraints is one factor driving the requirement for a BAR that is specified by the BIER WG. >From an architectural view, the idea of having the IGP/routing layer have to understand BIER specifics seems an undesirable coupling. Could someone walk me through how this would be supported in each of the different options? For Option D, where there is a sub-TLV and that sub-TLV can supply the additional non-BIER constraints, I understand it. For Option B - which some folks are preferring, I do not see understand how it would work. For Option A, I do not understand how it would work. Obviously, this is going far out on a design limb - where flex-algo does not yet have any IETF support or adoption, but since it is clear that people's perspectives are being strongly influenced by what that might morph into, I think this is important for the whole WG to understand. Regards, Alia On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda wrote: > all the implementations I am aware off can adjust to Option A) with BAR > registry without problems, neither do I see a problem with option B) given > we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony > > On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas wrote: > >> I have one additional question for those with implementations or testing >> them. >> >> What is the impact of going with your preferred option in terms of >> interoperability? It may be early enough that changes can happen, but more >> feedback is needed. >> >> For those favoring Option B, could you send email to the list providing >> exact text so we have the details? >> >> For those favoring the current status without an IANA registry, are you >> able to handle one being imposed during IESG Review? It is an obvious >> concern to raise. Are you just prolonging or postponing the discussion? >> >> Regards, >> Aka >> >> >> >> On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" >> wrote: >> >>> +1 to Option-B >>> >>> Seems future proof to me. >>> >>> >>> >>> Thanks, >>> >>> Senthil >>> >>> >>> >>> >>> >>> >>> >>> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Alia Atlas >>> *Sent:* 20 February 2018 03:21 >>> *To:* BIER WG ; isis-wg@ietf.org list >>> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions >>> and draft-ietf-bier-ospf-extensions >>> >>> >>> >>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and >>> draft-ietf-bier-ospf-extensions-12, I have been following the >>> discussion on the mailing list with interest. >>> >>> >>> >>> I have not seen clear consensus for any change. >>> >>> >>> >>> Let me be clear on what I see the options are from the discussion. Then >>> I'll elaborate >>> >>> a bit on how you can express your perspective most usefully. >>> >>> >>> >>> 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, >>> only value 0 is specified. The drafts do not have an IANA registry - with >>> the expectation that one will be created when the first additional use is >>> clear. It is possible that there will be objections from the IESG to >>> progressing without an IANA registry. Given the lack of clarity for future >>> use-cases and after discussion, I decided not to force one after my AD >>> review - but I will not push back against having a BIER IANA registry if >>> raised by others. >>> >>> >>> >>> 2) Option B: Add a BAR sub-type of 8 bits. This would modify the >>> current TLVs. >>> >>>Define an IANA registry for the BAR type. The meaning of the BAR >>> sub-type derives >>> >>>from the BAR type. We can debate over the reg
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
I have one additional question for those with implementations or testing them. What is the impact of going with your preferred option in terms of interoperability? It may be early enough that changes can happen, but more feedback is needed. For those favoring Option B, could you send email to the list providing exact text so we have the details? For those favoring the current status without an IANA registry, are you able to handle one being imposed during IESG Review? It is an obvious concern to raise. Are you just prolonging or postponing the discussion? Regards, Aka On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" wrote: > +1 to Option-B > > Seems future proof to me. > > > > Thanks, > > Senthil > > > > > > > > *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Alia Atlas > *Sent:* 20 February 2018 03:21 > *To:* BIER WG ; isis-wg@ietf.org list > *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions and > draft-ietf-bier-ospf-extensions > > > > As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and > draft-ietf-bier-ospf-extensions-12, I have been following the discussion > on the mailing list with interest. > > > > I have not seen clear consensus for any change. > > > > Let me be clear on what I see the options are from the discussion. Then > I'll elaborate > > a bit on how you can express your perspective most usefully. > > > > 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, only > value 0 is specified. The drafts do not have an IANA registry - with the > expectation that one will be created when the first additional use is > clear. It is possible that there will be objections from the IESG to > progressing without an IANA registry. Given the lack of clarity for future > use-cases and after discussion, I decided not to force one after my AD > review - but I will not push back against having a BIER IANA registry if > raised by others. > > > > 2) Option B: Add a BAR sub-type of 8 bits. This would modify the current > TLVs. > >Define an IANA registry for the BAR type. The meaning of the BAR > sub-type derives > >from the BAR type. We can debate over the registration policy for the > BAR type. > > > > 3) Option C: Change the BAR field to be 16 bits and define an IANA > registry. Part of the range can be FCFS with Expert Review, part can be > Specification Required, and part can be IETF Consensus. > > > > 4) Option D: At some point in the future, if there is an actual understood > and documented need, a BAR sub-type could be added a sub-TLV. The length > of the BAR sub-type could be determined when the sub-TLV is defined. > > > > Given > > > > a) option D exists > > b) there is currently only one defined value for BAR > > c) I do not see strong consensus for change to one particular other > option > > > > I see no current reason for a change and I certainly see absolutely no > reason for > > a delay in progressing the documents. > > > > I do want to be clear about what the WG wants to do on this issue. > Therefore, here is > > my following request. > > > > Please send your feedback to the mailing list as follows: > > > > IF you prefer or can accept the current status, please say so. No more > justification > > or reasoning is required. I just don't want the bulk of folks who are > content to be > > overlooked by those suggesting change. > > > > IF you prefer or can accept the current status, but think there should be > an IANA registry > > as is usual for managing code-points, please say so. No more > justification is needed. > > > > IF you prefer Option B, C, and/or D, please say so with your explanation. > More technical depth than "'we might need it" would be helpful; the > availability of sub-TLVs already > > provides future proofing. > > > > IF you have a clear technical objection to why the Current Status is not > acceptable, > > please express that - with clear details. > > > > IF you feel that additional code-points should be allocated in a BAR IANA > Registry or > > have thoughts on the appropriate policy, please say so with your > explanation for what > > those should be. > > > > Unless I see clear and strong consensus for something other than the > Current Status, > > that will remain. > > > > IF there is clear and strong consensus for Option B, C, or D, or adding an > IANA registry with particular values, then it will be possible to have a > change up through this Weds night - with a 1 week WGLC on tha
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Ice, On Mon, Feb 19, 2018 at 11:32 PM, IJsbrand Wijnands wrote: > Alia, > > I am quite disappointed in the level of discourse; the BIER-WG has > traditionally worked very > collegially with substantive technical points. > > > I don’t think its necessary to try and discredit people like this for > speaking up. > I am asking for technical reasoning; what breaks, what is facilitated, and so on. I am also evaluating whether the WG is mature enough to handle the proposed recharter - as BIER continues to make its way into the industry - or whether stricter controls are needed. Please do consider the private side conversations you have had as well. > If you ask for input from the WG, you should be honest enough to list all > the options. > If I didn't want the WG input, I would have simply said that it is done. That I have not done so is because I believe in the IETF Standards Process and it is my current responsibility to uphold that. I put options that I see as reasonable on the table - to provide flexibility. I hear you and Les speaking up but not explaining why. I have put up technical objections and concerns that should clearly articulate why I see a joint registry as a technically bad and limiting idea. I have to look at the broad picture. What Les and I say is because we think that is architecturally the right > think to do. If you don’t understand the reasoning or disagree, that is > fine. > You did not give reasoning. You did not explain how you see the complexity it introduces between WGs being handled. > Some problems take time to converge on, clearly in this case there was not > enough time, but the drafts are pushed through anyway, your call. We got > informed through a draft that there was no consensus on how to use the BAR > type 4 weeks ago. > Sometimes deadlines are needed to force conversations to happen and into the open. You knew this when my AD review recommended an IANA registry and I got pushback. > Les’s response to Andrew’s comments are spot on. Over the weekend we tried > to converge over a 16 bit BAR, and how it would look like. We where not > able to converge on the semantics, especially related to option B and > the “BAR sub-type”. Its opening an other can of worms and will cause new > discussion over the BIER architecture in the future. I know, not your > problem. > I see specific technical problems and complexity introduced by a common registry. I see other suggestions trying to merge. I am unclear on why you believe I do not care about setting up BIER for success in the future. That is precisely what I am spending too much time working on. Cough up technical reasons that persuade the WG. Explain to me exactly where I am incorrect. I have not seen technical reasons to justify an extremely late change to the WG drafts nor consensus to do so. I KEEP giving you chances and Weds night is the final deadline. Cheers, Alia > Thx, > > Ice. > > > Regards, > Alia > > On Mon, Feb 19, 2018 at 10:11 PM, Alia Atlas wrote: > Les, > > On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > I am very sympathetic to doing “as little as possible” given we are > talking about documents which are going through final reviews. > > At the same time, I think defining the authoritative source for algorithm > values is important. > > > > I therefore agree w Ice – let’s keep the current 8 bit algorithm value – > but make it clear that the identifiers come from the IGP Registry. > > > I do not hear from you or Ice a clear technical reason nor willingness to > address the concerns that I raised about the impact > on the use of BIER. > > I see no technical reasons being used to recommend combining the BIER BAR > registry and the IGP Algorithms registry. > > > Andrew – I do not think there is agreement on what the function of a “BAR > sub-type” is. Therefore I am not comfortable in adding it to the drafts. > > Certainly this may prove to be useful, but let’s add it when we know how > it will be used and how to assign values to it. That requires more > discussion than can reasonably be had in the current context. > > > > Tony / Alia – the argument that 256 algorithm values is not enough for all > use cases (BIER specific and IGP specific and Babel specific…) – or even > that 128 is not enough (if we allow the Flex-Algo proposal to reserve half > of the space) – simply does not ring true to me. > > If I waited for you to buy me a beer when we reached 10 algorithms I > likely will go thirsty for a very long time. > > > It is fascinating to see that you believe me too busy to keep up on the > side discussions happening - or perhaps merely too distracted to > recall the emails discussing acqu
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Les, Let me clarify - rereading your email again where you clearly suggest using 128 values for flex-algo. (I've been working all evening - except for ducking out for that 10 minutes to chase the kids to bed in the middle of that last email.) a) I found the need for an SR Algorithm field to be limited, given our experience with different IGP algorithms. I would also be stunned if we got to 10 different algorithms. b) Having unclear semantics because an algorithm only makes sense for BIER or only makes sense for an IGP-specific technology is not good. c) Adding the complexity to consider how and when to use an algorithm or similar new feature that makes sense for a link-state IGP - to then also consider if it can apply to BIER and if it can work in non-link-state IGPs - would only make sense if it were balanced by an equal technical benefit. These drafts were WGLCed in June - with no BAR. In October, I did not just insist on a IANA registry for the BAR in the BIER registries - because it was claimed that would let the documents progress and not force to an assumption. I regret that decision - given the poor efforts to force a registry merge. IF you and Ice truly believe that this is the technically correct thing to do, then you would make substantive technical arguments instead of this sophistry. I have given several more chances to allow this WG to discuss whether any changes are needed or are desirable. I am pushing for technical discussion. I am quite disappointed in the level of discourse; the BIER-WG has traditionally worked very collegially with substantive technical points. Regards, Alia On Mon, Feb 19, 2018 at 10:11 PM, Alia Atlas wrote: > Les, > > On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > >> I am very sympathetic to doing “as little as possible” given we are >> talking about documents which are going through final reviews. >> >> At the same time, I think defining the authoritative source for algorithm >> values is important. >> >> >> >> I therefore agree w Ice – let’s keep the current 8 bit algorithm value – >> but make it clear that the identifiers come from the IGP Registry. >> > > I do not hear from you or Ice a clear technical reason nor willingness to > address the concerns that I raised about the impact > on the use of BIER. > > I see no technical reasons being used to recommend combining the BIER BAR > registry and the IGP Algorithms registry. > > Andrew – I do not think there is agreement on what the function of a “BAR >> sub-type” is. Therefore I am not comfortable in adding it to the drafts. >> >> Certainly this may prove to be useful, but let’s add it when we know how >> it will be used and how to assign values to it. That requires more >> discussion than can reasonably be had in the current context. >> >> >> >> Tony / Alia – the argument that 256 algorithm values is not enough for >> all use cases (BIER specific and IGP specific and Babel specific…) – or >> even that 128 is not enough (if we allow the Flex-Algo proposal to reserve >> half of the space) – simply does not ring true to me. >> >> If I waited for you to buy me a beer when we reached 10 algorithms I >> likely will go thirsty for a very long time. >> > > It is fascinating to see that you believe me too busy to keep up on the > side discussions happening - or perhaps merely too distracted to > recall the emails discussing acquiring half of the IGP Algorithm space for > flex-algo. I do talk to my WG Chairs. > > Please engage substantively with technical arguments. If you have them, > you are more than capable of representing them > accurately. > > So Option E seems best to me. >> > > That was not part of my listed options. > > Regards, > Alia > > >> >>Les >> >> >> >> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Tony >> Przygienda >> *Sent:* Monday, February 19, 2018 6:20 PM >> *To:* Dolganow, Andrew (Nokia - SG/Singapore) >> *Cc:* BIER WG ; IJsbrand Wijnands ; >> isis-wg@ietf.org list >> *Subject:* Re: [Bier] [Isis-wg] BAR field length in >> draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions >> >> >> >> My reaction to AD's options: >> >> IF you prefer or can accept the current status, but think there should be >> an IANA registry >> as is usual for managing code-points, please say so. No more >> justification is needed. >> >> >> >> >> +1 to this option, i.e. current status with IANA BIER BAR registry. >> >> I think we have a clear and current case which is anchore
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
he point of > logical conclusion of a "all routing protocols under the sun algorithm > registry" and found to be a rathole I thought ... > > > > > > > On Mon, Feb 19, 2018 at 6:09 PM, Dolganow, Andrew (Nokia - SG/Singapore) < > andrew.dolga...@nokia.com> wrote: > > All, > > > > As we discussed here (as a WG) and in this topic: > >- We need to have ability to define way for independent BIER >computation algorithms (for BIER specific computations or other use cases, >some of which Alia highlighted in her email below) >- We want to have extensibility to use other non-BIER specific >algorithms (as others brought up) > > > > The original draft can be argued not to provide both of those > capabilities, and thus Option A below (marked as Current status) really > just defers the issue. I find Option E that Ice added also > counterproductive as it eliminates the top use case above. Thus we really > left with options B, C, D as a compromise. From those, Option B seems to me > the best: > >- It meets the requirements above >- It allows a clean implementation (as opposed to Option C which is a >bit more kludgy). Thanks to a sub-TLV defining what BAR field carries – a >BIER-specific algorithm defined in BIER specific registry (a registry that >should be BIER specific, regardless of IGP used), or something else to meet >needs expressed by others, we meet the requirements from those who wanted >to change the Current status > > > > Option C/D are acceptable alternatives; however, Option B seems > technically cleanest, most flexible, and meeting all requirements. > > > > Andrew > > > > > > *From: *Isis-wg on behalf of Alia Atlas < > akat...@gmail.com> > *Date: *Tuesday, February 20, 2018 at 12:05 PM > *To: *"(Ice) IJsbrand Wijnands" > *Cc: *BIER WG , "isis-wg@ietf.org list" > *Subject: *Re: [Isis-wg] [Bier] BAR field length in > draft-ietf-bier-isis-extensions > and draft-ietf-bier-ospf-extensions > > > > Ice, > > > > On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands wrote: > > Alia, > > > > I appreciate that you have finally decided to discuss this on the BIER > mailing list. > > > I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00 > and draft-hegdeppsenak-isis-sr-flex-algo-02. > I see a bit of discussion on the is-is mailing list and at IETF 100, but, > of course, no WG adoption. > > I see BIER as a fundamental technology that can be used in different > situations. For instance, there is not merely > discussion of how Babel and BIER could interact - but actual code (thanks > Sandy!); of course, that is not a WG-adopted > draft yet either, so this is merely a thought experiment example. How do > the different algorithms > work for an IGP that isn't link-state? What about the ideas around using > BIER with caches? Are there issues there? > What about algorithms that make sense for BIER or multicast - but not for > unicast? > > IANA registries are not price prohibitive. Why would we tie BIER to the > link-state IGP registry? > > > > We are talking about what needs to be advertised in OSPF and ISIS in order > to select the BIER underlay. We are not discussing Babel or any other > candidate underlay technologies for BIER. Moreover, we are not limiting any > new innovation with BIER regarding the underlay. This discussion is > strictly related to the drafts in the title. > > > > I do not hear you making a technical argument. > > > > This is an architectural argument! > > > > An architectural argument can't also limit itself to the drafts in the > title. > > > > If it sounded like the IANA registry was suggested as separate for BIER > OSPF and BIER ISIS, then your attempt to reframe the conversation might be > reasonable. Let me clarify - I see no current reason for an OSPF BAR > registry and an ISIS BAR registry; it would just be a BAR registry. Perhaps > > that clarification is a good reason to get the IANA registry included in > the next update? > > > > The routing layer is separate from the BIER layer. The BAR is for the > BIER layer. > > > > Regards, > > Alia > > > > > > Hope this clarifies, > > > > Thx, > > > > Ice. > > > > > Regards, > Alia > > > On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands wrote: > Hi Alia, > > There is one more option that I think is not fully covered from the choice > of options related to getting a registry. > > The topic of the discussion is what information we ne
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Ice, I forgot to add - of course - that I understand you have already stated that you don't have any technical objections to the current status. Regards, Alia On Mon, Feb 19, 2018 at 8:58 PM, Alia Atlas wrote: > Ice, > > At this point in the process, it would be necessary to make an > overwhelming technical argument - that would sway almost the whole > WG to your perspective. > > I see you saying that you have a personal preference for having the IGP > Algorithm registry also be used for the BAR registry. While > I do, of course, respect where you have technical expertise, my response - > particularly from a process perspective - is "that's nice". > > Regards, > Alia > > On Mon, Feb 19, 2018 at 8:15 PM, IJsbrand Wijnands wrote: > >> Alia, >> >> > An architectural argument can't also limit itself to the drafts in the >> title. >> > >> > If it sounded like the IANA registry was suggested as separate for BIER >> OSPF and BIER ISIS, then your attempt to reframe the conversation might be >> reasonable. Let me clarify - I see no current reason for an OSPF BAR >> registry and an ISIS BAR registry; it would just be a BAR registry. Perhaps >> > that clarification is a good reason to get the IANA registry included >> in the next update? >> >> There is no reason for an individual BIER OSPF and BIER ISIS registry. >> The point is to align with what ever ISIS and OSPF are using to identify >> the algorithm. >> >> > The routing layer is separate from the BIER layer. The BAR is for the >> BIER layer. >> >> The underlay is separate from the BIER layer, and each underlay can carry >> BIER specific information that is needed for for BIER to make the selection. >> >> Thx, >> >> Ice. >> >> > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Ice, At this point in the process, it would be necessary to make an overwhelming technical argument - that would sway almost the whole WG to your perspective. I see you saying that you have a personal preference for having the IGP Algorithm registry also be used for the BAR registry. While I do, of course, respect where you have technical expertise, my response - particularly from a process perspective - is "that's nice". Regards, Alia On Mon, Feb 19, 2018 at 8:15 PM, IJsbrand Wijnands wrote: > Alia, > > > An architectural argument can't also limit itself to the drafts in the > title. > > > > If it sounded like the IANA registry was suggested as separate for BIER > OSPF and BIER ISIS, then your attempt to reframe the conversation might be > reasonable. Let me clarify - I see no current reason for an OSPF BAR > registry and an ISIS BAR registry; it would just be a BAR registry. Perhaps > > that clarification is a good reason to get the IANA registry included in > the next update? > > There is no reason for an individual BIER OSPF and BIER ISIS registry. The > point is to align with what ever ISIS and OSPF are using to identify the > algorithm. > > > The routing layer is separate from the BIER layer. The BAR is for the > BIER layer. > > The underlay is separate from the BIER layer, and each underlay can carry > BIER specific information that is needed for for BIER to make the selection. > > Thx, > > Ice. > > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Ice, On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands wrote: > Alia, > > I appreciate that you have finally decided to discuss this on the BIER > mailing list. > > > I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00 > and draft-hegdeppsenak-isis-sr-flex-algo-02. > I see a bit of discussion on the is-is mailing list and at IETF 100, but, > of course, no WG adoption. > > I see BIER as a fundamental technology that can be used in different > situations. For instance, there is not merely > discussion of how Babel and BIER could interact - but actual code (thanks > Sandy!); of course, that is not a WG-adopted > draft yet either, so this is merely a thought experiment example. How do > the different algorithms > work for an IGP that isn't link-state? What about the ideas around using > BIER with caches? Are there issues there? > What about algorithms that make sense for BIER or multicast - but not for > unicast? > > IANA registries are not price prohibitive. Why would we tie BIER to the > link-state IGP registry? > > > We are talking about what needs to be advertised in OSPF and ISIS in order > to select the BIER underlay. We are not discussing Babel or any other > candidate underlay technologies for BIER. Moreover, we are not limiting any > new innovation with BIER regarding the underlay. This discussion is > strictly related to the drafts in the title. > > I do not hear you making a technical argument. > > > This is an architectural argument! > An architectural argument can't also limit itself to the drafts in the title. If it sounded like the IANA registry was suggested as separate for BIER OSPF and BIER ISIS, then your attempt to reframe the conversation might be reasonable. Let me clarify - I see no current reason for an OSPF BAR registry and an ISIS BAR registry; it would just be a BAR registry. Perhaps that clarification is a good reason to get the IANA registry included in the next update? The routing layer is separate from the BIER layer. The BAR is for the BIER layer. Regards, Alia > Hope this clarifies, > > Thx, > > Ice. > > > Regards, > Alia > > > On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands wrote: > Hi Alia, > > There is one more option that I think is not fully covered from the choice > of options related to getting a registry. > > The topic of the discussion is what information we need to pass in the IGP > in order for BIER to select the correct underlay. What identifies the > underlay is really what ever information is needed to select the Table > (MT-ID) and Algorithm. An example of Algorithm work that is going on is > Flex-Algo. My preferred option is to align with what ever the IGPs are > using to identify the Algorithm. > > Option E: Change BAR into “IGP Algorithm” registry as documented in > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp- > algorithm-types > > Thx, > > Ice. > > On 19 Feb 2018, at 13:51, Alia Atlas wrote: > > As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and > draft-ietf-bier-ospf-extensions-12, I have been following the discussion > on the mailing list with interest. > > I have not seen clear consensus for any change. > > Let me be clear on what I see the options are from the discussion. Then > I'll elaborate > a bit on how you can express your perspective most usefully. > > 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, only > value 0 is specified. The drafts do not have an IANA registry - with the > expectation that one will be created when the first additional use is > clear. It is possible that there will be objections from the IESG to > progressing without an IANA registry. Given the lack of clarity for future > use-cases and after discussion, I decided not to force one after my AD > review - but I will not push back against having a BIER IANA registry if > raised by others. > > 2) Option B: Add a BAR sub-type of 8 bits. This would modify the current > TLVs. >Define an IANA registry for the BAR type. The meaning of the BAR > sub-type derives >from the BAR type. We can debate over the registration policy for the > BAR type. > > 3) Option C: Change the BAR field to be 16 bits and define an IANA > registry. Part of the range can be FCFS with Expert Review, part can be > Specification Required, and part can be IETF Consensus. > > 4) Option D: At some point in the future, if there is an actual understood > and documented need, a BAR sub-type could be added a sub-TLV. The length > of the BAR sub-type could be determined when the sub-TLV is defined. > > Given > > a) option D exists > b) there is curr
Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Hi Ice, I appreciate that you have finally decided to discuss this on the BIER mailing list. I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00 and draft-hegdeppsenak-isis-sr-flex-algo-02. I see a bit of discussion on the is-is mailing list and at IETF 100, but, of course, no WG adoption. I see BIER as a fundamental technology that can be used in different situations. For instance, there is not merely discussion of how Babel and BIER could interact - but actual code (thanks Sandy!); of course, that is not a WG-adopted draft yet either, so this is merely a thought experiment example. How do the different algorithms work for an IGP that isn't link-state? What about the ideas around using BIER with caches? Are there issues there? What about algorithms that make sense for BIER or multicast - but not for unicast? IANA registries are not price prohibitive. Why would we tie BIER to the link-state IGP registry? I do not hear you making a technical argument. Regards, Alia On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands wrote: > Hi Alia, > > There is one more option that I think is not fully covered from the choice > of options related to getting a registry. > > The topic of the discussion is what information we need to pass in the IGP > in order for BIER to select the correct underlay. What identifies the > underlay is really what ever information is needed to select the Table > (MT-ID) and Algorithm. An example of Algorithm work that is going on is > Flex-Algo. My preferred option is to align with what ever the IGPs are > using to identify the Algorithm. > > Option E: Change BAR into “IGP Algorithm” registry as documented in > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp- > algorithm-types > > Thx, > > Ice. > > On 19 Feb 2018, at 13:51, Alia Atlas wrote: > > As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and > draft-ietf-bier-ospf-extensions-12, I have been following the > discussion on the mailing list with interest. > > I have not seen clear consensus for any change. > > Let me be clear on what I see the options are from the discussion. Then > I'll elaborate > a bit on how you can express your perspective most usefully. > > 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, only > value 0 is specified. The drafts do not have an IANA registry - with the > expectation that one will be created when the first additional use is > clear. It is possible that there will be objections from the IESG to > progressing without an IANA registry. Given the lack of clarity for future > use-cases and after discussion, I decided not to force one after my AD > review - but I will not push back against having a BIER IANA registry if > raised by others. > > 2) Option B: Add a BAR sub-type of 8 bits. This would modify the current > TLVs. >Define an IANA registry for the BAR type. The meaning of the BAR > sub-type derives >from the BAR type. We can debate over the registration policy for the > BAR type. > > 3) Option C: Change the BAR field to be 16 bits and define an IANA > registry. Part of the range can be FCFS with Expert Review, part can be > Specification Required, and part can be IETF Consensus. > > 4) Option D: At some point in the future, if there is an actual understood > and documented need, a BAR sub-type could be added a sub-TLV. The length > of the BAR sub-type could be determined when the sub-TLV is defined. > > Given > > a) option D exists > b) there is currently only one defined value for BAR > c) I do not see strong consensus for change to one particular other > option > > I see no current reason for a change and I certainly see absolutely no > reason for > a delay in progressing the documents. > > I do want to be clear about what the WG wants to do on this issue. > Therefore, here is > my following request. > > Please send your feedback to the mailing list as follows: > > IF you prefer or can accept the current status, please say so. No more > justification > or reasoning is required. I just don't want the bulk of folks who are > content to be > overlooked by those suggesting change. > > IF you prefer or can accept the current status, but think there should be > an IANA registry > as is usual for managing code-points, please say so. No more > justification is needed. > > IF you prefer Option B, C, and/or D, please say so with your explanation. > More technical depth than "'we might need it" would be helpful; the > availability of sub-TLVs already > provides future proofing. > > IF you have a clear technical objection to why the Current Status is not > acceptable, > please express that
[Isis-wg] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the mailing list with interest. I have not seen clear consensus for any change. Let me be clear on what I see the options are from the discussion. Then I'll elaborate a bit on how you can express your perspective most usefully. 1) Current Status: Bier Algorithm (BAR) field is 8 bits. Currently, only value 0 is specified. The drafts do not have an IANA registry - with the expectation that one will be created when the first additional use is clear. It is possible that there will be objections from the IESG to progressing without an IANA registry. Given the lack of clarity for future use-cases and after discussion, I decided not to force one after my AD review - but I will not push back against having a BIER IANA registry if raised by others. 2) Option B: Add a BAR sub-type of 8 bits. This would modify the current TLVs. Define an IANA registry for the BAR type. The meaning of the BAR sub-type derives from the BAR type. We can debate over the registration policy for the BAR type. 3) Option C: Change the BAR field to be 16 bits and define an IANA registry. Part of the range can be FCFS with Expert Review, part can be Specification Required, and part can be IETF Consensus. 4) Option D: At some point in the future, if there is an actual understood and documented need, a BAR sub-type could be added a sub-TLV. The length of the BAR sub-type could be determined when the sub-TLV is defined. Given a) option D exists b) there is currently only one defined value for BAR c) I do not see strong consensus for change to one particular other option I see no current reason for a change and I certainly see absolutely no reason for a delay in progressing the documents. I do want to be clear about what the WG wants to do on this issue. Therefore, here is my following request. Please send your feedback to the mailing list as follows: IF you prefer or can accept the current status, please say so. No more justification or reasoning is required. I just don't want the bulk of folks who are content to be overlooked by those suggesting change. IF you prefer or can accept the current status, but think there should be an IANA registry as is usual for managing code-points, please say so. No more justification is needed. IF you prefer Option B, C, and/or D, please say so with your explanation. More technical depth than "'we might need it" would be helpful; the availability of sub-TLVs already provides future proofing. IF you have a clear technical objection to why the Current Status is not acceptable, please express that - with clear details. IF you feel that additional code-points should be allocated in a BAR IANA Registry or have thoughts on the appropriate policy, please say so with your explanation for what those should be. Unless I see clear and strong consensus for something other than the Current Status, that will remain. IF there is clear and strong consensus for Option B, C, or D, or adding an IANA registry with particular values, then it will be possible to have a change up through this Weds night - with a 1 week WGLC on that particular technical change. My priority is to have the base BIER specifications published as Proposed Standards so that more BIER implementations and deployment can be done. I would like the WG to wrap up the core work (as expressed in the proposed recharter) so that you all can look at how to use it. Given this topic was raised last Weds and given that there are no technical objections raised to the documents as are, there isn't much time - so please just respond to this email ASAP. My deadline for a decision is 6pm EST on Weds. Regards, Alia ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
Ice, The draft is in IETF Last Call. What is your technical objection to having it go forward as it is? Regards, Alia On Fri, Feb 9, 2018 at 12:13 PM, IJsbrand Wijnands (iwijnand) wrote: > Greg, > > I think there is a confusion here, there is no consensus to remove BAR! We > want to keep it, but might change the format a little... > > Sent from my iPhone > > On 9 Feb 2018, at 17:49, Greg Shepherd wrote: > > Les, > draft-ietf-bier-isis-extensions still mentions BAR. Is this intentional? > Then consensus on the thread was to remove BAR. > > Greg > > On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd wrote: > >> Thanks Les. >> >> Any other feedback? Looks like the concerns have been addressed. Speak >> now. >> >> Cheers, >> Greg >> >> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) < >> ginsb...@cisco.com> wrote: >> >>> Greg – >>> >>> >>> >>> This thread is outdated. >>> >>> In V6 of the draft we removed the restriction to limit IS-IS BIER >>> support to area boundaries – so Toerless’s comment (and my proposed text) >>> are no longer relevant. >>> >>> >>> >>> Specifically: >>> >>> >>> >>> Section 4.1: >>> >>> >>> >>> “At present, IS-IS support for a given BIER domain/sub-domain >>> is >>> >>>limited to a single area - or to the IS-IS L2 >>> sub-domain.” >>> >>> >>> >>> The above text was removed. >>> >>> >>> >>> Section 4.2 >>> >>> >>> >>> o BIER sub-TLVs MUST NOT be included when a prefix reachability >>> >>> advertisement is leaked between levels. >>> >>> >>> >>> Was changed to >>> >>> >>> >>> o BIER sub-TLVs MUST be included when a prefix reachability >>> >>> advertisement is leaked between levels. >>> >>> >>> >>> This aligns IS-IS and OSPF drafts in this regard. >>> >>> >>> >>> Les >>> >>> >>> >>> *From:* Greg Shepherd [mailto:gjs...@gmail.com] >>> *Sent:* Thursday, February 01, 2018 2:23 AM >>> *To:* Toerless Eckert >>> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda < >>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) < >>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list < >>> isis-wg@ietf.org>; Christian Hopps >>> >>> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 >>> >>> >>> >>> Have these changes been reflected in the draft? We're in WGLC but this >>> discussion needs to come to a conclusion so we can progress. >>> >>> >>> >>> Greg >>> >>> >>> >>> On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert wrote: >>> >>> Thanks, Less, that would be lovely! >>> >>> I didn't check the OSPF draft, if its similar state, explanatory text >>> wold equally be appreciated. >>> >>> >>> On Sun, Jul 23, 2017 at 11:28:08PM +, Les Ginsberg (ginsberg) wrote: >>> > Toerless - >>> > >>> > I am thinking to add a statement in Section 4.1 - something like: >>> > >>> > "At present, IS-IS support for a given BIER domain/sub-domain is >>> limited to a single area - or to the IS-IS L2 sub-domain." >>> > >>> > If you believe this would be helpful I will spin a new version >>> (subject to review/agreement from my co-authors). >>> > >>> >Les >>> > >>> > >>> > > -Original Message- >>> > > From: Toerless Eckert [mailto:t...@cs.fau.de] >>> > > Sent: Saturday, July 22, 2017 6:34 AM >>> > > To: Les Ginsberg (ginsberg) >>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg >>> Shepherd; >>> > > b...@ietf.org; isis-wg@ietf.org list; Christian Hopps >>> > > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 >>> > > >>> > > Thanks Les >>> > > >>> > > When searching various terms in the doc to figure out what happens i >>> am not >>> > > sure why i missed this one. >>> > > >>> > > But: IMHO, RFCs can not only be the minimum number of words to get a >>> > > running implementation. It also needs to specify what this >>> implementation >>> > > intends to achieve. Otherwise its not possible to do a useful review: >>> > > The reviewer can to verify whether the spec will achieve what it >>> claims to >>> > > achieve is there no definitionn of what it claims to achieve. >>> > > >>> > > If i understand ISIS correctly, my reverse engineering of the intent >>> is: >>> > > >>> > > - BIER TLVs stay within single ISIS areas. BFIR and BFER must >>> therefore be >>> > > in the same ISIS area: There is no inter-area BIER traffic possible >>> > > with this specification. This is also true for ISIS area 0. >>> > > >>> > > - The same BIER sub-domain identifiers can be re-used >>> > > across different ISIS areas without any current impact. If these >>> BFR-IDs >>> > > are non-overlapping, then this would allow in the future to create >>> a single >>> > > cross ISIS area BIER sub-domain by leaking TLVs for such a BIER >>> sub-domain >>> > > across ISIS levels. Leakage is outside the scope of this >>> specificication. >>> > > >>> > > I actually even would like to do the following: >>> > > >>> > > - If BIER sub-domains are made to span multiple ISIS areas and >>> BFR-ids >>> > > assignemtns >>> > > are made such that all BFR-ids
Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda wrote: > Went last nits with Les, we found one issue (encaps section was wrong, > need to look @ OSPF as well) and basically tightened language in few places. > K - please get that out with the details of changes to the list. I did my AD review back in Oct and looked at the differences before issuing IETF Last Call. I look forward to reviewing the minor changes. Regards, Alia > tony > > On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd wrote: > >> Thanks Les. >> >> Any other feedback? Looks like the concerns have been addressed. Speak >> now. >> >> Cheers, >> Greg >> >> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) < >> ginsb...@cisco.com> wrote: >> >>> Greg – >>> >>> >>> >>> This thread is outdated. >>> >>> In V6 of the draft we removed the restriction to limit IS-IS BIER >>> support to area boundaries – so Toerless’s comment (and my proposed text) >>> are no longer relevant. >>> >>> >>> >>> Specifically: >>> >>> >>> >>> Section 4.1: >>> >>> >>> >>> “At present, IS-IS support for a given BIER domain/sub-domain >>> is >>> >>>limited to a single area - or to the IS-IS L2 >>> sub-domain.” >>> >>> >>> >>> The above text was removed. >>> >>> >>> >>> Section 4.2 >>> >>> >>> >>> o BIER sub-TLVs MUST NOT be included when a prefix reachability >>> >>> advertisement is leaked between levels. >>> >>> >>> >>> Was changed to >>> >>> >>> >>> o BIER sub-TLVs MUST be included when a prefix reachability >>> >>> advertisement is leaked between levels. >>> >>> >>> >>> This aligns IS-IS and OSPF drafts in this regard. >>> >>> >>> >>> Les >>> >>> >>> >>> *From:* Greg Shepherd [mailto:gjs...@gmail.com] >>> *Sent:* Thursday, February 01, 2018 2:23 AM >>> *To:* Toerless Eckert >>> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda < >>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) < >>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list < >>> isis-wg@ietf.org>; Christian Hopps >>> >>> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 >>> >>> >>> >>> Have these changes been reflected in the draft? We're in WGLC but this >>> discussion needs to come to a conclusion so we can progress. >>> >>> >>> >>> Greg >>> >>> >>> >>> On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert wrote: >>> >>> Thanks, Less, that would be lovely! >>> >>> I didn't check the OSPF draft, if its similar state, explanatory text >>> wold equally be appreciated. >>> >>> >>> On Sun, Jul 23, 2017 at 11:28:08PM +, Les Ginsberg (ginsberg) wrote: >>> > Toerless - >>> > >>> > I am thinking to add a statement in Section 4.1 - something like: >>> > >>> > "At present, IS-IS support for a given BIER domain/sub-domain is >>> limited to a single area - or to the IS-IS L2 sub-domain." >>> > >>> > If you believe this would be helpful I will spin a new version >>> (subject to review/agreement from my co-authors). >>> > >>> >Les >>> > >>> > >>> > > -Original Message- >>> > > From: Toerless Eckert [mailto:t...@cs.fau.de] >>> > > Sent: Saturday, July 22, 2017 6:34 AM >>> > > To: Les Ginsberg (ginsberg) >>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg >>> Shepherd; >>> > > b...@ietf.org; isis-wg@ietf.org list; Christian Hopps >>> > > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 >>> > > >>> > > Thanks Les >>> > > >>> > > When searching various terms in the doc to figure out what happens i >>> am not >>> > > sure why i missed this one. >>> > > >>> > > But: IMHO, RFCs can not only be the minimum number of words to get a >>> > > running implementation. It also needs to specify what this >>> implementation >>> > > intends to achieve. Otherwise its not possible to do a useful review: >>> > > The reviewer can to verify whether the spec will achieve what it >>> claims to >>> > > achieve is there no definitionn of what it claims to achieve. >>> > > >>> > > If i understand ISIS correctly, my reverse engineering of the intent >>> is: >>> > > >>> > > - BIER TLVs stay within single ISIS areas. BFIR and BFER must >>> therefore be >>> > > in the same ISIS area: There is no inter-area BIER traffic possible >>> > > with this specification. This is also true for ISIS area 0. >>> > > >>> > > - The same BIER sub-domain identifiers can be re-used >>> > > across different ISIS areas without any current impact. If these >>> BFR-IDs >>> > > are non-overlapping, then this would allow in the future to create >>> a single >>> > > cross ISIS area BIER sub-domain by leaking TLVs for such a BIER >>> sub-domain >>> > > across ISIS levels. Leakage is outside the scope of this >>> specificication. >>> > > >>> > > I actually even would like to do the following: >>> > > >>> > > - If BIER sub-domains are made to span multiple ISIS areas and >>> BFR-ids >>> > > assignemtns >>> > > are made such that all BFR-ids with the same SI are in the same >>> ISIS ara, >>> > > then it should be in the future reasonably easy to crea
Re: [Isis-wg] Link-State Routing WG charter
To finish this up, I also got a better wording suggestion from Hannes for the data-center support. The charter is on the IESG telechat this Thurs for internal review. There will still be a couple weeks for the external review before it is finally approved. Please take a look at https://datatracker.ietf.org/doc/charter-ietf-lsr/ (charter-ietf-lsr-00-06) for the current proposed charter text. That is also copied below: == The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of link-state routing interior gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. The LSR Working Group is formed by merging the isis and ospf WGs and will take on all their existing adopted work at the time of chartering. IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR-WG’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR-WG will interact with other standards bodies that have responsible for standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for example TRILL work) as needed. OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director. In addition to ongoing maintenance, the following topics are expected to be among the work-items at the time of chartering. 1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA Extendibility. 2) Extensions needed for Segment Routing and associated architectural changes 3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions 4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src-routing] 5) Improving the transport/io/flooding behavior of the protocols to better support dense meshed network topologies, such as are commonly used in data centers. The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, PCE, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs and is compatible with IS-IS and/or OSPF from functional, architectural and performance point of views. LSR-WG will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as applicable to LSR protocol operation and scale. LSR-WG should coordinate with other WGs as needed. = Regards, Alia On Thu, Jan 25, 2018 at 10:07 PM, Alia Atlas wrote: > Andrew, > > > I like that improvement. > > Thanks, > Alia > > On Thu, Jan 25, 2018 at 9:06 PM, Dolganow, Andrew (Nokia - SG/Singapore) < > andrew.dolga...@nokia.com> wrote: > >> One comment – I would add a bit of text at the end of the below-quoted >> sentence to ensure that “extensions planned to meet the needs” do not >> create stability/performance problems to IGPs. I proposed a text in red for >> that: >> >> >> >> The Link-State Routing (LSR) Working Group will coordinate with other >> working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to >> understand the need for extensions and to confirm that the planned work >> meets the needs and is compatible with both IS-IS and OSPF from >> functional, architectural and performance point of views >> >> >> >> Andrew >> >> >> >> *From: *Isis-wg on behalf of Alia Atlas < >> akat...@gmail.com> >> *Date: *Thursday, January 25, 2018 at 1:19 AM >> *To: *"isis-wg@ietf.org" , OSPF List >> *Subject: *[Isis-wg] Link-State Routing WG charter >> >> >> >> Here is the proposed charter for the LSR working group >> >> that will be created from the SPF and ISIS working groups. >> >> >> >> This is scheduled for internal review for the IESG telechat on February 8. >> >> >> >> https://datatracker.ietf.org/doc/charter-ietf-lsr/ >> >> >> >> The Link-State Routing (LSR) Working Group is chartered to document >> current protocol implementation practices and improvements, protocol usage >> scenarios, maintenance and extensions of link-state routing interior >> gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. The >> LSR Working Group is formed by merging the isis and ospf WGs and will take >> on all their existing adopted work at the time of chartering. >>
Re: [Isis-wg] Link-State Routing WG charter
Andrew, I like that improvement. Thanks, Alia On Thu, Jan 25, 2018 at 9:06 PM, Dolganow, Andrew (Nokia - SG/Singapore) < andrew.dolga...@nokia.com> wrote: > One comment – I would add a bit of text at the end of the below-quoted > sentence to ensure that “extensions planned to meet the needs” do not > create stability/performance problems to IGPs. I proposed a text in red for > that: > > > > The Link-State Routing (LSR) Working Group will coordinate with other > working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to > understand the need for extensions and to confirm that the planned work > meets the needs and is compatible with both IS-IS and OSPF from > functional, architectural and performance point of views > > > > Andrew > > > > *From: *Isis-wg on behalf of Alia Atlas < > akat...@gmail.com> > *Date: *Thursday, January 25, 2018 at 1:19 AM > *To: *"isis-wg@ietf.org" , OSPF List > *Subject: *[Isis-wg] Link-State Routing WG charter > > > > Here is the proposed charter for the LSR working group > > that will be created from the SPF and ISIS working groups. > > > > This is scheduled for internal review for the IESG telechat on February 8. > > > > https://datatracker.ietf.org/doc/charter-ietf-lsr/ > > > > The Link-State Routing (LSR) Working Group is chartered to document > current protocol implementation practices and improvements, protocol usage > scenarios, maintenance and extensions of link-state routing interior > gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. The > LSR Working Group is formed by merging the isis and ospf WGs and will take > on all their existing adopted work at the time of chartering. > > > > IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 > and additional RFC standards with extensions to support IP that has been > deployed in the Internet for decades. For the IS-IS protocol, LSR’s work > is focused on IP routing, currently based on the agreement in RFC 3563 with > ISO/JTC1/SC6. The LSR WG will interact with other standards bodies that > have responsible for standardizing IS-IS. > > > > OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the > Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for > IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. > > > > The LSR Working Group will generally manage its specific work items by > milestones agreed with the responsible Area Director. > > > > The following topics are expected to be an initial focus: > > > > 1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA > Extendibility. > > 2) Extensions needed for Segment Routing and associated architectural > changes > > 3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions > > 4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src- > routing] > > 5) Potentially, extensions to better support specific network topologies > such as > > ones commonly used in data centers. > > > > The Link-State Routing (LSR) Working Group will coordinate with other > working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to > understand the need for extensions and to confirm that the planned work > meets the needs. LSR can coordinate with CCAMP and BIER on their > extensions to the LSR IGPs as useful. LSR may coordinate with other WGs as > needed. > > > > Regards, > > Alia > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] [OSPF] Link-State Routing WG charter
On Wed, Jan 24, 2018 at 6:11 PM, Jeff Tantsura wrote: > Wouldn’t L2 reference would be a bit outdated? > There has been work from IEEE and from TRILL in the past as well as other aspects (e.g. RFC 6165, RFC 6326, RFC 6329, RFC 7176) and - particularly with TRILL closing soon - making sure that such work isn't out of scope seems useful. Regards, Alia > > > Cheers, > > Jeff > > > > *From: *OSPF on behalf of "Les Ginsberg > (ginsberg)" > *Date: *Wednesday, January 24, 2018 at 15:09 > *To: *Stewart Bryant , "Acee Lindem (acee)" < > a...@cisco.com>, Alia Atlas > *Cc: *OSPF List , "isis-wg@ietf.org" > *Subject: *Re: [OSPF] [Isis-wg] Link-State Routing WG charter > > > > It occurred to me after sending this that perhaps a better statement as > regards IS-IS would be: > > > > “LSR’s work is focused on IP/IPv6 and Layer 2 routing…” > > > > though admittedly there isn’t much going on as regards Layer2 and IS-IS at > the moment. > > > >Les > > > > > > *From:* Isis-wg [mailto:isis-wg-boun...@ietf.org] *On Behalf Of *Les > Ginsberg (ginsberg) > *Sent:* Wednesday, January 24, 2018 2:33 PM > *To:* Stewart Bryant ; Acee Lindem (acee) < > a...@cisco.com>; Alia Atlas > *Cc:* OSPF List ; isis-wg@ietf.org > *Subject:* Re: [Isis-wg] Link-State Routing WG charter > > > > Since a charter only provides a general definition of the work that falls > within the purview of the WG it requires some adjunct to keep track of the > current priorities. > > That could be the list of milestones (which OSPF has regularly maintained > – but IS-IS has not) – or it could simply be the list of active WG > documents. > > I just don’t see that we should expect the charter to express “work in > progress” now – or in the future. > > > > Alia – do you think the statement about IS-IS: > > > > “LSR’s work is focused on IP routing…” > > > > Could be improved by saying > > > > “LSR’s work is focused on IP/IPv6 routing…” > > > > ??? > > > >Les > > > > > > *From:* Isis-wg [mailto:isis-wg-boun...@ietf.org > ] *On Behalf Of *Stewart Bryant > *Sent:* Wednesday, January 24, 2018 10:01 AM > *To:* Acee Lindem (acee) ; Alia Atlas > *Cc:* OSPF List ; isis-wg@ietf.org > *Subject:* Re: [Isis-wg] Link-State Routing WG charter > > > > Yes that fixes that. > > How about: > > s/The following topics are expected to be an initial focus:/ In addition > to ongoing maintenance, the following topics are expected to be an initial > focus:/ > > I am just concerned that we need not to loose focus on work in progress. > > - Stewart > > > > On 24/01/2018 17:54, Acee Lindem (acee) wrote: > > How about: > > > > LSR will coordinate with CCAMP and BIER on their extensions to the LSR > IGPs as > > applicable to LSV protocol operation and scale. > > > > Thanks, > > Acee > > > > *From: *Isis-wg on > behalf of Alia Atlas > *Date: *Wednesday, January 24, 2018 at 12:42 PM > *To: *Stewart Bryant > *Cc: *OSPF WG List , "isis-wg@ietf.org" > > *Subject: *Re: [Isis-wg] Link-State Routing WG charter > > > > Hi Stewart, > > > > Thanks for the quick feedback. Feel free to provide suggestions for text > changes if you have them. > > You've certainly written enough charters :-) > > > > Regards, > > Alia > > > > On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant > wrote: > > Alia, > > I think that this merger is long overdue, and hopefully it will help new > features to be written in an aligned way. > > I think the remit to perform general maintenance should slightly clarified > since the way the charter is written they look like they are at a lower > priority than the enumerated list. > > I would have thought that "LSR can coordinate with CCAMP and BIER on their > extensions " should have been more directive. > > - Stewart > > > > On 24/01/2018 17:18, Alia Atlas wrote: > > Here is the proposed charter for the LSR working group > > that will be created from the SPF and ISIS working groups. > > > > This is scheduled for internal review for the IESG telechat on February 8. > > > > https://datatracker.ietf.org/doc/charter-ietf-lsr/ > > > > The Link-State Routing (LSR) Working Group is chartered to document > current protocol implementation practices and improvements, protocol usage > scenarios, maintenance and extensions of link-state routing interior > gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. Th
Re: [Isis-wg] Link-State Routing WG charter
Hi Les, Thanks for the suggestions! I've modified the paragraph about IS-IS to read: "IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR-WG’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR-WG will interact with other standards bodies that have responsible for standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for example TRILL work) as needed." and updated to "In addition to ongoing maintenance, the following topics are expected to be among the work-items at the time of chartering." to clarify that the list isn't constrictive. I didn't go for IP/IPv6 since IP should cover both IPv4 & IPv6. The updated version (with Stewart's comments addressed as well) can be found as charter-ietf-lsf-00-04 at: https://datatracker.ietf.org/doc/charter-ietf-lsr/ Regards, Alia On Wed, Jan 24, 2018 at 6:09 PM, Les Ginsberg (ginsberg) wrote: > It occurred to me after sending this that perhaps a better statement as > regards IS-IS would be: > > > > “LSR’s work is focused on IP/IPv6 and Layer 2 routing…” > > > > though admittedly there isn’t much going on as regards Layer2 and IS-IS at > the moment. > > > >Les > > > > > > *From:* Isis-wg [mailto:isis-wg-boun...@ietf.org] *On Behalf Of *Les > Ginsberg (ginsberg) > *Sent:* Wednesday, January 24, 2018 2:33 PM > *To:* Stewart Bryant ; Acee Lindem (acee) < > a...@cisco.com>; Alia Atlas > > *Cc:* OSPF List ; isis-wg@ietf.org > *Subject:* Re: [Isis-wg] Link-State Routing WG charter > > > > Since a charter only provides a general definition of the work that falls > within the purview of the WG it requires some adjunct to keep track of the > current priorities. > > That could be the list of milestones (which OSPF has regularly maintained > – but IS-IS has not) – or it could simply be the list of active WG > documents. > > I just don’t see that we should expect the charter to express “work in > progress” now – or in the future. > > > > Alia – do you think the statement about IS-IS: > > > > “LSR’s work is focused on IP routing…” > > > > Could be improved by saying > > > > “LSR’s work is focused on IP/IPv6 routing…” > > > > ??? > > > >Les > > > > > > *From:* Isis-wg [mailto:isis-wg-boun...@ietf.org > ] *On Behalf Of *Stewart Bryant > *Sent:* Wednesday, January 24, 2018 10:01 AM > *To:* Acee Lindem (acee) ; Alia Atlas > *Cc:* OSPF List ; isis-wg@ietf.org > *Subject:* Re: [Isis-wg] Link-State Routing WG charter > > > > Yes that fixes that. > > How about: > > s/The following topics are expected to be an initial focus:/ In addition > to ongoing maintenance, the following topics are expected to be an initial > focus:/ > > I am just concerned that we need not to loose focus on work in progress. > > - Stewart > > > > On 24/01/2018 17:54, Acee Lindem (acee) wrote: > > How about: > > > > LSR will coordinate with CCAMP and BIER on their extensions to the LSR > IGPs as > > applicable to LSV protocol operation and scale. > > > > Thanks, > > Acee > > > > *From: *Isis-wg on > behalf of Alia Atlas > *Date: *Wednesday, January 24, 2018 at 12:42 PM > *To: *Stewart Bryant > *Cc: *OSPF WG List , "isis-wg@ietf.org" > > *Subject: *Re: [Isis-wg] Link-State Routing WG charter > > > > Hi Stewart, > > > > Thanks for the quick feedback. Feel free to provide suggestions for text > changes if you have them. > > You've certainly written enough charters :-) > > > > Regards, > > Alia > > > > On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant > wrote: > > Alia, > > I think that this merger is long overdue, and hopefully it will help new > features to be written in an aligned way. > > I think the remit to perform general maintenance should slightly clarified > since the way the charter is written they look like they are at a lower > priority than the enumerated list. > > I would have thought that "LSR can coordinate with CCAMP and BIER on their > extensions " should have been more directive. > > - Stewart > > > > On 24/01/2018 17:18, Alia Atlas wrote: > > Here is the proposed charter for the LSR working group > > that will be created from the SPF and ISIS working groups. > > > > This is scheduled for internal review for the IESG telechat on February 8. > > > > https://datatracker
Re: [Isis-wg] Link-State Routing WG charter
Sounds good to both. Thanks, Alia On Wed, Jan 24, 2018 at 1:01 PM, Stewart Bryant wrote: > Yes that fixes that. > > How about: > > s/The following topics are expected to be an initial focus:/ In addition > to ongoing maintenance, the following topics are expected to be an initial > focus:/ > > I am just concerned that we need not to loose focus on work in progress. > > - Stewart > > On 24/01/2018 17:54, Acee Lindem (acee) wrote: > > How about: > > > > LSR will coordinate with CCAMP and BIER on their extensions to the LSR > IGPs as > > applicable to LSV protocol operation and scale. > > > > Thanks, > > Acee > > > > *From: *Isis-wg on > behalf of Alia Atlas > *Date: *Wednesday, January 24, 2018 at 12:42 PM > *To: *Stewart Bryant > *Cc: *OSPF WG List , "isis-wg@ietf.org" > > *Subject: *Re: [Isis-wg] Link-State Routing WG charter > > > > Hi Stewart, > > > > Thanks for the quick feedback. Feel free to provide suggestions for text > changes if you have them. > > You've certainly written enough charters :-) > > > > Regards, > > Alia > > > > On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant > wrote: > > Alia, > > I think that this merger is long overdue, and hopefully it will help new > features to be written in an aligned way. > > I think the remit to perform general maintenance should slightly clarified > since the way the charter is written they look like they are at a lower > priority than the enumerated list. > > I would have thought that "LSR can coordinate with CCAMP and BIER on their > extensions " should have been more directive. > > - Stewart > > > > On 24/01/2018 17:18, Alia Atlas wrote: > > Here is the proposed charter for the LSR working group > > that will be created from the SPF and ISIS working groups. > > > > This is scheduled for internal review for the IESG telechat on February 8. > > > > https://datatracker.ietf.org/doc/charter-ietf-lsr/ > > > > The Link-State Routing (LSR) Working Group is chartered to document > current protocol implementation practices and improvements, protocol usage > scenarios, maintenance and extensions of link-state routing interior > gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. The > LSR Working Group is formed by merging the isis and ospf WGs and will take > on all their existing adopted work at the time of chartering. > > > > IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 > and additional RFC standards with extensions to support IP that has been > deployed in the Internet for decades. For the IS-IS protocol, LSR’s work > is focused on IP routing, currently based on the agreement in RFC 3563 with > ISO/JTC1/SC6. The LSR WG will interact with other standards bodies that > have responsible for standardizing IS-IS. > > > > OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the > Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for > IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. > > > > The LSR Working Group will generally manage its specific work items by > milestones agreed with the responsible Area Director. > > > > The following topics are expected to be an initial focus: > > > > 1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA > Extendibility. > > 2) Extensions needed for Segment Routing and associated architectural > changes > > 3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions > > 4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src- > routing] > > 5) Potentially, extensions to better support specific network topologies > such as > > ones commonly used in data centers. > > > > The Link-State Routing (LSR) Working Group will coordinate with other > working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to > understand the need for extensions and to confirm that the planned work > meets the needs. LSR can coordinate with CCAMP and BIER on their > extensions to the LSR IGPs as useful. LSR may coordinate with other WGs as > needed. > > > > Regards, > > Alia > > > > ___ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > > > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] Link-State Routing WG charter
Hi Stewart, Thanks for the quick feedback. Feel free to provide suggestions for text changes if you have them. You've certainly written enough charters :-) Regards, Alia On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant wrote: > Alia, > I think that this merger is long overdue, and hopefully it will help new > features to be written in an aligned way. > > I think the remit to perform general maintenance should slightly clarified > since the way the charter is written they look like they are at a lower > priority than the enumerated list. > > I would have thought that "LSR can coordinate with CCAMP and BIER on their > extensions " should have been more directive. > > - Stewart > > > On 24/01/2018 17:18, Alia Atlas wrote: > > Here is the proposed charter for the LSR working group > that will be created from the SPF and ISIS working groups. > > This is scheduled for internal review for the IESG telechat on February 8. > > https://datatracker.ietf.org/doc/charter-ietf-lsr/ > > The Link-State Routing (LSR) Working Group is chartered to document > current protocol implementation practices and improvements, protocol usage > scenarios, maintenance and extensions of link-state routing interior > gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. The > LSR Working Group is formed by merging the isis and ospf WGs and will take > on all their existing adopted work at the time of chartering. > > IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 > and additional RFC standards with extensions to support IP that has been > deployed in the Internet for decades. For the IS-IS protocol, LSR’s work > is focused on IP routing, currently based on the agreement in RFC 3563 with > ISO/JTC1/SC6. The LSR WG will interact with other standards bodies that > have responsible for standardizing IS-IS. > > OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the > Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for > IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. > > The LSR Working Group will generally manage its specific work items by > milestones agreed with the responsible Area Director. > > The following topics are expected to be an initial focus: > > 1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA > Extendibility. > 2) Extensions needed for Segment Routing and associated architectural > changes > 3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions > 4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src- > routing] > 5) Potentially, extensions to better support specific network topologies > such as > ones commonly used in data centers. > > The Link-State Routing (LSR) Working Group will coordinate with other > working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to > understand the need for extensions and to confirm that the planned work > meets the needs. LSR can coordinate with CCAMP and BIER on their > extensions to the LSR IGPs as useful. LSR may coordinate with other WGs as > needed. > > Regards, > Alia > > > ___ > Isis-wg mailing > listIsis-wg@ietf.orghttps://www.ietf.org/mailman/listinfo/isis-wg > > > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
[Isis-wg] Link-State Routing WG charter
Here is the proposed charter for the LSR working group that will be created from the SPF and ISIS working groups. This is scheduled for internal review for the IESG telechat on February 8. https://datatracker.ietf.org/doc/charter-ietf-lsr/ The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of link-state routing interior gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3. The LSR Working Group is formed by merging the isis and ospf WGs and will take on all their existing adopted work at the time of chartering. IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR WG will interact with other standards bodies that have responsible for standardizing IS-IS. OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director. The following topics are expected to be an initial focus: 1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA Extendibility. 2) Extensions needed for Segment Routing and associated architectural changes 3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions 4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src-routing] 5) Potentially, extensions to better support specific network topologies such as ones commonly used in data centers. The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs. LSR can coordinate with CCAMP and BIER on their extensions to the LSR IGPs as useful. LSR may coordinate with other WGs as needed. Regards, Alia ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
[Isis-wg] early proposed charter for the Link-State Routing WG
I am working on the initial charter for the LSR WG, which will combine the OSPF and ISIS WGs. At this time, I do not see moving the fast-reroute work from RTGWG, but I am willing to hear opinions. In general, feedback on what areas should be the initial focus or specific concerns on scoping would be useful. My basic plan is for a broad charter focused on maintenance, usage scenarios, and extensions - much as OSPF and ISIS are chartered today. I would like to have this on the February 8 IESG telechat, so rapid feedback and reviews of the proposed charter when it is sent out would be appreciated. Thanks, Alia ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] TLV conflict
Hi Jeff, Thanks! I was looking at the version that Harish mentioned - and didn't verify that it was the most recent version. On Thu, Dec 14, 2017 at 2:47 PM, Jeff Tantsura wrote: > Hi, > > > 07 version of MSD draft published about 2 weeks ago states IANA > allocations: > > Following values have been allocated by IANA: > Value Description Reference > - --- - > 23 Node MSDThis document > > Value Description Reference > - --- - > 15 Link MSD This document > > Hope this clarifies > > Thanks, > Jeff > On Thu, Dec 14, 2017 at 08:11 Alia Atlas wrote: > >> Hi Les, >> >> On Thu, Dec 14, 2017 at 10:37 AM, Les Ginsberg (ginsberg) < >> ginsb...@cisco.com> wrote: >> >>> Folks – >>> >>> >>> >>> >>> >>> The conflict for SRMS Preference sub-TLV in https://tools.ietf.org/html/ >>> draft-ietf-isis-segment-routing-extensions-13#section-3.4 has already >>> been noted and has been eliminated in the new version of the IS-IS SR draft >>> which I expect to publish tomorrow. Note that although the IS-IS SR draft >>> was given early allocation of some code points, a couple more sub-TLVs have >>> been defined since then and these values have not yet been assigned by >>> IANA. SRMS preference was one of them – though at the time of the writing >>> of the version which added this the early allocation for MSD had not yet >>> happened. >>> >> >> Fine - but this is the exact issue with having "suggested" values that >> aren't allocated in drafts. >> I am really not happy with such text. I have been pushing and happy to >> approve early allocations. >> >> >>> Alia - I believe the MSD draft already is using the code points which >>> have been assigned by early allocation – so I do not know what further >>> update you believe is required in that document. >>> >>> ??? >>> >> >> In the IANA section, it should refer to the values as allocated - not >> suggested or potential. >> >> >>>Les >>> >>> >>> >>> >>> >>> *From:* Isis-wg [mailto:isis-wg-boun...@ietf.org] *On Behalf Of *Alia >>> Atlas >>> *Sent:* Thursday, December 14, 2017 7:01 AM >>> *To:* Harish R Prabhu >>> *Cc:* draft-ietf-isis-segment-routing-extensi...@ietf.org; >>> isis-wg@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org >>> *Subject:* Re: [Isis-wg] TLV conflict >>> >>> >>> >>> Hi Harish, >>> >>> >>> >>> Please take a look at >>> >>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- >>> codepoints.xhtml#isis-tlv-codepoints-242 >>> >>> where it is clear that draft-ietf-isis-segment-routing-msd has an early >>> temporary registration for type 23. >>> >>> >>> draft-ietf-isis-segment-routing-msd-02 should be updated to clearly >>> state the IANA allocations that have already happened. >>> >>> >>> >>> draft-ietf-isis-segment-routing-extensions-13 MUST be updated to >>> clearly state the IANA allocations >>> that have already happened for it (e.g. values 2 & 19) and to STOP >>> SQUATTING on already allocated >>> code-points. >>> >>> >>> >>> Thank you for bringing this to our attention! >>> >>> >>> >>> Regards, >>> >>> Alia >>> >>> >>> >>> >>> >>> On Thu, Dec 14, 2017 at 9:41 AM, Harish R Prabhu < >>> harish.r.pra...@gmail.com> wrote: >>> >>> While going through the I-Ds pertaining to SR attributes, it was found >>> that the following 2 TLVs have been assigned the same Type number >>> >>> SRMS Preference Sub-TLV : >>> https://tools.ietf.org/html/draft-ietf-isis-segment- >>> routing-extensions-13#section-3.4 >>> >>> Node MSD Advertisement : >>> https://tools.ietf.org/html/draft-ietf-isis-segment- >>> routing-msd-02#page-4 >>> >>> Both these sections talk about different sub tlvs under >>> router_capabilities TLV, but type value assigned is 23 for both. >>> >>> Request to address this. >>> >>> Thanks, >>> -- >>> Harish R Prabhu >>> Bangalore, India. >>> mailtp:harish.r.pra...@gmail.com >>> >>> ___ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> >>> >> ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] TLV conflict
Hi Les, On Thu, Dec 14, 2017 at 10:37 AM, Les Ginsberg (ginsberg) < ginsb...@cisco.com> wrote: > Folks – > > > > > > The conflict for SRMS Preference sub-TLV in https://tools.ietf.org/html/ > draft-ietf-isis-segment-routing-extensions-13#section-3.4 has already > been noted and has been eliminated in the new version of the IS-IS SR draft > which I expect to publish tomorrow. Note that although the IS-IS SR draft > was given early allocation of some code points, a couple more sub-TLVs have > been defined since then and these values have not yet been assigned by > IANA. SRMS preference was one of them – though at the time of the writing > of the version which added this the early allocation for MSD had not yet > happened. > Fine - but this is the exact issue with having "suggested" values that aren't allocated in drafts. I am really not happy with such text. I have been pushing and happy to approve early allocations. > Alia - I believe the MSD draft already is using the code points which have > been assigned by early allocation – so I do not know what further update > you believe is required in that document. > > ??? > In the IANA section, it should refer to the values as allocated - not suggested or potential. > Les > > > > > > *From:* Isis-wg [mailto:isis-wg-boun...@ietf.org] *On Behalf Of *Alia > Atlas > *Sent:* Thursday, December 14, 2017 7:01 AM > *To:* Harish R Prabhu > *Cc:* draft-ietf-isis-segment-routing-extensi...@ietf.org; > isis-wg@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org > *Subject:* Re: [Isis-wg] TLV conflict > > > > Hi Harish, > > > > Please take a look at > > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- > codepoints.xhtml#isis-tlv-codepoints-242 > > where it is clear that draft-ietf-isis-segment-routing-msd has an early > temporary registration for type 23. > > > draft-ietf-isis-segment-routing-msd-02 should be updated to clearly state > the IANA allocations that have already happened. > > > > draft-ietf-isis-segment-routing-extensions-13 MUST be updated to clearly > state the IANA allocations > that have already happened for it (e.g. values 2 & 19) and to STOP > SQUATTING on already allocated > code-points. > > > > Thank you for bringing this to our attention! > > > > Regards, > > Alia > > > > > > On Thu, Dec 14, 2017 at 9:41 AM, Harish R Prabhu < > harish.r.pra...@gmail.com> wrote: > > While going through the I-Ds pertaining to SR attributes, it was found > that the following 2 TLVs have been assigned the same Type number > > SRMS Preference Sub-TLV : > https://tools.ietf.org/html/draft-ietf-isis-segment- > routing-extensions-13#section-3.4 > > Node MSD Advertisement : > https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-02#page-4 > > Both these sections talk about different sub tlvs under > router_capabilities TLV, but type value assigned is 23 for both. > > Request to address this. > > Thanks, > -- > Harish R Prabhu > Bangalore, India. > mailtp:harish.r.pra...@gmail.com > > ___ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > > > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] TLV conflict
Hi Harish, Please take a look at https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242 where it is clear that draft-ietf-isis-segment-routing-msd has an early temporary registration for type 23. draft-ietf-isis-segment-routing-msd-02 should be updated to clearly state the IANA allocations that have already happened. draft-ietf-isis-segment-routing-extensions-13 MUST be updated to clearly state the IANA allocations that have already happened for it (e.g. values 2 & 19) and to STOP SQUATTING on already allocated code-points. Thank you for bringing this to our attention! Regards, Alia On Thu, Dec 14, 2017 at 9:41 AM, Harish R Prabhu wrote: > While going through the I-Ds pertaining to SR attributes, it was found > that the following 2 TLVs have been assigned the same Type number > > SRMS Preference Sub-TLV : > https://tools.ietf.org/html/draft-ietf-isis-segment- > routing-extensions-13#section-3.4 > > Node MSD Advertisement : > https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-02#page-4 > > Both these sections talk about different sub tlvs under > router_capabilities TLV, but type value assigned is 23 for both. > > Request to address this. > > Thanks, > -- > Harish R Prabhu > Bangalore, India. > mailtp:harish.r.pra...@gmail.com > > ___ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
Re: [Isis-wg] [Bier] early AD review of draft-ietf-bier-isis-extensions-05
Sounds good to me. Regards, Alia On Thu, Nov 30, 2017 at 12:24 PM, Greg Shepherd wrote: > I believe we are at a point of agreement for draft-ietf-bier-isis-extensions, > and should be ready for WGLC. Do we have agreement here? > > Thanks, > Greg > > On Sun, Oct 22, 2017 at 9:24 AM, Antoni Przygienda > wrote: > >> Les, thanks for the work. >> >> >> >> Alia, given some of the changes is a 7 days limited (i.e. only pertaining >> to changes introduced) WG LC appropriate? >> >> >> >> --- tony >> >> >> >> >> >> spake: >> >> >> >> Alia – >> >> >> >> A new version of the draft has been posted which addresses your comments. >> >> >> >> Sorry this was not completed as quickly as you hoped, but reviewing the >> comments/changes led to some lively discussion among the co-authors – it >> took us a while to reach consensus on the changes. >> >> >> >> Some responses inline. >> >> >> >> *From:* Alia Atlas [mailto:akat...@gmail.com] >> *Sent:* Tuesday, September 26, 2017 4:09 PM >> *To:* b...@ietf.org; isis-wg@ietf.org; draft-ietf-bier-isis-extension >> s...@ietf.org >> *Subject:* early AD review of draft-ietf-bier-isis-extensions-05 >> >> >> >> I have done an early AD review of draft-ietf-bier-isis-extensions-05 in >> preparation for receiving a request to publish it. First, I would like to >> thank the authors - Les, Tony, Sam and Jeffrey - for their work on this >> document. >> >> >> >> In my ideal timing, this draft would be updated and ready for IETF Last >> Call by Oct 5 so that it could reach the IESG telechat on Oct 26 >> with draft-ietf-bier-mpls-encapsulation and >> draft-ietf-bier-ospf-bier-extensions. >> It would be great to have 4 drafts approved for RFC publication - or even >> some RFCs! If we can't make this timeline, then it'll add at least a month >> or more. >> >> >> >> I do see a number of issues to be addressed. >> >> >> >> Major: >> >> >> >> 1) Sec 4.1: "At present, IS-IS support for a given BIER domain/sub-domain >> is >>limited to a single area - or to the IS-IS L2 sub-domain." >> >>Why is there this limitation? Having just reviewed the ospf draft, >> the detail needed to handle inter-area seems straightforward there. It'd >> be a pity to have different support in ISIS and OSPF... >> >> I didn't see anything about such a limitation in the bier-architecture or >> bier-mpls-encapsulation drafts, so I'm startled to see it here. >> >> >> >> At the very least, some explanation of why IS-IS can't handle inter-area >> and the implications for deployments is needed. >> >> >> >> In Sec 4.2, this is enforced by "BIER sub-TLVs MUST NOT be included when >> a prefix reachability >> advertisement is leaked between levels." but I don't see any >> reasoning for why the BIER sub-TLVs couldn't be included... >> >> >> >> *[Les:] We have removed the restriction.* >> >> >> >> 2) Sec 5.1: This section has concern about restricting the advertisement >> of BIER information in IS-IS for scalability - but it doesn't discuss at >> all when a router would stop advertising the BIER sub-TLVs. It feels like >> the section is hunting for a bit of a manageability or operational >> considerations section. I'm not comfortable with the interoperability >> issues posed by not indicating what triggers should cause advertisements or >> withdrawals. Receiving an advertisement from a BFER seems like a >> reasonable trigger to me, since it indicates an active receiver for the >> . >> >> >> >> *[Les:] This section has been removed.* >> >> >> >> 3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in >> draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice, >> labels only have to be assigned if they are >>going to be used. If a particular BIER domain supports BSLs 256 and >>512, but some SD, say SD 1, only uses BSL 256, then it is not >>necessary to assign labels that correspond to the combination of SD 1 >>and BSL 512." >> >> >> >> *[Les:] I believe this comment was resolved in the exchange between you >> and Tony.* >> >> >> >> 4) Sec 5.6: "A valid BFR-id MUST be unique within the floodin
Re: [Isis-wg] early AD review of draft-ietf-bier-isis-extensions-05
Hi Tony, On Tue, Sep 26, 2017 at 11:10 PM, Antoni Przygienda wrote: > > > 2) Sec 5.1: This section has concern about restricting the advertisement > of BIER information in IS-IS for scalability - but it doesn't discuss at > all when a router would stop advertising the BIER sub-TLVs. It feels like > the section is hunting for a bit of a manageability or operational > considerations section. I'm not comfortable with the interoperability > issues posed by not indicating what triggers should cause advertisements or > withdrawals. Receiving an advertisement from a BFER seems like a > reasonable trigger to me, since it indicates an active receiver for the > . > > > > Have to disagree to large extent: > > a) Section is basically saying “it’s outside the scope of this doc > but here’s a couple of hints”. We should probably say “those are all _ > *optional*_ extensions”. We may be better off moving it into “operational > considerations” section, that’s true. > > b) Suggested trigger is possible one but smarter ones are possible, > e.g. a node may know it’s not on any BIER computed tree (SPF or other) and > save memory by not advertising. All that are implementation techniques and > the draft is kind of overspecifying here a bit. > > c) I don’t see how any _*valid*_ trigger will cause interoperability > problems with other possible triggers. > > > > In summary, let’s say “it’s all optional” and generate an “operational > considerations” section with this text? > Sure - that's fine. > 3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in > draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice, > labels only have to be assigned if they are >going to be used. If a particular BIER domain supports BSLs 256 and >512, but some SD, say SD 1, only uses BSL 256, then it is not >necessary to assign labels that correspond to the combination of SD 1 >and BSL 512." > > > > > > Actually, I don’t think so. The encaps draft talks about BIER _*domain*_ > doing 256+512 while _*sub*_domain_1 does only 256. The ISIS draft talks > about the _*sub*_domain, i.e. in a subdomain everyone must advertise > enough labels for BSLs they support while in a _*domain*_ each _ > *subdomain*_ may do different things. Observe that we have the future > capability of converting BSLs in a subdomain and it may come handy later > (we can send smaller BMLs if we see lots zeroes or bunch things up together > if we see really small BSLs flying or support BSL migration in a > subdomain). For now we don’t have conversion and with that we may blackhole > if people disagree on the BSLs they support in a subdomain. > Ok - I see the contradiction between the drafts. If ISIS and OSPFv2 both implement it as needing to allocate all the labels, then it's not a tragedy. It would be nice to clean up the wording in Sec 2.1.1.1 of draft-ietf-mpls-encapsulation-08 to clarify that this is just a potential optimization (or simply remove it). > 4) Sec 5.6: "A valid BFR-id MUST be unique within the flooding scope of > the BIER advertisments." This doesn't leave scope for expanding to > inter-area in the future because the issue is not the flooding scope but > rather the distribution. > > > > ? within the scope the BFR-ids must be unique per BFER says it all. I > think that’s consistent with any scope, inter-, intra- or planetary reach … > ;-) > > Ah - sure BFR-ids unique per BFER is fine of course. The flooding scope is less than that. > 5) Sec 6.1: " The sub-TLV advertises a single combination followed > by >optional sub-sub-TLVs as described in the following sections." > > The figure and field descriptions do not include the MT-ID. There is > clearly the reserved octet intended for that?? > > > > Nope. ISIS MT is built very, very cleanly in this respect, i.e. the TLVs > are all already annotated and provide the MT scope. Hence it doesn’t show > up anywhere here. Did I say ISIS is very, very clean when it comes to MT ;-) > Now you see how long it's been since I looked at MT for IS-IS! Thanks for the correction. > 6) Sec 6.2: This section needs to clearly define the relationship > between the labels and the Set Index in the specified . It's also > unclear whether it is better to advertise all the labels ever needed or be > able to advertise only labels for a particular sequential number of SIs. > The restriction that only one sub-sub-TLV with the same BitStringLength > makes that impossible (but so does the lack of explicit starting SI). > > > > That goes far back. We agreed to use a set-0-based range covering all > BFR-ids. IGP TLVs are scarce resource and it makes for a much simpler > processing on computation. Labels are not _*that*_ scarce given how many > routers we cover by each label. I don’t think we’ll move that. > Ok as far as advertising all labels - but please add text defining the relationship between labels and Set Index. 7) Sec 6.3: The values for the Length & Tree Type fi
[Isis-wg] early AD review of draft-ietf-bier-isis-extensions-05
I have done an early AD review of draft-ietf-bier-isis-extensions-05 in preparation for receiving a request to publish it. First, I would like to thank the authors - Les, Tony, Sam and Jeffrey - for their work on this document. In my ideal timing, this draft would be updated and ready for IETF Last Call by Oct 5 so that it could reach the IESG telechat on Oct 26 with draft-ietf-bier-mpls-encapsulation and draft-ietf-bier-ospf-bier-extensions. It would be great to have 4 drafts approved for RFC publication - or even some RFCs! If we can't make this timeline, then it'll add at least a month or more. I do see a number of issues to be addressed. Major: 1) Sec 4.1: "At present, IS-IS support for a given BIER domain/sub-domain is limited to a single area - or to the IS-IS L2 sub-domain." Why is there this limitation? Having just reviewed the ospf draft, the detail needed to handle inter-area seems straightforward there. It'd be a pity to have different support in ISIS and OSPF... I didn't see anything about such a limitation in the bier-architecture or bier-mpls-encapsulation drafts, so I'm startled to see it here. At the very least, some explanation of why IS-IS can't handle inter-area and the implications for deployments is needed. In Sec 4.2, this is enforced by "BIER sub-TLVs MUST NOT be included when a prefix reachability advertisement is leaked between levels." but I don't see any reasoning for why the BIER sub-TLVs couldn't be included... 2) Sec 5.1: This section has concern about restricting the advertisement of BIER information in IS-IS for scalability - but it doesn't discuss at all when a router would stop advertising the BIER sub-TLVs. It feels like the section is hunting for a bit of a manageability or operational considerations section. I'm not comfortable with the interoperability issues posed by not indicating what triggers should cause advertisements or withdrawals. Receiving an advertisement from a BFER seems like a reasonable trigger to me, since it indicates an active receiver for the . 3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice, labels only have to be assigned if they are going to be used. If a particular BIER domain supports BSLs 256 and 512, but some SD, say SD 1, only uses BSL 256, then it is not necessary to assign labels that correspond to the combination of SD 1 and BSL 512." 4) Sec 5.6: "A valid BFR-id MUST be unique within the flooding scope of the BIER advertisments." This doesn't leave scope for expanding to inter-area in the future because the issue is not the flooding scope but rather the distribution. 5) Sec 6.1: " The sub-TLV advertises a single combination followed by optional sub-sub-TLVs as described in the following sections." The figure and field descriptions do not include the MT-ID. There is clearly the reserved octet intended for that?? 6) Sec 6.2: This section needs to clearly define the relationship between the labels and the Set Index in the specified . It's also unclear whether it is better to advertise all the labels ever needed or be able to advertise only labels for a particular sequential number of SIs. The restriction that only one sub-sub-TLV with the same BitStringLength makes that impossible (but so does the lack of explicit starting SI). 7) Sec 6.3: The values for the Length & Tree Type field need to be clearer after the figure. Also, is Tree Type an IANA-managed field?? I don't see it in the IANA considerations. Ca it be different between IS-IS and OSPF? Minor: a) Sec 2: "Invalid BFR-id: Unassigned BFR-id, consisting of all 0s." A clearer definition might be "Invalid BFR-ID: The special value of 0 - used to indicate that there is not a valid BFR-ID" The same comment applies to "Invalid BMP". b) Sec 5.7: Please add some text about dampening the reports of misconfiguration - as usual. Nits: i) Sec 5.1: "supported bitstring lengths MLs " All the other BIER drafts use the acronym BSL (BitStringLength). Consistency is frequently useful for clarity. ii) Sec 6.2: "Length: 1 octet." Please specify the value! Regards, Alia ___ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
