[Idr] Re: draft-ietf-idr-bgp-srmpls-elp-03 - Shepherd Review

[[e-mail]]

Hi Sue,


Thanks again for your detailed review.
I've just submitted v-04 to address the comments following Review-1  Issue #2, using the suggested text.
And there's no implementation of this document yet.


Best Regards,
Yao



Original


From: SusanHares <[e-mail]>
To: [e-mail] <[e-mail]>;
Date: 2025年07月14日 00:11
Subject: [Idr] draft-ietf-idr-bgp-srmpls-elp-03 - Shepherd Review 

_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
 

Review is online at: https://wiki.ietf.org/en/group/idr/Shepherd-SR-BGP-LS/BGP-SR/draft-ietf-idr-bgp-sr-mpls-elp
 
Type: Proposed Standard 
status: WG Draft  
adopted:  8/12/2024 (7/12/2024 - 7/30/2024) 
current version: 03
Early Allocation: ready for early allocation
implementations: H3C and ZTE (2 implementations) 
WG LC requirements: 
      1. Early allocation, 
       2. Implementation report on 2 implementations
       3. draft-ietf-idr-bgp-sr-mpls-elp-04 - to correct editorial below. 
bgp-ls draft: none
 
 
Review of -03 
Summary: resolves previous technical issues, Need – 04 with minor editorial nits for follow-up on Issue 2. 
Next step:  Early Allocation call
 
### Technical issues resolved 
- Review-1, Issue #1: resolved in version 3 
- Review-1, Issue #2: Section 4 or 5, Missing Error handling for a malformed Explicit NULL Policy TLV - needs textual edit: 
 
Current 
>   The error handling principles for the SR Policy TLVs/sub-TLVs in
>    [I-D.ietf-idr-sr-policy-safi] apply to this document.  The validation
>    of each ELP sub-TLV MUST be performed on the headend nodes to
>    determine if they are malformed or invalid.  In case of any error
>    detected, the "treat-as-withdraw" strategy MUST be applied.
{.is-info}
Suggested changes:
>    The error handling methods for the SR Policy TLVs/sub-TLVs in
>    [I-D.ietf-idr-sr-policy-safi] apply to this document.  The validation
>    of each ELP sub-TLV MUST be performed in headend nodes in the BGP 
>    process to determine if they are malformed or invalid.  In case of any error
>    detected, the "treat-as-withdraw" strategy MUST be applied.
>    
>    The SRPM policy determines if the values for ELP impact the
>    selection of the SR Policy Candidate Path (SR Policy CP) as the best SR Policy CP.
{.is-info}
 
 
- Review 1, Issue #3 -  Security Section – resolved  
 
Text that resolves the comment: 
  The ELP extension is included in the SR Policy extension
  [I-D.ietf-idr-sr-policy-safi], so it does not introduce extra
  security problems comparing the existing SR policy extension.  SR
  Policies with ELP information distributed by BGP are expected to be
  used entirely within trusted SR domain.  The ELP information is a
  critical piece of information about critical infrastructure.
  Therefore, precaution is necessary to ensure that the ELP information
   advertised via BGP sessions is limited to nodes in a secure manner
   within this trusted SR domain.
 
- Issue #4 - Missing Scalability considerations for this work. 
 
Resolved with the following comments in section 4, last paragraph: 
 
    When using the protocol extensions introduced in this document,
   scalability SHOULD be considered since it may increase the the amount
   of control plane information(i.e., the BGP messages) exchanged
   between the network controller and the headend nodes.