Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt

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

Acee -

Thanx for reviving this thread.

In fairness, Qin did respond - and we exchanged a couple of emails on this thread - though I would not say that we had reached closure.

He also sent an email to PCE WG asking for an update on their position - but to date I have seen no response to that.

So for me - this topic is still open for further discussion - both by the authors and the LSR/PCE WGs.

  Les

> -----Original Message-----
> From: Acee Lindem (acee)
> Sent: Saturday, June 22, 2019 1:36 PM
> To: [e-mail]
> Cc: [e-mail]; Les Ginsberg (ginsberg) <[e-mail]>
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
> 
> Authors - can you respond to Les' comments?
> Thanks,
> Acee
> 
> On 6/3/19, 2:22 AM, "Lsr on behalf of Les Ginsberg (ginsberg)" <lsr-
> [e-mail] on behalf of [e-mail]> wrote:
> 
>     A few - somewhat tardy - concerns about this draft.
> 
>     1)During adoption call it was mentioned that PCE WG had not taken a
> position on this draft. Since I don't follow PCE WG (apologies) I need to ask -
> has that status changed??
> 
>     2)As discussed during the adoption call, the draft removes the restriction
> specified in RFC 5088/5089 of not allowing further PCE related
> advertisements in Router Capability TLV/Router Information LSA.
>     Acee had mentioned that he thought this was no longer a concern because
> in RFC 7770 multiple OSPF Router Information LSA support was introduced.
> But this is really not relevant to the reason that the restriction was originally
> introduced.
> 
>     The restriction was introduced because of general concern that using IGPs
> to advertise information not directly relevant to the operation of the IGP as a
> routing protocol is sub-optimal and negatively impacts the performance of
> the primary IGP functions.
> 
>     I am aware that this is a line that has been crossed (in modest ways) more
> than once - and I am not categorically opposing the extensions proposed -
> but I do wonder if this is the most appropriate way to advertise the new
> attributes - particularly since this does not solve the general case - it only
> applies when the PCE is also an LSR. I think a broader discussion of this issue
> is warranted.
> 
>     3)If the draft goes forward in its current form, it updates RFC 5088/5089 in a
> significant way (the removal of restriction against additional PCE related IGP
> advertisements) - in which case I wonder if it would be better to write an RFC
> 5088/89 bis document rather than an extension document.
> 
>     And, BTW, do you know why the HTML version of the document has no
> table of contents?
> 
>        Les
> 
> 
>     > -----Original Message-----
>     > From: Lsr <[e-mail]> On Behalf Of [e-mail]
>     > Sent: Sunday, June 02, 2019 8:45 PM
>     > To: [e-mail]
>     > Cc: [e-mail]
>     > Subject: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
>     >
>     >
>     > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>     > This draft is a work item of the Link State Routing WG of the IETF.
>     >
>     >         Title           : IGP extension for PCEP security capability support in the
> PCE
>     > discovery
>     >         Authors         : Diego R. Lopez
>     >                           Qin Wu
>     >                           Dhruv Dhody
>     >                           Michael Wang
>     >                           Daniel King
>     > 	Filename        : draft-ietf-lsr-pce-discovery-security-support-01.txt
>     > 	Pages           : 10
>     > 	Date            : 2019-06-02
>     >
>     > Abstract:
>     >    When a Path Computation Element (PCE) is a Label Switching Router
>     >    (LSR) participating in the Interior Gateway Protocol (IGP), or even a
>     >    server participating in IGP, its presence and path computation
>     >    capabilities can be advertised using IGP flooding.  The IGP
>     >    extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
>     >    to advertise path computation capabilities using IGP flooding for
>     >    OSPF and IS-IS respectively.  However these specifications lack a
>     >    method to advertise PCEP security (e.g., Transport Layer
>     >    Security(TLS), TCP Authentication Option (TCP-AO)) support
>     >    capability.
>     >
>     >    This document proposes new capability flag bits for PCE-CAP-FLAGS
>     >    sub-TLV that can be announced as attribute in the IGP advertisement
>     >    to distribute PCEP security support information.  In addition, this
>     >    document updates RFC 5088 and RFC 5089 to allow advertisement of
> Key
>     >    ID or Key Chain Name Sub-TLV to support TCP AO security capability.
>     >
>     >
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-
>     > support/
>     >
>     > There are also htmlized versions available at:
>     > https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-support-
> 01
>     > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-
> security-
>     > support-01
>     >
>     > A diff from the previous version is available at:
>     > https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-
>     > support-01
>     >
>     >
>     > Please note that it may take a couple of minutes from the time of
> submission
>     > until the htmlized version and diff are available at tools.ietf.org.
>     >
>     > Internet-Drafts are also available by anonymous FTP at:
>     > ftp://ftp.ietf.org/internet-drafts/
>     >
>     > _______________________________________________
>     > Lsr mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/lsr
> 
>     _______________________________________________
>     Lsr mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/lsr
>