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

[Adrian Farrel <[e-mail]>]

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:  <mailto:[e-mail]> [e-mail]
< <mailto:[e-mail]> [e-mail]>

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

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

> Cc: '6man' < <mailto:[e-mail]> [e-mail]>;
<mailto:[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 < <mailto:[e-mail]> [e-mail]> De la
part de Adrian Farrel Envoyé :

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

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

> > draft-ietf-6man-enhanced-vpn-vtn-  <mailto:[e-mail]> [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]>
mailto:[e-mail]] On Behalf Of Dongjie

> > (Jimmy)

> > > Sent: Wednesday, November 8, 2023 12:59 AM

> > > To: 6man < <mailto:[e-mail]> mailto:[e-mail]>

> > > Cc:  <mailto:[e-mail]>
[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

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

> > Administrative Requests:

> >  <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252>
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.