Hi Quan, Bo, Please see inline....
On Wed, Oct 12, 2022 at 8:24 AM <xiong.q...@zte.com.cn> wrote: > Hi Bo, > > Thanks for your review! Please see inline with Quan>>. > > Quan > > > <<Original > From: BoWuviaDatatracker <nore...@ietf.org> > To: ops-...@ietf.org <ops-...@ietf.org>; > Cc: draft-ietf-pce-lsp-extended-flags....@ietf.org < > draft-ietf-pce-lsp-extended-flags....@ietf.org>;last-c...@ietf.org < > last-c...@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-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
