Re: [Teas] WG adoption poll: draft-wdbsp-teas-nrp-yang-04

["Wubo (lana)" <[e-mail]>]

Hi Lius,



Many thanks for your valuable comments. Please see the response inline.



Regards,

Bo



-----Original Message-----
From: Teas <[e-mail]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Monday, February 12, 2024 10:57 PM
To: Italo Busi <Italo.Busi=[e-mail]>; Lou Berger <[e-mail]>; TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>
Subject: Re: [Teas] WG adoption poll: draft-wdbsp-teas-nrp-yang-04



Hi all,



I support the adoption as well.



From my reading, I have the following comments / clarification questions which I would like to be addressed by the authors:



- At the very end of Introduction, we can find the following statement: “the NRPs model is a network configuration model”. When looking at Figure 4 of the framework document, the NRPs appear as internal abstract representation of network topologies at the NSC. Thus, this means NSC should keep an abstract representation of the topology underneath, and NSC should support a network configuration model for handling the NRP exercising the described YANG model. Is my understanding correct?

[Bo Wu] Yes. You are correct. Though the NRP seems to be an internal definition of the NSC in the Figure 4, my interpretation is that the NS framework does not restrict the NRP to be only supported by the NSC. Per the Figure1 of draft-ietf-teas-ns-ip-mpls, it shows that NRP can also be managed in network controllers and devices. We will add text to clarify that the NRP model may be used for NSC internal interfaces, or for interfaces between NSCs and network controllers. And the NRP device model used for the interface between device and controller will be extended with interface-specific attributes.



- Section 3. The first bullet (NRP instantiation) refers to the network controller as the one handling an NRP. It should be the NSC, according to Figure 4 of the framework document, and to be consistent what the other bullets in the same section.

[Bo Wu] Same with above explanation. Please refer Figure 1 of draft-ietf-teas-ns-ip-mpls, network controller and device can also manage NRP.



- Section 3, bullet on NRP modification. It only refers to bandwidth, while the NRP is refer at the beginning as a collection of resources. The model later on also insist on bandwidth. Thus, It seems that the only resource applicable is bandwidth. Should we then narrow down the NRP definition and take bandwidth as resource, or widening up and generalize the statements (and model) in the draft? For instance, section 3.1.1 title is abut resource reservation, but only bandwidth is considered.

[Bo Wu] The idea is the latter one. The NRP resource is not specific to bandwidth. It can also include nodes and links, a control plane resource (IGP instance), and forwarding plane resource (NRP selector, PHB), etc. Here we only take bandwidth as an example and we will clarify this. For the title of 3.1.1, how about we change to “bandwidth reservation”?



- Section 3.1 mentions “NRP capable node”. This is not defined anywhere in the document, I think it is convenient to do so.

[Bo Wu] This is defined in draft-ietf-teas-ns-ip-mpls. We will add the reference.



- The document assumes a single PHB per NRP (see section 3.1.3 as well). Is this correct? If so, it means that all the slices on top of an NRP will get the same behavior. But a slice could have different kind of flows. Thus, all the flow types on a slice would get the same behavor once mapped to an NRP. Is my understanding correct?

[Bo Wu] Actually, the model supports multiple PHB per NRP. It defines a per NRP global PHB, and a per topology/filter topology PHB, and the topology specific one can override the global one. We will add text in the PHB section to clarify this.



- Same section 3.1. Regarding the statement “The NRP policy modes (b) and (c) require the distributed/centralized resource reservation management”. It would be nice to have some clarification for what distributed/centralized resource reservation management the text is referring to. Furthermore, both of them are required, only one of them?

[Bo Wu] We will add the reference of Section 4 of draft-ietf-teas-ns-ip-mpls to clarify this. The NRP policy modes (b) is control plane only resource partition, and the NRP policy modes (c) is combined control plane and data planes resource partition. And distributed/centralized resource reservation management is applicable for both modes.



- Section 3.1.2. Few selectors are described. However many other fields could be used as selector. The more obvious could be those used in the YANG slice model under match-criteria at the time of mapping customer flows to slices (e.g. vlan). I think the selectors should be consistent with that, opening up the door to some other selectors or ways of combining selectors.

[Bo Wu] NRP selector is used to determine the NRP PHB and forwarding. The Selector defined is based on the forwarding mechanisms mentioned in draft-ietf-teas-ns-ip-mpls and draft-ietf-teas-nrp-scalability. Therefore, the IP destination address, MPLS, and SR are defined. We will be extend this when there are other stable NRP selector standard mechanism.

To support some complex scenarios, the model also defines ACL reference node.



- Regarding selectors, when referring to IP addresses. Always destination address is considered, never origin. I presume that for some cases would be much easier select origin instead of destination.

[Bo Wu] Same with previous one, perhaps a Selector of ACL can be used here.



- Section 3.1.3. mention that the PHB is defined by the controller, should it be the NSC instead? NSC is the one handling the NRP.

[Bo Wu] We will add NSC as well. Yes, the PHB needs to be consistent across the NRP management domain.



- At the time of discussing Bandwidth reservation, one case identified is the reservation specified as percentage of link capacity. However such % can be very different depending on the distinct links of an NRP. How can it be consistent?

[Bo Wu] The percentage is defined for the use cases of some link groups, such as links in access network or aggregation network. If consistent bandwidth reservation is required, the specific bandwidth value can be set.



Thanks



Best regards



Luis





-----Mensaje original-----

De: Teas <[e-mail]<mailto:[e-mail]>> En nombre de Italo Busi Enviado el: viernes, 9 de febrero de 2024 10:54

Para: Lou Berger <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>

CC: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>

Asunto: Re: [Teas] WG adoption poll: draft-wdbsp-teas-nrp-yang-04



I support the adoption of this draft as WG document



I have one comment which may be worthwhile addressing in the -00 version of the WG



The current name and title of the draft and YANG model can be misinterpreted as if this draft is defining a technology-agnostic NRP model. Instead, the discussion on the list has clarified that this draft is defining an IP technology-specific NRP model



I think that clarifying this in the title and name of the draft and YANG model would avoid any confusion:



c/A YANG Data Model for Network Resource Partitions (NRPs)/A YANG Data Model for Network Resource Partitions (NRPs) in IP networks/



c/nrp-yang/ip-nrp-yang/



c/ietf-nrp/ietf-ip-nrp/



I have also another comment that could be addressed in a future update through normal WG process: it would also be worthwhile updating the abstract/introduction to clarify that this model applies on devices and on controllers (as clarified by Pavan in his mail)



My 2 cents



Thanks, Italo



> -----Original Message-----

> From: Lou Berger <[e-mail]<mailto:[e-mail]>>

> Sent: martedì 23 gennaio 2024 14:48

> To: TEAS WG <[e-mail]<mailto:[e-mail]>>

> Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>

> Subject: [Teas] WG adoption poll: draft-wdbsp-teas-nrp-yang-04

>

> Hello,

>

> This email begins a 2-week adoption poll for:

> https://datatracker.ietf.org/doc/draft-wdbsp-teas-nrp-yang/

>

> No IPR has been disclosed on this document

>

> Please voice your support or objections to adoption on the list by the

> end of the day (any time zone) February 6.

>

> Thank you,

> Lou (as Co-chair)

>



_______________________________________________

Teas mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/teas



________________________________



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.



The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.



Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________

Teas mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/teas