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 protected]>
收件人：Loa Andersson <[email protected]>;
抄送人：[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
日 期 ：2020年07月29日 19:15
主 题 ：Re: cursory review of draft-xiong-pce-lsp-flag
Hi Loa,
On Wed, Jul 29, 2020 at 4:13 PM Loa Andersson <[email protected]> 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: [email protected]
> >> Senior MPLS Expert [email protected]
> >> Bronze Dragon Consulting phone: +46 739 81 21 64
>
> --
>
> Loa Andersson email: [email protected]
> Senior MPLS Expert [email protected]
> Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
