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

[Dhruv Dhody <[e-mail]>]

Hi Aijun,

If you have a need for an early allocation, please send an email to
[e-mail] 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 <[e-mail]> 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 <[e-mail]> wrote:
>
>
> From: Aijun Wang <[e-mail]>
> 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 <[e-mail]> wrote:
>
> From: Aijun Wang <[e-mail]>
> 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: [e-mail] <[e-mail]> On Behalf Of tom petch
> Sent: Monday, May 22, 2023 7:35 PM
> To: Dhruv Dhody <[e-mail]>; [e-mail]
> Cc: pce-chairs <[e-mail]>;
> [e-mail]
> Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20
>
>
>
> From: Pce <[e-mail]<mailto:[e-mail]>> on behalf
> of Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
>
> 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
>
> [e-mail]<mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/pce
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>