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

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

Hello János:



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



The dialog was as follows



> 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?





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-

       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.

"





Is that OK?



All the best,



Pascal


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


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.