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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Chongfeng and Adrian,

Thanks for your comments and suggestion on the way to progress this document. They are very helpful.

Regarding the terminology, yes we plan to follow the decision in TEAS and update the draft to replace the term VTN with NRP. Some editing to the text would also be considered.

As for the S flag, personally I also think it is useful both in the network slicing case and also in other general cases, as it provides an approach to customize the forwarding behavior for non-matching packets. And I found it is necessary to make "discard packet" as an option, one use case is for connectivity check or other OAM packets, operator may want to obtain the status of exactly the specific NRP for trouble shooting or other operation purpose. Of course "best effort forwarding" would be the other option.

Then it seems it would be preferable not to split the S flag from this document.

If there is no other opinions, our plan is to make the above changes to the draft in next revision.

Best regards,
Jie

From: Chongfeng Xie [mailto:[e-mail]]
Sent: Thursday, December 14, 2023 10:54 AM
To: adrian <[e-mail]>; Dongjie (Jimmy) <[e-mail]>
Cc: IPv6 List <[e-mail]>; [e-mail]
Subject: Re: Re: Progress of comments resolution on draft-ietf-6man-enhanced-vpn-vtn-id


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<mailto:[e-mail]>
Date: 2023-12-13 01:03
To: Dongjie (Jimmy)<mailto:[e-mail]>
CC: '6man'<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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.