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

[[e-mail]]

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 <[e-mail]>
To: 熊泉00091065;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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 <[e-mail]> wrote:

Hi Bo,
 
 Thanks for your review! Please see inline with Quan>>.
 
 Quan
 
 
 <<Original
 From: BoWuviaDatatracker <[e-mail]>
 To: [e-mail] <[e-mail]>;
 Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
 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]
 https://www.ietf.org/mailman/listinfo/last-call