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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 20 April 2022 19:37 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18B33A0D7E; Wed, 20 Apr 2022 12:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDtUa4fw0KwX; Wed, 20 Apr 2022 12:37:47 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5986B3A0D71; Wed, 20 Apr 2022 12:37:47 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id t12so2722491pll.7; Wed, 20 Apr 2022 12:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1fcPXxDEhmYSVJ/ogmtstCSuQ+WzYE2nDHQCiZjQDD0=; b=IuVLyOCWot/mFOQEZiLtRJ+zF6t0uuvhzReQ+KRDuz4sN2fHjFFiFFWsHdeMKqKU1K ZHVZ99Q2/azrLPgW1T1GWqliN0KsvA9gEwwmRjkewE2lpkW6BiMWcu6c3PDu1c2iA3+Y ObD3XZBz/QqBm+6BWdyCKmEHte6uqipv9K8x3GWTIRBBFGa3J9GLWnKUzkZmtmZD9TzU xxAgJyzzXK6zMjZW4t2f5v9rYnTMFP3liXJKscxZmJEf/s2YaLFddW7UBqP0j0YTnqlP Qu6IVDPGpdkCWuoh8WybXswUGwRzxbqRi6xeUYQm1sojZY5hnr63DFuAG0ZV84wVYWh4 ZESw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1fcPXxDEhmYSVJ/ogmtstCSuQ+WzYE2nDHQCiZjQDD0=; b=CbM7pLeiM3F/Q1H9NbRB4w2BxXkVQbsJFCgp0AyRxKXbpWGu6b3BmAqVhbPZ0i+KUk f09/DsbjwsJRJ5wCM/dk2GU3e8JCtlPhpWkIc/pyVdHnJTSGQYdxrxr9p+P+LZKZQxWs 0//3Y0135w0hlrQeQvFiS2CnDWnu76qbxMwM0UMTpqZ+2Qncglf368etT7NNm9v1KA66 TdFlf03I7r0p5BsHJ8b21KVoJc4nedMRutne2Fq+Fn+0wpOj40NoKBIXUTZQ089lIpmS CLwsluCGyW75IOqksTF5VbEWffhgiyL/MJ7HcHhlDKGUI2nJSoIiyD9RIu9e9HxVjSlv gxnw==
X-Gm-Message-State: AOAM531Q0h8VURI/al6AUUtG7q2cT1n/arIaTFJTmBcVTiB+QVxQNnFR L29Ze39d/cDRTjahXSzWs9h/PSHE7a/TXatLmOs=
X-Google-Smtp-Source: ABdhPJy2L7I2Z42qRU6Ahtbl6u05JBpfalVtp87j/qF3beFSlSgLFOdfMTwIroRaamPorT0G5d3XxA7Uvqm7MOY58b4=
X-Received: by 2002:a17:902:ccc3:b0:15a:2d52:78fe with SMTP id z3-20020a170902ccc300b0015a2d5278femr4590253ple.58.1650483465829; Wed, 20 Apr 2022 12:37:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5bC95SwqbPC-Fm1-bTyAmaVOb-O5Bg4CKqe3tSe=LUzZQ@mail.gmail.com> <CAH6gdPwrwXosAUqShGxqW-ODXO0jqLRpa3_x-1cu3aay=Z19ig@mail.gmail.com> <CABNhwV3ri7HeAqPQDCYcyk3P9=sSQsZWNxpeAdbaKQ5v04PKjw@mail.gmail.com> <CAH6gdPxF+xYueq76XPP2tVTy+sJjsGa5bD8khx94cxaTUuQNCw@mail.gmail.com>
In-Reply-To: <CAH6gdPxF+xYueq76XPP2tVTy+sJjsGa5bD8khx94cxaTUuQNCw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 20 Apr 2022 15:37:35 -0400
Message-ID: <CABNhwV0fCOwwYqs17DjPSXABy7f89eKO-Fc=c8k7vD6JT9fryQ@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Dhruv Dhody <dd@dhruvdhody.com>, draft-li-pce-pcep-pmtu@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b041cb05dd1b20a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/znidL3wgveL9g-zs8b6kyNEPEtw>
Subject: Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2022 19:37:52 -0000

Hi Ketan

Please see in-line

Thanks

On Wed, Apr 20, 2022 at 7:10 AM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Hi Gyan,
>
> Please check inline below.
>
>
> On Wed, Apr 20, 2022 at 10:08 AM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
>>
>> Hi Ketan
>>
>>
>> On Mon, Apr 4, 2022 at 10:05 AM Ketan Talaulikar <ketant.ietf@gmail.com>
>> 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?

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

>
> 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 <dd@dhruvdhody.com> 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
>>>> Pce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pce
>>>>
>>> _______________________________________________
>>> Pce mailing list
>>> Pce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pce
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*