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

[Gyan Mishra <[e-mail]>]

Hi Jie

Welcome.

I will review the draft some more and try to think of some other possible
use cases for the S bit.

Thanks

Gyan

On Tue, Jan 9, 2024 at 2:40 AM Dongjie (Jimmy) <[e-mail]> wrote:

> Hi Gyan,
>
> Thanks for sharing your opinion on the S flag. It is good to know you
> agree with keeping the S flag in this document.
>
> Our plan is to update the draft with some text to describe the usage of
> the S bit, and we are still open to opinions and suggestions.
>
> Best regards,
> Jie
>
> > -----Original Message-----
> > From: Gyan Mishra [mailto:[e-mail]]
> > Sent: Saturday, January 6, 2024 4:10 PM
> > To: [e-mail]
> > Cc: 6man <[e-mail]>; Dongjie (Jimmy) <[e-mail]>;
> > [e-mail];
> > [e-mail]
> > Subject: Re: [IPv6] Progress of comments resolution on
> > draft-ietf-6man-enhanced-vpn-vtn-id
> >
> > 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
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*