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

We need to see the use cases that hop by hop OAM is applied.
In most cases, active OAM is used edge to edge. So there is no need for intermediate nodes to process. And OAM over UDP has least dependency on the intermediate nodes, hence easy to deploy.
If indeed there are requirements for hop by hop processing, I would agree with Pascal, tag over UDP is not a good idea.
In addition to active OAM, there are also passive and hybrid ways that we can apply.

Best,
Tianran
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, July 29, 2022 4:57 AM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Black, David <David.Black=40dell.com@dmarc.ietf.org>; detnet@ietf.org; Black, David <David.Black@dell.com>
Subject: 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<mailto: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<mailto: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<mailto:detnet-bounces@ietf.org>> On Behalf Of Pascal Thubert (pthubert)
> Sent: Thursday, July 28, 2022 3:48 PM
> To: gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>
> Cc: detnet@ietf.org<mailto: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$<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<mailto:detnet@ietf.org>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/detnet__;!!LpKI!g764fAu3jINFXJra3JMCgLbYlGpnPnE5hkPRXlDq4G-_KTqxk9KMGMi3dTHijBEertf03WLsnoSG9kuqrjmdT9EpGgoSXTG4$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/detnet__;!!LpKI!g764fAu3jINFXJra3JMCgLbYlGpnPnE5hkPRXlDq4G-_KTqxk9KMGMi3dTHijBEertf03WLsnoSG9kuqrjmdT9EpGgoSXTG4$> [ietf[.]org]