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

[Greg Mirsky <[e-mail]>]

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