Re: [Lsr] Opsdir last call review of draft-ietf-lsr-ip-flexalgo-11 (Reformatted for Readability)

[Qin Wu]

Thanks Acee, it looks the template distorts the comments I produced. I believe 
it is the tool's problem.

-Qin
-邮件原件-
发件人: Acee Lindem  
发送时间: 2023年5月13日 13:39
收件人: draft-ietf-lsr-ip-flexa...@ietf.org; last-c...@ietf.org; ops-...@ietf.org; 
Qin Wu 
抄送: lsr 
主题: Opsdir last call review of draft-ietf-lsr-ip-flexalgo-11 (Reformatted for 
Readability) 

Hi Bill, 

Thanks for the Ops review. I reformatted your Email for readability and 
continued discussion.

Thanks,
Acee


Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Ops area directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other 
last-call comments.

This document extends Flex-Algorithm that is originally used for SR MPLS and
SRv6 data plane, allowing it to compute paths to IPv4 and IPv6 prefixes. This 
draft is well written, however I do have a few comments on the latest version 
before seeing this work being moved forward:

1. Abstract:Is regular IPv4 and IPv6 forwarding related to Native IP data plane,
IP dataplane has been describe once in section 5, but most of other places 
use
IP forwarding, which lack consistency. 

2. Introduction, last paragraph: It looks there are some contradiction here, On
one hand, Flex algorithm can be used independent of data plane technologies
such as SR MPLS, SRv6, Native IPv4/IPv6 On the other hand, it said: Flex 
algorithm is tied to SR MPLS or SRv6 data plane technology, lack 
consistency. 


3. Section 3 Do we use specific GTP data plane technology in this 5G use case?
If not the case, is there IGP protocol enabled on both gNodeB and UPF?
GTP/Native IP/ IP network with IGP protocol support Please be more explcit
 in the use case section.  

4.Section 6.1: Last Paragraph Lack RFC reference for IPv4 Prefix Reachability
   TLV and IPv6 Prefix Reachability TLV. Why IPv4 prefix reachability TLV can 
not
be used toCarry algo prefix reachability related information? Suppose both
IPv4 prefix reachability TLV and IPv4 Algorithm Prefix reachability TLV can
be used to carry the similar information, then the question is when we use
IPv4 Prefix Rechability TLV? When we use IPv4 Algorithm Prefix Reachability
TLV? Do we over design for this? 

5. Section 6.2: Last two Paragraphs It looks both ISIS SRv6 locator TLV an
ISIS IPv6 algorithm Prefix rechability TLV serve the similar purpose? Why 
we should introduce ISIS IPv6 Algorithm Rechability TLV?



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Opsdir last call review of draft-ietf-lsr-ip-flexalgo-11

[Qin Wu via Datatracker]

Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

This document extends Flex-Algorithm that is originally used for SR MPLS and
SRv6 data plane, allowing it to compute paths to IPv4 and IPv6 prefixes. This
draft is well written, however I do have a few comments on the latest version
before seeing this work being moved forward:

1. Abstract:
Is regular IPv4 and IPv6 forwarding related to Native IP data plane,
IP dataplane has been describe once in section 5, but most of other places use
IP forwarding, which lack consistency. 2. Introduction, last paragraph: It
looks there are some contradiction here, On one hand, Flex algorithm can be
used independent of data plane technologies such as SR MPLS, SRv6, Native
IPv4/IPv6 On the other hand, it said: Flex algorithm is tied to SR MPLS or SRv6
data plane technology, lack consistency. 3. Section 3 Do we use specific GTP
data plane technology in this 5G use case? If not the case, is there IGP
protocol enabled on both gNodeB and UPF? GTP/Native IP/ IP network with IGP
protocol support Please be more explcit in the use case section. 4.Section 6.1:
Last Paragraph Lack RFC reference for IPv4 Prefix Reachability TLV and IPv6
Prefix Reachability TLV. Why IPv4 prefix reachability TLV can not be used to
Carry algo prefix reachability related information? Suppose both IPv4 prefix
reachability TLV and IPv4 Algorithm Prefix reachability TLV can be used to
carry the similar information, then the question is when we use IPv4 Prefix
Rechability TLV? When we use IPv4 Algorithm Prefix Reachability TLV? Do we over
design for this? 5. Section 6.2: Last two Paragraphs It looks both ISIS SRv6
locator TLV an ISIS IPv6 algorithm Prefix rechability TLV serve the similar
purpose? Why we should introduce ISIS IPv6 Algorithm Rechability TLV?



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Opsdir last call review of draft-ietf-lsr-pce-discovery-security-support-10

[Qin Wu]

Thanks Will, good catch for the nits. Have fixed in v-11
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-11

-Qin
-邮件原件-
发件人: Will LIU via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2022年9月16日 14:56
收件人: ops-...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Opsdir last call review of draft-ietf-lsr-pce-discovery-security-support-10

Reviewer: Will LIU
Review result: Has Nits

Hi all,

I have reviewed draft-ietf-lsr-pce-discovery-security-support-10 as part of the 
Operational directorate's ongoing effort to review all IETF documents being 
processed by the IESG.  These comments were written with the intent of 
improving the operational aspects of the IETF drafts. Comments that are not 
addressed in last call may be included in AD reviews during the IESG review. 
Document editors and WG chairs should treat these comments just like any other 
last call comments.

“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 the 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 PCE Communication Protocol (PCEP) security (e.g.,
   Transport Layer Security (TLS), TCP Authentication Option (TCP-AO))
   support capability.”

My overall view of the document is almost 'Ready' for publication, except some 
editorials below.

** Technical **

No.

** Editorial **

• Section 1. Introduction
○ The fifth paragraph: s/This documents update [RFC5088]/This
document updates [RFC5088]/
• Section 3.1 Use of PCEP security capability support for PCE discovery
○ The last paragraph: s/If a client is configured to require
that its PCE server support TCP-AO/If a client is configured to
require that its PCE server supports TCP-AO; ○ s/If a client is
configured to require that its PCE server support TLS/If a
client is configured to require that its PCE server supports TLS
• Section 5 Backward Compatibility Considerations
○ The second paragraph: How to understand "KEYNAME" here?
s/KEYNAME/KEY-ID and KEY-CHAIN-NAME/?
• The title of Section 8.1: s/PCE Capability Flag/PCE Capability Flags/
• Section 9 Acknowledges
○ s/speical/special/

Regards,
Will (Shucheng LIU)



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Qin Wu]

Hi, John:
The v-10 is posted, see our diff below:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-10

-Qin (on behalf of authors)
-邮件原件-
发件人: John Scudder [mailto:jgs=40juniper@dmarc.ietf.org] 
发送时间: 2022年9月5日 2:38
收件人: Qin Wu 
抄送: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr@ietf.org; Dhruv 
Dhody ; Acee Lindem (acee) ; Les Ginsberg 
(ginsberg) 
主题: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Hi Qin and all,

Looks like we’ve agreed on all the points under discussion, I’ll look forward 
to reviewing the next revision.

Thanks,

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Qin Wu]

Hi, John:
-邮件原件-
发件人: John Scudder [mailto:jgs=40juniper@dmarc.ietf.org] 
发送时间: 2022年8月27日 5:34
收件人: Qin Wu 
抄送: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr@ietf.org; Dhruv 
Dhody ; Acee Lindem (acee) ; Les Ginsberg 
(ginsberg) 
主题: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Hi Qin,

Thanks for your reply, and Dhruv, Acee, and Les for your subsequent remarks. 
I’m rolling all my comments together into this reply to Qin’s message. Anything 
that’s settled I’ve snipped out, remaining items discussed in line.

> On Aug 25, 2022, at 5:21 AM, Qin Wu  
> wrote:

[snip]

> +jgs: I don't find any place where you explicitly mention that the 
> +sub-TLVs you define are identical for both OSPF and IS-IS. Please do 
> +make this explicit.
>  
> 
> [Qin Wu] We authors add explicit statement in section 3 to say
> 
> “
> 
>  
> 
>In addition, the sub-TLVs defined in this document (i.e.,Section 
> 3.2,
> 
> Section 3.3) are used identically in both OSPF and IS-IS.
> 
> ”
> 
> Hope this addresses your comment.

Les’s subsequent remarks have convinced me that it will be better to explicitly 
define the sub-TLVs separately for the two protocols. Assuming you do so, this 
becomes moot.

>  3.2.  KEY-ID Sub-TLV
>  
> -   The KEY-ID sub-TLV specifies a key that can be used by the PCC to
> +   The KEY-ID sub-TLV specifies an identifier that can be used by the 
> + PCC to
> identify the TCP-AO key [RFC5925].
>  
> The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried 
> within @@ -233,6 +267,14 @@
>  
>Reserved: MUST be set to zero while sending and ignored on
>receipt.
> +  
> +jgs: what is the size of the Reserved field?  I'm guessing it's three 
> +octets, to align the sub-TLV to a word boundary, but you need to say.
> +[Qin Wu] Yes, it can be inferred from 4 octets length and 1 octet KEY ID.
> 
> But we can make it explicitly.

Actually, why do you have a Reserved field anyway? If it’s just padding to get 
32-bit alignment — in OSPF, doesn’t that come “for free” without need for 
explicitly defining the field (as we covered in our discussion of the 
key-chain-name sub-TLV), and in IS-IS there is no need for padding, so why burn 
the bytes?

If you’re reserving the field on purpose for some contemplated future use, 
that’s fine of course. But otherwise it seems to me you could remove it. 
However, see also my further comments below under KEY-CHAIN-NAME.

[Qin Wu] I agree to remove reserve field for ISIS.
> +A diagram of the style used in RFC 5088 would make this more evident 
> +since presumably you'd show the Reserved field in the diagram.  I 
> +don't insist you add diagrams, but they do tend to help the 
> +document's readability so maybe consider it for this and also §3.3.
>  [Qin Wu] This has been discussed on the list before, it is 
> intentional not use diagram
> 
> for IGP since OSPF uses diagram for TLV format while ISIS not.

This also becomes moot assuming you follow Les’s recommendation to have 
separate definitions for the OSPF and IS-IS sub-TLVs. In that case you would 
presumably follow the OSPF format for the OSPF definition, and the IS-IS format 
for the IS-IS definition.
[Qin Wu] Agree, will do.
>  3.3.  KEY-CHAIN-NAME Sub-TLV
>  
> @@ -241,9 +283,9 @@
>  
> The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried
> within the IS-IS Router Information Capability TLV when the
> -   capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to
> +   capability flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set 
> + to
> indicate TCP Authentication Option (TCP-AO) support.  Similarly, this
> -   sub-TLV MAY be present in the PCED TLV carried within OSPF Router
> +   sub-TLV MAY be present in the PCED TLV carried within the OSPF 
> + Router
> Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV
> in OSPF is set to indicate TCP-AO support.
>  
> @@ -257,6 +299,57 @@
>identify the key chain.  It SHOULD be a string of printable ASCII
>characters, without a NULL terminator.  The sub-TLV MUST be zero-
>padded so that the sub-TLV is 4-octet aligned.
> +  
> +jgs: Shouldn't your SHOULD be a MUST? If not, what are the non-ASCII 
> +characters that are allowed, and under what circumstances?
> +
> +For that matter, why are you restricting the key chain name to ASCII?
> +You cite RFC 8177 above. Looking at 8177, it defines a key-chain name 
> +as a YANG string, and RFC 7950 tells us that for a YANG string:
> +
> +   Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]
> +   characters, including tab, carriage return, and line feed but
> +   excluding the other C0 

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Qin Wu]

Thanks Les, Acee and John for suggestion on protocol format definition, I agree 
to have two separate protocol format for ISIS and OSPF and will add addition 
pages to make these clear.

-Qin
-邮件原件-
发件人: John Scudder [mailto:j...@juniper.net] 
发送时间: 2022年8月27日 3:33
收件人: Les Ginsberg (ginsberg) 
抄送: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr@ietf.org
主题: Re: AD review of draft-ietf-lsr-pce-discovery-security-support-09

Les, thanks for the followup, and the sanity-check.

> On Aug 26, 2022, at 3:04 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Rather than do what John suggests below (have two lengths in the encoding), 
> please define distinct formats for each protocol.
> This should be done for the KEY-ID sub-TLV as well.
> This is not only consistent with the behavior of each protocol, it is 
> consistent with what has been done in RFCs 5088/5089.
>  
> Using the same sub-TLV code point across both protocols is fine since we 
> constrain it to sub-TLVs under the PCED advertisement – but please - protocol 
> specific sub-TLV format definitions always.

This makes good sense to me. It will take another page or two in the draft, but 
will make it more readable and implementable, IMO.

Thanks,

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Qin Wu]

Thanks Acee and Dhruv for suggested changes and check on the following two 
issues.
See reply inline below.
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2022年8月25日 21:49
收件人: Dhruv Dhody ; Qin Wu 
抄送: John Scudder ; 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr@ietf.org
主题: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Speaking as document shepherd and WG member:

Hi John, Qin, and Dhruv,

See a couple inlines.

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Date: Thursday, August 25, 2022 at 7:02 AM
To: Qin Wu mailto:bill...@huawei.com>>
Cc: John Scudder mailto:j...@juniper.net>>, 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Hi Qin, John,

I have added my comments for two issues, please see inline (look for Dhruv:)


On Thu, Aug 25, 2022 at 2:52 PM Qin Wu 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi, John:
Thanks for your valuable AD review. We have incorporate your comments into 
draft-ietf-lsr-pce-discovery-security-support-10.
Regarding the issues your raised below, please reply inline below.

-Qin (on behalf of authors)
发件人: John Scudder [mailto:j...@juniper.net<mailto:j...@juniper.net>]
发送时间: 2022年8月18日 8:41
收件人: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>
主题: AD review of draft-ietf-lsr-pce-discovery-security-support-09

Dear Authors,

Thanks for you patience as this document sat in my queue for too long. :-( 
Here’s my review.

I’ve supplied my comments in the form of an edited copy of the draft. Minor 
editorial suggestions I’ve made in place without further comment, more 
substantive comments are done in-line and prefixed with “jgs:”. You can use 
your favorite diff tool to review them; I’ve attached a PDF of the iddiff 
output for your convenience if you’d like to use it. I’ve also pasted a 
traditional diff below in case you want to use it for in-line reply. I’d 
appreciate feedback regarding whether you found this a useful way to receive my 
comments as compared to a more traditional numbered list of comments with 
selective quotation from the draft.

Thanks,

—John


--- draft-ietf-lsr-pce-discovery-security-support-09.txt2022-08-17 
15:35:47.0 -0400
+++ draft-ietf-lsr-pce-discovery-security-support-09-jgs-comments.txt   
2022-08-17 20:37:48.0 -0400
@@ -13,14 +13,14 @@
   21 August 2021


-IGP extension for PCEP security capability support in the PCE discovery
+IGP extension for PCEP security capability support in PCE discovery
 draft-ietf-lsr-pce-discovery-security-support-09

 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
+   server participating in the 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
@@ -28,10 +28,10 @@
method to advertise PCEP security (e.g., Transport Layer Security
(TLS), TCP Authentication Option (TCP-AO)) support capability.

-   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
+   This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV
that can be announced as an 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
+   document updates RFC 5088 and RFC 5089 to allow advertisement of a Key
ID or Key Chain Name Sub-TLV to support TCP-AO security capability.
RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the
movement of the IANA "PCE Capability Flags" registry.
@@ -100,7 +100,7 @@
 1.  Introduction

As described in [RFC5440], PCEP communication privacy is one
-   importance issue, as an attacker that intercepts a Path Computation
+   important issue, as an attacker that intercepts a Path Computation
Element (PCE) message could obtain sensitive information related to
computed paths and resources.

@@ -114,14 +114,14 @@
 Internet-Draft   IGP discovery for PCEP Security August 2021


-   Among the possible solutions mentioned in these documents, Transport
+   Among the possible solutions mentioned in th

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

John:
Hope you are doing well.
We authors know draft-ietf-lsr-pce-discovery-security-support-05 is one of WG 
drafts you are responsible for.
We just want to give you a quick heads up, we have addressed all comments from 
directorate review including secdir review.
Unfortunately secdir review can not be updated to reflect the real status but 
just note the review has completed.
I know this is a bug, but it is not a big deal.

Please let us authors know if anything is needed from us to move this work 
forward.
Thanks in advance.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月27日 21:27
收件人: Tero Kivinen ; Yaron Sheffer 
抄送: Qin Wu ; tom petch ; 
draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Tero,
I see the review is now marked "Completed". This was what I wanted.
Thanks,
Acee

On 8/27/21, 9:11 AM, "Tero Kivinen"  wrote:

Yaron Sheffer writes:
> Hi Acee,
> 
> I honestly don't know how to do it, and if I even can unless you
> send a new review request. 

We do not really update the reviews, but we do assign draft for two
reviews, i.e., one during the last call and one before the telechat (I
will not reassign it for telechat if there is no need to do rereview,
i.e., original review was ready and/or nothing major changed in the
draft since the review). 

> Copying Tero who's an expert on this.
> 
> To clarify: my review of -05 still stands, but it has been addressed
> by -07.

As area directors will see the review email thread and if the there is
comment there that review comments have been addressed in later drafts
that is enough, so no need to update the review.

Note, that even when the reviewer thinks his comments have been
addressed, the area director might have different view on that matter,
i.e., they might still comment on the issues found during the
telechat. 

> 
> Thanks,
>   Yaron
> 
> 
> On 8/19/21, 20:55, "Acee Lindem (acee)"  wrote:
> 
> Hi Yaron,
> 
> Thanks for the review. Can you update the status of the SECDIR 
review? 
> 
> 
https://datatracker.ietf.org/doc/review-ietf-lsr-pce-discovery-security-support-05-secdir-lc-sheffer-2021-08-05/
> 
> Thanks,
> Acee
> 
> On 8/17/21, 3:15 AM, "Yaron Sheffer"  wrote:
    > 
> Looks good to me. Thank you!
> 
>   Yaron
> 
> On 8/17/21, 03:17, "Qin Wu"  wrote:
> 
> Sorry for late followup, here is the update, the diff is
> 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06
> Yaron, let authors know if your comments are addressed in 
v-06.
> Thanks!
> 
>         -Qin
> -邮件原件-
> 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
> 发送时间: 2021年8月17日 4:33
> 收件人: Qin Wu ; tom petch 
; Yaron Sheffer ; sec...@ietf.org
> 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
> 主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05
> 
> Hi Qin, 
> 
    > Can you publish a revision so that Yaron assure it satisfies 
his comments? 
> 
> Thanks,
> Acee
> 
> On 8/12/21, 9:21 PM, "Qin Wu"  wrote:
> 
> Thanks Acee and Tom for good suggestion, we will take 
them into account.
> 
    > -Qin
> -邮件原件-
> 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
> 发送时间: 2021年8月12日 1:18
> 收件人: tom petch ; Yaron Sheffer 
; Qin Wu ; sec...@ietf.org
> 抄送: 
draft-ietf-lsr-pce-discovery-security-support@ietf.org
> 主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05
> 
> I'd also recommend changing, "key names" to "key-ids or 
key-chain names" since this is what is actually being advertised.
> Thanks,
> Acee
> 
> On 8/10/21, 11:53 AM, "tom petch"  
wrote:
> 
> From: Lsr  on behalf of Yaron 
Sheffer 
> Sent: 10 August 2021 14:57
> 
> So let me suggest:
> 
> 
>  

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Thanks Yaron.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
发送时间: 2021年8月17日 15:15
收件人: Qin Wu ; Acee Lindem (acee) ; tom 
petch ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Looks good to me. Thank you!

Yaron

On 8/17/21, 03:17, "Qin Wu"  wrote:

Sorry for late followup, here is the update, the diff is

https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06
Yaron, let authors know if your comments are addressed in v-06.
Thanks!

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月17日 4:33
    收件人: Qin Wu ; tom petch ; Yaron 
Sheffer ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin, 

Can you publish a revision so that Yaron assure it satisfies his comments? 

Thanks,
Acee

On 8/12/21, 9:21 PM, "Qin Wu"  wrote:

Thanks Acee and Tom for good suggestion, we will take them into account.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月12日 1:18
收件人: tom petch ; Yaron Sheffer 
; Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

I'd also recommend changing, "key names" to "key-ids or key-chain 
names" since this is what is actually being advertised.
Thanks,
Acee

On 8/10/21, 11:53 AM, "tom petch"  wrote:

From: Lsr  on behalf of Yaron Sheffer 

Sent: 10 August 2021 14:57

So let me suggest:


An offlist suggestion for you to consider

OLD
Thus before advertisement of the PCE security parameters, it 
MUST be insured that the IGP protects the authentication and integrity of the 
PCED TLV using the mechanisms defined in
[RFC5310] and [RFC5709], if the mechanism described in this 
document is used.

Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not 
provide any encryption mechanisms to protect the secrecy of the PCED TLV, and 
the operator must ensure that no private data is carried in the TLV, for 
example that key names do not reveal sensitive information about the network.

NEW

 Thus before advertising the PCE security parameters, using the 
mechanism described in this document, the IGP MUST be known to provide 
authentication and integrity for the PCED TLV using the mechanisms defined in  
[RFC5304],  [RFC5310] or [RFC5709],

Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does 
not provide any encryption mechanisms to protect the secrecy of the PCED TLV, 
then the operator must ensure that no private data is carried in the TLV, e.g. 
that key names do not reveal sensitive information about the network.

Tom Petch


Thanks,
        Yaron

On 8/10/21, 15:01, "Qin Wu"  wrote:

Yaron:
Thank for clarification. I agree to keep the last sentence in 
the second paragraph of section 7 as is.
But I prefer to add the addition references in the previous 
sentence as follows:
"
Thus before advertisement of the PCE security parameters, it 
MUST be insured that the IGP is
protected for authentication and integrity of the PCED TLV,, 
with the mechanisms defined in
[RFC5310] and [RFC5709] if the mechanism described in this 
document is used.

As stated in [RFC5088] and [RFC5089], the IGP do not provide 
encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the 
PCEP session less secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, 
because we should be focusing on integrity protection and not privacy 
(=secrecy) of the TLV. So I would prefer to keep the text as-is, with the 
addition of a refer

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Sorry for late followup, here is the update, the diff is
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06
Yaron, let authors know if your comments are addressed in v-06.
Thanks!

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月17日 4:33
收件人: Qin Wu ; tom petch ; Yaron 
Sheffer ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin, 

Can you publish a revision so that Yaron assure it satisfies his comments? 

Thanks,
Acee

On 8/12/21, 9:21 PM, "Qin Wu"  wrote:

Thanks Acee and Tom for good suggestion, we will take them into account.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月12日 1:18
收件人: tom petch ; Yaron Sheffer 
; Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

I'd also recommend changing, "key names" to "key-ids or key-chain names" 
since this is what is actually being advertised.
Thanks,
Acee

On 8/10/21, 11:53 AM, "tom petch"  wrote:

From: Lsr  on behalf of Yaron Sheffer 

Sent: 10 August 2021 14:57

So let me suggest:


An offlist suggestion for you to consider

OLD
Thus before advertisement of the PCE security parameters, it MUST 
be insured that the IGP protects the authentication and integrity of the PCED 
TLV using the mechanisms defined in
[RFC5310] and [RFC5709], if the mechanism described in this 
document is used.

Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not 
provide any encryption mechanisms to protect the secrecy of the PCED TLV, and 
the operator must ensure that no private data is carried in the TLV, for 
example that key names do not reveal sensitive information about the network.

NEW

 Thus before advertising the PCE security parameters, using the 
mechanism described in this document, the IGP MUST be known to provide 
authentication and integrity for the PCED TLV using the mechanisms defined in  
[RFC5304],  [RFC5310] or [RFC5709],

Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does not 
provide any encryption mechanisms to protect the secrecy of the PCED TLV, then 
the operator must ensure that no private data is carried in the TLV, e.g. that 
key names do not reveal sensitive information about the network.

Tom Petch


Thanks,
        Yaron

On 8/10/21, 15:01, "Qin Wu"  wrote:

Yaron:
Thank for clarification. I agree to keep the last sentence in the 
second paragraph of section 7 as is.
But I prefer to add the addition references in the previous 
sentence as follows:
"
Thus before advertisement of the PCE security parameters, it MUST 
be insured that the IGP is
protected for authentication and integrity of the PCED TLV,, with 
the mechanisms defined in
[RFC5310] and [RFC5709] if the mechanism described in this document 
is used.

As stated in [RFC5088] and [RFC5089], the IGP do not provide 
encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP 
session less secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, because 
we should be focusing on integrity protection and not privacy (=secrecy) of the 
TLV. So I would prefer to keep the text as-is, with the addition of a reference 
to the IS-IS and OSPF security mechanisms that were discussed on this thread.

    Thanks,
Yaron

On 8/10/21, 05:00, "Qin Wu"  wrote:

Hi, Yaron
-邮件原件-
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu ; sec...@ietf.org
>抄送: 
draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-c...@ietf.org; 
lsr@ietf.org
>主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

>Hi Qin,

&g

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Thanks Acee and Tom for good suggestion, we will take them into account.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月12日 1:18
收件人: tom petch ; Yaron Sheffer ; 
Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

I'd also recommend changing, "key names" to "key-ids or key-chain names" since 
this is what is actually being advertised.
Thanks,
Acee

On 8/10/21, 11:53 AM, "tom petch"  wrote:

From: Lsr  on behalf of Yaron Sheffer 

Sent: 10 August 2021 14:57

So let me suggest:


An offlist suggestion for you to consider

OLD
Thus before advertisement of the PCE security parameters, it MUST be 
insured that the IGP protects the authentication and integrity of the PCED TLV 
using the mechanisms defined in
[RFC5310] and [RFC5709], if the mechanism described in this document is 
used.

Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide 
any encryption mechanisms to protect the secrecy of the PCED TLV, and the 
operator must ensure that no private data is carried in the TLV, for example 
that key names do not reveal sensitive information about the network.

NEW

 Thus before advertising the PCE security parameters, using the mechanism 
described in this document, the IGP MUST be known to provide authentication and 
integrity for the PCED TLV using the mechanisms defined in  [RFC5304],  
[RFC5310] or [RFC5709],

Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does not 
provide any encryption mechanisms to protect the secrecy of the PCED TLV, then 
the operator must ensure that no private data is carried in the TLV, e.g. that 
key names do not reveal sensitive information about the network.

Tom Petch


Thanks,
    Yaron

On 8/10/21, 15:01, "Qin Wu"  wrote:

Yaron:
Thank for clarification. I agree to keep the last sentence in the 
second paragraph of section 7 as is.
But I prefer to add the addition references in the previous sentence as 
follows:
"
Thus before advertisement of the PCE security parameters, it MUST be 
insured that the IGP is
protected for authentication and integrity of the PCED TLV,, with the 
mechanisms defined in
[RFC5310] and [RFC5709] if the mechanism described in this document is 
used.

As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption 
mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP 
session less secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, because we 
should be focusing on integrity protection and not privacy (=secrecy) of the 
TLV. So I would prefer to keep the text as-is, with the addition of a reference 
to the IS-IS and OSPF security mechanisms that were discussed on this thread.

Thanks,
Yaron

On 8/10/21, 05:00, "Qin Wu"  wrote:

Hi, Yaron
-邮件原件-
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu ; sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
>主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

>Hi Qin,

>Thank you for your response.

>* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 
5304 still uses HMAC-MD5, which would be considered insecure nowadays.
>* RFC 2154 is very old and Experimental (and only supports RSA-MD5 
signatures). I'm not an OSPF expert by any means, but I'm willing to bet that 
there are no production implementations of this RFC. (I'm willing to be proven 
wrong).
>Is there another RFC that define a protection mechanism for OSPF?

>All in all, there appear to be no good options for the IGP.

[Qin Wu]Yes, we do have alternatives, see Les's response in the 
separate email
"
On 8/9/21, 23:36,"Les Ginsberg (ginsberg)"  
wrote:
For IS-IS security please also see RFC 5310.
For OSPF security please see RFC 57

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Agree, thanks Les for additional suggestions.
发件人： Les Ginsberg (ginsberg)mailto:ginsb...@cisco.com>>
收件人： Qin Wumailto:bill...@huawei.com>>;Yaron 
Sheffermailto:yaronf.i...@gmail.com>>;secdirmailto:sec...@ietf.org>>
抄送： 
draft-ietf-lsr-pce-discovery-security-support.allmailto:draft-ietf-lsr-pce-discovery-security-support@ietf.org>>;last-callmailto:last-c...@ietf.org>>;lsrmailto:lsr@ietf.org>>
主题： RE: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05
时间： 2021-08-10 22:47:05

Qin -

Just to note that RFC 5310 does NOT replace or obsolete RFC 5304. Both RFC 's 
have their uses.
Please be sure to reference both RFCs in your updated text.

Thanx.

   Les


> -Original Message-
> From: Qin Wu 
> Sent: Monday, August 9, 2021 6:13 PM
> To: Les Ginsberg (ginsberg) ; Yaron Sheffer
> ; sec...@ietf.org
> Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-
> c...@ietf.org; lsr@ietf.org
> Subject: RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security-
> support-05
>
> Thanks Les for the pointer, I was looking into RFC6863 in KARP WG and found
> RFC5709 for OSPF security as well.
> Yes, I agree to use RFC5310 to replace RFC5304 for IS-IS security.
>
> Regarding the debate about MUST vs SHOULD, thanks for clarification. yes,
> whether to choose IGP advertisement is implementation specific. Operator
> will make their choice.
> So I think I tend to agree to use SHOULD for client behavior. Thanks.
>
> -Qin
> -邮件原件-----
> 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> 发送时间: 2021年8月9日 23:36
> 收件人: Yaron Sheffer ; Qin Wu
> ; sec...@ietf.org
> 抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-
> c...@ietf.org; lsr@ietf.org
> 主题: RE: Secdir last call review of draft-ietf-lsr-pce-discovery-security-
> support-05
>
> Yaron/Qin -
>
> For IS-IS security please also see RFC 5310.
> For OSPF security please see RFC 5709.
>
> Regarding the debate about MUST vs SHOULD, as I see it advertisement of
> this information is an option. The IGP might not have access to this
> information in a given implementation/deployment - and I can easily imagine
> that some customers might prefer NOT to advertise this information in an
> IGP even if it were available.
>
> It is useful to check the wording used in https://www.rfc-
> editor.org/rfc/rfc5089.html#section-4 . There, those sub-TLVs which are
> necessary for the PCED sub-TLV to be useful at all are required - but other
> sub-TLVs are optional. I think these new sub-TLVs fall into the latter 
> category.
>
>Les
>
> > -Original Message-
> > From: Lsr  On Behalf Of Yaron Sheffer
> > Sent: Monday, August 9, 2021 6:44 AM
> > To: Qin Wu ; sec...@ietf.org
> > Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last-
> > c...@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Secdir last call review of
> > draft-ietf-lsr-pce-discovery-
> > security-support-05
> >
> > Hi Qin,
> >
> > Thank you for your response.
> >
> > * RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC
> > 5304 still uses HMAC-MD5, which would be considered insecure nowadays.
> > * RFC 2154 is very old and Experimental (and only supports RSA-MD5
> > signatures). I'm not an OSPF expert by any means, but I'm willing to
> > bet that there are no production implementations of this RFC. (I'm
> > willing to be proven wrong). Is there another RFC that defines a
> > protection mechanism for OSPF?
> >
> > All in all, there appear to be no good options for the IGP.
> >
> > To your last point, when I mentioned decoupling the mechanisms, I was
> > suggesting to use the extension you define even if the IGP *cannot* be
> > secured. If you think this is reasonable, please add such text to the
> > Security Considerations.
> >
> > Thanks,
> >  Yaron
> >
> > On 8/9/21, 16:09, "Qin Wu"  wrote:
> >
> > Thanks Yaron for valuable comments, please see my reply inline below.
> > -邮件原件-
> > >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org]
> > >发送时间: 2021年8月6日 3:25
> > >收件人: sec...@ietf.org
> > >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org;
> > last- c...@ietf.org; lsr@ietf.org
> > >主题: Secdir last call review of
> > draft-ietf-lsr-pce-discovery-security-
> > support-05
> >
> > >Reviewer: Yaron Sheffer
> > >Review result: Not Ready
> >
> > >This document defines a mechanism (a TLV) to advertise the PCE
> 

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

The proposed change sounds good to me, Thanks Yaron.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
发送时间: 2021年8月10日 21:58
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

So let me suggest:

Thus before advertisement of the PCE security parameters, it MUST be 
insured that the IGP protects the authentication and integrity of the PCED TLV 
using the mechanisms defined in 
[RFC5310] and [RFC5709], if the mechanism described in this document is 
used. 

Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not provide any 
encryption mechanisms to protect the secrecy of the PCED TLV, and the operator 
must ensure that no private data is carried in the TLV, for example that key 
names do not reveal sensitive information about the network.

Thanks,
Yaron

On 8/10/21, 15:01, "Qin Wu"  wrote:

Yaron:
Thank for clarification. I agree to keep the last sentence in the second 
paragraph of section 7 as is.
But I prefer to add the addition references in the previous sentence as 
follows:
"
Thus before advertisement of the PCE security parameters, it MUST be 
insured that the IGP is
protected for authentication and integrity of the PCED TLV,, with the 
mechanisms defined in 
[RFC5310] and [RFC5709] if the mechanism described in this document is 
used. 

As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption 
mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP session 
less secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, because we 
should be focusing on integrity protection and not privacy (=secrecy) of the 
TLV. So I would prefer to keep the text as-is, with the addition of a reference 
to the IS-IS and OSPF security mechanisms that were discussed on this thread.

Thanks,
Yaron

On 8/10/21, 05:00, "Qin Wu"  wrote:

Hi, Yaron
-邮件原件-
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu ; sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
>主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

>Hi Qin,

>Thank you for your response.

>* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 
5304 still uses HMAC-MD5, which would be considered insecure nowadays.
>* RFC 2154 is very old and Experimental (and only supports RSA-MD5 
signatures). I'm not an OSPF expert by any means, but I'm willing to bet that 
there are no production implementations of this RFC. (I'm willing to be proven 
wrong). 
>Is there another RFC that define a protection mechanism for OSPF?

    >All in all, there appear to be no good options for the IGP.

[Qin Wu]Yes, we do have alternatives, see Les's response in the 
separate email
"
On 8/9/21, 23:36,"Les Ginsberg (ginsberg)"  wrote:
For IS-IS security please also see RFC 5310.
For OSPF security please see RFC 5709.
"
>To your last point, when I mentioned decoupling the mechanisms, I was 
suggesting to use the extension you define even if the IGP *cannot* be secured. 
If you think this is reasonable, please add such text to the Security 
Considerations.

[Qin Wu] Okay, how about the following change
OLD TEXT:
"
As stated in [RFC5088]
and [RFC5089], the IGP do not provide encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP
session less secure then the operator should take that into 
consideration .
"
NEW TEXT:
"
As stated in [RFC5088]
and [RFC5089], the IGP do not provide encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP
session less secure then the operator should take that into 
consideration 
when getting the mechanism described in this document deployed.
"
 >Thanks,
 >  Yaron

>On 8/9/21, 16:09, "Qin Wu"  wrote:

  

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Yaron:
Thank for clarification. I agree to keep the last sentence in the second 
paragraph of section 7 as is.
But I prefer to add the addition references in the previous sentence as follows:
"
Thus before advertisement of the PCE security parameters, it MUST be insured 
that the IGP is
protected for authentication and integrity of the PCED TLV,, with the 
mechanisms defined in 
[RFC5310] and [RFC5709] if the mechanism described in this document is used. 

As stated in [RFC5088] and [RFC5089], the IGP do not provide encryption 
mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP session less 
secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, because we should 
be focusing on integrity protection and not privacy (=secrecy) of the TLV. So I 
would prefer to keep the text as-is, with the addition of a reference to the 
IS-IS and OSPF security mechanisms that were discussed on this thread.

Thanks,
Yaron

On 8/10/21, 05:00, "Qin Wu"  wrote:

Hi, Yaron
-邮件原件-
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu ; sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
>主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

>Hi Qin,

>Thank you for your response.

>* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 
still uses HMAC-MD5, which would be considered insecure nowadays.
>* RFC 2154 is very old and Experimental (and only supports RSA-MD5 
signatures). I'm not an OSPF expert by any means, but I'm willing to bet that 
there are no production implementations of this RFC. (I'm willing to be proven 
wrong). 
>Is there another RFC that define a protection mechanism for OSPF?

>All in all, there appear to be no good options for the IGP.

[Qin Wu]Yes, we do have alternatives, see Les's response in the separate 
email
"
On 8/9/21, 23:36,"Les Ginsberg (ginsberg)"  wrote:
For IS-IS security please also see RFC 5310.
For OSPF security please see RFC 5709.
"
>To your last point, when I mentioned decoupling the mechanisms, I was 
suggesting to use the extension you define even if the IGP *cannot* be secured. 
If you think this is reasonable, please add such text to the Security 
Considerations.

[Qin Wu] Okay, how about the following change
OLD TEXT:
"
As stated in [RFC5088]
and [RFC5089], the IGP do not provide encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP
session less secure then the operator should take that into consideration .
"
NEW TEXT:
"
As stated in [RFC5088]
and [RFC5089], the IGP do not provide encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP
session less secure then the operator should take that into consideration 
when getting the mechanism described in this document deployed.
"
 >Thanks,
 >  Yaron

>On 8/9/21, 16:09, "Qin Wu"  wrote:

  >   Thanks Yaron for valuable comments, please see my reply inline below.
-邮件原件-
>发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] 
>发送时间: 2021年8月6日 3:25
>收件人: sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
>主题: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

>Reviewer: Yaron Sheffer
>Review result: Not Ready

>This document defines a mechanism (a TLV) to advertise the PCE 
Protocol security required (use of TCP-AO and its key ID, or alternatively use 
of TLS) within the routing protocol being used.

>* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. 
Especially given the strict client behavior defined later.
[Qin]: I believe "SHOULD advertise" is consistent with client behavior 
defined later, i.e., we apply SHOULD NOT language to the client behavior.
I am not sure we should change it into strong language with MUST. Since 
if IGP advertisement doesn't include TCP-AO
 support flag bit or TLS support flag bit, NMS may fall back to 
configure both PCC and

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Qin Wu]

Hi, all:
I support adoption of both YANG related drafts.

-Qin
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, July 22, 2021 6:48 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
> 
> 
> Hi Folks,
> 
> This begins a 3 week WG Adoption Call for the following related YANG drafts:
> 
> https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
> https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/
> 
> Please indicate your support or objections by August 12th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Hi, Yaron
-邮件原件-
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu ; sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
>last-c...@ietf.org; lsr@ietf.org
>主题: Re: Secdir last call review of 
>draft-ietf-lsr-pce-discovery-security-support-05

>Hi Qin,

>Thank you for your response.

>* RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 5304 still 
>uses HMAC-MD5, which would be considered insecure nowadays.
>* RFC 2154 is very old and Experimental (and only supports RSA-MD5 
>signatures). I'm not an OSPF expert by any means, but I'm willing to bet that 
>there are no production implementations of this RFC. (I'm willing to be proven 
>wrong). 
>Is there another RFC that define a protection mechanism for OSPF?

>All in all, there appear to be no good options for the IGP.

[Qin Wu]Yes, we do have alternatives, see Les's response in the separate email
"
On 8/9/21, 23:36,"Les Ginsberg (ginsberg)"  wrote:
For IS-IS security please also see RFC 5310.
For OSPF security please see RFC 5709.
"
>To your last point, when I mentioned decoupling the mechanisms, I was 
>suggesting to use the extension you define even if the IGP *cannot* be 
>secured. If you think this is reasonable, please add such text to the Security 
>Considerations.

[Qin Wu] Okay, how about the following change
OLD TEXT:
"
As stated in [RFC5088]
and [RFC5089], the IGP do not provide encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP
session less secure then the operator should take that into consideration .
"
NEW TEXT:
"
As stated in [RFC5088]
and [RFC5089], the IGP do not provide encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the PCEP
session less secure then the operator should take that into consideration 
when getting the mechanism described in this document deployed.
"
 >Thanks,
 >  Yaron

>On 8/9/21, 16:09, "Qin Wu"  wrote:

  >   Thanks Yaron for valuable comments, please see my reply inline below.
-邮件原件-
>发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] 
>发送时间: 2021年8月6日 3:25
>收件人: sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
>主题: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

>Reviewer: Yaron Sheffer
>Review result: Not Ready

>This document defines a mechanism (a TLV) to advertise the PCE Protocol 
security required (use of TCP-AO and its key ID, or alternatively use of TLS) 
within the routing protocol being used.

>* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. 
Especially given the strict client behavior defined later.
[Qin]: I believe "SHOULD advertise" is consistent with client behavior 
defined later, i.e., we apply SHOULD NOT language to the client behavior.
I am not sure we should change it into strong language with MUST. Since if 
IGP advertisement doesn't include TCP-AO
 support flag bit or TLS support flag bit, NMS may fall back to configure 
both PCC and PCE server to support TCP-AO or TLS. That's one of reason I think 
why we choose to use SHOULD language.

>* Sec. 3.1: should we also say something about the case where both methods 
are advertised, and whether we recommend for the client to use one of them over 
the other?

[Qin]: It is up to local policy, which has bee clarified in the end of 
section 3.1. Hope this clarify.

>* Sec. 4: typo (appears twice) - "to be carried in the PCED TLV of the for 
use".

[Qin]:Thanks, have fixed them in the local copy.

>* Sec. 7: this phrase appears to be essential to security of this 
mechanism: "it MUST be insured that the IGP is protected for authentication and 
integrity of the PCED TLV". I would expect more guidance: how can this property 
be ensured in the relevant IGPs?
[Qin]:I think mechanism defined in [RFC3567] and [RFC2154] can be used to 
ensure authenticity and integrity of OSPF LSAs or ISIS LSPs and their TLVs. 
Here is the proposed changes:
OLD TEXT:
"
   Thus before advertisement of
   the PCE security parameters, it MUST be insured that the IGP is
   protected for authentication and integrity of the PCED TLV if the
   mechanism described in this document is used.
"
NEW TEXT:
"
   Thus before advertisement of
   the PCE security parameters, it MUST be insured that the IGP is
   protected for authentication and integrity of the PCED TLV with 
mechanisms defined in [RFC3567][RFC2154] if the
   mechanism described in this document is used.
"
>* Also, a possibly un

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Thanks Les for the pointer, I was looking into RFC6863 in KARP WG and found 
RFC5709 for OSPF security as well.
Yes, I agree to use RFC5310 to replace RFC5304 for IS-IS security.

Regarding the debate about MUST vs SHOULD, thanks for clarification. yes, 
whether to choose IGP advertisement is implementation specific. Operator will 
make their choice. 
So I think I tend to agree to use SHOULD for client behavior. Thanks.

-Qin
-邮件原件-
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
发送时间: 2021年8月9日 23:36
收件人: Yaron Sheffer ; Qin Wu ; 
sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: RE: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Yaron/Qin -

For IS-IS security please also see RFC 5310.
For OSPF security please see RFC 5709.

Regarding the debate about MUST vs SHOULD, as I see it advertisement of this 
information is an option. The IGP might not have access to this information in 
a given implementation/deployment - and I can easily imagine that some 
customers might prefer NOT to advertise this information in an IGP even if it 
were available.

It is useful to check the wording used in 
https://www.rfc-editor.org/rfc/rfc5089.html#section-4 . There, those sub-TLVs 
which are necessary for the PCED sub-TLV to be useful at all are required - but 
other sub-TLVs are optional. I think these new sub-TLVs fall into the latter 
category.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Yaron Sheffer
> Sent: Monday, August 9, 2021 6:44 AM
> To: Qin Wu ; sec...@ietf.org
> Cc: draft-ietf-lsr-pce-discovery-security-support@ietf.org; last- 
> c...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Secdir last call review of 
> draft-ietf-lsr-pce-discovery-
> security-support-05
> 
> Hi Qin,
> 
> Thank you for your response.
> 
> * RFC 3567 (for IS-IS) is obsoleted by RFC 5304. Unfortunately RFC 
> 5304 still uses HMAC-MD5, which would be considered insecure nowadays.
> * RFC 2154 is very old and Experimental (and only supports RSA-MD5 
> signatures). I'm not an OSPF expert by any means, but I'm willing to 
> bet that there are no production implementations of this RFC. (I'm 
> willing to be proven wrong). Is there another RFC that defines a 
> protection mechanism for OSPF?
> 
> All in all, there appear to be no good options for the IGP.
> 
> To your last point, when I mentioned decoupling the mechanisms, I was 
> suggesting to use the extension you define even if the IGP *cannot* be 
> secured. If you think this is reasonable, please add such text to the 
> Security Considerations.
> 
> Thanks,
>   Yaron
> 
> On 8/9/21, 16:09, "Qin Wu"  wrote:
> 
> Thanks Yaron for valuable comments, please see my reply inline below.
> -邮件原件-
> >发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org]
> >发送时间: 2021年8月6日 3:25
> >收件人: sec...@ietf.org
> >抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
> last- c...@ietf.org; lsr@ietf.org
> >主题: Secdir last call review of 
> draft-ietf-lsr-pce-discovery-security-
> support-05
> 
> >Reviewer: Yaron Sheffer
> >Review result: Not Ready
> 
> >This document defines a mechanism (a TLV) to advertise the PCE 
> Protocol security required (use of TCP-AO and its key ID, or 
> alternatively use of TLS) within the routing protocol being used.
> 
> >* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST.
> Especially given the strict client behavior defined later.
> [Qin]: I believe "SHOULD advertise" is consistent with client 
> behavior defined later, i.e., we apply SHOULD NOT language to the client 
> behavior.
> I am not sure we should change it into strong language with MUST. 
> Since if IGP advertisement doesn't include TCP-AO
>  support flag bit or TLS support flag bit, NMS may fall back to 
> configure both PCC and PCE server to support TCP-AO or TLS. That's one 
> of reason I think why we choose to use SHOULD language.
> 
> >* Sec. 3.1: should we also say something about the case where 
> both methods are advertised, and whether we recommend for the client 
> to use one of them over the other?
> 
> [Qin]: It is up to local policy, which has bee clarified in the 
> end of section 3.1. Hope this clarify.
> 
> >* Sec. 4: typo (appears twice) - "to be carried in the PCED TLV 
> of the for use".
> 
> [Qin]:Thanks, have fixed them in the local copy.
> 
> >* Sec. 7: this phrase appears to be essential to security of this 
> mechanism:
> "it MUST be insured that the IGP is protected for authentication and 
>

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Thanks Yaron for valuable comments, please see my reply inline below.
-邮件原件-
>发件人: Yaron Sheffer via Datatracker [mailto:nore...@ietf.org] 
>发送时间: 2021年8月6日 3:25
>收件人: sec...@ietf.org
>抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
>last-c...@ietf.org; lsr@ietf.org
>主题: Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

>Reviewer: Yaron Sheffer
>Review result: Not Ready

>This document defines a mechanism (a TLV) to advertise the PCE Protocol 
>security required (use of TCP-AO and its key ID, or alternatively use of TLS) 
>within the routing protocol being used.

>* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. Especially 
>given the strict client behavior defined later.
[Qin]: I believe "SHOULD advertise" is consistent with client behavior defined 
later, i.e., we apply SHOULD NOT language to the client behavior.
I am not sure we should change it into strong language with MUST. Since if IGP 
advertisement doesn't include TCP-AO
 support flag bit or TLS support flag bit, NMS may fall back to configure both 
PCC and PCE server to support TCP-AO or TLS. That's one of reason I think why 
we choose to use SHOULD language.

>* Sec. 3.1: should we also say something about the case where both methods are 
>advertised, and whether we recommend for the client to use one of them over 
>the other?

[Qin]: It is up to local policy, which has bee clarified in the end of section 
3.1. Hope this clarify.

>* Sec. 4: typo (appears twice) - "to be carried in the PCED TLV of the for 
>use".

[Qin]:Thanks, have fixed them in the local copy.

>* Sec. 7: this phrase appears to be essential to security of this mechanism: 
>"it MUST be insured that the IGP is protected for authentication and integrity 
>of the PCED TLV". I would expect more guidance: how can this property be 
>ensured in the relevant IGPs?
[Qin]:I think mechanism defined in [RFC3567] and [RFC2154] can be used to 
ensure authenticity and integrity of OSPF LSAs or ISIS LSPs and their TLVs. 
Here is the proposed changes:
OLD TEXT:
"
   Thus before advertisement of
   the PCE security parameters, it MUST be insured that the IGP is
   protected for authentication and integrity of the PCED TLV if the
   mechanism described in this document is used.
"
NEW TEXT:
"
   Thus before advertisement of
   the PCE security parameters, it MUST be insured that the IGP is
   protected for authentication and integrity of the PCED TLV with mechanisms 
defined in [RFC3567][RFC2154] if the
   mechanism described in this document is used.
"
>* Also, a possibly unintended consequence of this requirement is that if the 
>IGP cannot be protected in a particular deployment/product, this mechanism 
>would not be used. Please consider if this is likely to happen and whether we 
>want to forego PCEP transport >security in such cases. My gut feel (not based 
>on experience in such networks) is that the threat models are different enough 
>that we should decouple the security of IGP from that of PCEP.

[Qin] I agree IGP security should be separated from PCEP security. IGP 
extension defined in this document is used by the PCC to select PCE server with 
appropriate security mechanism. On the other hand, Operator can either use IGP 
advertisement for PCEP security capability or rely on local policy to select 
PCE. If operator feels IGP advertisement is not secure, he can fall back to 
local policy or rely on manual configuration. Hope this clarifies.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Hi, Acee
Thanks for valuable comments, see reply inline below.

发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2021年7月22日 23:11
收件人: Acee Lindem (acee) ; lsr@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
主题: Re: [Lsr] WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Speaking as a WG member, I support publication.

I only have one functional comment and that is on Appendix A. Note that a 
key-chain or key-id would be useful for MD5 as well as TLS and TCP-AO. I’m not 
suggesting that you add MD5 since it is historic but support of MD5 as 
specified in RFC 5440 would require configuration of the same key or key-chain 
on the PCC and PCE server.
[Qin]: Good comment, I think we can add one statement at the end of the 
paragraph to say:
“
Irrespective of which security capability support is selected, the same key or 
key-chain on the PCC and PCE server should be configured.
”

I also have some editorial comments that you can decide whether or not to 
apply. Of note are that I don’t think you need to say “looking for connecting 
with a” and can simply say “looking for a”. Also, once this document is 
published the capability bits and sub-TLVs are not longer “new”.

See full set of editorial comments in attached RFC diff.
[Qin]: I agree with the most of comments and will incorporate them in.
One little tweak or fallback is s/ capability flag bit in the PCE-CAP-FLAGS 
sub-TLV in IS-IS is set to/ capability flag bit of PCE-CAP-FLAGS sub-TLV in 
IS-IS is set to
I think the original text is more clear here, using two ‘in’ is a little bit 
verbose in my view.
Thanks,
Acee


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Wednesday, July 21, 2021 at 12:46 PM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>
Subject: [Lsr] WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

This begins a 3-week WG Last Call, ending on August 4th, 2021, for 
draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or 
objection to this list before the end of the WG last call. The longer WG last 
call is to account for IETF week.

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


Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call IPR Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Hi Acee:
I am not aware of any other IPR that applies to 
draft-ietf-lsr-pce-discovery-security-support besides the one that has already 
been disclosed.

-Qin
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2021年7月22日 0:37
收件人: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
抄送: lsr@ietf.org
主题: WG Last Call IPR Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

The following IPR has been filed for 
draft-ietf-lsr-pce-discovery-security-support:

https://datatracker.ietf.org/ipr/3351/

Are you aware of any other IPR that applies to 
draft-ietf-lsr-pce-discovery-security-support?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Qin Wu]

Hi,
I have read this draft and It is well written and I support adoption of this 
work.
Here are a few comments and suggestions:

1.   What is VTN resource, how do we define network resource, is the 
resource

a.   the label that is switched on the path of the LSP,

b.   is the resource physical resource assigned to LSP?

c.   Is the resource a measure of the capacity of a link that is dedicated 
for use by the traffic on the LSP.

d.   Is the resource referred to node or link in the network topology?

Would it be great to provide VTN resource definition in the terminology section,

In addition, I also recommend you to reference RFC8413 for resource definition.



2.   Section 2 said:

“

The MT-specific Link or Prefix TLVs are defined by

   adding additional two bytes, which includes 12-bit MT-ID field in

   front of the ISN TLV and IP or IPv6 Reachability TLVs.

”
Does this require protocol extension? Are these two bytes reserved fields?  
Where MT-ID is defined? In which RFC?
Also ISN TLV, IP/Ipv6 Reachablity TLV, where these TLVS are defined? Please 
provide references.


-Qin Wu
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2021年3月3日 7:28
收件人: lsr@ietf.org
主题: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Qin Wu]

Support this work.

-Qin
发件人: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2020年5月16日 3:40
收件人: lsr@ietf.org
主题: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Qin Wu]

v-03 is posted to address additional comments from Les
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-03
Thanks Les for proposed change.

-Qin
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 internet-dra...@ietf.org
发送时间: 2019年11月1日 14:24
收件人: i-d-annou...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-03.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-03.txt
Pages   : 9
Date: 2019-10-31

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-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-03


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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Qin Wu]

Les:
-邮件原件-
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
发送时间: 2019年9月30日 12:34
收件人: Qin Wu ; lsr@ietf.org
主题: 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  On Behalf Of Qin Wu
> Sent: Tuesday, September 03, 2019 4:03 AM
> To: lsr@ietf.org
> 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:i-d-announce-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> 发送时间: 2019年9月3日 18:58
> 收件人: i-d-annou...@ietf.org
> 抄送: lsr@ietf.org
> 主题: 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 al

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

[Qin Wu]

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-security-support-02

-Qin
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2019年9月3日 18:58
收件人: i-d-annou...@ietf.org
抄送: lsr@ietf.org
主题: 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-support-02
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-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
i-d-annou...@ietf.org
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Solicit feedback on draft-ietf-lsr-pce-discovery-security-support-01

[Qin Wu]

Thanks Adrian for a proposed way forward, Aijun has already made a response to 
this email in the LSR ML before IETF105.
I also agree with comments and suggested changes you made below.
I will update the draft based on your comments on section 4 and section 7. 
Thanks again!

-Qin
-邮件原件-
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk] 
发送时间: 2019年8月21日 0:40
收件人: Qin Wu ; p...@ietf.org; lsr@ietf.org
主题: RE: [Lsr] Solicit feedback on 
draft-ietf-lsr-pce-discovery-security-support-01

Hi Qin,

I didn't see any response to this email, so I thought I should chip in with 
some (old, old, old) memories and context.

tl;dr I am generally supportive of this work, but I think a little fine-tuning 
is needed.

If I recall correctly, the situation when 5088 and 5089 were produced was that 
there was mission creep. The initial idea was to discover the existence of 
PCE-capable routers in the network, but it was quickly realised a specific 
address might be preferable for reaching the PCE, so there was need for the PCE 
Discovery TLV to contain an address, and it was decided to encode it as a TLV. 
Then the rot set in and we determined there were some other useful pieces of 
information to encode. And then we thought that it would be helpful to have an 
array of capability bits.

At this point the IGP working groups started to get worried. As Les and Acee 
noted, the concern was that we would be carrying "large" amounts of data in the 
IGP that was not directly related to the primary purpose of the IGP (packet 
routing) or even the secondary purpose (TE). We had a bit of a fight on our 
hands at this stage because the PCE implementers had already built stuff, and 
the IGP "purists" were digging in. So we agreed to stabilise with "this far and 
no further" and the lines in 5088/9 that say:
   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.
The idea was that it would be OK to define new capability bits, but not to add 
more TLVs.

I don't recall being delighted by this outcome at the time, but it certainly 
allowed us to move forward. It seemed to me that PCEs were not the only devices 
exchanging non-routing information in the IGP, and if there was a concern about 
volume of data or convergence time, then this seemed a bigger problem that 
needed a more general resolution. On the other hand, IETF consensus is what it 
is.

The approach that others have taken in this situation is to add flags as 
needed, but to put the additional discovery information in the PCEP Open 
message. Thus, at a high level, a PCC can decide whether there is any point in 
opening a PCEP session with a PCE, but may have to try the session to find out 
exactly what options are available and might, at that time, discover that the 
PCE is not suitable.

Looking at your draft, the addition of the two bit flags is easy and 
uncontroversial. 

It is the addition of the Key-ID and Key-Chain-Name sub-TLVs that cause you to 
want to change the RFCs. And I think you have a special case here because using 
the TCP security mechanism, the PCEP Open message would come too late to 
exchange the relevant information. That is, you need the security information 
to set up the secure TCP session before the PCEP Open messages can be exchanged.

This point could usefully be made more clear in the document. That is, why you 
cannot use the alternate mechanism for exchanging PCE characteristics and 
capabilities. After that has been done, I think that it would be reasonable to 
allow the approach you are describing subject to LSR WG consensus. (The 
alternative, which is perfectly acceptable within the architecture and within 
some operational environments, is configuration. But configuration doesn't work 
in the larger use cases, and another mechanism would constitute a third way of 
exchanging PCE information, and that sounds
ridiculous.)

However, while I think that you should be allowed through the doorway, I don't 
think you should leave the door open behind you. That means that you should 
update 5088/9 to allow your new sub-TLVs, but you should leave in place the 
ruling that no more new sub-TLVs are allowed. I *think* that is what you're 
trying to do, but I don't think your Section 4 is the right way to do that - it 
is not necessary to make edits to the old documents to make this change, you 
can simply say... 
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 RFC 5088 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 Information 
LSA.
Section 4 of [RFC5089] states that no new sub-TLVs will be added to the PCED 
TLV, and no

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

[Qin Wu]

Thanks Les for summary for the current status, will keep on pinging feedback 
from PCE WG.

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

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: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
> Cc: lsr@ietf.org; Les Ginsberg (ginsberg) 
> 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)"  boun...@ietf.org on behalf of ginsb...@cisco.com> 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  On Behalf Of internet-dra...@ietf.org
> > Sent: Sunday, June 02, 2019 8:45 PM
> > To: i-d-annou...@ietf.org
> > Cc: lsr@ietf.org
> > 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
>   

Re: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[Qin Wu]

I think what they are looking for in RFC7950 is generic overridden rule, i.e., 
a parent node statement can be overridden by its child node substatement.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2019年6月9日 23:28
收件人: Xufeng Liu 
抄送: lsr@ietf.org; NETMOD WG 
主题: Re: [netmod] A question on the parameter overriding in 
draft-ietf-isis-yang-isis-cfg

Hi,

YANG does not have 'levels'. This seems to be an ISIS specific question you 
should ask on the ISIS list.

/js

On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
> In Section 2.3. and many other locations, the current IS-IS model 
> applies the parameter overriding rule as below:
> 
> [Quote]:
> 
> 2.3 
> .
> Per-Level Parameters
> 
> 
>Some parameters allow a per level configuration.  In this case, the
>parameter is modeled as a container with three configuration
>locations:
> 
>o  a top-level container: corresponds to level-1-2, so the
>   configuration applies to both levels.
> 
>o  a level-1 container: corresponds to level-1 specific parameters.
> 
>o  a level-2 container: corresponds to level-2 specific parameters.
> 
>+--rw priority
>|  +--rw value? uint8
>|  +--rw level-1
>|  |  +--rw value?   uint8
>|  +--rw level-2
>| +--rw value?   uint8
> 
>Example:
> 
>
>250
>
>100
>
>
>200
>
>
> 
>An implementation SHOULD prefer a level specific parameter over a
>level-all parameter.  As example, if the priority is 100 for the
>level-1, 200 for the level-2 and 250 for the top-level configuration,
>the implementation should use 100 for the level-1 and 200 for the
>level-2.
> 
> [End of Quote]
> 
> 
> In the model, all three value leaves above have a default statement 
> “default 64”, which brings up my question for the following example:
> 
> 
>
>250
>
>100
>
>
> 
> 
> The user does not provide a configured value for level-2. According to 
> Section 7.6.1. of RFC7950, because the default value is in use, “the 
> server MUST operationally behave as if the leaf was present in the 
> data tree with the default value as its value”. This means the 
> priority value for level-2 will be 64 (the default value), so the 
> value 250 can never take effect as intended in the above quoted Section 2.3.
> 
> 
> Is my understanding correct?
> 
> 
> Since this is a generic question, I am CC’ing NETMOD WG too.
> 
> 
> Thanks,
> 
> - Xufeng

> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Solicit feeback on draft-ietf-lsr-pce-discovery-security-support-01

[Qin Wu]

Hi, Folks:
Draft-ietf-lsr-pce-discovery-security-support was adopted by LSR WG in December 
2018 due to security importance for routing protocol.
Julien shared his comments and also help look for comments and feedback from 
PCE WG on this draft during poll adoption call in LSR WG.
Recently we made a quick update to 
draft-ietf-lsr-pce-discovery-security-support without technical content changes.
We would like to solicit comments and feedback again on this draft. Thanks in 
advance!

-Qin
> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, June 02, 2019 8:45 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> 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-supp
> ort-01
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-sec
> urity-
> support-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-securit
> y-
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Qin Wu]

Hi, Les:
-邮件原件-
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
发送时间: 2019年6月3日 22:54
收件人: Qin Wu ; lsr@ietf.org
主题: RE: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt

Qin -

Thanx for the prompt response.
Responses inline.

> -Original Message-
> From: Qin Wu 
> Sent: Monday, June 03, 2019 5:09 AM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: [Lsr] I-D Action: 
> draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
> 
> Hi, Les:
> Thanks for your comments, see my reply inline.
> -邮件原件-
> 发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
> 发送时间: 2019年6月3日 14:22
> 收件人: lsr@ietf.org
> 主题: Re: [Lsr] I-D Action: 
> draft-ietf-lsr-pce-discovery-security-support-01.txt
> 
> 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??
> 
> Due to low priority of this work in PCE and heavy agenda when we 
> proceeded this work earlier in PCE, we made very little progress.
> This has been a little bit changed during adoption call and we authors 
> were also active in both PCE and LSR WG see the following link:
> https://mailarchive.ietf.org/arch/msg/lsr/wVZ7iELBEqYzvnKwdRR8MNoN6zQ
> 

[Les:] Yes - I had noted Julien's post in my search of the archives. But he was 
making comments as an individual on the content of the draft. I do not see that 
he was making any comment regarding the position of the PCE WG.
I am wondering if in the intervening 6 months the PCE WG has taken a position 
on this.
[Qin]: I will send an email to PCE to get feedback on this draft in a separate 
email.

> 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.
> [Qin]: It seems your argument also applies to RFC5088/5089.


[Les:] Indeed - which is why the limitation of "this much and no more" was put 
into RFC 5088/5089.

[Qin]:I think it is useful to carry such PCED info via IGP for discovery when 
PCEP session hasn't been setup.
I am not sure this is limitation or we should prevent this.
> 
> 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.
> [Qin]: Sure, but RFC5088/89 has already provide way to carry additional info.
> We could use some other out-band mechanism to carry additional info 
> beyond PCED sub-TLVs defined in RFC5088/89, but do you think 1. use 
> one protocol to convey all information needed 2. use two protocol to 
> convey information separately Which one is optimal?

[Les:] What are you going to do when the PCE is not also an LSR?
My concern is two fold:

1)That we further use the IGPs to carry non-IGP information.
(Again - this would not be the first time - but we should do this carefully.)
[Qin]: I believe you raise a generic topic, not limited to this draft, my point 
we should case by case.
2)That in cases where the PCE is NOT an LSR this extension would be of no use - 
so it seems you will have to define an alternate means of signaling this info 
anyway.
[Qin]: Key-ID and Key Chain Name piggybacked via PCED sub TLV is really generic 
information. I feel carrying them via PCED sub TLV is a better way, in my 
opinion.
> 
> 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.
> [Qin]: We don't' have too many changes going to RFC5088/89, so it is 
> expense to make bis document, it is cheaper to leverage RFC updates attribute 
> tool.

[Les:] Given that the draft contradic

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

[Qin Wu]

Hi, Les:
Thanks for your comments, see my reply inline.
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2019年6月3日 14:22
收件人: lsr@ietf.org
主题: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt

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??

Due to low priority of this work in PCE and heavy agenda when we proceeded this 
work earlier in PCE, we made very little progress.
This has been a little bit changed during adoption call and we authors were 
also active in both PCE and LSR WG
see the following link:
https://mailarchive.ietf.org/arch/msg/lsr/wVZ7iELBEqYzvnKwdRR8MNoN6zQ

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.
[Qin]: It seems your argument also applies to RFC5088/5089.

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.
[Qin]: Sure, but RFC5088/89 has already provide way to carry additional info. 
We could use some other out-band mechanism to carry additional info beyond PCED 
sub-TLVs defined in RFC5088/89, but do you think
1. use one protocol to convey all information needed
2. use two protocol to convey information separately
Which one is optimal?

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.
[Qin]: We don't' have too many changes going to RFC5088/89, so it is expense to 
make bis document, it is cheaper to leverage RFC updates attribute tool.
And, BTW, do you know why the HTML version of the document has no table of 
contents?
[Qin]:It is weird, seems we are using wrong boilerplate, I will see how to fix 
this.

   Les


> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, June 02, 2019 8:45 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> 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.
> 

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

[Qin Wu]

v-01 has just been posted to address received comments so far.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-wu-lsr-pce-discovery-security-support-01

-Qin
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2018年11月29日 14:29
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-wu-lsr-pce-discovery-security-support-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


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-wu-lsr-pce-discovery-security-support-01.txt
Pages   : 10
Date: 2018-11-28

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-wu-lsr-pce-discovery-security-support/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-01
https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wu-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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-isis-rfc5306bis-00 - Restart Signaling for IS-IS

[Qin Wu]

Support.

-Qin
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2018年11月20日 6:22
收件人: lsr@ietf.org
主题: [Lsr] Working Group Last Call for draft-ietf-lsr-isis-rfc5306bis-00 - 
Restart Signaling for IS-IS

The begins a Working Group Last Call for the subject document. Please post for 
review comments and/or support/objection to this document before 12:00 AM UTC 
on Tuesday, December 4th, 2018.

Other than some RFC boiler plate changes, the RFC 5306 BIS document really only 
adds the PR/PA bit handling in section 2.2.3 and the addition of the Planned 
Restart State to sections 3.1 and 3.2.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Qin Wu]

I am happy to update RFC5088 and RFC5089 to allow advertisement of additional 
PCE information carried in the Router Capability TLV if this is the agreement.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年11月16日 21:18
收件人: Qin Wu; julien.meu...@orange.com; lsr@ietf.org
抄送: p...@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

Hi Qin, 

This was at a time when there were concerns about advertising non-IGP specific 
information in OSPF(v3) Router Information LSAs. We've since assuaged our 
concerns with RFC 7770 where I added the functionality  of advertising multiple 
instances of the OSPF(v3) Router Information LSA. Note that this new draft 
should update both RFC 5088 and RFC 5089. 

Thanks,
Acee 

On 11/16/18, 12:01 AM, "Qin Wu"  wrote:

Working on this. Try to figure out how to carry key name in PCED sub-TLV. 
It looks RFC5088 and RFC5089 doesn't allow add additional sub-TLVs.
"
RFC5088
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.

RFC5089
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 IS-IS, this will not be carried in the CAPABILITY TLV.
"
The reason behind was clarified here:
https://mailarchive.ietf.org/arch/msg/pce/cR7e1SZ_DyUyY14OkfWbCc94paU
I am wondering whether there is any other key information exchange that 
might be happening during discovery mechanism.
Depending on the answer, we have three options:
1) Update RFC5088 and RFC 5089 to allow additional sub-TLVs to be added to 
the PCEP TLV.
2) carry key name using GENINFO TLV of RFC 6823
3) Carry key name during PCEP session establishment phase instead of 
discovery phase.

-Qin
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2018年11月15日 23:18
收件人: julien.meu...@orange.com; lsr@ietf.org
抄送: p...@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security 
capability support in the PCE discovery - 
draft-wu-lsr-pce-discovery-security-support-00

Authors, 
Please note that you need not wait until the end of the adoption poll to 
address my comment and Julien's comments. 
Thanks,
Acee 

On 11/15/18, 10:02 AM, "Lsr on behalf of julien.meu...@orange.com" 
 wrote:

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to
highlight some of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is
only mentioned in the introduction): the discussed mechanism has been
used multiple times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a
given specification in multiples places brings no value but may create
discrepancies, please stick to the references to the aforementioned 
RFCs;
- Section 3 tries to list the existing flag allocations: these are
inaccurate (e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete
(e.g. RFC 8231 is missing) and inappropriate (this is the role of the
IANA registry, not of every new I-D!);
- Contrary to the written text, the I-D does not "extend" anything, it
requests bit allocation from an existing registry; the IANA section (7)
is thus key: please make it point to the relevant registry, namely "PCE
Capability Flags" managed within the "OSPFv2 Parameters"

(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior
> to that time. 



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme 
ou 

Re: [Lsr] IPR Poll for "IGP extension for PCEP security capability support in the PCE discovery" (Corrected)

[Qin Wu]

It seems there was one relevant IPR
https://patents.google.com/patent/US8127129B2/en
but I am not sure it is applicable. I will consult with our IPR people to check 
on this.

-Qin
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2018年11月16日 11:59
收件人: draft-wu-lsr-pce-discovery-security-support
抄送: lsr@ietf.org; p...@ietf.org
主题: Re: [Lsr] IPR Poll for "IGP extension for PCEP security capability support 
in the PCE discovery" (Corrected)

Authors – Reminder that you need to explicitly reply to this poll.

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem mailto:a...@cisco.com>>
Date: Wednesday, November 14, 2018 at 3:02 PM
To: draft-wu-lsr-pce-discovery-security-support 
mailto:draft-wu-lsr-pce-discovery-security-supp...@ietf.org>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] IPR Poll for "IGP extension for PCEP security capability support 
in the PCE discovery" (Corrected)

Authors,

Are you aware of any IPR that applies to 
draft-wu-lsr-pce-discovery-security-support?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are currently no IPR disclosures against 
draft-wu-lsr-pce-discovery-security-support.

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing list. The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Qin Wu]

Working on this. Try to figure out how to carry key name in PCED sub-TLV. It 
looks RFC5088 and RFC5089 doesn't allow add additional sub-TLVs.
"
RFC5088
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.

RFC5089
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 IS-IS, this will not be carried in the CAPABILITY TLV.
"
The reason behind was clarified here:
https://mailarchive.ietf.org/arch/msg/pce/cR7e1SZ_DyUyY14OkfWbCc94paU
I am wondering whether there is any other key information exchange that might 
be happening during discovery mechanism.
Depending on the answer, we have three options:
1) Update RFC5088 and RFC 5089 to allow additional sub-TLVs to be added to the 
PCEP TLV.
2) carry key name using GENINFO TLV of RFC 6823
3) Carry key name during PCEP session establishment phase instead of discovery 
phase.

-Qin
-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2018年11月15日 23:18
收件人: julien.meu...@orange.com; lsr@ietf.org
抄送: p...@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

Authors, 
Please note that you need not wait until the end of the adoption poll to 
address my comment and Julien's comments. 
Thanks,
Acee 

On 11/15/18, 10:02 AM, "Lsr on behalf of julien.meu...@orange.com" 
 wrote:

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to
highlight some of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is
only mentioned in the introduction): the discussed mechanism has been
used multiple times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a
given specification in multiples places brings no value but may create
discrepancies, please stick to the references to the aforementioned RFCs;
- Section 3 tries to list the existing flag allocations: these are
inaccurate (e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete
(e.g. RFC 8231 is missing) and inappropriate (this is the role of the
IANA registry, not of every new I-D!);
- Contrary to the written text, the I-D does not "extend" anything, it
requests bit allocation from an existing registry; the IANA section (7)
is thus key: please make it point to the relevant registry, namely "PCE
Capability Flags" managed within the "OSPFv2 Parameters"

(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).

Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior
> to that time. 



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Qin Wu]

-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 julien.meu...@orange.com
发送时间: 2018年11月15日 23:01
收件人: lsr@ietf.org
主题: Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

Hi,

Contributor hat on, I take the opportunity mentioned by Acee to highlight some 
of the issues in the current version:
- The I-D teaches multiple time about RFC 5088 and 5089 (while 8253 is only 
mentioned in the introduction): the discussed mechanism has been used multiple 
times, there is no need to elaborate so much (see section
3.1.1 of RFC 8306 for example);
[Qin]:Good point and will following RFC8306 example to make it concise.

- Section 3 includes the PCE-CAP-FLAGS sub-TLV definition: having a given 
specification in multiples places brings no value but may create discrepancies, 
please stick to the references to the aforementioned RFCs;
[Qin]: Okay.
- Section 3 tries to list the existing flag allocations: these are inaccurate 
(e.g. RFC 6006 has been obsoleted by RFC 8306), incomplete (e.g. RFC 8231 is 
missing) and inappropriate (this is the role of the IANA registry, not of every 
new I-D!);
[Qin]:Okay, I propose to remove these.
- Contrary to the written text, the I-D does not "extend" anything, it requests 
bit allocation from an existing registry; the IANA section (7) is thus key: 
please make it point to the relevant registry, namely "PCE Capability Flags" 
managed within the "OSPFv2 Parameters"
(https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14).
[Qin]: Okay, fixed in the local copy.
Thanks,

Julien


On 13/11/2018 23:10, Acee Lindem (acee) wrote:
> Note the authors may refresh the draft to address some comments prior 
> to that time.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Qin Wu]

I support this work as one of coauthors.

-Qin
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2018年11月14日 6:11
收件人: lsr@ietf.org
主题: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability 
support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

At the LSR WG meeting in Bangkok, there was general agreement that we should 
adopt this draft given that the PCE WG believes it is useful. Please indicate 
your support or objection prior to 12:00 AM UT, Wednesday November 26th, 2018. 
Note the authors may refresh the draft to address some comments prior to that 
time.


Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

[Qin Wu]

Agree, your proposal sounds reasonable to me. Thanks.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年8月26日 1:41
收件人: Qin Wu; lsr@ietf.org
主题: Re: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt

Hi Qin, 

I believe it is a significant security exposure to include the actual keys in 
IGPs. What I was suggesting was to include an identifier of the key to be used.

Thanks,
Acee

On 8/24/18, 10:56 PM, "Qin Wu"  wrote:

Hi, Acee:
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年8月24日 22:23
    收件人: Qin Wu; lsr@ietf.org
主题: Re: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt

Hi Qin, 

On 8/23/18, 11:03 PM, "Qin Wu"  wrote:

Hi, Folks:
draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as 
draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion.

https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
This draft define IGP extension for PCEP security support, 
1.TCP AO which has been published as RFC5295.
2.PCEP over TLS which has been published as RFC8253 recently.

One issue raised by chair is shared key support for TCP-AO, how do you 
get shared key?

I guess my point was is that if you are distributing shared keys, you 
probably know whether or not TCP-AO is supported. Having said that, possibly 
the draft should include some sort of key-id for TCP-AO or TLS usage. For 
example, the key-chain name from RFC 8177. We don't need to decide now. 

[Qin]: RFC5088 " OSPF Protocol Extensions for PCE discovery" said:
"
   PCE discovery information is, by nature, fairly static and does not
   change with PCE activity.  Changes in PCE discovery information may
   occur as a result of PCE configuration updates, PCE
   deployment/activation, PCE deactivation/suppression, or PCE failure.
   Hence, this information is not expected to change frequently.
"
So security capability as part of PCE discovery information should also be 
static. 

RFC5926 section 3.1 said:
"
In TCP-AO's manual key mode, this is a key shared by both peers, entered 
via some interface to their
respective configurations.  The Master_Key is used as the seed for the KDF.
"
My impression TCP-AO relies on manual installation for shared key. But TLS 
has key management protocol to exchange shared key,e.g., one defined in RFC4279.
We can either negotiate shared key for TCP-AO in the PCE discovery phase or 
during PCE configuration phase. For TLS usage, this is not needed, in my 
opinion.
To support shared key negotiation during PCE discovery phase, we need to 
define a IGP PCED Sub-TLV for TCP-AO, I am not sure this is allowed according 
to RFC5088,
It looks this new IGP PCEP TLV is a companion Sub-TLV for PCE-CAP-FLAGS 
Sub-TLV. 
If adding a new Sub-TLV is allowed, we can add algorithm identifier and key 
chain name,key identifier altogether.

If negotiating shared key during PCE configuration phase, it is clearly 
beyond scope of this draft.
Thanks,
Acee 


we believe to support TCP-AO, RFC5296 should also be implemented, which 
provide PSK and associated ciphersuit.
Let us know if you have any other opinion?

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2018年8月24日 10:57
收件人: Daniel King; wangzitao; Dhruv Dhody; wangzitao; Diego R. Lopez; 
Diego Lopez; Qin Wu
主题: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt


A new version of I-D, draft-wu-lsr-pce-discovery-security-support-00.txt
has been successfully submitted by Qin Wu and posted to the IETF 
repository.

Name:   draft-wu-lsr-pce-discovery-security-support
Revision:   00
Title:  IGP extension for PCEP security capability support in 
the PCE discovery
Document date:  2018-08-23
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-wu-lsr-pce-discovery-security-support-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/
Htmlized:   
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support


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 presen

Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

[Qin Wu]

Hi, Acee:
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年8月24日 22:23
收件人: Qin Wu; lsr@ietf.org
主题: Re: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt

Hi Qin, 

On 8/23/18, 11:03 PM, "Qin Wu"  wrote:

Hi, Folks:
draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as 
draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion.
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
This draft define IGP extension for PCEP security support, 
1.TCP AO which has been published as RFC5295.
2.PCEP over TLS which has been published as RFC8253 recently.

One issue raised by chair is shared key support for TCP-AO, how do you get 
shared key?

I guess my point was is that if you are distributing shared keys, you probably 
know whether or not TCP-AO is supported. Having said that, possibly the draft 
should include some sort of key-id for TCP-AO or TLS usage. For example, the 
key-chain name from RFC 8177. We don't need to decide now. 

[Qin]: RFC5088 " OSPF Protocol Extensions for PCE discovery" said:
"
   PCE discovery information is, by nature, fairly static and does not
   change with PCE activity.  Changes in PCE discovery information may
   occur as a result of PCE configuration updates, PCE
   deployment/activation, PCE deactivation/suppression, or PCE failure.
   Hence, this information is not expected to change frequently.
"
So security capability as part of PCE discovery information should also be 
static. 

RFC5926 section 3.1 said:
"
In TCP-AO's manual key mode, this is a key shared by both peers, entered via 
some interface to their
respective configurations.  The Master_Key is used as the seed for the KDF.
"
My impression TCP-AO relies on manual installation for shared key. But TLS has 
key management protocol to exchange shared key,e.g., one defined in RFC4279.
We can either negotiate shared key for TCP-AO in the PCE discovery phase or 
during PCE configuration phase. For TLS usage, this is not needed, in my 
opinion.
To support shared key negotiation during PCE discovery phase, we need to define 
a IGP PCED Sub-TLV for TCP-AO, I am not sure this is allowed according to 
RFC5088,
It looks this new IGP PCEP TLV is a companion Sub-TLV for PCE-CAP-FLAGS 
Sub-TLV. 
If adding a new Sub-TLV is allowed, we can add algorithm identifier and key 
chain name,key identifier altogether.

If negotiating shared key during PCE configuration phase, it is clearly beyond 
scope of this draft.
Thanks,
Acee 


we believe to support TCP-AO, RFC5296 should also be implemented, which 
provide PSK and associated ciphersuit.
Let us know if you have any other opinion?

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2018年8月24日 10:57
收件人: Daniel King; wangzitao; Dhruv Dhody; wangzitao; Diego R. Lopez; Diego 
Lopez; Qin Wu
主题: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt


A new version of I-D, draft-wu-lsr-pce-discovery-security-support-00.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-wu-lsr-pce-discovery-security-support
Revision:   00
Title:  IGP extension for PCEP security capability support in 
the PCE discovery
Document date:  2018-08-23
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-wu-lsr-pce-discovery-security-support-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/
Htmlized:   
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support


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.


  


Please note that it ma

Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

[Qin Wu]

Hi, Folks:
draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as 
draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion.
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
This draft define IGP extension for PCEP security support, 
1.TCP AO which has been published as RFC5295.
2.PCEP over TLS which has been published as RFC8253 recently.

One issue raised by chair is shared key support for TCP-AO, how do you get 
shared key?
we believe to support TCP-AO, RFC5296 should also be implemented, which provide 
PSK and associated ciphersuit.
Let us know if you have any other opinion?

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2018年8月24日 10:57
收件人: Daniel King; wangzitao; Dhruv Dhody; wangzitao; Diego R. Lopez; Diego 
Lopez; Qin Wu
主题: New Version Notification for 
draft-wu-lsr-pce-discovery-security-support-00.txt


A new version of I-D, draft-wu-lsr-pce-discovery-security-support-00.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-wu-lsr-pce-discovery-security-support
Revision:   00
Title:  IGP extension for PCEP security capability support in the PCE 
discovery
Document date:  2018-08-23
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-wu-lsr-pce-discovery-security-support-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/
Htmlized:   
https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support


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.


  


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.

The IETF Secretariat

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

[Qin Wu]

Support.

-Qin

> On May 23, 2018, at 5:28 PM, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> We're starting a 2 week WG Last Call on
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/
> 
> Please raise any objections or comments before Jun 6th, 2018.
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

[Qin Wu]

Support as coauthor.

-Qin
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2018年4月10日 3:39
收件人: draft-ginsberg-lsr-isis-rfc7810...@ietf.org
抄送: lsr@ietf.org
主题: IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - 
draft-ginsberg-lsr-isis-rfc7810bis-00

Authors,

Are you aware of any IPR that applies to draft-ginsberg-lsr-isis-rfc7810bis-00 
in addition to the IPR declared on RFC 7810:

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-te-metric-extensions

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing list.* The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

[Qin Wu]

+1
I am not aware of any IPR related to this draft.

-Qin
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2018年4月10日 3:42
收件人: Acee Lindem (acee) ; 
draft-ginsberg-lsr-isis-rfc7810...@ietf.org
抄送: lsr@ietf.org
主题: RE: IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - 
draft-ginsberg-lsr-isis-rfc7810bis-00

I am not aware of any undisclosed IPR.

Les

From: Acee Lindem (acee)
Sent: Monday, April 09, 2018 12:39 PM
To: 
draft-ginsberg-lsr-isis-rfc7810...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "IS-IS Traffic Engineering (TE) Metric Extensions" - 
draft-ginsberg-lsr-isis-rfc7810bis-00

Authors,

Are you aware of any IPR that applies to draft-ginsberg-lsr-isis-rfc7810bis-00 
in addition to the IPR declared on RFC 7810:

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-te-metric-extensions

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing list.* The document will not 
advance to the next stage until a response has been received from each author 
and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr