Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 Apr 2022 14:31:03 +0000

Hi PCE WG

Support adoption, seems reasonable to relay path MTU as status information and criteria/constraint in PCEP. A few comments/questions (these are non-blocking to adoption):

  1.  Shouldn’t the MTU bound use case be an inversion of the current description? Rather than specify a max mtu, wouldn't an operator prefer to find a path that satisfies a minimum MTU to avoid fragmentation? For example, if I have a requirement for X byte MTU along my path, then my bounds should indicate "please find a path that supports at minimum MTU value of X" ?   Similar to a bandwidth constraint?  This is the paragraph reference:

   Further, a PCC MAY use the Path MTU metric in a Path Computation
   Request (PCReq) message to request a path meeting the MTU requirement
   of the path.  In this case, the B bit MUST be set to suggest a bound
   (a maximum) for the Path MTU metric that must not be exceeded for the
   PCC to consider the computed path as acceptable.  The Path MTU metric
   must be less than or equal to the value specified in the metric-value
   field.

  1.  Should the term optimize be defined in the below snippet? I assume the goal to find a path providing the largest MTU possible, so recommend some text describing what is the optimization goal when the goal is metric type MTU.

   A PCC can also use this metric to ask PCE to optimize the path MTU
   during path computation.  In this case, the B bit MUST be cleared.

  1.  Glad to see considerations for ietf-pce-multipath in the document. Since multipath document generically handles embedding other objects including METRIC (section 7.1 in draft-ietf-multipath), I would assume this metric would follow suit similar to existing metrics (ex TE-metric). Do the authors have potential other special use cases/needs involving the PMTU metric object per ERO?

  1.  In section 3.3 it specifies " A PCC MAY include the path MTU metric as a bound constraint or to indicate optimization criteria (similar to PCReq)." I assume the intention here was to indicate that a PcRpt may carry the MTU metric as a constraint, so probably worth explicitly stating PcRpt may carry it rather than comparing to PcReq.

  1.  The document makes a brief remark on the differentiation for MSD compared to PMTU. While correct, it’s likely worth remarking that for SR-MPLS the type of SIDs pushed onto the path would also have an impact to MTU in the path selection. For example, AdjSIDs being popped as the packet is in transit vs node SIDs remaining constant vs more complexity with BSIDs being used in the transit path could actually cause the packet size to grow while in mid-flight. Was there any consideration into the impact of this for PCE and or guidance for how PCE should be able to handle this ? I don’t have content to suggest but since there’s no discussion SR-MPLS segment type behavior makes me wonder if there might be a scenario or situation gap.

Thanks
Andrew

From: Pce <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Date: Monday, March 28, 2022 at 12:10 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th April 2022.

Thanks!
Dhruv & Julien

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 4 Apr 2022 19:35:26 +0530

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

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.

[*] What I see is that some amount of uncoordinated protocol spec
development related to SPRING constructs is happening in the
protocol-specific WGs (PCE & IDR) without the base work being done in the
SPRING WG. I had raised this point during the IDR document adoption as
well: https://mailarchive.ietf.org/arch/msg/idr/ZrN1-Uw1ggyxKeltBICmcthjymM/

Thanks,
Ketan

On Mon, Mar 28, 2022 at 9:40 PM Dhruv Dhody <[email-masked]> wrote:

> Should this draft be adopted by the PCE WG? Please state your reasons -
> Why / Why not? What needs to be fixed before or after adoption? Are you
> willing to work on this draft? Review comments should be posted to the list.
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 7 Apr 2022 02:52:43 +0000

Hi Ketan,

Thank you for your comments. Regarding to your three points, please find our responses below.

1)      Are you referring to an architecture kind of draft on Path MTU? Including collection, calculation/comparison, selection, enforcement to the headend? We are open to have such draft but would like to get the guidance from the Chairs of these working groups whether it is needed since there have been several PMTU drafts adopted already in each WG. But we don’t think this should be taken as a reason to stop the adoption of this draft because it has all the information that needs to be adopted in the PCE WG.

2)      In PCEP, the METRIC object as per RFC5440 is used for both a) and b). In this draft, we defined a new type of METRIC object.

