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

[Pascal Thubert <[e-mail]>]

done!

Le 20/10/2023 à 14:49, Lou Berger a écrit :
>
> 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
>>