Return-Path: 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)" To: "Ketan Talaulikar (ketant)" , Susan Hares , 'idr wg' , 'SPRING WG List' 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: References: <00f901d582ba$f474a230$dd5de690$@ndzh.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 07:05:14 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB0274933Fdggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Katen, Many thanks for your valuable comments, will update the drafts to address t= hem ASAP. Please see my rely inline. Thank you again! Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (keta= nt) Sent: Friday, October 18, 2019 1:51 PM To: Susan Hares ; 'idr wg' ; 'SPRING WG List= ' 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 c= orresponding 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 re= quire 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/ 1) Sec 3 has the following statement which is incorrect. First the Pat= h 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 se= gment 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 a= t both the Segment List and Candidate path level. I can understand the sign= alling at the Segment List level, but not sure why we need it also at the C= P level? If the same Path Segment needs to be shared across Segment Lists t= hen it can be specified for each of them? [Cheng] We aim to provide the capabilities, but your suggestion is right. T= hey can be specified for each of them. Let's discuss which one is better la= ter. 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 se= gment document is adopted in WG, we need SPRING WG to evaluate the SRv6 pat= h segment. I would suggest to call this "MPLS Path Segment" so that work ca= n proceed independently. Down the line, we can introduce another TLV for SR= v6 Path Segment. [Cheng] You are right. Do we have any SRv6 related text in the drafts? I re= member I have removed it. Will check again. 4) I would also propose to use the TLV encoding that is similar to htt= ps://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07#sectio= n-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 t= hat 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 s= upport 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 men= tioned in my previous email. We can discuss on this to design to better solution of supp= orting multiple SID lists for bidirectional path. 6) I am not sure why the parameters like weight is required in the rev= erse 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-i= etf-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 "bidire= ctional", it is actually the reverse path information. There is nothing lik= e traditional bidirectional LSP signalling happening here between the two e= nd 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 hav= e 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 appli= es 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] [Cheng] ACK b) Most of the comments from the previous draft also applies to this o= ne 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 in= stead with draft-ietf-idr-te-lsp-distribution. [Cheng] Sure. Will make that in the next revision. Last time we aligned wit= h draft-ietf-idr-te-lsp-distribution-08, and then the TLV formats were upda= ted, so we should sync up again. d) Please remove all suggested code points from the draft until we hav= e IANA allocations for them. [Cheng] ACK Many thanks! Thank you for your comments, it will definitely help to improv= e the document and my skills of writing drafts. Thanks! Thanks, Ketan From: Idr > On Behalf Of = Susan Hares Sent: 14 October 2019 23:43 To: 'idr wg' >; 'SPRING WG List' > 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 supp= ort below the threshold to accept this draft into the IDR WG. There were n= o 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 th= e 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/ 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 --_000_C7C2E1C43D652C4E9E49FE7517C236CB0274933Fdggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Katen, <= /span>

 

Many thanks for your v= aluable comments, will update the drafts to address them ASAP. Please see m= y rely inline.

 

Thank you again!<= /o:p>

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&g= t;; 'SPRING WG List' <spring@ietf.org>
Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segm= ent-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [1= 0/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 defin= ed in Spring and we need the corresponding work in BGP to build the solutio= ns based on path segments.

 

2)      Is this technology a good way to implement the requ= ired

Features in BGP?

 

Yes and do refer to some of the issues pointe= d in the comments below.

 

3)      Is this technology ready for adoption? <= /p>

 

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

 

4)      Do you have any concerns about adopting this techno= logy?

 

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-id= r-sr-policy-path-segment/

 

1)      Sec 3 has the following statement which is incorrect. First t= he Path Segment does not identify the SR Policy and the identifiers of SR P= olicy are specified in draft-ietf-spring-segment-routing-policy. What the path segment does is identify the specific “SR Path(s)̶= 1; at the tail-end – this is as per draft-ietf-spring-mpls-path-segme= nt. 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 ca=
ses if needed.


 


      &nbs=
p;             =
[Cheng] You are correct! Will address it later.


 



2)     
The draft proposes to have the ability to encode the Path Seg=
ment at both the Segment List and Candidate path level. I can understand th=
e 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 e=
ach of them. Let’s discuss which one is
 better later.


 



3)     
Sec 3.1. Both the SR-MPLS and SRv6 path segments are being co=
mbined here and I am not sure that is appropriate. Since only the SR-MPLS p=
ath segment document is adopted in WG,
 we need SPRING WG to evaluate the SRv6 path segment. I would suggest to ca=
ll this “MPLS Path Segment” so that work can proceed independen=
tly. Down the line, we can introduce another TLV for SRv6 Path Segment.


 


=
[Ch=
eng] You are right. Do we have any SRv6 related text in the drafts? I remem=
ber I have removed it. Will check again.


 



4)     
I would also propose to use the TLV encoding that is similar =
to
https://tools.ietf.o=
rg/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 da=
y. 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 pa=
th 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 SI=
D lists, which means per SID list level.
 That is why we need to add weight TLV into the  Bidirectional Path su=
b-TLV as I mentioned in my previous email.


         &=
nbsp;      We can discuss on this to design to bet=
ter solution of supporting multiple SID lists for bidirectional path.<=
/o:p>


 



6)     
I am not sure why the parameters like weight is required in t=
he reverse path since weight is for load-balancing when steering into the p=
ath.


[Cheng ] For 1:1 correlati=
on, we don’t need weight TLV, should discuss more on this.=



 



7)     
I think either this draft or perhaps more appropriately the d=
raft-ietf-spring-mpls-path-segment better describes the usage of the revers=
e path list so that this draft can refer
 to it. While we are calling this “bidirectional”, it is actual=
ly the reverse path information. There is nothing like traditional bidirect=
ional 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-segme=
nt-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 s=
ince in BGP-LS we have 2 byte type and 2 byte length. It is required to ali=
gn 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 defin=
itely help to improve the document and my skills of writing drafts. Thanks!=



 


 


Thanks,


Ketan


 



 


Greetings IDR and Spri=
ng WG


 


The WG Adoption for th=
e two IDR drafts related to IDR received a level support below the threshol=
d 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 co=
mment on whether these drafts have matured enough to be IDR WG drafts. &nbs=
p;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]<=
/o:p>






 


This begins a 2 week WG Adoption call two related dr=
afts [9/17 to 10/1/2019]




·        
draft-li-bgp-ls-sr-policy-path-segment-03.tx=
t and 




·        
draft-li-idr-sr-policy-path-segment-01.txt. =



 


You can access these two drafts at the following loc=
ation: 



 


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


 


https://datatracker.ietf..org/doc/draft-li-id=
r-sr-policy-path-segment/


 


The authors have pointed out that the adoption of th=
is 



draft since the following  SR-MPLS Path Segment=
 draft has been adopted:



 


https://tools.ietf.org/html/draft-ietf-spring-mp=
ls-path-segment-00


 


Please consider the following questions in your resp=
onses? 



 



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



 


Spring has adopted the draft, but IDR can pro=
vide feedback



to spring about putting this technology in BG=
P.


 



2)     
Is this technology a good way to implement the requ=
ired 



Features in BGP? 


 



3)     
Is this technology ready for adoption? <=
/p>

 



4)     
Do you have any concerns about adopting this techno=
logy? 



 


 


Cheers, Susan Hares
--_000_C7C2E1C43D652C4E9E49FE7517C236CB0274933Fdggeml529mbxchi_--