3)      Yes, this is applicable for both RSVP-TE and SR Policy.

Thank you!

Best Regards,
Shuping

From: Ketan Talaulikar [mailto:[email-masked]]
Sent: Monday, April 4, 2022 10:05 PM
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

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

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?

[*] What I see is that some amount of uncoordinated protocol spec development related to SPRING constructs is happening in the protocol-specific WGs (PCE & IDR) without the base work being done in the SPRING WG. I had raised this point during the IDR document adoption as well: https://mailarchive.ietf.org/arch/msg/idr/ZrN1-Uw1ggyxKeltBICmcthjymM/

Thanks,
Ketan

On Mon, Mar 28, 2022 at 9:40 PM Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

Thanks!
Dhruv & Julien
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 7 Apr 2022 21:58:20 +0530

Hi Shuping,

Please check inline below.

On Thu, Apr 7, 2022 at 8:22 AM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> 1)      Are you referring to an architecture kind of draft on Path MTU?
> Including collection, calculation/comparison, selection, enforcement to the
> headend?
>
KT> It starts from the definition and applicability of PMTU for SR
Policies. How is the (reducing) label stack factored in for SR-MPLS? How
does it apply for SRv6? Since in SRv6 we are actually doing encapsulation
(H.encap.*), is there fragmentation done? How are errors handled/reported?
Unlike RSVP-TE, with SR the "path" is not "nailed" down link-by-link and we
do have ECMP (not "multipath" that the draft refers to) where IGP routing
is followed. How is PMTU measured in such cases? Consider an SR Policy
which is a single FlexAlgo Prefix-SID of the destination - what would be
the PMTU of such an SR Policy? It also includes the aspects you mention.
These are not specific to PCEP protocol and also apply when provisioning is
done via BGP SRTE.

> We are open to have such draft but would like to get the guidance from the
> Chairs of these working groups whether it is needed since there have been
> several PMTU drafts adopted already in each WG. But we don’t think this
> should be taken as a reason to stop the adoption of this draft because it
> has all the information that needs to be adopted in the PCE WG.
>
KT> I have a concern with protocol extensions and encodings being defined
without the applicability, use-case, architecture, and design being ironed
out first.

>
>
> 2)      In PCEP, the METRIC object as per RFC5440 is used for both a) and
> b). In this draft, we defined a new type of METRIC object.
>
KT> Please point me to the text in the document where both these
use-cases/scenarios are described. Have I missed it?

Thanks,
Ketan

> *From:* Ketan Talaulikar [mailto:[email-masked]]
> *Sent:* Monday, April 4, 2022 10:05 PM
> *To:* Dhruv Dhody <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
>
>
>
> Hello,
>
>
>
> well:
> https://mailarchive.ietf.org/arch/msg/idr/ZrN1-Uw1ggyxKeltBICmcthjymM/
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>

---

From: "韩柳燕" <[email-masked]>
Date: Fri, 8 Apr 2022 10:20:13 +0800

Hi Chairs,

I support the adoption of this work. 
As an operator, I think this draft is very valuable for any operator's deployments of SR networks in order to ensure that fragmentation does not occur along the SR path. The scenario and benefits are clear.

Thanks.

Best regards,
Liuyan

2022-04-08 

-------------------------------------
韩柳燕 / Han Liuyan
中国移动通信研究院 网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33076
传真：010-63601087
手机: 15810339103
Email: [email-masked]
------------------------------------- 

发件人： Dhruv Dhody 
发送时间： 2022-03-29  00:11:30 
收件人： [email-masked] 
抄送： [email-masked] 
主题： [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05 
 
Hi WG,

Thanks!
Dhruv & Julien

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Apr 2022 10:42:53 +0800

Hi chairs,
I support its adoption. Taking PMTU with PCEP is an important work to ensure the end-to-end SR path.

-------------------------------------
王敏学/ Wang Minxue
中国移动通信研究院 基础网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33202
传真：010-63601087
Email: [email-masked]
-------------------------------------
 
From: Dhruv Dhody
Date: 2022-03-29 00:09
To: [email-masked]
CC: [email-masked]
Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
Hi WG,

Thanks!
Dhruv & Julien