Subject: [Detnet] DP solution (Flow identification)

From: Balázs Varga A <[email-masked]>
Date: Tue, 16 Jan 2018 18:20:32 +0000

I think the last mails are more about flow identification and not the sequence number.
So, I have re-subjected my answer.

PSN layer vs. DN layer (MPLS):
- in current data plane text we have stated that DetNet PWs may use dedicated LSPs (TE-tunnels).
That allow to identify DetNet flows in PSN layer without checking the PW label. Such a solution of
course may challenge scalability.
- regarding prioritization: text allows both E-LSP and L-LSP concept, what makes possible
to identify DetNet packets. However that is more for simple queuing scenarios as it does not
identify individual flows.

PSN layer vs. DN layer (non-MPLS):
- IPv4: If I remember correctly it was discussed to be out-of-scope to simplify the scenarios we focus on.
No-one wanted to define new IPv4 fields for flow-ID and Seq-Num in the “sunset of IPv4”.
- IPv6: based on the src-IPv6 and the flow-label NP can detect DetNet flows. Why would we need a new
IP protocol type?

Generic vs. DN aware data plane:
- I think we need both. We have use-cases specified for both.

DetNet traffic to be transported:
- two types are considered:
(1) Ethernet: IEEE TSN traffic encapsulated in Ethernet frames and
(2) IP: IPv6 transported over any L2 (not always Ethernet, but most cases Ethernet)
As noted above IPv4 is currently out-of-scope …

Cheers
Bala’zs

From: Stewart Bryant [mailto:[email-masked]]
Sent: 2018. január 16. 17:38
To: Andrew G. Malis <[email-masked]>
Cc: Mach Chen <[email-masked]>; Balázs Varga A <[email-masked]>; DetNet WG <[email-masked]>
Subject: Re: [Detnet] DP solution (Sequence Numbering)

Andy
On 16/01/2018 15:20, Andrew G. Malis wrote:
Stewart,

Like with PWs (since DETNET for MPLS would just be another PW type), targeted LDP and provisioning (via a central controller, NMS, etc.) are alternatives to RSVP and SR to provisioning/allocating the DETNET PW label.

.. and I suppose strictly BGP which is also used for this purpose in VPNs

You and Mach are both right that in the IP (non-MPLS) case, we need a way for the NP to detect DETNET flows. We could have a new IP protocol type for DETNET, and a DETNET header directly follows the IP header. In that case, the DETNET header would also need a next protocol identifier, unless the next protocol is always another IP header.

Last I saw, the thinking was that there would be an IP extension header, although I am not a fan of those since (a) I am not confident what a router will do one it does not understand, and (b) I am concerned about the need to support IPv4 which I suspect will have a long tail in enterprise deployment.

I prefer a UDP type for this purpose since it has universal support through any middle box. firewall etc, and all routers need to look a the UDP DP so checking if it is one they need to work on is just one compare and conditional branch.

Of course, for MPLS, the DETNET PW label is the identifier.

Only at the PW layer. Note my question about whether this is sufficient.

- Stewart

Cheers,
Andy

On Tue, Jan 16, 2018 at 5:46 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

If we need to discriminate at the PSN layer rather than the DN layer then we really are forced to create a new FEC type for MPLS, or synthesize one through RSVP or SR. IP has no native support for this, but we could introduce the concept, for example by making this the property of the IP address or some way of MPLSing IP.

However there is a deeper question we need to answer. Is our expectation that each hop in the data plane DN aware, or is our expectation that at lest in some networks the data plane is generic with some DN nodes strategically placed?

I can see than in some greenfield specialist cases the routers will all be DN aware, but in order to get deployment in most networks we need to design for the case where only strategic nodes are DN aware.

- Stewart

On 16/01/2018 01:14, Mach Chen wrote:
Hi Balazs,

#2 is a more nature solution, the DetNet CW is dedicated for DetNet, seems there is no compatibility issue.

In addition, I think we need to define a way on how to differentiate a DetNet flow from a non-DetNet flow, then the network processor can process the CW as expected.  In TSN, it uses the priority to determine whether a flow is TSN or non-TSN flow. For DetNet, should we also use the same way (e.g., TC, DSCP)? Or the DetNet service Label itself implies the situation, but it seems that this only works when the DetNet service label is the top label.

Any other thoughts?

Best regards,
Mach

From: detnet [mailto:[email-masked]] On Behalf Of Balázs Varga A
Sent: Monday, January 15, 2018 9:06 PM
To: DetNet WG <[email-masked]><mailto:[email-masked]>
Subject: [Detnet] DP solution (Sequence Numbering)

Hi,

Some thoughts to start discussion on open points of the DP solution draft.

This mail(-thread) is on sequence numbering.

Problem in case of MPLS and DetNet Control Word:

- S/N skips zero problem: Ethernet PW definition states that S/N skips zero.

It uses zero to mean no S/N in use. (rfc4448)

Possible problem resolutions:

#1: Using a "flag" in the reserved bits part of the CW:

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |0 0 0 0|D|reserved - set to 0  |   16 bit Sequence Number      |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D-bit: set to “1” means DetNet specific Seq. Number used,

Bit5-15: reserved.

RFC4448 states that reserved bits “MUST be ignored upon receipt”, so backward

compatibility is ensured. Such a solution would allow also to use longer seq.num.

formats (if needed). Such a format is also inline with RFC4385.

#2: Making “0” as a valid Seq.Num.

DetNet flows are recognized and forwarded special within the DetNet

domain. S/N is used within the DetNet domain by DetNet Service functions

(i.e. PREF). S/N used only on DetNet end-nodes and DetNet relay-nodes. No

other nodes care about the value of S/N, therefore DetNet can specify its

own sequence number processing algorithm. So “0” can be a valid number

and not the indication that no Seq.Num. is used. This is inline with RFC4385.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

is available for download at:

https://ietf.webex.com/ietf/ldr.php?RCID=e5116bc7db254c24a7bb3217bf202301

raw notes are available at

http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-01

Please feel free to update the etherpad based on the recording.

Lou (and co-chairs)

_______________________________________________

detnet mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________

detnet mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/detnet

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

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 16 Jan 2018 18:38:19 +0000

Hi Bala’zs,
Regarding IPv4, I also understood that we decided that we can’t add new IPv4 fields. Pardon my ignorance here, but does that mean there is no part of DetNet capability that can be run over IPv4? Or is there some “workaround” to provide as I say even part of the DetNet capability, given that it is an Engineered network? I just want to clarify expectations here.
Thanks,
Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of Balázs Varga A
Sent: Tuesday, January 16, 2018 10:21 AM
To: Stewart Bryant <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: DetNet WG <[email-masked]>; Mach Chen <[email-masked]>
Subject: [Detnet] DP solution (Flow identification)

Cheers
Bala’zs

From: Stewart Bryant [mailto:[email-masked]]
Sent: 2018. január 16. 17:38
To: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Cc: Mach Chen <[email-masked]<mailto:[email-masked]>>; Balázs Varga A <[email-masked]<mailto:[email-masked]>>; DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] DP solution (Sequence Numbering)

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

https://ietf.webex.com/ietf/ldr.php?RCID=e5116bc7db254c24a7bb3217bf202301<https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_ldr.php-3FRCID-3De5116bc7db254c24a7bb3217bf202301&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=3rb3RE_Z2wOW8vp-AMsa2lgSh0U4BgdZF7zu1tXwd6k&e=>

http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-01<https://urldefense.proofpoint.com/v2/url?u=http-3A__etherpad.tools.ietf.org-3A9000_p_notes-2Dietf-2Dinterim-2D2018-2Ddetnet-2D01&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=lO_ZdHArQQsaDNYvMyIczmd6F1P_acuM0kFMZ51UX6c&e=>

Lou (and co-chairs)

detnet mailing list

https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>

detnet mailing list

https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 16 Jan 2018 20:20:50 +0000

> course may challenge scalability.

Do you mean may, MAY or do you mean MUST?

If the plan is to use the PSN label as the payload type indicator that 
has a number of implications that we need to be clear about.

1) We need a new FEC.

2) We cannot deploy classes of determinism for example that that just 
need 1+1 and do not care about delay over an existing MPLS PSN.

If you think that the LSP label identifies the PW I need to point you at 
some work in the early days if PW. It does not scale.
It does not scale and that is why it never went anywhere as an approach 
despite initial commercial deployment.

> identify individual flows.

I am not sure how much L-LSP is in the wild. L-LSP needs RSVP-TE as far 
as I can tell, but
segment routing puts a new twist on that which I am sure has not yet had 
full attention.

> No-one wanted to define new IPv4 fields for flow-ID and Seq-Num in the 

There hangs a much bigger story. Some in the IETF want to kill off IPv4, 
as much as anything
to force the introduction of IPv6. However it is not a question of what 
we want to do
it is a question of the needs of the users.

> flows. Why would we need a new

I am highly sceptical about the flow label given its history.

We could use IP address as the payload type, IF we can get the Internet 
area to agree, but it
is a big extension of the IP address semantics, something that perhaps 
the IETF should
consider taking up to the BOF level given the inroads into those 
semantics that SR is
trying to make.

> As noted above IPv4 is currently out-of-scope …

I am not sure about the IPv4 scoping we need to understand the needs of 
our users.

If however we are carrying IP over PW we will need a shim to give us the 
type
something we looked at a while ago in PWE3 and concluded that the best shim
was Ethernet. If we want to carry it in a slightly more compact way we need
to have a more complex CW with type and length and possible frag.

- Stewart

> Cheers
>
> Bala’zs
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* 2018. január 16. 17:38
> *To:* Andrew G. Malis <[email-masked]>
> *Cc:* Mach Chen <[email-masked]>; Balázs Varga A 
> <[email-masked]>; DetNet WG <[email-masked]>
> *Subject:* Re: [Detnet] DP solution (Sequence Numbering)
>
> Andy
>
>     Like with PWs (since DETNET for MPLS would just be another PW
>     type), targeted LDP and provisioning (via a central controller,
>     NMS, etc.) are alternatives to RSVP and SR to
>     provisioning/allocating the DETNET PW label.
>
>
>     You and Mach are both right that in the IP (non-MPLS) case, we
>     need a way for the NP to detect DETNET flows. We could have a new
>     IP protocol type for DETNET, and a DETNET header directly follows
>     the IP header. In that case, the DETNET header would also need a
>     next protocol identifier, unless the next protocol is always
>     another IP header.
>
>
> Last I saw, the thinking was that there would be an IP extension 
> header, although I am not a fan of those since (a) I am not confident 
> what a router will do one it does not understand, and (b) I am 
> concerned about the need to support IPv4 which I suspect will have a 
> long tail in enterprise deployment.
>
> I prefer a UDP type for this purpose since it has universal support 
> through any middle box. firewall etc, and all routers need to look a 
> the UDP DP so checking if it is one they need to work on is just one 
> compare and conditional branch.
>
>
>     On Tue, Jan 16, 2018 at 5:46 AM, Stewart Bryant
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         If we need to discriminate at the PSN layer rather than the DN
>         layer then we really are forced to create a new FEC type for
>         MPLS, or synthesize one through RSVP or SR. IP has no native
>         support for this, but we could introduce the concept, for
>         example by making this the property of the IP address or some
>         way of MPLSing IP.
>
>         However there is a deeper question we need to answer. Is our
>         expectation that each hop in the data plane DN aware, or is
>         our expectation that at lest in some networks the data plane
>         is generic with some DN nodes strategically placed?
>
>         I can see than in some greenfield specialist cases the routers
>         will all be DN aware, but in order to get deployment in most
>         networks we need to design for the case where only strategic
>         nodes are DN aware.
>
>         - Stewart
>
>             #2 is a more nature solution, the DetNet CW is dedicated
>             for DetNet, seems there is no compatibility issue.
>
>             In addition, I think we need to define a way on how to
>             differentiate a DetNet flow from a non-DetNet flow, then
>             the network processor can process the CW as expected. In
>             TSN, it uses the priority to determine whether a flow is
>             TSN or non-TSN flow. For DetNet, should we also use the
>             same way (e.g., TC, DSCP)? Or the DetNet service Label
>             itself implies the situation, but it seems that this only
>             works when the DetNet service label is the top label.
>
>             Any other thoughts?
>
>             Best regards,
>
>             Mach
>
>             *From:* detnet [mailto:[email-masked]] *On Behalf
>             Of *Balázs Varga A
>             *Sent:* Monday, January 15, 2018 9:06 PM
>             *To:* DetNet WG <[email-masked]> <mailto:[email-masked]>
>             *Subject:* [Detnet] DP solution (Sequence Numbering)
>
>             Hi,
>
>             To: DetNet WG <[email-masked] <mailto:[email-masked]>>
>             [email-masked] <mailto:[email-masked]>
>
>             [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>

---

From: Jouni <[email-masked]>
Date: Wed, 17 Jan 2018 01:23:41 +0200

> On 16 Jan 2018, at 22:20, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> If the plan is to use the PSN label as the payload type indicator that has a number of implications that we need to be clear about.

By payload you mean the DetNet flows over an LSP that have specific queuing/forwarding treatment?

> 1) We need a new FEC. 

Would there be a problem to introduce a new FEC?

> 2) We cannot deploy classes of determinism for example that that just need 1+1 and do not care about delay over an existing MPLS PSN.

Could you rephrase the above? 

> If you think that the LSP label identifies the PW I need to point you at some work in the early days if PW. It does not scale. 
> It does not scale and that is why it never went anywhere as an approach despite initial commercial deployment.

LSP label referred here is here the top label?

- Jouni

> I am not sure how much L-LSP is in the wild. L-LSP needs RSVP-TE as far as I can tell, but 
> segment routing puts a new twist on that which I am sure has not yet had full attention. 
> 
>>  
> There hangs a much bigger story. Some in the IETF want to kill off IPv4, as much as anything
> to force the introduction of IPv6. However it is not a question of what we want to do
> We could use IP address as the payload type, IF we can get the Internet area to agree, but it
> is a big extension of the IP address semantics, something that perhaps the IETF should
> consider taking up to the BOF level given the inroads into those semantics that SR is
> trying to make.
> 
>>  
> I am not sure about the IPv4 scoping we need to understand the needs of our users.
> 
> If however we are carrying IP over PW we will need a shim to give us the type
>> On Tue, Jan 16, 2018 at 5:46 AM, Stewart Bryant <[email-masked]> wrote:
>> To: DetNet WG <[email-masked]>
>> To: DetNet WG <[email-masked]>
>> [email-masked]
>> [email-masked]
>> [email-masked]
> [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Jan 2018 08:29:01 +0000

On 16/01/2018 18:38, Grossman, Ethan A. wrote:
>
> Hi Bala’zs,
>
> Regarding IPv4, I also understood that we decided that we can’t add 
> new IPv4 fields. Pardon my ignorance here, but does that mean there is 
> no part of DetNet capability that can be run over IPv4? Or is there 
> some “workaround” to provide as I say even part of the DetNet 
> capability, given that it is an Engineered network? I just want to 
> clarify expectations here.
>

If you have a native IPv4 network to which you present IPv6 packets, you 
either have to tunnel them across where the IPv6 is considered opaque 
data, or you have to translate them to IPv4, but that requires some 
common semantics to deal with extension headers which we don't currently 
have.

So, as far as I can see, a decision not to support IPv4 means no DN 
support across the IPv4 network.

Which takes us back to the question of how important is this and what 
will it do to the take-up of the technology by its target customers?

- Stewart

> Thanks,
>
> Ethan.
>
> *From:*detnet [mailto:[email-masked]] *On Behalf Of *Balázs 
> Varga A
> *Sent:* Tuesday, January 16, 2018 10:21 AM
> *To:* Stewart Bryant <[email-masked]>; Andrew G. Malis 
> <[email-masked]>
> *Cc:* DetNet WG <[email-masked]>; Mach Chen <[email-masked]>
> *Subject:* [Detnet] DP solution (Flow identification)
>
> *To:* Andrew G. Malis <[email-masked] <mailto:[email-masked]>>
> *Cc:* Mach Chen <[email-masked] <mailto:[email-masked]>>; 
> Balázs Varga A <[email-masked] 
> <mailto:[email-masked]>>; DetNet WG <[email-masked] 
> <mailto:[email-masked]>>
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_ldr.php-3FRCID-3De5116bc7db254c24a7bb3217bf202301&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=3rb3RE_Z2wOW8vp-AMsa2lgSh0U4BgdZF7zu1tXwd6k&e=>
>
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__etherpad.tools.ietf.org-3A9000_p_notes-2Dietf-2Dinterim-2D2018-2Ddetnet-2D01&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=lO_ZdHArQQsaDNYvMyIczmd6F1P_acuM0kFMZ51UX6c&e=>
>
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>
>
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>
>
>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 17 Jan 2018 18:24:01 +0000

Thanks Stewart for the clarification. I interpret your statement “a decision not to support IPv4” to mean “a decision not to propose adding anything to the existing IPv4 standard”. If that isn’t correct, please let me know. As you may recall I already started a thread awhile ago to discuss IPv4 vs IPv6, and based on the responses it appeared to me at that time that there were some kind of options, though not a “native IPv4” solution, but it wasn’t clear to me (as a non-expert in the various networking protocols mentioned) whether they would be viable in practice or not. I will revive that thread and see if we can get any closer to determining the importance of IPv4 to our target customers, and hopefully some sense of whether the proposed non-native-IPv4 strategies will hold water.
Ethan.

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 12:29 AM
To: Grossman, Ethan A. <[email-masked]>; Balázs Varga A <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: DetNet WG <[email-masked]>; Mach Chen <[email-masked]>
Subject: Re: DP solution (Flow identification)

If you have a native IPv4 network to which you present IPv6 packets, you either have to tunnel them across where the IPv6 is considered opaque data, or you have to translate them to IPv4, but that requires some common semantics to deal with extension headers which we don't currently have.

So, as far as I can see, a decision not to support IPv4 means no DN support across the IPv4 network.

Which takes us back to the question of how important is this and what will it do to the take-up of the technology by its target customers?

- Stewart

Thanks,
Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of Balázs Varga A
Sent: Tuesday, January 16, 2018 10:21 AM
To: Stewart Bryant <[email-masked]><mailto:[email-masked]>; Andrew G. Malis <[email-masked]><mailto:[email-masked]>
Cc: DetNet WG <[email-masked]><mailto:[email-masked]>; Mach Chen <[email-masked]><mailto:[email-masked]>
Subject: [Detnet] DP solution (Flow identification)

Cheers
Bala’zs

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Jan 2018 18:38:43 +0000

Hi  Ethan,

On 17/01/2018 18:24, Grossman, Ethan A. wrote:
>
> Thanks Stewart for the clarification. I interpret your statement “a 
> decision not to support IPv4” to mean “a decision not to propose 
> adding anything to the existing IPv4 standard”.
>

To support IPv4 there are a number of methods that are possible, one is 
to add something to v4 itself as is proposed for v6. Adding something to 
the base protocol will be very difficult.

Another method, is to do what has been proposed by some for MPLS, that 
is to encode the identity and type in the IP address. There is a 
proposal to do this in SRv6. I am not a great fan of abusing the address 
space for this in the way proposed by that work, but maybe we can do 
something much simpler here and simply identify the DN instance by the 
IP address with no other semantics. Much easier to do this for IPv6 with 
the "infinite addresses" but we could get away with it in limited 
private Ipv4 networks. Of course this does change the per-hop behaviour 
of IP which may be a challenge to get the IETF to sign of on.

Another method is to use some method of carrying an MPLS label stack - 
this was the first proposal. Now I said that I did not think anyone had 
done that and I still believe that to be the case, but that does not 
mean that it is not the least worst approach. There are alternates for 
example IP/UDP/MPLS
which is the so called USR approach that a number of us advocate as an 
alternative to SRv6.

> If that isn’t correct, please let me know. As you may recall I already 
> started a thread awhile ago to discuss IPv4 vs IPv6, and based on the 
> responses it appeared to me at that time that there were some kind of 
> options, though not a “native IPv4” solution, but it wasn’t clear to 
> me (as a non-expert in the various networking protocols mentioned) 
> whether they would be viable in practice or not. I will revive that 
> thread and see if we can get any closer to determining the importance 
> of IPv4 to our target customers, and hopefully some sense of whether 
> the proposed non-native-IPv4 strategies will hold water.
>

Yes, we need to have the discussion on the list and reach a consensus of 
whether

a) We support v4
b) We support v4 and v6 by v4 and v6 specific protocol extensions
c) We use a single common IP approach
d) We use an approach that is common across IP and MPLS

