Subject: [Detnet] Last call comments on draft-ietf-detnet-problem-statement-04

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jun 2018 13:04:48 +0000

Hello Janos:

I'm almost through, see below. You'll find 2 items on which I need clarification :)

> You expressed in your email that you wanted to follow Stewart's suggestion,

> but it seems that you missed implementing his first comment in the

> document. As I understand the suggestion is to replace "IP network" with "an

> IP or MPLS network" in:

> "As a result of this work, it will be possible to establish a multihop path over

> the IP network, for ..."

[PT>] done

> Item 3) in section 3.4 misses one of the possibilities. An IGP can also be an

> alternative, e.g., IS-IS TE, IS-IS PCR (RFC 7813), which are not mentioned. It

> may be added, e.g.,: "Alternatively, the path may be installed by a routing

> protocol or the routing and flow information may be placed in-band in the

> packet ..."

[PT>] refinement needed:

In fact the intent was to differentiate the case where the routes are compute centrally vs. no PCE at all.

I understand that the TE extensions are feeding a PCE, and that PCR also depends on a PCE to compute the ECTs.

=> I agree with your text but the content seems to belong to the second bullet of 3.3, what do you think?

> Item 3) in section 3.4 suggests that MPLS-TE is the only option. I'd suggest to

> rewrite, e.g.:

> "Traffic flows can be transported through an MPLS-TE tunnel, using the

> reserved resources for this flow at each hop."

[PT>] refinement needed:

Item Section 3.4 in 04 reads:

"   3.   The path may be installed using a control protocol such as RSVP-

       TE, associated with flow identification, per-hop behavior such as

       Packet Replication and Elimination, blocked resources, and flow

       timing information.  Alternatively, the routing and flow

      information may be placed in-band in the packet, e.g., using

       Segment Routing, in which case the packet is routed along a

       prescribed source route path following forwarding indications

       that are present in the packet.

"

Whereas Item 4 is

"

   4.  Traffic flows are transported through the MPLS-TE tunnel, using

       the reserved resources for this flow at each hop.

"

Maybe we can move item 4) that you modified into item 3. And then the IP based data plane could become the altrenative item 4.

What about:

"   3.   The path may be installed using a control protocol such as RSVP-

       TE, associated with flow identification, per-hop behavior such as

       Packet Replication and Elimination, blocked resources, and flow

       timing information. In that case, Traffic flows can be transported

       through an MPLS-TE tunnel, using the reserved resources for this

       flow at each hop.

   4.  Alternatively, the routing and flow information may be placed

       in-band in the IP packet, e.g., using Segment Routing and/or IPv6

       Routing and Option Headers, in which case the packet is routed

       along a prescribed source route path following forwarding

       indications that are present in the packet.

"

Works?

> Authentication and authorization are only mentioned for control nodes in

> section 4. I guess it also applies to hosts in a plug-and-play network.

> Maybe we should consider this case too.

[PT>] sure ; I'd say that the end point participates to the control to a certain extent, so what about :

       the authentication and authorization of the controlling nodes including

       plug-and-play participating end systems.

> A couple of acronyms are not resolved at the first occurrence or at all:

> DetNet, PCE, CSPF, SDN.

[PT>] Argl ! If you look at the xml you'll find what happened. We commented out a large chunk on "Related IETF work".

Sure, I'm fixing that, but for SDN that is going away. Reintroduced the ref to the PCE architecture as well.

> In addition to resolving PCE, it would be good to add a reference to RFC 4655.

[PT>] Yes I restored that too : )

> I'm afraid it is not easy to find a precise definition of SDN that is accepted by

> all. Therefore, it seems better to avoid the term SDN, i.e., delete the single

> occurrence. The remaining sentence will be complete and meaningful, fitting

> into the context.

> CSPF appears only once. The given sentence could be rewritten to:

> "A constrained path is calculated with an improved version of a constrained

> shortest path first algorithm that is aware of DetNet."

[PT>] done using the resolution of your discussion with Stewart

> There seems to be a space before the full stop in the abstract.

[PT>] Gone

> ID nits found three unused references:

>    == Unused Reference: 'AVnu' is defined on line 404, but no explicit

>       reference was found in the text

>    == Unused Reference: 'EIP' is defined on line 410, but no explicit

>       reference was found in the text

>    == Unused Reference: 'ODVA' is defined on line 449, but no explicit

>       reference was found in the text

[PT>] These are bugs in the id nits. It only looks at certain references, not all them.

These refs are used page 3, see the htmlized version.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Jun 2018 09:29:31 +0000

Hello János:

I'd like to publish but would appreciate your confirmation on the resulting section 3.4.

The dialog was as follows

[PT>] refinement needed:

In 05 as it stands now in the repo the whole section reads as:

"

3.4.  Distributed Path Setup

   Whether a distributed alternative without a PCE can be valuable could

   be studied as well.  Such an alternative could for instance inherit

   from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows.

   But the focus of the work should be to deliver the centralized

   approach first.

   To enable a RSVP-TE like functionality, the following steps would

   take place:

   1.  Neighbors and their capabilities are discovered and exposed to

       compute a path that fits the DetNet constraints, typically of

       latency, time precision and resource availability.

   2.  A constrained path is calculated with an improved version of

       Constrained Shortest Path First (CSPF) that is aware of DetNet.

   3.  The path may be installed using a control protocol such as RSVP-

       timing information.  In that case, traffic flows can be

       transported through an MPLS-TE tunnel, using the reserved

       resources for this flow at each hop.

   4.  Alternatively, the routing and flow information may be placed in-

       band in the IP packet, e.g., using Segment Routing and/or IPv6

"

Is that OK?

All the best,

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 19 juin 2018 15:03
To: 'János Farkas' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Last call comments on draft-ietf-detnet-problem-statement-04

Hello Janos:

[PT>] done

[PT>] refinement needed:

[PT>] refinement needed:

"

Whereas Item 4 is

"

"

What about:

       flow at each hop.

"

Works?

[PT>] Gone