Subject: [Detnet] DetNet and IPv4

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 16 Nov 2017 22:38:04 +0000

Hi All,
I heard in conversations yesterday a few things which I am concerned about (from a use case point of view) regarding DetNet and MPLS, IPv6 and IPv4. Probably these things are well known to network professionals, but are news to me, or maybe I misunderstood. So if anyone wants to correct or comment on any of these impressions please do. And of course there is a question to be answered...
1)      Although MPLS (and variants) are often available in today's routers, apparently the skillset of configuring a network of MPLS routers is far less common than for IPv4. Presumably IPv6 falls somewhere in between on this scale. So the notion of our target audience (i.e. the implementers of our use cases) setting up an MPLS network for a factory or a building or a mine or a smart grid or an audio/video facility seems like it isn't going to be an easy sell. Presumably one reason for this is the complexity of configuring the network. Mitigating that somewhat is the notion that since we are not going for interop with existing implementations, perhaps we could "cut to the chase" and define some configuration process or interface that would be simpler than the existing ones?
2)      Perhaps IPv6 might be easier in that regard, however it was pointed out that most industrial controllers (for example National Instruments, and probably existing equipment in most of our other use cases) don't support IPv6, and if they do, apparently they don't interoperate well with existing IPv4 plant. And the motivation in most of our areas to adopt IPv6 hasn't been there, presumably because they don't need extra address space and don't perceive any value in exchange for the effort and pain involved.
3)      So the question was raised, why can't we have an IPv4 solution, i.e. without involving MPLS or IPv6? It could still use a central controller, what part of the puzzle is missing? Clearly we need some notion of Flow ID and Sequence number, and it doesn't seem feasible to add such things to IPv4. But is there some way we can work around that?
4)      As Norm pointed out in the session, we have been spending a lot of time on PREF, but what if we just went for the basics of no congestion and low latency - could we do it then? Is it worth considering that as an interim solution, figuring it will probably serve many use cases, and leave the ultra high reliability stuff as follow-on? I mean obviously PREF is important, but if leaving it out of a first cut simplifies things enough and served enough use cases in the nearer term, maybe worth some backtracking to get to the full solution later?
5)      Or how about IPv4 as an alternate solution, since we have discussed separate implementations for MPLS and IPv6? Maybe IPv4, with "whatever performance/features we can get out of it" would serve some purpose, particularly in the near term?
Anyway I'm just saying that I hadn't realized before that this could be as much of an impediment to adoption as it is sounding to me now like it is, which to me seems like a "use case issue" so I'm bringing it up. I mean it would be less than ideal to develop a whole solution which is too unwieldy for our customers to adopt.
Ethan.

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Nov 2017 22:53:01 +0000

Hi,

> On 16 Nov 2017, at 22:38, Grossman, Ethan A. <[email-masked]> wrote:
> 
> Hi All,
> I heard in conversations yesterday a few things which I am concerned about (from a use case point of view) regarding DetNet and MPLS, IPv6 and IPv4. Probably these things are well known to network professionals, but are news to me, or maybe I misunderstood. So if anyone wants to correct or comment on any of these impressions please do. And of course there is a question to be answered…
> 	• Although MPLS (and variants) are often available in today’s routers, apparently the skillset of configuring a network of MPLS routers is far less common than for IPv4. Presumably IPv6 falls somewhere in between on this scale. So the notion of our target audience (i.e. the implementers of our use cases) setting up an MPLS network for a factory or a building or a mine or a smart grid or an audio/video facility seems like it isn’t going to be an easy sell. Presumably one reason for this is the complexity of configuring the network. Mitigating that somewhat is the notion that since we are not going for interop with existing implementations, perhaps we could “cut to the chase” and define some configuration process or interface that would be simpler than the existing ones?  
> 	• Perhaps IPv6 might be easier in that regard, however it was pointed out that most industrial controllers (for example National Instruments, and probably existing equipment in most of our other use cases) don’t support IPv6, and if they do, apparently they don’t interoperate well with existing IPv4 plant. And the motivation in most of our areas to adopt IPv6 hasn’t been there, presumably because they don’t need extra address space and don’t perceive any value in exchange for the effort and pain involved. 
> 	• So the question was raised, why can’t we have an IPv4 solution, i.e. without involving MPLS or IPv6? It could still use a central controller, what part of the puzzle is missing? Clearly we need some notion of Flow ID and Sequence number, and it doesn’t seem feasible to add such things to IPv4. But is there some way we can work around that?
> 	• As Norm pointed out in the session, we have been spending a lot of time on PREF, but what if we just went for the basics of no congestion and low latency – could we do it then? Is it worth considering that as an interim solution, figuring it will probably serve many use cases, and leave the ultra high reliability stuff as follow-on? I mean obviously PREF is important, but if leaving it out of a first cut simplifies things enough and served enough use cases in the nearer term, maybe worth some backtracking to get to the full solution later? 
> 	• Or how about IPv4 as an alternate solution, since we have discussed separate implementations for MPLS and IPv6? Maybe IPv4, with “whatever performance/features we can get out of it” would serve some purpose, particularly in the near term?  
> Anyway I’m just saying that I hadn’t realized before that this could be as much of an impediment to adoption as it is sounding to me now like it is, which to me seems like a “use case issue” so I’m bringing it up. I mean it would be less than ideal to develop a whole solution which is too unwieldy for our customers to adopt.
> Ethan.

