Subject: Re: [Detnet] The road to DetNet

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 22 Apr 2015 22:39:10 +0000

Let’s talk about what’s needed.

DetNet is:

 1. Time synchronization.
 2. Zero congestion loss.
 3. Seamless redundancy.  (Figure 1 in the architecture)
 4. Peer-to-peer protocols to set up any of the above.
 5. Central control paradigms to set up any of the above.
 6. Robust defenses against misbehaving end and relay systems.

That seems to be a lot of stuff, but when we divide it up into specific
work items a lot of things are already done or should be done elsewhere
than in a DetNet WG:

 A. Time synchronization is solved elsewhere.  DetNet need not invent
anything, here.

 B. IEEE 802 have defined more than enough queuing and scheduling
mechanisms to solve the problem of zero congestion loss for constant
bit-rate flows at the lowest levels of the stack.  DetNet need not invent
anything, here.

 C. There is definitely DetNet work required to either invent or select
(select is better) one or more specific data plane methods related to
Seamless Redundancy (see the architecture draft).  We need a method that
works end-to-end through routers and bridges to:

  1. Identify individual DetNet flows.

  2. Operate on a sequence number in a DetNet packet.

 D. We require service-level YANG models for:

  1. Pinned-down paths through the network.

  2. Resource reservations along:

     i) a pinned-down path; or

    ii) a normal, dynamic path through the network topology;

  3. Seamless redundancy replication and elimination points along a
pinned-down path.

  These service-level YANG models will likely be some combination of new
models and selection (perhaps with modification) of existing models.
Certainly, they must tie into any existing models that apply to our
choices for points C1 and C2.  I think that this is a DetNet WG problem.

 E. We require device-level YANG models to support the IEEE 802 queuing
and scheduling models.  This is an IEEE 802 job, not a DetNet job.

 F. We require device-level YANG models for flow identification.   IEEE
will have some stuff for L2-only flows, but we need models for the flows
in point C, above. And this is primarily a DetNet issue.  The DetNet
solution should subsume the IEEE solution as a special case.

 G. We require device-level YANG models for the replication and
elimination seamless redundancy functions.  IEEE may provide a basis for
this, but of course, it must be tied to the specific method(s) we select
for DetNet.

 H. Having defined the service- and device-level YANG models, it is not
clear that we need to do any more work on central controllers, e.g. mess
with the PCE.

 I. In my opinion, existing existing AVB users, as well as certain classes
of industrial and in-vehicle users, require a peer-to-peer protocol for
resource reservation.  At the very least, we need this protocol between
talkers or listeners and the nearest relay node (bridge or router).
Whether we do this in IEEE or DetNet is TBD, as far as I’m concerned.

 J. We need to consider the robust defense issues of point 6 when
designing the YANG models, to make sure that we have enough information
available.

So:

A, B, E, and H are problems that DetNet does not have to solve.

Point I may or may not be a problem for DetNet.  TBD.

C, D, F, G, and J are the major concerns of a DetNet WG.

IMO, the reasons that we need a WG are:

 — We need a credible L2/L3 architecture for the general problem space.

 — We need a forum to discuss the Seamless Redundancy problem, and decide
either to invent something new or reuse existing mechanisms.

 — We need a forum to coordinate and connect together all of the
device-level and service-level YANG models from both IETF and IEEE.

What do others think?

— Norm

-----Original Message-----
From: Pascal Thubert <[email-masked]>
Date: Thursday, April 9, 2015 at 10:57 AM
To: "[email-masked]" <[email-masked]>, "Deborah Brungard
([email-masked]) ([email-masked])" <[email-masked]>, Erik
Nordmark <[email-masked]>, Lou Berger <[email-masked]>
Cc: Tom Phinney <[email-masked]>, "[email-masked]"
<[email-masked]>, "Alia Atlas ([email-masked])"
<[email-masked]>
Subject: [Detnet] The road to DetNet

>Dear all:
>
>As Jouni pointed out, we have little time to make a compelling case for
>DetNet. The cutoff forreuesting the BoF is June 5th, but a last minute
>burst of activity is no great sign for the IESG.
>
>What we have in good state (see my post about the charter today):
>- documents (4 major WIP)
>	https://tools.ietf.org/html/draft-finn-detnet-architecture
>	https://tools.ietf.org/html/draft-finn-detnet-problem-statement
>	https://tools.ietf.org/html/draft-gunther-detnet-proaudio-req
>	https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs
>- references (6TiSCH architecture clearly indicates DetNet dependencies,
>IEEE coordination provides information that Layer2-independent work is
>needed in the industry)
>	https://tools.ietf.org/html/draft-ietf-6tisch-architecture
>	https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases
>- a draft charter
>
>
>What we seem to be missing:
>
>- an improved gap analysis. Ted Lemon indicated at the BoF that this gap
>analysis would be crucial to figure if and which work would be needed
>from the IETF. From the early work on gap analysis, it seems that there
>is work that has no home, like the overall architecture and coordination,
>and a number of items that would have a home in different places,
>including at least PCE, CCAMP, TEAS, MPLS and TSVWG. We must refine this
>gap analysis and clarify the dependencies.
>
>- an evaluation of the amount of work. Lou indicated that CCAMP has
>already hosted work in the past. The amount of work would be an
>indication if DetNet can simply be hosted in an existing WG or should be
>its own WG. If the proposed charter is any indication, there is a lot
>that must be done before we are ready to ask for a specification from the
>groups mentioned above.
>
>- an industrial automation requirements draft. We have a number of great
>potential authors, but no one published DetNet work to date. One
>suggestion could be to use
>http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability
>as a starting point and elaborate on the deterministic flows. Another
>would be that an external group such as ISA100 publishes its requirements
>in its own terms and formats, and then we write a short draft that
>references it. 
>
>- activity on this mailing list. We need reviews and discussions on the
>drafts and the charter. We need inputs for the gap analysis, considering
>the scope of the existing WGs versus the work detailed in the charter. We
>need to demonstrate that we have an active team that is ready to execute
>on the commitment that we all would take with the IESG by forming a WG.
>
>- other?
>
>Please indicate if you are willing to contribute to any of the items
>above and fire discussions at will!
>
>Cheers;
>
>Pascal
>
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Apr 2015 19:28:13 +0000

Hi Norm:

> That seems to be a lot of stuff, but when we divide it up into specific work items
> a lot of things are already done or should be done elsewhere than in a DetNet
> WG:
> 
>  A. Time synchronization is solved elsewhere.  DetNet need not invent anything,
> here.
> 
> mechanisms to solve the problem of zero congestion loss for constant bit-rate
> flows at the lowest levels of the stack.  DetNet need not invent anything, here.
> 

Right: and/but I love the way Pat Thaler presented it at an adhoc with Lou.
This queues and timers and buffers system is really completely abstract from MAC/PHY technology and could be seen as an upper MAC function if passing a frame to the MAC allowed instantaneous presentation to the wire.
I think it would be good that this abstraction is presented in a way that is separated from Ethernet so we can reuse that abstraction everywhere. Is it already like that or would we need a short document that defines the entities and points to the IEEE doc for more details?

>  C. There is definitely DetNet work required to either invent or select (select is
> better) one or more specific data plane methods related to Seamless
> Redundancy (see the architecture draft).  We need a method that works end-to-
> end through routers and bridges to:
> 

Yes. That will be an inters

>   2. Operate on a sequence number in a DetNet packet.

Yes

>   1. Pinned-down paths through the network.

Yes, which related to pinned down resources defined in B

>      i) a pinned-down path; or

There are really 2 versions of that. 

In the TE model where flows are installed asynchronously, the classical model is to send a control message at ingress with the path in it. The message progresses along the indicated path till it is all set. I understand that this is what CCAMP is used to.

