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

Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 07 April 2022 16:28 UTC

Return-Path: <ketant.ietf@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 9B6833A10AA; Thu, 7 Apr 2022 09:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MHe8hwY8i2v8; Thu, 7 Apr 2022 09:28:33 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 EE8423A10E8; Thu, 7 Apr 2022 09:28:32 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id t6so4155045vsq.11; Thu, 07 Apr 2022 09:28:32 -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=jYAz4R9JxtCed4fLXEzyW9VWsuh0idViuUifuzWmMP4=; b=C3mW0W4Hg3M9r6YRl2gg6QfKrLSzX1/0+Yeygt1+RXLbhM1LrZ16VG6s75PNSuJ2YA MHpOdwLCfNiLNXDK/rhKGtU8utctHGRWaROGIFjG42ibT5lo4xEgxtqq84oYOGHo1/18 rjeBtgdRx3iDcJg6mMmY2gNikVdKOMYSoRPQNNRzncK4scxOT/sB+X3jFbLBoXfVuoi3 gF4vM9OYYInsVbQTpfRduy+EJCBPWEvVXGdCebFZ6Bc2GFnzTLG6WwCG0yijCeU1dk/+ Q7QlXfPRSFVdDsa4p/6LYvYx7J9uDzRtm32D8qkwzxIIjYvDOMfKxNpbdIaEA+EW3pP0 2JgA==
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=jYAz4R9JxtCed4fLXEzyW9VWsuh0idViuUifuzWmMP4=; b=0Wkk8cBsRsuGBVJ3LcjsgluzEo3i6srbOrlYXGu/4dKOVltPXXgHn6AYBHzshrTec9 97jDTJfEZHBW+6ffohZWG+9Tyw5M2B2Hrh5uyMC5BMd9DfBadhbZV3Ww3tPyUJl6uqXL zoVdYcGh9gz4Jx5E6zzziDdYMineQ70lvpy3THOMg4taFquY/NZ9q3Djz+viwrrobMnw STggQHHsQFy2rPey7N6+W7OFJ6jJvXNkgBc1L9k2VzerUAMvVe2d+2UKX0CiBegXow25 kO8Y0cY1ukV17qWFsYuDIw7eAEF7Kog83/YiCLhi0VxQsXzWEaXmHM2hGpzKx/KEhYZ1 yfcQ==
X-Gm-Message-State: AOAM530s172FhopgAtMgvkvFNi5Nf3hbr6+WrbrDKLFbLN2NqsHv3Z7S 53xN0p3HcMFXj12rJ/WPIQ97B4utsQ/GxsIl8haYTf9P
X-Google-Smtp-Source: ABdhPJwYqd8X18YZXk3Sj+K9dwpKhNy8H7rNZ8DFgSc990VG/Hb/Z89hYzPrYeiG8sbzbmR9B5+dENJ5bpuflXeXCWI=
X-Received: by 2002:a67:c893:0:b0:325:5b5d:d1dd with SMTP id v19-20020a67c893000000b003255b5dd1ddmr4845052vsk.33.1649348911746; Thu, 07 Apr 2022 09:28:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5bC95SwqbPC-Fm1-bTyAmaVOb-O5Bg4CKqe3tSe=LUzZQ@mail.gmail.com> <CAH6gdPwrwXosAUqShGxqW-ODXO0jqLRpa3_x-1cu3aay=Z19ig@mail.gmail.com> <5a05dde4a5b947b2af89cf95073a75d0@huawei.com>
In-Reply-To: <5a05dde4a5b947b2af89cf95073a75d0@huawei.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 07 Apr 2022 21:58:20 +0530
Message-ID: <CAH6gdPyYxUKwekwEY7rt7Fn2m6bd9ebrTjprCz9VzWqLfoPNGw@mail.gmail.com>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
Cc: Dhruv Dhody <dd@dhruvdhody.com>, "pce@ietf.org" <pce@ietf.org>, "draft-li-pce-pcep-pmtu@ietf.org" <draft-li-pce-pcep-pmtu@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fed39405dc12f75e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/TyCKBEeOJG_hEze8zve_WOymgoY>
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: Thu, 07 Apr 2022 16:28:46 -0000

Hi Shuping,

Please check inline below.


On Thu, Apr 7, 2022 at 8:22 AM Pengshuping (Peng Shuping) <
pengshuping@huawei.com> wrote:

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


>
>
> 3)      Yes, this is applicable for both RSVP-TE and SR Policy.
>
>
>
> Thank you!
>
>
>
> Best Regards,
>
> Shuping
>
>
>
>
>
>
>
> *From:* Ketan Talaulikar [mailto:ketant.ietf@gmail.com]
> *Sent:* Monday, April 4, 2022 10:05 PM
> *To:* Dhruv Dhody <dd@dhruvdhody.com>
> *Cc:* pce@ietf.org; draft-li-pce-pcep-pmtu@ietf.org
> *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?
>
>
>
> 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 <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
>
>