Subject: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

From: <[email-masked]>
Date: Mon, 1 Feb 2021 11:54:34 +0100

Hi WG,

We have received a request from the authors of
draft-ietf-pce-segment-routing-policy-cp for an early code point allocation.

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 Monday, February 15th, we will kick off
the early allocation request.

Thanks!

Dhruv & Julien

---

From: tom petch <[email-masked]>
Date: Sat, 6 Feb 2021 12:06:31 +0000

From: Pce <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 01 February 2021 10:54

Hi WG,

<tp>

Which code point or code points?

This I-D asks IANA to allocate eleven values; to which of these does the early allocation request apply?

Tom Petch

Thanks!

Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Sun, 7 Feb 2021 10:06:10 +0530

Hi Tom, WG,

> This I-D asks IANA to allocate eleven values; to which of these does the early allocation request apply?

All of them.

This I-D is asking for allocations from 3 existing sub-registries:

ASSOCIATION Type Field
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-02#section-7.1)
https://www.iana.org/assignments/pcep/pcep.xhtml#association-type-field

PCEP-ERROR Object Error Types and Values
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-02#section-7.2)
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object

PCEP TLV Type Indicators
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-02#section-7.3)
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators

Please feedback to the list if you feel the RFC 7120 criteria listed
in the original email does not meet any (or all) of the codepoints
allocation requests.

Thanks!
Dhruv & Julien

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: tom petch <[email-masked]>
Date: Wed, 17 Feb 2021 11:46:28 +0000

From: Dhruv Dhody <[email-masked]>
Sent: 07 February 2021 04:36

Hi Tom, WG,

All of them.

ASSOCIATION Type Field

PCEP TLV Type Indicators

<tp>
I am sure that IANA will cope because they always do, but it will be by reading between the lines, applying intelligence to what the authors may have meant, and so on.  Editorially this is a poor I-D (as yet), and that quality verges on the technical aspects.

Thus 7.3 says the I-D defines five new TLV and lists four; this also occurs in the body of the I-D.  A reader might also notice the absence of TBD2 and wonder.

Or the new Association.  Thus needs an identifier.  Trouble is, the I-D uses (at least) three different ones; this looseness of terminology can lead to problems down the line.  (MPLS I see as a classic in how not to specify IANA registries and I see this heading the same way).

Likewise the identifiers used in s.7 do not match those in current use, a good way of storing up future trouble.

Is the specification adequate?  Only if you do not take it literally and interpret the words the way you think they should have been.

Tom Petch

Thanks!
Dhruv & Julien

---

From: <[email-masked]>
Date: Thu, 18 Feb 2021 11:35:05 +0100

Hi Tom,

Thank you for your valuable feedback.

Some of the issues you point out are easy to address and we've already
requested the authors to revise the I-D accordingly. To fully resolve
your concern, could you please point any other specific parts where you
feel you have to "interpret the words the way you think they should have
been"? If you even have some text to suggest, that could smoothly ease
the update.

Thanks,

Dhruv & Julien

On 17/02/2021 12:46, tom petch wrote:
> <snip>

_________________________________________________________________________________________________________________________

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.

---

From: tom petch <[email-masked]>
Date: Fri, 19 Feb 2021 12:30:53 +0000

From: [email-masked] <[email-masked]>
Sent: 18 February 2021 10:35

Hi Tom,

<tp>
At a first glance,

s.7.1
RFC8697 names three  columns for the registry; those names do not appear here.

The new association type is given a different identifier in different places.  The preferred identifier needs to be nailed down since it is going into IANA forthwith and will be confusing to change thereafter.

s.7.2
This requests new error values  under Association Error  and specifies a Type of 29.  RFC8697 specifies a Type of 26 (29 is Path Computation Failure).

'Conflicting SRAG TLV' I find rather vague; conflicting with what?  Likewise 'Multiple SRPAG from one LSP'

s.7.3
This document defines five new TLVs
That is TBD3, TBD4, TBD11, TBD5 and ....

RFC8697 specifies the names of the fields in the registry,  Those names are not used here.

s.3.2 
'as of the time of writing' will change its meaning as the I-D progresses; date needed

s.4.1
'is only meant to be used'
MUST NOT, SHOULD NOT, .....?

'Policy Identifiers uniquely identify..
Policy Identifiers consist of Color.. Endpoint, optionally the policy hame.
So if one is Color red, Endpoint NY no policy name
and then one is requested for
Color red, Endpoint NY, policy name standby
that is a different triplet and so valid.  Mmm. I can see that being mis-implemented

s.4.2

'is meant to strictly correspond'
MUST, SHOULD, ?

s.5
This document specifies four new TLVs...
These five TLVs .....

