Hi Quan, Bo,
Please see inline....
On Wed, Oct 12, 2022 at 8:24 AM <xiong.quan@xxxxxxxxxx> wrote:
Hi Bo,
Thanks for your review! Please see inline with Quan>>.
Quan
<<Original
From: BoWuviaDatatracker <noreply@xxxxxxxx>
To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;
Cc: draft-ietf-pce-lsp-extended-flags.all@xxxxxxxx <draft-ietf-pce-lsp-extended-flags.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;pce@xxxxxxxx <pce@xxxxxxxx>;
Date: 2022年10月11日 21:31
Subject: Opsdir last call review of draft-ietf-pce-lsp-extended-flags-05
Reviewer: Bo Wu
Review result: Has Nits
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.
The draft defines the PCE LSP object flag extension. The original 12 bits flags
have been allocated, but a new individual draft requires new flags. In summary,
the document is ready, with only small issues.
Major issues:
Minor issues:
Introduction:
The bits from 1 to 3 are assigned in [RFC8623] for Explicit
Route Object (ERO)-compression, fragmentation and Point-to-Multipoint
(P2MP) respectively.
[Bo Wu] Here uses ERO object. But the title and abstract say Label Switched
Path (LSP) Object Flag Extension, contradict?
Quan>>The description of the two objects do not contradict. The flag extension is carried in LSP Object.
And one bit of this flag is assigned and named ERO-compression flag. And if the ERO-compression flag is
set to 1, it indicates the route is in compressed format as per [RFC8623].
Dhruv: Agree with Quan.
5. Backward Compatibility
The LSP-EXTENDED-FLAG TLV defined in this document does not introduce any
interoperability issues.
[Bo Wu] I feel there are interoperability issues introduced, correct? But the
issue will be resolved by the future use?
Quan>>I think the TLV itself does not introduce any interoperability issues and the use of flag may
introduce interoperability issues which may be resolved and considered by the future use. Maybe
we should add this sentence in draft?
Dhruv: How about this rewrite of the section ->
5. Backward Compatibility
The LSP-EXTENDED-FLAG TLV defined in this document does not introduce
any backward compatibility issues. An implementation that does not
understand or support the LSP-EXTENDED-FLAG TLV will silently ignore
the TLV as per [RFC5440]. It is expected that future documents that
define bits in the LSP-EXTENDED-FLAG TLV will also define the error
case handling required for missing LSP-EXTENDED-FLAG TLV if it MUST
be present.
Further, any additional bits in the LSP-EXTENDED-FLAG TLV that are
not understood by an implementation would be ignored. It is expected
that future documents that define bits in the LSP-EXTENDED-FLAG TLV
will take that into consideration.
Nits/editorial comments:
Introduction:
OLD
The bit value 4 is assigned in [RFC8281] for create for PCE-Initiated
LSPs.
New
The bit value 4 is assigned in [RFC8281] for creation and deletion for
PCE-Initiated LSPs.
Quan>>Thanks, will revise it in the new version.
Dhruv: The flag is called "create" and the new change could lead to confusion. I would rather we rephrase this to -
"The bit value 4 is assigned in [RFC8281] to identify PCE-Initiated LSPs."
Thanks!
Dhruv
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
