Notes from TEAS WG Virtual Interim Meeting

Datatracker: https://datatracker.ietf.org/group/teas/about/

Wednesday, May 29, 2024

10:00-11:30 EDT
https://www.timeanddate.com/worldclock/converter.html?iso=20240529T140000&p1=179&p2=505&p3=141&p4=33&p5=900

Materials: https://datatracker.ietf.org/meeting/interim-2024-teas-01/session/teas
Note taking: https://notes.ietf.org/notes-ietf-interim-2024-teas-01-teas
Online conference: https://meetings.conf.meetecho.com/interim/?group=57ec842f-da3b-4e6d-92e0-8c43b6fb176c
Zulip: https://zulip.ietf.org/#narrow/stream/teas
ICS: https://datatracker.ietf.org/meeting/interim-2024-teas-01/sessions/teas.ics
Youtube: https://www.youtube.com/watch?v=6rUDrxOHgfg

Slot#) Start | Duration | Information

01) 10:00 | 10 min | Title: Administrivia

Presenter: Chairs

02) 10:10 | 30 min | Title: NRP Selector - Options

Reference Drafts: https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/ and https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability/

Presenter: Tarek Saad

Discussion Points: NRP selector vs NRP ID; General options for carrying the NRP selector in the packet (implications on scale and network management)

Ketan Talaulikar: I have a few questions, hopefully those can trigger some discussion. First question: There are 2 documents referenced in this presentation. One (draft-ietf-teas-ns-ip-mpls) is a network slicing realization draft while the other (draft-ietf-teas-nrp-scalability) is specific to scalability. Is my understanding correct?

Vishnu Pavan Beeram: We have multiple network slicing realization drafts in the WG. draft-ietf-teas-ns-ip-mpls discusses how network slicing can be realized using the notion of "Network Resource Partitions" (NRPs). The other realization drafts don't discuss NRPs. draft-ietf-teas-nrp-scalability, as the name suggests discusses NRP specific scalability considerations

Ketan Talaulikar: OK, if someone wants to propose NRP specific extensions, does draft-ietf-teas-ns-ip-mpls provide the necessary requirements?

Vishnu Pavan Beeram: It should. But please note that it is still an evolving document.

Ketan Talaulikar: There seem to be some contradictions between the 2 docs - draft-ietf-teas-ns-ip-mpls and draft-ietf-teas-nrp-scalability.

Vishnu Pavan Beeram: Can you please point out the misalignments? Please send it to the list.

Ketan Talaulikar: Will do.

Ketan Talaulikar: Regarding terminology, Slide 3 there is where NRP ID is introductions. From the definition, it seems more like a NRP policy id. In later slides, you call out a distinction between the NRP ID and the ID that is used in the data plane packet. Having separate terms for these should help disambiguate.

Tarek Saad: Agree, separate terms are needed. The NRP selector that is carried in the data plane packet may or may not have a dedicated identifier. When a dedicated identifier is used, we can call it NRP Selector ID to distinguish it from NRP ID, which is used in the management/control plane. We also don't want to preclude anyone from encoding the NRP ID in the dedicated NRP Selector ID field (if desired).

Ketan Talaulikar: Not all routing platforms have same capabilities, disambiguating the identifier that is carried in the data plane from the identifier used in the management/control plane should help with scalability.

Tarek Saad: Agree.

Ketan Talaulikar: Regarding the open question on NRP selector options (slide 11 - a. Overload existing fields, b. Use a dedicated identifier, c. both), in the longer term it might be simpler to have a dedicated field. But in the interim, it would be good to have flexibility that comes with overloading existing fields (until all hardware is upgraded). So, I'm in support of having both options.

Jie Dong: Regarding overloading existing fields in the packet for carrying the NRP selector, I understand the use of MPLS forwarding label or the IP destination address, but the use of "source address" needs more discussion.

Tarek Saad: Yes, the operational overhead associated with the use of "source address" is understood.

Vishnu Pavan Beeram: It is my understanding that the options listed in slide 5 are based on the various proposals made so far -- the slide isn't recommending any one approach over another. We, in TEAS, don't need to come to any conclusions on which specific data plane fields should be used. For now, we just need to decide if both "overloading existing fields" and "using a dedicated identifier" need to be allowed. We heard Ketan suggesting the use of both. Are there any reservations with going ahead with this?

Jie Dong: I agree with Ketan. In the short term, the scale of NRPs is likely to be low and "overloading existing fields" may be good short term choice. For the long term, as the scale of NRPs increases, having a dedicated identifier makes sense.

Ketan Talaulikar: NRP selector is more like a "classifier" and modeling the selector separate from the control-plane specific identifier should help with migration from the short term solution to the long term solution.

Jie Dong: Regarding the use of management plane vs control plane for distributing NRP specific information, the slides seem to indicate that the "management plane" approach is better. I'm not sure we can conclude that -- it is the same information.

