Subject: [Detnet] draft-ietf-detnet-architecture-10

From: János Farkas <[email-masked]>
Date: Wed, 19 Dec 2018 16:53:45 +0100

Hi,

The DetNet architecture document has been updated to address the 
comments. The new revision (v10) is available at 
https://tools.ietf.org/html/draft-ietf-detnet-architecture-10.

There have been a number of discussion items emails on the list. The 
updates are along the major discussion items, which also cover the 
derivative discussions, address the comments.

The major items have been summarized in:
https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html.
Follow up discussions implied terminology changes summarized in:
https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: 
replace "transport sub-layer" with "forwarding sub-layer"
https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: 
replace "congestion protection" with "resource" allocation"
Consequently, the document had a good 'scurb".

In addition, outstanding comments have been addressed along 
https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html.

Please let us know if any comment happened to be remained open.

Best regards,
Janos

---

From: "Black, David" <[email-masked]>
Date: Wed, 19 Dec 2018 17:37:40 +0000

Janos,

The terminology is definitely improved - the resulting draft is much
clearer - many thanks to you and the authors for doing that.

Where do we stand on the concern about protecting external
non-DetNet networks from DetNet flows that escape a DetNet
network, e.g., due to an erroneous network configuration change?

My current views are ...

There's no throttling in DetNet, e.g., this text in 4.3.2:

   There is no provision in DetNet for throttling DetNet flows, i.e.,
   the transmission rate cannot be reduced via explicit congestion
   notification [RFC3168].  The assumption is that a DetNet flow, to be
   useful, must be delivered in its entirety.

and no assurance that all DetNet-using applications will cease and desist
in the face of packet drops that indicate congestion.

Packet Replication and Elimination makes this worse via its ability to hide
network packet drops and congestion indications from endpoints, e.g.,
of those drops and/or congestion indications occur on only one of 
the paths used by replicated packets.

The first paragraph in section 3.3.2 is a good start, but I think its lower
case "should" is too weak:

   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 a volume.  Furthermore, filters and
   policers can take actions to discard the offending packets or flows,
   or trigger shutting down the offending flow or the offending
   interface.

At a minimum, I think that the requirement to discard DetNet traffic
that would otherwise escape a DetNet network has to be stated as
a "MUST" requirement for any DetNet network that supports Packet
Replication and Elimination due to the ability of that functionality
to hide congestion from endpoints, making it impossible for higher
layers of the protocol stack to respond.

Beyond this, I think a "SHOULD" requirement to discard DetNet traffic
that would otherwise escape is needed, and the statement of that
requirement ought to be connected to the explanation of how to
implement that requirement.  The text in Section 3.3.2 has a lot of
the content needed - for a worked example of such "SHOULD" text,
see Section 5 of RFC 7510, in particular the itemized list at the end of
that section and the paragraph that introduces that list:
   https://tools.ietf.org/html/rfc7510#section-5

Thanks, --David

> -----Original Message-----
> From: detnet [mailto:[email-masked]] On Behalf Of János Farkas
> Sent: Wednesday, December 19, 2018 10:54 AM
> To: DetNet WG
> Subject: [Detnet] draft-ietf-detnet-architecture-10
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 19 Dec 2018 13:11:42 -0500

David,

I agree with you regarding the SHOULD.

I also think it might help the text if we had a better understanding of how
DetNet flows can "escape" a DetNet network.

For example, for an MPLS-based DetNet flow, random MPLS packets arriving at
an ingress MPLS interface to a router that don't have a corresponding LIB
entry for the top-most label will be dropped. They'll also be dropped if
they arrive at an interface that isn't configured to expect MPLS packets.

So I think any concept of "escaping" would be limited to DetNet packets
over an IP infrastructure. In that case, the DetNet flows would most
probably be a using DetNet-specific DSCP, and if the ingress interface
isn't properly provisioned to know how to process packets with that DSCP,
they'll at least be reduced to best-effort treatment. We can also recommend
that packets with DetNet-specific DSCPs be dropped if they arrive at an
ingress interface that isn't otherwise provisioned to expect such packets.

Cheers,
Andy

---

From: "Black, David" <[email-masked]>
Date: Wed, 19 Dec 2018 20:15:43 +0000

Andy,

> I agree with you regarding the SHOULD.

Thanks, I hope you also agree with the MUST when Packet Replication and Elimination is supported.

I likewise agree with the overall point that misdirected MPLS traffic tends to die quickly, and hence the primary concern is “limited to DetNet packets over an IP infrastructure.”

If the architecture draft goes in this overall direction of making this escape prevention the responsibility of the solution (IP or MPLS) draft, then the “filters and policers” wording in 3.3.2 ought to be generalized to include solution-specific functional equivalents of filters and policers.  That would enable the MPLS solution draft to explain why traffic misdirected in the middle of an MPLS LSP usually winds up in the bit-bucket in short order, and what to do if MPLS paths are somehow joined via an IP forwarding node (if that’s even supported in the initial MPLS solution).

OTOH, I’ve definitely heard contrary opinions on use of DetNet-specific DSCPs, so I don’t share the assumption that they will be used.

Thanks, --David

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Wednesday, December 19, 2018 1:12 PM
To: Black, David
Cc: János Farkas; detnet WG
Subject: Re: [Detnet] draft-ietf-detnet-architecture-10

[EXTERNAL EMAIL]
David,

I also think it might help the text if we had a better understanding of how DetNet flows can "escape" a DetNet network.

For example, for an MPLS-based DetNet flow, random MPLS packets arriving at an ingress MPLS interface to a router that don't have a corresponding LIB entry for the top-most label will be dropped. They'll also be dropped if they arrive at an interface that isn't configured to expect MPLS packets.

So I think any concept of "escaping" would be limited to DetNet packets over an IP infrastructure. In that case, the DetNet flows would most probably be a using DetNet-specific DSCP, and if the ingress interface isn't properly provisioned to know how to process packets with that DSCP, they'll at least be reduced to best-effort treatment. We can also recommend that packets with DetNet-specific DSCPs be dropped if they arrive at an ingress interface that isn't otherwise provisioned to expect such packets.

Cheers,
Andy

On Wed, Dec 19, 2018 at 12:38 PM Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Janos,

My current views are ...

Thanks, --David

> From: detnet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of János Farkas
> [email-masked]<mailto:[email-masked]>

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Dec 2018 07:55:35 +0000

Hello all

I think the quoted text was meant to protect against excess/wrong traffic to enter the DetNet stream and using resources beyond what was allocated as the risk of congestion loss.
Clearly we also need protection to prevent from traffic leaving the stream. But then what if the adjacent node is not A DetNet node, the spec does not mention filtering by non dDetNet nodes. Best we can do is filter what is going out from the DetNet node. Which means adding an egress filter in addition to the ingress filter.

   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 or transmitted on the wrong interface, or at
   the wrong time, or in too great a volume.  Furthermore, filters and
   policers can take actions to discard the offending packets or flows,
   or trigger shutting down the offending flow or the offending
   interface.

Do I make sense?

Pascal

From: detnet <[email-masked]> On Behalf Of Black, David
Sent: mercredi 19 décembre 2018 21:16
To: Andrew G. Malis <[email-masked]>
Cc: detnet WG <[email-masked]>; János Farkas <[email-masked]>
Subject: Re: [Detnet] draft-ietf-detnet-architecture-10

Andy,

Thanks, --David

[EXTERNAL EMAIL]
David,

Cheers,
Andy

My current views are ...

Thanks, --David

---

From: Lou Berger <[email-masked]>
Date: Mon, 24 Dec 2018 15:18:11 -0500

Hi David,

> clearer - many thanks to you and the authors for doing that.

Happy to hear that.

> network, e.g., due to an erroneous network configuration change?

I'm not sure we have general solutions in the internet architecture for 
miss-configured/buggy systems other than dropping the packets on the 
floor (e.g., due to no route, no label, or ttl expiry).  What type of 
protection are you looking for here, and can you provide a reference to 
the type of router behavior you would like to see?  I have a suggestion 
that might address your concern below elated to non-BCP41 conformant 
traffic, but am unsure if this is what you are concerned about.

>     useful, must be delivered in its entirety.

Well looking at it this way, there is no throttling in any IP network as 
the routers generate the CN and only drop when their queues are full or 
implementing some sort of RED.

