Re: [Pce] [Last-Call] Opsdir last call review of draft-ietf-pce-lsp-extended-flags-05

["Wubo (lana)" <[e-mail]>]

Hi Dhruv, Quan,

Thanks for taking care of my review. That work for me.

Regards,
Bo


Subject: 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 <[e-mail]><mailto:&lt;[e-mail]&gt;> wrote:



> Hi Bo,

>

> Thanks for your review! Please see inline with Quan>>.

>

> Quan

>

>

> <<Original

> From: BoWuviaDatatracker <[e-mail]><mailto:&lt;[e-mail]&gt;>

> To: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:&lt;[e-mail]&gt;>;

> Cc: [e-mail]<mailto:[e-mail]> <

> [e-mail]>;[e-mail]<mailto:[e-mail]%3e;[e-mail]> <

> [e-mail]>;[e-mail]<mailto:[e-mail]%3e;[e-mail]> <[e-mail]><mailto:&lt;[e-mail]&gt;>;

> 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

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/last-call

>