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 ..."
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
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). How are you deciding if the extended TLV
missing?
/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
