Re: [Detnet] on signaling the packet treatment vs. the flow/OAM

Hi Pascal and David,
thank you for a great discussion. I fully agree with David that active OAM
must share fate with the monitored DetNet flow. Thus, all elements of IPv6
encapsulation that impact the treatment of a packet in the data path MUST
be identical across the DetNet flow and corresponding active OAM. Where it
gets tricky, in my opinion, is IPv6 HbH EH(s). I think that we need to look
closely at which HbH EHs used by the particular DetNet flow MUST also be
applied to the OAM test packets. It seems like we can do that analysis in,
for example, the OAM Considerations section.

WDYT?

Regards,
Greg

On Thu, Jul 28, 2022 at 4:21 PM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Great point David,
>
> If one places an ECMP hash in a DetNet network he would better do that
> consciously because the interaction with the DetNet service plane might be
> tricky.
>
> The idea along a DetNet path is that there’s no such surprise as an
> unexpected balancer.
>
> Adding a UDP layer just to obfuscate the inner traffic against such
> unexpected activity looks like an overkill to me.
>
> The service layer tightly controls its distribution. All nodes comply to
> DetNet. If DetNet says that the fate will depend on the tag, so it will be.
>
> Regards,
>
> Pascal
>
> > Le 28 juil. 2022 à 22:12, Black, David <David.Black=
> 40dell.com@dmarc.ietf.org> a écrit :
> >
> > Hi Pascal,
> >
> > I'm not Greg, but nonetheless ...
> >
> > One can certainly tag packets with IPv6 hbh headers, but there's still a
> concern for active OAM where the OAM traffic is a different flow that needs
> to fate-share with the traffic flow of interest.  Getting that fate-sharing
> to work in the presence of flow spreading measures (e.g., ECMP hashes) is
> possible, but subtle, and dependent on what the data plane is doing for
> flow spreading (e.g., hash inputs, number of hash buckets).  UDP
> encapsulating all the traffic that needs to share fate is independent of
> all that, and hence I'd characterize it as a more robust mechanism to
> ensure fate sharing ... at the cost of the encapsulation and consequences
> thereof (another instance of "no free lunch").
> >
> > Thanks, --David
> >
> > -----Original Message-----
> > From: detnet <detnet-bounces@ietf.org> On Behalf Of Pascal Thubert
> (pthubert)
> > Sent: Thursday, July 28, 2022 3:48 PM
> > To: gregimirsky@gmail.com
> > Cc: detnet@ietf.org
> > Subject: [Detnet] on signaling the packet treatment vs. the flow/OAM
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hello Greg:
> >
> > My point at the mike was that IPv6 allows you to tag packets with L3
> information (e.g., DetNet, but also routing topology / VRF for RPL, and all
> those things SRv6 does) related to packet treatment without impacting the
> upper layer information (UDP ports and all above UDP).
> >
> >
> > It's actually cool to leave upper layer do and signal their stuff and
> have DetNet signal its own stuff independently.
> > This way we can tag all sorts of packets for the same treatment, whether
> they are UDP or not, whether they are an app flow or OAM, etc...
> >
> > The way to do that in IPv6 is Extension Headers. This is the essence of
> the proposal in
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-07__;!!LpKI!g764fAu3jINFXJra3JMCgLbYlGpnPnE5hkPRXlDq4G-_KTqxk9KMGMi3dTHijBEertf03WLsnoSG9kuqrjmdT9EpGukcymj4$
> [datatracker[.]ietf[.]org] which was done with OAM (and flow aggregation)
> in mind.
> >
> > As it goes, the more we look at enhanced DetNet, the more tagging we
> will need. DetNet should own and control the tags it operates own. The
> mapping flow->tag is an ingress edge problem, just like tagging a VLAN is
> in .1Q... Your OAM packet should be whatever OAM wants IoT to be, and the
> ingress policy should apply the tag the DetNet network needs.
> >
> > Arguable, you could use UDP encaps as a tag. But is that the best tag?
> It's far in the packet (see the discussion on how far ASICs look in the
> packets) and heavy with information we do not need (the checksum is a MUST
> in IPv6, do we have enough ports?, etc...). It's like taking a truck to
> bring your loved one around the Cuomo lake. Works but maybe not the best
> idea.
> >
> > All the best,
> >
> > Pascal
> >
> >
> >
> >
> >
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/detnet__;!!LpKI!g764fAu3jINFXJra3JMCgLbYlGpnPnE5hkPRXlDq4G-_KTqxk9KMGMi3dTHijBEertf03WLsnoSG9kuqrjmdT9EpGgoSXTG4$
> [ietf[.]org]
>