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

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

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]] On Behalf Of Dongjie
> > (Jimmy)
> > > Sent: Wednesday, November 8, 2023 12:59 AM
> > > To: 6man <mailto:[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
> >
> 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.