Subject: Re: [Detnet] Transport sub-layer name change (Was Re: Tsvart last call review of draft-ietf-detnet-architecture-08)

From: János Farkas <[email-masked]>
Date: Fri, 7 Dec 2018 16:45:43 +0100

Hi,

I have a similar concern with the change. It of course depends on the 
definition of Traffic Engineering, but the term "DetNet TE sub-layer" 
may imply to the reader that Traffic Engineering is a must even for 
DetNet transit nodes. As far as I recall, the intention is to make 
possible that DetNet transit nodes can be kept simple. Depending on the 
actual DetNet service provided, DetNet transit nodes can be actually simple.

The idea behind the introduction of the two DetNet sub-layers was to 
make it easier to tackle the problem. The lower layer provides simpler 
packet forwarding related functions, the higher DetNet Service sub-layer 
provides more complex DetNet service related functions.

In order to have another alternative on the table I propose renaming 
"DetNet Transport sub-layer" to "DetNet Forwarding sub-layer"

Best regards,
Janos

On 11/20/2018 10:10 PM, Lou Berger wrote:
>
> On 11/20/2018 3:11 PM, Andrew G. Malis wrote:
>> This terminology is certainly appropriate for TEAS. For DetNet, this 
>> seems to make the assertion that the DetNet underlay is always 
>> traffic-engineered, even if IPv4 or IPv6 (which is certainly possible 
>> using TE extensions for the IGPs).
>
> This is certainly a fair point and one that does lead me to have a 
> slight reservation about the change, that said, it seems the benefit 
> out ways the downsides.
>
>>
>> As long as people are OK with this assertion, then I'm OK with it as 
>> well. That should be made clear in the architecture spec where the 
>> term "DetNet TE sub-layer" is introduced/defined.
>
> agreed.
>
> Lou
>
>>
>> Cheers,
>> Andy
>>
>> On Tue, Nov 20, 2018 at 1:29 PM Grossman, Ethan A. <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     I like it.
>>     Ethan.
>>
>>     -----Original Message-----
>>     From: Pascal Thubert (pthubert) <[email-masked]
>>     <mailto:[email-masked]>>
>>     Sent: Tuesday, November 20, 2018 10:27 AM
>>     To: Lou Berger <[email-masked] <mailto:[email-masked]>>;
>>     Scharf, Michael <[email-masked]
>>     <mailto:[email-masked]>>
>>     Cc: [email-masked] <mailto:[email-masked]>;
>>     [email-masked]
>>     <mailto:[email-masked]>
>>     Subject: RE: Transport sub-layer name change (Was Re: [Detnet]
>>     Tsvart last call review of draft-ietf-detnet-architecture-08)
>>
>>     I support this change;
>>
>>     Pascal
>>
>>     > -----Original Message-----
>>     > From: Lou Berger <[email-masked] <mailto:[email-masked]>>
>>     > Sent: mardi 20 novembre 2018 19:19
>>     > To: Pascal Thubert (pthubert) <[email-masked]
>>     <mailto:[email-masked]>>; Scharf, Michael
>>     > <[email-masked]
>>     <mailto:[email-masked]>>
>>     > Cc: [email-masked] <mailto:[email-masked]>;
>>     [email-masked]
>>     <mailto:[email-masked]>
>>     > Subject: Transport sub-layer name change (Was Re: [Detnet]
>>     Tsvart last
>>     > call review of draft-ietf-detnet-architecture-08)
>>     >
>>     > ALL,
>>     >
>>     > There is a desire to replace the word "Transport" from the DetNet
>>     > Transport sub-layer to avoid confusion with L$ Transport 
>> protocols.
>>     >
>>     > In the TEAS WG we had a similar discussion and we replaced
>>     "Transport"
>>     > with "Traffic Engineered (TE) ".
>>     >
>>     > While a bit more verbose, what do people think about this change?
>>     >
>>     > To be clear, the suggestion is:
>>     >
>>     > OLD
>>     >
>>     >                     .
>>     >                     .
>>     >       +----------------------------+
>>     >       |  DetNet Service sub-layer  | PW, UDP, GRE
>>     >       +----------------------------+
>>     >       | DetNet Transport sub-layer | IPv6, IPv4, MPLS TE LSPs,
>>     MPLS SR
>>     >       +----------------------------+
>>     >                     .
>>     >                     .
>>     >
>>     >                   Figure 4: DetNet adaptation to data plane
>>     >
>>     > NEW
>>     >
>>     >                     .
>>     >                     .
>>     >       +----------------------------+
>>     >       |  DetNet Service sub-layer  | PW, UDP, GRE
>>     >       +----------------------------+
>>     >       |      DetNet TE sub-layer   | IPv6, IPv4, MPLS TE LSPs,
>>     MPLS SR
>>     >       +----------------------------+
>>     >                     .
>>     >                     .
>>     >
>>     >                   Figure 4: DetNet adaptation to data plane
>>     >
>>     > Lou
>>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Lou Berger <[email-masked]>
Date: Fri, 7 Dec 2018 11:13:08 -0500

Hi,

> "DetNet Transport sub-layer" to "DetNet Forwarding sub-layer"
This is a bit of a new usage for 'Forwarding' but not totally -- 
thinking about FIBs.  My main reservation is that forwarding is usually 
considered separately from queuing, while this sub-layer embodies both.  
I do accept that TE usually considers both forwarding/steering and 
queuing, and that some assume that sophisticated queuing is required for 
TE -- which is actually service dependent.

Even with this caveat and my personal preference for the 'TE' option, I 
(as contributor) can live with "DetNet Forwarding sub-layer".

Lou

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 7 Dec 2018 12:48:42 -0500

I also support DetNet Forwarding sub-layer. Unlike Lou, I've always
regarded queuing as a fundamental part of an overall forwarding
architecture.

Cheers,
Andy

On Fri, Dec 7, 2018 at 11:13 AM Lou Berger <[email-masked]> wrote:

> >>>      > From: Lou Berger <[email-masked] <mailto:[email-masked]>>
> >>>      > Sent: mardi 20 novembre 2018 19:19
> >>>      > To: Pascal Thubert (pthubert) <[email-masked]
> >>>      > <[email-masked]
> >>>      > Subject: Transport sub-layer name change (Was Re: [Detnet]
> >>>      Tsvart last
> >>>      > call review of draft-ietf-detnet-architecture-08)
> >>>      >
> >>>      > ALL,
> >>>      >
> >>>      > There is a desire to replace the word "Transport" from the
> DetNet
> >>>      > Transport sub-layer to avoid confusion with L$ Transport
> >>> protocols.
> >>>      >
> >>>      > In the TEAS WG we had a similar discussion and we replaced
> >>>      "Transport"
> >>>      > with "Traffic Engineered (TE) ".
> >>>      >
> >>>      > While a bit more verbose, what do people think about this
> change?
> >>>      >
> >>>      > To be clear, the suggestion is:
> >>>      >
> >>>      > OLD
> >>>      >
> >>>      >                     .
> >>>      >                     .
> >>>      >       +----------------------------+
> >>>      >       |  DetNet Service sub-layer  | PW, UDP, GRE
> >>>      >       +----------------------------+
> >>>      >       | DetNet Transport sub-layer | IPv6, IPv4, MPLS TE LSPs,
> >>>      MPLS SR
> >>>      >       +----------------------------+
> >>>      >                     .
> >>>      >                     .
> >>>      >
> >>>      >                   Figure 4: DetNet adaptation to data plane
> >>>      >
> >>>      > NEW
> >>>      >
> >>>      >                     .
> >>>      >                     .
> >>>      >       +----------------------------+
> >>>      >       |  DetNet Service sub-layer  | PW, UDP, GRE
> >>>      >       +----------------------------+
> >>>      >       |      DetNet TE sub-layer   | IPv6, IPv4, MPLS TE LSPs,
> >>>      MPLS SR
> >>>      >       +----------------------------+
> >>>      >                     .
> >>>      >                     .
> >>>      >
> >>>      >                   Figure 4: DetNet adaptation to data plane
> >>>      >
> >>>      > Lou
> >>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 7 Dec 2018 10:10:28 -0800

Dear All,
my first choice would be "DetNet Transport Network sub-layer" but would
agree with "DetNet Forwarding sub-layer".
On a side note, for the sake of completeness, we may add SRv6 to the list
in Figure 4 and refer to SR over MPLS data plane as SR-MPLS.

Regards,
Greg

---

From: Loa Andersson <[email-masked]>
Date: Sat, 8 Dec 2018 11:07:55 +0800

Lou, et.al,.

> (as contributor) can live with "DetNet Forwarding sub-layer".

Understanding that we want to pick good names, and that sometimes this
turns out to be "impossible".

But after all a name is just a name.

I can live with "DetNet Forwarding sub-layer".

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: S.V.R.Anand <[email-masked]>
Date: Sat, 8 Dec 2018 07:08:36 +0000

Hi All,

I feel Detnet Forwarding sub-layer is very close to capturing the functionality,
but Forwarding still overloaded as observed by Lou.

Given the wide range of mechanisms and lower layer services that this layer
works with, I wonder if it makes sense to use a generic term "convergence" in
the name. It is not uncommon to come across this term as part of a name in the
context of a typical foo-layer.5. Just a thought. This said, I am still fine
with Detnet Forwarding sub-layer.

Regards
Anand

On Sat, Dec 08, 2018 at 11:07:55AM +0800, Loa Andersson wrote:
> >thinking about FIBs.  My main reservation is that forwarding is
> >usually considered separately from queuing, while this sub-layer
> >embodies both. I do accept that TE usually considers both
> >forwarding/steering and queuing, and that some assume that
> >sophisticated queuing is required for TE -- which is actually
> >service dependent.
> >
> >Even with this caveat and my personal preference for the 'TE'
> >option, I (as contributor) can live with "DetNet Forwarding
> >sub-layer".
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 Dec 2018 05:37:33 +0000

Hello 

I’m fine with both with a preference for TE. It seems to me that we are extending classical forwarding in the TE and QoS spaces, so TE is more specific this better suited.

Now, my hope is that we never spell it out. We have to find an acronym that is pronounceable and that acronym will leave no room to confusion if we never expand it.

DTSL (transport) is too close from DTLS
DFSL is  ok but tiresome 
DTESL is a bit long, we may ignore the S either in spelling and or writing; note that old French has many S that went away e.g., forest is pronounced foray and modern spelling is forêt 
DTEL could be pronounced dee-tell quite easy.

Think about how many times you will have to pronounce it and choose wisely! I vote “dee-tell” whether we have the S in the acronym or not...

Regards,

Pascal

> Le 8 déc. 2018 à 08:08, S.V.R.Anand <[email-masked]> a écrit :
> 
> Hi All,
> 
>>>>>>      > There is a desire to replace the word "Transport"
>>>>>> from the DetNet
>>>>>>      > While a bit more verbose, what do people think about
>>>>>> this change?
>>>>>>      >

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 10 Dec 2018 02:55:49 +0000

Hi All,

Personally, I prefer for forwarding sub-layer for the reason -- "packet forwarding" describes how nodes forward packets after receiving the packets, including necessary de-/en-capsuslation, table lookup, of course queueing related operations and etc.

Best regards,

Cristina QIANG

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Sunday, December 09, 2018 1:38 PM
To: S.V.R.Anand <[email-masked]>
Cc: detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]; [email-masked]; János Farkas <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Lou Berger <[email-masked]>; Loa Andersson <[email-masked]>
Subject: Re: [Detnet] Transport sub-layer name change (Was Re: Tsvart last call review of draft-ietf-detnet-architecture-08)

Hello 

DTSL (transport) is too close from DTLS
DFSL is  ok but tiresome
DTESL is a bit long, we may ignore the S either in spelling and or writing; note that old French has many S that went away e.g., forest is pronounced foray and modern spelling is forêt DTEL could be pronounced dee-tell quite easy.

Regards,

Pascal

> I feel Detnet Forwarding sub-layer is very close to capturing the 
> functionality, but Forwarding still overloaded as observed by Lou.
> 
> Given the wide range of mechanisms and lower layer services that this 
> layer works with, I wonder if it makes sense to use a generic term 
> "convergence" in the name. It is not uncommon to come across this term 
> as part of a name in the context of a typical foo-layer.5. Just a 
> thought. This said, I am still fine with Detnet Forwarding sub-layer.
> 
> Regards
> Anand
> 
> 
> 
>>>> In order to have another alternative on the table I propose 
>>>> renaming "DetNet Transport sub-layer" to "DetNet Forwarding sub-layer"
>> Understanding that we want to pick good names, and that sometimes 
>> this turns out to be "impossible".
>> 
>>>> I have a similar concern with the change. It of course depends on 
>>>> the definition of Traffic Engineering, but the term "DetNet TE sub-layer"
>>>> possible that DetNet transit nodes can be kept simple. Depending on 
>>>> the actual DetNet service provided, DetNet transit nodes can be 
>>>> actually simple.
>>>> 
>>>> The idea behind the introduction of the two DetNet sub-layers was 
>>>> to make it easier to tackle the problem. The lower layer provides 
>>>> simpler packet forwarding related functions, the higher DetNet 
>>>> Service sub-layer provides more complex DetNet service related functions.
>>>> 
>>>> In order to have another alternative on the table I propose 
>>>> renaming "DetNet Transport sub-layer" to "DetNet Forwarding sub-layer"
>>>> 
>>>> Best regards,
>>>> Janos
>>>> 
>>>> 
>>>>>> This terminology is certainly appropriate for TEAS. For DetNet, 
>>>>>> this seems to make the assertion that the DetNet underlay is 
>>>>>> always traffic-engineered, even if IPv4 or IPv6 (which is 
>>>>>> certainly possible using TE extensions for the IGPs).
>>>>> slight reservation about the change, that said, it seems the 
>>>>> benefit out ways the downsides.
>>>>> 
>>>>>> As long as people are OK with this assertion, then I'm OK with it 
>>>>>> as well. That should be made clear in the architecture spec where 
>>>>>> the term "DetNet TE sub-layer" is introduced/defined.
>>>>> agreed.
>>>>> 
>>>>> Lou
>>>>> 
>>>>>> Cheers,
>>>>>> Andy
>>>>>> 
>>>>>> On Tue, Nov 20, 2018 at 1:29 PM Grossman, Ethan A. 
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>      I like it.
>>>>>>      Ethan.
>>>>>>

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 10 Dec 2018 06:32:42 +0000

Hi,

I am fine with "DetNet Forwarding sub-layer".

Note: in order to match it somewhat better (i.e., considering the QoS aspects) 
we can consider "DetNet Forwarding Adaptation sub-layer".

Cheers
Bala'zs

-----Original Message-----
From: qiangli (D) <[email-masked]> 
Sent: Monday, December 10, 2018 3:56 AM
To: Pascal Thubert (pthubert) <[email-masked]>; S.V.R.Anand <[email-masked]>
Cc: detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]; [email-masked]; Janos Farkas <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Lou Berger <[email-masked]>; Loa Andersson <[email-masked]>
Subject: RE: [Detnet] Transport sub-layer name change (Was Re: Tsvart last call review of draft-ietf-detnet-architecture-08)

Hi All,

Best regards,

Cristina QIANG

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Sunday, December 09, 2018 1:38 PM
To: S.V.R.Anand <[email-masked]>
Cc: detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]; [email-masked]; János Farkas <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Lou Berger <[email-masked]>; Loa Andersson <[email-masked]>
Subject: Re: [Detnet] Transport sub-layer name change (Was Re: Tsvart last call review of draft-ietf-detnet-architecture-08)

Hello 

Regards,

Pascal

---

From: Loa Andersson <[email-masked]>
Date: Mon, 10 Dec 2018 15:56:45 +0800

Folks,

The issue being discussed is one that should be resolved to let the
architecture document move ahead,

I think the time of tweaking is over and that the chairs ´ should call
consensus on "DetNet Forwarding sub-layer".

