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

[[e-mail]]

Hi Joel，
Please see inline...

Best Regards，
Ran


Original


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

Please confirm that I am reading your explanaation of the draft relationship correctly.
It appears that this draft assumes that we have two different encodings for representing NRP usage in IPv6 packets using SRv6.  On mechanism is that described in drraft-ietf-spring-resource-aware-sements.  The other mechanism is that there would be a hop-by-hop option carrying an NRP-ID used in conjunction with an SRv6 SID list (that does not represent resource usage.)
[Ran] Yes.
If that is correct, that second usage would seem to need to be described somewhere.  The 6man vtn ID draft which describes carrying an NRP-ID does not discuss the relationship with segment routing.
[Ran] Yes. The 6man vtn ID draft does not rely on SR, while it can be used with SR.  We will consider how and where to reflect its relationship with SRv6.
And it would seem that the adoption of two separate solutions needs to be understood and accepted by the IETF community.  Preferably before IDR works on how to export that information in BGP-LS.
[Ran]  https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability/ mentions two separate solutions respectively, but it does not mention how the two solutions can be used in SR policy.   Maybe we can write a draft SR policy NRP in SPRING WG as suggested by ketan, and discuss it in spring WG.

Yours,
Joel
On 5/21/2024 4:18 AM, [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
 
 





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