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

[Gyan Mishra <[e-mail]>]

All,

I agree with Jie & Adrian that the S flag should be kept in the same
document and not split out.

As the S flag is part of the 8 bit flag field of the NRP ID and is
intrinsic to the specification for carrying the NRP ID in an IPv6 extension
header, I believe the S flag should be kept in the draft.

As pointed out by Adrian & Jie that the S flag provides more granularity
per-NRP ID per packet, per flow characteristic then is possible using a
configuration option for the case where the NRP ID does not match and the
drop of forward behavior.

Jie mentioned the BFD control packets use case however this could apply to
any OAM telemetry use case where strict match is required.  There as well
maybe other data path telemetry control packets use cases such as maybe
used by SR Policy SR PM STAMP/TWAMP packets that may need this S flag
requirement for steering per NRP ID, per packet or per flow into a Flex
Algo NRP ID sub topology network slice.

The S flag could also could be used with SR path tracing telemetry probe
packets per draft below:

https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/


Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Fri, Dec 22, 2023 at 1:18 PM Adrian Farrel <[e-mail]> wrote:

> 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]>
> Sent: 18 December 2023 15:47
> To: [e-mail]; [e-mail]
> Cc: '6man' <[e-mail]>; [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] <[e-mail]>
>
> > Sent: Thursday, December 14, 2023 8:23 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,
>
> >
>
> > > 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]> De la part de Adrian Farrel Envoyé :
>
> > > mardi 12 décembre 2023 18:04 À : 'Dongjie (Jimmy)'
>
> > > <[e-mail]> Cc : '6man' <[e-mail]>;
>
> > > draft-ietf-6man-enhanced-vpn-vtn- [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] <[e-mail]>]
> On Behalf Of Dongjie
>
> > > (Jimmy)
>
> > > > Sent: Wednesday, November 8, 2023 12:59 AM
>
> > > > To: 6man <mailto:[e-mail] <[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.
>
> > >
>
> > > -----------------------------------------------------------------
>
> > > ---
>
> > > IETF IPv6 working group mailing list
>
> > > [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.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>