[Idr] Re: draft-chen-idr-bgp-ls-sr-policy-nrp-09 - WG adoption call (7/22/2024 to 8/9/2024)

[Adrian Farrel <[e-mail]>]

Hi Sue,

 

Thanks for asking.

 

To your specific questions:

1.	Is the addition of NRP-ID information to SR BGP-LS information
valuable to networks?

With my TEAS network slicing head on, yes, this is a useful thing to have so
that the steering actions at the network edge can be reported for more clear
understanding of how the slicing services (traffic flows) are being
reported.

 

2.	Does the draft clearly specify the TLV?

With one of my other heads on (DE for BGP-LS), this looks good to me.

Maybe the definition of what goes in the NRP ID field could be a little
clearer. Section 2 has "NRP ID is planned by network operator." Maybe
something like: "The NRP ID is defined by the network operator and has
meaning in the network operator's context. Refer to
[I-D.ietf-idr-sr-policy-nrp] for more information about how this value may
be set and interpreted."

 

3.	Are there any security concerns about reporting NRP-ID?

I like the specific issue that is called out in Section 6. I don't see any
other concerns.

 

4.	Is this document ready to adopt? 

I did a thorough review of this draft at -08. The authors have addressed my
comments in -09, so I am content for this version to move forward.

 

Cheers,

Adrian

 

 

From: Susan Hares <[e-mail]> 
Sent: 23 July 2024 02:42
To: [e-mail]
Subject: [Idr] draft-chen-idr-bgp-ls-sr-policy-nrp-09 - WG adoption call
(7/22/2024 to 8/9/2024)

 

This begins a 2+ week WG adoption call (7/22 to 8/9/2024)for 

draft-chen-bgp-ls-sr-policy-nrp-09.txt.

(https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-nrp/) 

 

The authors should respond to this WG adoption call with an email with the
IPR statement. 

 

Document focus: 

This document defines a new TLV in BGP-LS to report the NRP-ID

associated with an SR Candidate Policy Path (CP). 

 

Links to Spring: During the 5/20/2024 interim, the following question was
raised:

What is the relationship between the information in this draft and the
information in draft-ietf-spring-resource-aware-segments?

 

Ran answered the following: 

Due to the resource SID mechanism defined in the
draft-ietf-spring-resource-aware-segments

(https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/
)

 

the headend node does not have information about the relationship between 

Candidate Path (CP) and NRP IDs, 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 SR 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.

 

In your discussion, please consider:

 

1.	Is the addition of NRP-ID information to SR BGP-LS information
valuable to networks?
2.	Does the draft clearly specify the TLV?
3.	Are there any security concerns about reporting NRP-ID?
4.	Is this document ready to adopt? 

 

Cheerily, Sue