Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

"Chengli (Cheng Li)" <chengli13@huawei.com> Fri, 18 October 2019 07:05 UTC

Return-Path: <chengli13@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E700C1202A0; Fri, 18 Oct 2019 00:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 LwuTb18OUeVJ; Fri, 18 Oct 2019 00:05:10 -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 BBF38120098; Fri, 18 Oct 2019 00:05:09 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E3846E1564D7AC83EAC4; Fri, 18 Oct 2019 08:05:06 +0100 (IST)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Oct 2019 08:04:56 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.135]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Fri, 18 Oct 2019 15:04:52 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>, 'SPRING WG List' <spring@ietf.org>
Thread-Topic: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]
Thread-Index: AdWCuk3YU0jOn/ygQ1+t1TuQqTQ3YACtfKXgAALIXFA=
Date: Fri, 18 Oct 2019 07:04:51 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB0274933F@dggeml529-mbx.china.huawei.com>
References: <00f901d582ba$f474a230$dd5de690$@ndzh.com> <CY4PR11MB15411996CCC61AE91C257726C16C0@CY4PR11MB1541.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB15411996CCC61AE91C257726C16C0@CY4PR11MB1541.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.185.75]
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB0274933Fdggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NRGwxRZ5RQc1Oj0vENGR_KHhSI4>
Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 07:05:14 -0000

Hi Katen,

Many thanks for your valuable comments, will update the drafts to address them ASAP. Please see my rely inline.

Thank you again!
Cheng


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, October 18, 2019 1:51 PM
To: Susan Hares <shares@ndzh.com>; 'idr wg' <idr@ietf.org>; 'SPRING WG List' <spring@ietf.org>
Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

Hi Sue,

1)      Should this SR Policy technology be included in BGP for SR-MPLS



Yes. The path segment for MPLS has been defined in Spring and we need the corresponding work in BGP to build the solutions based on path segments.

2)      Is this technology a good way to implement the required

Features in BGP?



Yes and do refer to some of the issues pointed in the comments below.


3)      Is this technology ready for adoption?



I have listed down the issues/concerns below. I believe we need to hear the responses from the authors on them. The WG/chairs can decide whether to require these changes before or after adoption.


4)      Do you have any concerns about adopting this technology?



No (subject to clarifications on the comments below).



My apologies for the delay in review and sharing these comments:

https://datatracker.ietf..org/doc/draft-li-idr-sr-policy-path-segment/<https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-segment/>

1)      Sec 3 has the following statement which is incorrect. First the Path Segment does not identify the SR Policy and the identifiers of SR Policy are specified in draft-ietf-spring-segment-routing-policy. What the path segment does is identify the specific "SR Path(s)" at the tail-end - this is as per draft-ietf-spring-mpls-path-segment. So I think the statement below needs to be revised.


Also,

   it can be used for identifying an SR candidate path or an SR Policy

   in some use cases if needed.



                    [Cheng] You are correct! Will address it later.

2)      The draft proposes to have the ability to encode the Path Segment at both the Segment List and Candidate path level. I can understand the signalling at the Segment List level, but not sure why we need it also at the CP level? If the same Path Segment needs to be shared across Segment Lists then it can be specified for each of them?

[Cheng] We aim to provide the capabilities, but your suggestion is right. They can be specified for each of them. Let's discuss which one is better later.

3)      Sec 3.1. Both the SR-MPLS and SRv6 path segments are being combined here and I am not sure that is appropriate. Since only the SR-MPLS path segment document is adopted in WG, we need SPRING WG to evaluate the SRv6 path segment. I would suggest to call this "MPLS Path Segment" so that work can proceed independently. Down the line, we can introduce another TLV for SRv6 Path Segment.



[Cheng] You are right. Do we have any SRv6 related text in the drafts? I remember I have removed it. Will check again.


4)      I would also propose to use the TLV encoding that is similar to https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07#section-2.4.3.2.1 for the MPLS path segment.
[Cheng] Agree. We designed the TLV format to draft-ietf-idr-segment-routing-te-policy at the first day. Will update to align again.


5)      Sec 4.1. The proposed Bidirectional Path sub-TLV is at the CP level. So does it indicate a single reverse path SL for all the forward path SLs or can it have multiple SLs? Why not also do this on the per SL level so that the reverse path matches the forward path where necessary? Otherwise it is not possible to correlate the forward and reverse SLs.
[Cheng] We plan to update this in the next revision. Right now, we do not support to have multiple SID lists, which means per SID list level. That is why we need to add weight TLV into the  Bidirectional Path sub-TLV as I mentioned in my previous email.
                We can discuss on this to design to better solution of supporting multiple SID lists for bidirectional path.

6)      I am not sure why the parameters like weight is required in the reverse path since weight is for load-balancing when steering into the path.
[Cheng ] For 1:1 correlation, we don't need weight TLV, should discuss more on this.


7)      I think either this draft or perhaps more appropriately the draft-ietf-spring-mpls-path-segment better describes the usage of the reverse path list so that this draft can refer to it. While we are calling this "bidirectional", it is actually the reverse path information. There is nothing like traditional bidirectional LSP signalling happening here between the two end points directly. It is something that is provisioned by a controller.
[Cheng] OK, will do.


8)      Please remove all suggested code points from the draft until we have IANA allocations for them.
[Cheng] OK

https://datatracker.ietf.org/doc/draft-li-idr-bgp-ls-sr-policy-path-segment/

a)      Sec 3 has some similar text as below and the comment (1) also applies to it.

it can be used for identifying an SR candidate path or an SR
   Policy defined in [I-D.ietf-spring-segment-routing-policy<https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment-03#ref-I-D.ietf-spring-segment-routing-policy>]
[Cheng] ACK

b)      Most of the comments from the previous draft also applies to this one and so I won't repeat them.

c)       This draft cannot borrow the TLV formats from the one above since in BGP-LS we have 2 byte type and 2 byte length. It is required to align instead with draft-ietf-idr-te-lsp-distribution.
[Cheng] Sure. Will make that in the next revision. Last time we aligned with draft-ietf-idr-te-lsp-distribution-08, and then the TLV formats were updated, so we should sync up again.


d)      Please remove all suggested code points from the draft until we have IANA allocations for them.
[Cheng] ACK

Many thanks! Thank you for your comments, it will definitely help to improve the document and my skills of writing drafts. Thanks!


Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: 14 October 2019 23:43
To: 'idr wg' <idr@ietf.org<mailto:idr@ietf.org>>; 'SPRING WG List' <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

Greetings IDR and Spring WG

The WG Adoption for the two IDR drafts related to IDR received a level support below the threshold to accept this draft into the IDR WG.  There were no objection, but there was simply a low level of response.

This 1 week extension to the Adoption call is to let the members of both the IDR and SPRING WG comment on whether these drafts have matured enough to be IDR WG drafts.  On 10/21/2019, the IDR chairs will make a determination of whether either of these two drafts have enough support to be accepted.

Thank you,  Susan  Hares
IDR co-chair

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, September 17, 2019 12:35 PM
To: 'idr wg'
Subject: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt [9/17 to 10/1/2019]

This begins a 2 week WG Adoption call two related drafts [9/17 to 10/1/2019]
*         draft-li-bgp-ls-sr-policy-path-segment-03.txt and
*         draft-li-idr-sr-policy-path-segment-01.txt.

You can access these two drafts at the following location:

https://datatracker.ietf.org/doc/draft-li-idr-bgp-ls-sr-policy-path-segment/

https://datatracker.ietf..org/doc/draft-li-idr-sr-policy-path-segment/<https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-segment/>

The authors have pointed out that the adoption of this
draft since the following  SR-MPLS Path Segment draft has been adopted:

https://tools.ietf.org/html/draft-ietf-spring-mpls-path-segment-00

Please consider the following questions in your responses?

1)      Should this SR Policy technology be included in BGP for SR-MPLS



Spring has adopted the draft, but IDR can provide feedback

to spring about putting this technology in BGP.

2)      Is this technology a good way to implement the required

Features in BGP?


3)      Is this technology ready for adoption?


4)      Do you have any concerns about adopting this technology?



Cheers, Susan Hares