Re: [Raw] [Detnet] Terminology: draft-ietf-raw-architecture-14.txt and what's still unclear

[Lou Berger <[e-mail]>]

Pascal,

Please publish the update.  Please also review the past comments and 
ensure all have been addressed.  I don't recall points raised being 
discussed - it would helpful if you have time to check/review, of course 
this will also have be done as part of any LC and per-publication 
resolution process. (Note, Eve is Shepherd on this one.)

Thank you,

Lou

On 10/3/2023 9:00 AM, Pascal Thubert (pthubert) wrote:
>
> Dear all:
>
> I’m ready to publish 16 to incorporate Greg’s comments. Before I do 
> that, is there any other clarification that we need to make?
>
> With that I believe we’re ready to launch the WGLC as we agreed in 
> London.
>
> regards,
>
> Pascal
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* Wednesday, August 16, 2023 11:34 AM
> *To:* Greg Mirsky <[e-mail]>; Pascal Thubert (pthubert) 
> <pthubert=[e-mail]>
> *Cc:* [e-mail]; Adrian Farrel ([e-mail]) 
> <[e-mail]>; Lou Berger ([e-mail]) 
> <[e-mail]>; [e-mail]
> *Subject:* RE: [Detnet] [Raw] Terminology: 
> draft-ietf-raw-architecture-14.txt and what's still nuclear
>
> GIM>> I see, thank you for pointing it out to me. Can we call it a 
> "Decision function" similar, for example, to PREOF? If 'yes', then tit 
> could be expressed as "A PLR that hosts a Decision function". WDYT?
>
> WFM Greg 😊
>
> I pushed to https://github.com/raw-wg/raw-architecture.git 
>  422ef61..0bb4c73  main -> main
>
> regards,
>
> Pascal
>
> *From:* detnet <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, August 15, 2023 7:16 PM
> *To:* Pascal Thubert (pthubert) <pthubert=[e-mail]>
> *Cc:* [e-mail]; Adrian Farrel ([e-mail]) 
> <[e-mail]>; Lou Berger ([e-mail]) 
> <[e-mail]>; [e-mail]
> *Subject:* Re: [Detnet] [Raw] Terminology: 
> draft-ietf-raw-architecture-14.txt and what's still nuclear
>
> Hi Pascal,
>
> so glad my comments are of help.
>
> I agree with the resolutions you proposed. One thought about the OODA 
> down below tagged by GIM>>.
>
> Regards,
>
> Greg
>
> On Fri, Aug 11, 2023 at 1:49 PM Pascal Thubert (pthubert) 
> <pthubert=[e-mail]> wrote:
>
>     Hello Greg
>
>     Many thanks for your review!
>
>     > I have several suggestions for your consideration (purely
>     editorial, as I think of them):
>
>     • in Abstract, it could be easier to use extended forms of
>     acronyms like PREOF, OAM, DetNet, and PAREO
>
>     Can do, with the exception of DetNet which is more of a noun
>     meaning our work rather than deterministic networking at large.
>     PAREO I’d simply omit simpler that way.
>
>     • capitalize the title of Section 2.3.2 to "Recovery Graph"
>
>     Done
>
>     > capitalize "Forward" in the title of Section 2.3.3 (also
>     capitalize in the first and second sentences of the first paragraph).
>
>     Done
>
>     > capitalize "Recovery Graph" in the title of Section 2.3.6. Also,
>     if you decide to capitalize Complex, should "recovery graph" also
>     be capitalized when used together?
>
>     Removed the “complex” thingy. A simple path is now a lane and that
>     should be enough terminology.
>
>     > I think that the correct reference to the BFD specification is
>     RFC 5880 (there seems like a typo referencing RFC 5580 in Section
>     2.6.7)
>
>     Oups
>
>     > "A PLR that Decides" reads like a PLR has a mind of its own ;).
>     Would "A PLR that selects" or something similar be acceptable as a
>     replacement?
>
>     Selects would have the same ias. We cold say follows the decision
>     tree or performs the selection algorithm. But why discuss
>     implementation? BTW the D is the one from OODA, that’s why it’s there.
>
> GIM>> I see, thank you for pointing it out to me. Can we call it a 
> "Decision function" similar, for example, to PREOF? If 'yes', then tit 
> could be expressed as "A PLR that hosts a Decision function". WDYT?
>
>     > s/r CPF/rCPF/?
>
>     CPF is supposed to refer to the DetNet one. And r/aCPF to the RAW
>     split of the CPF. I might have missed one instance, but that’s
>     probably not a change all… “DetNet rCPF” should not have shown up;
>     another change all artifact. I cleaned that.
>
>     > "sensitive/reactive" as a characterization of the DetNet rCPF
>     seems like putting together sweet and overly sweet (in reverse
>     order). Could both characteristics be replaced by "overreactive"
>     or simply use "sensitive"?
>
>     What about
>
>     “
>
>     As a result, the DetNet CPF is not expected to be aware of and to
>
>     react to very transient changes.
>
>     “
>
>     ?
>
> GIM>> Excellent!
>
>     The commit for the above is ea5fc11
>     <https://github.com/raw-wg/raw-architecture/commit/ea5fc1149daf0119c9e8c7dd0324078c66393b91>.Please
>     let me know if it if fitting.
>
>     Many thanks again!
>
>     Pascal
>
>     *From:* Greg Mirsky <[e-mail]>
>     *Sent:* Wednesday, August 2, 2023 4:31 AM
>     *To:* Pascal Thubert (pthubert) <[e-mail]>
>     *Cc:* [e-mail]; Adrian Farrel ([e-mail])
>     <[e-mail]>; Lou Berger ([e-mail])
>     <[e-mail]>; [e-mail]
>     *Subject:* Re: Terminology: draft-ietf-raw-architecture-14.txt and
>     what's still nuclear
>
>     Hi Pascal,
>
>     thank you for your thoughtful consideration of our discussion and
>     careful updates to reflect the agreement reached. The result is
>     great and made the document more readable and easier to relate to
>     mechanisms known to other groups. I have several suggestions for
>     your consideration (purely editorial, as I think of them):
>
>       * in Abstract, it could be easier to use extended forms of
>         acronyms like PREOF, OAM, DetNet, and PAREO
>       * capitalize the title of Section 2.3.2 to "Recovery Graph"
>       * capitalize "Forward" in the title of Section 2.3.3 (also
>         capitalize in the first and second sentences of the first
>         paragraph).
>       * capitalize "Recovery Graph" in the title of Section 2.3.6.
>         Also, if you decide to capitalize Complex, should "recovery
>         graph" also be capitalized when used together?
>       * I think that the correct reference to the BFD specification is
>         RFC 5880 (there seems like a typo referencing RFC 5580 in
>         Section 2.6.7)
>       * "A PLR that Decides" reads like a PLR has a mind of its own
>         ;). Would "A PLR that selects" or something similar be
>         acceptable as a replacement?
>       * s/r CPF/rCPF/?
>       * "sensitive/reactive" as a characterization of the DetNet rCPF
>         seems like putting together sweet and overly sweet (in reverse
>         order). Could both characteristics be replaced by
>         "overreactive" or simply use "sensitive"?
>
>     Regards,
>
>     Greg
>
>     On Sun, Jul 30, 2023 at 1:39 PM Pascal Thubert (pthubert)
>     <[e-mail]> wrote:
>
>         Dear all:
>
>         the publication of 14 adds terminologies and typos. The goal
>         is to serve as the new reference for the WGLC so we can use
>         the new terms in our discussions. If someone still uses PSE
>         and Track, well, I guess we'll still understand for a little
>         while, but he will be harshly reprimanded.
>
>         What I did not do yet though I started is work out the
>         positioning of the aCPF (the component that talks
>         asynchronously to the rCPF == PCE to report performance and
>         get route updates), the Point of Local Repair (PLR is the term
>         that replaces the PSE) and the OAM supervisor that triggers
>         OAM and aggregates results for the PLR.
>
>         These are 3 new architectural blocks, and we want to position
>         them well in the DetNet architecture.
>
>         The DetNet architecture (section 4.4) has 3 planes that are
>         mapped to classical SDN, with the controller plane in the
>         middle, a southbound interface to the network plane (in the
>         case of RAW used between rCPF and aCPF) and a northbound
>         interface to the Application Plane.
>
>         The Controller plane has the typical route servers like PCEs,
>         and network management entities. In the SDN model they are
>         "far away" and monitor the whole network. Which is what
>         causing the RAW issue of lack of reactivity and pushed us to
>         port functionality in the network plane. In networking planes
>         parlance, the PCE is control plane and the NMEs are management
>         plane.
>
>         As we see, though the term controller plane looks like control
>         plane, they are different beasts. A classical IGP is a control
>         plane function that operates in the DetNet network plane. The
>         controller plane hosts controllers, which physically may embed
>         routing and management entities. In the DetNet architecture,
>         "The Controller Plane corresponds to the aggregation of the
>         Control and Management Planes in [RFC7426
>         <https://datatracker.ietf.org/doc/html/rfc7426>], though
>         Common Control and Measurement Plane (CCAMP) (as defined by
>         the CCAMP Working Group [CCAMP
>         <https://datatracker.ietf.org/wg/ccamp/charter/>]) makes an
>         additional distinction between management and measurement."
>
>         In my book, the OAM supervisor, the aCPF and the PLR operate
>         in the control plane. The OAM supervisor talks to the OAM
>         handlers in the management plane. And all of the above being
>         distributed in the network, they operate in the DetNet Network
>         plane.  So 1) we extend the DetNet architecture to place
>         functional blocks in the Network Plane and 2) one could say we
>         need 3D pictures to represent the intersection of the DetNet
>         planes and the traditional control and management planes.
>         While the data plane remains firmly in the Network plane.
>
>         Now this is my view and the way I intend to update the text to
>         publish 15, hopefully quite soon. But I need confirmation that
>         we are on the same line, or else debates to reach a consensus.
>
>         What do you all think?
>
>         Pascal
>
>         ------------------------------------------------------------------------
>
>         *De :*[e-mail]<[e-mail]>
>         *Envoyé :* samedi 29 juillet 2023 15:40
>         *À :* Pascal Thubert (pthubert) <[e-mail]>
>         *Objet :* New Version Notification for
>         draft-ietf-raw-architecture-14.txt
>
>
>         A new version of I-D, draft-ietf-raw-architecture-14.txt
>         has been successfully submitted by Pascal Thubert and posted
>         to the
>         IETF repository.
>
>         Name: draft-ietf-raw-architecture
>         Revision:       14
>         Title:          Reliable and Available Wireless Architecture
>         Document date:  2023-07-29
>         Group:          raw
>         Pages:          43
>         URL:
>         https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.txt
>         Status:
>         https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/
>         Html:
>         https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html
>         Htmlized:
>         https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture
>         Diff:
>         https://author-tools.ietf.org/iddiff?url2=draft-ietf-raw-architecture-14
>
>         Abstract:
>            Reliable and Available Wireless (RAW) provides for high
>         reliability
>            and availability for IP connectivity across any combination
>         of wired
>            and wireless network segments.  The RAW Architecture
>         extends the
>            DetNet Architecture and other standard IETF concepts and
>         mechanisms
>            to adapt to the specific challenges of the wireless medium, in
>            particular intermittently lossy connectivity.  This
>         document defines
>            a network control loop that optimizes the use of
>         constrained spectrum
>            and energy while maintaining the expected connectivity
>         properties,
>            typically reliability and latency.  The loop involves OAM,
>         DetNet
>            Controller Plane, and PREOF extensions, and specifically a new
>            recovery Function called PAREO and a new Point of Local Repair
>            operation, that dynamically selects the DetNet path(s) for
>         the future
>            packets to route around local degradations and failures.
>
>
>
>
>         The IETF Secretariat
>
>     -- 
>     RAW mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/raw
>