Re: [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=
40cisco.com@dmarc.ietf.org> 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 <gregimirsky@gmail.com>
> *Sent:* Wednesday, August 2, 2023 4:31 AM
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
> *Cc:* raw@ietf.org; Adrian Farrel (adrian@olddog.co.uk) <
> adrian@olddog.co.uk>; Lou Berger (lberger@labn.net) <lberger@labn.net>;
> detnet@ietf.org
> *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) <
> pthubert@cisco.com> 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 :* internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Envoyé :* samedi 29 juillet 2023 15:40
> *À :* Pascal Thubert (pthubert) <pthubert@cisco.com>
> *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
> RAW@ietf.org
> https://www.ietf.org/mailman/listinfo/raw
>