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

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

Please check inline below.


On Wed, Apr 20, 2022 at 10:08 AM Gyan Mishra <[e-mail]> wrote:

>
> Hi Ketan
>
>
> On Mon, Apr 4, 2022 at 10:05 AM Ketan Talaulikar <[e-mail]>
> 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.


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

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
>> 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 <[e-mail]> wrote:
>>
>>> 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
>>> _______________________________________________
>>> Pce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pce
>>>
>> _______________________________________________
>> Pce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pce
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>