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

["Andrew G. Malis" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     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 <[e-mail]
> >     <mailto:[e-mail]>
> >     > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> >     >
> >     >     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
> >     >            +----------------------------+
> >     >                          .
> >     >                          .
> >     >
> >     >                        Figure 4: DetNet adaptation to data plane
> >     >
> >     >     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"
> >     >     > 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
> >     >     >
> >     >     > 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
> >     >     >>
> >     >     >>> -----Original Message-----
> >     >     >>> From: Lou Berger <[e-mail]
> >     <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>>
> >     >     >>> Sent: mardi 20 novembre 2018 13:11
> >     >     >>> To: Scharf, Michael <[e-mail]
> >     <mailto:[e-mail]>
> >     >     <mailto:[e-mail]
> >     <mailto:[e-mail]>>>
> >     >     >>> Cc: [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>;
> >     > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>; draft-ietf-detnet-
> >     >     >>> [e-mail]
> >     <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]
> >>
> >     >     >>> 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
> >     >     >>>> [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >     >     >>>> https://www.ietf.org/mailman/listinfo/detnet
> >     >
> >     >     _______________________________________________
> >     >     detnet mailing list
> >     > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >     > https://www.ietf.org/mailman/listinfo/detnet
> >     >
> >
>