John - Thanx for finding the old email thread. Folks also might want to look at this thread: https://mailarchive.ietf.org/arch/msg/lsr/NhezQqKwIvHK_9dDUmW0iuhyjDA/
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://mailarchive.ietf.org/arch/msg/isis-wg/- > 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
