Hi Les, Thanks, that’s helpful. One comment, regarding
> Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to > GENINFO/OSPF-GT even if such an addition might be relevant. what I was actually suggesting was that the paragraph in draft-ietf-lsr-pce-discovery-security-support could be updated to add the pointer. Since draft-ietf-lsr-pce-discovery-security-support formally updates RFCs 5088/5089, that would establish at least some mechanism less unreliable than trolling through old mailing lists, to help a new implementor find this old history, while still not requiring us to do the heavy lift of bis’ing 5088/5089 (which I agree would be crazy to do just for this). —John > On Oct 4, 2022, at 3:24 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > wrote: > > John - > > Thanx for finding the old email thread. > Folks also might want to look at this thread: > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/NhezQqKwIvHK_9dDUmW0iuhyjDA/__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3N-mB2epg$ > > In summary, I raised these points when the draft was adopted - but eventually > agreed to allow the draft to go forward. > > The intent of the restrictions in RFC5088/5089 is to discourage carrying > additional "non-routing" information in the IGPs. > The practical matter in this case is that trying to advertise the additional > information using some other mechanism is quite costly and awkward. The fact > that the additional information are sub-sub-TLVs of the PCED sub-TLV speaks > to the coupling of the new information with the existing information. > > I think we want to keep restrictions in place so as to discourage new > advertisements, but recognize that we compromise when it seems practical. > This isn’t ideal - and I understand why Lars would want to discuss this - but > I don't have a cleaner solution. > The fact that we introduced PCE advertisements into the IGPs in the first > place makes it difficult to adhere to the restrictions for PCE related > advertisements. > > Section 4 of the draft states: > > "This introduction of additional sub-TLVs should be viewed as an exception to > the [RFC5088][RFC5089] policy, justified by the requirement to discover the > PCEP security support prior to establishing a PCEP session. The restrictions > defined in [RFC5089][RFC5089] should still be considered to be in place." > > which is an accurate summary. > > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to > GENINFO/OSPF-GT even if such an addition might be relevant. > > Les > >> -----Original Message----- >> From: John Scudder <j...@juniper.net> >> Sent: Tuesday, October 4, 2022 11:16 AM >> To: Acee Lindem (acee) <a...@cisco.com> >> Cc: Lars Eggert <l...@eggert.org>; The IESG <i...@ietf.org>; draft-ietf-lsr- >> pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; lsr >> <lsr@ietf.org>; p...@ietf.org; Hannes Gredler <han...@gredler.at>; Les >> Ginsberg (ginsberg) <ginsb...@cisco.com>; JP Vasseur (jvasseur) >> <jvass...@cisco.com>; meral.shirazip...@polymtl.ca; Adrian Farrel >> <adr...@olddog.co.uk> >> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery- >> security-support-11: (with DISCUSS and COMMENT) >> >> Hi Acee, >> >> Thanks. I have a few followups (addressed to the WG at large, not just you). >> >> First, your point relates to OSPF. In the mail thread I cited, Les is >> talking about >> IS-IS. Are the concerns there similar? >> >> Second, you say "For non-routing information or advertising more >> information without impacting unicast routing, I'd recommend OSPF-GT”. >> That seems similar to Les’s advice (in >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/isis-wg/-__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3NUtSlhyQ$ >> YjCC5vzHkBY4aVWLJGP2w5OJHM/) to use IS-IS GENINFO (RFC 6823). I can >> see that extending the PCED (sub-)TLV was the most obvious and expedient >> thing to do, but was it the right thing? I’m thinking about your advice and >> Les’s, to use the generalized/generic transport options instead — was that >> option considered/discussed, or had everyone forgotten about the “please >> use GENINFO” suggestion by the time work on this draft began (after all, >> more than ten years after the base document was developed)? (I don’t see >> evidence in a review of the mailing list archives that this was ever >> considered, >> but I might have missed something.) >> >> Third, if indeed the restriction in question is no longer relevant, is this >> paragraph in the new spec really needed or even appropriate? >> >> This introduction of additional sub-TLVs should be viewed as an >> exception to the [RFC5088][RFC5089] policy, justified by the >> requirement to discover the PCEP security support prior to >> establishing a PCEP session. The restrictions defined in >> [RFC5089][RFC5089] should still be considered to be in place. >> >> Maybe it should just get rid of the restriction completely! On the other >> hand, >> if it *is* appropriate to leave that paragraph in, maybe it should be a >> little >> more helpful, by mentioning IS-IS GENINFO and OSPF-GT as being the >> preferred options for any future work, so that next time we are less likely >> to >> have the same oversight? >> >> Thanks, >> >> —John >> >>> On Oct 4, 2022, at 1:52 PM, Acee Lindem (acee) <a...@cisco.com> wrote: >>> >>> Speaking as long-time LSR/OSPF WG Member and Co-author of RFC 4970 >> and RFC 7770: >>> >>> When RFC 5088 was being standardized, there was concern over both >> advertising non-routing information in OSPF and exceeding the maximum >> size of an OSPF Router Information LSA which was limited to a single LSA >> instance per OSPF router (RFC 4970). The controversial statement below was >> added to assuage these concerns. With the publication of RFC 7770, an OSPF >> router can advertise multiple Router Instance LSAs with different instance >> IDs. At the same time, we have evolved to using Router Instance LSAs for >> limited capability information associated with routing applications (e.g., >> PCE). >> For non-routing information or advertising more information without >> impacting unicast routing, I'd recommend OSPF-GT >> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- >> lsr-ospf-transport-instance/__;!!NEt6yMaO- >> gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2 >> PUMF_yYzechg$ ). >>> >>> Thanks, >>> Acee >>> >>> On 10/4/22, 1:29 PM, "John Scudder" <j...@juniper.net> wrote: >>> >>> Hi Everyone, >>> >>> +Adrian since he appears to have been the shepherd for RFC 5088, which >> is the root of Lars’ DISCUSS. >>> +Hannes, Les, JP, Meral as people who may have more context on the >> question >>> >>> Since I haven’t seen any replies to this DISCUSS yet I did a little >>> digging. >> The text in question: >>> >>> No additional sub-TLVs will be added to the PCED TLV in the future. >>> If a future application requires the advertisement of additional PCE >>> information in OSPF, this will not be carried in the Router >>> Information LSA. >>> >>> Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. >> Checking in the archives, I see one relevant mail thread: >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/pce/UE >> Rk8vF5e7cFQoblkDAVA74Ojh0/__;!!NEt6yMaO- >> gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2 >> PUMF_994CNrH$ is the beginning, but then it seems to have been indexed >> wrong so you should continue from here: >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/isis- >> wg/BpUVKsjr46ha9kbF3jwgKyymEBo/__;!!NEt6yMaO- >> gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2 >> PUMF_4C7YoXF$ to pick up Les’s reply as well. There are four relevant >> messages in total, from Meral Shirazipour, JP Vasseur, Hannes Gredler, and >> Les Ginsberg. >>> >>> Rather than try to summarize I’m going to ask people to go look at the >> short mail thread for themselves. Perhaps this will jog people’s memories >> enough to allow a discussion on why we’re opening a registry for new code >> points that was explicitly defined as being closed. >>> >>> Thanks, >>> >>> —John >>> >>>> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker >> <nore...@ietf.org> wrote: >>>> >>>> >>>> Lars Eggert has entered the following ballot position for >>>> draft-ietf-lsr-pce-discovery-security-support-11: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/stat >> ements/handling-ballot-positions/__;!!NEt6yMaO- >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$ >>>> for more information about how to handle DISCUSS and COMMENT >> positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- >> lsr-pce-discovery-security-support/__;!!NEt6yMaO- >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11 >>>> >>>> CC @larseggert >>>> >>>> ## Discuss >>>> >>>> ### Section 4, paragraph 3 >>>> ``` >>>> Section 4 of [RFC5088] states that no new sub-TLVs will be added to >>>> the PCED TLV, and no new PCE information will be carried in the >>>> Router Information LSA. This document updates [RFC5088] by allowing >>>> the two sub-TLVs defined in this document to be carried in the PCED >>>> TLV advertised in the Router Information LSA. >>>> >>>> Section 4 of [RFC5089] states that no new sub-TLVs will be added to >>>> the PCED TLV, and no new PCE information will be carried in the >>>> Router CAPABLITY TLV. This document updates [RFC5089] by allowing >>>> the two sub-TLVs defined in this document to be carried in the PCED >>>> TLV advertised in the Router CAPABILITY TLV. >>>> >>>> This introduction of additional sub-TLVs should be viewed as an >>>> exception to the [RFC5088][RFC5089] policy, justified by the >>>> requirement to discover the PCEP security support prior to >>>> establishing a PCEP session. The restrictions defined in >>>> [RFC5089][RFC5089] should still be considered to be in place. >>>> ``` >>>> (This is mostly for discussion on the telechat, and I expect to clear >>>> during the call.) >>>> >>>> Why were 5088/89 so strict on not allowing new sub-TLVs? This seems >>>> quite unusual for IETF specs. I'm not arguing that this document >>>> can't update those earlier RFCs to allow these new sub-TLVs, but it >>>> seems odd to do so and in the same sentence say "the restrictions >>>> should still be considered in place." >>>> >>>> ### Section 8.2, paragraph 1 >>>> ``` >>>> The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they >>>> did not create a registry for it. This document requests IANA to >>>> create a new registry called "PCED sub-TLV type indicators" under the >>>> "Interior Gateway Protocol (IGP) Parameters" grouping. The >>>> registration policy for this registry is "IETF Review" [RFC8126]. >>>> Values in this registry come from the range 0-65535. >>>> ``` >>>> Should the registration policy not be stricter (e.g., Standards >>>> Action?) given that 5088/89 didn't even allow any new values? >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> ## Comments >>>> >>>> ### Inclusive language >>>> >>>> Found terminology that should be reviewed for inclusivity; see >>>> https://urldefense.com/v3/__https://www.rfc- >> editor.org/part2/*inclusive_language__;Iw!!NEt6yMaO- >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt1fwrlFS$ for >> background and more >>>> guidance: >>>> >>>> * Term `master`; alternatives might be `active`, `central`, `initiator`, >>>> `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` >>>> * Term `man`; alternatives might be `individual`, `people`, `person` >>>> >>>> ## Nits >>>> >>>> All comments below are about very minor potential issues that you may >> choose to >>>> address in some way - or ignore - as you see fit. Some were flagged by >>>> automated tools (via >> https://urldefense.com/v3/__https://github.com/larseggert/ietf- >> reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$ ), so there >>>> will likely be some false positives. There is no need to let me know what >> you >>>> did with these suggestions. >>>> >>>> ### URLs >>>> >>>> These URLs in the document can probably be converted to HTTPS: >>>> >>>> * >> https://urldefense.com/v3/__http://www.unicode.org/unicode/reports/tr3 >> 6/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt9o1UwDk$ >>>> >>>> ### Grammar/style >>>> >>>> #### "Abstract", paragraph 1 >>>> ``` >>>> for OSPF and IS-IS respectively. However these specifications lack a >> method >>>> ^^^^^^^ >>>> ``` >>>> A comma may be missing after the conjunctive/linking adverb "However". >>>> (Also elsewhere.) >>>> >>>> #### Section 1, paragraph 5 >>>> ``` >>>> ry" instead of the "IGP registry" where as [RFC8623] and [RFC9168] uses >> the >>>> ^^^^^^^^ >>>> ``` >>>> Did you mean "whereas"? >>>> >>>> #### Section 3.2.2, paragraph 3 >>>> ``` >>>> string to be used to identify the key chain. It MUST be encoded using UTF- >> 8. >>>> ^^^^^^^^^ >>>> ``` >>>> This word is normally spelled as one. (Also elsewhere.) >>>> >>>> #### Section 5, paragraph 4 >>>> ``` >>>> enable a man-in-the-middle attack. Thus before advertising the PCEP >> security >>>> ^^^^ >>>> ``` >>>> A comma may be missing after the conjunctive/linking adverb "Thus". >>>> >>>> ## Notes >>>> >>>> This review is in the ["IETF Comments" Markdown format][ICMF], You can >> use the >>>> [`ietf-comments` tool][ICT] to automatically convert this review into >>>> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. >>>> >>>> [ICMF]: https://urldefense.com/v3/__https://github.com/mnot/ietf- >> comments/blob/main/format.md__;!!NEt6yMaO- >> gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8uPawyE$ >>>> [ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf- >> comments__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxU9hxDt$ >>>> [IRT]: https://urldefense.com/v3/__https://github.com/larseggert/ietf- >> reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1- >> 32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$ >>>> >>> >>> > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
