Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

Dhruv Dhody <dd@dhruvdhody.com> Wed, 24 May 2023 16:49 UTC

Return-Path: <dd@dhruvdhody.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 385C3C1CCCB1 for <pce@ietfa.amsl.com>; Wed, 24 May 2023 09:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20221208.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYWeXBby-0Xg for <pce@ietfa.amsl.com>; Wed, 24 May 2023 09:49:11 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6DCC151555 for <pce@ietf.org>; Wed, 24 May 2023 09:49:11 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-783e5c64d29so19419241.1 for <pce@ietf.org>; Wed, 24 May 2023 09:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20221208.gappssmtp.com; s=20221208; t=1684946950; x=1687538950; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8l6mEZxcpEbPagHD4z0X0vaKAP9qtW3GpUaV7rkqNYA=; b=oPxbMhh9UfHT6BESjUp3K/6KqWfEqGC6/5kchk6DDOUd8RDlQXfiYLpWdb8fWLLuvK nwNprEoTm69sSijawrg//r+dP5qrKmQmuFyAmwNzaEvC3KZJmaNjOzN5ZH3NZM+b8Pry UBOBsSMkunVbNgAta6j+jyUY/+UlAacrklCbFmtqWqpeyNZh2p1Hju0ByL3gssWfaWLL 2LQiQDmXB/T1kRcRCY5SqAoXctyJgS1u91xByC+DxxFmh1CS60n+JXqEmuOqSlq7A8mC Jwk8inK4vnhJY0iv1EfIhu3Ep7CPBP938sHzkQYPRlPxxZD/oi98FTsrrJDjMZbTfEh3 LRZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684946950; x=1687538950; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8l6mEZxcpEbPagHD4z0X0vaKAP9qtW3GpUaV7rkqNYA=; b=QQQKY9q4zijVjGytP8VM+GsKt3+688aQWCzUBsgDV96irj19tR+rfXfPy9VbIqIFLL CUSEY0oub3QOWkfnzg404JGBYjWCpmsnd2d4UGkDUwwuC1BZcK0CY3G2a8RY3Unw0K/h hVMm1GOKVVzBtgkCULdDzXIu8GWewKnvWbnI3vzjfrIhTfvA0uy7lznqBYwj5awWVBSQ cTpcG2gToSO3qDO85EC6bre86xTQ7Hrr3/N0tB27jBOB5JJ8wIggfC+mzuSFr0mmcFAP KnEW5ZuaXbAY2b4nmqBrQivxuVjc1zr+F+o4t0yrAe7Q1py0yla8UJHTHa1SmQzi0eLc i4Yg==
X-Gm-Message-State: AC+VfDxX+FIeNOXy4eH99X38VxK2WizAqzXXhn87hda85qNtI0eSih+9 T2VYfKDVuLBp5XiEBbCEFK+UceVvw/Idk6sLbyQdVA==
X-Google-Smtp-Source: ACHHUZ6LoIrxI1ZIGc5mHeTqTdVYbmQhHyTJCf7mqQr/tnDvBucX7+E4YUDVie4KMTKYTq5y34t9FpS7y2ntps7aOdA=
X-Received: by 2002:a05:6102:55a1:b0:439:3e8a:1c07 with SMTP id dc33-20020a05610255a100b004393e8a1c07mr27533vsb.1.1684946950629; Wed, 24 May 2023 09:49:10 -0700 (PDT)
MIME-Version: 1.0
References: <20230524171242.31EC690007C@mail-m121149.qiye.163.com> <FD954DC3-8DFC-4C27-9C66-8A10EA126F40@tsinghua.org.cn> <AM7PR07MB6248EA3616D98B7C7DD42047A0419@AM7PR07MB6248.eurprd07.prod.outlook.com> <988700032.173668.1684943330777@www.getmymail.co.uk>
In-Reply-To: <988700032.173668.1684943330777@www.getmymail.co.uk>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Wed, 24 May 2023 22:18:34 +0530
Message-ID: <CAP7zK5by_XAohk8LE+zBUFdpzVkWMGPbEDAy3fEg6QaXa2=NLg@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: tom petch <ietfc@btconnect.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "pce@ietf.org" <pce@ietf.org>, "huaimo.chen@futurewei.com" <huaimo.chen@futurewei.com>, pce-chairs <pce-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000075406e05fc7348b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/mA8UObMKZ9d1ZvFpKhHtpLMY-dc>
Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
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, 24 May 2023 16:49:13 -0000