Then you have the case of a very stable network like an airbus. 
One may want the system to push the full schedule of each node individually as a package, as opposed to set up flow by flow.
For 6TiSCH, this model saves a lot of battery.

>     ii) a normal, dynamic path through the network topology;

Cheers,

Pascal

> >- references (6TiSCH architecture clearly indicates DetNet
> >dependencies, IEEE coordination provides information that
> >Layer2-independent work is needed in the industry)
> >- an improved gap analysis. Ted Lemon indicated at the BoF that this
> >gap analysis would be crucial to figure if and which work would be
> >needed from the IETF. From the early work on gap analysis, it seems
> >that there is work that has no home, like the overall architecture and
> >coordination, and a number of items that would have a home in different
> >places, including at least PCE, CCAMP, TEAS, MPLS and TSVWG. We must
> >refine this gap analysis and clarify the dependencies.
> >
> >indication if DetNet can simply be hosted in an existing WG or should
> >be its own WG. If the proposed charter is any indication, there is a
> >lot that must be done before we are ready to ask for a specification
> >from the groups mentioned above.
> >
> >- an industrial automation requirements draft. We have a number of
> >great potential authors, but no one published DetNet work to date. One
> >would be that an external group such as ISA100 publishes its
> >requirements in its own terms and formats, and then we write a short
> >draft that references it.
> >
> >drafts and the charter. We need inputs for the gap analysis,
> >considering the scope of the existing WGs versus the work detailed in
> >the charter. We need to demonstrate that we have an active team that is
> >ready to execute on the commitment that we all would take with the IESG by
> forming a WG.
> >
> >- other?
> >

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Apr 2015 07:52:38 -0400

Hi,
    See below for some comments.

>>  6. Robust defenses against misbehaving end and relay systems.

Isn't this list missing the key point of operation 802.1 bridged
networks interconnected over L3?  (Without it, it's just 802.1TSN, right?)

>>  A. Time synchronization is solved elsewhere.  DetNet need not invent anything,
100% agree, but DetNet needs to ensure proper operation over L3 (devices)

>> flows at the lowest levels of the stack.  DetNet need not invent anything, here.
Thankfully, there are also L3/IETF mechanisms that can be leveraged here
too. 
> Right: and/but I love the way Pat Thaler presented it at an adhoc with Lou.
I believe you, but don't recall this specific point;-)

> I think it would be good that this abstraction is presented in a way that is separated from Ethernet so we can reuse that abstraction everywhere. Is it already like that or would we need a short do…

This is good and important, particularly when mapping back and forth to
IETF mechanisms.

>> Redundancy (see the architecture draft). 
MPLS related mechanisms (I'm thinking TP more than FRR, but think this
is a discussion point) may be a good starting point for the L3 portion
of this.

>>  We need a method that works end-to-

Echoing my earlier point, 802.1 TSN operation across a collection of
bridges and routers is the fundamental unique effort of DetNet.

> In the TE model where flows are installed asynchronously,
TE, from the architectural perspective  doesn't predicate a specific
control behavior, so I'd omit the word "asynchronously" to be accurate.

>  the classical model is to send a control message at ingress with the path in it. The message progresses along the indicated path till it is all set. I understand that this is what CCAMP is used to.
This is one model and one shared by both MPLS-TE and GMPLS (by using
RSVP-TE for signaling and IS-IS/OSPF for resource discovery/advertisement).

Static allocation via management plane (e.g., in TP networks) and
controller based models (e.g., using PCEP, YANG, etc) are also valid TE
architecture implementation approaches.

> For 6TiSCH, this model saves a lot of battery.
Management based control of TE is definitely useful in a number of use
cases.
 
>>     ii) a normal, dynamic path through the network topology;

Are there any OAM considerations?  This has been  hot topic in a similar
recent discussions.

Thanks,
Lou