|
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 <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
