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. 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. 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 <[email protected]> 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 <[email protected]> On Behalf Of Cheng Li > Sent: Wednesday, June 28, 2023 10:42 AM > To: [email protected]; Mahendra Negi <[email protected]>; Mahendra Singh > Negi <[email protected]>; Mike Koldychev <[email protected]>; > Prejeeth Kaladharan <[email protected]>; Siva Sivabalan < > [email protected]>; Yongqing Zhu <[email protected]>; Ketan > Talaulikar <[email protected]>; [email protected]; > [email protected]; [email protected] > 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: [email protected] <[email protected]> > Sent: Wednesday, June 28, 2023 10:29 AM > To: Cheng Li <[email protected]>; Cheng Li <[email protected]>; Mahendra Negi < > [email protected]>; Mahendra Singh Negi <[email protected]>; Mike > Koldychev <[email protected]>; Prejeeth Kaladharan <[email protected]>; > Siva Sivabalan <[email protected]>; Yongqing Zhu <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
