Re: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt

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

Hello Don

Whao, that's a lot! Many thanks. Let's see below:



> Remove "Track" - use "RAW protection" or "Active RAW protection paths"
> Rational: These concepts are
> covered in many IETF drafts but here are a few:
> - TEAS terminology 3272bis and MPLS FRR 4090 terminology As well:
> DetNet 8655 M:n protection None, 1:1, 1+1,  detour LSP, local
> protection.  Replication, Ordering Elimination PREOF.

I'm good with "protection" and I agree with the history you point out. The way we use the Track appears consistent with that term to me too.
I'm not good with "RAW" since though RAW is using the concept, it did not create it and is not the end of it.

We cannot ignore how much work has taken place at ROLL and 6TiSCH, which contribute to the work on reliable and available Wireless by providing the route installation and the forwarding over TSCH, respectively. 

Just look at https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection. I cannot easily go and tell ROLL that the term they have been using forever must now change because of RAW. And This draft is the only way I'm aware of to build the Tracks in a centralized fashion - unless we argue that PCEP is a valid contender in a wireless mesh?

I suggest we settle for "Protection Track".


> Remove Network Plane - It is a Data plane or a control plane.  Rational
> Network plane is not a common term.
> 

See section   "4.4.3.  The Network Plane" of RFC 8655

> Remove OODA. - Rational the OODA loop is one type of feedback loop
> common in cybersecurity.  In RAW there are multiple feedback loops.

It's a very abstract model and that's the only one we have defined a mapping for. It fits very well the detnet network plane roles of PCE, PSE, OAM and PAREO, respectively.
Do you have something in mind that does not match that model? Should we describe it in the architecture?


> 
> Details:
> Reading over the RAW architecture I would remove Track and refer to
> places where Track is used as as RAW protection and active RAW
> protection paths
> - This reuses IETF terminology.
> RFC 9030 defined a Track but it is not common use outside
> that group.

It is used in the IETF wireless / IoT groups in INT area and RTG Area.


> The WG should then decide if a single term such is Track (or other) can
> be used.  My issue with the term Track is it is singular in nature and
> the usage here varies from singular to multiple.

Agreed


> There are two fundamental concepts:
> a protection set and
> the active protection set.

True. I figured from the discussion with Lou that the "active protection set" is a TE path, so I changed the terminology to that in the latest publication. Was that wrong? Note that as I insisted at the WG meeting in London, the 2 sets are not of the same nature. The former is a potential, the latter is an actual. Using "protection set" for both hides that subtlety under the carpet.


> Currently, the RAW Architecture talks about a Network plane.
> I think it means a data plane.  Network plane is not widely used.
> 
> I would remove OODA loop.   There is not much reference to
> it in the IETF and I think it is more a security feedback loop than a
> run time operational feedback loop. We have feedback loops. I think the
> PAREO loop stays largely as as you have defined it.

We do not have a PAREO loop. PAREO is the action in OODA.

> RAW (and other networks) have multiple feedback loops.
> Link state with statistics (comprises a topology feedback loop). RAW
> active protection path set and service statistics is another feedback
> loop.

I'm not aware of feedback loop in the data plane though. The closest I'm aware of would be FRR/LFA but that's not really a control loop, more a reflex action to avoid a broken path.

> Currently the architecture allows RAW to ask for a path to be computed
> (one or several protection paths).
> Then RAW uses local decisions locally decide if it needs to refine the
> active path out of the set.  To maintain stability over all paths, path
> allocations of capacity should be sized to the fullest use of the
> protection path set assigned although locally RAW can decide not to use
> all paths.

True. Do we need more words in the document on that?

> I think for path computation RAW should assume it uses all resource
> allocated in "active RAW protection". When less resources are used over
> time
> - then it should relinquish the resources.
> This slow adjustment of the actual usage is another feedback loop.
> 
> Here is what I think this looks like.
> 
>                    +--------------+
>         +--------->+ Compute RAW  +-----------+
>         |          | Protection   |           |
>         |          | Paths        |           |
>         |          +--------+-----+           |
>         |                   ^                 |
>         |                   | Network         V
>  +------+---------+         | Link      +-----+-----+
>  |Request RAW     |         | State     |           |
>  |Service  Path   |         +-----------+Deploy and |
>  |                |                     |Monitor    |
>  |Traffic Request |         +-----------+RAW        |
>  |[Add or delete  |         | Service   |protection |
>  | Resources]     |         V State     |           |
>  +------+---------+   +-----+-------+   +-----+-----+
>         ^             |RAW actions  |         ^
>         |             |PAREO        +---------+
>         |             +-----+-------+  Local
>         |                   |          Change
>         |     Service       |
>         |     Change        |
>         +-------------------+

I like this drawing, many thanks. The "Network Link State" is not really correct though. More like "Network Link Stats", one letter, very different meaning. Or both if we consider a permanent stat of 0 to be a link down information.

Just like there's async and periodic OAM-based "state" information on links (passing, not passing, assumed reliability / PDR) to the PSE, there must be periodic and async stats to the PCE. When the stats differ to widely from those used to compute the Track, the PCE may update or rebuild the protection Track. OTOH, if the stats remain in an acceptable range, the PCE will rely on the PSE to adapt and refrain from impacting the Track.

This is the big difference between what the PSE and the PCE see. The PSE sees links as usable or not at one instant. The PCE sees quality stats over long periods. As opposed to classical IGPs the model in radio networks has to accommodate link flapping smoothly. E.g., RPL is built for that, that's why it builds DODAGs as opposed to trees. 

> There are three possibilities:
> - The quality is poor, and more resources need to be
>   requested.  If a RAW service determines that the service
>   is not getting sufficient packets through it should ask
>   for a better RAW protection (set of paths) .
> 
> -The quality meets it targets and allocation of resources  stays
> constant.
> 
> - The quality meets it target but the connection is
>   consuming excessive bandwidth/capacity.  Currently RAW
>   makes this determination locally.  I think that RAW
>   should release resources within
>   some bounds.
> 
> This scheme should be set up to reduce the chance that RAW services
> will compete by over allocating (blocking) or under allocating
> (congesting).


True. Then again as a DetNet Extension, RAW uses provisioned resources so on paper congesting is not part of the game. On paper, there should be enough resources for all RAW flows using all the PCE allocated resources. The game is to save 1) energy and 2) spectrum which can then be used by non-deterministic flows. 

Arguably, the link rate may vary (with MCF). OAM must capture that, and the PSE of some flows will have to react and stop using that link, while for other flows the link will remain usable. Maybe a sentence or 2 to clarify that is in order?

All the best,

Pascal