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

[Dhruv Dhody <[e-mail]>]

Hi Loa,

On Wed, Jul 29, 2020 at 4:13 PM Loa Andersson <[e-mail]> wrote:
>
> Dhruv,
>
> Inline please.
>
> On 29/07/2020 17:01, Dhruv Dhody wrote:
> > 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.
>
> 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 ..."
>

This text is incorrect then and should be fixed.

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

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

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

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