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

[Dhruv Dhody <[e-mail]>]

Hi Loa,

> 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.
>

[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.

> 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?
>

[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

> /Loa
>
>
> --
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]