Subject: [Detnet] PREOF signaling

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Feb 2022 08:22:00 +0000

Dear WG

The HbH draft is soon to expire, and I do not see that we had a deep discussion and a consensus on which kind of signaling will work best for DetNet IPv6.

We have a proposal to encapsulate over UDP, which appears ready for adoption, and one to use IPv6 extension headers, which is ready to expire; arguments on the table include:

Size of the encapsulation
Complexity of silicon implementation
Reuse of MPLS design
IP version independence
DetNet and SRv6
Flow vs path (the pipe and the water)

I believe that each of those topics deserves a solid discussion before the group jumps on the UDP solution. The wrong decision now could mean a lot of wasted effort in the future.

Regards,

Pascal

Début du message transféré :

De: IETF Secretariat <[email-masked]>
Date: 13 février 2022 à 09:04:11 UTC+1
À: [email-masked]
Objet: Expiration impending: <draft-pthubert-detnet-ipv6-hbh-06.txt>

The following draft will expire soon:

Name:     draft-pthubert-detnet-ipv6-hbh
Title:    IPv6 Options for DetNet
State:    I-D Exists
Expires:  2022-02-25 (in 1 week, 4 days)

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 14 Feb 2022 03:16:03 +0000

Hi Pascal,

I think the choice between the UDP and HbH depends on the target scenario and use case.
If only need tasks on the server to behave, I think UDP should be a good choice.
If the on path network devices need to behave, I think HbH option should be better.

So what’s the scenario?

Best,
Tianran

From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Sunday, February 13, 2022 4:22 PM
To: [email-masked]
Subject: [Detnet] PREOF signaling

Dear WG

Regards,

Pascal

Début du message transféré :
De: IETF Secretariat <[email-masked]<mailto:[email-masked]>>
Date: 13 février 2022 à 09:04:11 UTC+1
À: [email-masked]<mailto:[email-masked]>
Objet: Expiration impending: <draft-pthubert-detnet-ipv6-hbh-06.txt>
The following draft will expire soon:

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 14 Feb 2022 12:46:38 +0000

Hi,

Thanks for the comments. I agree with Tianran there is no XOR relationship between
the UDP and the HbH solution. Usage may depend on the target scenario and use cases.

Cheers
Bala’zs

From: detnet <[email-masked]> On Behalf Of Tianran Zhou
Sent: Monday, February 14, 2022 4:16 AM
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; [email-masked]
Subject: Re: [Detnet] PREOF signaling

Hi Pascal,

So what’s the scenario?

Best,
Tianran

From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Sunday, February 13, 2022 4:22 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Detnet] PREOF signaling

Dear WG

Regards,

Pascal

---

From: Janos Farkas <[email-masked]>
Date: Mon, 14 Feb 2022 12:52:30 +0000

Hi,

I also agree that there is no XOR relation bw two such WG documents.
I guess it is worth highlighting again that the Intended status of https://datatracker.ietf.org/doc/draft-varga-detnet-ip-preof/ is Informational; and it just makes it clearer by explaining with different words what has been standardized by RFC 9025.

Best regards,
Janos

From: detnet <[email-masked]> On Behalf Of Balázs Varga A
Sent: Monday, February 14, 2022 1:47 PM
To: Tianran Zhou <zhoutianran=[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>; [email-masked]
Subject: Re: [Detnet] PREOF signaling

Hi,

Cheers
Bala’zs

From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Monday, February 14, 2022 4:16 AM
To: Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] PREOF signaling

Hi Pascal,

So what’s the scenario?

Best,
Tianran

Dear WG

Regards,

Pascal

---

From: "Yangfan(Fan,IP Standards)" <[email-masked]>
Date: Tue, 15 Feb 2022 01:49:14 +0000

Hi DetNet,

I agree two documents targets to different use cases and be useful in both scenarios. Even in IP(including IPv4, IPv6, SRv6,6lowpan…), more than one solutions/encapsulations are worth being specified if different network requires. Based on that, I suggest WG adopt two drafts together. To be clear to future readers, it is worth mentioning the background/use cases in each draft. I also suggest to change the title of “IPv6 Options for DetNet” to “Deterministic Networking (DetNet): DetNet PREOF via IPv6”.

Best,

Fan

From: detnet [mailto:[email-masked]] On Behalf Of Janos Farkas
Sent: Monday, February 14, 2022 8:53 PM
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Tianran Zhou <zhoutianran=[email-masked]>; Balázs Varga A <balazs.a.varga=[email-masked]>; [email-masked]
Subject: Re: [Detnet] PREOF signaling

Hi,

Best regards,
Janos

From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Balázs Varga A
Sent: Monday, February 14, 2022 1:47 PM
To: Tianran Zhou <zhoutianran=[email-masked]<mailto:zhoutianran=[email-masked]>>; Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] PREOF signaling

Hi,

Cheers
Bala’zs

Hi Pascal,

So what’s the scenario?

Best,
Tianran

Dear WG

Regards,

Pascal

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 16 Feb 2022 18:36:16 +0100

Pascal, *:

Thanks a lot for the HbH header work!

(Q: Remind me, which one is the UDP encap ?)

The HbH header document has a lot of interesting, but quite novel ideas that
should further be discussed. In general i think we should separate the data
model we want for DetNet services from the encapsulation, aka: create one
document where we define the desired data model (in an extensible fashion),
and then one or more encapsulations reusing the same data model.

Ideally the encapsulation documents would not need to be updated when we add
more data model items, e.g.: by use of appropriate registry definition. Aka:
the encoding rules should come from the registry or be pre-defined for all
supportable data-model extensions.

Wrt to the data items proposed:

- In MPLS we have other than just 32/8 bit sequence number counters, so i think
  we should have a data model which is a superset of what we have in MPLS to
  ease migration.

- The text is a bit euphemistic on the use of timestamps instead of sequence
  numbers (great marketing ;-). I think for fairness it should mention also key downsides:

  - It does not permit to detect loss

  - The elimination function becomes much harder to implement at high speeds,
    because efficient methods of matching duplicates (bitmasks for sequence
    number spaces) cannot be used.

Overall, i think that timestamps for PREOF would be even more of a new DetNet QoS
feature as T-CQF is for bounded latency (draft-eckert-detnet-mpls-tc-tcqf), which does
not even introduce new packet headers, but just new algorithms inside the
hops.

Aka: I am all for being more innovative in DetNet, but our really very conservative
and very well vetted T-CQF mechanism has not been making progress in DetNet for
about 4 years now, so i would really appreciate if we would also consider
that such long waiting work would be taken care of in the WG. Especially (and this
is another linkage to your draft) when we would start introducing new data-models
and not taking the data items required for example for T-CQF also into account).

Cheers
    Toerless

> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

-- 
---
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Feb 2022 10:48:39 +0000

Hello Toerless

Many thanks for this!

Please see below:

> -----Original Message-----
> From: Toerless Eckert <[email-masked]>
> Sent: mercredi 16 février 2022 18:36
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]

That's draft-varga-detnet-ip-preof

> The HbH header document has a lot of interesting, but quite novel ideas
> that should further be discussed. In general i think we should separate
> the data model we want for DetNet services from the encapsulation, aka:
> create one document where we define the desired data model (in an
> extensible fashion), and then one or more encapsulations reusing the same
> data model.
> 

Works for me

> Ideally the encapsulation documents would not need to be updated when we
> add more data model items, e.g.: by use of appropriate registry
> definition. Aka:

To be balanced with the need for a simple / hard coded format for hardware consumption

>   we should have a data model which is a superset of what we have in MPLS

OK

>   - It does not permit to detect loss

Agreed

>     number spaces) cannot be used.

Maybe so. Again I have hardware in mind and we're looking at a plain bitwise compare.

> 
> Overall, i think that timestamps for PREOF would be even more of a new
> DetNet QoS feature as T-CQF is for bounded latency (draft-eckert-detnet-
> mpls-tc-tcqf), which does not even introduce new packet headers, but just
> new algorithms inside the hops.

Time stamp is probably very hard to realize with current hardware. So I see that piece of the draft as a placeholder for a discussion. Should we propose it now so the hardware evolves sometime? Or drop it knowingly? Note that the time stamp would also sell as a way to detect whether a packet is "late" in which case it can be "accelerated" as a more intelligent "aging".

> 
> Aka: I am all for being more innovative in DetNet, but our really very
> conservative and very well vetted T-CQF mechanism has not been making
> progress in DetNet for about 4 years now, so i would really appreciate if
> we would also consider that such long waiting work would be taken care of
> in the WG. Especially (and this is another linkage to your draft) when we
> would start introducing new data-models and not taking the data items
> required for example for T-CQF also into account).

Good discussion, that would really be another EH that could be added to this draft as a suboption to the path information.

I guess the point you make on the data model applies there to.
At the moment both drafts appear as proposals to do some work. Whether it is published with the data model or the data model comes separate, before or after, depends on whether we agree to do the work in the first place.

Keep safe;

Pascal

> > The HbH draft is soon to expire, and I do not see that we had a deep
> discussion and a consensus on which kind of signaling will work best for
> DetNet IPv6.
> >
> > We have a proposal to encapsulate over UDP, which appears ready for
> adoption, and one to use IPv6 extension headers, which is ready to expire;
> arguments on the table include:
> >
> > I believe that each of those topics deserves a solid discussion before
> the group jumps on the UDP solution. The wrong decision now could mean a
> lot of wasted effort in the future.
> >
> > Regards,
> >
> > Pascal
> >