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

[tom petch <[e-mail]>]

From: Pce <[e-mail]> on behalf of [e-mail] <[e-mail]>
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'

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
[e-mail]
https://www.ietf.org/mailman/listinfo/pce