We are a number of people that are not 100% happy with that, but most
of us has said that we can live with that.

/Loa

--

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Dec 2018 08:52:36 -0500

+1

On Mon, Dec 10, 2018 at 2:57 AM Loa Andersson <[email-masked]> wrote:

> > Cc: detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>;
> [email-masked];
> [email-masked]; Janos Farkas <
> [email-masked]>; Grossman, Ethan A. <[email-masked]>; Lou
> Berger <[email-masked]>; Loa Andersson <[email-masked]>
> > Subject: RE: [Detnet] Transport sub-layer name change (Was Re: Tsvart
> last call review of draft-ietf-detnet-architecture-08)
> >
> > Hi All,
> >
> > Personally, I prefer for forwarding sub-layer for the reason -- "packet
> forwarding" describes how nodes forward packets after receiving the
> packets, including necessary de-/en-capsuslation, table lookup, of course
> queueing related operations and etc.
> >
> > Best regards,
> >
> > Cristina QIANG
> >
> > Cc: detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>;
> [email-masked];
> [email-masked]; János Farkas <
> [email-masked]>; Grossman, Ethan A. <[email-masked]>; Lou
> Berger <[email-masked]>; Loa Andersson <[email-masked]>
> > Subject: Re: [Detnet] Transport sub-layer name change (Was Re: Tsvart
> last call review of draft-ietf-detnet-architecture-08)
> >
> > Hello
> >
> > I’m fine with both with a preference for TE. It seems to me that we are
> extending classical forwarding in the TE and QoS spaces, so TE is more
> specific this better suited.
> >
> > Now, my hope is that we never spell it out. We have to find an acronym
> that is pronounceable and that acronym will leave no room to confusion if
> we never expand it.
> >
> > DTESL is a bit long, we may ignore the S either in spelling and or
> writing; note that old French has many S that went away e.g., forest is
> pronounced foray and modern spelling is forêt DTEL could be pronounced
> dee-tell quite easy.
> >
> > Think about how many times you will have to pronounce it and choose
> wisely! I vote “dee-tell” whether we have the S in the acronym or not...
> >
> > Regards,
> >
> > Pascal
> >

---

From: János Farkas <[email-masked]>
Date: Mon, 10 Dec 2018 15:29:39 +0100

Hi,

As I understand, there is confusion around two DetNet terms.
We are removing "transport".

The other one is "congestion" and "congestion protection".

Brief description of congestion protection in Section 3.1:

    Congestion protection operates by allocating resources along the path
    of a DetNet flow, e.g., buffer space or link bandwidth. Congestion
    protection greatly reduces, or even eliminates entirely, packet loss
    due to output packet congestion within the network, but it can only
    be supplied to a DetNet flow that is limited at the source to a
    maximum packet size and transmission rate.  Note that congestion
    protection provided via congestion detection and notification is
    explicitly excluded from consideration in DetNet, as it serves a
    different set of applications.

    Congestion protection addresses two of the DetNet QoS requirements:
    latency and packet loss.  Given that DetNet nodes have a finite
    amount of buffer space, congestion protection necessarily results in
    a maximum end-to-end latency.  It also addresses the largest
    contribution to packet loss, which is buffer congestion.

Detailed description is in Section 3.2.1.

We wanted to have a brief collective term for the mechanisms used to 
avoid queuing related packet loss (including buffer overflow etc.).

Based on the discussions, we should have a term that does not include 
"congestion".
("Service Protection" is another DetNet term, hence we may consider a 
term without "protection" to minimize confusion.)

I suggest to replace "congestion protection" with "queuing loss avoidance".

After agreeing in the terminology cahnge (if any), the text has to be 
updated accordingly.

What do you think?

Best regards,
Janos

On 11/20/2018 1:11 PM, Lou Berger wrote:
> Michael,
>
> I think we're getting somewhere and identifying where we have 
> disconnects and what may (and what may not) need to change in the 
> document.  My takeaways are:
>
> - The document needs a good 'scrub' of the congestion related 
> references to ensure that the document only makes statements on what 
> is actually done within a DetNet and the relationship with transport 
> protocols that use detnet (which are in fact outside the scope of the 
> DetNet WG).  I'll work with the authors and WG on this -- I see this 
> change as important, but editorial in nature.
>
> - We have a perception issue with at least one member of the TSV area 
> on the meaning and more importantly, implication, of the term "DetNet 
> *Transport* sub-layer".  While I don't disagree that a good portion of 
> the IETF thinks transport protocol (UDP/TCP) when they hear 
> "transport" there are plenty others, particularly in the routing area, 
> who understand that "transport" can refer to Transport Networks.  And 
> Transport Network is a well understood general industry term. The IETF 
> even has a bunch of RFCs that relate to Transport networks.  This 
> said, I think it reasonable to go back to the DetNet WG and discuss 
> changing the name of the "DetNet Transport sub-layer"  to avoid the 
> word "transport".  -- BTW we made a parallel change in the TEAS WG 
> when producing RFC8453.
>
> See below for detail response in-line.
>
> On 11/19/2018 5:15 PM, Scharf, Michael wrote:
>> Lou,
>>
>>> -- 
>>> I wanted to take a step back from the multiple discussions that were
>>> spawned by your review -- from a doc shepherd perspective, and see
>>> where
>>> we are.   I know that the authors have sent a -09 version that
>>> addresses
>>> some, but not all issues.
>>>
>>>   From the exchanges I've seen, I think the key remaining issues are
>>> related to:
>>>
>>> (a) possibly introduction of congestion in the general internet if
>>> packets were somehow to escape a detnet domain.  The source of this
>>> congestion would be inelastic traffic using DetNet or due to congestion
>>> loss that is masked by PREOF.
>> These are two major issues that need to be addressed. Note that it 
>> may not be sufficient just to add a section on operational and 
>> deployment considerations. Also the existing text in the document 
>> will need to get aligned to normative guidance on how to avoid a 
>> congestion collapse.
>>
>> In -09, one example would be Section 3.1. "Primary goals defining the 
>> DetNet QoS"
>>
>>     Congestion protection operates by allocating resources along the 
>> path
>>     of a DetNet flow, e.g., buffer space or link bandwidth. Congestion
>>     protection greatly reduces, or even eliminates entirely, packet loss
>>     due to output packet congestion within the network, but it can only
>>     be supplied to a DetNet flow that is limited at the source to a
>>     maximum packet size and transmission rate.  Note that congestion
>>     protection provided via congestion detection and notification is
>>     explicitly excluded from consideration in DetNet, as it serves a
>>     different set of applications.
>
>> At least the last sentence would contradict a better discussion of 
>> congestion in the document. For instance, it could just be removed. 
>> In any case, the current wording in the last sentence is not correct, 
>> as the IETF term for what is described in the last sentence is 
>> "congestion control".
>>
>> Another example would be  Section 3.2.1.1. "Eliminate congestion loss"
>>       The primary means by which DetNet achieves its QoS assurances 
>> is to
>>     reduce, or even completely eliminate, congestion within a DetNet 
>> node
>>     as a cause of packet loss.  This can be achieved only by the
>>     provision of sufficient buffer storage at each node through the
>>     network to ensure that no packets are dropped due to a lack of 
>> buffer
>>     storage.  Note that a DetNet flow cannot be throttled, i.e., its
>>     transmission rate cannot be reduced via explicit congestion
>>     notification.
>>
>> This section IMHO has to include a discussion of what happens in the 
>> (not expected) case that packets get dropped or that ECN marks are 
>> received. It is understood that this would not happen in normal 
>> operation of a DetNet network, but I believe just considering the 
>> error-free operation of a DetNet network is not sufficient for this 
>> document. At least for the risk of traffic that may escape from a 
>> DetNet network is inherently not sufficient to assume that the DetNet 
>> network is always error-free.
>
> I think these are examples of text that needs to be cleanup up and to 
> delineate what is done with a DetNet.
>
>
>> As a result, addressing my concerns will most likely require editing 
>> several parts of the document.
>>
>> In addition, I'd like to emphasize that my review comment "It is 
>> surprising that there is hardly any discussion on network robustness 
>> and safety"
>
> I have no idea what you mean by safety here.  Can you elaborate.
>
>
>> covers more than just inelastic traffic that escapes from a DetNet 
>> network and masking of packet loss. Given that DetNet traffic may be 
>> extremely critical traffic, I really wonder why the document doesn't 
>> emphasize more the required robustness against failures *inside* the 
>> DetNet network as well as counter-measures. But this is something the 
>> WG needs to decide. As TSV-ART reviewer, I will be fine if the 
>> document clearly describes how the impact of failures will be 
>> isolated inside the DetNet network and will not put the general 
>> Internet at risk.
>
> I agree - I think, the document should be clear on it's scope and 
> relationship to general internet usage.
>
>
>>
>>> (b) The use of the term 'transport' in DetNet to refer to what is
>>> basically a Traffic Engineered sub-network layer, such as is provided
>>> with MPLS-TE or Optical Transport Networks.
>> In the Internet architecture, the term 'transport' refers to Internet 
>> transport protocols. I doubt that the document can avoid discussing 
>> the implications of and interactions with Internet transport 
>> protocols such as UDP or TCP. As a result, I disagree that the 
>> document can use the term 'transport' to refer to traffic engineered 
>> sub-network layers.
>
> I think this is covered by my comment above.
>
>
>>  From a TSV-ART point of view, the document can either only use the 
>> term "transport" for Internet transport protocols and use another 
>> term for sub-network layers (as handled in the *routing* area of the 
>> IETF), or the document has to clearly distinguish between the 
>> Internet transport layer and other uses of the term "transport" and 
>> explain the overlap. I believe the former would be less confusing, 
>> but I will leave it up to the TSV ADs to discuss terminology overlap 
>> in the IESG. As TSV-ART reviewer I insist that the document uses the 
>> terms "transport layer" and "transport protocol" only when referring 
>> to the Internet transport layer.
>
> I'm personally okay with a name change and even willing to push this 
> discussion within the WG, but as said above, "Transport Network" is a 
> generally understood industry term that is also used in RFCs -- so 
> we'll have to see what where WG consensus ends up.
>
>>
>>> Do you have any other issues that that are critical to be addressed
>>> before this work moves forward?  If so which?
>> Regarding Section 4.4 I have already deferred the discussion to the 
>> IESG. The TSV-ART review comment is that the IESG needs to carefully 
>> look at the concepts, terminology, and references in section 4.4.
>>
>> Regarding my other comments, I acknowledge that -09 is a step 
>> forward. But given the cross-dependencies e.g. regarding terminology 
>> and definitions, I will need to read the text completely once there 
>> is a proposal how to address my review. As noted in my review, I 
>> believe the document must use terminology clearly and consistently. 
>> As example, a statement in -09 such as "Network nodes supporting 
>> DetNet flows have to implement some of the DetNet capabilities (not 
>> necessarily all) in order to treat DetNet flows such that their QoS 
>> requirements are met" is IMHO too vague. But in such cases it depends 
>> whether there is precise normative guidance elsewhere. And this 
>> requires looking at the text as a whole.
>
> I think the next steps lie with me and the WG.  We'll let you know 
> once there is a new version.  Of course, you can also contribute to 
> the WG discussion on the topic.
>
> Thanks,
>
> Lou
>
>>
>> Best regards
>>
>> Michael
>>
>>
>>
>>> Thank you,
>>>
>>> Lou
>>>
>>> On 9/28/2018 6:24 PM, Michael Scharf wrote:
>>>> Reviewer: Michael Scharf
>>>> Review result: Ready with Issues
>>>>
>>>> The document "Deterministic Networking Architecture"
>>>> (draft-ietf-detnet-architecture-08) defines an overall framework for
>>>> Deterministic Networking.
>>>>
>>>> As TSV-ART reviewer, I believe that this document has issues as
>>> detailed below.
>>>> Michael
>>>>
>>>> Major issues:
>>>>
>>>> * It seems that DetNet cannot easily be deployed in the Internet
>>> without
>>>> additional means. Thus, for a baseline document, one could expect
>>> some
>>>> explanation on the requirements of deploying DetNet in a network.
>>> DetNet
>>>> basically requires support in (almost) all network devices
>>> transporting DetNet
>>>> traffic. That assumption should be explicitly spelt out early in the
>>> document,
>>>> e.g., in the introduction. There also needs to be an explicit
>>> discussion of the
>>>> implications if not the whole network is aware of or supports DetNet.
>>> There is
>>>> some text in Section 4.2.2 and Section 4.3.3, but I believe
>>> additional explicit
>>>> discussion is needed at a prominant place. For instance, can use of
>>> DetNet do
>>>> harm to parts of a network not supporting DetNet? As a side note,
>>> when TCPM
>>>> published RFC 8257, the following disclaimer was added: "DCTCP, as
>>> described in
>>>> this specification, is applicable to deployments in controlled
>>> environments
>>>> like data centers, but it must not be deployed over the public
>>> Internet without
>>>> additional measures." I wonder if a similar disclaimer is needed for
>>> DetNet. If
>>>> there is an implicit assumption that DetNet will  be used in
>>> homogenous
>>>> environments with mostly DetNet-aware devices within the same
>>> organization,
>>>> such an assumption should be made explicit.
>>>>
>>>> * It is surprising that there is hardly any discussion on network
>>> robustness
>>>> and safety; this probably also relates to security. For instance,
>>>> misconfiguration or errors of functions performing packet replication
>>> could
>>>> severely and permantly congest a network and cause harm. How does the
>>> DetNet
>>>> architecture ensure that a network stays fully operational e.g. if
>>> the topology
>>>> changes or there are equipment failures? Probably this can be solved
>>> by
>>>> implementations (e.g., dynamic control plane), but why are
>>> corresponding
>>>> requirements not spelt out? Section 3.3.2 speculates that filters and
>>> policers
>>>> can help, and that may be true, but that probably still assumes
>>> consistently
>>>> and correctly configured (and well-behaving) devices. And Section
>>> 3.3.2 is
>>>> vague and mentions a "infinite variety of possible failures" without
>>> stating
>>>> any requirements or recommendations. There may be further solutions,
>>> such as
>>>> circuit breakers and the like. Why are such topics not discussed?
>>>>
>>>> * Somewhat related, the document only looks at impact of failures to
>>> the QoS of
>>>> DetNet traffic. What is missing is a discussion how to protect non-
>>> DetNet parts
>>>> of a network from any harm caused by DetNet mechanisms. Solutions to
>>> this
>>>> probably exist. But why is the impact on non-DetNet traffic (e.g., in
>>> case of
>>>> topology changes or failures of DetNet functions) not discussed at
>>> all in the
>>>> document?
>>>>
>>>> * Regarding security, an architecture like DetNet probably requires
>>> that only
>>>> authenticated and authorized end systems have access to the data
>>> plane. The
>>>> security considerations only briefly mention the control aspect ("the
>>>> authentication and authorization of the controlling systems").
>>>>
>>>> * For an architecture document, the lack of clarity and consistency
>>> regarding
>>>> terminology is concerning. This specifically applies to the case of
>>> incomplete
>>>> networks (as per Section 4.2.2 and 4.3.3) that include "DetNet-
>>> unaware nodes".
>>>> The document introduces terms such as "DetNet intermediate nodes" but
>>> then
>>>> repeatedly uses generic terms such as "node" or "hop" that may
>>> include
>>>> DetNet-unaware nodes. For instance, for incomplete networks, a
>>> sentence such as
>>>> "The primary means by which DetNet achieves its QoS assurances is to
>>> reduce, or
>>>> even completely eliminate, congestion within a node as a cause of
>>> packet loss"
>>>> seems to only apply to "DetNet transit nodes" but not "DetNet-unaware
>>> nodes".
>>>> Similar ambiguity exist for other use of the terms "hop" and "node",
>>> which may
>>>> or may not include DetNet-unaware nodes. It is unclear why the
>>> document does
>>>> not consistently use the terminology introduced in Section 2.1 in all
>>> sections
>>>> and clearly distinguishes cases with and without DetNet support.
>>>>
>>>> * Section 4.4 refers to RFC 7426, which is an informational RFC on
>>> IRTF stream,
>>>> and the document uses the concepts introduced there (e.g., "planes").
>>> This is
>>>> very confusing. First, an IETF Proposed Standard should probably
>>> refer to
>>>> documents having IETF consensus. An example would be RFC 7491, albeit
>>> there is
>>>> other related work as well, e.g., in the TEAS WG. Second, Section 4.4
>>> is by and
>>>> large decoupled from the rest of the document and not specific to
>>> DetNet.
>>>> Neither do other sections of the document refer to the concepts
>>> introduced in
>>>> Section 4.4, nor does Section 4.4 use the DetNet terminology or
>>> discuss
>>>> applicability to DetNet. Section 4.4 even mentions explicitly at the
>>> end that
>>>> it discusses aspects that are orthogonal to the DetNet architecture.
>>> It is not
>>>> at all clear why Section 4.4 is in this document. Section 4.4 could
>>> be removed
>>>> from the document without impacting the rest of the document.
>>>>
>>>> Minor issues:
>>>>
>>>> * Terminology "DetNet transport layer"
>>>>
>>>>     The term "transport layer" has a well-defined meaning in the IETF,
>>> e.g.
>>>>     originating from RFC 1122. While "transport" and e.g. "transport
>>> network" is
>>>>     used in the IETF for different technologies in different areas, I
>>> think the
>>>>     term "transport layer" is typically understood to refer to
>>> transport
>>>>     protocols such as TCP and UDP. As such, I personally find the term
>>> "DetNet
>>>>     transport layer" misleading and confusing. The confusion is easy
>>> to see e.g.
>>>>     in Figure 4, where UDP (which is a transport protocol as per RFC
>>> 1122) sits
>>>>     on top of "transport".
>>>>
>>>>     Based on the document it also may be solution/implementation
>>> specific whether
>>>>     the "DetNet transport layer" is actually a separate protocol layer
>>> compared
>>>>     to the "DetNet service layer". Thus it is not clear to me why the
>>> word
>>>>     "layer" has to be used, specifically in combination "transport
>>> layer".
>>>>     To me as, the word "transport layer" (and "transport protocol")
>>> should be
>>>>     used for protocols defined in TSV area, consistent with RFC 1122.
>>> But this is
>>>>     probably a question to be sorted out by the IESG.
>>>>
>>>> * Page 9
>>>>
>>>>      A DetNet node may have other resources requiring allocation
>>> and/or
>>>>      scheduling,
>>>>
>>>>     This is just one of several examples for inconsistent use of
>>> terminology.
>>>>     What is a "DetNet node"? That term is not introduced in Section
>>> 2.1
>>>> * Page 14
>>>>
>>>>      A DetNet network supports the dedication of a high proportion
>>> (e.g.
>>>>      75%) of the network bandwidth to DetNet flows.
>>>>
>>>>     The 75% value is not reasoned. What prevents using 99% of the
>>> bandwidth for
>>>>     DetNet traffic?
>>>>
>>>> * Page 15: Figure 2
>>>>
>>>>     If the term "transport layer" cannot be avoided, the labels in
>>> this figure
>>>>     should at least be expanded to "DetNet transport layer".
>>>>
>>>> * Page 18: Figure 4
>>>>
>>>>     As already mentioned earlier, Figure 4 is confusing. UDP is a
>>> transport
>>>>     protocol. If the term "transport" cannot be avoided, the labels in
>>> this
>>>>     figure should at least be expanded to "DetNet transport".
>>>>
>>>> * Page 23
>>>>
>>>>      If the source transmits less data than this limit
>>>>      allows, the unused resource such as link bandwidth can be made
>>>>      available by the system to non-DetNet packets.
>>>>
>>>>     Could there be additional requirements on the use of unused
>>> resources by
>>>>     non-DetNet packets, e.g., regarding preemption? I am just
>>> wondering... If
>>>>     that was possible, a statement like "... can be made available by
>>> the system
>>>>     to non-DetNet packets as long as all guarantees are fulfilled"
>>> would be on
>>>>     the safe side, no?
>>>>
>>>> * Page 27:
>>>>
>>>>      DetNet achieves congestion protection and bounded delivery
>>> latency by
>>>>      reserving bandwidth and buffer resources at every hop along the
>>> path
>>>>      of the DetNet flow.
>>>>
>>>>     Why does this sentence use the word "hop"? As far as I understand,
>>> in DetNet
>>>>     bandwidth and buffer resources are reserved in each DetNet
>>> intermediate node.
>>>>     If there were hops over IP routers not being DetNet intermediate
>>> nodes, no
>>>>     resources would be reserved there. As per Section 4.3.3, it is
>>> possible to
>>>>     deploy DetNet this way. And obviously there can be resource
>>> bottlenecks below
>>>>     IP, on devices that are not routers... So does "hop" here refer to
>>> IP router
>>>>     hops or also to devices not processing IP (or IP/MPLS)?
>>>>
>>>> * Page 27:
>>>>
>>>>      Standard queuing and transmission selection algorithms allow a
>>>>      central controller to compute the latency contribution of each
>>>>      transit node to the end-to-end latency, ...
>>>>
>>>>     The text does not explain why a _central_ controller is needed for
>>> this
>>>>     computation. Why would a distributed control plane not be able to
>>> realize
>>>>     this computation. Isn't this implementation-specific?
>>>>
>>>> * Page 32
>>>>
>>>>     To somebody who is not deeply familiar with DetNet, it is
>>> impossible to parse
>>>>     the description of the examples in Section 4.7.3. For instance,
>>> "VID +
>>>>     multicast MAC address" is not introduced. I think this example
>>> must be
>>>>     expaned with additional context and explanation to be useful to
>>> readers.
>>>> * Page 34
>>>>
>>>>      There are three classes of information that a central controller
>>> or
>>>>      distributed control plane needs to know that can only be obtained
>>>>      from the end systems and/or nodes in the network.
>>>>
>>>>     Wouldn't it be sufficient to state "Provisioning of DetNet
>>> requires knowledge
>>>>     about ...". Does it matter in this context whether the
>>> provisioning is done
>>>>     by a central controller or a distributed control plane? For
>>> instance, could
>>>>     the same paragraph also apply to a network that uses _multiple_
>>> central
>>>>     controllers, or hybrid combinations of central controllers and
>>> distributed
>>>>     control planes? In general, an architecture document should be
>>> agnostic to
>>>>     implementation aspects unless there is a specific need. In this
>>> specific
>>>>     case, I fail to see a need to discuss the realization of the
>>> control plane of
>>>>     a network.
>>>>
>>>> Editorial nits:
>>>>
>>>> * Page 9:
>>>>
>>>>      The low-level mechanisms described in Section 4.5 provide the
>>>>      necessary regulation of transmissions by an end system or
>>>>      intermediate node to provide congestion protection. The
>>> allocation
>>>>      of the bandwidth and buffers for a DetNet flow requires
>>> provisioning
>>>>      A DetNet node may have other resources requiring allocation
>>> and/or
>>>>      scheduling, that might otherwise be over-subscribed and trigger
>>> the
>>>>      rejection of a reservation.
>>>>
>>>>     Probably a full stop is missing after "provisioning".
>>>>
>>>> * Page 11: "... along separate (disjoint non-SRLG) paths ..."
>>>>
>>>>     I find this confusing. I would understand e.g. "along separate
>>>>     (SRLG-disjoint) paths".
>>>>
>>>> * Page 34:
>>>>
>>>>      When using a peer-
>>>>      to-peer control plane, some of this information may be required
>>> by a
>>>>      system's neighbors in the network.
>>>>
>>>>     Would "acquired" be a better term?
>>>>
>>>> * Page 34:
>>>>
>>>>      o  The identity of the system's neighbors, and the
>>> characteristics of
>>>>         the link(s) between the systems, including the length (in
>>>>         nanoseconds) of the link(s).
>>>>
>>>>     "Latency" or "delay" would probably be a better terms if the value
>>> is
>>>>     measured in nanoseconds.
>>>>
>>>> * Page 35:
>>>>
>>>>      DetNet is provides a Quality of Service (QoS), and as such, does
>>> not
>>>>      directly raise any new privacy considerations.
>>>>
>>>>     Broken sentence
>>>>
>>>> * Please expand acronyms on first use (e.g., OTN)
>>>>
>>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Dec 2018 14:47:30 +0000

The problem János is that we do not only avoid loss. We also control latency. So "queuing loss" is too limitation.
We are protecting the resources that are necessary, or providing guarantees that they are available. To provide the service.
Maybe "service guarantees" could be good?
Pascal 

> From: János Farkas <[email-masked]>
> Sent: lundi 10 décembre 2018 18:30
> To: Lou Berger <[email-masked]>; Scharf, Michael <Michael.Scharf@hs-
> esslingen.de>
> Cc: [email-masked]; [email-masked]; draft-ietf-detnet-
> [email-masked]
> Subject: Congestion Protection name change (was: Re: [Detnet] Tsvart last call
> review of draft-ietf-detnet-architecture-08)
> 
> Hi,
> 
> We wanted to have a brief collective term for the mechanisms used to avoid
> queuing related packet loss (including buffer overflow etc.).
> 
> ("Service Protection" is another DetNet term, hence we may consider a term
> without "protection" to minimize confusion.)
> 
> After agreeing in the terminology cahnge (if any), the text has to be updated
> accordingly.
> 
> What do you think?
> 
> Best regards,
> Janos
> 
> 
> >>> where we are.   I know that the authors have sent a -09 version that
> >>> addresses some, but not all issues.
> >>>
> >>> congestion would be inelastic traffic using DetNet or due to
> >>> congestion loss that is masked by PREOF.
> >>> basically a Traffic Engineered sub-network layer, such as is
> >>> provided with MPLS-TE or Optical Transport Networks.
> >>>> (draft-ietf-detnet-architecture-08) defines an overall framework
> >>>> for Deterministic Networking.
> >>>>
> >>>> security considerations only briefly mention the control aspect
> >>>> ("the authentication and authorization of the controlling systems").
> >>>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Dec 2018 10:28:16 -0500

Since we're guaranteeing a particular level of service as generally used in
SLAs, I would prefer the term "service level guarantee", which includes
bounds on packet delay and packet loss.

If we want, we can extend the definition to include examples of the
mechanisms used to provide the guarantee, such as queue management, link
and node resource management, shaping, preemption, scheduling, and so on,
but we don't have to.

Cheers,
Andy

On Mon, Dec 10, 2018 at 9:48 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> The problem János is that we do not only avoid loss. We also control
> latency. So "queuing loss" is too limitation.
> We are protecting the resources that are necessary, or providing
> guarantees that they are available. To provide the service.
> avoid
> term
> updated

---

From: Lou Berger <[email-masked]>
Date: Mon, 10 Dec 2018 12:15:59 -0500

Fwiw in the te world, we normally call this "resource allocation". As a 
contributor, I'd be comfortable with that term or "resource management".

Lou

----------

---

From: János Farkas <[email-masked]>
Date: Mon, 10 Dec 2018 18:58:59 +0100

I'm of course open to other alternatives. I'm interested to avoid the 
confusion; just proposed an initial idea.
I'm afraid we won't find the ideal term, but it would be good to have a 
good enough one.

> Maybe "service guarantees" could be good?
I know, and it is also there in the document:

"   Congestion protection addresses two of the DetNet QoS requirements:
    latency and packet loss.  Given that DetNet nodes have a finite
    amount of buffer space, congestion protection necessarily results in
    a maximum end-to-end latency.  It also addresses the largest
    contribution to packet loss, which is buffer congestion."

also:
"   The low-level mechanisms described in Section 4.5 provide the
    necessary regulation of transmissions by an end system or DetNet node
    to provide congestion protection.  The allocation of the bandwidth
    and buffers for a DetNet flow requires provisioning.  A DetNet node
    may have other resources requiring allocation and/or scheduling, that
    might otherwise be over-subscribed and trigger the rejection of a
    reservation."

In other words, we need adequate queuing mechanism with appropriate 
queue management plus resource allocation.

On 12/10/2018 6:15 PM, Lou Berger wrote:
> Fwiw in the te world, we normally call this "resource allocation". As 
> a contributor, I'd be comfortable with that term or "resource 
> management".

I'd prefer "resource management" out of these two because I can talk 
into it that it is the combination of "resource allocation" and queue 
management".

Thanks,
Janos

>>>>>> ("the

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Dec 2018 01:40:28 +0000

> >>     maximum packet size and transmission rate.  

> >> avoid queuing related packet loss (including buffer overflow etc.).

Perhaps "flow protection" as it protects individual flows and is configured/administered/managed at flow granularity??

The use of the word "resource" proposed below seems easy to mis-read as involving resources beyond the flow-by-flow scope of this functionality.

Thanks, --David

> From: detnet [mailto:[email-masked]] On Behalf Of János Farkas
> Sent: Monday, December 10, 2018 12:59 PM
> To: Lou Berger
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Detnet] Congestion Protection name change
> 
> 
> [EXTERNAL EMAIL]
> 
> >>>>>> severely and permantly congest a network and cause harm. How
> does
> >>>>>> the
> >>>>> DetNet
> >>>>>> The document introduces terms such as "DetNet intermediate
> nodes"
> >>>>>> but
> >>>>> then

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Dec 2018 04:21:23 +0000

"Flow Protection" looks good to me too...

> From: Black, David <[email-masked]>
> Sent: mardi 11 décembre 2018 05:40
> To: János Farkas <[email-masked]>; Lou Berger <[email-masked]>
> Subject: RE: [Detnet] Congestion Protection name change
> 
> > >> We wanted to have a brief collective term for the mechanisms used
> > >> to avoid queuing related packet loss (including buffer overflow etc.).
> 
> Perhaps "flow protection" as it protects individual flows and is
> configured/administered/managed at flow granularity??
> 
> The use of the word "resource" proposed below seems easy to mis-read as
> involving resources beyond the flow-by-flow scope of this functionality.
> 
> Thanks, --David
> 
> 
> > I'm afraid we won't find the ideal term, but it would be good to have
> > a good enough one.
> >
> > > Fwiw in the te world, we normally call this "resource allocation".
> > > As a contributor, I'd be comfortable with that term or "resource
> > > management".
> >
> > >> We wanted to have a brief collective term for the mechanisms used
> > >> to avoid queuing related packet loss (including buffer overflow etc.).
> > >>
> > >> Based on the discussions, we should have a term that does not
> > >> include "congestion".
> > >> ("Service Protection" is another DetNet term, hence we may consider
> > >> a term without "protection" to minimize confusion.)
> > >>
> > >> After agreeing in the terminology cahnge (if any), the text has to
> > >> be updated accordingly.
> > >>
> > >> What do you think?
> > >>
> > >> Best regards,
> > >> Janos
> > >>
> > >>
> > >>> is actually done within a DetNet and the relationship with
> > >>> transport protocols that use detnet (which are in fact outside the
> > >>> scope of the DetNet WG).  I'll work with the authors and WG on
> > >>> this -- I see this change as important, but editorial in nature.
> > >>>
> > >>> - We have a perception issue with at least one member of the TSV
> > >>> area on the meaning and more importantly, implication, of the term
> > >>> "DetNet
> > >>> *Transport* sub-layer".  While I don't disagree that a good
> > >>> portion of the IETF thinks transport protocol (UDP/TCP) when they
> > >>> hear "transport" there are plenty others, particularly in the
> > >>> routing area, who understand that "transport" can refer to
> > >>> Transport Networks.  And Transport Network is a well understood
> > >>> general industry term. The IETF even has a bunch of RFCs that
> > >>> relate to Transport networks. This said, I think it reasonable to
> > >>> go back to the DetNet WG and discuss changing the name of the
> > >>> "DetNet Transport sub-layer"  to avoid the word "transport".  --
> > >>> BTW we made a parallel change in the TEAS WG when producing
> RFC8453.
> > >>>
> > >>>>> I wanted to take a step back from the multiple discussions that
> > >>>>> were spawned by your review -- from a doc shepherd perspective,
> > >>>>> and see where we are.   I know that the authors have sent a -09
> > >>>>> version that addresses some, but not all issues.
> > >>>>>
> > >>>>>   From the exchanges I've seen, I think the key remaining issues
> > >>>>> are related to:
> > >>>>>
> > >>>>> (a) possibly introduction of congestion in the general internet
> > >>>>> if packets were somehow to escape a detnet domain.  The source
> > >>>>> of
> > this
> > >>>> These are two major issues that need to be addressed. Note that
> > >>>> it may not be sufficient just to add a section on operational and
> > >>>> In -09, one example would be Section 3.1. "Primary goals defining
> > >>>> the DetNet QoS"
> > >>>>
> > >>>> At least the last sentence would contradict a better discussion
> > >>>> of congestion in the document. For instance, it could just be removed.
> > >>>> In any case, the current wording in the last sentence is not
> > >>>> correct, as the IETF term for what is described in the last
> > >>>> sentence is "congestion control".
> > >>>>
> > >>>>       The primary means by which DetNet achieves its QoS
> > >>>> assurances is to
> > >>>>     reduce, or even completely eliminate, congestion within a
> > >>>> DetNet node
> > >>>>     network to ensure that no packets are dropped due to a lack
> > >>>> of buffer
> > >>>> This section IMHO has to include a discussion of what happens in
> > >>>> the (not expected) case that packets get dropped or that ECN
> > >>>> marks are received. It is understood that this would not happen
> > >>>> in normal operation of a DetNet network, but I believe just
> > >>>> considering the error-free operation of a DetNet network is not
> > >>>> sufficient for this document. At least for the risk of traffic
> > >>>> that may escape from a DetNet network is inherently not
> > >>>> sufficient to assume that the DetNet network is always error-free.
> > >>>
> > >>> I think these are examples of text that needs to be cleanup up and
> > >>> to delineate what is done with a DetNet.
> > >>>
> > >>>
> > >>>> As a result, addressing my concerns will most likely require
> > >>>> editing several parts of the document.
> > >>>>
> > >>>> surprising that there is hardly any discussion on network
> > >>>> robustness and safety"
> > >>>
> > >>>> covers more than just inelastic traffic that escapes from a
> > >>>> DetNet network and masking of packet loss. Given that DetNet
> > >>>> traffic may be extremely critical traffic, I really wonder why
> > >>>> the document doesn't emphasize more the required robustness
> > >>>> against failures *inside* the DetNet network as well as
> > >>>> counter-measures. But this is something the WG needs to decide.
> > >>>> As TSV-ART reviewer, I will be fine if the document clearly
> > >>>> describes how the impact of failures will be isolated inside the
> > >>>> DetNet network and will not put the general Internet at risk.
> > >>>
> > >>>>> (b) The use of the term 'transport' in DetNet to refer to what
> > >>>>> is basically a Traffic Engineered sub-network layer, such as is
> > >>>> In the Internet architecture, the term 'transport' refers to
> > >>>> Internet transport protocols. I doubt that the document can avoid
> > >>>> discussing the implications of and interactions with Internet
> > >>>> transport protocols such as UDP or TCP. As a result, I disagree
> > >>>> that the document can use the term 'transport' to refer to
> > >>>> traffic engineered sub-network layers.
> > >>>
> > >>>>  From a TSV-ART point of view, the document can either only use
> > >>>> the term "transport" for Internet transport protocols and use
> > >>>> another term for sub-network layers (as handled in the *routing*
> > >>>> area of the IETF), or the document has to clearly distinguish
> > >>>> between the Internet transport layer and other uses of the term
> > >>>> "transport" and explain the overlap. I believe the former would
> > >>>> be less confusing, but I will leave it up to the TSV ADs to
> > >>>> discuss terminology overlap in the IESG. As TSV-ART reviewer I
> > >>>> insist that the document uses the terms "transport layer" and
> > >>>> "transport protocol" only when referring to the Internet transport layer.
> > >>>
> > >>> I'm personally okay with a name change and even willing to push
> > >>> this discussion within the WG, but as said above, "Transport
> > >>> Network" is a generally understood industry term that is also used
> > >>> in RFCs -- so we'll have to see what where WG consensus ends up.
> > >>>
> > >>>>
> > >>>>> Do you have any other issues that that are critical to be
> > >>>>> addressed before this work moves forward?  If so which?
> > >>>> Regarding Section 4.4 I have already deferred the discussion to
> > >>>> the IESG. The TSV-ART review comment is that the IESG needs to
> > >>>> carefully look at the concepts, terminology, and references in section
> 4.4.
> > >>>>
> > >>>> forward. But given the cross-dependencies e.g. regarding
> > >>>> terminology and definitions, I will need to read the text
> > >>>> completely once there is a proposal how to address my review. As
> > >>>> noted in my review, I believe the document must use terminology
> clearly and consistently.
> > >>>> DetNet flows have to implement some of the DetNet capabilities
> > >>>> (not necessarily all) in order to treat DetNet flows such that
> > >>>> their QoS requirements are met" is IMHO too vague. But in such
> > >>>> cases it depends whether there is precise normative guidance
> > >>>> elsewhere. And this requires looking at the text as a whole.
> > >>>
> > >>> once there is a new version.  Of course, you can also contribute
> > >>> to the WG discussion on the topic.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Lou
> > >>>
> > >>>>
> > >>>> Best regards
> > >>>>
> > >>>> Michael
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Thank you,
> > >>>>>
> > >>>>> Lou
> > >>>>>
> > >>>>>> (draft-ietf-detnet-architecture-08) defines an overall
> > >>>>>> framework for Deterministic Networking.
> > >>>>>>
> > >>>>>> and safety; this probably also relates to security. For
> > >>>>>> instance, misconfiguration or errors of functions performing
> > >>>>>> packet replication
> > >>>>> could
> > >>>>>> * Somewhat related, the document only looks at impact of
> > >>>>>> failures
> > to
> > >>>>> the QoS of
> > >>>>>> "The primary means by which DetNet achieves its QoS assurances
> > >>>>>> is
> > to
> > >>>>> reduce, or
> > >>>>>> other related work as well, e.g., in the TEAS WG. Second,
> > >>>>>> Section
> > >>>>>> 4.4
> > >>>>> is by and

---

From: "qiangli (D)" <[email-masked]>
Date: Tue, 11 Dec 2018 04:57:41 +0000

Current service layer focuses on packet loss control, no or nearly no delay control solutions. My personal feeling is --- it’s inappropriate to name a packet loss control focused layer with “detnet service layer” or “detnet service level guarantee layer”.

Best regards,

Cristina QIANG

From: detnet [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Monday, December 10, 2018 11:28 PM
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; [email-masked]; János Farkas <[email-masked]>; Transport Area Review Team <[email-masked]>; detnet WG <[email-masked]>
Subject: Re: [Detnet] Congestion Protection name change (was: Re: Tsvart last call review of draft-ietf-detnet-architecture-08)

Since we're guaranteeing a particular level of service as generally used in SLAs, I would prefer the term "service level guarantee", which includes bounds on packet delay and packet loss.

If we want, we can extend the definition to include examples of the mechanisms used to provide the guarantee, such as queue management, link and node resource management, shaping, preemption, scheduling, and so on, but we don't have to.

Cheers,
Andy

On Mon, Dec 10, 2018 at 9:48 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
The problem János is that we do not only avoid loss. We also control latency. So "queuing loss" is too limitation.
We are protecting the resources that are necessary, or providing guarantees that they are available. To provide the service.
Maybe "service guarantees" could be good?
Pascal

> From: János Farkas <[email-masked]<mailto:[email-masked]>>
> To: Lou Berger <[email-masked]<mailto:[email-masked]>>; Scharf, Michael <Michael.Scharf@hs-
<mailto:Michael.Scharf@hs-%0b>> esslingen.de<http://esslingen.de>>
> Cc: tsv-art@ietf..org<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-detnet-
> [email-masked]<mailto:[email-masked]>

---

From: "qiangli (D)" <[email-masked]>
Date: Tue, 11 Dec 2018 05:17:24 +0000

I am afraid flow-grained operations will face with scalability problem, and flow-protection may limit some tunnel like or other possible solutions. How about using "DetNet packet loss control layer" to replace current " service sub-layer", similarly using "DetNet delay control layer" to replace current "transport sub-layer"? Just a suggestion ;-)

Best regards,

Cristina QIANG

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, December 11, 2018 12:21 PM
To: Black, David <[email-masked]>; János Farkas <[email-masked]>; Lou Berger <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Detnet] Congestion Protection name change

