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

[Don Fedyk <[e-mail]>]

Hi Pascal
>
>
>Hello Don
>
>Whao, that's a lot! Many thanks. Let's see below:
>
My goal is just to give the WG the opportunity to come to
consensus on the terminology.   
>
>
>> 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.

My point was "Track" is new to me - not been following Roll  
perhaps my bad but what I offered to do was define Track 
without using the term and see if the WG agreed Track was
what to call it. 

I caught my self saying "protection path" then realized when 
talking with Lou that "Protection" embodies the whole concept.   
>
>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.

I only used the term to mean the RAW flavor of protection.
I'm fine dropping that. 
>
>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?

Well, it points to RAW as the defining place for Track yes 
I see. 

>
>I suggest we settle for "Protection Track".

Again, not my decision but the WGs. Perhaps 
- Protection as the superset 
- Protection Track is then the active set of paths in that
  protection scheme? 
- And Protection Tracks are the active set of paths for
  separate services? 

Googling images of track I realize that I like "lanes". 
Protection lanes?  Was lanes considered? Lanes are a subset of 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

I see it is a composite plane and still _rarely_ referenced in
DetNet.  
I'm familiar with data plane, control plane, management plane
and Network.  So OK my bad.  If the WG thinks it brings
clarity then it is an established term.


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

It is the "orient" part I think is being forced. 
OODA looks to me like a larger system of multiple feedbacks. 
It is a general system and can be fitted to many situations.

There are multiple feedback loops.  

In control loops you have a system with an operating goal, 
a measurement function and feedback to maintain the goal. 
There is no orienting measurement is implicit in the
feedback loop design.  Since we deal with packets and paths
we have discrete steps thresholds and actions.  

There is also in theory a network manager role that tries to
optimize over all service - maximizing network utility
however when services are equal priority established
services win over not yet established services. When
priority is involved higher priority services win.   
I  contend this higher level does not exist and you either 
have equal services FIFO or priority services or both. 

Again, a question for WG. Does OODA bring clarity over a
simple feedback?


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

I agree. 
>
>
>> 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.

Yes I agree I used the wrong wording for PAREO. 
>
>> 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.A

The feedback loop for QoS is RFC2386. Generally considered
not a good idea. This is why I questioned the use 
of PAREO actions and why I suggest they should be limited.  

>
>> 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 so to alleviate the instability concerns.
>
>> 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.

Yes full link capacity to degraded to zero. I think you have
better wording. 

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

Yes, Even if you over allocate bandwidth there are cases where a 
loss will cause congestion. You can argue for queuing that 
sacrifices other flows before RAW flows but ultimately 
you may not be satisfying.  
Some environments/wireless links may be bandwidth starved. 
>
>All the best,
>
>Pascal

And I apologize for not having given input earlier.  

Cheers
Don
>
>