Re: [Tsv-art] [Detnet] Tsvart last call review of draft-ietf-detnet-architecture-08

[Lou Berger <[e-mail]>]

Hi,

See below for in-line responses

On 11/5/2018 12:21 AM, Black, David wrote:
> ...

>>> * 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 permanently congest a network and cause harm.
> [... snip ...]
>> NEW:
>> Robust real-time systems require to reduce the number of possible
>> failures. Filters and policers should be used in a DetNet network to
>> detect if DetNet packets are received on the wrong interface, or at
>> the wrong time, or in too great volume. Furthermore, filters and
>> policers can take action to discard offending packets or flows, or
>> trigger shutting down the offending DetNet flow, or shutting down
>> the offending interface.
>>
>> [ms] That does not address my concern. As I wrote already, I believe this
>> document has to discuss the applicability of circuit breakers according to RFC
>> 8084.
> I concur with Michael's implied concern that the "should" in the NEW text
> is woefully inadequate.  The provisions to prevent escaped non-elastic traffic
> from causing damage elsewhere need to be mandatory particularly if DetNet
> and non-DetNet networks are interconnected.  The above
> text on filters doesn't appear to cover escape from the DetNet network,
> and needs to do so.  Deployment of filters at DetNet nodes that drop all
> DetNet traffic that tries to escape, and that drop all misdirected DetNet
> traffic should address most of this problem.
>
> Once that is done, I think a discussion of circuit breakers is needed, in the
> form of Detnet service mechanisms that can shut down (cease transmission
> of) a flow that is being sent entirely into the bit-bucket by a downstream filter,
> due to misconfiguration, failure, etc.

I think we have a bit of a disconnect of what DetNet service delivers.

DetNet does not itself impact any Transport protocol  (e.g., UDP, TCP) 
so itself does not *produce* elastic or non-elastic traffic.

DetNet operates at Layer 3 and basically provides detnet flows with a 
service equivalent to IntServ's Guaranteed Quality of Service.  As such, 
DetNet flows basically operate as if the network is uncongested.

WRT escaped traffic, as I mentioned in today's session, I really think 
this is no difference between escaped DetNet traffic and traffic 
delivered over an uncongested network to a peer (congested or 
uncongested) network.

Based on all this, I'm not sure how or why a  discussion of circuit 
breakers is needed.

Lou

