Hi Cheng, Thanks for your quick responses and acknowledgement of the changes suggested. Based on your responses, I have no strong views on the parts which can (or need to) be incorporated before adoption and which can be done post adoption.
We can continue to discuss and address the outstanding topics as suggested by you. Thanks, Ketan From: Chengli (Cheng Li) <chengl...@huawei.com> Sent: 18 October 2019 12:35 To: Ketan Talaulikar (ketant) <ket...@cisco.com>; Susan Hares <sha...@ndzh.com>; 'idr wg' <i...@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 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-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant) Sent: Friday, October 18, 2019 1:51 PM To: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>; 'idr wg' <i...@ietf.org<mailto:i...@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] 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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/ 1. 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 1. Most of the comments from the previous draft also applies to this one and so I won't repeat them. 1. 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. 1. 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-boun...@ietf.org<mailto:idr-boun...@ietf.org>> On Behalf Of Susan Hares Sent: 14 October 2019 23:43 To: 'idr wg' <i...@ietf.org<mailto:i...@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-boun...@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. 1. Is this technology a good way to implement the required Features in BGP? 1. Is this technology ready for adoption? 1. Do you have any concerns about adopting this technology? Cheers, Susan Hares
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
