Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Tom,

Thanks, please see inline.

Cheng

-----Original Message-----
From: tom petch [mailto:ietfc@btconnect.com] 
Sent: Monday, March 22, 2021 8:02 PM
To: julien.meuric@orange.com; pce@ietf.org
Cc: draft-ietf-pce-binding-label-sid@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

From: Pce <pce-bounces@ietf.org> on behalf of julien.meuric@orange.com <julien.meuric@orange.com>
Sent: 18 March 2021 11:08

Hi all,

This message initiates a 2-week PCE WG Last Call for draft-ietf-pce-binding-label-sid-07. Please review and share your feedback, whatever it is, using the PCE mailing list. This WGLC will end on Thursday April 1st (no kidding).

<tp>
I find the terminology imprecise and in need of tightening up.

S.11.1.1 uses MPLS Label and MPLS Label Stack Entry as does RFC3032 which is as it should be.

Elsewhere the I-D uses binding label/SID without ever being precise about its meaning.  It needs defining  or expanding to binding MPLS label/SID or probably being replaced by something neater.

s.1 uses binding MPLS label; what is the difference?

Binding value is then defined which seems to me to make binding label/SID and unnecessary mouthful.

s.3 has binding label or SID as well as MPLS label binding

this section also uses 'MPLS label' - good - but then spoils it by using label unqualified

It then uses MPLS label entry which would appear to be a reference to an MPLS label stack entry

Likewise label stack entry would appear to mean MPLS label stack entry

s.4 uses MPLS label binding

The problem comes with loose terminology when e.g. a document is up for revision and future readers wonder why, if the same concept is being referred to, does the terminology keep changing, which sometimes just leads to a waste of time, other times to errors in implementation.

Since label has overtones of MPLS whereas SID is clearly SR, then I think you need a different term when you mean one or the other.  I think that 'binding value' as used in at least one place is a better choice, with an explanation thereof early on in the introduction. 'Binding value is used here to refer to an MPLS label or an IPv6 SID as appropriate'

[Cheng]I have added - 

In this document, binding label/SID is used to generalize the allocation of binding value for both SR and non-SR paths.

Removed - 
- binding MPLS label
- binding label or SID   
- MPLS label binding

Made some other correction. Hope the above clarification and cleanup is enough. 

Also,
- Binding value is the term when refering to the specified value in the TLV 
- binding label/SID is used in the generic sense 
I find this to be useful distinction. 

Thanks! 
Cheng

Tom Petch

Moreover, we have received a request from the authors for a code point allocation to support interoperability testing.

RFC 7120 requires to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft.
c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria, or believes that early allocation is not appropriate for any other reason, please send an email to the PCE mailing list explaining why. If the chairs hear no objections by Thursday, March 25th, we will kick off the "early" allocation request.

Thanks,

Dhruv & Julien

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce