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

["Pascal Thubert (pthubert)" <[e-mail]>]

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

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:[e-mail]]
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 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


On Wed, Dec 19, 2018 at 12:38 PM Black, David <[e-mail]<mailto:[e-mail]>> wrote:
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:[e-mail]<mailto:[e-mail]>] 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,
>
> 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
>
> _______________________________________________
> 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