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

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

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