Re: [Idr] Adoption call for - draft-dong-idr-sr-policy-nrp-02 (3/1 to 3/14)

Hi Dhruv,

Thanks a lot for your support and valuable comments.

Please see some replies inline:

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Wednesday, April 5, 2023 2:46 PM
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf.org
Subject: Re: [Idr] Adoption call for - draft-dong-idr-sr-policy-nrp-02 (3/1 to 3/14)

Hi Sue,

Since the WG adoption call is not closed yet, let me slip in my review...

I support WG adoption, but I have some comments...

1)    The I-D states that the candidate paths in one SR Policy SHOULD be associated with the same NRP. The I-D should explicitly state what happens if it is not! (Also see (4))

[Jie] The intention is to make “the candidate paths associating with the same NRP” the default behavior, while it also allows different candidate paths associating with different NRPs with careful design.  We will clarify this in next revision.

2)    The security consideration needs to add reference to relevant documents that describe the security risks of NRP-ID in the dataplane as well as incorrect association of NRP in the control plane.

[Jie] OK, will do that.

3)    Please remove the codepoint in the IANA consideration, use TBD!

[Jie] OK with that, while the code point has been allocated by IANA.

4)    Is NRP a property of SR Policy or the Candidate path? It feels it is used interchangeably. I suggest being specific and consistent.

[Jie] Will clarify that it is the property of the candidate path.

5)    We could also lay out explicitly, what does it mean to not have an NRP sub-TLV.

[Jie] Good point. It means the candidate path is not associated with any non-default NRP. Will clarify this in the draft.

6)    NRP ID in section 2, you should also state that it is unsigned

[Jie] Please see the reply to item 3.

7)    Section 3, i am not sure about the SHOULD in para 1, why not MUST?

[Jie] It seems MUST is better in such description. Will update it in next revision.

Many thanks,
Jie

Thanks!
Dhruv

On Wed, Mar 1, 2023 at 10:19 AM Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:
This begins a 2 week WG adoption call for
draft-dong-idr-sr-policy-nrp
https://datatracker.ietf.org/doc/draft-dong-idr-sr-policy-nrp/

Each of the authors should respond to this message with
an email indicating if they know of any IPR regarding this draft.

The draft specifies an extension to BGP SR policy to
Specify the NRP (network partition resources) that
Than an SR Policy candidate path is associated with.

In your discussion consider if this is a useful addition to the
SR Policy candidate path.

Cheerily, Sue

===========
Full description from the draft

  Segment Routing (SR) Policy is a set of candidate paths, each

   consisting of one or more segment lists and the associated

   information.  The header of a packet steered in an SR Policy is

   augmented with an ordered list of segments associated with that SR

   Policy.  A Network Resource Partition (NRP) is a subset of network

   resources allocated in the underlay network which can be used to

   support one or a group of IETF network slice services.

   In networks where there are multiple NRPs, an SR Policy may be
   associated with a particular NRP.  The association between SR Policy
   and NRP needs to be specified, so that for service traffic which is
   steered into the SR Policy, the header of the packets can be
   augmented with the information associated with the NRP.  An SR Policy
   candidate path can be distributed using BGP SR Policy.  This document
   defines the extensions to BGP SR policy to specify the NRP which the
   SR Policy candidate path is associated with.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr