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

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

Hi Med,

Thanks for your reply. Yes the draft was updated based on the discussion on and off the list.

Please find some of my response inline:

From: [e-mail] <[e-mail]>
Sent: Wednesday, February 21, 2024 9:01 PM
To: [e-mail]; Dongjie (Jimmy) <[e-mail]>
Cc: '6man' <[e-mail]>; [e-mail]
Subject: RE: [IPv6] Progress of comments resolution on draft-ietf-6man-enhanced-vpn-vtn-id

Hi Adrian, Jie, all,

(apologies for the long delay to follow-up. Thanks Jie for the updated version)

You made good observations, but I'm still struggling to see a good justification for the complexity induced by this S bit.

[Jie] That is fine. It is useful to share opinions on the S bit on the list, which could help people to better understand it.


For example, even if the S bit is used, configuration actions are still required. At least, ingress nodes should be provided with the appropriate instructions that will trigger the setting of the S bit as a function of the NRP ID, and eventually as a function of the flow (if I got well the finer grained use case you listed below).

[Jie] You are right that for NRPs which the node needs to participate in, NRP-specific configuration is needed, but this is not what the S bit is designed for. In contrary, the S bit is used to control the forwarding behavior for NRPs (or for some flows of the NRPs) which are NOT configured on the node (please note in the text of the draft, S bit is checked if the NRP ID in the NRP option does NOT match with any of the NRP ID provisioned on the network node).


Likewise, intermediate node should provided with the NRP-ID they belong to + resources partitioning information (which are much more complex, IMO) + any configuration as per 5.1.1. of draft-ietf-6man-hbh-processing.

[Jie] Same response as above, for NRPs which need to be enabled on the node, such configuration is needed. While this is orthogonal to the functionality of the S bit.


You said: "I would say that the field should be marked "Reserved" not "Flags", meaning that the document that defined the S flag would also have to Update the base spec to define the Flags field". I'm not sure the argument stands here because the field can simply be tagged as "Unassigned" as per Section 6 of RFC 8126:

      Unassigned:  Not currently assigned, and available for assignment
            via documented procedures.  While it's generally clear that
            any values that are not registered are unassigned and
            available for assignment, it is sometimes useful to
            explicitly specify that situation.  Note that this is
            distinctly different from "Reserved".

[Jie] I'd not comment on this. While if the WG reaches consensus that the S bit is needed, we may not need to discuss this further.

Best regards,
Jie

Thank you.

Cheers,
Med

De : Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 22 décembre 2023 19:18
À : 'Dongjie (Jimmy)' <[e-mail]<mailto:[e-mail]>>; BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : '6man' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : RE: [IPv6] Progress of comments resolution on draft-ietf-6man-enhanced-vpn-vtn-id


Well, I'm going to pile in once more (it *is* Christmas) and then sit back to see whether there are other opinions...



  *   As Ketan observed (a little late ;-) the proposed S flag comes from the NRP ID extension header, so there is no shortage of flags.



  *   Yes, Med is right, this function could be configured at each node. Indeed, most things can be configured at nodes, but does that mean we discard the IGPs? :-)



  *   The S flag provides greater granularity than can be achieved with configuration. If you configure "discard or best effort" you have some choices:



     *   Configure the default behaviour for "I don't have resources for this NRP ID". That is relatively simple, but it is "one size fits all."
     *   Configure the behaviour for each NRP ID that might be seen and for which resources aren't reserved. That feels like a nightmare for configuration.
     *   Set the requested behaviour in the packet (as the S flag) which allows different behaviours for different NRP IDs without the overhead of configuration on nodes that are unlikely to see packets for an NRP ID for which they don't have reserved resources.



  *   In fact, the S flag provides even greater granularity because it can be set per packet meaning that some packets within the NRP can take best effort, while others can be dropped. This, I think, recognises that an NRP carries multiple flows for different purposes (easy example is that different network slices might need different treatments).



And (again, in case any one is still worried) the NRP ID in the packet is not used to make any routing or forwarding decisions. It simply indicates which resources (bandwidth, queues, ...) are used by the packet.



So, I *do* see that the S flag could be moved to another document.  However, I think that would be jut making work for everyone. I also think it would be odd to define the base extension header with a flags field that has no flags defined - if I were an external reviewer of that, I would say that the field should be marked "Reserved" not "Flags", meaning that the document that defined the S flag would also have to Update the base spec to define the Flags field.



Cheers,

Adrian



-----Original Message-----
From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: 18 December 2023 15:47
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: '6man' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [IPv6] Progress of comments resolution on draft-ietf-6man-enhanced-vpn-vtn-id



Hi Med and Adrian,



Thanks for the discussion. Here I'd like to give some further explanation about the usage of the S bit and why it is considered useful.



In normal IPv6 packet forwarding, the next-hop and outgoing interface are determined based on longest matching of the destination IPv6 address. Packets with unmatched destination address are always dropped.



After the introduction of the VTN (or NRP, will use VTN just in this mail) option, the next-hop and outgoing interface are still determined based on the destination address, this is unchanged.



Then for packets whose next-hop and outgoing interface are determined, the VTN ID in the packet is used to match with the sets of local resources allocated to VTNs on the outgoing interface. There are two possible results:



  1) The VTN ID in the packet matches with the same VTN ID which is configured on the outgoing interface with a set of network resources, then the packet is forwarded using that set of resources.



  2) The VTN ID in the packet does not match with any VTN ID configured on the outgoing interface. How should the node behave in this case? There are two options: 1) forward the packet with best effort. 2) discard the packet.



The S flag is used to tell the node how to forward the packet when the VTN-ID is not configured on the outgoing interface.



With the above, I hope the functionality of the S flag is clear.



Then the possible question is can this be achieved by configuration?



The answer is it can, but possibly with a relatively higher cost. Note this is to control the behavior for NRPs which are not provisioned on the node's outgoing interface. Usually devices do not provide control configuration for elements which are not enabled. Even if such configuration is supported, as the behavior can be different per NRP, this requires lots of configuration for NRPs which are not enabled. Then we also need to consider the case where the behavior may be different for different flows under the same NRP...



One analogy (not quite the same) to the S flag is the bits in IPv6 extension header options which are used to control the forwarding behavior when the option cannot be parsed by some node. That may also be achieved via configuration on the nodes, while it turns out a better choice is to use flags to indicate the behavior for unrecognized entities.



With the above analysis, hope you also agree that the S flag is a more efficient approach for the required functionality.



Best regards,

Jie



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

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

> Sent: Thursday, December 14, 2023 8:23 PM

> To: [e-mail]<mailto:[e-mail]>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>

> Cc: '6man' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> Subject: RE: [IPv6] Progress of comments resolution on

> draft-ietf-6man-enhanced-vpn-vtn-id

>

> Hi Adrian,

>

> > 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 isn't.

>

> The issue is that the use of the S bit is not justified, including with the case you

> mentioned below. This scan be handled by a local config parameter. I fail to see

> valid arguments so far why a per-NRP per-packet behavior will needed to

> process a packet.

>

> Cheers,

> Med

>

> > -----Message d'origine-----

> > De : ipv6 <[e-mail]<mailto:[e-mail]>> De la part de Adrian Farrel Envoyé :

> > mardi 12 décembre 2023 18:04 À : 'Dongjie (Jimmy)'

> > <[e-mail]<mailto:[e-mail]>> Cc : '6man' <[e-mail]<mailto:[e-mail]>>;

> > draft-ietf-6man-enhanced-vpn-vtn- [e-mail]<mailto:[e-mail]> Objet : Re: [IPv6]

> > 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.

> >

> > -----------------------------------------------------------------

> > ---

> > IETF IPv6 working group mailing list

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

> > Administrative Requests:

> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>

> >

> Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=05%7C01%7Cmohamed.

> >

> boucadair%40orange.com%7Cc7b66a0799ca41a4b00e08dbfb346dd5%7C90c

> 7a

> >

> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638379974860934578%7CUn

> know

> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha

> >

> WwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9bNvzWEsR9J86r5zy3V%

> 2BD6Y

> > Iv9ZsyazWDcIjP6aUlNA%3D&reserved=0

> > -----------------------------------------------------------------

> > ---

> ___________________________________________________________________

> _________________________________________

> Ce message et ses pieces jointes peuvent contenir des informations

> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou

> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le

> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages

> electroniques etant susceptibles d'alteration, Orange decline toute

> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

>

> This message and its attachments may contain confidential or privileged

> information that may be protected by law; they should not be distributed,

> used or copied without authorisation.

> If you have received this email in error, please notify the sender and delete this

> message and its attachments.

> As emails may be altered, Orange is not liable for messages that have been

> modified, changed or falsified.

> Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.