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

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

Hello Janos



Many thanks for your review!



>  I think RAW, i.e., wireless aspects actually rather reside in the Forwarding sub-layer (not in the Service sub-layer).

> The Service sub-layer is pretty much IP in this case. Ideally, it is hidden from the Service sub-layer as much as possible what kind of forwarding is used in the Forwarding > sub-layer, e.g., whether it is wireline or wireless. (Well, the Forwarding sub-layer may provide some certain APIs towards the Service sub-layer if we want to.)





We defined the sublayers by listing functions as hints as opposed to mapping to IP or L2. Our intention (Norm and I) at the start was that the DetNet operated at L3 but deterministic networking at large could be widely done at either L2 or L3 (or a mix) and the abstractions and service, from a distance, would be the same.



RAW being DetNet it is L3, so neither wireless nor wired, though it is meant to address gaps that are more common in wireless like quick flaps, reliability degradation, and PHY speed variations. Wireless, like wire, is only observed and requested through APIs. As Lou said, some aspects like promiscuous and ARQ are more commonly observed on wireless, but are not exclusive to wireless. We provide a L3 architecture that is sensitive to those elements but does not include them since they are operated in another layer altogether.



The RAW architecture is focused on a fast protection/recovery loop. This is why the main operation (PAREO actuation and OAM processing/compiling ) is in the DetNet (=> L3) service sublayer. But not only:



“

    +------------------------------+ +--------------------------------+

    |                              | |                                |

   .....................................................................

    |                              | |                                |

    | +--------------------------+ | | +----------------------------+ |

    | |     aCPF                 | | | |         aCPF               | |

    | +--------------------------+ | | +----------------------------+ |

    | +----------+  +------------+ | | .-.-.-.-.-.--.  .-.-.-.-.-.--. |

    | | PLR      |  | OAM        | | | | Distr. PLR |  | Distr. OAM | |

    | |          |  | Supervisor | | | |            |  | Supervisor | |

    | +----------+  +------------+ | | .-.-.-.-.-.--.  .-.-.-.-.-.--. |

    |                              | |    optional         optional   |

       RAW Management sub-layer

   .....................................................................

       DetNet Service sub-layer

    |                              | |                                |

    | +----------+  +------------+ | | +------------+  +------------+ |

    | | PAREO    |  |  OAM       | | | |  PAREO     |  |  OAM       | |

    | | Actuator |  |  Observer  | | | |  Actuator  |  |  Observer  | |

    | +----------+  +------------+ | | +------------+  +------------+ |

    |                              | |                                |

       DetNet Service sub-layer

   .....................................................................

       DetNet Forwarding sub-layer

    |                              | |                                |

    |               +------------+ | |                 +------------+ |

    |               |In-Situ OAM | | |                 |In-Situ OAM | |

    |               +------------+ | |                 +------------+ |

    |                              | |                                |

    +------------------------------+ +--------------------------------+



            End System or                       Relay

          Ingress Edge Node                     Node



          Figure 4: RAW functional posture within DetNet sublayers



“



Is there a change you would suggest to this picture?











> As I read, the 1st paragraph in section 4.3 is actually along these lines

https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html#name-raw-and-detnet

> “RAW leverages the DetNet Forwarding sub-layer”

> “RAW enhances DetNet to improve the protection against link errors such as transient flapping that are far more common in wireless links.” – Well, this reads to me to be in the Forwarding sub-layer.



Well, protection is service sub-layer actually (section 2.1 of RFC 8655). Forwarding is packet handling, like find which buffer and which protection path for this packet. The PAREO actuator impacts the forwarding operation for future packets but does not necessarily run on every packet, see the discussion with David.





> However, I’m quire unsure of the beginning of the 2nd paragraph in section 4.3:

