Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
Les: Hi! Just to close this loop: I looked at -12 and we’re good. :-) I’ll now wait for draft-ietf-ospf-te-link-attr-reuse to catch up to process both documents together. Thanks!! Alvaro. On March 21, 2020 at 1:09:56 PM, Les Ginsberg (ginsberg) (ginsb...@cisco.com) wrote: Following some offline discussion with you, V12 of the draft has been posted to address your additional comments. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
Alvaro - Following some offline discussion with you, V12 of the draft has been posted to address your additional comments. Some responses inline. Look for "Les3". > -Original Message- > From: Alvaro Retana > Sent: Thursday, March 05, 2020 8:54 AM > To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) > ; draft-ietf-isis-te-...@ietf.org > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: RE: AD Review of draft-ietf-isis-te-app-09 > > On February 27, 2020 at 11:00:19 PM, Les Ginsberg wrote: > > > Les: > > Hi! How are you? > > > Some of the responses, yours and mine, feel like we're not > communicating well, like we are talking past each other. I am > probably not clearly asking the right questions... I think it would > be a good idea to talk live. Let me know a time that works for you > and we can set up a short call. Maybe the Shepherd can help us sort > through things. > > Nonetheless, I responded to some of your comments. > > > Thanks! > > Alvaro. > > > ... > > > > > 177 3. Legacy Advertisements > > > ... > > > > > [minor] Please add references to where all the values in this section > > > > > are defined...if the same as the references above. > > > > > > > > > [Les:] Done. > > > > > > Sorry, I meant the RFCs where the sub-TLVs are defined, not the > registries. > > > > [Les:] Well, the IANA registry identifies the Reference RFCs - and has the > > advantage that it gets updated should that ever change. So I would suggest > > providing a link to the registry is actually better than identifying the RFC > > for each code point. :-) > > ?? > > [nit] I disagree because the RFC gives you the detail not just the > value, which is what you originally get from the registry. > Sure...it's just an indirection. > [Les3:] I have decided to leave the reference to the registry. > > > ... > > > > > [major] In a mixed network, where some routers support this > > > > > specification, but other don't, it seems that setting the L-flag would > > > > > be useful as all applications would "fall back" to the legacy > > > > > advertisements. However, not setting the L-flag seems to have the > > > > > potential for the routers to use different information resulting in > > > > > (at best) inconsistent decisions if the values are not the same. > > > > > > > > > [Les:] The revised Deployment considerations section now addresses > this. > > > > > > [nit] In the new §6.3.3 (Interoperability with Legacy Routers) it > > > might be good to mention the setting of the L-flag. For example, > > > extend Step 1, "Receiving routers continue to use legacy > > > advertisements" to include a mention of the L-flag being set. > > > > > [Les:] This isn't a nit - it is a misunderstanding. > > We aren't using L-bit here at all. > > We are accommodating the coexistence of legacy/non-legacy routers. > > > > Legacy routers only send/receive legacy advertisements. They don't > understand > > the new advertisements - let alone the L-bit. > > > > To migrate to all new routers - at which point legacy advertisements can be > > deprecated - you must follow the three steps described. The transition > > between steps is controlled by some implementation specific knob. > > > > Please reread and let me know if it is clear. > > > What I think I missed (even in the initial review) is this text (now > in §6.1 - Use of Legacy Advertisements) which talks about the knob you > mention: > > Under the conditions defined above, implementations which support the > extensions defined in this document have the choice of using legacy > advertisements or application specific advertisements in support of > SRTE and/or LFA. This will require implementations to provide > controls specifying which type of advertisements are to be sent/ > processed on receive for these applications. Further discussion of > the associated issues can be found in Section 6.3. > > > The steps in §6.3.3 are: > > 1)Send application specific advertisements while continuing to > advertise using legacy (all advertisements are then duplicated). > Receiving routers continue to use legacy advertisements. > > 2)Enable the use of the application specific advertisements on all > routers > > 3)Remove legacy advertisements > > > I agree that this transition can be achieved with a knob. But it can > also be achieved if the L-flag is set (during steps 1 and 2), right? > Sure, the legacy routers won't know what the L-flag is, but the new > ones will -- and will then use the legacy advertisements. > > The difference that I see is that the L-flag affects *all* the > applications in the bit mask while the knob may be more specific. It > would be very nice if some text was added about this to avoid more > people misunderstanding. > [Les3:] The use of the L-flag is of no value in this case. Since legacy routers will never send the ASLA sub-TLV (w or w/o the L-flag), new routers have to have a knob which says "only process legacy
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
On February 27, 2020 at 11:00:19 PM, Les Ginsberg wrote: Les: Hi! How are you? Some of the responses, yours and mine, feel like we're not communicating well, like we are talking past each other. I am probably not clearly asking the right questions... I think it would be a good idea to talk live. Let me know a time that works for you and we can set up a short call. Maybe the Shepherd can help us sort through things. Nonetheless, I responded to some of your comments. Thanks! Alvaro. ... > > > > 177 3. Legacy Advertisements > > ... > > > > [minor] Please add references to where all the values in this section > > > > are defined...if the same as the references above. > > > > > > > [Les:] Done. > > > > Sorry, I meant the RFCs where the sub-TLVs are defined, not the registries. > > [Les:] Well, the IANA registry identifies the Reference RFCs - and has the > advantage that it gets updated should that ever change. So I would suggest > providing a link to the registry is actually better than identifying the RFC > for each code point. :-) > ?? [nit] I disagree because the RFC gives you the detail not just the value, which is what you originally get from the registry. Sure...it's just an indirection. ... > > > > [major] In a mixed network, where some routers support this > > > > specification, but other don't, it seems that setting the L-flag would > > > > be useful as all applications would "fall back" to the legacy > > > > advertisements. However, not setting the L-flag seems to have the > > > > potential for the routers to use different information resulting in > > > > (at best) inconsistent decisions if the values are not the same. > > > > > > > [Les:] The revised Deployment considerations section now addresses this. > > > > [nit] In the new §6.3.3 (Interoperability with Legacy Routers) it > > might be good to mention the setting of the L-flag. For example, > > extend Step 1, "Receiving routers continue to use legacy > > advertisements" to include a mention of the L-flag being set. > > > [Les:] This isn't a nit - it is a misunderstanding. > We aren't using L-bit here at all. > We are accommodating the coexistence of legacy/non-legacy routers. > > Legacy routers only send/receive legacy advertisements. They don't understand > the new advertisements - let alone the L-bit. > > To migrate to all new routers - at which point legacy advertisements can be > deprecated - you must follow the three steps described. The transition > between steps is controlled by some implementation specific knob. > > Please reread and let me know if it is clear. What I think I missed (even in the initial review) is this text (now in §6.1 - Use of Legacy Advertisements) which talks about the knob you mention: Under the conditions defined above, implementations which support the extensions defined in this document have the choice of using legacy advertisements or application specific advertisements in support of SRTE and/or LFA. This will require implementations to provide controls specifying which type of advertisements are to be sent/ processed on receive for these applications. Further discussion of the associated issues can be found in Section 6.3. The steps in §6.3.3 are: 1)Send application specific advertisements while continuing to advertise using legacy (all advertisements are then duplicated). Receiving routers continue to use legacy advertisements. 2)Enable the use of the application specific advertisements on all routers 3)Remove legacy advertisements I agree that this transition can be achieved with a knob. But it can also be achieved if the L-flag is set (during steps 1 and 2), right? Sure, the legacy routers won't know what the L-flag is, but the new ones will -- and will then use the legacy advertisements. The difference that I see is that the L-flag affects *all* the applications in the bit mask while the knob may be more specific. It would be very nice if some text was added about this to avoid more people misunderstanding. ... > > > > [major] "Undefined bits MUST be transmitted as 0 and MUST be ignored > > > > on receipt." What if the sender and the receiver support a different > > > > set of applications? For example, suppose that the sender supports a > > > > new application identified by the N-bit, and sets only that bit; the > > > > receiver treats the N-bit as undefined and ignores it. The result is > > > > that, for the receiver, there seems to be no indication of an > > > > application. Is "no application" a valid indication, or should at > > > > least one bit always be set? > > > > > > > [Les:] Just like unknown TLVs, unknown bits MUST be ignored. > > > I have added text. > > > > Yes, that is ok. > > > > [major] But you didn't answer my question: Is "no application" a valid > > indication, or should at least one bit always be set? I guess that > > the receiver wouldn't see anything it understands... Would this be > > equivalent to
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
Alvaro - Thanx for the continued review. V11 of the draft has been posted to address your additional comments. More inline. > -Original Message- > From: Alvaro Retana > Sent: Tuesday, February 25, 2020 4:42 AM > To: Les Ginsberg (ginsberg) ; draft-ietf-isis-te- > a...@ietf.org > Cc: Acee Lindem (acee) ; lsr@ietf.org; lsr-cha...@ietf.org > Subject: RE: AD Review of draft-ietf-isis-te-app-09 > > On February 7, 2020 at 1:50:58 AM, Les Ginsberg wrote: > > Les: > > Hi! > > > We have published V10 of the draft addressing your comments. > > It looks like your copy of my review was truncated (not sure why). > The archive has the complete version, and I pasted the remaining > comments at the end of this message. > > https://mailarchive.ietf.org/arch/msg/lsr/Q39ilCqsDo0WIhayZ57RTqHEHCQ/ > > > > Note that the authors of the IS-IS and OSPF drafts are "synchronizing" as > > there is a lot of similarity in your comments regarding the two drafts. We > > have decided to close all issues with you for the IS-IS draft first - then > > hopefully the equivalent changes can be made for the OSPF draft can be > made > > and resolved more quickly. > > Makes sense! > > > > Detailed responses inline. > > I have some responses myself; most of them not-major. I've indicated > the ones that I consider major -- it would be ideal if others in the > WG chimed in with any opinions. > > > Thanks! > > Alvaro. > > > ... > > > (B) I was able to identify one significant functional difference which > > > warrants a discussion of the reason for it and maybe the pros/cons: > > > > > > §4.1 talks about the behavior when "both SABM Length and UDABM > Length > > > are zero". This document makes the use of the attributes optional while > the > > > OSPF draft mandates their use (§3). > > > > > [Les:] Both drafts use the word "MAY" in the respective sections entitled > > "Use of Zero Length Application Identifier Bit Masks". > > > > "MAY" - or perhaps "may" - makes sense to me because in the absence of > SABM > > bits there is no way to know if a given application will have any reason to > > use the attributes advertised. The text is intended to say use by any > > application is "permitted". I have changed the text in this way. > > I'm fine with the changes you made. > > This is the text from the OSPF draft that I was referring to: > > When neither the Standard Application Bits nor the User Defined > Application bits are set (i.e., both SABM Length and UDABM Length are > 0) in the ASLA sub-TLV, then the link attributes included in it MUST > be considered as being applicable to all applications. > > From your explanation, I see the intent, but the use of "MUST" gives > the impression that there's no choice. > [Les:] The OSPF text will be changed to be consistent with what is in the IS-IS draft. > > > ... > > > 177 3. Legacy Advertisements > ... > > > [minor] Please add references to where all the values in this section > > > are defined...if the same as the references above. > > > > > [Les:] Done. > > Sorry, I meant the RFCs where the sub-TLVs are defined, not the registries. [Les:] Well, the IANA registry identifies the Reference RFCs - and has the advantage that it gets updated should that ever change. So I would suggest providing a link to the registry is actually better than identifying the RFC for each code point. :-) ?? > > > > ... > > > 231 4.1. Application Identifier Bit Mask > > > > > > 233 Identification of the set of applications associated with link > > > 234 attribute advertisements utilizes two bit masks. One bit mask is for > > > 235 standard applications where the definition of each bit is defined in > > > 236 a new IANA controlled registry. A second bit mask is for non- > > > 237 standard User Defined Applications(UDAs). > ... > > > [minor] "second bit mask is for non-standard User Defined > > > Applications" The explicit point is made here that the UDAs are used > > > for *non-standard* applications. Given that these bits are for *user > > > defined* applications, the user can make the bits mean anything they > > > want (including SRTE, LFA, etc.), right? If so, then highlighting > > > *non-standard* seems not to be needed. s/for non-standard User > > > Defined Applications/for User Defined Applications > > > > > [Les:] In theory it is possible for a User Defined Application to perform > > the > > same functions as a standard application (such as SRTE). However, if it did > > so it would not be "Standard SRTE" and the bit could NOT be considered as > the > > same as "standard SRTE". > > I didn't mean just the same function, but the same application. Let > me try again. > > Can an operator do the following: define a bit (call it X) in the > UDABM to mean SRTE (*the* SRTE)? IOW, for the routers operating in > the network (which all would be aware of the X-bit), when the X-bit is > set it indicates that SRTE will use the information. This operation > would result in
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
On February 7, 2020 at 1:50:58 AM, Les Ginsberg wrote: Les: Hi! > We have published V10 of the draft addressing your comments. It looks like your copy of my review was truncated (not sure why). The archive has the complete version, and I pasted the remaining comments at the end of this message. https://mailarchive.ietf.org/arch/msg/lsr/Q39ilCqsDo0WIhayZ57RTqHEHCQ/ > Note that the authors of the IS-IS and OSPF drafts are "synchronizing" as > there is a lot of similarity in your comments regarding the two drafts. We > have decided to close all issues with you for the IS-IS draft first - then > hopefully the equivalent changes can be made for the OSPF draft can be made > and resolved more quickly. Makes sense! > Detailed responses inline. I have some responses myself; most of them not-major. I've indicated the ones that I consider major -- it would be ideal if others in the WG chimed in with any opinions. Thanks! Alvaro. ... > > (B) I was able to identify one significant functional difference which > > warrants a discussion of the reason for it and maybe the pros/cons: > > > > §4.1 talks about the behavior when "both SABM Length and UDABM Length > > are zero". This document makes the use of the attributes optional while the > > OSPF draft mandates their use (§3). > > > [Les:] Both drafts use the word "MAY" in the respective sections entitled > "Use of Zero Length Application Identifier Bit Masks". > > "MAY" - or perhaps "may" - makes sense to me because in the absence of SABM > bits there is no way to know if a given application will have any reason to > use the attributes advertised. The text is intended to say use by any > application is "permitted". I have changed the text in this way. I'm fine with the changes you made. This is the text from the OSPF draft that I was referring to: When neither the Standard Application Bits nor the User Defined Application bits are set (i.e., both SABM Length and UDABM Length are 0) in the ASLA sub-TLV, then the link attributes included in it MUST be considered as being applicable to all applications. >From your explanation, I see the intent, but the use of "MUST" gives the impression that there's no choice. ... > > 177 3. Legacy Advertisements ... > > [minor] Please add references to where all the values in this section > > are defined...if the same as the references above. > > > [Les:] Done. Sorry, I meant the RFCs where the sub-TLVs are defined, not the registries. ... > > 231 4.1. Application Identifier Bit Mask > > > > 233 Identification of the set of applications associated with link > > 234 attribute advertisements utilizes two bit masks. One bit mask is for > > 235 standard applications where the definition of each bit is defined in > > 236 a new IANA controlled registry. A second bit mask is for non- > > 237 standard User Defined Applications(UDAs). ... > > [minor] "second bit mask is for non-standard User Defined > > Applications" The explicit point is made here that the UDAs are used > > for *non-standard* applications. Given that these bits are for *user > > defined* applications, the user can make the bits mean anything they > > want (including SRTE, LFA, etc.), right? If so, then highlighting > > *non-standard* seems not to be needed. s/for non-standard User > > Defined Applications/for User Defined Applications > > > [Les:] In theory it is possible for a User Defined Application to perform the > same functions as a standard application (such as SRTE). However, if it did > so it would not be "Standard SRTE" and the bit could NOT be considered as the > same as "standard SRTE". I didn't mean just the same function, but the same application. Let me try again. Can an operator do the following: define a bit (call it X) in the UDABM to mean SRTE (*the* SRTE)? IOW, for the routers operating in the network (which all would be aware of the X-bit), when the X-bit is set it indicates that SRTE will use the information. This operation would result in exactly the same thing as if the S-bit was set. Why would anyone want to do this? For security reasons (for example): by not using the defined bit, anyone eavesdropping on the LSPs would not know which application is enabled. In any case, this is just a nit/minor comment... ... > > [major] In a mixed network, where some routers support this > > specification, but other don't, it seems that setting the L-flag would > > be useful as all applications would "fall back" to the legacy > > advertisements. However, not setting the L-flag seems to have the > > potential for the routers to use different information resulting in > > (at best) inconsistent decisions if the values are not the same. > > > [Les:] The revised Deployment considerations section now addresses this. [nit] In the new §6.3.3 (Interoperability with Legacy Routers) it might be good to mention the setting of the L-flag. For example, extend Step 1, "Receiving routers continue to use legacy advertisements" to
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
Alvaro - Thanx for your patience. We have published V10 of the draft addressing your comments. Note that the authors of the IS-IS and OSPF drafts are "synchronizing" as there is a lot of similarity in your comments regarding the two drafts. We have decided to close all issues with you for the IS-IS draft first - then hopefully the equivalent changes can be made for the OSPF draft can be made and resolved more quickly. Detailed responses inline. > -Original Message- > From: Alvaro Retana > Sent: Thursday, January 09, 2020 9:17 AM > To: draft-ietf-isis-te-...@ietf.org > Cc: Acee Lindem (acee) ; lsr-cha...@ietf.org; lsr@ietf.org > Subject: AD Review of draft-ietf-isis-te-app-09 > > Dear Authors: > > Happy New Year! > > I have finished reading this document, reviewing the e-mail archive > and all the various reviews and comments. Quoting one of the authors, > "it is essential that the two IGPs provide equivalent functionality" > [1] -- so I have considered draft-ietf-ospf-te-link-attr-reuse-10 in > parallel with this one (I'm sending out a separate yet very similar > review for it). > > In general, I think both drafts need some work. When appropriate, I > have used "[c]" to highlight comparisons. I tried to put equivalent > comments in both documents, but may have missed a few... > > I have some significant concerns (see details inline) about this > document -- and as a result about the OSPF draft. I want to point out > a couple of them here: > > (A) Deployment Considerations > > This document contains what I would characterize as a "distributed" > Deployment Considerations section through §5, §6 and §7. There is a > lot of content, but I still made some comments in-line about other > important information. Please consider consolidating all the > deployment-related information in one place. rfc5706 (specially §2) > may be useful, please take a look. > > [Les:] This comment covers three sections: 5. Deployment Considerations 6. Attribute Advertisements and Enablement 7. Interoperability, Backwards Compatibility and Migration Concerns Of these I think 5 and 7 have been combined and fall under the heading of "Deployment Considerations". Section 6 is discussing a particular aspect of the protocol extensions - what the advertisement of link attributes associated with a particular applications says about the state of that application on that link. This isn't a deployment consideration and has been retained as a separate section. > (B) I was able to identify one significant functional difference which > warrants a discussion of the reason for it and maybe the pros/cons: > > §4.1 talks about the behavior when "both SABM Length and UDABM Length > are > zero". This document makes the use of the attributes optional while the > OSPF draft mandates their use (§3). > [Les:] Both drafts use the word "MAY" in the respective sections entitled "Use of Zero Length Application Identifier Bit Masks". "MAY" - or perhaps "may" - makes sense to me because in the absence of SABM bits there is no way to know if a given application will have any reason to use the attributes advertised. The text is intended to say use by any application is "permitted". I have changed the text in this way. > > I will wait for this review to be addressed before moving both > documents forward together. > > Thanks! > > Alvaro. > > [1] > https://mailarchive.ietf.org/arch/msg/ospf/7zkoaLfUe19JxTOWaKWO51wK9 > gg > > > [Line numbers from idnits.] > > > idnits 2.16.02 > > ... > 16Abstract > > 18 Existing traffic engineering related link attribute advertisements > 19 have been defined and are used in RSVP-TE deployments. Since > the > 20 original RSVP-TE use case was defined, additional applications (e.g., > 21 SRTE, LFA) have been defined which also make use of the link > 22 attribute advertisements. In cases where multiple applications wish > 23 to make use of these link attributes the current advertisements do > 24 not support application specific values for a given attribute nor do > 25 they support indication of which applications are using the > 26 advertised value for a given link. > > [minor] Expand SRTE and LFA. > [Les:] DONE > 28 This draft introduces new link attribute advertisements which > address > 29 both of these shortcomings. It also discusses backwards > 30 compatibility issues and how to minimize duplicate advertisements > in > 31 the presence of routers which do not support the extensions > defined > 32 in this document. > > [nit] s/draft/document > > [c] The OSPF abstract is more general, while this one provides more > specifics... > [Les:] I have shortened the abstract - though the text is still somewhat different than the OSPF draft because in IS-IS we provide a way to migrate RSVP-TE to the new advertisements whereas in OSPF the recommendation is NOT to migrate
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
On January 15, 2020 at 3:48:31 PM, Les Ginsberg wrote: Les: Hi! ... > 5. Deployment Considerations > 6. Attribute Advertisements and Enablement > 7. Interoperability, Backwards Compatibility and Migration > Concerns > > Of these I think 5 and 7 could logically be combined and fall under the > heading of "Deployment Considerations". > > Section 6 is discussing a particular aspect of the protocol extensions - what > the advertisement of link attributes associated with a particular application > says about the state of that application on that link. This isn't a > deployment consideration. > > I therefore suggest that Section 6 remain as is but be placed BEFORE a new > Deployment Considerations section which will have the combined content of the > current Sections 5 and 7 - plus revisions based on your comments. > > Let me know if that makes sense to you. Yes, that works for me. > > [c] The OSPF abstract is more general, while this one provides more > > specifics... > > [Les:] And which style do you prefer? Most of the time I prefer the general approach. In this case either works for me. I would simply want to avoid questions about what may look like different scope/goals/functionality... Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
Alvaro - A few pointed questions as we work on the revisions. > > (A) Deployment Considerations > > This document contains what I would characterize as a "distributed" > Deployment Considerations section through §5, §6 and §7. There is a > lot of content, but I still made some comments in-line about other > important information. Please consider consolidating all the > deployment-related information in one place. rfc5706 (specially §2) > may be useful, please take a look. > [Les:] This comment covers three sections: 5. Deployment Considerations 6. Attribute Advertisements and Enablement 7. Interoperability, Backwards Compatibility and Migration Concerns Of these I think 5 and 7 could logically be combined and fall under the heading of "Deployment Considerations". Section 6 is discussing a particular aspect of the protocol extensions - what the advertisement of link attributes associated with a particular application says about the state of that application on that link. This isn't a deployment consideration. I therefore suggest that Section 6 remain as is but be placed BEFORE a new Deployment Considerations section which will have the combined content of the current Sections 5 and 7 - plus revisions based on your comments. Let me know if that makes sense to you. > > [c] The OSPF abstract is more general, while this one provides more > specifics... [Les:] And which style do you prefer? Les ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
On January 10, 2020 at 10:53:40 AM, Les Ginsberg wrote: Les: Hi! > We are working on addressing your comments - but it will take us a bit of > time to complete that - please be patient. You have all been very patient with me already -- I can only return the favor. :-) > One question. In several places you are requesting a forward reference to the > IANA Considerations section. For example in Section 4.1. > I find this ask rather unusual. > Section 4.1 is defining the format of some fields in the new sub-TLV. What > would be the need of a forward reference to the IANA section? > I cannot recall ever doing the equivalent in any draft I have worked on. 231 4.1. Application Identifier Bit Mask 233 Identification of the set of applications associated with link 234 attribute advertisements utilizes two bit masks. One bit mask is for 235 standard applications where the definition of each bit is defined in 236 a new IANA controlled registry. A second bit mask is for non- 237 standard User Defined Applications(UDAs). In this case, there is a mention in the text about the new registry -- I thought it would be useful to the reader to have a pointer to where the values are. The comment was meant just as a suggestion. Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-isis-te-app-09
Alvaro - Happy New Year to you! Thanx for the extensive review of this draft and draft-ietf-ospf-te-link-attr-reuse-10. It is clear that you spent a good deal of time on this and covered a lot of ground - much appreciated. We are working on addressing your comments - but it will take us a bit of time to complete that - please be patient. One question. In several places you are requesting a forward reference to the IANA Considerations section. For example in Section 4.1. I find this ask rather unusual. Section 4.1 is defining the format of some fields in the new sub-TLV. What would be the need of a forward reference to the IANA section? I cannot recall ever doing the equivalent in any draft I have worked on. ??? Thanx. Les ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] AD Review of draft-ietf-isis-te-app-09
Dear Authors: Happy New Year! I have finished reading this document, reviewing the e-mail archive and all the various reviews and comments. Quoting one of the authors, "it is essential that the two IGPs provide equivalent functionality" [1] -- so I have considered draft-ietf-ospf-te-link-attr-reuse-10 in parallel with this one (I'm sending out a separate yet very similar review for it). In general, I think both drafts need some work. When appropriate, I have used "[c]" to highlight comparisons. I tried to put equivalent comments in both documents, but may have missed a few... I have some significant concerns (see details inline) about this document -- and as a result about the OSPF draft. I want to point out a couple of them here: (A) Deployment Considerations This document contains what I would characterize as a "distributed" Deployment Considerations section through §5, §6 and §7. There is a lot of content, but I still made some comments in-line about other important information. Please consider consolidating all the deployment-related information in one place. rfc5706 (specially §2) may be useful, please take a look. (B) I was able to identify one significant functional difference which warrants a discussion of the reason for it and maybe the pros/cons: §4.1 talks about the behavior when "both SABM Length and UDABM Length are zero". This document makes the use of the attributes optional while the OSPF draft mandates their use (§3). I will wait for this review to be addressed before moving both documents forward together. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/ospf/7zkoaLfUe19JxTOWaKWO51wK9gg [Line numbers from idnits.] idnits 2.16.02 ... 16 Abstract 18 Existing traffic engineering related link attribute advertisements 19 have been defined and are used in RSVP-TE deployments. Since the 20 original RSVP-TE use case was defined, additional applications (e.g., 21 SRTE, LFA) have been defined which also make use of the link 22 attribute advertisements. In cases where multiple applications wish 23 to make use of these link attributes the current advertisements do 24 not support application specific values for a given attribute nor do 25 they support indication of which applications are using the 26 advertised value for a given link. [minor] Expand SRTE and LFA. 28 This draft introduces new link attribute advertisements which address 29 both of these shortcomings. It also discusses backwards 30 compatibility issues and how to minimize duplicate advertisements in 31 the presence of routers which do not support the extensions defined 32 in this document. [nit] s/draft/document [c] The OSPF abstract is more general, while this one provides more specifics... ... 107 1. Introduction 109 Advertisement of link attributes by the Intermediate-System-to- 110 Intermediate-System (IS-IS) protocol in support of traffic 111 engineering (TE) was introduced by [RFC5305] and extended by 112 [RFC5307], [RFC6119], and [RFC8570]. Use of these extensions has 113 been associated with deployments supporting Traffic Engineering over 114 Multiprotocol Label Switching (MPLS) in the presence of Resource 115 Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE. [nit] s/presence of Resource/presence of the Resource [minor] Please add a reference for RSVP-TE. 117 In recent years new applications have been introduced which have use 118 cases for many of the link attributes historically used by RSVP-TE. 119 Such applications include Segment Routing Traffic Engineering (SRTE) 120 and Loop Free Alternates (LFA). This has introduced ambiguity in 121 that if a deployment includes a mix of RSVP-TE support and SRTE 122 support (for example) it is not possible to unambiguously indicate 123 which advertisements are to be used by RSVP-TE and which 124 advertisements are to be used by SRTE. If the topologies are fully 125 congruent this may not be an issue, but any incongruence leads to 126 ambiguity. [minor] What is an application? From the examples above I think I can tell the difference between an "application", as used in this document, and an "application" as what the ART area does: "The ART area develops application protocols and architectures in the IETF." [1] Please define what an application is in the context of this document. [1] https://datatracker.ietf.org/group/art/about/ [minor] Add references for SRTE and LFA...and any use cases/requirements that support the need (or a forward reference to §2, for this last point). All Informational. ... 177 3. Legacy Advertisements 179 There are existing advertisements used in support of RSVP-TE. These 180 advertisements include sub-TLVs for TLVs 22,
