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

[Qin Wu <[e-mail]>]

Les:
-----邮件原件-----
发件人: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
发送时间: 2019年9月30日 12:34
收件人: Qin Wu <[e-mail]>; [e-mail]
主题: RE: I-D Action: draft-ietf-lsr-pce-discovery-security-support-02.txt

Qin -

Apologies for the tardy response. I was on vacation when you sent the update - and it has taken me a while to catch up.

I would agree with Adrian that the new version is a significant improvement - but there are still two points of concern for me.

1)Although you now mention the restrictions in RFC 5088/5089 against further IGP extensions, you do not reinforce that this restriction should still be considered to be in place after the allowance of the two additional exceptions. Something to the effect:

OLD

" 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 new sub-TLVs defined in this document to be carried in the
   PCED TLV of the for use in the Router CAPABILITY TLV."

NEW

" Section 4 of [RFC5089] states that no new sub-TLVs will be added to
   the PCED sub-TLV, and no new PCE information will be carried in the
   Router CAPABLITY TLV.  This document updates [RFC5089] by allowing
   the two new sub-TLVs defined in this document to be carried in the
   PCED TLV of the for use in the Router CAPABILITY TLV. The introduction of
  the additional sub-TLVs should be viewed as an exception to the [RFC5089] policy
  justified by the need to know the new information prior to establishing a PCEP session.
  The restrictions defined in  [RFC5089] should still
  be considered  to be in place."
[Qin]: The proposed change looks good, I think it also applies to new TLV for OSPF. So I will tweak a little bit the text your proposed, thanks.
2)I still do not know what position the PCE WG has regarding this work.
[Qin]: If you followed discussion in last PCE WG, I presented this draft in PCE session in Montreal, PCE chair agreed to remove such restriction on RFC5089.
Based on this agreement, Adrian responded to my email raised on the lsr list and suggest not open door to new future extension. Your proposed text perfectly
close the door, thanks.
Hope this clarifies.

   Les


> -----Original Message-----
> From: Lsr <[e-mail]> On Behalf Of Qin Wu
> Sent: Tuesday, September 03, 2019 4:03 AM
> To: [e-mail]
> Subject: Re: [Lsr] I-D Action: 
> draft-ietf-lsr-pce-discovery-security-support-
> 02.txt
> 
> The v-02 is posted to address remaining comments on the list, thanks 
> Adrain, Aijun, Les for comments and input.
> The diff is:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-securit
> y-
> support-02
> 
> -Qin
> -----邮件原件-----
> 发件人: I-D-Announce [mailto:[e-mail]] 代表
> [e-mail]
> 发送时间: 2019年9月3日 18:58
> 收件人: [e-mail]
> 抄送: [e-mail]
> 主题: I-D Action: draft-ietf-lsr-pce-discovery-security-support-02.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-02.txt
> 	Pages           : 9
> 	Date            : 2019-09-03
> 
> 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-supp
> ort-02
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-sec
> urity-
> support-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-securit
> y-
> support-02
> 
> 
> 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/
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr