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

[Joel Halpern <[e-mail]>]

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.)

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.

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.

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
>
>
> 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 presentationon 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:
>
> 1.
>
>     The headend needs to report the configuration and the states of an
>     SR Policy carrying NRP information.
>
> 2.
>
>     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
>
>