Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Hi Gyan, Please check inline below with KT2. On Thu, Apr 21, 2022 at 1:07 AM Gyan Mishra wrote: > Hi Ketan > > Please see in-line > > Thanks > > On Wed, Apr 20, 2022 at 7:10 AM Ketan Talaulikar > wrote: > >> Hi Gyan, >> >> Please check inline below. >> >> >> On Wed, Apr 20, 2022 at 10:08 AM Gyan Mishra >> wrote: >> >>> >>> Hi Ketan >>> >>> >>> On Mon, Apr 4, 2022 at 10:05 AM Ketan Talaulikar >>> wrote: >>> Hello, I do not believe this document is ready for adoption. I believe the WG perhaps needs to discuss some basic concepts before taking up this work. Please note that I do not object to (what I infer is) the motivation for this work. This document is not (yet) a good starting point for this work. 1) We need a SPRING WG document that covers the considerations related to Path MTU for SR Policies. We do not have such a document today. While this document does touch upon certain aspects, it is inadequate. This document should focus more on the PCEP protocol aspects and rely on the existing RSVP-TE spec RFC3209 and TBD for SR Policy for the application to the respective constructs. Note that draft-ietf-idr-sr-policy-path-mtu introduces this PMTU for BGP SRTE [*] >>> >>> Gyan> As Spring SR Policy draft has already been submitted for >>> publication, could we add verbiage to the IDR SR Policy draft and as this >>> draft is BGP SR policy related PCE extension for PMTUD similar to the IDR >>> SR policy PMTU draft mentioned. >>> >> >> KT> I do not see these mechanisms as being protocol specific and hence do >> not seem right for either PCEP or BGP documents. >> > > Gyan> Understood. So PMTU related protocol specific in the IDR and > PCEP documents and PMTU in SR policy specifics in a Spring Informational > document? > KT2> Yes. > >> >>> I read the comments from the IDR adoption call as it relates to SR and >>> PMTU. I think we all agree that the goal of this and the IDR drafts are >>> warranted. However as PMTUD even as it relates to SR is not overly >>> complicated that we need a draft to explain what constitutes the total SR >>> packet size, as SR is not any different from any other technology from a >>> packet sizing perspective. The same concept that the lowest MTU link >>> along a path is the maximum MTU PMTU for the path is valid and that is the >>> basis for PMTU. I don’t think this should hold up the adoption call. >>> >> >> KT> We've had this conversation in the IDR WG during the IDR document >> adoption and we don't yet have a SPRING document. I am not sure if the PCEP >> work proceeds in a similar manner. I will leave it to the WG chairs' >> judgment on this matter. >> > > Gyan> I reviewed the mail archive on the discussion and your request > for a PMTU in SR policy Spring document. I think this is an important > issue to be solved related to PMTU to prevent fragmentation for operators. > KT2> We have SR-MPLS and SRv6. For each of them, we have different kinds of payload - IPv4, IPv6, MPLS, Ethernet, etc. which have different characteristics when it comes to whether or not fragmentation can be performed at the SR Policy head-end. > Would this draft go into the details of how fragmentation would work with > SR problem statement or would it just detail the PMTU protocol specific BGP > and PCEP solution? > KT2> BGP and PCEP documents should be about their respective protocol signaling extensions. The realization and actual implementation of the SR Policy forwarding and path computation construct is common and perhaps outside of those signaling protocols. What I am looking for is a SPRING document that first defines what is a PMTU for an SR Policy, how is it computed, and then how MTU exceed conditions are handled. > If the authors of the PCEP draft published an informational draft on PMTU > in SR Policy as it relates to both IDR and PCE drafts would that suffice? > KT2> Perhaps we need a standards-track document to specify the implementation behavior? Otherwise, how would one ensure interoperability between the controllers and head-end routers coming from different vendors? Everyone needs to have the same understanding of what the PMTU is and how things are to be handled. Thanks, Ketan > >> Thanks, >> Ketan >> >> >>> 2) There seems to be some degree of mixup between the concept of (a) constraint for the path and (b) the reporting of the calculated path MTU of the path. Both are perhaps needed, but we need them to be unambiguous and differentiated. I would think that (a) is also very useful. And I am not sure if it is appropriate to refer to (b) as a "metric" - isn't it a property? >>> >>> >>> 3) This is applicable for both RSVP-TE and SR Policy. >>> >>> Gyan> Agreed >>> [*] What I see is that some amount of uncoordinated protocol spec development related to SPRING constructs is happening in the protoco
[Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP extension to support Segment Routing Policy Candidate Paths Authors : Mike Koldychev Siva Sivabalan Colby Barth Shuping Peng Hooman Bidgoli Filename: draft-ietf-pce-segment-routing-policy-cp-07.txt Pages : 25 Date: 2022-04-21 Abstract: This document introduces a mechanism to specify a Segment Routing (SR) policy, as a collection of SR candidate paths. An SR policy is identified by tuple. An SR policy can contain one or more candidate paths where each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. This document proposes extension to PCEP to support association among candidate paths of a given SR policy. The mechanism proposed in this document is applicable to both MPLS and IPv6 data planes of SR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-policy-cp-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] I-D Action: draft-ietf-pce-state-sync-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Inter Stateful Path Computation Element (PCE) Communication Procedures. Authors : Stephane Litkowski Siva Sivabalan Cheng Li Haomian Zheng Filename: draft-ietf-pce-state-sync-02.txt Pages : 32 Date: 2022-04-21 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-state-sync/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-pce-state-sync-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-state-sync-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Hi Ketan Please see in-line below Gyan2. On Thu, Apr 21, 2022 at 10:32 AM Ketan Talaulikar wrote: > Hi Gyan, > > Please check inline below with KT2. > > > On Thu, Apr 21, 2022 at 1:07 AM Gyan Mishra wrote: > >> Hi Ketan >> >> Please see in-line >> >> Thanks >> >> On Wed, Apr 20, 2022 at 7:10 AM Ketan Talaulikar >> wrote: >> >>> Hi Gyan, >>> >>> Please check inline below. >>> >>> >>> On Wed, Apr 20, 2022 at 10:08 AM Gyan Mishra >>> wrote: >>> Hi Ketan On Mon, Apr 4, 2022 at 10:05 AM Ketan Talaulikar wrote: > Hello, > > I do not believe this document is ready for adoption. I believe the WG > perhaps needs to discuss some basic concepts before taking up this work. > > Please note that I do not object to (what I infer is) the motivation > for this work. This document is not (yet) a good starting point for this > work. > > 1) We need a SPRING WG document that covers the considerations related > to Path MTU for SR Policies. We do not have such a document today. While > this document does touch upon certain aspects, it is inadequate. This > document should focus more on the PCEP protocol aspects and rely on the > existing RSVP-TE spec RFC3209 and TBD for SR Policy for the application to > the respective constructs. Note that draft-ietf-idr-sr-policy-path-mtu > introduces this PMTU for BGP SRTE [*] > Gyan> As Spring SR Policy draft has already been submitted for publication, could we add verbiage to the IDR SR Policy draft and as this draft is BGP SR policy related PCE extension for PMTUD similar to the IDR SR policy PMTU draft mentioned. >>> >>> KT> I do not see these mechanisms as being protocol specific and hence >>> do not seem right for either PCEP or BGP documents. >>> >> >> Gyan> Understood. So PMTU related protocol specific in the IDR and >> PCEP documents and PMTU in SR policy specifics in a Spring Informational >> document? >> > > KT2> Yes. > > >> >>> I read the comments from the IDR adoption call as it relates to SR and PMTU. I think we all agree that the goal of this and the IDR drafts are warranted. However as PMTUD even as it relates to SR is not overly complicated that we need a draft to explain what constitutes the total SR packet size, as SR is not any different from any other technology from a packet sizing perspective. The same concept that the lowest MTU link along a path is the maximum MTU PMTU for the path is valid and that is the basis for PMTU. I don’t think this should hold up the adoption call. >>> >>> KT> We've had this conversation in the IDR WG during the IDR document >>> adoption and we don't yet have a SPRING document. I am not sure if the PCEP >>> work proceeds in a similar manner. I will leave it to the WG chairs' >>> judgment on this matter. >>> >> >> Gyan> I reviewed the mail archive on the discussion and your request >> for a PMTU in SR policy Spring document. I think this is an important >> issue to be solved related to PMTU to prevent fragmentation for operators. >> > > KT2> We have SR-MPLS and SRv6. For each of them, we have different kinds > of payload - IPv4, IPv6, MPLS, Ethernet, etc. which have different > characteristics when it comes to whether or not fragmentation can be > performed at the SR Policy head-end. > Gyan2> Understood. So a design document that goes into the details related to fragmentation on SR Policy head end SID list candidate path instantiated and the impact of fragmentation on intermediate nodes. The goal of the IDR and PCE drafts is in solution space to prevent fragmentation from happening using PMTU. Fragmentation aspect of SR Policy instantiation is the problem and I agree that should be in Spring WG and I would be happy to collaborate on that draft. I agree that SR Policy PMTU should also be part of that Spring draft. > > >> Would this draft go into the details of how fragmentation would work with >> SR problem statement or would it just detail the PMTU protocol specific BGP >> and PCEP solution? >> > > KT2> BGP and PCEP documents should be about their respective protocol > signaling extensions. The realization and actual implementation of the SR > Policy forwarding and path computation construct is common and perhaps > outside of those signaling protocols. What I am looking for is a SPRING > document that first defines what is a PMTU for an SR Policy, how is it > computed, and then how MTU exceed conditions are handled. > Gyan2> Understood. Makes sense. Agreed. > > If the authors of the PCEP draft published an informational draft on PMTU >> in SR Policy as it relates to both IDR and PCE drafts would that suffice? >> > > KT2> Perhaps we need a standards-track document to specify the > implementation behavior? Otherwise, how would one ensure interoperability > between the controllers and head-end routers coming from differe
[Pce] I-D Action: draft-ietf-pce-stateful-pce-optional-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Extension for Stateful PCE to allow Optional Processing of PCEP Objects Authors : Cheng Li Haomian Zheng Stephane Litkowski Filename: draft-ietf-pce-stateful-pce-optional-03.txt Pages : 12 Date: 2022-04-21 Abstract: This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints. This document introduces this relaxation and updates RFC 8231. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-optional-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-optional-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
