Re: [Detnet] The road to DetNet

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

Lou,

See in-line for a couple of responses.

-----Original Message-----
From: Lou Berger <[e-mail]>
Date: Thursday, April 30, 2015 at 04:52 AM
To: Pascal Thubert <[e-mail]>, Norman Finn <[e-mail]>,
"[e-mail]" <[e-mail]>, "Deborah Brungard ([e-mail])
([e-mail])" <[e-mail]>, Erik Nordmark <[e-mail]>
Cc: Tom Phinney <[e-mail]>, "Alia Atlas ([e-mail])"
<[e-mail]>
Subject: Re: [Detnet] The road to DetNet

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

We could certainly add:

7. Operation over bridged, routed, mixed, or non-Ethernet networks.

I only phrase it this way to avoid any implication (not intended by you,
as is clear from your later comments) that the end stations have to be
connected to L2 networks.  L2 tunneling technologies between bridged
networks are not precluded, by any means, but we don’t want them to be
necessary, and all-L3 networks are definitely a use case for DetNet.

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

After many years of being a non-fan of MPLS, I have to admit that its
ability to export the flow ID to the outside of the packet is very, very
useful in the context of DetNet; it makes it easy to do per-flow contract
validation and, when needed, to assign per-flow resources.

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

That’s a good question — not because I’m being polite, but because we
haven’t given it much thought.

My first reaction is that no, we’re not interested in OAM.  That would
surprise some, because I was the editor of the IEEE 802.1 Ethernet OAM
document, have my name on the TRILL OAM drafts, and I’m a big fan of OAM.

The reasons (which would have to go into the requirements draft) include:

  1. We hope to not introduce any new tunneling techniques that would
require a new kind of OAM.  The existing OAM should cover us.  (Note that
existing OAM technologies for both Ethernet and MPLS include latency
measurements.)
  2. When an application wants 10^(-12) packet loss rate, no amount of OAM
packets getting through give sufficient assurance that the data packets
will get through.  For this reason, we (IEEE P802.1CB draft) do things
like raise an alarm if the duplicate elimination function at the end of a
dual-path duplicated stream finds itself not throwing away half the
packets it receives.  IEEE 802.1 has a new project for per-flow filtering
and policing that will likely raise an alarm if a stream seems inactive.
  3. There is no extant OAM that I know of that traverses a mixed
bridged/routed network for ordinary data, and that gives visibility to
both bridges and routers, to serve as the basis for a DetNet OAM.

I would think that the solution to point 3 would something so general that
it belongs in another WG than DetNet.

— Norm

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