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

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

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