Re: [Detnet] The road to DetNet

[Lou Berger <[e-mail]>]

Hi Norm,

    Thanks for the response. See below.

On 5/1/2015 6:37 PM, Norman Finn (nfinn) wrote:
> 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 think operation L2-only operation belongs to the IEEE, so just need to
be careful to not go there.

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

Yup, its TE mechanisms seem well aligned.  I sort of chuckled when I saw
draft-mirsky-mpls-residence-time announced soon after reading your mail.

>>>>  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.)
makes sense to me

>   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.
The MIP and MEP functions that were formalized along with MPLS-TP could
be leveraged.  That said, I think it's fine to be quite on this point
for now.

Lou

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