- Stewart

> *Sent:* Wednesday, January 17, 2018 12:29 AM
> *To:* Grossman, Ethan A. <[email-masked]>; Balázs Varga A 
> <[email-masked]>; Andrew G. Malis <[email-masked]>
> *Subject:* Re: DP solution (Flow identification)
>
>     Regarding IPv4, I also understood that we decided that we can’t
>     add new IPv4 fields. Pardon my ignorance here, but does that mean
>     there is no part of DetNet capability that can be run over IPv4?
>     Or is there some “workaround” to provide as I say even part of the
>     DetNet capability, given that it is an Engineered network? I just
>     want to clarify expectations here.
>
>
> If you have a native IPv4 network to which you present IPv6 packets, 
> you either have to tunnel them across where the IPv6 is considered 
> opaque data, or you have to translate them to IPv4, but that requires 
> some common semantics to deal with extension headers which we don't 
> currently have.
>
>     *From:*detnet [mailto:[email-masked]] *On Behalf Of
>     *Balázs Varga A
>     *To:* Stewart Bryant <[email-masked]>
>     <mailto:[email-masked]>; Andrew G. Malis
>     <[email-masked]> <mailto:[email-masked]>
>     *Cc:* DetNet WG <[email-masked]> <mailto:[email-masked]>; Mach
>     Chen <[email-masked]> <mailto:[email-masked]>
>     - IPv4: If I remember correctly it was discussed to be
>     out-of-scope to simplify the scenarios we focus on.
>
>     *Cc:* Mach Chen <[email-masked]
>     <mailto:[email-masked]>>; Balázs Varga A
>     <[email-masked]
>         type), targeted LDP and provisioning (via a central
>         controller, NMS, etc.) are alternatives to RSVP and SR to
>         need a way for the NP to detect DETNET flows. We could have a
>         new IP protocol type for DETNET, and a DETNET header directly
>         follows the IP header. In that case, the DETNET header would
>         also need a next protocol identifier, unless the next protocol
>         is always another IP header.
>
>
>     header, although I am not a fan of those since (a) I am not
>     confident what a router will do one it does not understand, and
>     (b) I am concerned about the need to support IPv4 which I suspect
>     will have a long tail in enterprise deployment.
>
>     I prefer a UDP type for this purpose since it has universal
>     support through any middle box. firewall etc, and all routers need
>     to look a the UDP DP so checking if it is one they need to work on
>     is just one compare and conditional branch.
>
>
>             If we need to discriminate at the PSN layer rather than
>             the DN layer then we really are forced to create a new FEC
>             type for MPLS, or synthesize one through RSVP or SR. IP
>             has no native support for this, but we could introduce the
>             concept, for example by making this the property of the IP
>             address or some way of MPLSing IP.
>
>             However there is a deeper question we need to answer. Is
>             our expectation that each hop in the data plane DN aware,
>             or is our expectation that at lest in some networks the
>             data plane is generic with some DN nodes strategically placed?
>
>             I can see than in some greenfield specialist cases the
>             routers will all be DN aware, but in order to get
>             deployment in most networks we need to design for the case
>             where only strategic nodes are DN aware.
>
>             - Stewart
>
>                 #2 is a more nature solution, the DetNet CW is
>                 dedicated for DetNet, seems there is no compatibility
>                 issue.
>
>                 differentiate a DetNet flow from a non-DetNet flow,
>                 then the network processor can process the CW as
>                 expected.  In TSN, it uses the priority to determine
>                 whether a flow is TSN or non-TSN flow. For DetNet,
>                 should we also use the same way (e.g., TC, DSCP)? Or
>                 the DetNet service Label itself implies the situation,
>                 but it seems that this only works when the DetNet
>                 service label is the top label.
>
>                 Any other thoughts?
>
>                 Best regards,
>
>                 Mach
>
>                 *From:* detnet [mailto:[email-masked]] *On
>                 Behalf Of *Balázs Varga A

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 17 Jan 2018 18:51:27 +0000

Thanks Stewart. Regarding:
“Yes, we need to have the discussion on the list and reach a consensus of whether
a) We support v4
b) We support v4 and v6 by v4 and v6 specific protocol extensions
c) We use a single common IP approach
d) We use an approach that is common across IP and MPLS”

Perhaps, given Tim Chown’s earlier comment:
        “If you’re suggesting an IPv4-only solution, you’re running up against https://www.iab.org/2016/11/07/iab-statement-on-ipv6/.”

We could get Deborah with her AD hat on to comment on this?
Ethan.

Sent: Wednesday, January 17, 2018 10:39 AM

Hi  Ethan,

On 17/01/2018 18:24, Grossman, Ethan A. wrote:
Thanks Stewart for the clarification. I interpret your statement “a decision not to support IPv4” to mean “a decision not to propose adding anything to the existing IPv4 standard”.

To support IPv4 there are a number of methods that are possible, one is to add something to v4 itself as is proposed for v6. Adding something to the base protocol will be very difficult.

Another method, is to do what has been proposed by some for MPLS, that is to encode the identity and type in the IP address. There is a proposal to do this in SRv6. I am not a great fan of abusing the address space for this in the way proposed by that work, but maybe we can do something much simpler here and simply identify the DN instance by the IP address with no other semantics. Much easier to do this for IPv6 with the "infinite addresses" but we could get away with it in limited private Ipv4 networks. Of course this does change the per-hop behaviour of IP which may be a challenge to get the IETF to sign of on.

Another method is to use some method of carrying an MPLS label stack - this was the first proposal. Now I said that I did not think anyone had done that and I still believe that to be the case, but that does not mean that it is not the least worst approach. There are alternates for example IP/UDP/MPLS
which is the so called USR approach that a number of us advocate as an alternative to SRv6.

If that isn’t correct, please let me know. As you may recall I already started a thread awhile ago to discuss IPv4 vs IPv6, and based on the responses it appeared to me at that time that there were some kind of options, though not a “native IPv4” solution, but it wasn’t clear to me (as a non-expert in the various networking protocols mentioned) whether they would be viable in practice or not. I will revive that thread and see if we can get any closer to determining the importance of IPv4 to our target customers, and hopefully some sense of whether the proposed non-native-IPv4 strategies will hold water.

Yes, we need to have the discussion on the list and reach a consensus of whether

a) We support v4

- Stewart

Ethan.

To: Grossman, Ethan A. <[email-masked]><mailto:[email-masked]>; Balázs Varga A <[email-masked]><mailto:[email-masked]>; Andrew G. Malis <[email-masked]><mailto:[email-masked]>

- Stewart

Thanks,
Ethan.

Cheers
Bala’zs

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 17 Jan 2018 18:56:56 +0000

Maybe I didn’t interpret Tim’s comment correctly – I interpreted it to mean “an IPv4-only solution” in the context of also having IPv6 and MPLS solutions, as we’re planning. Does the IAB directive still apply in that case?
Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of Grossman, Ethan A.
Sent: Wednesday, January 17, 2018 10:51 AM
To: DetNet WG <[email-masked]>; Deborah Brungard <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: Tim Chown ([email-masked]) <[email-masked]>
Subject: Re: [Detnet] DP solution (Flow identification)

        “If you’re suggesting an IPv4-only solution, you’re running up against https://www.iab.org/2016/11/07/iab-statement-on-ipv6/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iab.org_2016_11_07_iab-2Dstatement-2Don-2Dipv6_&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=oXVLyuObJ6nJvM1lEu50B-g3YBVoCmxP_kRgjhC4tDk&s=GLJ2oCCQ3YYzToc4GGxH9Rg6SLJD8RJSyyRgE2q-mjM&e=>.”

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 10:39 AM
To: Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; Balázs Varga A <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Cc: DetNet WG <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>
Subject: Re: DP solution (Flow identification)

Hi  Ethan,

a) We support v4

- Stewart

Ethan.

- Stewart

Thanks,
Ethan.

Cheers
Bala’zs

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Jan 2018 19:01:33 +0000

A point I have made before and will continue to make:

If the IETF does not maintain IPv4 appropriately until it's natural 
death, it will be declared critical national infrastructure by 
governments and they will effectively gift it to their SDO (the ITU-T). 
Such an organization may find it expedient to find many new ways to 
extend the life of IPv4. In any case I anticipate a very long tail on 
the IPv4 decay curve.

We need to do what is right for our customers, some of whom may find it 
infeasible to migrate away from IPv4 any time soon.

I will of course be interested in Deborah's directive on this.

- Stewart

On 17/01/2018 18:51, Grossman, Ethan A. wrote:
>         “If you’re suggesting an IPv4-only solution, you’re running up 
> against https://www.iab.org/2016/11/07/iab-statement-on-ipv6/.”
>
> *Sent:* Wednesday, January 17, 2018 10:39 AM
>     Thanks Stewart for the clarification. I interpret your statement
>     “a decision not to support IPv4” to mean “a decision not to
>     propose adding anything to the existing IPv4 standard”.
>
>
> To support IPv4 there are a number of methods that are possible, one 
> is to add something to v4 itself as is proposed for v6. Adding 
> something to the base protocol will be very difficult.
>
> proposal to do this in SRv6. I am not a great fan of abusing the 
> address space for this in the way proposed by that work, but maybe we 
> can do something much simpler here and simply identify the DN instance 
> by the IP address with no other semantics. Much easier to do this for 
> IPv6 with the "infinite addresses" but we could get away with it in 
> limited private Ipv4 networks. Of course this does change the per-hop 
> behaviour of IP which may be a challenge to get the IETF to sign of on.
>
> this was the first proposal. Now I said that I did not think anyone 
> had done that and I still believe that to be the case, but that does 
> not mean that it is not the least worst approach. There are alternates 
> for example IP/UDP/MPLS
>     If that isn’t correct, please let me know. As you may recall I
>     already started a thread awhile ago to discuss IPv4 vs IPv6, and
>     based on the responses it appeared to me at that time that there
>     were some kind of options, though not a “native IPv4” solution,
>     but it wasn’t clear to me (as a non-expert in the various
>     networking protocols mentioned) whether they would be viable in
>     practice or not. I will revive that thread and see if we can get
>     any closer to determining the importance of IPv4 to our target
>     customers, and hopefully some sense of whether the proposed
>     non-native-IPv4 strategies will hold water.
>
>
>     *To:* Grossman, Ethan A. <[email-masked]>
>     <mailto:[email-masked]>; Balázs Varga A
>     <[email-masked]>
>     <mailto:[email-masked]>; Andrew G. Malis
>         Regarding IPv4, I also understood that we decided that we
>         can’t add new IPv4 fields. Pardon my ignorance here, but does
>         that mean there is no part of DetNet capability that can be
>         run over IPv4? Or is there some “workaround” to provide as I
>         say even part of the DetNet capability, given that it is an
>         Engineered network? I just want to clarify expectations here.
>
>
>     If you have a native IPv4 network to which you present IPv6
>     packets, you either have to tunnel them across where the IPv6 is
>     considered opaque data, or you have to translate them to IPv4, but
>     that requires some common semantics to deal with extension headers
>     which we don't currently have.
>
>     Which takes us back to the question of how important is this and
>     what will it do to the take-up of the technology by its target
>     customers?
>
>     - Stewart
>
>
>
>         Thanks,
>
>         Ethan.
>
>         *Cc:* DetNet WG <[email-masked]> <mailto:[email-masked]>;
>         Mach Chen <[email-masked]> <mailto:[email-masked]>
>         That allow to identify DetNet flows in PSN layer without
>         checking the PW label. Such a solution of
>
>         <mailto:[email-masked]>>; DetNet WG
>         <[email-masked] <mailto:[email-masked]>>
>             Like with PWs (since DETNET for MPLS would just be another
>             PW type), targeted LDP and provisioning (via a central
>             You and Mach are both right that in the IP (non-MPLS)
>             case, we need a way for the NP to detect DETNET flows. We
>             could have a new IP protocol type for DETNET, and a DETNET
>             header directly follows the IP header. In that case, the
>             DETNET header would also need a next protocol identifier,
>             unless the next protocol is always another IP header.
>
>
>         Last I saw, the thinking was that there would be an IP
>         extension header, although I am not a fan of those since (a) I
>         am not confident what a router will do one it does not
>         understand, and (b) I am concerned about the need to support
>         IPv4 which I suspect will have a long tail in enterprise
>         deployment.
>
>         support through any middle box. firewall etc, and all routers
>         need to look a the UDP DP so checking if it is one they need
>         to work on is just one compare and conditional branch.
>
>
>
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 If we need to discriminate at the PSN layer rather
>                 than the DN layer then we really are forced to create
>                 a new FEC type for MPLS, or synthesize one through
>                 RSVP or SR. IP has no native support for this, but we
>                 could introduce the concept, for example by making
>                 this the property of the IP address or some way of
>                 MPLSing IP.
>
>                 However there is a deeper question we need to answer.
>                 Is our expectation that each hop in the data plane DN
>                 aware, or is our expectation that at lest in some
>                 networks the data plane is generic with some DN nodes
>                 strategically placed?
>
>                 deployment in most networks we need to design for the
>                 case where only strategic nodes are DN aware.
>
>                 - Stewart
>
>                     dedicated for DetNet, seems there is no
>                     compatibility issue.
>
>                     In addition, I think we need to define a way on
>                     how to differentiate a DetNet flow from a
>                     non-DetNet flow, then the network processor can
>                     process the CW as expected.  In TSN, it uses the
>                     priority to determine whether a flow is TSN or
>                     non-TSN flow. For DetNet, should we also use the
>                     same way (e.g., TC, DSCP)? Or the DetNet service
>                     Label itself implies the situation, but it seems
>                     that this only works when the DetNet service label
>                     is the top label.
>
>                     Any other thoughts?
>
>                     Best regards,
>
>                     Mach
>
>                     *From:* detnet [mailto:[email-masked]]
>                     *On Behalf Of *Balázs Varga A

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 17 Jan 2018 20:34:19 +0000

I don’t want to influence your discussion on solution(s).

As mails are getting crossed, and not having Tim’s original comment, I think as Ethan later says in a mail after this one – the IAB concern would be if doing an “IPv4-only” solution. Many working groups are still doing work supporting IPv4 networks. The discussion when it reaches the IESG – can IPv6 support be included in the same document or is there work on-going to support IPv6 (and the IPv6 solution does not depend on IPv4).

The charter for detnet is not to sunset IPv4😊 If you have operational use cases for supporting IPv4, then as you are doing, it is important to discuss the deployment requirements e.g. closed network, IPv4-IPv6 islands, etc., so as to understand the best solution.

My interpretation of the IAB statement is to give guidance on prioritizing work for IPv6. Unless you have large user groups requiring IPv4-only, then your priority should be in developing an IPv6 solution. And the IPv4 solution should not limit the IPv6 solution.

Deborah

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 2:02 PM
To: Grossman, Ethan A. <[email-masked]>; DetNet WG <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>
Cc: Tim Chown ([email-masked]) <[email-masked]>
Subject: Re: DP solution (Flow identification)

If the IETF does not maintain IPv4 appropriately until it's natural death, it will be declared critical national infrastructure by governments and they will effectively gift it to their SDO (the ITU-T). Such an organization may find it expedient to find many new ways to extend the life of IPv4. In any case I anticipate a very long tail on the IPv4 decay curve.

We need to do what is right for our customers, some of whom may find it infeasible to migrate away from IPv4 any time soon.

- Stewart

Perhaps, given Tim Chown’s earlier comment:
        “If you’re suggesting an IPv4-only solution, you’re running up against https://www.iab.org/2016/11/07/iab-statement-on-ipv6/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iab.org_2016_11_07_iab-2Dstatement-2Don-2Dipv6_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=oQquk5yvF5yLvj8_jVqVRcavQ7tUO_LtU3-EcEIDPFE&s=wVxexSKRCd7LZceNPkXpPMxA0OlNnL0Pihe4MlyqBoE&e=>.”

Hi  Ethan,

a) We support v4

- Stewart

Ethan.

- Stewart

Thanks,
Ethan.

Cheers
Bala’zs

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 17 Jan 2018 20:47:29 +0000

Thanks Deborah. FYI Tim's comment was exactly as I quoted it below, no more or less:

Ethan.

________________________________
From: BRUNGARD, DEBORAH A <[email-masked]>
Sent: Wednesday, January 17, 2018 12:34:19 PM
To: Stewart Bryant; Grossman, Ethan A.; DetNet WG
Cc: Tim Chown ([email-masked])
Subject: RE: DP solution (Flow identification)

Deborah

- Stewart

Ethan.

Hi  Ethan,

a) We support v4

- Stewart

Ethan.

Hi Bala’zs,

- Stewart

Thanks,

Ethan.

IP protocol type?

Cheers

Bala’zs

Andy

Stewart,

- Stewart

Cheers,

Andy

- Stewart

Hi Balazs,

Any other thoughts?

Best regards,

Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: Tim Chown <[email-masked]>
Date: Thu, 18 Jan 2018 11:30:53 +0000

Hi,

My understanding of the IAB statement was that new IPv4 work was no longer desirable. I think you will run into some potentially adverse IAB and/or IESG review comments if you put forward a new IPv4-only solution. So speaking to the relevant AD(s) now for advise is prudent. I believe maintaining existing, already-defined IPv4-only protocols is a different matter, as are transition tools which implicitly involve IPv4 (witness 464XLAT, softwires work, etc).  

I think Stewart's pragmatic comments would be weighed up within an IESG review, but if the solution supported both IPv4 and IPv6 operation one might imagine that would be considered rather more favourably.  It's the IPv4-only aspect that needs to be sounded out.  I can't think of any other IPv4-only new protocols published recently - are there examples?  

As an aside, in my dayjob with an NREN, one area of interest is end-to-end performance of data-intensive science transfers.  The Large Hadron Collider data transfers, over what's known as the World LHC Computing Grid, are now moving towards IPv6-only.  The storage nodes are moving to dual-stack by later this year, with a view to allowing large IPv6-only worker node clusters to stream data for computation, and a transition to IPv6-only storage nodes over time.  The WLCG no longer wishes to depend on IPv4. The biggest streams we see over the Janet NREN are currently ~30-40Gbit/s of IPv6 LHC data; as the LHC experiments evolve over the next 3-5 years those average and burst rates are only going to rise (*).  Other emerging (and very exciting) experiments like SKA (**) look like having even greater requirements.  This is all multi-domain though, so perhaps not in scope for DetNet, and while it's a very different application domain to many DetNet use cases, it's an indication of where leading academic research organisations and collaborations like CERN and WLCG are heading. 

Tim 

(*) LHC forward look - https://www.gridpp.ac.uk/wp-content/uploads/2017/10/179_20171004_NetworkForwardLook.pdf

(**) SKA - https://www.skatelescope.org/software-and-computing/

> On 17 Jan 2018, at 20:47, Grossman, Ethan A. <[email-masked]> wrote:
> 
>         “If you’re suggesting an IPv4-only solution, you’re running up againsthttps://www.iab.org/2016/11/07/iab-statement-on-ipv6/.”
>  
> To: Grossman, Ethan A. <[email-masked]>; Balázs Varga A<[email-masked]>; Andrew G. Malis <[email-masked]>
> To: Stewart Bryant <[email-masked]>; Andrew G. Malis<[email-masked]>

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 18 Jan 2018 19:41:41 +0000

Hi,

some comments regarding what is needed for a "networks that are under a single administrative control", based on the existing WG drafts (problem statement, use-cases, architecture, etc.). Let's try to keep it simple and focus on what we need:
1, Flow requirements:
                - loss and/or delay bounds
2, DetNet functions (defined so far):
                - DN1, Congestion protection (i.e. reserving resources, magic queuing, etc.)
                - DN2, Explicit routes (i.e. traffic engineering)
                - DN3, Service protection (against loss by network failures)
Note: These three techniques can be applied independently, depending on the Flow requirements and the network scenario. As an example, congestion protection (DN1) alone is offered by IEEE 802.1 Audio Video bridging.

3, Flow specific information have to travel with the packet:
                - Flow-ID (required by all DetNet functions)
                - Sequence Number (required only by "Service Protection" function)

So, regarding the questions here on the list:
- Do we need all nodes to be DN-aware in a network?
Not necessarily. If in a network scenario DetNet flows require only for example basic DN1 function than You have a good chance to serve it with existing devices. However in some cases all DN functions are needed at each hop, so yes, all nodes have to be DN aware.
Conclusion: the more DN functions are needed in a network scenario to serve DetNet flows, the more probably we need DN-aware nodes at each hop.

- Do we need DetNet data-plane for IPv4, IPv6 and MPLS?
Yes, that would be nice to have for all of them. But I think it is a better question which one has the smallest distance to be DetNet-ready? (I mean which need the less new stuff to support DN?) The data-plane alternative related draft focused on that and also the mailing threads here.
Conclusion: I think we can conclude on a rank of "smallest DetNet-distance":
1, MPLS
2, IPv6
3. IPv4
Note: in my view this is also the probability list what networks someone intends to use to forward DetNet flows …

Cheers
VBala'zs

Sent: 2018. január 17. 19:51

Hi  Ethan,

a) We support v4

- Stewart

Ethan.

- Stewart

Thanks,
Ethan.

Cheers
Bala’zs

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 Jan 2018 16:48:58 -0500

Balázs,

I agree with your conclusions regarding “DetNet distance”.

However, one point I think I disagree with you is when the sequence number
is necessary - you said only by the “service protection” function”.
However, as DetNet flows are indeed flows, and and most (if not all)
applications that will require DetNet will most probably require in-order
delivery, sequence numbers are generally useful for reordering at the
destination if packets get out of order during delivery by the underlying
network.

Cheers,
Andy

On Thu, Jan 18, 2018 at 2:41 PM, Balázs Varga A <[email-masked]
> wrote:

> Hi,
>
>
>
> some comments regarding what is needed for a "networks that are under a
> single administrative control", based on the existing WG drafts (problem
> statement, use-cases, architecture, etc.). Let's try to keep it simple and
> focus on what we need:
>
> 1, Flow requirements:
>
> Note: These three techniques can be applied independently, depending on
> the Flow requirements and the network scenario. As an example, congestion
> protection (DN1) alone is offered by IEEE 802.1 Audio Video bridging.
>
>
>
> Not necessarily. If in a network scenario DetNet flows require only for
> example basic DN1 function than You have a good chance to serve it with
> existing devices. However in some cases all DN functions are needed at each
> hop, so yes, all nodes have to be DN aware.
>
> Conclusion: the more DN functions are needed in a network scenario to
> serve DetNet flows, the more probably we need DN-aware nodes at each hop.
>
>
>
> Yes, that would be nice to have for all of them. But I think it is a
> better question which one has the smallest distance to be DetNet-ready? (I
> mean which need the less new stuff to support DN?) The data-plane
> alternative related draft focused on that and also the mailing threads
> here.
>
> *From:* detnet [mailto:[email-masked]] *On Behalf Of *Grossman,
> Ethan A.
> *Sent:* 2018. január 17. 19:51
> *To:* DetNet WG <[email-masked]>; Deborah Brungard <[email-masked]>;
> Stewart Bryant <[email-masked]>
> *Cc:* Tim Chown ([email-masked]) <[email-masked]>
> *Subject:* Re: [Detnet] DP solution (Flow identification)
>
>
>
> *From:* Stewart Bryant [mailto:[email-masked]
> <[email-masked]>]
> *To:* Grossman, Ethan A. <[email-masked]>; Balázs Varga A <
> [email-masked]>; Andrew G. Malis <[email-masked]>
> decision not to support IPv4” to mean “a decision not to propose adding
> anything to the existing IPv4 standard”.
>
>
> To support IPv4 there are a number of methods that are possible, one is to
> add something to v4 itself as is proposed for v6. Adding something to the
> base protocol will be very difficult.
>
> Another method, is to do what has been proposed by some for MPLS, that is
> to encode the identity and type in the IP address. There is a proposal to
> do this in SRv6. I am not a great fan of abusing the address space for this
> in the way proposed by that work, but maybe we can do something much
> simpler here and simply identify the DN instance by the IP address with no
> other semantics. Much easier to do this for IPv6 with the "infinite
> addresses" but we could get away with it in limited private Ipv4 networks.
> Of course this does change the per-hop behaviour of IP which may be a
> challenge to get the IETF to sign of on.
>
> done that and I still believe that to be the case, but that does not mean
> that it is not the least worst approach. There are alternates for example
> IP/UDP/MPLS
> options, though not a “native IPv4” solution, but it wasn’t clear to me (as
> a non-expert in the various networking protocols mentioned) whether they
> would be viable in practice or not. I will revive that thread and see if we
> can get any closer to determining the importance of IPv4 to our target
> customers, and hopefully some sense of whether the proposed non-native-IPv4
> strategies will hold water.
>
>
> *From:* Stewart Bryant [mailto:[email-masked]
> <[email-masked]>]
> *To:* Grossman, Ethan A. <[email-masked]> <[email-masked]>; Balázs
> Varga A <[email-masked]> <[email-masked]>;
> Andrew G. Malis <[email-masked]> <[email-masked]>
> *Cc:* DetNet WG <[email-masked]> <[email-masked]>; Mach Chen
> <[email-masked]> <[email-masked]>
> Regarding IPv4, I also understood that we decided that we can’t add new
> IPv4 fields. Pardon my ignorance here, but does that mean there is no part
> of DetNet capability that can be run over IPv4? Or is there some
> “workaround” to provide as I say even part of the DetNet capability, given
> that it is an Engineered network? I just want to clarify expectations here.
>
>
> either have to tunnel them across where the IPv6 is considered opaque data,
> or you have to translate them to IPv4, but that requires some common
> semantics to deal with extension headers which we don't currently have.
>
> Which takes us back to the question of how important is this and what will
> it do to the take-up of the technology by its target customers?
>
> - Stewart
>
>
> Thanks,
>
> Ethan.
>
>
>
> *From:* detnet [mailto:[email-masked] <[email-masked]>] *On
> *To:* Stewart Bryant <[email-masked]> <[email-masked]>;
> Andrew G. Malis <[email-masked]> <[email-masked]>
> *Cc:* DetNet WG <[email-masked]> <[email-masked]>; Mach Chen
> <[email-masked]> <[email-masked]>
> *From:* Stewart Bryant [mailto:[email-masked]
> <[email-masked]>]
> *Cc:* Mach Chen <[email-masked]>; Balázs Varga A <
> [email-masked]>; DetNet WG <[email-masked]>
> Like with PWs (since DETNET for MPLS would just be another PW type),
> targeted LDP and provisioning (via a central controller, NMS, etc.) are
> alternatives to RSVP and SR to provisioning/allocating the DETNET PW label.
>
>
> You and Mach are both right that in the IP (non-MPLS) case, we need a way
> for the NP to detect DETNET flows. We could have a new IP protocol type for
> DETNET, and a DETNET header directly follows the IP header. In that case,
> the DETNET header would also need a next protocol identifier, unless the
> next protocol is always another IP header.
>
>
> Last I saw, the thinking was that there would be an IP extension header,
> although I am not a fan of those since (a) I am not confident what a router
> will do one it does not understand, and (b) I am concerned about the need
> to support IPv4 which I suspect will have a long tail in enterprise
> deployment.
>
> through any middle box. firewall etc, and all routers need to look a the
> UDP DP so checking if it is one they need to work on is just one compare
> and conditional branch.
>
>
>
>
> If we need to discriminate at the PSN layer rather than the DN layer then
> we really are forced to create a new FEC type for MPLS, or synthesize one
> through RSVP or SR. IP has no native support for this, but we could
> introduce the concept, for example by making this the property of the IP
> However there is a deeper question we need to answer. Is our expectation
> that each hop in the data plane DN aware, or is our expectation that at
> lest in some networks the data plane is generic with some DN nodes
> strategically placed?
>
> I can see than in some greenfield specialist cases the routers will all be
> DN aware, but in order to get deployment in most networks we need to design
> for the case where only strategic nodes are DN aware.
>
> - Stewart
>
>
>
> In addition, I think we need to define a way on how to differentiate a
> DetNet flow from a non-DetNet flow, then the network processor can process
> the CW as expected.  In TSN, it uses the priority to determine whether a
> flow is TSN or non-TSN flow. For DetNet, should we also use the same way
> (e.g., TC, DSCP)? Or the DetNet service Label itself implies the situation,
> but it seems that this only works when the DetNet service label is the top
> label.
>
>
>
> Any other thoughts?
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* detnet [mailto:[email-masked] <[email-masked]>] *On
> *To:* DetNet WG <[email-masked]> <[email-masked]>
> From: detnet [mailto:[email-masked] <[email-masked]>]
> On Behalf Of Lou Berger
> https://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=Ww506GT5I1lpl0z4wh0NtK-sdaqjAfwQf7dIWKBfMjs&s=hS9_HI114vlyT-MDJVp5eK8h7URobpcWbBt9njrFQMI&e=>
>
>
>
>

---

From: Balázs Varga A <[email-masked]>
Date: Fri, 19 Jan 2018 09:09:36 +0000

Hi Andy,

Yes, good point. From DN flow perspective we have to cope with in-order delivery. However,
some detailed thoughts on the DN functions and their usage of S/N:
- DN1, Congestion protection it is practically about QoS functions, which works on a per flow
level. It selects queues based on flow-ID. It does not consider S/N.
- DN2, Explicit routes is practically traffic engineering. It does not care about S/N, just flow-ID
(which flow have to take which tunnel).
- DN3, Service protection is the per packet 1+n protection, where the elimination function is
based on S/N.

This is why I wrote S/N is used only by the Service Protection function.

But Your comment is fully valid and points for me to a possible missing DN function. We should
consider to define an additional one: “DN4 Frame ordering”. Such a function would use both the
flow-ID and the S/N. Its function is to ensure in order delivery if that is required by the DetNet
application. Best located at the egress-PE. Details need further discussion. (Note: if the application
has its own embedded seq.num in the flow it may not need in-order delivery, etc.)

I think that is a good idea and makes the DN functions more modular. Also during the Elimination
we can simple concentrate on duplicate detection and out-source in-order delivery to DN4.

So, we could end up in four DN functions:
- DN1, Congestion protection
- DN2, Explicit routes
- DN3, Service protection
- DN4, Frame ordering

Cheers
Bala’zs

From: Andrew G. Malis [mailto:[email-masked]]
Sent: 2018. január 18. 22:49
To: Balázs Varga A <[email-masked]>
Cc: DetNet WG <[email-masked]>
Subject: Re: [Detnet] DP solution (Flow identification)

Balázs,

However, one point I think I disagree with you is when the sequence number is necessary - you said only by the “service protection” function”. However, as DetNet flows are indeed flows, and and most (if not all) applications that will require DetNet will most probably require in-order delivery, sequence numbers are generally useful for reordering at the destination if packets get out of order during delivery by the underlying network.

Cheers,
Andy

On Thu, Jan 18, 2018 at 2:41 PM, Balázs Varga A <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers
VBala'zs

From: detnet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Grossman, Ethan A.
Sent: 2018. január 17. 19:51
To: DetNet WG <[email-masked]<mailto:[email-masked]>>; Deborah Brungard <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: Tim Chown ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] DP solution (Flow identification)

Hi  Ethan,

a) We support v4

- Stewart
Ethan.

- Stewart

Thanks,
Ethan.

Cheers
Bala’zs

Andy

- Stewart

Cheers,
Andy

- Stewart

Any other thoughts?

Best regards,
Mach

Hi,

      0                   1                   2                   3

Bit5-15: reserved.

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2018. január 10. 19:01
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] recording for today's interim

Lou (and co-chairs)

detnet mailing list

detnet mailing list

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 19 Jan 2018 07:33:35 -0500

Balázs,

Yes, I agree with this analysis.

Cheers,
Andy

On Fri, Jan 19, 2018 at 4:09 AM, Balázs Varga A <[email-masked]

> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* 2018. január 18. 22:49
> *To:* Balázs Varga A <[email-masked]>
> *Cc:* DetNet WG <[email-masked]>
> On Thu, Jan 18, 2018 at 2:41 PM, Balázs Varga A <
> [email-masked]> wrote:
>
> Hi,
>
>
>

---

From: <[email-masked]>
Date: Sat, 20 Jan 2018 10:10:24 +0800 (CST)

Hi Balázs,

I agree with your clarification on S/N and DN frame ordering function suggestion.

from service protection point of view, S/N is also heavily involved in replication which might happen in multiple intermidiary nodes,  in addition to duplicate dection in elimination and re-ordering delivery on the egress.

cheers,

Daniel

黄光平 huangguangping

预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product Operation Division

南京市雨花区软件大道50号中兴通讯1号楼 
R&D Building, ZTE
Corporation Software Road No.50, 
Yuhua District, Nanjing, P..R.China, 210012 
M: +86 13770311052 
E: [email-masked] 
www.zte.com.cn

原始邮件

发件人： <[email-masked]>;
收件人： <[email-masked]>;
抄送人： <[email-masked]>;
日 期 ：2018年01月19日 20:34
主 题 ：Re: [Detnet] DP solution (Flow identification)

Balázs,

Cheers,
Andy

On Fri, Jan 19, 2018 at 4:09 AM, Balázs Varga A <[email-masked]> wrote:

Hi Andy,

 

 

 

 

- DN2, Explicit routes

- DN4, Frame ordering

Cheers

Bala’zs

 

Balázs,

 

 

Cheers,

Andy

 

On Thu, Jan 18, 2018 at 2:41 PM, Balázs Varga A <[email-masked]> wrote:

Hi,

1, Flow requirements:

 

 

 

1, MPLS

2, IPv6

3. IPv4

 

Cheers

VBala'zs

 

 

Ethan.

 

Hi  Ethan,

 

 
 a) We support v4
 
 - Stewart

Ethan.

 

Hi Bala’zs,

 

 - Stewart

Thanks,

Ethan.

 

 

 

IP protocol type?

 

 

Cheers

Bala’zs

 

Andy

Stewart,

 ... and I suppose strictly BGP which is also used for this purpose in VPNs

 

 
 - Stewart

Cheers,

Andy

 

- Stewart

Hi Balazs,

 

 

Any other thoughts?

Best regards,

Mach

 

Hi,

 

 

      0                   1                   2                   3

Bit5-15: reserved.

 

 

#3: Other … ?!?

Comments are welcome.

Cheers

Bala'zs

-----Original Message-----
 From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
 Sent: 2018. január 10. 19:01
 To: DetNet WG <[email-masked]>
 Subject: [Detnet] recording for today's interim

 

 

 

Lou (and co-chairs)

detnet mailing list

[email-masked]

 

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

---

From: Jouni <[email-masked]>
Date: Sun, 21 Jan 2018 22:29:04 +0200

Hi,

These are fine (good explanation below btw) and all listed/analysed already in the architecture document to some extent, except that there is no specific naming convention for a DetNet flow with reordering. 

I wonder if we really need to state which DetNet node with a DetNet service layer functionality does the reordering? Wouldn’t that be just something a control plane or configuration defines?

- Jouni

> On 19 Jan 2018, at 11:09, Balázs Varga A <[email-masked]> wrote:
> 
> Hi Andy,
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Jan 2018 10:30:21 +0000

Andy,

That is of course highly application specific.

In order delivery is an invariant of Ethernet, but not something that 
the deployed Ethernet PWs assure.

I wonder if we require to do this in the PW - we could do it in an 
application specific shim - or we could create two PWs, one with S/N and 
one without.

So to go back to the "DN Distance". Whilst we need a "future proof" 
design, we need to be careful not to put anything in that current 
equipment designs would find hard unless that is critical to the first 
priority use cases.

- Stewart

On 18/01/2018 21:48, Andrew G. Malis wrote:
> However, one point I think I disagree with you is when the sequence 
> number is necessary - you said only by the “service protection” 
> function”. However, as DetNet flows are indeed flows, and and most (if 
> not all) applications that will require DetNet will most probably 
> require in-order delivery, sequence numbers are generally useful for 
> reordering at the destination if packets get out of order during 
> delivery by the underlying network.
>
> Cheers,
> Andy
>
>
> On Thu, Jan 18, 2018 at 2:41 PM, Balázs Varga A 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     some comments regarding what is needed for a "networks that are
>     under a single administrative control", based on the existing WG
>     drafts (problem statement, use-cases, architecture, etc.). Let's
>     try to keep it simple and focus on what we need:
>
>     1, Flow requirements:
>
>     Note: These three techniques can be applied independently,
>     depending on the Flow requirements and the network scenario. As an
>     example, congestion protection (DN1) alone is offered by IEEE
>     802.1 Audio Video bridging.
>
>     Not necessarily. If in a network scenario DetNet flows require
>     only for example basic DN1 function than You have a good chance to
>     serve it with existing devices. However in some cases all DN
>     functions are needed at each hop, so yes, all nodes have to be DN
>     aware.
>
>     Conclusion: the more DN functions are needed in a network scenario
>     to serve DetNet flows, the more probably we need DN-aware nodes at
>     each hop.
>
>     Yes, that would be nice to have for all of them. But I think it is
>     a better question which one has the smallest distance to be
>     DetNet-ready? (I mean which need the less new stuff to support
>     DN?) The data-plane alternative related draft focused on that and
>     also the mailing threads here.
>
>     Note: in my view this is also the probability list what networks
>     someone intends to use to forward DetNet flows …
>
>     Cheers
>
>     VBala'zs
>
>     *From:*detnet [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Grossman, Ethan A.
>     *To:* DetNet WG <[email-masked] <mailto:[email-masked]>>;
>     Deborah Brungard <[email-masked] <mailto:[email-masked]>>; Stewart
>     Bryant <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Tim Chown ([email-masked]
>     <mailto:[email-masked]>) <[email-masked]
>     <mailto:[email-masked]>>
>     against https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
>     <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.”
>
>     *From:*Stewart Bryant [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Grossman, Ethan A. <[email-masked]
>     <mailto:[email-masked]>>; Balázs Varga A
>     <mailto:[email-masked]>>; Andrew G. Malis
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* DetNet WG <[email-masked] <mailto:[email-masked]>>; Mach
>     Chen <[email-masked] <mailto:[email-masked]>>
>         Thanks Stewart for the clarification. I interpret your
>         statement “a decision not to support IPv4” to mean “a decision
>         not to propose adding anything to the existing IPv4 standard”.
>
>
>     To support IPv4 there are a number of methods that are possible,
>     one is to add something to v4 itself as is proposed for v6. Adding
>     Another method, is to do what has been proposed by some for MPLS,
>     that is to encode the identity and type in the IP address. There
>     is a proposal to do this in SRv6. I am not a great fan of abusing
>     the address space for this in the way proposed by that work, but
>     maybe we can do something much simpler here and simply identify
>     the DN instance by the IP address with no other semantics. Much
>     easier to do this for IPv6 with the "infinite addresses" but we
>     could get away with it in limited private Ipv4 networks. Of course
>     this does change the per-hop behaviour of IP which may be a
>     Another method is to use some method of carrying an MPLS label
>     stack - this was the first proposal. Now I said that I did not
>     think anyone had done that and I still believe that to be the
>     case, but that does not mean that it is not the least worst
>     approach. There are alternates for example IP/UDP/MPLS
>         already started a thread awhile ago to discuss IPv4 vs IPv6,
>         and based on the responses it appeared to me at that time that
>         there were some kind of options, though not a “native IPv4”
>         solution, but it wasn’t clear to me (as a non-expert in the
>         various networking protocols mentioned) whether they would be
>         viable in practice or not. I will revive that thread and see
>         if we can get any closer to determining the importance of IPv4
>         to our target customers, and hopefully some sense of whether
>         *From:*Stewart Bryant [mailto:[email-masked]
>         <mailto:[email-masked]>]
>             can’t add new IPv4 fields. Pardon my ignorance here, but
>             does that mean there is no part of DetNet capability that
>             can be run over IPv4? Or is there some “workaround” to
>             provide as I say even part of the DetNet capability, given
>         packets, you either have to tunnel them across where the IPv6
>         is considered opaque data, or you have to translate them to
>         IPv4, but that requires some common semantics to deal with
>         extension headers which we don't currently have.
>
>         Which takes us back to the question of how important is this
>         and what will it do to the take-up of the technology by its
>         target customers?
>
>         - Stewart
>
>
>             Thanks,
>
>             Ethan.
>
>             *From:*detnet [mailto:[email-masked]
>             <mailto:[email-masked]>] *On Behalf Of *Balázs
>             Varga A
>             <mailto:[email-masked]>; Mach Chen <[email-masked]>
>             <mailto:[email-masked]>
>             - IPv6: based on the src-IPv6 and the flow-label NP can
>             detect DetNet flows. Why would we need a new
>
>             IP protocol type?
>
>             *From:*Stewart Bryant [mailto:[email-masked]
>             <mailto:[email-masked]>]
>                 Like with PWs (since DETNET for MPLS would just be
>                 another PW type), targeted LDP and provisioning (via a
>                 central controller, NMS, etc.) are alternatives to
>                 RSVP and SR to provisioning/allocating the DETNET PW
>                 label.
>
>
>                 case, we need a way for the NP to detect DETNET flows.
>                 We could have a new IP protocol type for DETNET, and a
>                 DETNET header directly follows the IP header. In that
>                 case, the DETNET header would also need a next
>                 protocol identifier, unless the next protocol is
>                 always another IP header.
>
>
>             extension header, although I am not a fan of those since
>             (a) I am not confident what a router will do one it does
>             not understand, and (b) I am concerned about the need to
>             support IPv4 which I suspect will have a long tail in
>             enterprise deployment.
>
>             I prefer a UDP type for this purpose since it has
>             universal support through any middle box. firewall etc,
>             and all routers need to look a the UDP DP so checking if
>             it is one they need to work on is just one compare and
>             conditional branch.
>
>
>                     than the DN layer then we really are forced to
>                     create a new FEC type for MPLS, or synthesize one
>                     through RSVP or SR. IP has no native support for
>                     this, but we could introduce the concept, for
>                     example by making this the property of the IP
>                     However there is a deeper question we need to
>                     answer. Is our expectation that each hop in the
>                     data plane DN aware, or is our expectation that at
>                     lest in some networks the data plane is generic
>                     with some DN nodes strategically placed?
>
>                     I can see than in some greenfield specialist cases
>                     the routers will all be DN aware, but in order to
>                     get deployment in most networks we need to design
>                         In addition, I think we need to define a way
>                         on how to differentiate a DetNet flow from a
>                         non-DetNet flow, then the network processor
>                         can process the CW as expected.  In TSN, it
>                         uses the priority to determine whether a flow
>                         is TSN or non-TSN flow. For DetNet, should we
>                         also use the same way (e.g., TC, DSCP)? Or the
>                         DetNet service Label itself implies the
>                         situation, but it seems that this only works
>                         when the DetNet service label is the top label.
>
>                         Any other thoughts?
>
>                         Best regards,
>
>                         Mach
>
>                         *From:* detnet [mailto:[email-masked]
>                         <mailto:[email-masked]>] *On Behalf
>                         Of *Balázs Varga A
>                         From: detnet [mailto:[email-masked]
>                         <mailto:[email-masked]>] On Behalf Of
>                         Lou Berger
>     <https://www.ietf.org/mailman/listinfo/detnet>
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Jan 2018 10:42:03 +0000

On 19/01/2018 09:09, Balázs Varga A wrote:
>
> Also during the Elimination
>

In the middle of the network it may be sufficient to do approximate 
duplication detection. That is to say delete a packet if it has the same 
s/n as its predecessor (may be with a very tiny window) and let the 
egress do anything more complex.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Mon, 22 Jan 2018 21:12:11 +0800

Stewart,

> egress do anything more complex.

This has been tried before, but if I remember correctly. there turned
out to be very few true P nodes.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 22 Jan 2018 14:22:58 +0000

Exactly. :--))) Cheers Bala’zs

From: Stewart Bryant [mailto:[email-masked]]
Sent: 2018. január 22. 11:42
To: Balázs Varga A <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: DetNet WG <[email-masked]>
Subject: Re: [Detnet] DP solution (Flow identification)

In the middle of the network it may be sufficient to do approximate duplication detection. That is to say delete a packet if it has the same s/n as its predecessor (may be with a very tiny window) and let the egress do anything more complex.

- Stewart

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 22 Jan 2018 14:25:02 +0000

Hi Loa,
I think this case is rather different. The "Packet Ordering" function 
is rather specific and You need the right order only at the egress.
Cheers
Bala'zs

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: 2018. január 22. 14:12
To: Stewart Bryant <[email-masked]>; Balázs Varga A <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: DetNet WG <[email-masked]>
Subject: Re: [Detnet] DP solution (Flow identification)

Stewart,

On 2018-01-22 18:42, Stewart Bryant wrote:
> duplication detection. That is to say delete a packet if it has the 
> same s/n as its predecessor (may be with a very tiny window) and let 
> the egress do anything more complex.

This has been tried before, but if I remember correctly. there turned out to be very few true P nodes.

/Loa

--

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Jan 2018 10:00:47 -0500

I wanted to follow up on the IPv4 point from this message:

In the past we have discussed that IPv4 would be supported as a special 
case of IEEE 802.1TSN over DetNet, i.e., end stations would map IPv4 
(presumably, 5 tuple)  flows to TSN flows and then TSN domains would be 
interconnected over DetNet.  Of course this means that IPv4 DetNet 
support would be limited to  TSN domains interconnected via basically 
bridging.  Note that this case requires no special IPv4 awareness or 
IPv4 processing in the DetNet domain.

An alternative to this would be that the DetNet edge node map individual 
IPv4 (again, presumably, 5 tuple)  flows, which still arrive via a TSN 
subnet,  to DetNet flows and transport (e.g., over MPLS).  In this case, 
the IPv4 flows could be forwarded and the scope would not be limited to 
bridged/interconnected TSN domains.  This would of course required 
additional DetNet definition and support.

It would be good to here from  WG participants would like to see this 
additional case explicitly covered by the WG.

Options are:

1) keep as is: IPv4 supported as a byproduct of TSN interconnect

2) add routed DetNet support for IPv4 flows (carried over DetNet transport)

Lou

On 1/18/2018 2:41 PM, Balázs Varga A wrote:
...
> better question which one has the smallest distance to be 
> DetNet-ready? (I mean which need the less new stuff to support DN?) 
> The data-plane alternative related draft focused on that and also the 
> mailing threads here.
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Jan 2018 15:31:16 +0000

If we go with 1, I think we will end up back here sometime also solving 2.

A lot depends on how tied to TSN some of the applications are.

- Stewart

On 22/01/2018 15:00, Lou Berger wrote:
> In the past we have discussed that IPv4 would be supported as a 
> special case of IEEE 802.1TSN over DetNet, i.e., end stations would 
> map IPv4 (presumably, 5 tuple)  flows to TSN flows and then TSN 
> domains would be interconnected over DetNet.  Of course this means 
> that IPv4 DetNet support would be limited to  TSN domains 
> interconnected via basically bridging.  Note that this case requires 
> no special IPv4 awareness or IPv4 processing in the DetNet domain.
>
> An alternative to this would be that the DetNet edge node map 
> individual IPv4 (again, presumably, 5 tuple)  flows, which still 
> arrive via a TSN subnet,  to DetNet flows and transport (e.g., over 
> MPLS).  In this case, the IPv4 flows could be forwarded and the scope 
> would not be limited to bridged/interconnected TSN domains.  This 
> would of course required additional DetNet definition and support.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Jan 2018 16:41:02 +0000

Hello Stewart :

If we do this, the behavior of the eliminator becomes unpredictable for flows that approach and may pass the boundary of the tiny window. If the ingress bandwidth at the node located downstream of the eliminator is strictly controlled, the overall output will not be what we’d like it to be.

-          Say flow 2 is delayed by more than the tiny window, then the 2 copies will pass. It may be that the ingress filtering of the next node drops every other packet without a understanding the sequence, only based on excess rate. Which may discard both copies of some packets and let both copies of another through.

-          One might say, then let the double bandwidth after the eliminator. But then no point eliminating.

-          Another may say, drop every packet received outside the tight window at the eliminator. But then the whole of flow 2 will be discarded, and if one packet of flow 1 is lost, now both copies are, which means that we lost all the value of PRE.

This boils down to the fact that a getting packets outside the “tiny” window means a grave malfunction.

Which tells us that the tiny time difference has to be above the sum of the worst case jitter of the 2 parallel flows, plus the delta(Time) of the 2 flows arriving at the eliminator with 0 jitter.  How tiny can that be?

Pascal

From: detnet [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: lundi 22 janvier 2018 11:42
To: Balázs Varga A <[email-masked]>; Andrew G. Malis <[email-masked]>
Cc: DetNet WG <[email-masked]>
Subject: Re: [Detnet] DP solution (Flow identification)

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 23 Jan 2018 18:57:12 +0800

Balazs,

Yes I understand your point, what I tried to sat (a bit glibly) is that 
find true P-nodes is not that easy. Most nodes have some edge
functionality anyway.

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Jan 2018 11:26:16 +0000

Loa,

That used to be the case, but I am not so sure that it is still the 
case, mainly due to the cost of the linecards.

If a node does have mixed functions egress is normally on a specialist 
line card, and so long at the duplicate deletion happens on the egress 
of that line card we have a single point of perfection where can 
de-duplicate.

- Stewart

On 23/01/2018 10:57, Loa Andersson wrote:
> Balazs,
>
> Yes I understand your point, what I tried to sat (a bit glibly) is 
> that find true P-nodes is not that easy. Most nodes have some edge
> functionality anyway.
>
> /Loa
>
>> To: Stewart Bryant <[email-masked]>; Balázs Varga A

---

From: Loa Andersson <[email-masked]>
Date: Wed, 24 Jan 2018 08:52:42 +0800

Stewart,

Thanks, I'm aware of that trend, the only question is how much of "the
old" situation actually remains in the deployed networks?

/Loa

--