Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

["Les Ginsberg (ginsberg)" <[e-mail]>]

John -

So you are suggesting that Section 4 of the draft be modified to say:

"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.
If in the future new advertisements are required, alternative mechanisms such as using [RFC6823] or https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ should be considered."

(or similar...)

I am fine with that.

   Les


> -----Original Message-----
> From: John Scudder <[e-mail]>
> Sent: Tuesday, October 4, 2022 12:31 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Acee Lindem (acee) <[e-mail]>; Lars Eggert <[e-mail]>;
> The IESG <[e-mail]>; draft-ietf-lsr-pce-discovery-security-
> [e-mail]; [e-mail]; lsr <[e-mail]>; [e-mail];
> Hannes Gredler <[e-mail]>; JP Vasseur (jvasseur)
> <[e-mail]>; [e-mail]; Adrian Farrel
> <[e-mail]>
> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-
> security-support-11: (with DISCUSS and COMMENT)
> 
> 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) <[e-mail]>
> 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/Nhe
> zQqKwIvHK_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 <[e-mail]>
> >> Sent: Tuesday, October 4, 2022 11:16 AM
> >> To: Acee Lindem (acee) <[e-mail]>
> >> Cc: Lars Eggert <[e-mail]>; The IESG <[e-mail]>; draft-ietf-
> lsr-
> >> [e-mail]; [e-mail]; lsr
> >> <[e-mail]>; [e-mail]; Hannes Gredler <[e-mail]>; Les
> >> Ginsberg (ginsberg) <[e-mail]>; JP Vasseur (jvasseur)
> >> <[e-mail]>; [e-mail]; Adrian Farrel
> >> <[e-mail]>
> >> 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) <[e-mail]>
> 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" <[e-mail]> 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
> >> <[e-mail]> 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$
> >>>>
> >>>
> >>>
> >