[Idr] Re: continue discussion //Re: draft-chen-idr-bgp-ls-sr-policy-nrp-05 - Pre-Adoption Shepherd's review

[[e-mail]]

Hi Ketan，

Thanks! We will consider writing the new SR policy NRP document in the SPRING WG, or adding this part to the existing document.

Best Regards，
Ran

Original


From: KetanTalaulikar <[e-mail]>
To: 陈然00080434;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年05月22日 01:48
Subject: Re: continue discussion //Re: draft-chen-idr-bgp-ls-sr-policy-nrp-05 - Pre-Adoption Shepherd's review


Hi Ran,
Regarding applicability of NRP to SR Policies, there are two drafts in IDR (BGP SR Policy SAFI and BGP-LS) and another one in PCEP. Clearly, these details that we are discussing do not belong to either BGP or PCEP and are better covered in a SPRING document. 

The draft has an informative reference to draft-ietf-teas-nrp-scalability but I could not find any text there that describes exactly how NRP is used for SR Policy. There is clearly need for a standards track SPRING document that can be normatively referred to by these BGP and PCEP protocol extensions for SR Policy NRP.

Thanks,
Ketan





On Tue, May 21, 2024 at 1:48 PM <[e-mail]> wrote:


Hi Sue，Joel &Ketan，

Thank you very much for your valuable comments on 5/20/2024 IDR interim.  Please see below.
1.  Sue's comment on why the headend needs to report the configuration and the states of an SR Policy carrying NRP information. 
[Ran] The controller collects the resources occupied by the SR policy by the reported association between the NRP ID and the SR policy from the head node. The controller can use this information to visualize paths, verify consistency, calculate other SR policy paths that may share or bypass specific nodes or links, etc. 
One of the most important functions is to verify consistency, for example,  SR policy with associated NRP-ID can be configured statically by the headend, or the association between NRP-ID and SR policy can be distributed to the headend by [I-D.ietf-idr-sr-policy-nrp]. The headend reports the association between NRP-ID and SR pilicy candidate path, indicating the association takes effect.

2. Joel's comment on clarifying this draft's relationship to draft-ietf-spring-resource-aware-segments-09,

[Ran]  In the resource SID scenario, The headend node does not have information about the relationship between CP and NRP ID,  so it currently does not consider reporting the relationship between CP and NRP ID.
The current draft is only for the scenario where data packets carry NRP ID,  The NRP ID is used with the normal SRv6 SID as the resource used will be indicated by the NRP-ID.  An SR Policy candidate path  (CP) may be instantiated with a specific NRP on the headend node via a local configuration, PCEP, or BGP SR Policy signaling. Then the state and attributes of the NRP associated with the candidate path of SR policy  can be distributed to the controller.
For SR Policy with IPv6 data plane, the approach to encapsulate the NRP ID in IPv6 Hop-by-Hop Options header is defined in [I-D.ietf-6man-enhanced-vpn-vtn-id]. I will communicate with Jie about how to specify the relationship with SRv6 in the [I-D.ietf-6man-enhanced-vpn-vtn-id].  
and clarify the scope in draft-chen-idr-bgp-ls-sr-policy-nrp. Is this ok?

3. Ketan's comment on how does the tail node of SR policy know to remove NRP-ID?
[Ran] Since the tail node of the SR policy is the final destination, the IPv6 header will be removed, and the NRP ID carried in the IPv6 Hop-by-Hop Options header will naturally also be removed.

Best Regards,
Ran


Original

From: 陈然00080434
To: SusanHares <[e-mail]>;
Cc: [e-mail] <[e-mail]>;Dongjie (Jimmy) <[e-mail]>;赵德涛10132546;龚立艳 <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年05月17日 18:15
Subject: Re: draft-chen-idr-bgp-ls-sr-policy-nrp-05 - Pre-Adoption Shepherd's review


Hi Sue & WG,

We would like to request a presentation on 5/20/2024 IDR interim.

 Problem 1:
Authors need to provide additional information on the following comment in section 1:
“This document defines a new TLV to enable the headend to report the configuration and the states of an SR Policy carrying the NRP information by using BGP-LS”.
The authors should indicate why:
      1. The headend needs to report the configuration and the states of an SR Policy carrying NRP information. 
      [Ran]: As defined in  [I-D.ietf-idr-bgp-ls-sr-policy],  SR policy information can be used by external components for path computation, re-optimization, service placement, network visualization, etc.  A Network Resource            Partition (NRP) is a network resource attribute associated with the SR policy.  It is also an important attribute of the SR policy and needs to be reported to the external components. The notification of SR policy  with              NRP information is also used for the same function.

      2. Why BGP-LS in BGP is the best protocol to pass this state.
     [Ran]:  When reporting SR Policy information, the corresponding protocol is BGP-LS.  As an attribute of  SR Policy, NRP is reported together with the SR Policy information.
    
Problem 2: 
     Why the security considerations in this draft are sufficient when they only reference RFC9552 and RFC4271.
    [Ran]: A Network Resource Partition (NRP) also an important attribute of the SR policy and needs to be reported to the external components.  The security considerations of BGP-LS SR policy  [I-D.ietf-idr-bgp-ls-sr-policy]      also apply to this document.  Will update it.

Best Regards,
Ran








From: SusanHares <[e-mail]>
To: [e-mail] <[e-mail]>;
Cc: 陈然00080434;Dongjie (Jimmy) <[e-mail]>;赵德涛10132546;龚立艳 <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年05月15日 10:19
Subject: draft-chen-idr-bgp-ls-sr-policy-nrp-05 - Pre-Adoption Shepherd's review


Draft: draft-chen-idr-bgp-ls-sr-policy-nrp-05    
Status:  Almost ready for adoption
TEAS checks: 

The concept of NRP – has been OKed by TEAS. 

The IDR chairs will validate section 1 with the TEAS and MPLS chairs prior to adopting the draft.


 
Problem 1: 
Authors need to provide additional information on the following comment in section 1:
 
“This document defines a new TLV to enable the headend to report
the configuration and the states of an SR Policy carrying the NRP
information by using BGP-LS”.
 
The authors should indicate why:

The headend needs to report the configuration and the states of an SR Policy carrying NRP information. 

Why BGP-LS in BGP is the best protocol to pass this state.


 
Problem 2:  Why the security considerations in this draft are sufficient when they only reference RFC9552 and RFC4271.
 
The IDR chairs welcome a presentation on this draft at the 5/20/2024 interim. 
 
Cheerily, Susan Hares