These five TLVs encode the Policy Identifiers, SR Policy name, Candidate path identifiers, candidate path name and Candidate path preference..
That is five TLV. Wrong! That is four TLV and something completely different.

When any of the mandatory TLVs
Only one TLV is listed as mandatory SRPOLICY-CPATH-ID.

s.5
At most only one .. can be carried
and then goes on to describe the carriage of  more than one;
'Only one ... SHOULD be present in a ... (whatever identifier you fix on) message.  If more than one is present, only the first is processed and subsequent ones are silently discarded.

A Normative Reference to an unadopted I-D that expires next week is not a good look:-)

Like I said, the word that came to my mind was 'sloppy':-(

Tom Petch

Thanks,

Dhruv & Julien

---

From: tom petch <[email-masked]>
Date: Sat, 20 Feb 2021 12:33:21 +0000

From: Pce <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 19 February 2021 12:30
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

Hi Tom,

<tp>

The more I look, the less I like it.

This I-D asks for an error code for missing mandatory TLV, a category which PCE has defined  as Error-Type 6 and is referenced  by such as pce-vn-association.

Why does this I-D put missing mandatory TLV in a different Error-Type?

I will raise some more issues next week.

Tom Petch

<tp>
At a first glance,

s.7.1

s.7.2

s.7.3

s.3.2

s.4.1

s.4.2

s.5

s.5

Tom Petch

Thanks,

Dhruv & Julien

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Mon, 22 Feb 2021 11:16:31 +0000

Hi Tom,

Thanks a lot for your review, the -03 version should address your prior comments. Please log any new comments against the -03 version.

Thanks,
Mike.

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of tom petch
Sent: Saturday, February 20, 2021 7:33 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

Hi Tom,

<tp>

Tom Petch

Some of the issues you point out are easy to address and we've already requested the authors to revise the I-D accordingly. To fully resolve your concern, could you please point any other specific parts where you feel you have to "interpret the words the way you think they should have been"? If you even have some text to suggest, that could smoothly ease the update.

<tp>
At a first glance,

s.7.1

s.7.2

s.7.3

s.3.2

s.4.1

'Policy Identifiers uniquely identify..
Policy Identifiers consist of Color.. Endpoint, optionally the policy hame.
So if one is Color red, Endpoint NY no policy name and then one is requested for Color red, Endpoint NY, policy name standby that is a different triplet and so valid.  Mmm. I can see that being mis-implemented

s.4.2

s.5

s.5
At most only one .. can be carried
and then goes on to describe the carriage of  more than one; 'Only one ... SHOULD be present in a ... (whatever identifier you fix on) message.  If more than one is present, only the first is processed and subsequent ones are silently discarded.

Tom Petch

Thanks,

Dhruv & Julien

---

From: tom petch <[email-masked]>
Date: Mon, 22 Feb 2021 12:21:58 +0000

From: Pce <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 20 February 2021 12:33

Hi Tom,

<tp>

<tp2>
Next week and I like this I-D even less.

The I-D says repeatedly that only one instance of a particular TLV is allowed and others must be ignored.  Where the TLV is optional, this may make sense but where it is mandatory and forms part of the identifier then I think this wrong.  The sender is in effect saying I am confused about which association I am referring to (as indicated by including more than one).  That should be an error IMHO.

In passing I find the error messages poor.  I was looking at 
draft-ietf-pce-associated-bidirectional-lsp
and thinking how clear and easy to understand those error messages are, which I would not say of this I-D; the authors should look and learn.

A more significant problem is the identification of policy.  I assume that when this I-D talks of policy then it means SR policy.  (Sometimes it says so, sometimes it does not - needs fixing.)  This I-D says that a policy identifier consists of color, endpoint and optionally name.  

This raises a number of issues.  I raised earlier the point that an optional label as part of an identifier is a good candidate for erroneous implementations.  In fact it is more challenging than that.  The topic of optional keys came up in the development of YANG, were considered and rejected.  I forget the reasoning, whether they led to logical impossibilities or were too error-prone to implement or what, but they are not allowed.  So you cannot model in YANG anything with an optional key which is what this I-D seems to propose.

Separately, this I-D seems to contradict 
draft-ietf-spring-segment-routing-policy
which is clear that an SR policy is identified by the tuple <headend, color, endpoint> which is not what this I-D says (and which, in passing,  can be modelled in YANG).  Yes this PCE I-D mentions the context of headend but does not say where that should be inferred from to form the unique SR Policy identifier.

As you may infer, I do not see this I-D as fit for an early IANA allocation.

Tom Petch

<tp>
At a first glance,

s.7.1

s.7.2

s.7.3

s.3.2

s.4.1

s.4.2

s.5

s.5

Tom Petch

Thanks,

Dhruv & Julien