Hi Aijun,

If you have a need for an early allocation, please send an email to
pce-chairs@ietf.org and we will follow
https://datatracker.ietf.org/doc/html/rfc7120#section-3

But note that as per your Implementation Status [
https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-native-ip-21.html#section-12]
there are no known implementations though!

Thanks!
Dhruv

On Wed, May 24, 2023 at 9:19 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> In the past, I would have agreed with Tom on this.
>
> But we are routinely seeing a pause of more than 200 days between a WG
> issuing a Publication Request and the AD starting their review (which leads
> to updates and discussion before IETF last call). IANA don't do their
> provisional assignments until IETF last call.
>
> If there are implementations of what is presumably a stable draft, I think
> early assignment is reasonable. It shouldn't take more than 10 minutes of
> the chairs' and AD'S time.
>
> Cheers,
> Adrian
>
> On 24/05/2023 16:33 BST tom petch <ietfc@btconnect.com> wrote:
>
>
> From: Aijun Wang <wangaijun@tsinghua.org.cn>
> Sent: 24 May 2023 16:02
>
> As I remember, it is the IANA first allocate the necessary values, then go
> to the RFCEditor.
>
> Can we ask the IANA to (early) allocate the value now?
>
> <tp>
> At this stage in the process, I doubt if it is worth the extra work. Such
> a request goes via chairs and AD. I see it more when users want to
> implement and it may be some time before the I-D gets to the stage that
> this one is now at. And later reviews - Last Call, IESG - may come up with
> changes to the TBDnnn that then confuse the picture. I prefer the 'normal'
> process but with perhaps a bit more of a nudge to the RFC Editor to make
> sure that they pick up all the usages e.g. pointing out to the RFC Editor
> up front or in the IANA Considerations that there are many TBDnn in the
> body of the I-D.
>
> Thinking about it, I am a bit hazy on the normal process between IANA and
> RFC Editor. The e-mails that I see are when things go wrong and either the
> RFC Editor or IANA (or both) are unclear as to what is intended and need
> guidance from the WG
>
> Tom Petch
>
> Aijun Wang
> China Telecom
>
>
> On May 24, 2023, at 17:12, tom petch <ietfc@btconnect.com> wrote:
>
> From: Aijun Wang <wangaijun@tsinghua.org.cn>
> Sent: 23 May 2023 07:59
>
> Hi, Tom:
>
> Thanks for your review.
>
> I have uploaded the new version to address your comments.
>
> I am trying to find some more convenient methods to describe the
> un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't
> be "too easy to miss"?
>
> My purpose is that once the IANA allocates the value to each of these
> values according to our requests (
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)
>
>
> , I can replace them easily in the updated version.
>
> <tp>
>
> Mmm I did look at other I-D for another way but think that this is unusual
> in the number of TBDnnn in the body of the I-D, not in the IANA
> Considerations. I did not see a request for early allocation so the values
> will not be assigned until the I-D is about to leave the RFC Editor Queue
> so it is the RFC Editor, not you, who has to find all the instances of
> TBDnnn and replace them. Common practice is to add a
> -- Note to the RFC Editor
> in each and every place where such action is needed outside the IANA
> Considerations. There are a lot of them; 44 I think. I think that at least
> there should be a Note to the RFC Editor in IANA Considerations to the
> effect that these values appear in many places and need editing.
>
> I will post separately a concern about BGP session setup.
>
> Tom Petch
>
>
> For the interaction between BGP and PCEP, we think the paces or procedures
> described in this document can be controlled by the PCE------Once the PCE
> sends the command to PCC, it will collect the status of such command. Only
> when the previous command is executed successfully, then the next command
> can be issued. Section 6 cover the descriptions of main procedures.
>
> For your other comments, please see replies inline.
>
>
>
> Huaimo also gives us more valuable suggestions to refine the document
> offline. I have also incorporated them together in the updated version.
>
>
>
> Thanks all you together!
>
>
>
> Future reviews from other experts can be based on the updated version.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> -----Original Message-----
> From: pce-bounces@ietf.org <pce-bounces@ietf.org> On Behalf Of tom petch
> Sent: Monday, May 22, 2023 7:35 PM
> To: Dhruv Dhody <dd@dhruvdhody.com>; pce@ietf.org
> Cc: pce-chairs <pce-chairs@ietf.org>;
> draft-ietf-pce-pcep-extension-native-ip@ietf.org
> Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
>
>
>
> From: Pce <pce-bounces@ietf.org<mailto:pce-bounces@ietf.org>> on behalf
> of Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>
>
> Sent: 16 May 2023 23:15
>
>
>
> This email starts a 2-weeks working group last call for
> draft-ietf-pce-pcep-extension-native-ip-20 [1].
>
>
>
> <tp>
>
> I had a look and decided that it is mostly beyond me - I am not up to
> speed with all the 15 Normative References, in particular with RFC8821. I
> would prefer that this I-D provided a better bridge to the material in
> RFC8821.
>
>
>
> I note that RFC8821 is an as yet unapproved downref which reinforces that
> view.
>
>
>
> I note too that the Abstract references this and 8735 as anchors which
> Abstracts must not do.
>
> [WAJ] Remove the anchors in the abstract.
>
>
>
> The I-D uses the word 'draft' in many places. These must be changed.
>
> [WAJ] Changed the "draft" to "document" within the entire document.
>
>
>
> The I-D has a large number of TBDnnn with no note requesting that they are
> replaced; I find these easy to miss.
>
> [WAJ] Do you have any suggestions that can't be "easy to miss"?
>
>
>
> p.9 2)
>
> seems to end mid-sentence.
>
> [WAJ] Updated
>
>
>
> The English is not quite in several places and could be confusing. Thus
> p.5 "Further only one
>
> of BPI, EPR, or PPA object MUST be present. "
>
> I can interpret in two ways although subsequent text makes one the
> preferred one.
>
> [WAJ] Change the phrase to "Further only one and one kind of BPI,EPR, or
> PPA object MUST be present", is it better?
>
>
>
> I suspect that there are many potential interactions with BGP, especially
> when things are not going quite right, and that the I-D does not cover them
> all. The language used is not that of BGP (e.g. Established, speaker). The
> timing too of BGP can be quite slow, in setup and in shutdown and I wonder
> how a PCC copes with that.
>
> [WAJ] Once the PCC receives the PCInitiate message that include BPI (BGP
> Peer Info) object, it will try to build the BGP session between the peers
> that indicates in the BPI object. Only when it establishes the BGP session
> successfully, it will report the PCE via the PCRpt message(as that
> described in section
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-6.1)
> Then the PCE can send other instruction to the PCCs. Actually, the
> procedures described in this document is asynchronous.
>
>
>
>
>
> As I say, largely beyond me but the English needs some attention; using
> the terminology of BGP would help.
>
>
>
> Tom Petch
>
>
>
>
>
> Please indicate your support or concern for this draft. If you are opposed
> to the progression of the draft to RFC, please articulate your concern. If
> you support it, please indicate that you have read the latest version and
> it is ready for publication in your opinion. As always, review comments and
> nits are most welcome.
>
>
>
> The WG LC will end on Wednesday 31st May 2023. We will also notify the IDR
> WG about this WGLC.
>
>
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption and help us unclog our queues :)
>
>
>
> Thanks,
>
> Dhruv & Julien
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
>
>
>
> _______________________________________________
>
> Pce mailing list
>
> Pce@ietf.org<mailto:Pce@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/pce
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>