Subject: [Pce] cursory review of draft-xiong-pce-lsp-flag

From: Loa Andersson <[email-masked]>
Date: Wed, 29 Jul 2020 16:07:07 +0800

Quan,

I have not done a comprehensive review of the document, but from what I
see it is a well written and much needed document. I would advice to run 
the working group adoption poll as soon as possible.

I have one comment and one question.

Comment:

5.2.  PCEP-Error Object

    IANA is requested to register the following error types and error
    values within the "PCEP-ERROR Object Error Types and Values"
    subregistry of the "Path Computation Element Protocol (PCEP) Numbers"
    registry:

           +--------------+-------------------------------------+
           |  Error-Type  |  Meaning                            |
           +--------------+-------------------------------------+
           |  6           |  Mandatory Object missing           |
           |              |  Error-value                        |
           |              | TBD2: LSP-EXTENDED-FLAG TLV missing |
           +--------------+-------------------------------------+

                                   Table 2

Both the RTG DIR rules and IANA rules strongly advice against putting
fixed numeric  values into allocation from existing registries. The
reason is obvious, in the time from you put the value in your document
until iet is ready for IESG review (which includes IANA review) someone
else might have been assigned tht value. This has happened and have
caused serious problems.

6 in table 2 hould be replaced with TBA (to be assigned).

Note: If you really want the value 6, we should go for an early
allocation as soon as we have the wg document.

Question:

In section 4 you say:

    The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router
    supporting the LSP Object and needs to use the extended flag field.

I don't really parse; are you saying that if it is present it should be
treated as mandatory?

If that is what you are saying, what does it change?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 29 Jul 2020 14:31:17 +0530

Hi Loa,

>     subregistry of the "Path Computation Element Protocol (PCEP) Numbers"

[Dhruv] The value 6 is for Error-Type already allocated by RFC 5440.
This I-D is asking for a new Error-Value which is  TBD2. A reference
column in the IANA table would have helped here.

> If that is what you are saying, what does it change?

[Dhruv]: I read it as a requirement for a future extension that would
define a flag in the LSP-EXTENDED-FLAG TLV.

If that is true, I would suggest not using normative MUST. How about -

A future extension that defines a flag in the LSP-EXTENDED-FLAG TLV
could mark this TLV as mandatory to be carried the LSP Object.

Thanks!
Dhruv

---

From: Loa Andersson <[email-masked]>
Date: Wed, 29 Jul 2020 18:43:25 +0800

Dhruv,

Inline please.

> column in the IANA table would have helped here.

hmmmm - okey, but no, we are asking IANA to register a new error-value,
but not a new error type. The text says:

   "IANA is requested to register the following error types and error
     values ..."

But then the table is very unclear, at a minimum it should look
something like this:

   +-------------+----------------------------+-------------------------+
   |  Error-Type | Meaning                    | Error-value             |
   +-------------+----------------------------+-------------------------+
   |  6          | Mandatory Object missing   | 0: Unassigned           |
   |             |                            | 1-15 Assigned           |
   |             |                            | TBD2: LSP-EXTENDED-FLAG |
   |             |                            |       TLV missing       |
   +-------------+----------------------------+-------------------------+

                                      Table 2

> could mark this TLV as mandatory to be carried the LSP Object.

I have been reading a bit more, but this is still unclear to me, if I
understand it will still be valid to send without the extended TLV
(if you don't need the flags). How are you deciding if the extended TLV
missing?

/Loa

--

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 29 Jul 2020 16:45:03 +0530

Hi Loa,

>    "IANA is requested to register the following error types and error

This text is incorrect then and should be fixed.

> But then the table is very unclear, at a minimum it should look
Yes. I suggest Quan to look at -
https://www.rfc-editor.org/rfc/rfc8800.html#section-7.5 as a good
reference from a recent published RFC.

> (if you don't need the flags).

Yes! Maybe we should not use the word "mandatory" then!

As it is "mandatory" in the context of using a new feature defined in
a future extension -- so to use the new feature, an implementation
MUST include the LSP-EXTENDED-FLAG TLV and MUST set a particular flag.
The so-called "mandatory" would be only in the scope of the protocol
extension and not required when the feature is not used.

> How are you deciding if the extended TLV
> missing?
>

This could be because of the presence of some other object/TLVs needed
by the same extension but without the LSP-EXTENDED-FLAG TLV in the LSP
object.
Perhaps the right thing to do would be to move the error handling to
the first document that uses the LSP-EXTENDED-FLAG TLV instead of this
document.

Thanks!
Dhruv

---

From: <[email-masked]>
Date: Thu, 30 Jul 2020 10:30:42 +0800 (CST)

Hi Dhruv and Loa,

Thanks for your review and detailed discussion!

For the IANA text, I will update that as you suggest.

In my view, we need to clarify the LSP-EXTENDED-FLAG TLV is mandatory or not firstly. Then consider the error handling.

There are two cases.

First case, for the implementations which just use the Flag field of  LSP Object from  bit 1 to bit 11, it has no need to carry LSP-EXTENDED-FLAG TLV and not mandatory.

Second case, for the implementations which will use the flag of LSP-EXTENDED-FLAG TLV, It is mandatory.  When LSP-EXTENDED-FLAG TLV is missing, the error handling should be taken into consideration.

I suggest to make clarification in the draft about the implementations 

or use the bit 0 of Flag field in LSP Object to indicate the existing of the LSP-EXTENDED-FLAG TLV?

Could you tell me what is your suggestion?

Thanks,

Quan

原始邮件

发件人：DhruvDhody <[email-masked]>
收件人：Loa Andersson <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年07月29日 19:15
主 题 ：Re: cursory review of draft-xiong-pce-lsp-flag

Hi Loa,

Thanks!
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 30 Jul 2020 11:16:36 +0530

Hi Quan,

>From the point of view of this I-D there are no flags defined in the
LSP-EXTENDED-FLAG TLV yet.

Also, Loa rightly pointed out that any text would be incomplete as an
implementation that just receives an LSP object without the
LSP-EXTENDED-FLAG TLV would not know if it is the first "valid" or the
second "error" case in your text above just by the fact that the TLV
is missing. The error would be noticed in conjunction with some other
encoding required by the extension.

So my suggestion would be to move the error handling to the first
document that defines the flag in LSP-EXTENDED-FLAG TLV. We have
documents that need to use it right away so this should not be a
problem, just some coordination.

Thanks!
Dhruv

---

From: <[email-masked]>
Date: Thu, 30 Jul 2020 14:00:37 +0800 (CST)

Hi Dhruv,

Thanks for your quick reply and suggestion!

The  LSP-EXTENDED-FLAG TLV is not mandatory and I will modify and move the error handing to the draft-peng-pce-entropy-label which needs to use the flag.  I will update the drafts as you suggest as soon as possible!

Thanks,

Quan

原始邮件

发件人：DhruvDhody <[email-masked]>
收件人：熊泉00091065;
抄送人：Loa Andersson <[email-masked]>;[email-masked] <[email-masked]>;pce-chairs <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年07月30日 13:47
主 题 ：Re: cursory review of draft-xiong-pce-lsp-flag

Hi Quan,

Thanks!
Dhruv