Ketan Talaulikar: There has been general pushback in other WGs like IDR and LSR regarding the addition of state to the routing protocols that could otherwise be addressed in the management plane. The same pushback is expected with this as well.

Tarek Saad: Yes, there was some discussion in the WG on this and there was some explicit text added to clarify this in Rev 03 of draft-ietf-teas-nrp-scalability. For some reason, the text in Rev 04 modified this a bit. This change needs to be discussed.

Vishnu Pavan Beeram: Let's take the control and management plane specific discussion to the list. The focus of today's session is not that.

Vishnu Pavan Beeram: How many NRPs are enough? What is a reasonable range - minimum-maximum?

Katen Talaulikar: As NRPs are associated with queues and buffers, they are limited on a given router. The capabilities depend a lot on the router and role of the router. It also depends on whether the flows are point to point, or multi-point to multi-point. Its challenging to have multiple NRPs. And based on conversations with operators, the number seems to be small. It would be useful to get direct feedback from operators.

Jie Dong: Modern routers have a large number of queues and should be well equipped to support a large number. The NRP scale also depends on the scale of the topology size and service scale.

Ketan Talaulikar: We need to make sure that concepts like aggregation should come into play.

Vishnu Pavan Beeram: The reason behind asking the question on the slide is to be able provide guidance on what should be the minimum and maximum number of bits set aside for carrying the identifier.

Oscar de Gonzalez (as an operator): The number of services that require strict guarantees (e.g. VPNs) is typically in the ~100s. The ones requiring loose guarantees are in the thousands or more. In the future, with network slicing, the scale of services that require strict guarantees is expected to increase.

03) 10:40 | 15 min | Title: Modeling NRP Selector

Reference Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-yang/

Presenter: Bo Wu

Greg Mirsky: I thought the NRP-ID is the "name" of the NRP. Why are there "two" identifiers?

Tarek Saad: This is similar to how TE constructs within the IETF tend to have both a symbolic name as well as a numerical identifier.

Greg Mirsky: How do you maintain uniqueness of the nrp-id if it is not the key.

Tarek Saad: We are using the YANG "unique" keyword when modeling this.

Vishnu Pavan Beeram: There are a fair number of other routing constructs that have been modeled this way to facilitate operational flexibility -- have both, a unique symbolic name and a unique numerical identifier. That said, this can be revisited and discussed on the list.

Ketan Talaulikar: Should the nrp-id be renamed to nrp-policy-id.

Vishnu Pavan Beeram: This has been discussed in the past. The reason why it is called nrp-id is that the nrp policy is used to instantiate the NRP and the id shown here is the id of the instantiated NRP. There is 1-1 mapping between the two. That said, this can be revisited and discussed on the list.

Ketan Talaulikar: With regards to aggregation, there doesn't need to be a 1-1 mapping between the management nrp-id and the selector field in the packet.

Bo Wu: This is already covered in the way the NRP selector is modeled in this draft.

04) 10:55 | 15 min | Title: Carrying Network Resource Partition (NRP) Information in IPv6 Extension Header

Draft: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-vpn-vtn-id/

Presenter: Jie Dong

Ketan Talaulikar: Regarding the "S" flag (slide 4) and the option to break the SLA, I'm not convinced this is needed. Is this discussed in the NRP realization draft?

Jie Dong: This is an option provided for exception handling. Dropping the packet if we are not able to map it to an NRP may not always be the desired option.

Ketan Talaulikar: Maybe, NRPs can be marked as strict or loose. My point is that this needs to be covered in one of the realization documents.

Jie Dong: We should be able to add text.

Ketan Talaulikar: This is generic and should be apply to MPLS as well.

Vishnu Pavan Beeram: Agree that this is generic. There is some text already in draft-ietf-teas-ns-ip-mpls that elaborates on what can be done when a packet arrives and it cannot be mapped to any specific NRP. We should review and see if it needs to be elaborated further.

Tarek Saad: Regarding the terminology to be used for the new IPv6 HBH option and identifier, the preferred term for the marking in the packet that is used to select the NRP is "NRP Selector". But I thought I heard Ketan say that he would like to see a more generic term to be used for the IPv6 HBH option to facilitate other similar use-cases.

Ketan Talaulikar: My point is that there is a need to conserve the IPv6 HBH option space and having a more generic option would be desirable -- but this is not for TEAS to decide. The input that is needed from TEAS is the number of bits to be used for this field.

Tarek Saad: Slide 6 says different data-plane encapsulations may need different NRP ID lengths. Why?

Jie Dong: This flexibility is to accommodate different data-plane limitations.

Vishnu Pavan Beeram: Thanks for the productive meeting. Please continue the discussion on the list.

Adjourn 11:10