In DetNet there is an expectation that intermediate nodes do more than 
this.  Specifically, see section 4.5: "Queuing, Shaping, Scheduling, and 
Preemption" and policing, which is mentioned as requirement in section 
3.3.1.

> in the face of packet drops that indicate congestion.

I think this is correct.

> layers of the protocol stack to respond.

To me clear, your are suggesting that text be added to say that sending 
detnet traffic out a non-detnet interfaces must be treated as a fault.  
Is this correct?  If so, I think this is too broad considering that 
there are networks that can provided the required detnet forwarding 
sub-layer service that are not detnet service aware as is mentioned at 
the end of section 4.3.2. (I'll refer to such as "DetNet supporting 
networks" in the next paragraph.)

This said, I think it would be reasonable to make it a requirement that 
DetNet nodes must not forward traffic that doesn't conform with BCP41 
over a network that is neither a Detnet network or a DetNet supporting 
network.  Although this would require a change to the DetNet service 
model, i.e.,  to know which traffic was conformant/non-conformant.

> implement that requirement.

I think adding a statement on output filters (and policiers) to this 
section is reasonable.

> The text in Section 3.3.2 has a lot of
If I'm not mistaken, such mechanisms are already included in the 
document and you really are just asking them to be (re)listed to ensure 
that this import point isn't missed.  Is this correct? Besides what is 
mentioned above, is there anything else missing?

Thanks!

Lou

---

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

Andy,

Just following up on one point on DetNet-specific DSCPs:

On 12/19/2018 1:11 PM, Andrew G. Malis wrote:
> In that case, the DetNet flows would most probably be a using 
> DetNet-specific DSCP, and if the ingress interface isn't properly 
> provisioned to know how to process packets with that DSCP, they'll at 
> least be reduced to best-effort treatment.. We can also recommend that 
> packets with DetNet-specific DSCPs be dropped if they arrive at an 

While I personally think use of DSCPs will be useful in supporting 
aggregated DetNet flows, the IP solution draft has no requirement that 
operators or vendors restrict DetNet flows to a specific DSCP value.  -- 
I personally think this is an important design point.

Happy Holidays!

Lou

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 24 Dec 2018 15:26:40 -0500

Lou,

Thanks for following up.

Cheers,
Andy

---

From: "Black, David" <[email-masked]>
Date: Tue, 25 Dec 2018 01:29:46 +0000

Hi Lou,

Excerpting key paragraphs ...

> To me clear, you are suggesting that text be added to say that sending
> Is this correct?

Not exactly ...

> If so, I think this is too broad considering that

I agree with where this is headed - sending DetNet traffic into a network
that has not been provisioned to provide the required detnet forwarding
service to that traffic has to be treated as a fault.  In this statement,
"provisioned" should be read broadly, e.g., it could be realized via an
administrative decision that the DetNet supporting network has the
available capacity to carry the DetNet traffic that is being sent into it.

> model, i.e.,  to know which traffic was conformant/non-conformant.

That's fine with one important twist:

Any traffic that has been replicated by DetNet packet replication has to
be treated as not conforming with BCP41 because DetNet packet
elimination (of replicated packets) may hide congestion indications
(e.g., delay, ECN CE marks, drops) from the endpoints - a scenario of
particular concern involves the other flow of replicated packets
following a DetNet network path along which nothing goes wrong.
BCP41 is about end-to-end-congestion control, which does not do
anything if DetNet packet elimination hides congestion indications
from the endpoints.

> I think adding a statement on output filters (and policers) to this
> section is reasonable.

Let's start with the inclusion of output filters (and policers) in the 3.3.2
text with the use of upper-case "SHOULD" as suggested by Pascal - I will
look this over and suggest any additional text that I think ought to be
included.

Thanks, --David

> From: Lou Berger [mailto:[email-masked]]
> Sent: Monday, December 24, 2018 3:18 PM
> To: Black, David; János Farkas; DetNet WG

---

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

Hi David,

> available capacity to carry the DetNet traffic that is being sent into it.
agreed.
> anything if DetNet packet elimination hides congestion indications

This seems reasonable to me.

> look this over and suggest any additional text that I think ought to be

As an architecture document, the authors/WG made the call to not use 
conformance capitalization or reference 2119/8174.  I think this 
translates to the conformance language needing to be added to the data 
plane solution documents.

Cheers,

Lou