Re: [Raw] WG Last Call: draft-ietf-raw-architecture-11 - David Black's comments

["Black, David" <[e-mail]>]

Hi Pascal,

> Many thanks ! I’ll need to clarify that the ooda loop of effectively the one you describe. There is no other.
> It certainly never goes through the PCE, the whole point of RAW is that the communication with the PCE is too slow and expensive so we export functionality in the routers.

Sounds good - the crucial change is to get the PCE (as well as the entire detnet controller plane) out of the RAW OODA loop, starting with item 2 at the end of Section 3.2 and a revision of Figure 8.

In support of this, it might help to swap the order of section 4 and section 5, so that the PSE-centric control loop is explained (revision of current section 5) before discussion of how it fits into the layers of the detnet architecture (section 4).   As noted below, I also think that the PSE (or at least its path selection functionality) belongs in the detnet forwarding sub-layer, not just the service sub-layer (although I think I see some rationale for a portion of the PSE being in the service sub-layer).

> The PCE is expected to build some hints based on its history and predictions of the links state.
> This is exported to the network with the initial Track structure and possibly updated overtime as a background task.

As noted below, I’d suggest an initial rewrite that never mentions the PCE.  A plausible approach would be to make a raw-enhanced DetNet controller plane responsible for producing and updating Tracks.

> This knowledge/wisdom level set of hints constitutes the Orient piece which is the base for the reroute decision. I’m game for suggestions on which text should be reworded that caused this confusion.
Sections 2.6 and 5.3 along with item 1 at the end of section 3.2 discuss OAM in terms of measurement protocols and packets.  In contrast, Figure 10 in section 5.5 shows an additional PSE interface to L2 which appears to be outside the scope of OAM as used elsewhere in this draft.   Perhaps broadening “Observe” to be more than OAM (which implies protocols and packets) would help.

Thanks, --David

From: Pascal Thubert (pthubert) <pthubert=[e-mail]>
Sent: Friday, July 7, 2023 5:54 AM
To: Black, David
Cc: Eve Schooler; [e-mail]; [e-mail]; [e-mail]; [e-mail]; John Scudder; Black, David
Subject: Re: [Raw] WG Last Call: draft-ietf-raw-architecture-11 - David Black's comments


[EXTERNAL EMAIL]
Hello David

Many thanks ! I’ll need to clarify that the ooda loop of effectively the one you describe. There is no other.

It certainly never goes through the PCE, the whole point of RAW is that the communication with the PCE is too slow and expensive so we export functionality in the routers.

The PCE is expected to build some hints based on its history and predictions of the links state. This is exported to the network with the initial Track structure and possibly updated overtime as a background task.

This knowledge/wisdom level set of hints constitutes the Orient piece which is the base for the reroute decision. I’m game for suggestions on which text should be reworded that caused this confusion.
Again many thanks !

Pascal


Le 7 juil. 2023 à 01:32, Black, David <David.Black=[e-mail]<mailto:David.Black=[e-mail]>> a écrit :

Lou and Janos (detnet chairs) asked me to take a look at this draft – these comments are posted as an individual, not in my role as a Technical Advisor to the detnet WG.  I actually looked at -12, which has some minor changes from -11.

Overall, there are valuable and important concepts in the architecture.  The primary functional additions of raw over detnet that I noticed are the concepts of multi-Path Tracks and the PSE (Path Selection Engine) that can select Path within Track on a packet-by-packet basis, with the control path revising Tracks on a longer timescale.  That’s more dynamic than the static path provisioning that is envisioned by detnet, e.g., in the discussion of explicit routes in section 3.2.2 of RFC 8655 (Deterministic Networking Architecture).  In addition, the ability of the PSE to monitor, react to, and possibly modify wireless link characteristics (e.g., monitor level of interference and signal loss, modify ARQ & FEC parameters) results in a significantly more dynamic version of detnet PREOF, although I’m not convinced that introducing the new PAREO term and acronym is a productive way of describing that.

Unfortunately, the OODA Raw Control Loop in Section 5 doesn’t work well with this, as exemplified by Figure 8 showing only one control loop that runs through a centralized PCE (Path Computation Engine).  There is a far more important control loop that runs between the PSE and the network, based on far more information than RAW OAM (in Figure 8) provides.  While the draft does characterize the PCE as an example of a control plane structure, it doesn’t have much to say about any others.  That’s too easy to read as reinventing the detnet control plane, which would not be a good idea.

This draft would be considerably stronger if it jettisoned the PCE and its Figure 8 coarse control plane feedback loop to focus on the PSE and its fine-grain path selection feedback loop.  In particular, there’s a lot of good content in Figure 10 that deserves much more explanation than currently provided in sections 5.5 and 5.6.   This sort of approach would involve extending the detnet architecture to introduce Tracks as the entities via which traffic is explicitly “routed” by the detnet/raw control plane.  Section 4 also needs work, as it places the PSE in the detnet service sub-layer with the premise that it uses the detnet forwarding sub-layer with minor changes.  That doesn’t make sense – to phrase this as a question: Given that the PSE is selecting Path within Track on a packet-by-packet basis, how and why is that not packet forwarding functionality?

This is intended as constructive criticism for discussion – as I’ve not been following raw closely, some portion of this is likely to be incorrect in some fashion.

Thanks, --David

From: detnet <[e-mail]<mailto:[e-mail]>> On Behalf Of Eve Schooler
Sent: Friday, June 23, 2023 1:11 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder
Subject: [Detnet] WG Last Call: draft-ietf-raw-architecture-11


[EXTERNAL EMAIL]

All,



This starts working group last call on draft-ietf-raw-architecture-11

https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-detnet-pof/__;!!LpKI!gwAT9SygbUUZ8R5o9vGdxPNzKSMI44j13KrTFoVFxilR3iN3ZAcjdFYU1uqKEJwOtjWHwje5_7am6fHX4_EpuxQ$>



The working group last call ends on Friday, July 21st, the Friday before IETF 117.

Please send your comments to the working group mailing list.



Two IPR disclosures have been made for this document thus far (in tandem with WGLC, in a separate e-mail, we will solicit all co-authors/contributors for any additional disclosures).

All comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome.

This is useful and important, even from authors.

In preparation for the transition of the RAW WG to roll back into the DetNet WG, we are issuing this as a joint WGLC to both WGs.

Thank you,

Eve (RAW Co-Chair & doc Shepherd)
--
RAW mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/raw [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/raw__;!!LpKI!neGbePuwOEQnPaz0Blsdxcf55SE0K9zSdcQlv_ao9x35SDrFjI-PZqODRmM_f48qGdZncuOvti7M3F-Ju1jXd-MrETxGwjdT$>