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

[Lou Berger <[e-mail]>]

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]>> 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]>>
>     >>> Sent: mardi 20 novembre 2018 13:11
>     >>> To: Scharf, Michael <[e-mail]
>     <mailto:[e-mail]>>
>     >>> Cc: [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; draft-ietf-detnet-
>     >>> [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]>
>     >>>> https://www.ietf.org/mailman/listinfo/detnet
>
>     _______________________________________________
>     detnet mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/detnet
>