Re: [Pce] [Last-Call] 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 <xiong.quan@zte.com.cn> wrote:

> Hi Bo,
>
> Thanks for your review! Please see inline with Quan>>.
>
> Quan
>
>
> <<Original
> From: BoWuviaDatatracker <noreply@ietf.org>
> To: ops-dir@ietf.org <ops-dir@ietf.org>;
> Cc: draft-ietf-pce-lsp-extended-flags.all@ietf.org <
> draft-ietf-pce-lsp-extended-flags.all@ietf.org>;last-call@ietf.org <
> last-call@ietf.org>;pce@ietf.org <pce@ietf.org>;
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>