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

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

Hi Med, 

I agree that in many cases fallback to best-effort would be the default behavior for user traffic. While as I mentioned in previous discussion, one application of the S flag is to control the behavior for some in-band OAM packets, such as BFD packets, which are used to detect the availability of the NRP-specific data path. BFD packets for such detection should be discarded when there is no matching NRP-ID on the outgoing interface, so as to trigger path switchover. This falls into the category where different packets in one NRP require different match behavior. 

For the transit nodes, it is difficult to distinguish BFD packets from user packets (same packet header), hence it is hard to provide different behavior for BFD packets via local configuration. While this problem can be easily solved with the S flag: the ingress node just needs to send BFD packets with the S flag set, while for user packets the S flag is unset. 

This is just one example showing the value the S flag. There are other use cases where the S flag could help to provide customized behavior with flexible granularity which is either difficult or burdensome to do with per-node local configuration.

If you agree, we may add some text in the draft to explain the benefit of the S flag comparing to per-node local configuration. 

Best regards,
Jie


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Wednesday, December 20, 2023 12:28 AM
> To: Dongjie (Jimmy) <[e-mail]>; Ketan Talaulikar
> <[e-mail]>; Dongjie (Jimmy)
> <jie.dong=[e-mail]>
> Cc: [e-mail]; 6man <[e-mail]>;
> [e-mail]
> Subject: RE: [IPv6] Progress of comments resolution on
> draft-ietf-6man-enhanced-vpn-vtn-id
> 
> Hi Jie, all,
> 
> I think we still need first a solid justification for per-NRP match behavior
> and also for differentiated match behavior for flows within an NRP.
> 
> That's said, IMO most of the cases can be caught by fall back as default
> behavior + config to override the behavior with a drop when no match.
> Supplying a config to override the default behavior is a minor task
> compared to touching a node to provision VTN resource partitions, etc.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dongjie (Jimmy) <[e-mail]> Envoyé : mardi 19
> décembre
> > 2023 03:57 À : Ketan Talaulikar <[e-mail]>; Dongjie
> > (Jimmy) <jie.dong=[e-mail]>
> > Cc : BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>;
> > [e-mail]; 6man <[e-mail]>; draft-ietf-6man-
> > [e-mail] Objet : RE: [IPv6] Progress of comments
> > resolution on draft-ietf- 6man-enhanced-vpn-vtn-id
> >
> > Hi Ketan,
> >
> > Thanks for the comment. As you have corrected in another mail, this
> > flag is not in the SRH.
> >
> > I see you also agree that when the NRP ID in packet does not match
> > with any NRP-ID available on the node, an indication to control
> > whether to drop or fallback to best effort is needed.
> >
> > If you read my below email carefully, such indication is not a simple
> > global nob, it needs to be (at least) per-NRP, and actually it is for
> > NRPs which are NOT provisioned on the local node/outgoing interface.
> > This is different from what we usually do with configuration. Also
> > note if using local configuration, this needs to be configured on
> > every node along the path, not just the ingress node. This would
> > further complicate the provisioning.
> >
> > Thus it is considered more efficient to have the policy configured on
> > the ingress node (which is be part of the NRP), and convey the
> > indication to the downstream nodes together with the packet.
> >
> > The existing TOS/DSCP/EXP are for QoS class indication, which are
> > still useful within an NRP, so it is better not to overload them with
> > additional semantics.
> >
> > Best regards,
> > Jie
> >
> > > -----Original Message-----
> > > From: Ketan Talaulikar [mailto:[e-mail]]
> > > Sent: Tuesday, December 19, 2023 12:42 AM
> > > To: Dongjie (Jimmy) <jie.dong=[e-mail]>
> > > Cc: [e-mail]; [e-mail]; 6man
> > > <[e-mail]>; [e-mail]
> > > Subject: Re: [IPv6] Progress of comments resolution on
> > > draft-ietf-6man-enhanced-vpn-vtn-id
> > >
> > > 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
> _________________________________________________________
> ___________________________________________________
> 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.