Re: [spring] [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]

["Ketan Talaulikar (ketant)" <[e-mail]>]

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/


  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.


  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?


  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.



  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.



  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.



  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.



  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.



  1.  Please remove all suggested code points from the draft until we have IANA allocations for them.


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


  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.



  1.  Please remove all suggested code points from the draft until we have IANA allocations for them.

Thanks,
Ketan

From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: 14 October 2019 23:43
To: 'idr wg' <[e-mail]>; 'SPRING WG List' <[e-mail]>
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:[e-mail]] 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.


  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