Re: [Pce] Regd open discussions on draft-ietf-pce-segment-routing-ipv6

Hi Ketan,

On Fri, Jul 21, 2023 at 8:38 PM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Hello All,
>
> There are few aspects that need further work/discussion on this draft.
>
> 1) We need some text that specifies that for SRv6 (unlike in the case of
> SR-MPLS), the MSD capabilities of the headend node alone is not sufficient.
> For the PCE to compute and provision an SRv6 Policy, it needs to know how
> many Segments the headend can impose in the SRH. The PCE also needs to know
> how deep in the SRH can each midpoint (i.e. SR Endpoint Node) read and
> process SRv6 Segments. Finally, the PCE also needs to know how large an SRH
> can the tailend or the penultimate SR Endpoint Node dispose. So, when the
> draft talks about MSD for SRv6, it must clearly describe all of the above.
> The current text is giving an impression of a false analogy with SR-MPLS
> where PCE is only interested in the MSD capabilities of the headend node.
>
> 2) As an extension of the above point, it does not make much sense to
> report only the headend's SRv6 MSD via PCEP. The PCE would anyway need to
> use the topology feed from IGP/BGP-LS that conveys the SRv6 MSD
> capabilities of the other midpoint and tailend node as part of the overall
> topology information. So, what is the point of reporting the headend SRv6
> MSD via PCEP? Since we cannot remove MSD from the encoding at this late
> stage, at least the draft can say that it is not a recommended option to
> signal SRv6 MSD via PCEP.
>
>
How about we add this text -

"Note that the PCE needs to take the MSD values of all SRv6 nodes along the
path into consideration."

The PCE can learn this via IGP/BGP-LS or even PCEP (in PCECC like
scenarios). I hope the above takes care of it.

> 3) A related topic then is the value of the X flag that is used to
> indicate that the headend doesn't have any MSD limitation. This does not
> apply for SRv6. We can either remove this X flag or if there are
> implementations shipping then we can deprecate it.
>
>
Let's find out if any one is setting the X flag in their implementations in
the PCE WG session today!

Anyways, in my mind, if an operator sets the flag it is fine with MSD being
not taken into consideration during the path computation and living with
the consequences of it.  We can make an explicit warning about it.

Thanks!
Dhruv

> I hope we can discuss these points over the mailer and/or during the
> upcoming IETF week.
>
> Thanks,
> Ketan
>
> On Tue, Jun 27, 2023 at 7:50 PM Cheng Li <c.l@huawei.com> wrote:
>
>> Hi PCE,
>> (The previous email was sent too fast, fixed some syntax errors and
>> resend)
>>
>> This update addressed the comments from Adrian, Ran Chen and Yingzhen.
>> Many thanks to their valuable comments[1], please review and confirm,
>> thanks!
>> This update also tries to address the comments from Ketan. We believe
>> that we have addressed the editorial comments from Ketan[1].
>>
>> Till now, we may have two reserved comments to be addressed:
>> 1. IANA allocation of SRv6-ERO(From Adrian): Should we create a new
>> registry for SR/SRv6?  or allocate them from the RSVP parameters registry?
>> Comments are welcome.
>> 2. X-flag(From Ketan): is the X-flag needed? If not, why? if we decide to
>> delete it, we need to know from the WG that if anyone has implemented it,
>> and how can we handle the compatibility problem.
>>
>> Comments and feedbacks are appreciated.
>>
>> Respect,
>> Cheng
>>
>>
>> [1]. https://github.com/muzixing/IETF-PCEP-SRV6/issues
>>
>> -----Original Message-----
>> From: Pce <pce-bounces@ietf.org> On Behalf Of Cheng Li
>> Sent: Wednesday, June 28, 2023 10:42 AM
>> To: pce@ietf.org; Mahendra Negi <mahend.ietf@gmail.com>; Mahendra Singh
>> Negi <mahend.ietf@gmail.com>; Mike Koldychev <mkoldych@cisco.com>;
>> Prejeeth Kaladharan <prejeeth@rtbrick.com>; Siva Sivabalan <
>> msiva282@gmail.com>; Yongqing Zhu <zhuyq8@chinatelecom.cn>; Ketan
>> Talaulikar <ketant.ietf@gmail.com>; adrian@olddog.co.uk;
>> yingzhen.ietf@gmail.com; chen.ran@zte.com.cn
>> Subject: Re: [Pce] New Version Notification for
>> draft-ietf-pce-segment-routing-ipv6-17.txt
>>
>> Hi PCE,
>>
>> This update addressed the comments from Adrian, Ran Chen and Yingzhen.
>> Many thanks to their valuable comments[1], please review and confirm,
>> thanks!
>> This update also try to address the comments from Ketan. We believe that
>> we have addressed the editorial from Ketan[1].
>>
>> Till now, we may have two reserved comments to be addressed:
>>
>> 1. IANA allocation of SRv6-ERO(From Adrian): Should we create a new
>> registry for SR/SRv6 or allocate in from the RSVP parameters registry?
>> Comments are welcome.
>> 2. X-flag(From Ketan): is the X-flag needed? If not, why? if we decide to
>> delete it, we need to know from the WG that if anyone has implemented it,
>> and how can we handle the compatibility problem.
>>
>> Comments and feedback are appreciated.
>>
>> Respect,
>> Cheng
>>
>>
>> [1]. https://github.com/muzixing/IETF-PCEP-SRV6/issues
>>
>>
>> -----Original Message-----
>> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
>> Sent: Wednesday, June 28, 2023 10:29 AM
>> To: Cheng Li <c.l@huawei.com>; Cheng Li <c.l@huawei.com>; Mahendra Negi <
>> mahend.ietf@gmail.com>; Mahendra Singh Negi <mahend.ietf@gmail.com>;
>> Mike Koldychev <mkoldych@cisco.com>; Prejeeth Kaladharan <
>> prejeeth@rtbrick.com>; Siva Sivabalan <msiva282@gmail.com>; Yongqing Zhu
>> <zhuyq8@chinatelecom.cn>
>> Subject: New Version Notification for
>> draft-ietf-pce-segment-routing-ipv6-17.txt
>>
>>
>> A new version of I-D, draft-ietf-pce-segment-routing-ipv6-17.txt
>> has been successfully submitted by Cheng Li(Editor) and posted to the
>> IETF repository.
>>
>> Name:           draft-ietf-pce-segment-routing-ipv6
>> Revision:       17
>> Title:          Path Computation Element Communication Protocol (PCEP)
>> Extensions for Segment Routing leveraging the IPv6 dataplane
>> Document date:  2023-06-28
>> Group:          pce
>> Pages:          26
>> URL:
>> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-17.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/
>> Html:
>> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-17.html
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6
>> Diff:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-17
>>
>> Abstract:
>>    Segment Routing (SR) can be used to steer packets through an IPv6 or
>>    MPLS network using the source routing paradigm.  SR enables any head-
>>    end node to select any path without relying on a hop-by-hop signaling
>>    technique (e.g., LDP or RSVP-TE).
>>
>>    A Segment Routed Path can be derived from a variety of mechanisms,
>>    including an IGP Shortest Path Tree (SPT), explicit configuration, or
>>    a PCE.
>>
>>    Since SR can be applied to both MPLS and IPv6 forwarding planes, a
>>    PCE should be able to compute SR-Path for both MPLS and IPv6
>>    forwarding planes.  The PCEP extension and mechanisms to support SR-
>>    MPLS have been defined.  This document describes the extensions
>>    required for SR support for IPv6 data plane in the Path Computation
>>    Element communication Protocol(PCEP).
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
>> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>