>
> Thanks, --David
>
>> -----Original Message-----
>> From: Tsv-art [mailto:[e-mail]] On Behalf Of Scharf, Michael
>> Sent: Monday, October 22, 2018 5:44 PM
>> To: 'János Farkas'
>> Cc: [e-mail]; DetNet WG; [e-mail]
>> Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-detnet-architecture-08
>>
>>
>> [EXTERNAL EMAIL]
>> Please report any suspicious attachments, links, or requests for sensitive
>> information.
>>
>>
>> Hi Janos,
>>
>> Thanks for the reply. My comments are inline [ms].
>>
>> I have omitted all proposed changes that work for me.
>>
>> Michael
>>
>>
>> -----Original Message-----
>> From: János Farkas <[e-mail]>
>> Sent: Wednesday, October 17, 2018 10:56 AM
>> To: Scharf, Michael <[e-mail]>
>> Cc: [e-mail]; [e-mail]; DetNet WG
>> <[e-mail]>
>> Subject: Re: Tsvart last call review of draft-ietf-detnet-architecture-08
>>
>> Hi Michael,
>>
>> Thank you very much for the thorough review and good comments!
>>
>> Please find below in-line responses and how we plan to update the draft to
>> resolve your comments.
>>
>> Best regards,
>> Janos
>>
>>
>> On 9/29/2018 12:24 AM, 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:
>> [...]
>>
>>> 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.
>> Actually, some form of DetNet support is required from each node that
>> transports DetNet traffic. For instance, DetNet flows have to be recognized in
>> order not to spoil their QoS at the minimum.
>>
>> [ms] I look for an clear explanation in the architecture document of what "some
>> form of DetNet support" exactly means. For instance, is standard MPLS TE
>> without any DetNet support good enough for an LSR on the IP/MPLS path used
>> by DetNet traffic, or not? As an example, when I read the following paragraph in
>> draft-ietf-detnet-dp-sol-mpls-01 ...
>>
>>     Transit nodes are normal MPLS Label Switching Routers (LSRs).  They
>>     are generally unaware of the special requirements of DetNet flows,
>>     although they need to provide traffic engineering services and proper
>>     QoS to the LSPs associated with DetNet flows to enhance the prospect
>>     of the LSPs meeting the DetNet service requirements.  Some
>>     implementations of transit nodes may be DetNet aware, but such nodes
>>     just support the DetNet transport layer.
>>
>> ... I could maybe assume that actually there can be "transit nodes" that do not
>> require *any* sort of DetNet support or DetNet awareness. Is that correct? I
>> think the architecture document has to be clear on such fundamental questions.
>>
>> The Introduction could be extended to clarify, e.g., the third paragraph:
>>
>> OLD:
>> A goal of DetNet is a converged network in all respects. That is, the presence of
>> DetNet flows does not preclude non-DetNet flows, and the benefits offered
>> DetNet flows should not, except in extreme cases, prevent existing QoS
>> mechanisms from operating in a normal fashion, subject to the bandwidth
>> required for the DetNet flows. A single source-destination pair can trade both
>> DetNet and non-DetNet flows. End systems and applications need not
>> instantiate special interfaces for DetNet flows. Networks are not restricted to
>> certain topologies; connectivity is not restricted. Any application that generates
>> a data flow that can be usefully characterized as having a maximum bandwidth
>> should be able to take advantage of DetNet, as long as the necessary resources
>> can be reserved. Reservations can be made by the application itself, via network
>> management, by an application’s controller, or by other means, e.g., a dynamic
>> control plane (e.g., [RFC2205]).
>>
>> NEW:
>> A goal of DetNet is a converged network in all respects. That is, the presence of
>> DetNet flows does not preclude non-DetNet flows, and the benefits offered
>> DetNet flows should not, except in extreme cases, prevent existing QoS
>> mechanisms from operating in a normal fashion, subject to the bandwidth
>> required for the DetNet flows. A single source-destination pair can trade both
>> DetNet and non-DetNet flows. End systems and applications need not
>> instantiate special interfaces for DetNet flows. Networks are not restricted to
>> certain topologies; connectivity is not restricted. Any application that generates
>> a data flow that can be usefully characterized as having a maximum bandwidth
>> should be able to take advantage of DetNet, as long as the necessary resources
>> can be reserved. Reservations can be made by the application itself, via network
>> management, by an application’s controller, or by other means, e.g., a dynamic
>> control plane (e.g., [RFC2205]). 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.
>>
>> [ms] To me, the last sentence is not clear. Does "some of the DetNet capabilities
>> (not necessarily all)" include e.g. vanilla traffic engineering? For instance, if a
>> network node can ensure that the QoS requirements are met by leveraging
>> existing standardized TE without any additional DetNet awareness, is this
>> enough for deploying DetNet? Or does this node have to implement additional
>> DetNet-specific functionality? Specifically, please explain if an existing DetNet-
>> unaware router on the path taken by DetNet traffic can be used to forward
>> DetNet traffic, or if it is mandatory that any router forwarding DetNet traffic
>> indeed implements new capabilities specific to DetNet. In the latter case, I think
>> the document would need to discuss incremental deployment strategies as well.
>>
>>> * 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?
>> Security issues and considerations are addressed by the DetNet Security
>> draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security.
>> Reference to the  DetNet Security draft will be added.
>>
>> There will be a document dedicated to Operations, Administration and
>> Maintenance (OAM), which will address operational, misconfiguration, and
>> failure detection issues.
>>
>> The topology changes have to be solved by the control plane, either
>> centralized or distributed.
>>
>> The filters and policers described in Section 3.3.2 also provide
>> robustness by eliminating/mitigating traffic coming from malfunctioning
>> devices.
>>
>> RFC2475 is recommended for traffic policing functions to increase
>> robustness.
>>
>> The text  in Section 3.3.2 could be made clearer, e.g., by updating the
>> first paragraph to:
>>
>> OLD:
>> One key to building robust real-time systems is to reduce the
>> infinite variety of possible failures to a number that can be
>> analyzed with reasonable confidence. DetNet aids in the process by
>> allowing for filters and policers to detect DetNet packets received
>> on the wrong interface, or at the wrong time, or in too great a
>> volume, and to then take actions such as discarding the offending
>> packet, shutting down the offending DetNet flow, or shutting down the
>> offending interface.
>>
>> NEW:
>> Robust real-time systems require to reduce the number of possible
>> failures. Filters and policers should be used in a DetNet network to
>> detect if DetNet packets are received on the wrong interface, or at
>> the wrong time, or in too great volume. Furthermore, filters and
>> policers can take action to discard offending packets or flows, or
>> trigger shutting down the offending DetNet flow, or shutting down
>> the offending interface.
>>
>> [ms] That does not address my concern. As I wrote already, I believe this
>> document has to discuss the applicability of circuit breakers according to RFC
>> 8084.
>>
>>> * 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?
>> Actually the regulation of DetNet traffic by polices and filters
>> protects both other DetNet traffic and non-DetNet traffic.
>>
>> Section 3.3.1 could be extended to make it clear, e.g., by extending the
>> last paragraph:
>>
>> OLD:
>> Ideally, the net effect of the presence of DetNet flows in a network
>> on the non-DetNet packets is primarily a reduction in the available
>> bandwidth.
>>
>> NEW:
>> Traffic policing functions (e.g. [RFC2475]) are used to avoid the
>> starvation of non-DetNet traffic. Thus, the net effect of the presence
>> of DetNet flows in a network on non-DetNet flows is primarily a
>> reduction in the available bandwidth.
>>
>> [ms] I believe a stronger wording is needed, e.g. along the lines of "a DetNet
>> deployment must avoid starvation of non-DetNet traffic ...".
>>
>> [...]
>>
>>> * 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.
>> The document should point out to traffic engineering and centralized
>> control plane aspects, so it is better to keep Section 4.4.
>>
>> RFC 7426 provides the full picture of SDN architecture, which needs to
>> be referred from the DetNet architecture. No other RFC provides such
>> detailed picture. Therefore, we need to keep the reference to RFC 7426,
>> which is an informative reference.
>>
>> [ms] I'll leave that up to the IESG to decide whether an IETF proposed standard
>> should build an architecture based on research work instead of, say, documents
>> with IETF consensus. As a side note, I believe the understanding in industry what
>> "SDN architecture" really means and how it is implemented may have evolved
>> since publication of IRTF RFC 7426, which was published in Jan. 2015. For
>> instance, IRTF RFC 7426 does not discuss the implications of segment routing,
>> BGP-LS, and other recent IETF techniques. And, based on what I read in the
>> DetNet architecture, I believe DetNet could actually be implemented without
>> any "SDN architecture", e.g. by distributed traffic engineering. As a result, I don't
>> even understand the need to discuss "SDN".
>>
>> [ms] For the record: As TSV-ART reviewer, I question whether IRTF RFC 7426 is
>> indeed an appropriate reference, I have doubts that IRTF RFC 7426 is really up-
>> to-date, and I am concerned about the content quality of section 4.4, e.g.,
>> regarding the lack of alignment with the rest of the document. The IESG will
>> certainly have a better understanding that than me how to deal with such topics.
>>
>> The related work in TEAS is already referred to.
>>
>> [...]
>>
>>> 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.
>> "transport" is used here as in "packet transport networks" not as OSI L4
>> transport.
>>
>> [ms] At the risk of stating the obvious: The relevant section of RFC 1122 defining
>> "transport layer" is entitled by "The Internet Architecture". And, according e.g.
>> to RFC 5921, "packet transport network" is a term defined by ITU-T. In an IETF
>> document, I believe IETF terminology should be used.
>>
>> I suggest to use the terms "DetNet transport sub-layer" and "DetNet
>> service sub-layer" throughout the document, which would hopefully avoid
>> confusion.
>>
>> [ms] "DetNet transport sub-layer" somewhat solves my concern of avoiding the
>> expression "transport layer". To really avoid confusion, I believe it would be
>> better to avoid the ambiguous term "transport" altogether.  But I will be fine if
>> all DetNet documents consistently avoid the term "transport layer".
>>
>> Michael
>> _______________________________________________
>> Tsv-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tsv-art
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet