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
