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

[Don Fedyk <[e-mail]>]

Hi Pascal 

Here are the changes to terms that I think would bring more clarity. 
If the WG and you agree on these points I'm happy to help integrate them into the document. 

I've used a fixed font because I included an ascii art diagram. 
(If your mail reader mangles this, I can send you the text separately.) 

Cheers
Don 


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. 

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

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

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.   
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.  
There are two fundamental concepts:
a protection set and 
the active protection set. 

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

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