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

[Ketan Talaulikar <[e-mail]>]

My apologies for the mixup - the S flag is not from the SRH but the VTN/NRP
ID extn header. But the rest of my comments still apply.

Thanks,
Ketan


On Mon, Dec 18, 2023 at 10:12 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Jie,
>
> I concur with Med on this one and don't see the need for the S-flag. We've
> had TOS/DSCP/EXP for QoS where exactly the same scenario exists and we've
> never had the need for such a flag/indication on the packet.
>
> This looks something like a local configuration/policy on the router to me
> - drop or fallback.
>
> We have very limited (8) flags on the SRH and there should be really
> strong and compelling reasons for allocating one. This one doesn't look
> like such.
>
> Thanks,
> Ketan
>
>
> On Mon, Dec 18, 2023 at 9:17 PM Dongjie (Jimmy) <jie.dong=
> [e-mail]> wrote:
>
>> 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.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>