Re: [Detnet] The road to DetNet

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Norm:

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

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:
> 
>   1. Identify individual DetNet flows.

Yes. That will be an inters

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

Yes

>  D. We require service-level YANG models for:
> 
>   1. Pinned-down paths through the network.

Yes, which related to pinned down resources defined in B

> 
>   2. Resource reservations along:
> 
>      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

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