Subject: Re: [Detnet] DP solution (Flow identification)

From: Jeff Tantsura <[email-masked]>
Date: Wed, 17 Jan 2018 14:12:34 -0800

Speaking on behalf of IAB – building a IPv4 only solution would be a rather unfortunate direction and very much against IAB statement ( https://www.iab.org/2016/11/07/iab-statement-on-ipv6/).

Cheers,

Jeff

From: detnet <[email-masked]> on behalf of "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wednesday, January 17, 2018 at 12:34
To: Stewart Bryant <[email-masked]>, "Grossman, Ethan A." <[email-masked]>, DetNet WG <[email-masked]>
Cc: "Tim Chown ([email-masked])" <[email-masked]>
Subject: Re: [Detnet] DP solution (Flow identification)

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)

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:

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.

From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, January 17, 2018 10:39 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)

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

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)

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)

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]> 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]>
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]>
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]

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

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

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

 

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

---

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

Thanks Jeff, fortunately no-one here is proposing that.
Ethan.

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

Speaking on behalf of IAB – building a IPv4 only solution would be a rather unfortunate direction and very much against IAB statement ( 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=>).

Cheers,
Jeff

From: detnet <[email-masked]<mailto:[email-masked]>> on behalf of "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 17, 2018 at 12:34
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>, "Grossman, Ethan A." <[email-masked]<mailto:[email-masked]>>, DetNet WG <[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)

Deborah

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

- 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=>.”

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.

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 12:29 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)

- 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

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

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

- Stewart

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,

      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

[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=>

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=>

_______________________________________________
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=>

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jan 2018 12:12:13 +0000

Jeff

There is an important difference between only building an IPv4 solution 
and building an IPv4 only solution.

We should design what is right for the customer in the network context 
they need it to work. If we do not do that we will loose the design 
authority for the protocols.

- Stewart

On 17/01/2018 22:12, Jeff Tantsura wrote:
>
> Speaking on behalf of IAB – building a IPv4 only solution would be a 
> rather unfortunate direction and very much against IAB statement ( 
> 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=>).
>
> Cheers,
>
> Jeff
>
> *From: *detnet <[email-masked]> on behalf of "BRUNGARD, 
> DEBORAH A" <[email-masked]>
> *Date: *Wednesday, January 17, 2018 at 12:34
> *To: *Stewart Bryant <[email-masked]>, "Grossman, Ethan A." 
> <[email-masked]>, DetNet WG <[email-masked]>
> *Cc: *"Tim Chown ([email-masked])" <[email-masked]>
> *Subject: *Re: [Detnet] DP solution (Flow identification)
>
> 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.
>
>     “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=>.”
>
>     *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,
>
>         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
>         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.
>
>
>         *From:*Stewart Bryant [mailto:[email-masked]]
>         *Sent:* Wednesday, January 17, 2018 12:29 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)
>
>             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.
>
>             *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)
>
>             That allow to identify DetNet flows in PSN layer without
>             checking the PW label. Such a solution of
>
>             - IPv4: If I remember correctly it was discussed to be
>             out-of-scope to simplify the scenarios we focus on.
>
>             - 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]]
>             *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
>
>                 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,
>
>                         <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=>
>
>                         [email-masked] <mailto:[email-masked]>
>
>                         <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=>
>
>                         [email-masked] <mailto:[email-masked]>
>
>                         <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=>
>
>
>                     [email-masked] <mailto:[email-masked]>
>                     <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] https://www.ietf.org/mailman/listinfo/detnet
>