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

[[e-mail]]

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%7C90c7a
> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638379974860934578%7CUnknow
> 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.