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

["Pascal Thubert (pthubert)" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, August 2, 2023 4:31 AM
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Adrian Farrel ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Lou Berger ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : samedi 29 juillet 2023 15:40
À : Pascal Thubert (pthubert) <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/raw