> “RAW extends the DetNet Stack (see fig 4 of [https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html#RFC8655]) with additional functionality at the DetNet Service sub-layer for the PLR operation.”

>  and the location of PLR in Figure 4, where the PLR is not in the data plane.



You’re correct about the inconsistency. The PLR is a piece of the controller that was exported to the forwarding devices. The discussion with Greg placed that component in the management sublayer. The text that you point out is a victim of the renaming and the component it discusses is now called PAREO actuator. Proposed beginning of that section:

“

   RAW leverages the DetNet Forwarding sub-layer and requires the

   support of in-situ OAM in DetNet Transit Nodes (see fig 3 of

   [RFC8655] for the dynamic acquisition of link capacity and state to

   maintain a strict RAW service, end-to-end, over a DetNet Network.

   RAW enhances DetNet to improve the protection against link errors

   such as transient flapping that are far more common in wireless

   links.  Nevertheless, the RAW methods are for the most part

   applicable to wired links as well, e.g., when energy savings are

   desirable and the available path diversity exceeds 1+1 linear

   redundancy.



   RAW adds a Management sub-layer that operates in the DetNet

   Operational Plane.  The RAW Management sub-layer typically runs only

   in the DetNet Ingress Edge Node or End System, though it may also run

   in DetNet Relay Nodes when the RAW Control sub-layer is distributed

   along the recovery graph.  The RAW Management sub-layer functionality

   includes the PLR that decides the DetNet Path for the future packets

   of a flows and controls the PAREO Actuators along the DetNet Path

   through specific signaling, and the OAM Supervisor that triggers, and

   learns from, OAM observations, and feeds the PLR for its next

   decision.



   RAW extends the DetNet Stack (see fig 4 of [RFC8655]) with additional

   functionality at the DetNet Service sub-layer for the actuation of

   the PLR decision by the PAREO Actuator.  Layer-3 in general and

   DetNet in particular operates on abstractions of the lower layers and

   through APIs to control those abstractions.  For instance, DetNet

   already leverages lower layers for time-sensitive operations such as

   time synchronization and traffic shapers.  Because the performances

   of the radio layers are subject to rapid changes, so RAW needs more

   dynamic gauges and knobs.  To that effect, the DetNet PREOF is

   extended with the PAREO capabilities (see Section 5.6) and the RAW

   PAREO Actuator manages dynamically the PAREO operations, which may be

   performed either within the DetNet sublayers or at a lower layer,

   using a common radio abstraction and APIs in the latter case.  In

   particular, PAREO needs the capability to push reliability and timing

   hints like suggest X retries (min, max) within a time window, or send

   unicast (one next hop) or multicast (for overhearing).  The other way

   around RAW needs hints about the radio conditions like L2 triggers

   (RSSI, LQI, ETX...) over all the wireless hops.  This information is

   useful to both the aCPF and the PLR.



“



> I think PLR should be located in the Forwarding sub-layer, but I may have misunderstood the intention.



I think the operation you have in mind is the realization of the PLR decision. We did not create a box for it. Should we? What name? Is there really something new there vs. DetNet?



> As far as I understood, the intention with the PLR is fast reaction to actual wireless situation, i.e., where to send a given packet actually.



True, and it reacts to signals that arrive asynchronously to the packets, for the most part. They are either coming from L2 or from OAM.







               |

        packet | going

      down the | stack

    +==========v==========+=====================+=====================+

    |   (iOAM + iCTRL)    | (L2 Triggers, DLEP) |       (oOAM)        |

    +==========v==========+=====================+=====================+

    |     Learn from      |                     |    Learn from       |

    |    packet tagging   >       Maintain      <    end-to-end       |

    +----------v----------+      Forwarding     |    OAM packets      |

    | Forwarding decision <        State        +---------^-----------|

    +----------v----------+                     |      Enrich or      |

    +    Retag Packet     |  Learn abstracted   >     Regenerate      |

    |    and Forward      | metrics about Links |     OAM packets     |

    +..........v..........+..........^..........+.........^.v.........+

    |                          Lower layers                           |

    +..........v.....................^....................^.v.........+

         frame | sent          Frame | L2 Ack        oOAM | | packet

          over | wireless        In  |                 In | | and out

               v                     |                    | v



                         Figure 10: PLR Interfaces







> Imo, this is very similar to FRR, see, e.g.: https://datatracker.ietf.org/doc/html/rfc5286. A key aspect is that the alternate next hops are precalculated. That is, it resides in the data plane, no control plane reaction is needed.



Hum FRR is still reroute. It installs new path in the forwarding plane (think software operation downloading a new FIB) and then the forwarding plane (think silicon now) uses the new paths possibly with no idea that it is a FRR path. Same here.



> I guess a more recent (segment routing) document on the subject with PLR in it is: https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa, see, e.g.: “no need for any co-ordination or message exchange between the PLR and any other router in the network.”

Note that segment routing is part of the DetNet Forwarding sub-layer (not the Service sub-layer).



Like RAW, SR is a lot of things; the SRH operation (execution) is indeed forwarding plane. The decision of which SRH to insert upon which condition is control plane. Now we have this interesting 3D problem of how our planes intersect those planes with similar names, e.g., DetNet Controller plane and usual control plane.



> Perhaps I’m the only one with these kind of thoughts.

> If not, then perhaps it might be good to converge on PLR (e.g., its location in the architecture) before figuring out what actual changes are needed in the draft.



Let’s see how others react. For now, you debunked at least one bug and that already very valuable. Committed as af8771a<https://github.com/raw-wg/raw-architecture/commit/af8771aeb4bc7dad5d2ae012cd53a4581e63f9df>

Many thanks!

Pascal
From: Janos Farkas <Janos.Farkas=[e-mail]>
Sent: Monday, July 31, 2023 4:02 PM
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]; Adrian Farrel ([e-mail]) <[e-mail]>; Greg Mirsky <[e-mail]>; Lou Berger ([e-mail]) <[e-mail]>
Subject: RE: Terminology: draft-ietf-raw-architecture-14.txt and what's still nuclear

Dear Pascal, all,

Many thanks for the updates!
Really great improvements towards architectural cleanliness.

Otoh, distillation may reveal further questions and further distillation. 😉

For instance, now that it is called PLR, it triggers a couple of questions on my part. (Well, with the assumption that I have some clue on PLR.)

Perhaps one step back first:
We actually introduced the division of DetNet data plane to Forwarding sub-layer and Service sub-layer for architectural cleanliness during DetNet data plane design team discussions. Furthermore, in order to divide (and conquer) in the sense to be able to identify the functions and to place them to some order, i.e., for functional decomposition.

I suppose, the RAW architecture would follow DetNet architectural principles and place the RAW related functions accordingly.

I think RAW, i.e., wireless aspects actually rather reside in the Forwarding sub-layer (not in the Service sub-layer).
The Service sub-layer is pretty much IP in this case. Ideally, it is hidden from the Service sub-layer as much as possible what kind of forwarding is used in the Forwarding sub-layer, e.g., whether it is wireline or wireless. (Well, the Forwarding sub-layer may provide some certain APIs towards the Service sub-layer if we want to.)

As I read, the 1st paragraph in section 4.3 is actually along these lines
https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html#name-raw-and-detnet
“RAW leverages the DetNet Forwarding sub-layer”
“RAW enhances DetNet to improve the protection against link errors such as transient flapping that are far more common in wireless links.” – Well, this reads to me to be in the Forwarding sub-layer.

However, I’m quire unsure of the beginning of the 2nd paragraph in section 4.3:
“RAW extends the DetNet Stack (see fig 4 of [RFC8655<https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html#RFC8655>]) with additional functionality at the DetNet Service sub-layer for the PLR operation.”
and the location of PLR in Figure 4, where the PLR is not in the data plane.

I think PLR should be located in the Forwarding sub-layer, but I may have misunderstood the intention.

As far as I understood, the intention with the PLR is fast reaction to actual wireless situation, i.e., where to send a given packet actually.
Imo, this is very similar to FRR, see, e.g.: https://datatracker.ietf.org/doc/html/rfc5286. A key aspect is that the alternate next hops are precalculated. That is, it resides in the data plane, no control plane reaction is needed.
I guess a more recent (segment routing) document on the subject with PLR in it is: https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa, see, e.g.: “no need for any co-ordination or message exchange between the PLR and any other router in the network.”
Note that segment routing is part of the DetNet Forwarding sub-layer (not the Service sub-layer).

Perhaps I’m the only one with these kind of thoughts.
If not, then perhaps it might be good to converge on PLR (e.g., its location in the architecture) before figuring out what actual changes are needed in the draft.

My 2 cents,
János

ps:
Sorry for late commenting. It was not the plan. And now we are hit by August = vacation. I’m not sure how much I can chime in the discussion from vacation. I just thought sharing the comment instead of waiting till September.


From: detnet <[e-mail]<mailto:[e-mail]>> On Behalf Of Pascal Thubert (pthubert)
Sent: Sunday, July 30, 2023 10:39 PM
To: [e-mail]<mailto:[e-mail]>; Adrian Farrel ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>; Lou Berger ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Detnet] Terminology: draft-ietf-raw-architecture-14.txt and what's still nuclear


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