[IPv6] Comments on draft-ietf-6man-enhanced-vpn-vtn-id

[Ketan Talaulikar <[e-mail]>]

Hello All,

I am sharing the comments that I made at the mic during the 6man WG session
today to start a list discussion. Also copying TEAS WG where the main
framework is being worked on and perhaps the place where perhaps most of
these points should be debated.

1) My feedback to the authors is to keep the IPv6 NRP HBH extension header
as short and simple as possible. This is something that needs to be
processed in hardware at line rate by all IPv6 routers in a provider
network "limited domain". Let us make it as efficient as possible for it to
be successful. So a simple header with a fixed length NRP-ID in it is
sufficient. Note that there will be similar extensions for other data
planes (I am aware of one for MPLS
https://datatracker.ietf.org/doc/draft-li-mpls-mna-nrp-selector/) and we
need to ensure some level of consistency across them.

2) Next point is the size of this NRP-ID. It seems like there is the desire
to keep it as 32-bit, and this seems to stem from the desire to map this to
a 3GPP slice (see text below from sec 2) ? However, it is for the TEAS WG
to check if there is a desire for such 1:1 mapping. My understanding, and I
could be wrong, is that the number of NRPs is intended to be a much smaller
number than the network slices that are layered on top of an NRP.
Shorter/smaller size that is more practically aligned to the framework
would be desirable.

Note that, in the context of 5G network slicing, if a deployment found it
useful, the four-octet NRP ID field may be derived from the four-octet
Single Network Slice Selection Assistance Information (S-NSSAI) defined in
3GPP [TS23501
<https://www.ietf.org/archive/id/draft-ietf-6man-enhanced-vpn-vtn-id-06.html#TS23501>
].

3) The flags defined in the extension header only complicate the
processing, especially as new ones are introduced. Even so, for the S flag
currently defined, I am not convinced of the rationale/argument. My
understanding is that the NRP is intended as a guarantee of network
resources that are partitioned - this needs actual QoS resources to be
provisioned on the node. If some traffic flow is routed over a node/link
where the NRP and its resources are not provisioned, then the "guarantee"
is broken? This seems to be more like a local policy thing. For years we
have been able to do QoS PHB with a fixed size DSCP/TOS/EXP bits, is this
not similar?

4) And finally, there was a discussion on the chat about extensibility for
carrying other information/identifiers. If this HBH EH is meant for
carrying NRP, then let it carry only NRP. I don't think we want some other
identifiers being carried around in this HBH for some other purposes -
there are bound to be concerns.

I hope this helps us converge towards a simple and consistent EH for NRP.

Thanks,
Ketan