Subject: [Detnet] FW: is draft-ietf-detnet-architecture ready for LC?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Jun 2018 12:12:44 +0000

Also in prep for the call, please find the diffs that I proposed to Norm end of last year. Lou asked me to share them at IETF 101.
You'll find that some suggestions were picked, and that others were not, probably because of the mindset of the time, not too inclined to discuss network coding, detnet in detnet, or in order delivery.
The changes might look more agreeable by now.
Take care,
Pascal

From: Pascal Thubert (pthubert)
Sent: vendredi 27 octobre 2017 17:14
To: Norman Finn <[email-masked]>; Lou Berger <[email-masked]>
Cc: [email-masked]
Subject: RE: is draft-ietf-detnet-architecture ready for LC?

I passed the nits on it and removed the unused references. Also passed intended status to info.

From: Pascal Thubert (pthubert)
Sent: vendredi 27 octobre 2017 16:59
To: Norman Finn <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: is draft-ietf-detnet-architecture ready for LC?

Dear all:

Please find my proposed diffs and updated files attached, as well as copies of the originals. They are minor. I'm not introducing much that was not there already. For instance, reordering was there for PRE in case the 2 flows are jittered one vs. the other. I mostly added the capability to tunnel, which Norm also introduced on the mailing list recently.

I pushed to the repo. Please let me know OK/changes and I'll publish by cutoff. I'm happy to start a WGLC with those changes.

Take care;

Pascal

From: Pascal Thubert (pthubert)
Sent: vendredi 27 octobre 2017 13:57
To: Norman Finn <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: is draft-ietf-detnet-architecture ready for LC?

Let me suggest minor edits and come back to you Norm.
I'm working on it right now

Take care,

Pascal

From: Norman Finn [mailto:[email-masked]]
Sent: vendredi 27 octobre 2017 07:09
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: is draft-ietf-detnet-architecture ready for LC?

You do make sense, Pascal.  But, I'm not sure what to do about it.

I would be worried about expanding the scope too far.  i agree that there are a lot of nasty things that are needed when interfacing, say, wireless and wired, or when linking very different technologies.  But, I'm not at all sure how to express that in an architecture document (this one, in particular) without bringing up a lot more questions than answers, in the minds of the readers.

IMO, the document is ready for a wider audience, and your comments, if made more detailed and more specific, would be very helpful during last call.

Do we really need to wait another meeting cycle to handle you concerns before last call?

-- Norm
________________________________
From: Pascal Thubert (pthubert) [[email-masked]]
Sent: Thursday, October 26, 2017 2:37 AM
To: Norman Finn; Lou Berger
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: is draft-ietf-detnet-architecture ready for LC?
Hello Norm :

I think the push back on some features has to do with the particular solutions and use cases that we are considering for the DetNet dataplane at this time, as opposed to the DetNet Architecture.

Also, because of the focus  on the DetNet Transport Layer, I think that we have not thought through the DetNet Service Layer. I agree that the Service Layer is difficult to implement if it is tightly integrated to the dataplane solution.  This applies to Packet Replication and Elimination too, as you know well in the current discussions with Jouni and Loa. I'm not sure that a discussion on how much "harder" Flow Reordering and Network Coding are vs. Packet Replication and Elimination is that constructive.

I think that the architecture already does a good work at decoupling functions that are not implemented in the same category of systems; I also think that it must not ignore functions that are useful on the basis that they are hard to implement in one particular use case / technology. Rather, we must make sure it is clear that all the platforms/solutions do not need to implement all that is available in the Architecture - e.g. we already clarified that PRE in the middle of the path is not necessarily a good / feasible idea in all cases.

The biggest issue I see with the current architecture doc is that it seems toindicate that an application flow is mapped one-to-one with a DetNet/TSN flow across all the DetNet Segments that represent different technologies and/or controller domains. Missing the capability to place one-in-many or many-in-one ignores the fact that in the real world, some pipes have different sizes and lifecycles than others. In the real world, we also find gateways that act as gearbox to adapt capabilities, and I do not see that we will live without that sort of thing at the DetNet Service Layer as well.

I'd rather have the DetNet architecture position this properly even if the current dataplane ignores it, which is perfectly OK for now. Alternate would be that the DetNet Architecture explicitly limits its scope to DetNet Services as opposed to DetNet End-to-End Services, in which case I'd candidate text from DetTrans for the rest of the way, maybe at TSVWG. This is really a discussion on what's covered by which Area/WG.

Do I make sense?

Pascal
From: Norman Finn [mailto:[email-masked]]
Sent: mercredi 25 octobre 2017 22:12
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: is draft-ietf-detnet-architecture ready for LC?

Pascal,

What points about the architecture draft are in the DetTrans draft?  I see something in
4.3.1 of draft-thubert-tsvwg-detnet-transport-01 that says that the architecture draft
lacks a clear "distinction between application layer flows and lower layer flows".  The architecture
draft does make a distinction between DetNet member flows and DetNet compound flows; this
is necessary to talk about replication/elimination.  But, making a distinction between
"application layer flows" and "lower layer flows" seems counter-productive.  Making them
architecturally identical is what makes aggregation of flows possible, which will allow scaling up
the number of flows.

Also, I'll point out that the architecture does not, at present, support demultiplexing a
DetNet flow over multiple sub-rate channels.  This was proposed, but it opens up a
bit of a pandora's box.  For example, it requires re-ordering the received packets (IMO)
and that has been avoided.  Also, distributing the packets is not a trivial task when you
cannot know the distribution of packet sizes within a flow.  (We know in 802.1 that
characterizing the bandwidth as {maxPacketSize, nPackets, interval} is too restrictive
when using CQF shaping, which works on {maxBitsOnTheWire, interval}.  But, that
makes sub-rate demultiplexing more complex.)

What specific changes would you suggest to the architecture document?

-- Norm
________________________________
From: Pascal Thubert (pthubert) [[email-masked]]
Sent: Tuesday, October 24, 2017 1:39 PM
To: Lou Berger
Cc: [email-masked]<mailto:[email-masked]>; DetNet Chairs
Subject: Re: is draft-ietf-detnet-architecture ready for LC?
Hello Lou:

Maybe a pass after we decide how to process the points made in the DetTrans draft and then yes, I 'd say that both problem statement and architecture should be ready.

What do others think?

Pascal

Le 24 oct. 2017 à 22:35, Lou Berger <[email-masked]<mailto:[email-masked]>> a écrit :
Authors,

What's you're view on this document, is it ready for LC?

Thanks,

Lou