> The use of the word "resource" proposed below seems easy to mis-read 
> as involving resources beyond the flow-by-flow scope of this functionality.
> 
> Thanks, --David
> 
> 
> > I'm of course open to other alternatives. I'm interested to avoid 
> > the confusion; just proposed an initial idea.
> > I'm afraid we won't find the ideal term, but it would be good to 
> > have a good enough one.
> >
> > into it that it is the combination of "resource allocation" and 
> > queue management".
> >
> > Thanks,
> > Janos
> >
> >
> > >
> > > Lou
> > >
> > >
> > >
> > > ----------
> > >> ("Service Protection" is another DetNet term, hence we may 
> > >> consider a term without "protection" to minimize confusion.)
> > >>
> > >> After agreeing in the terminology cahnge (if any), the text has 
> > >> to be updated accordingly.
> > >>
> > >> What do you think?
> > >>
> > >> Best regards,
> > >> Janos
> > >>
> > >>
> > >>> disconnects and what may (and what may not) need to change in 
> > >>> the document.  My takeaways are:
> > >>>
> > >>> transport protocols that use detnet (which are in fact outside 
> > >>> the scope of the DetNet WG).  I'll work with the authors and WG 
> > >>> on this -- I see this change as important, but editorial in nature.
> > >>>
> > >>> area on the meaning and more importantly, implication, of the 
> > >>> term "DetNet
> > >>> portion of the IETF thinks transport protocol (UDP/TCP) when 
> > >>> they hear "transport" there are plenty others, particularly in 
> > >>> the routing area, who understand that "transport" can refer to 
> > >>> relate to Transport networks. This said, I think it reasonable 
> > >>> to go back to the DetNet WG and discuss changing the name of the 
> > >>>>> I wanted to take a step back from the multiple discussions 
> > >>>>> that were spawned by your review -- from a doc shepherd 
> > >>>>> perspective, and see where we are.   I know that the authors 
> > >>>>> have sent a -09 version that addresses some, but not all issues.
> > >>>>>
> > >>>>>   From the exchanges I've seen, I think the key remaining 
> > >>>>> issues are related to:
> > >>>>>
> > >>>>> (a) possibly introduction of congestion in the general 
> > >>>>> internet if packets were somehow to escape a detnet domain.  
> > >>>>> The source of
> > this
> > >>>> it may not be sufficient just to add a section on operational 
> > >>>> and deployment considerations. Also the existing text in the 
> > >>>> document will need to get aligned to normative guidance on how 
> > >>>> to avoid a congestion collapse.
> > >>>>
> > >>>> In -09, one example would be Section 3.1. "Primary goals 
> > >>>> defining the DetNet QoS"
> > >>>>
> > >>>> This section IMHO has to include a discussion of what happens 
> > >>>> in the (not expected) case that packets get dropped or that ECN 
> > >>> I think these are examples of text that needs to be cleanup up 
> > >>> and to delineate what is done with a DetNet.
> > >>>
> > >>>
> > >>>> In addition, I'd like to emphasize that my review comment "It 
> > >>>> is surprising that there is hardly any discussion on network 
> > >>>> robustness and safety"
> > >>>
> > >>>> describes how the impact of failures will be isolated inside 
> > >>>> the DetNet network and will not put the general Internet at risk.
> > >>>
> > >>> I agree - I think, the document should be clear on it's scope 
> > >>> and relationship to general internet usage.
> > >>>
> > >>>
> > >>>>
> > >>>>> is basically a Traffic Engineered sub-network layer, such as 
> > >>>>> is provided with MPLS-TE or Optical Transport Networks.
> > >>>> Internet transport protocols. I doubt that the document can 
> > >>>> avoid discussing the implications of and interactions with 
> > >>>> Internet transport protocols such as UDP or TCP. As a result, I 
> > >>>> disagree that the document can use the term 'transport' to 
> > >>>> refer to traffic engineered sub-network layers.
> > >>>
> > >>>> another term for sub-network layers (as handled in the 
> > >>>> *routing* area of the IETF), or the document has to clearly 
> > >>>> distinguish between the Internet transport layer and other uses 
> > >>>> of the term "transport" and explain the overlap. I believe the 
> > >>>> former would be less confusing, but I will leave it up to the 
> > >>>> TSV ADs to discuss terminology overlap in the IESG. As TSV-ART 
> > >>>> reviewer I insist that the document uses the terms "transport 
> > >>>> layer" and "transport protocol" only when referring to the Internet transport layer.
> > >>>
> > >>> Network" is a generally understood industry term that is also 
> > >>> used in RFCs -- so we'll have to see what where WG consensus ends up.
> > >>>
> > >>>>
> > >>>> completely once there is a proposal how to address my review. 
> > >>>> As noted in my review, I believe the document must use 
> > >>>> terminology
> > >>>> As example, a statement in -09 such as "Network nodes 
> > >>>> supporting DetNet flows have to implement some of the DetNet 
> > >>>> capabilities (not necessarily all) in order to treat DetNet 
> > >>>> flows such that their QoS requirements are met" is IMHO too 
> > >>>> vague. But in such cases it depends whether there is precise 
> > >>>> normative guidance elsewhere. And this requires looking at the text as a whole.
> > >>>
> > >>> I think the next steps lie with me and the WG.  We'll let you 
> > >>> know once there is a new version.  Of course, you can also 
> > >>> contribute to the WG discussion on the topic.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Lou
> > >>>
> > >>>>
> > >>>> Best regards
> > >>>>
> > >>>> Michael
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Thank you,
> > >>>>>
> > >>>>> Lou
> > >>>>>
> > >>>>>> DetNet traffic. What is missing is a discussion how to 
> > >>>>>> protect
> > >>>>>> non-
> > >>>>> DetNet parts
> > >>>>>> security considerations only briefly mention the control 
> > >>>>>> aspect ("the authentication and authorization of the 
> > >>>>>> controlling systems").
> > >>>>>>
> > >>>>>> "The primary means by which DetNet achieves its QoS 
> > >>>>>> assurances is
> > to
> > >>>>> reduce, or

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 11 Dec 2018 07:20:31 +0000

Hi,

"queuing loss avoidance".

I am partly with You. I think the to include the term "flow" is a good idea. 
David has right, here we are focusing on flows.

However I have problems with the "protection" part of the term, due to other
terminology we have already defined, namely service protection (e.g., PREOF).
I think for many people "DetNet" + "protection" = "PREOF".

> to avoid queuing related packet loss (including buffer overflow etc.).
and Pascal extended:
- and at the same time we want to fulfill the latency requirement of the flow.

So, let's lists the functions we intend to describe with the term:
- selecting queuing method used and the queue used by the flow
- properly configuring queue parameters (e.g., egress speed, queue size, etc.), 
based on latency and (zero) loss requirements for the flow/hop

A possible way to put all these pieces together:
"flow queuing regulation " or "flow queuing management"

Any thoughts?

Cheers
Bala'zs

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Dec 2018 06:42:51 -0500

Isn't an angregate of (e.g., 6-tuple) flows still a flow, just like an lsp 
that carries other lsps is still an LSP?

Lou

----------
On December 11, 2018 12:18:14 AM "qiangli (D)" <[email-masked]> wrote:

> I am afraid flow-grained operations will face with scalability problem, and 
> flow-protection may limit some tunnel like or other possible solutions. How 
> about using "DetNet packet loss control layer" to replace current " service 
> sub-layer", similarly using "DetNet delay control layer" to replace current 
> "transport sub-layer"? Just a suggestion ;-)
>
> Best regards,
>
> Cristina QIANG
>
> To: Black, David <[email-masked]>; János Farkas 
> <[email-masked]>; Lou Berger <[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Dec 2018 06:45:32 -0500

Balázs,

In some systems that work on  more than just queue management is needed, so 
I personally feel pretty strongly that we should not include the word 
queue. How about:

'flow management'

Lou

----------
On December 11, 2018 2:21:19 AM Balázs Varga A 
<[email-masked]> wrote:

> To: Black, David <[email-masked]>; Janos Farkas 
> <[email-masked]>; Lou Berger <[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Dec 2018 11:58:30 +0000

Management looks like control plane, Lou, don’t you think?
David’s flow protection also indicates the interesting security properties that we are effectively bringing in...

Regards,

Pascal

> Le 11 déc. 2018 à 15:45, Lou Berger <[email-masked]> a écrit :
> 
> Balázs,
> 
> In some systems that work on  more than just queue management is needed, so I personally feel pretty strongly that we should not include the word queue. How about:
> 
> 'flow management'
> 
> Lou
> 
> 
> 
> ----------
>> On December 11, 2018 2:21:19 AM Balázs Varga A <[email-masked]> wrote:
>> 
>> Hi,
>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 11 Dec 2018 07:39:46 -0500

Protection has very specific meaning in transport networks and I think 
would lead to great confusion.

I see no issue with the term management implying control(er) plane, as 
there will be some level of control here whether it be centralized or 
distributed.

This whole discussion is sort of why 'resource allocation' ended up being 
used in the TE context.  If that term and 'flow management' don't work, I 
think 'resource management' is at the top of my personal list.

Lou

----------
On December 11, 2018 6:59:26 AM "Pascal Thubert (pthubert)"

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 11 Dec 2018 15:30:18 +0000

> we can consider "DetNet Forwarding Adaptation sub-layer".

I have just read through the thread.

Transport Network was the term that ITU taught us to use for this 
functionality when we did the MPLS-TP work and it describes the concept 
well.

Detnet Forwarding layer works, although I am concerned that there will 
be other aspects of the layer that it will not describe well. It does 
after all need to be a complete layer control and OAM.

An alternative to "Transport" that does not conflict with "Transport 
Layer" in the IETF sense is "Bearer".

Regards

Stewart

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Dec 2018 12:46:55 -0500

Hi,

     My reading is that the WG has settled on:

       +----------------------------+
       |  DetNet Service sub-layer  | PW, UDP, GRE
       +----------------------------+
       | DetNet Forwarding sub-layer| IPv6, IPv4, MPLS TE LSPs, MPLS SR
       +----------------------------+
                     .
                     .

Authors, (of detnet-architecture)
     Please work to have the next rev of the draft reflect this change.

Thank you to all who participated in the discussion!
Lou
(as co-chair and doc shepherd)

On 11/20/2018 1:18 PM, Lou Berger wrote:
> ALL,
>
> There is a desire to replace the word "Transport" from the DetNet
> Transport sub-layer to avoid confusion with L$ Transport protocols.
>
> In the TEAS WG we had a similar discussion and we replaced "Transport"
> While a bit more verbose, what do people think about this change?
>
>        | DetNet Transport sub-layer | IPv6, IPv4, MPLS TE LSPs, MPLS SR
>        |      DetNet TE sub-layer   | IPv6, IPv4, MPLS TE LSPs, MPLS SR
> On 11/20/2018 11:21 AM, Pascal Thubert (pthubert) wrote:
>> Hello Lou:
>>
>>
>> About ' discuss changing the name of the "DetNet Transport sub-layer"  to avoid the word "transport".  '
>>
>> For one I'd like to make that call. The unfortunate name collision has started to hurt us quite a bit already and people are getting confused on very active exchanges we have on the mailing list.
>>
>> I tend to agree that for the general IETF "transport" generally means "L4". Even point one in your email uses "transport" that way I guess. Sadly many alternate names are highly overloaded already (think "carrier" for instance, or "bus"). I like the term "train" because of the association with a schedule, but that's just me.
>>
>> Same goes actually for the complex path that we build. That complex path can be an elongated DODAG with multiple PREOF points. Usual terms like "circuit" or "path" fail to capture that complexity. 6TiSCH found the term "Track" to refer to it.
>>
>> Would you push that discussion to the ML?
>>
>> Take care,
>>
>> Pascal
>>
>>> From: Lou Berger <[email-masked]>
>>> Sent: mardi 20 novembre 2018 13:11
>>> To: Scharf, Michael <[email-masked]>
>>> Subject: Re: [Detnet] Tsvart last call review of draft-ietf-detnet-architecture-08
>>>
>>> Michael,
>>>
>>> I think we're getting somewhere and identifying where we have disconnects
>>> and what may (and what may not) need to change in the document.  My
>>> takeaways are:
>>>
>>> - The document needs a good 'scrub' of the congestion related references to
>>> ensure that the document only makes statements on what is actually done
>>> within a DetNet and the relationship with transport protocols that use detnet
>>> (which are in fact outside the scope of the DetNet WG).  I'll work with the
>>> authors and WG on this -- I see this change as important, but editorial in
>>> nature.
>>>
>>> - We have a perception issue with at least one member of the TSV area on the
>>> meaning and more importantly, implication, of the term "DetNet
>>> *Transport* sub-layer".  While I don't disagree that a good portion of the IETF
>>> thinks transport protocol (UDP/TCP) when they hear "transport"
>>> there are plenty others, particularly in the routing area, who understand that
>>> "transport" can refer to Transport Networks.  And Transport Network is a well
>>> understood general industry term. The IETF even has a bunch of RFCs that
>>> relate to Transport networks.  This said, I think it reasonable to go back to the
>>> DetNet WG and discuss changing the name of the "DetNet Transport sub-
>>> layer"  to avoid the word "transport".  -- BTW we made a parallel change in
>>> the TEAS WG when producing RFC8453.
>>>
>>>> These are two major issues that need to be addressed. Note that it may not
>>> be sufficient just to add a section on operational and deployment
>>> considerations. Also the existing text in the document will need to get aligned
>>> to normative guidance on how to avoid a congestion collapse.
>>>> At least the last sentence would contradict a better discussion of congestion
>>> in the document. For instance, it could just be removed. In any case, the
>>> current wording in the last sentence is not correct, as the IETF term for what is
>>> described in the last sentence is "congestion control".
>>>>       The primary means by which DetNet achieves its QoS assurances is to
>>>>       reduce, or even completely eliminate, congestion within a DetNet node
>>>>       network to ensure that no packets are dropped due to a lack of buffer
>>>> This section IMHO has to include a discussion of what happens in the (not
>>> expected) case that packets get dropped or that ECN marks are received. It is
>>> understood that this would not happen in normal operation of a DetNet
>>> network, but I believe just considering the error-free operation of a DetNet
>>> network is not sufficient for this document. At least for the risk of traffic that
>>> may escape from a DetNet network is inherently not sufficient to assume that
>>> the DetNet network is always error-free.
>>>
>>>> As a result, addressing my concerns will most likely require editing several
>>> parts of the document.
>>>> In addition, I'd like to emphasize that my review comment "It is surprising
>>> that there is hardly any discussion on network robustness and safety"
>>>
>>>> covers more than just inelastic traffic that escapes from a DetNet network
>>> and masking of packet loss. Given that DetNet traffic may be extremely critical
>>> traffic, I really wonder why the document doesn't emphasize more the
>>> required robustness against failures *inside* the DetNet network as well as
>>> counter-measures. But this is something the WG needs to decide. As TSV-ART
>>> reviewer, I will be fine if the document clearly describes how the impact of
>>> failures will be isolated inside the DetNet network and will not put the general
>>> Internet at risk.
>>>
>>>> In the Internet architecture, the term 'transport' refers to Internet transport
>>> protocols. I doubt that the document can avoid discussing the implications of
>>> and interactions with Internet transport protocols such as UDP or TCP. As a
>>> result, I disagree that the document can use the term 'transport' to refer to
>>>>    From a TSV-ART point of view, the document can either only use the term
>>> "transport" for Internet transport protocols and use another term for sub-
>>> network layers (as handled in the *routing* area of the IETF), or the document
>>> has to clearly distinguish between the Internet transport layer and other uses
>>> of the term "transport" and explain the overlap. I believe the former would be
>>> less confusing, but I will leave it up to the TSV ADs to discuss terminology
>>> overlap in the IESG. As TSV-ART reviewer I insist that the document uses the
>>> terms "transport layer" and "transport protocol" only when referring to the
>>> Internet transport layer.
>>>
>>> generally understood industry term that is also used in RFCs -- so we'll
>>> have to see what where WG consensus ends up.
>>>
>>>> Regarding Section 4.4 I have already deferred the discussion to the IESG. The
>>> TSV-ART review comment is that the IESG needs to carefully look at the
>>> concepts, terminology, and references in section 4.4.
>>>> Regarding my other comments, I acknowledge that -09 is a step forward. But
>>> given the cross-dependencies e.g. regarding terminology and definitions, I will
>>> need to read the text completely once there is a proposal how to address my
>>> review. As noted in my review, I believe the document must use terminology
>>> clearly and consistently. As example, a statement in -09 such as "Network
>>> nodes supporting DetNet flows have to implement some of the DetNet
>>> capabilities (not necessarily all) in order to treat DetNet flows such that their
>>> QoS requirements are met" is IMHO too vague. But in such cases it depends
>>> whether there is precise normative guidance elsewhere. And this requires
>>> looking at the text as a whole.
>>>
>>> I think the next steps lie with me and the WG.  We'll let you know once
>>> there is a new version.  Of course, you can also contribute to the WG
>>> discussion on the topic.
>>>
>>> Thanks,
>>>
>>> Lou
>>>
>>>> Best regards
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>> Thank you,
>>>>>
>>>>> Lou
>>>>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Dec 2018 13:16:52 -0500

Lou,

I think we've discussed this before, but I wanted to confirm whether SRv6
is in scope for the DetNet Forwarding sub-layer.

Thanks,
Andy

On Thu, Dec 13, 2018 at 12:47 PM Lou Berger <[email-masked]> wrote:

> >> For one I'd like to make that call. The unfortunate name collision has
> started to hurt us quite a bit already and people are getting confused on
> very active exchanges we have on the mailing list.
> >>
> >> I tend to agree that for the general IETF "transport" generally means
> "L4". Even point one in your email uses "transport" that way I guess. Sadly
> many alternate names are highly overloaded already (think "carrier" for
> instance, or "bus"). I like the term "train" because of the association
> with a schedule, but that's just me.
> >>
> >> Same goes actually for the complex path that we build. That complex
> path can be an elongated DODAG with multiple PREOF points. Usual terms like
> "circuit" or "path" fail to capture that complexity. 6TiSCH found the term
> "Track" to refer to it.
> >>
> disconnects
> references to
> on the
> the IETF
> are
> may not
> congestion
> (not
> surprising
> network
> we'll
> IESG. The
> forward. But

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Dec 2018 13:07:39 -0500

All,

     I met with the authors of detnet-architecture to see if we could 
come up with a a single proposal.  The discussion led to three 
candidates (see below for ordered list).  In the interest of closing on 
this topic, I'd like to ask if there are *objections* to changing the 
term "Congestion protection" to "Resource allocation".  Looking at the 
related, first use, text in Section 3.2.1 this change would read 
something like:

    Three techniques are used by DetNet to provide these qualities of
    service:
    o  Resource allocation (Section 3.2.1).
    o  Service protection (Section 3.2.2).
    o  Explicit routes (Section 3.2.3).

    Resource allocation operates by assigning resources, e.g., buffer
    space or link bandwidth, to a DetNet flow (or flow aggregate) along
    its path.  Resource allocation greatly reduces, or even eliminates
    entirely, packet loss due to output packet contention within the
    network, but it can only be supplied to a DetNet flow that is limited
    at the source to a maximum packet size and transmission rate. Note
    that congestion control provided via congestion detection and
    notification [RFC3168] is explicitly excluded from consideration in
    DetNet, as it serves a different set of applications.

    Resource allocation addresses two of the DetNet QoS requirements:
    latency and packet loss.  Given that DetNet nodes have a finite
    amount of buffer space, Resource allocation necessarily results in
    a maximum end-to-end latency.  It also addresses contention related
    packet loss.

    Other important contribution to packet loss are random media errors
    and equipment failures...

Please respond, if you think this change (to 'resource allocation') is:
     (a) acceptable/something you can live with
     (b) unacceptable/something you think should not be part of the 
DetNet architecture

(Note: please wait for the author to revise the actual text above based 
on the outcome of this thread before providing edits.)

Thank you,
Lou
(as co-chair and shepherd)

The top three alternatives at the end of the meeting, in order were:
     1. Resource allocation
     2. Resource management
     3. Contention management

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Dec 2018 13:55:42 -0500

Hi Andy,

As SRv6 is implemented using an IPv6 routing header the figure below 
accurately shows IPv6 (and consequently SRv6) as being  part of the 
Forwarding sub-layer.

In case you were really asking if use of SRv6 is in  scope of DetNet WG, 
I don't see anything in the charter that would preclude the WG working 
on DetNet SRv6.

Lou

On 12/13/2018 1:16 PM, Andrew G. Malis wrote:
> Lou,
>
> I think we've discussed this before, but I wanted to confirm whether 
> SRv6 is in scope for the DetNet Forwarding sub-layer.
>
> Thanks,
> Andy
>
>
> On Thu, Dec 13, 2018 at 12:47 PM Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     >> About ' discuss changing the name of the "DetNet Transport
>     sub-layer"  to avoid the word "transport".  '
>     >>
>     >> For one I'd like to make that call. The unfortunate name
>     collision has started to hurt us quite a bit already and people
>     are getting confused on very active exchanges we have on the
>     mailing list.
>     >>
>     >> I tend to agree that for the general IETF "transport" generally
>     means "L4". Even point one in your email uses "transport" that way
>     I guess. Sadly many alternate names are highly overloaded already
>     (think "carrier" for instance, or "bus"). I like the term "train"
>     because of the association with a schedule, but that's just me.
>     >>
>     >> Same goes actually for the complex path that we build. That
>     complex path can be an elongated DODAG with multiple PREOF points.
>     Usual terms like "circuit" or "path" fail to capture that
>     complexity. 6TiSCH found the term "Track" to refer to it.
>     >>
>     >>> To: Scharf, Michael <[email-masked]
>     >>> Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; draft-ietf-detnet-
>     >>> [email-masked] <mailto:[email-masked]>
>     portion of the IETF
>     that were
>     issues are
>     internet if
>     defining the
>     in the (not
>     is surprising
>     DetNet network
>     provided
>     Internet transport
>     former would be
>     addressed
>     flows such that their
>     know once
>     instance,
>     failures to
>     protect non-
>     aspect ("the
>     nodes" but
>     Section 4.4
>     >>>> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Dec 2018 15:29:25 -0500

Lou,

Thanks, that's what I thought, but I didn't see it in your list of DetNet
Forwarding sub-layer protocols.

Cheers.
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Dec 2018 15:36:27 -0500

Lou,

I think of "Resource management" as a superset of "Resource allocation",
and so prefer "Resource management". That said, I can live with "Resource
allocation" if that comes out as the consensus.

Cheers,
Andy

---

From: John E Drake <[email-masked]>
Date: Thu, 13 Dec 2018 20:43:34 +0000

Hi,

I think Andy’s right.

Yours Irrespectively,

John

From: detnet <[email-masked]> On Behalf Of Andrew G. Malis
Sent: Thursday, December 13, 2018 3:36 PM
To: Lou Berger <[email-masked]>
Cc: [email-masked]; detnet WG <[email-masked]>; János Farkas <[email-masked]>; [email-masked]
Subject: Re: [Detnet] Congestion Protection name change

Lou,

I think of "Resource management" as a superset of "Resource allocation", and so prefer "Resource management". That said, I can live with "Resource allocation" if that comes out as the consensus.

Cheers,
Andy

On Thu, Dec 13, 2018 at 1:23 PM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
All,

    Resource allocation operates by assigning resources, e.g.., buffer

Thank you,
Lou

On 12/10/2018 9:29 AM, János Farkas wrote:
>>> look at the concepts, terminology, and references in section 4..4.
>>>
>>>>> of a network from any harm caused by DetNet mechanisms.. Solutions to
>>>> this
>>>>> and the document uses the concepts introduced there (e..g., "planes").
>>>> This is
>>>>>      protocols such as TCP and UDP.. As such, I personally find the term
>>>> "DetNet
>>>>>      The 75% value is not reasoned.. What prevents using 99% of the
>>>> bandwidth for
>>>>>      DetNet traffic?
>>>>>
>>>>> * Page 15: Figure 2
>>>>>
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=x-a2-FkxV9FVzoBPYqhki-d6dTr8aMoYOZvLBMQiZKI&s=CgPCouhIIjjXPe07LlcZrBdgRhKb5hckS1j78aaZztE&e=>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=x-a2-FkxV9FVzoBPYqhki-d6dTr8aMoYOZvLBMQiZKI&s=CgPCouhIIjjXPe07LlcZrBdgRhKb5hckS1j78aaZztE&e=>

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=x-a2-FkxV9FVzoBPYqhki-d6dTr8aMoYOZvLBMQiZKI&s=CgPCouhIIjjXPe07LlcZrBdgRhKb5hckS1j78aaZztE&e=>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Dec 2018 15:43:46 -0500

Lou,

Yes, but not SRv6 explicitly, as opposed to explicitly both MPLS TE LSPs
and SR-MPLS. But my question was answered, so I'm good! :-)

Thanks,
Andy

On Thu, Dec 13, 2018 at 3:41 PM Lou Berger <[email-masked]> wrote:

> IPv6 *is* there ;-)
>
> On 12/13/2018 3:29 PM, Andrew G. Malis wrote:
> > Lou,
> >
> > Thanks, that's what I thought, but I didn't see it in your list of
> > DetNet Forwarding sub-layer protocols.
> >
> > Cheers.
> > Andy
> >
> >
> > On Thu, Dec 13, 2018 at 1:55 PM Lou Berger <[email-masked]
> >     <mailto:[email-masked]>
> >     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     >>> From: Lou Berger <[email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>>
> >     <mailto:[email-masked]>
> >     >     <mailto:[email-masked]
> >     <mailto:[email-masked]>>>
> >     >     >>> Cc: [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>;
> >     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>; draft-ietf-detnet-
> >     <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]
> >>
> >     >     >>> within a DetNet and the relationship with transport
> >     protocols
> >     >     that use detnet
> >     >     >>> (which are in fact outside the scope of the DetNet WG).
> >     I'll
> >     >     work with the
> >     >     >>> authors and WG on this -- I see this change as
> >     important, but
> >     >     editorial in
> >     >     >>> nature.
> >     >     >>>
> >     >     >>> - We have a perception issue with at least one member of
> the
> >     >     TSV area on the
> >     >     >>> there are plenty others, particularly in the routing
> >     area, who
> >     >     understand that
> >     >     >>> understood general industry term. The IETF even has a
> >     bunch of
> >     >     RFCs that
> >     >     >>>>> spawned by your review -- from a doc shepherd
> perspective,
> >     >     and see
> >     >     >>>>> packets were somehow to escape a detnet domain.  The
> >     source
> >     >     of this
> >     >     >>>>       Congestion protection operates by allocating
> >     resources
> >     >     along the path
> >     >     >>>>       due to output packet congestion within the
> >     network, but
> >     >     it can only
> >     >     >>>>       maximum packet size and transmission rate.  Note
> that
> >     >     congestion
> >     >     >>>>       explicitly excluded from consideration in DetNet,
> >     as it
> >     >     serves a
> >     >     >>>>       reduce, or even completely eliminate, congestion
> >     within
> >     >     a DetNet node
> >     >     >>>>       network to ensure that no packets are dropped due
> >     to a
> >     >     lack of buffer
> >     >     >>>>       storage.  Note that a DetNet flow cannot be
> >     throttled,
> >     >     i.e., its
> >     >     >>> expected) case that packets get dropped or that ECN
> >     marks are
> >     >     received. It is
> >     >     >>> understood that this would not happen in normal
> >     operation of a
> >     >     DetNet
> >     >     >>> network is not sufficient for this document. At least
> >     for the
> >     >     risk of traffic that
> >     >     >>> may escape from a DetNet network is inherently not
> >     sufficient
> >     >     to assume that
> >     >     >>> that there is hardly any discussion on network
> >     robustness and
> >     >     safety"
> >     >     >>>
> >     >     >>> and masking of packet loss. Given that DetNet traffic may
> be
> >     >     extremely critical
> >     >     >>> reviewer, I will be fine if the document clearly
> >     describes how
> >     >     the impact of
> >     >     >>> failures will be isolated inside the DetNet network and
> will
> >     >     not put the general
> >     >     >>> Internet at risk.
> >     >     >>>
> >     >     >>> protocols. I doubt that the document can avoid
> >     discussing the
> >     >     implications of
> >     >     >>> and interactions with Internet transport protocols such
> >     as UDP
> >     >     or TCP. As a
> >     >     >>>>    From a TSV-ART point of view, the document can
> >     either only
> >     >     use the term
> >     >     >>> "transport" for Internet transport protocols and use
> another
> >     >     term for sub-
> >     >     >>> network layers (as handled in the *routing* area of the
> >     IETF),
> >     >     or the document
> >     >     >>> generally understood industry term that is also used in
> RFCs
> >     >     -- so we'll
> >     >     >>>> Regarding Section 4.4 I have already deferred the
> >     discussion
> >     >     to the IESG. The
> >     >     >>> need to read the text completely once there is a
> >     proposal how
> >     >     to address my
> >     >     >>> review. As noted in my review, I believe the document
> >     must use
> >     >     terminology
> >     >     >>> clearly and consistently. As example, a statement in -09
> >     such
> >     >     as "Network
> >     >     >>> QoS requirements are met" is IMHO too vague. But in such
> >     cases
> >     >     it depends
> >     >     >>> there is a new version.  Of course, you can also
> >     contribute to
> >     >     the WG
> >     >     >>> discussion on the topic.
> >     >     >>>
> >     >     >>> Thanks,
> >     >     >>>
> >     >     >>> Lou
> >     >     >>>
> >     >     >>>> Best regards
> >     >     >>>>
> >     >     >>>> Michael
> >     >     >>>>
> >     >     >>>>
> >     >     >>>>
> >     >     >>>>> Thank you,
> >     >     >>>>>
> >     >     >>>>> Lou
> >     >     >>>>>
> >     >     >>>>>> additional means. Thus, for a baseline document, one
> >     could
> >     >     expect
> >     >     >>>>> some
> >     >     >>>>>> harm to parts of a network not supporting DetNet? As
> >     a side
> >     >     note,
> >     >     >>>>> when TCPM
> >     >     >>>>>> additional measures." I wonder if a similar disclaimer
> is
> >     >     needed for
> >     >     >>>>> DetNet. If
> >     >     >>>>>> * It is surprising that there is hardly any discussion
> on
> >     >     network
> >     >     >>>>> robustness
> >     >     >>>>>> misconfiguration or errors of functions performing
> packet
> >     >     replication
> >     >     >>>>> could
> >     >     >>>>>> architecture ensure that a network stays fully
> >     operational
> >     >     e.g. if
> >     >     >>>>> the topology
> >     >     >>>>>> changes or there are equipment failures? Probably
> >     this can
> >     >     be solved
> >     >     >>>>> by
> >     >     >>>>>> requirements not spelt out? Section 3.3.2 speculates
> that
> >     >     filters and
> >     >     >>>>> policers
> >     >     >>>>>> and correctly configured (and well-behaving) devices.
> And
> >     >     Section
> >     >     >>>>> 3.3.2 is
> >     >     >>>>>> any requirements or recommendations. There may be
> further
> >     >     solutions,
> >     >     >>>>> such as
> >     >     >>>>>> probably exist. But why is the impact on non-DetNet
> >     traffic
> >     >     (e.g., in
> >     >     >>>>> case of
> >     >     >>>>>> * Regarding security, an architecture like DetNet
> >     probably
> >     >     requires
> >     >     >>>>> that only
> >     >     >>>>>> authenticated and authorized end systems have access
> >     to the
> >     >     data
> >     >     >>>>> plane. The
> >     >     >>>>>> terminology is concerning. This specifically applies
> >     to the
> >     >     case of
> >     >     >>>>> incomplete
> >     >     >>>>>> not consistently use the terminology introduced in
> >     Section
> >     >     2.1 in all
> >     >     >>>>> sections
> >     >     >>>>>> * Section 4.4 refers to RFC 7426, which is an
> >     informational
> >     >     RFC on
> >     >     >>>>> IRTF stream,
> >     >     >>>>>> and the document uses the concepts introduced there
> >     (e.g.,
> >     >     "planes").
> >     >     >>>>> This is
> >     >     >>>>>> at all clear why Section 4.4 is in this document.
> Section
> >     >     4.4 could
> >     >     >>>>> be removed
> >     >     >>>>>>       The term "transport layer" has a well-defined
> >     meaning
> >     >     in the IETF,
> >     >     >>>>> e.g.
> >     >     >>>>>>       originating from RFC 1122. While "transport"
> >     and e.g.
> >     >     "transport
> >     >     >>>>> network" is
> >     >     >>>>>>       protocols such as TCP and UDP. As such, I
> >     personally
> >     >     find the term
> >     >     >>>>> "DetNet
> >     >     >>>>>>       in Figure 4, where UDP (which is a transport
> >     protocol
> >     >     as per RFC
> >     >     >>>>> 1122) sits
> >     >     >>>>>>       on top of "transport".
> >     >     >>>>>>
> >     >     >>>>>>       the "DetNet transport layer" is actually a
> separate
> >     >     protocol layer
> >     >     >>>>> compared
> >     >     >>>>>>       to the "DetNet service layer". Thus it is not
> clear
> >     >     to me why the
> >     >     >>>>> word
> >     >     >>>>>>       "layer" has to be used, specifically in
> combination
> >     >     "transport
> >     >     >>>>> layer".
> >     >     >>>>>>       To me as, the word "transport layer" (and
> >     "transport
> >     >     protocol")
> >     >     >>>>> should be
> >     >     >>>>>>       This is just one of several examples for
> >     inconsistent
> >     >     use of
> >     >     >>>>> terminology.
> >     >     >>>>>>       What is a "DetNet node"? That term is not
> >     introduced
> >     >     in Section
> >     >     >>>>> 2.1
> >     >     >>>>>> * Page 14
> >     >     >>>>>>
> >     >     >>>>>>        A DetNet network supports the dedication of a
> high
> >     >     proportion
> >     >     >>>>> (e.g.
> >     >     >>>>>>       If the term "transport layer" cannot be
> >     avoided, the
> >     >     labels in
> >     >     >>>>> this figure
> >     >     >>>>>>       As already mentioned earlier, Figure 4 is
> >     confusing.
> >     >     UDP is a
> >     >     >>>>> transport
> >     >     >>>>>>       protocol. If the term "transport" cannot be
> >     avoided,
> >     >     the labels in
> >     >     >>>>> this
> >     >     >>>>>>        allows, the unused resource such as link
> bandwidth
> >     >     can be made
> >     >     >>>>>>       Could there be additional requirements on the
> >     use of
> >     >     unused
> >     >     >>>>> resources by
> >     >     >>>>>>       that was possible, a statement like "... can be
> >     made
> >     >     available by
> >     >     >>>>> the system
> >     >     >>>>>>       to non-DetNet packets as long as all guarantees
> are
> >     >     fulfilled"
> >     >     >>>>> would be on
> >     >     >>>>>>       the safe side, no?
> >     >     >>>>>>
> >     >     >>>>>> * Page 27:
> >     >     >>>>>>
> >     >     >>>>>>       Why does this sentence use the word "hop"? As
> >     far as
> >     >     I understand,
> >     >     >>>>> in DetNet
> >     >     >>>>>>       bandwidth and buffer resources are reserved in
> each
> >     >     DetNet
> >     >     >>>>> intermediate node.
> >     >     >>>>>>       If there were hops over IP routers not being
> DetNet
> >     >     intermediate
> >     >     >>>>> nodes, no
> >     >     >>>>>>       IP, on devices that are not routers... So does
> >     "hop"
> >     >     here refer to
> >     >     >>>>> IP router
> >     >     >>>>>>       The text does not explain why a _central_
> >     controller
> >     >     is needed for
> >     >     >>>>> this
> >     >     >>>>>>       the description of the examples in Section
> >     4.7.3. For
> >     >     instance,
> >     >     >>>>> "VID +
> >     >     >>>>>>       expaned with additional context and explanation
> >     to be
> >     >     useful to
> >     >     >>>>> readers.
> >     >     >>>>>> * Page 34
> >     >     >>>>>>
> >     >     >>>>>>       Wouldn't it be sufficient to state "Provisioning
> of
> >     >     DetNet
> >     >     >>>>> requires knowledge
> >     >     >>>>>>       the same paragraph also apply to a network that
> >     uses
> >     >     _multiple_
> >     >     >>>>> central
> >     >     >>>>>>       control planes? In general, an architecture
> >     document
> >     >     should be
> >     >     >>>>> agnostic to
> >     >     >>>>>>       case, I fail to see a need to discuss the
> >     realization
> >     >     of the
> >     >     >>>>> control plane of
> >     >     >>>>>>       a network.
> >     >     >>>>>>
> >     >     >>>>>> Editorial nits:
> >     >     >>>>>>
> >     >     >>>>>> * Page 9:
> >     >     >>>>>>
> >     >     >>>>>>        scheduling, that might otherwise be
> >     over-subscribed
> >     >     and trigger
> >     >     >>>>> the
> >     >     >>>>>>       I find this confusing. I would understand e.g.
> >     "along
> >     >     separate
> >     >     >>>>>>       (SRLG-disjoint) paths".
> >     >     >>>>>>
> >     >     >>>>>> * Page 34:
> >     >     >>>>>>
> >     >     >>>>>>        When using a peer-
> >     >     >>>>>>        to-peer control plane, some of this
> >     information may
> >     >     be required
> >     >     >>>>> by a
> >     >     >>>>>>       "Latency" or "delay" would probably be a better
> >     terms
> >     >     if the value
> >     >     >>>>> is
> >     >     >>>>>>       measured in nanoseconds.
> >     >     >>>>>>
> >     >     >>>>>> * Page 35:
> >     >     >>>>>>
> >     >     >>>>>>        DetNet is provides a Quality of Service (QoS),
> and
> >     >     as such, does
> >     >     >>>>> not
> >     <mailto:[email-masked] <mailto:[email-masked]>>
> >     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 13 Dec 2018 15:39:41 -0500

IPv6 *is* there ;-)

On 12/13/2018 3:29 PM, Andrew G. Malis wrote:
>     >     > On 11/20/2018 11:21 AM, Pascal Thubert (pthubert) wrote:
>     >     >> Hello Lou:
>     >     >>
>     >     >>
>     >     >> About ' discuss changing the name of the "DetNet Transport
>     >     >>
>     >     >> For one I'd like to make that call. The unfortunate name
>     >     >>
>     >     >> I tend to agree that for the general IETF "transport"
>     generally
>     >     >>
>     >     >> Same goes actually for the complex path that we build. That
>     >     >>
>     >     >> Would you push that discussion to the ML?
>     >     >>
>     >     >> Take care,
>     >     >>
>     >     >> Pascal
>     >     >>
>     >     >>> -----Original Message-----
>     >     >>> From: Lou Berger <[email-masked]
>     >     >>> Sent: mardi 20 novembre 2018 13:11
>     >     >>> To: Scharf, Michael <[email-masked]
>     >     >>> Cc: [email-masked] <mailto:[email-masked]>
>     >     >>> [email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     >>> Subject: Re: [Detnet] Tsvart last call review of
>     >     draft-ietf-detnet-architecture-08
>     >     >>>
>     >     >>> Michael,
>     >     >>>
>     >     >>> I think we're getting somewhere and identifying where we
>     have
>     >     disconnects
>     >     >>> and what may (and what may not) need to change in the
>     >     document.  My
>     >     >>> takeaways are:
>     >     >>>
>     >     >>> - The document needs a good 'scrub' of the congestion
>     related
>     >     references to
>     >     >>> ensure that the document only makes statements on what is
>     >     actually done
>     >     >>> within a DetNet and the relationship with transport
>     protocols
>     >     that use detnet
>     >     >>> (which are in fact outside the scope of the DetNet WG). 
>     I'll
>     >     work with the
>     >     >>> authors and WG on this -- I see this change as
>     important, but
>     >     editorial in
>     >     >>> nature.
>     >     >>>
>     >     >>> - We have a perception issue with at least one member of the
>     >     TSV area on the
>     >     >>> meaning and more importantly, implication, of the term
>     "DetNet
>     >     >>> *Transport* sub-layer".  While I don't disagree that a good
>     >     portion of the IETF
>     >     >>> thinks transport protocol (UDP/TCP) when they hear
>     "transport"
>     >     >>> there are plenty others, particularly in the routing
>     area, who
>     >     understand that
>     >     >>> "transport" can refer to Transport Networks.  And Transport
>     >     Network is a well
>     >     >>> understood general industry term. The IETF even has a
>     bunch of
>     >     RFCs that
>     >     >>> relate to Transport networks.  This said, I think it
>     >     reasonable to go back to the
>     >     >>> DetNet WG and discuss changing the name of the "DetNet
>     >     Transport sub-
>     >     >>> layer"  to avoid the word "transport". -- BTW we made a
>     >     parallel change in
>     >     >>> the TEAS WG when producing RFC8453.
>     >     >>>
>     >     >>> See below for detail response in-line.
>     >     >>>
>     >     >>> On 11/19/2018 5:15 PM, Scharf, Michael wrote:
>     >     >>>> Lou,
>     >     >>>>
>     >     >>>>> --
>     >     >>>>> I wanted to take a step back from the multiple discussions
>     >     that were
>     >     >>>>> spawned by your review -- from a doc shepherd perspective,
>     >     and see
>     >     >>>>> where we are.   I know that the authors have sent a -09
>     >     version that
>     >     >>>>> addresses some, but not all issues.
>     >     >>>>>
>     >     >>>>>     From the exchanges I've seen, I think the key
>     remaining
>     >     issues are
>     >     >>>>> related to:
>     >     >>>>>
>     >     >>>>> (a) possibly introduction of congestion in the general
>     >     internet if
>     >     >>>>> packets were somehow to escape a detnet domain.  The
>     source
>     >     of this
>     >     >>>>> congestion would be inelastic traffic using DetNet or
>     due to
>     >     >>>>> congestion loss that is masked by PREOF.
>     >     >>>> These are two major issues that need to be addressed. Note
>     >     that it may not
>     >     >>> be sufficient just to add a section on operational and
>     deployment
>     >     >>> considerations. Also the existing text in the document will
>     >     need to get aligned
>     >     >>> to normative guidance on how to avoid a congestion collapse.
>     >     >>>> In -09, one example would be Section 3.1. "Primary goals
>     >     defining the
>     >     >>> DetNet QoS"
>     >     >>>>       Congestion protection operates by allocating
>     resources
>     >     along the path
>     >     >>>>       of a DetNet flow, e.g., buffer space or link
>     >     bandwidth.  Congestion
>     >     >>>>       protection greatly reduces, or even eliminates
>     >     entirely, packet loss
>     >     >>>>       due to output packet congestion within the
>     network, but
>     >     it can only
>     >     >>>>       be supplied to a DetNet flow that is limited at the
>     >     source to a
>     >     >>>>       maximum packet size and transmission rate.  Note that
>     >     congestion
>     >     >>>>       protection provided via congestion detection and
>     >     notification is
>     >     >>>>       explicitly excluded from consideration in DetNet,
>     as it
>     >     serves a
>     >     >>>>       different set of applications.
>     >     >>>> At least the last sentence would contradict a better
>     >     discussion of congestion
>     >     >>> in the document. For instance, it could just be removed. In
>     >     any case, the
>     >     >>> current wording in the last sentence is not correct, as the
>     >     IETF term for what is
>     >     >>> described in the last sentence is "congestion control".
>     >     >>>> Another example would be  Section 3.2.1.1. "Eliminate
>     >     congestion loss"
>     >     >>>>
>     >     >>>>       The primary means by which DetNet achieves its QoS
>     >     assurances is to
>     >     >>>>       reduce, or even completely eliminate, congestion
>     within
>     >     a DetNet node
>     >     >>>>       as a cause of packet loss. This can be achieved only
>     >     by the
>     >     >>>>       provision of sufficient buffer storage at each node
>     >     through the
>     >     >>>>       network to ensure that no packets are dropped due
>     to a
>     >     lack of buffer
>     >     >>>>       storage.  Note that a DetNet flow cannot be
>     throttled,
>     >     i.e., its
>     >     >>>>       transmission rate cannot be reduced via explicit
>     congestion
>     >     >>>>       notification.
>     >     >>>>
>     >     >>>> This section IMHO has to include a discussion of what
>     happens
>     >     in the (not
>     >     >>> expected) case that packets get dropped or that ECN
>     marks are
>     >     received. It is
>     >     >>> understood that this would not happen in normal
>     operation of a
>     >     DetNet
>     >     >>> network, but I believe just considering the error-free
>     >     operation of a DetNet
>     >     >>> network is not sufficient for this document. At least
>     for the
>     >     risk of traffic that
>     >     >>> may escape from a DetNet network is inherently not
>     sufficient
>     >     to assume that
>     >     >>> the DetNet network is always error-free.
>     >     >>>
>     >     >>> I think these are examples of text that needs to be
>     cleanup up
>     >     and to
>     >     >>> delineate what is done with a DetNet.
>     >     >>>
>     >     >>>
>     >     >>>> As a result, addressing my concerns will most likely
>     require
>     >     editing several
>     >     >>> parts of the document.
>     >     >>>> In addition, I'd like to emphasize that my review
>     comment "It
>     >     is surprising
>     >     >>> that there is hardly any discussion on network
>     robustness and
>     >     safety"
>     >     >>>
>     >     >>> I have no idea what you mean by safety here.  Can you
>     elaborate.
>     >     >>>
>     >     >>>
>     >     >>>> covers more than just inelastic traffic that escapes from a
>     >     DetNet network
>     >     >>> and masking of packet loss. Given that DetNet traffic may be
>     >     extremely critical
>     >     >>> traffic, I really wonder why the document doesn't emphasize
>     >     more the
>     >     >>> required robustness against failures *inside* the DetNet
>     >     network as well as
>     >     >>> counter-measures. But this is something the WG needs to
>     >     decide. As TSV-ART
>     >     >>> reviewer, I will be fine if the document clearly
>     describes how
>     >     the impact of
>     >     >>> failures will be isolated inside the DetNet network and will
>     >     not put the general
>     >     >>> Internet at risk.
>     >     >>>
>     >     >>> I agree - I think, the document should be clear on it's
>     scope and
>     >     >>> relationship to general internet usage.
>     >     >>>
>     >     >>>
>     >     >>>>> (b) The use of the term 'transport' in DetNet to refer to
>     >     what is
>     >     >>>>> basically a Traffic Engineered sub-network layer, such
>     as is
>     >     provided
>     >     >>>>> with MPLS-TE or Optical Transport Networks.
>     >     >>>> In the Internet architecture, the term 'transport'
>     refers to
>     >     Internet transport
>     >     >>> protocols. I doubt that the document can avoid
>     discussing the
>     >     implications of
>     >     >>> and interactions with Internet transport protocols such
>     as UDP
>     >     or TCP. As a
>     >     >>> result, I disagree that the document can use the term
>     >     'transport' to refer to
>     >     >>> traffic engineered sub-network layers.
>     >     >>>
>     >     >>> I think this is covered by my comment above.
>     >     >>>
>     >     >>>
>     >     >>>>    From a TSV-ART point of view, the document can
>     either only
>     >     use the term
>     >     >>> "transport" for Internet transport protocols and use another
>     >     term for sub-
>     >     >>> network layers (as handled in the *routing* area of the
>     IETF),
>     >     or the document
>     >     >>> has to clearly distinguish between the Internet transport
>     >     layer and other uses
>     >     >>> of the term "transport" and explain the overlap. I
>     believe the
>     >     former would be
>     >     >>> less confusing, but I will leave it up to the TSV ADs to
>     >     discuss terminology
>     >     >>> overlap in the IESG. As TSV-ART reviewer I insist that the
>     >     document uses the
>     >     >>> terms "transport layer" and "transport protocol" only when
>     >     referring to the
>     >     >>> Internet transport layer.
>     >     >>>
>     >     >>> I'm personally okay with a name change and even willing to
>     >     push this
>     >     >>> discussion within the WG, but as said above, "Transport
>     >     Network" is a
>     >     >>> generally understood industry term that is also used in RFCs
>     >     -- so we'll
>     >     >>> have to see what where WG consensus ends up.
>     >     >>>
>     >     >>>>> Do you have any other issues that that are critical to be
>     >     addressed
>     >     >>>>> before this work moves forward? If so which?
>     >     >>>> Regarding Section 4.4 I have already deferred the
>     discussion
>     >     to the IESG. The
>     >     >>> TSV-ART review comment is that the IESG needs to carefully
>     >     look at the
>     >     >>> concepts, terminology, and references in section 4.4.
>     >     >>>> Regarding my other comments, I acknowledge that -09 is
>     a step
>     >     forward. But
>     >     >>> given the cross-dependencies e.g. regarding terminology and
>     >     definitions, I will
>     >     >>> need to read the text completely once there is a
>     proposal how
>     >     to address my
>     >     >>> review. As noted in my review, I believe the document
>     must use
>     >     terminology
>     >     >>> clearly and consistently. As example, a statement in -09
>     such
>     >     as "Network
>     >     >>> nodes supporting DetNet flows have to implement some of
>     the DetNet
>     >     >>> capabilities (not necessarily all) in order to treat DetNet
>     >     flows such that their
>     >     >>> QoS requirements are met" is IMHO too vague. But in such
>     cases
>     >     it depends
>     >     >>> whether there is precise normative guidance elsewhere. And
>     >     this requires
>     >     >>> looking at the text as a whole.
>     >     >>>
>     >     >>> I think the next steps lie with me and the WG. We'll let you
>     >     know once
>     >     >>> there is a new version.  Of course, you can also
>     contribute to
>     >     the WG
>     >     >>> discussion on the topic.
>     >     >>>
>     >     >>> Thanks,
>     >     >>>
>     >     >>> Lou
>     >     >>>
>     >     >>>> Best regards
>     >     >>>>
>     >     >>>> Michael
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>>> Thank you,
>     >     >>>>>
>     >     >>>>> Lou
>     >     >>>>>
>     >     >>>>> On 9/28/2018 6:24 PM, Michael Scharf wrote:
>     >     >>>>>> Reviewer: Michael Scharf
>     >     >>>>>> Review result: Ready with Issues
>     >     >>>>>>
>     >     >>>>>> The document "Deterministic Networking Architecture"
>     >     >>>>>> (draft-ietf-detnet-architecture-08) defines an overall
>     >     framework for
>     >     >>>>>> Deterministic Networking.
>     >     >>>>>>
>     >     >>>>>> As TSV-ART reviewer, I believe that this document has
>     issues as
>     >     >>>>> detailed below.
>     >     >>>>>> Michael
>     >     >>>>>>
>     >     >>>>>> Major issues:
>     >     >>>>>>
>     >     >>>>>> * It seems that DetNet cannot easily be deployed in the
>     >     Internet
>     >     >>>>> without
>     >     >>>>>> additional means. Thus, for a baseline document, one
>     could
>     >     expect
>     >     >>>>> some
>     >     >>>>>> explanation on the requirements of deploying DetNet in a
>     >     network.
>     >     >>>>> DetNet
>     >     >>>>>> basically requires support in (almost) all network
>     devices
>     >     >>>>> transporting DetNet
>     >     >>>>>> traffic. That assumption should be explicitly spelt out
>     >     early in the
>     >     >>>>> document,
>     >     >>>>>> e.g., in the introduction. There also needs to be an
>     explicit
>     >     >>>>> discussion of the
>     >     >>>>>> implications if not the whole network is aware of or
>     >     supports DetNet.
>     >     >>>>> There is
>     >     >>>>>> some text in Section 4.2.2 and Section 4.3.3, but I
>     believe
>     >     >>>>> additional explicit
>     >     >>>>>> discussion is needed at a prominant place. For instance,
>     >     can use of
>     >     >>>>> DetNet do
>     >     >>>>>> harm to parts of a network not supporting DetNet? As
>     a side
>     >     note,
>     >     >>>>> when TCPM
>     >     >>>>>> published RFC 8257, the following disclaimer was added:
>     >     "DCTCP, as
>     >     >>>>> described in
>     >     >>>>>> this specification, is applicable to deployments in
>     controlled
>     >     >>>>> environments
>     >     >>>>>> like data centers, but it must not be deployed over
>     the public
>     >     >>>>> Internet without
>     >     >>>>>> additional measures." I wonder if a similar disclaimer is
>     >     needed for
>     >     >>>>> DetNet. If
>     >     >>>>>> there is an implicit assumption that DetNet will  be
>     used in
>     >     >>>>> homogenous
>     >     >>>>>> environments with mostly DetNet-aware devices within
>     the same
>     >     >>>>> organization,
>     >     >>>>>> such an assumption should be made explicit.
>     >     >>>>>>
>     >     >>>>>> * It is surprising that there is hardly any discussion on
>     >     network
>     >     >>>>> robustness
>     >     >>>>>> and safety; this probably also relates to security. For
>     >     instance,
>     >     >>>>>> misconfiguration or errors of functions performing packet
>     >     replication
>     >     >>>>> could
>     >     >>>>>> severely and permantly congest a network and cause harm.
>     >     How does the
>     >     >>>>> DetNet
>     >     >>>>>> architecture ensure that a network stays fully
>     operational
>     >     e.g. if
>     >     >>>>> the topology
>     >     >>>>>> changes or there are equipment failures? Probably
>     this can
>     >     be solved
>     >     >>>>> by
>     >     >>>>>> implementations (e.g., dynamic control plane), but
>     why are
>     >     >>>>> corresponding
>     >     >>>>>> requirements not spelt out? Section 3.3.2 speculates that
>     >     filters and
>     >     >>>>> policers
>     >     >>>>>> can help, and that may be true, but that probably
>     still assumes
>     >     >>>>> consistently
>     >     >>>>>> and correctly configured (and well-behaving) devices. And
>     >     Section
>     >     >>>>> 3.3.2 is
>     >     >>>>>> vague and mentions a "infinite variety of possible
>     >     failures" without
>     >     >>>>> stating
>     >     >>>>>> any requirements or recommendations. There may be further
>     >     solutions,
>     >     >>>>> such as
>     >     >>>>>> circuit breakers and the like. Why are such topics not
>     >     discussed?
>     >     >>>>>>
>     >     >>>>>> * Somewhat related, the document only looks at impact of
>     >     failures to
>     >     >>>>> the QoS of
>     >     >>>>>> DetNet traffic. What is missing is a discussion how to
>     >     protect non-
>     >     >>>>> DetNet parts
>     >     >>>>>> of a network from any harm caused by DetNet mechanisms.
>     >     Solutions to
>     >     >>>>> this
>     >     >>>>>> probably exist. But why is the impact on non-DetNet
>     traffic
>     >     (e.g., in
>     >     >>>>> case of
>     >     >>>>>> topology changes or failures of DetNet functions) not
>     >     discussed at
>     >     >>>>> all in the
>     >     >>>>>> document?
>     >     >>>>>>
>     >     >>>>>> * Regarding security, an architecture like DetNet
>     probably
>     >     requires
>     >     >>>>> that only
>     >     >>>>>> authenticated and authorized end systems have access
>     to the
>     >     data
>     >     >>>>> plane. The
>     >     >>>>>> security considerations only briefly mention the control
>     >     aspect ("the
>     >     >>>>>> authentication and authorization of the controlling
>     systems").
>     >     >>>>>>
>     >     >>>>>> * For an architecture document, the lack of clarity and
>     >     consistency
>     >     >>>>> regarding
>     >     >>>>>> terminology is concerning. This specifically applies
>     to the
>     >     case of
>     >     >>>>> incomplete
>     >     >>>>>> networks (as per Section 4.2.2 and 4.3.3) that
>     include "DetNet-
>     >     >>>>> unaware nodes".
>     >     >>>>>> The document introduces terms such as "DetNet
>     intermediate
>     >     nodes" but
>     >     >>>>> then
>     >     >>>>>> repeatedly uses generic terms such as "node" or "hop"
>     that may
>     >     >>>>> include
>     >     >>>>>> DetNet-unaware nodes. For instance, for incomplete
>     networks, a
>     >     >>>>> sentence such as
>     >     >>>>>> "The primary means by which DetNet achieves its QoS
>     >     assurances is to
>     >     >>>>> reduce, or
>     >     >>>>>> even completely eliminate, congestion within a node as a
>     >     cause of
>     >     >>>>> packet loss"
>     >     >>>>>> seems to only apply to "DetNet transit nodes" but not
>     >     "DetNet-unaware
>     >     >>>>> nodes".
>     >     >>>>>> Similar ambiguity exist for other use of the terms "hop"
>     >     and "node",
>     >     >>>>> which may
>     >     >>>>>> or may not include DetNet-unaware nodes. It is
>     unclear why the
>     >     >>>>> document does
>     >     >>>>>> not consistently use the terminology introduced in
>     Section
>     >     2.1 in all
>     >     >>>>> sections
>     >     >>>>>> and clearly distinguishes cases with and without DetNet
>     >     support.
>     >     >>>>>>
>     >     >>>>>> * Section 4.4 refers to RFC 7426, which is an
>     informational
>     >     RFC on
>     >     >>>>> IRTF stream,
>     >     >>>>>> and the document uses the concepts introduced there
>     (e.g.,
>     >     "planes").
>     >     >>>>> This is
>     >     >>>>>> very confusing. First, an IETF Proposed Standard should
>     >     probably
>     >     >>>>> refer to
>     >     >>>>>> documents having IETF consensus. An example would be RFC
>     >     7491, albeit
>     >     >>>>> there is
>     >     >>>>>> other related work as well, e.g., in the TEAS WG. Second,
>     >     Section 4.4
>     >     >>>>> is by and
>     >     >>>>>> large decoupled from the rest of the document and not
>     >     specific to
>     >     >>>>> DetNet.
>     >     >>>>>> Neither do other sections of the document refer to
>     the concepts
>     >     >>>>> introduced in
>     >     >>>>>> Section 4.4, nor does Section 4.4 use the DetNet
>     terminology or
>     >     >>>>> discuss
>     >     >>>>>> applicability to DetNet. Section 4.4 even mentions
>     >     explicitly at the
>     >     >>>>> end that
>     >     >>>>>> it discusses aspects that are orthogonal to the DetNet
>     >     architecture.
>     >     >>>>> It is not
>     >     >>>>>> at all clear why Section 4.4 is in this document. Section
>     >     4.4 could
>     >     >>>>> be removed
>     >     >>>>>> from the document without impacting the rest of the
>     document.
>     >     >>>>>>
>     >     >>>>>> Minor issues:
>     >     >>>>>>
>     >     >>>>>> * Terminology "DetNet transport layer"
>     >     >>>>>>
>     >     >>>>>>       The term "transport layer" has a well-defined
>     meaning
>     >     in the IETF,
>     >     >>>>> e.g.
>     >     >>>>>>       originating from RFC 1122. While "transport"
>     and e.g.
>     >     "transport
>     >     >>>>> network" is
>     >     >>>>>>       used in the IETF for different technologies in
>     >     different areas, I
>     >     >>>>> think the
>     >     >>>>>>       term "transport layer" is typically understood to
>     >     refer to
>     >     >>>>> transport
>     >     >>>>>>       protocols such as TCP and UDP. As such, I
>     personally
>     >     find the term
>     >     >>>>> "DetNet
>     >     >>>>>>       transport layer" misleading and confusing. The
>     >     confusion is easy
>     >     >>>>> to see e.g.
>     >     >>>>>>       in Figure 4, where UDP (which is a transport
>     protocol
>     >     as per RFC
>     >     >>>>> 1122) sits
>     >     >>>>>>       on top of "transport".
>     >     >>>>>>
>     >     >>>>>>       Based on the document it also may be
>     >     solution/implementation
>     >     >>>>> specific whether
>     >     >>>>>>       the "DetNet transport layer" is actually a separate
>     >     protocol layer
>     >     >>>>> compared
>     >     >>>>>>       to the "DetNet service layer". Thus it is not clear
>     >     to me why the
>     >     >>>>> word
>     >     >>>>>>       "layer" has to be used, specifically in combination
>     >     "transport
>     >     >>>>> layer".
>     >     >>>>>>       To me as, the word "transport layer" (and
>     "transport
>     >     protocol")
>     >     >>>>> should be
>     >     >>>>>>       used for protocols defined in TSV area, consistent
>     >     with RFC 1122.
>     >     >>>>> But this is
>     >     >>>>>>       probably a question to be sorted out by the IESG.
>     >     >>>>>>
>     >     >>>>>> * Page 9
>     >     >>>>>>
>     >     >>>>>>        A DetNet node may have other resources requiring
>     >     allocation
>     >     >>>>> and/or
>     >     >>>>>>        scheduling,
>     >     >>>>>>
>     >     >>>>>>       This is just one of several examples for
>     inconsistent
>     >     use of
>     >     >>>>> terminology.
>     >     >>>>>>       What is a "DetNet node"? That term is not
>     introduced
>     >     in Section
>     >     >>>>> 2.1
>     >     >>>>>> * Page 14
>     >     >>>>>>
>     >     >>>>>>        A DetNet network supports the dedication of a high
>     >     proportion
>     >     >>>>> (e.g.
>     >     >>>>>>        75%) of the network bandwidth to DetNet flows.
>     >     >>>>>>
>     >     >>>>>>       The 75% value is not reasoned. What prevents using
>     >     99% of the
>     >     >>>>> bandwidth for
>     >     >>>>>>       DetNet traffic?
>     >     >>>>>>
>     >     >>>>>> * Page 15: Figure 2
>     >     >>>>>>
>     >     >>>>>>       If the term "transport layer" cannot be
>     avoided, the
>     >     labels in
>     >     >>>>> this figure
>     >     >>>>>>       should at least be expanded to "DetNet
>     transport layer".
>     >     >>>>>>
>     >     >>>>>> * Page 18: Figure 4
>     >     >>>>>>
>     >     >>>>>>       As already mentioned earlier, Figure 4 is
>     confusing.
>     >     UDP is a
>     >     >>>>> transport
>     >     >>>>>>       protocol. If the term "transport" cannot be
>     avoided,
>     >     the labels in
>     >     >>>>> this
>     >     >>>>>>       figure should at least be expanded to "DetNet
>     transport".
>     >     >>>>>>
>     >     >>>>>> * Page 23
>     >     >>>>>>
>     >     >>>>>>        If the source transmits less data than this limit
>     >     >>>>>>        allows, the unused resource such as link bandwidth
>     >     can be made
>     >     >>>>>>        available by the system to non-DetNet packets.
>     >     >>>>>>
>     >     >>>>>>       Could there be additional requirements on the
>     use of
>     >     unused
>     >     >>>>> resources by
>     >     >>>>>>       non-DetNet packets, e.g., regarding preemption?
>     I am just
>     >     >>>>> wondering... If
>     >     >>>>>>       that was possible, a statement like "... can be
>     made
>     >     available by
>     >     >>>>> the system
>     >     >>>>>>       to non-DetNet packets as long as all guarantees are
>     >     fulfilled"
>     >     >>>>> would be on
>     >     >>>>>>       the safe side, no?
>     >     >>>>>>
>     >     >>>>>> * Page 27:
>     >     >>>>>>
>     >     >>>>>>        DetNet achieves congestion protection and bounded
>     >     delivery
>     >     >>>>> latency by
>     >     >>>>>>        reserving bandwidth and buffer resources at every
>     >     hop along the
>     >     >>>>> path
>     >     >>>>>>        of the DetNet flow.
>     >     >>>>>>
>     >     >>>>>>       Why does this sentence use the word "hop"? As
>     far as
>     >     I understand,
>     >     >>>>> in DetNet
>     >     >>>>>>       bandwidth and buffer resources are reserved in each
>     >     DetNet
>     >     >>>>> intermediate node.
>     >     >>>>>>       If there were hops over IP routers not being DetNet
>     >     intermediate
>     >     >>>>> nodes, no
>     >     >>>>>>       resources would be reserved there. As per Section
>     >     4.3.3, it is
>     >     >>>>> possible to
>     >     >>>>>>       deploy DetNet this way. And obviously there can be
>     >     resource
>     >     >>>>> bottlenecks below
>     >     >>>>>>       IP, on devices that are not routers... So does
>     "hop"
>     >     here refer to
>     >     >>>>> IP router
>     >     >>>>>>       hops or also to devices not processing IP (or
>     IP/MPLS)?
>     >     >>>>>>
>     >     >>>>>> * Page 27:
>     >     >>>>>>
>     >     >>>>>>        Standard queuing and transmission selection
>     >     algorithms allow a
>     >     >>>>>>        central controller to compute the latency
>     >     contribution of each
>     >     >>>>>>        transit node to the end-to-end latency, ...
>     >     >>>>>>
>     >     >>>>>>       The text does not explain why a _central_
>     controller
>     >     is needed for
>     >     >>>>> this
>     >     >>>>>>       computation. Why would a distributed control plane
>     >     not be able to
>     >     >>>>> realize
>     >     >>>>>>       this computation. Isn't this
>     implementation-specific?
>     >     >>>>>>
>     >     >>>>>> * Page 32
>     >     >>>>>>
>     >     >>>>>>       To somebody who is not deeply familiar with
>     DetNet, it is
>     >     >>>>> impossible to parse
>     >     >>>>>>       the description of the examples in Section
>     4.7.3. For
>     >     instance,
>     >     >>>>> "VID +
>     >     >>>>>>       multicast MAC address" is not introduced. I think
>     >     this example
>     >     >>>>> must be
>     >     >>>>>>       expaned with additional context and explanation
>     to be
>     >     useful to
>     >     >>>>> readers.
>     >     >>>>>> * Page 34
>     >     >>>>>>
>     >     >>>>>>        There are three classes of information that a
>     >     central controller
>     >     >>>>> or
>     >     >>>>>>        distributed control plane needs to know that can
>     >     only be obtained
>     >     >>>>>>        from the end systems and/or nodes in the network.
>     >     >>>>>>
>     >     >>>>>>       Wouldn't it be sufficient to state "Provisioning of
>     >     DetNet
>     >     >>>>> requires knowledge
>     >     >>>>>>       about ...". Does it matter in this context
>     whether the
>     >     >>>>> provisioning is done
>     >     >>>>>>       by a central controller or a distributed control
>     >     plane? For
>     >     >>>>> instance, could
>     >     >>>>>>       the same paragraph also apply to a network that
>     uses
>     >     _multiple_
>     >     >>>>> central
>     >     >>>>>>       controllers, or hybrid combinations of central
>     >     controllers and
>     >     >>>>> distributed
>     >     >>>>>>       control planes? In general, an architecture
>     document
>     >     should be
>     >     >>>>> agnostic to
>     >     >>>>>>       implementation aspects unless there is a specific
>     >     need. In this
>     >     >>>>> specific
>     >     >>>>>>       case, I fail to see a need to discuss the
>     realization
>     >     of the
>     >     >>>>> control plane of
>     >     >>>>>>       a network.
>     >     >>>>>>
>     >     >>>>>> Editorial nits:
>     >     >>>>>>
>     >     >>>>>> * Page 9:
>     >     >>>>>>
>     >     >>>>>>        The low-level mechanisms described in Section 4.5
>     >     provide the
>     >     >>>>>>        necessary regulation of transmissions by an end
>     >     system or
>     >     >>>>>>        intermediate node to provide congestion
>     protection.  The
>     >     >>>>> allocation
>     >     >>>>>>        of the bandwidth and buffers for a DetNet flow
>     requires
>     >     >>>>> provisioning
>     >     >>>>>>        A DetNet node may have other resources requiring
>     >     allocation
>     >     >>>>> and/or
>     >     >>>>>>        scheduling, that might otherwise be
>     over-subscribed
>     >     and trigger
>     >     >>>>> the
>     >     >>>>>>        rejection of a reservation.
>     >     >>>>>>
>     >     >>>>>>       Probably a full stop is missing after
>     "provisioning".
>     >     >>>>>>
>     >     >>>>>> * Page 11: "... along separate (disjoint non-SRLG)
>     paths ..."
>     >     >>>>>>
>     >     >>>>>>       I find this confusing. I would understand e.g.
>     "along
>     >     separate
>     >     >>>>>>       (SRLG-disjoint) paths".
>     >     >>>>>>
>     >     >>>>>> * Page 34:
>     >     >>>>>>
>     >     >>>>>>        When using a peer-
>     >     >>>>>>        to-peer control plane, some of this
>     information may
>     >     be required
>     >     >>>>> by a
>     >     >>>>>>        system's neighbors in the network.
>     >     >>>>>>
>     >     >>>>>>       Would "acquired" be a better term?
>     >     >>>>>>
>     >     >>>>>> * Page 34:
>     >     >>>>>>
>     >     >>>>>>        o  The identity of the system's neighbors, and the
>     >     >>>>> characteristics of
>     >     >>>>>>           the link(s) between the systems, including the
>     >     length (in
>     >     >>>>>>           nanoseconds) of the link(s).
>     >     >>>>>>
>     >     >>>>>>       "Latency" or "delay" would probably be a better
>     terms
>     >     if the value
>     >     >>>>> is
>     >     >>>>>>       measured in nanoseconds.
>     >     >>>>>>
>     >     >>>>>> * Page 35:
>     >     >>>>>>
>     >     >>>>>>        DetNet is provides a Quality of Service (QoS), and
>     >     as such, does
>     >     >>>>> not
>     >     >>>>>>        directly raise any new privacy considerations.
>     >     >>>>>>
>     >     >>>>>>       Broken sentence
>     >     >>>>>>
>     >     >>>>>> * Please expand acronyms on first use (e.g., OTN)
>     >     >>>>>>
>     >     >>>>>>
>     >     >>>> _______________________________________________
>     >     >>>> detnet mailing list
>     >     >>>> [email-masked] <mailto:[email-masked]>
>     >     >>>> https://www.ietf.org/mailman/listinfo/detnet
>     >