Hi Dhruv and Bo,
Thanks for your review and suggestions!
I have revised and update the draft as your comments.
https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-07.html
Best Regards,
Quan
Original
From: DhruvDhody <[email protected]>
To: 熊泉00091065;
Cc: [email protected] <[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
Date: 2022年10月12日 12:07
Subject: Re: [Last-Call] [Pce] Opsdir last call review of
draft-ietf-pce-lsp-extended-flags-05
Hi Quan, Bo,
Please see inline....
On Wed, Oct 12, 2022 at 8:24 AM <[email protected]> wrote:
Hi Bo,
Thanks for your review! Please see inline with Quan>>.
Quan
<<Original
From: BoWuviaDatatracker <[email protected]>
To: [email protected] <[email protected]>;
Cc: [email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
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
[email protected]
https://www.ietf.org/mailman/listinfo/last-call_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
