Re: [Detnet] The road to DetNet

[Lou Berger <[e-mail]>]

Hi,
    See below for some comments.

On 4/27/2015 3:28 PM, Pascal Thubert (pthubert) wrote:
> 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.


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?)


>>
>> 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.
100% agree, but DetNet needs to ensure proper operation over L3 (devices)

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

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

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

>>  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). 
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-
>> end through routers and bridges to:
>>
>>   1. Identify individual DetNet flows.
> Yes. That will be an inters

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

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

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

> 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