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

[Ketan Talaulikar <[e-mail]>]

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:
>
>    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
>
>
>