If you’re suggesting an IPv4-only solution, you’re running up against https://www.iab.org/2016/11/07/iab-statement-on-ipv6/. 

And there’s interesting new IPv6-only video distribution models to which DetNet could be applied, like http://6cn.io/.

Tim

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Nov 2017 07:05:53 +0800

I personally have been assuming that IPv4 would be supported by
(a) TSN in non-MPLS networks, this includes over DetNet routers 
interconnected by TSN (or similar L2), and
(b) over DetNet/MPLS  -- probably using some form of island interconnect

WRT PREF: (a) implies PREF on a per TSN/L2 basis and (b) implies PREF 
only within the DetNet/MPLS domain.

Lou

On 11/17/2017 6:53 AM, Tim Chown wrote:
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: Le boudec Jean-Yves <[email-masked]>
Date: Fri, 17 Nov 2017 02:55:45 +0000

A small factual correction: National Instrument supports IPv6.  But it is true that all smart grid software I know of uses IPv4. Moving to IPv6 involves re-coding, with some potential difficulties on the network side (in IP multicast for example) and with no benefit since such networks use private IPv4 addresses. 

JY 

> Le 17 nov. 2017 à 07:26, Lou Berger <[email-masked]> a écrit :
> 
> (a) TSN in non-MPLS networks, this includes over DetNet routers interconnected by TSN (or similar L2), and
> WRT PREF: (a) implies PREF on a per TSN/L2 basis and (b) implies PREF only within the DetNet/MPLS domain.
> 
> Lou
>

---

From: Norman Finn <[email-masked]>
Date: Fri, 17 Nov 2017 03:56:06 +0000

A good topic to discuss.

Ignoring PREF for a moment:

If we have YANG models such that the a network controller can configure the IntServ and/or TSN queues, then we have a plan that will provide bounded latency for either IPv4 or IPv6, at least until a topology change requires that the reservations be re-built.  Well, except for we need some way to ask the controller for a reservation, but that can certainly be in a YANG model, too.

If we constrain the network to a series of rings, and employ any of the many ring control protocols, then that same controller can pre-make the reservations in all directions around the rings, so that ring failures/recoveries will have ready-made reservations to accommodate the quick fail-over.  A workable plan for many.

Ah, but PREF:

To Get PREF, you probably need a new capability from your bridge/router/chip vendor to do elimination.  You don't need this capability everywhere.  But, we're probably already talking about a hardware upgrade.  (Which you may have required for the TSN and/or IntServ queues, anyway.)

Given that upgrade, let's talk about packet formats.  I could be surprised, either way, on the issue of whether it would be easy or hard to get an MPLS data plane at the same time as the packet elimination upgrade.  We'll have to hear from bridge/router/chip vendors to learn that.

As Lou says, MPLS supports IPv4 just fine.  No problems, there.

Seems that the only thing we are arguably missing is a native IPv4 format.  There are some obvious "nice" candidates, and some obvious "layer-crossing abomination" candidates.  I suppose IETF, IEEE, ODVA, Industrie 4.0, or some vendor could pick one.  But, it's possible that any IPv4 native encaps would run into as many HW upgrade problems as the MPLS data plane solution.  I don't know.

That leaves the MPLS control plane / network administrator training issue.  If you're putting DetNet on some service provider network, there may be no issue here, at all!  Otherwise, I freely admit that I'm partial to central control solutions for DetNet/TSN.  All the YANG stuff is there to pin down a path through a bridge.  Rather than bring up a full MPLS control plane, and figure out how to teach the relevant boxes how to make the necessary requests, I'd want YANG models for constructing pinned paths, and use MPLS only for pinned DetNet paths, not for general use in my network.  Pinned MPLS paths would be understood by the administrators exactly like pinned bridged paths, just a slightly different format.

Interesting fact:  As far as configuring the packet replicators/eliminators for either TSN or DetNet, the information model in IEEE Std 802.1CB-2017 is just as applicable to routers, label switching routers, or firewalls as it is to bridges.  All that's missing is the YANG model to conform to the information model, and plug-ins for the encapsulation desired.  (Both of those projects are getting underway, already.)

-- Norm

________________________________________
From: detnet [[email-masked]] on behalf of Le boudec Jean-Yves [[email-masked]]
Sent: Thursday, November 16, 2017 6:55 PM
To: [email-masked]
Subject: Re: [Detnet] DetNet and IPv4

JY

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Nov 2017 08:49:03 +0000

The "official" way of running PW over IP is via L2TP(v3).

The other way is to do a variant of what the PW arch had, and DETNET 
initially considered, and that is to run PW over MPLS over UDP over IPv4/6.

You only need one label and that can be considered an opaque data type 
{32 bits of which 20 are the session ident and the rest are just fixed}.

This way you can use almost the same data structures for MPLS and IP. In 
a host it works over a socket, it passes through a firewall, and is IP 
version neutral.

- Stewart

---

From: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Fri, 17 Nov 2017 09:53:43 +0000

Don’t give the impression that utilities will stay forever on IPv4.

Recent utility’s RFPs are asking for IPv6. 

Also, some utilities with the game of mergers and acquisitions have now to connect IPv4 networks with private addresses to their common control centers. Their IT departments are under pressure.

Patrick

On 17/11/2017, 03:55, "detnet on behalf of Le boudec Jean-Yves" <[email-masked] on behalf of [email-masked]> wrote:

    JY