Re: [IPv6] Progress of comments resolution on draft-ietf-6man-enhanced-vpn-vtn-id

[Chongfeng Xie <[e-mail]>]

Hi Adrian,

Thanks for sharing your opinion on this document.

I fully agree with your suggestion about the terminology alignment with TEAS according to recent discussion and decision made there on the enhanced VPN framework.

Regarding the S flag, I also find it useful for network slicing in our network, as it can help to customize the behavior on traffic belonging to specific NRPs, and also on specific flows in an NRP. It could also be generalized for other use cases.

Thus I think it would be more efficient to keep the S flag as part of this document and progress together.

Best regards

Chongfeng

From: Adrian Farrel
Date: 2023-12-13 01:03
To: Dongjie (Jimmy)
CC: '6man'; [e-mail]
Subject: Re: Progress of comments resolution on draft-ietf-6man-enhanced-vpn-vtn-id
Hi Jie,
 
I rather expected some more comments on this, and I sat back to watch them,
but then it went quiet and I forgot.
 
So, "better late than never".
 
As an aside, I wonder whether you should follow the advice given by TEAS in
its work on draft-ietf-teas-enhanced-vpn, and feeding into IDR on
draft-dong-idr-sr-policy-nrp. That is, generalise the VTN use case to NRP. I
don't think this makes any technical change to the document, but makes the
applicability wider (more generic) in step with what TEAS is doing. This
seems to in keeping with the suggestions in your Section 5. But it would
require some editorial work.
 
I am not enthusiastic about splitting out multiple documents. It just makes
more work.
 
While I understand that the authors and Med thought this might be a
compromise, I doubt that the authors really want to do this (that is, make
more work for themselves) and since no one spoke up on the list, I wonder
whether it the (perfectly valid) preference of only one person.
 
If the reason for splitting was technical or made for a radical improvement
in readability, I might buy it. But I think it is purely a documentation
issue.
 
It is worth noting that if the document was split then, without the S flag,
the whole flags field would be unused in the remaining document. It is
"unusual" for a spec to define a field that has no documented use. I'd be
uncomfortable with that.
Conversely, I think this drat should introduce a new registry to track the
flags field
 
Personally, I see some value in the S bit as defined. At least, I do in the
context of the network slicing use of the NRP. Consider a network where some
resources are strictly partitioned (reserved) at some transit nodes, but at
other nodes (perhaps ones that are known to have plenty of capacity) no
partitioning has been performed. In this case, you would want the nodes that
have not done any partitioning to not be bothered by the VTN/NRP ID carried
in the packet. But consider, instead, a network that is resource constrained
where partitioning has been carefully performed on all nodes. In this case
you would want to observe that the packet cannot be assigned to any
partition and so should not use the resources of any other partition.
 
Well, I think this might be softened for two reasons:
1. If a node does not understand the HBH option, it will skip over it (you
have specified the highest-order 2 bits are set to 00), so the default
behaviour is to try to forward the packet.
2. Assigning best-effort forwarding to packets seems like a reasonable
default.
 
So, I would keep the S bit in this, but I would change "drop" to "perform
best effort forwarding". (Noting, of course, that the best you can do might
still be to drop the packet.)
 
Cheers,
Adrian
 
> From: ipv6 [mailto:[e-mail]] On Behalf Of Dongjie (Jimmy)
> Sent: Wednesday, November 8, 2023 12:59 AM
> To: 6man <mailto:[e-mail]>
> Cc: [e-mail]
> Subject: [IPv6] Progress of comments resolution on
draft-ietf-6man-enhanced-vpn-vtn-id
>
> Hi WG,
>
> Regarding Med's review comments on draft-ietf-6man-enhanced-vpn-vtn-id,
the authors
> and Med met in Prague and reach some agreement about the possible
resolution of his
> comments.
>
> The proposed approach is to split the definition of the S flag out from
this document, so
> that this document will focus on the specification of the VTN option with
all the flags as
> reserved, and the S Flag could be defined as an extension to the VTN
option in a separate
> document.
>
> Before updating this WG draft, we would like to know the WG's opinion on
this approach
> to move forward. Any feedback is welcome.