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

From: [email-masked]
Date: Sun, 02 Jun 2019 20:45:02 -0700

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/

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 3 Jun 2019 06:21:46 +0000

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 <[email-masked]> On Behalf Of [email-masked]
> Sent: Sunday, June 02, 2019 8:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 22 Jun 2019 20:36:20 +0000

Authors - can you respond to Les' comments? 
Thanks,
Acee

On 6/3/19, 2:22 AM, "Lsr on behalf of Les Ginsberg (ginsberg)" <[email-masked] on behalf of [email-masked]> wrote:

    

    

       Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 23 Jun 2019 00:57:52 +0000

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

> From: Acee Lindem (acee)
> Sent: Saturday, June 22, 2019 1:36 PM
> To: [email-masked]
> Cc: [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
> 
> On 6/3/19, 2:22 AM, "Lsr on behalf of Les Ginsberg (ginsberg)" <lsr-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     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.
> 
>     >         Title           : IGP extension for PCEP security capability support in the
> PCE
>     > discovery
>     >         Authors         : Diego R. Lopez
>     >                           Qin Wu
>     >                           Dhruv Dhody
>     >                           Michael Wang
>     >                           Daniel King
>     > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-
> security-
>     > support-01
>     >

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 26 Jun 2019 15:36:11 +0800

Hi, Les:

For the situation that PCE is not an LSR, this draft also provides some help for other LSRs to find the PCE-----one can configure the PCE related info on one of the LSR/PCC, and then this LSR/PCC flood such information to other LSRs/PCCs? Or else, every PCC/LSR should know the PCE by manually configuration? This is applicable for RFC5088/5089.

The restriction stated in Section <https://tools.ietf.org/html/rfc5088#section-4>  4 of [RFC5088] and Section <https://tools.ietf.org/html/rfc5089#section-4>  4 of [RFC5089] seems not reasonable now, because the security communication consideration between PCE and PCC is important, as that pointed out in this draft.
 
I think we can have two options for such confliction avoidance:
1. Put this draft in individual document, update the RFC5088/5089 in their bis version(just to eliminate the above restriction)----Easy for the author, not for the reader, but is the most common way for such situation?
2. Merger this draft with RFC5088/RFC5089 in their bis version-----As Les pointed out, will be easier for the reader. But how to arrange the author list?
 
And another opinion is that IGP is suitable to transfer the information that needed by routers within the IGP domain. Such piggyback action can simplify the operation of network. Or else, the network should operate different protocols to accomplish such task.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-----邮件原件-----
发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
发送时间: 2019年6月23日 8:58
收件人: Acee Lindem (acee); [email-masked]
抄送: [email-masked]
主题: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt

Acee -

  Les

> To:  <mailto:[email-masked]> [email-masked]

> Cc:  <mailto:[email-masked]> [email-masked]; Les Ginsberg (ginsberg) < <mailto:[email-masked]> [email-masked]>

> Subject: Re: [Lsr] I-D Action: 

> draft-ietf-lsr-pce-discovery-security-support-

>  <mailto:[email-masked]> [email-masked] on behalf of  <mailto:[email-masked]> [email-masked]> wrote:

>     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

>     And, BTW, do you know why the HTML version of the document has no 

> table of contents?

>     > From: Lsr < <mailto:[email-masked]> [email-masked]> On Behalf Of  <mailto:[email-masked]> [email-masked]

>     > To:  <mailto:[email-masked]> [email-masked]

>     > Cc:  <mailto:[email-masked]> [email-masked]

>     > Subject: [Lsr] I-D Action: 

> draft-ietf-lsr-pce-discovery-security-support-

>     > A New Internet-Draft is available from the on-line 

> Internet-Drafts directories.

>     >    document updates RFC 5088 and RFC 5089 to allow advertisement of

> Key

>     >  <https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-> https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-

>     > support/

>  <https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-supp> https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-supp

> ort-

> 01

>  <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-

>     >  <https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-

>     > Please note that it may take a couple of minutes from the time 

> of submission

>     >  <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

>     >  <mailto:[email-masked]> [email-masked]

>     >  <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

>      <mailto:[email-masked]> [email-masked]

>      <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

Lsr mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr