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

Qin Wu <bill.wu@huawei.com> Mon, 24 June 2019 07:36 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3560A120111; Mon, 24 Jun 2019 00:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIVZDbhSsG1R; Mon, 24 Jun 2019 00:36:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A58F1200C1; Mon, 24 Jun 2019 00:36:22 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DEBE5D6488CF80A5E7A2; Mon, 24 Jun 2019 08:36:19 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Jun 2019 08:36:19 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.66]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Mon, 24 Jun 2019 15:36:16 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-lsr-pce-discovery-security-support@ietf.org" <draft-ietf-lsr-pce-discovery-security-support@ietf.org>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt
Thread-Index: AdUqX2U/gRJA1rzAQvu2gJ7v9cJy0g==
Date: Mon, 24 Jun 2019 07:36:16 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA49AB345@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.31.203]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/NS6ecbBHrwjDWa_rCTEUrD1yfcQ>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2019 07:36:24 -0000

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

-Qin
-----邮件原件-----
发件人: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
发送时间: 2019年6月23日 8:58
收件人: Acee Lindem (acee) <acee@cisco.com>;; draft-ietf-lsr-pce-discovery-security-support@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-support@ietf.org
> Cc: lsr@ietf.org; Les Ginsberg (ginsberg) <ginsberg@cisco.com>;
> Subject: Re: [Lsr] I-D Action: 
> draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
> 
> Authors - can you respond to Les' comments?
> Thanks,
> Acee
> 
> On 6/3/19, 2:22 AM, "Lsr on behalf of Les Ginsberg (ginsberg)" <lsr- 
> bounces@ietf.org on behalf of ginsberg@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 <lsr-bounces@ietf.org>; On Behalf Of internet-drafts@ietf.org
>     > Sent: Sunday, June 02, 2019 8:45 PM
>     > To: i-d-announce@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-
> security-
>     > support-01
>     >
>     > A diff from the previous version is available at:
>     > https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-
>     > support-01
>     >
>     >
>     > Please note that it may take a couple of minutes from the time 
> of submission
>     > until the htmlized version and diff are available at tools.ietf.org.
>     >
>     > Internet-Drafts are also available by anonymous FTP at:
>     > ftp://ftp.ietf.org/internet-drafts/
>     >
>     > _______________________________________________
>     > Lsr mailing list
>     > Lsr@ietf.org
>     > https://www.ietf.org/mailman/listinfo/lsr
> 
>     _______________________________________________
>     Lsr mailing list
>     Lsr@ietf.org
>     https://www.ietf.org/mailman/listinfo/lsr
>