Re: [Detnet] The road to DetNet

["Norman Finn (nfinn)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, April 9, 2015 at 10:57 AM
To: "[e-mail]" <[e-mail]>, "Deborah Brungard
([e-mail]) ([e-mail])" <[e-mail]>, Erik
Nordmark <[e-mail]>, Lou Berger <[e-mail]>
Cc: Tom Phinney <[e-mail]>, "[e-mail]"
<[e-mail]>, "Alia Atlas ([e-mail])"
<[e-mail]>
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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/detnet