[Raw] How do tracks differ from TE protection paths? was: Some comments/questions on RAW Architecture

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

Dear all:

Lou said:
"
In reading the definition of the tracks, the term seems quite aligned/similar to TE protection paths and segments.  Keep in mind that DetNet PREOF is just one form of service restoration supported in IETF TE, i.e., the 1+1 form.  A track reads to me to be something that can be composed or combine 1:1, 1:N and even 1+N, and have interesting
(uncoordinated) protection switching based on actual network/link
(channel) state.  I suspect we can accomplish the same objectives as Tracks and stay consistent with existing DetNet and TE(AS) terminology.
"

My short answer: 
There's too much preconception with the term path as an experience and too much slight overload of the term path in different WGs, sometimes without a clear terminology but rather an intuition that means confusion. We need a term that reflects the statistical expectation and overloading path will entertain / augment the existing confusion. Defining Track allows us to point explicitly on what happens at DetNet and RAW that is really new.

Longer answer:
My view is that the concept of path in the art of IETF is incompatible with that of Track because a path has the classical IP expectation of 1 packet in, the same packet along, and then out. In TE, even in the 1+N case, the packet is replicated first, and then each copy follows a path where the assumption above stands. A  copy is an atom that remains in its integrity along the path. The path can thus be defined after the fact as the experience of the (copy of the) packet. And we can define a protection path as a set of such paths for multiple copies, either sent at the same time or deferred.

I believe that in RAW, and even in DetNet, the capability to replicate inside the network already defeats that definition. When a packet is replicated inside the network, which one is the original that follows the path? What is the path for the copy? If a relay fragments a packet into N frags, uses network coding N->P, P>N between the fragments as redundancy technique, and then distributes the fragments across the feasible next-segments within the Track, the packet is not more an atom, and there's no "path" that the packet experiences. The packet is literally disseminated (as opposed to flooded as an atom) and reconstituted at arrival. 

If I'm unclear, maybe a quantic analogy will help. The path is the observation/measurement of how an atomic packet traversed the network (which hole the photon passed through). In the case of network coded fragments, there are superimposed "path" states, each with its own probability. The Track describes the superimposition, not the measurement. It is expressed as the set of statistical possibilities for a future packet, not the experience of one. 

Note: The sum of probabilities is typically more than 1 due to redundancy methods, and the PSE dynamically DECIDEs the new values for those statistics to place them on segments that appear to work at this time based on ORIENTation by the PCE (D and O in OODA).

In terms of IETF inheritance, the term Track is already defined in the art of a deterministic wireless RFC (RFC 9030) and a method to program Tracks in a wireless network is being defined at ROLL (draft-ietf-roll-dao-projection). The definition of Track at RAW, ROLL, and 6TiSCH are consistent, though ROLL can only build Tracks that are DODAGs (it cannot build bidir North/South segments).

I hope this helps,

Pascal


-----Original Message-----
From: Lou Berger <[e-mail]> 
Sent: lundi 21 mars 2022 2:25
To: [e-mail]
Cc: RAW WG <[e-mail]>
Subject: Some comments/questions on RAW Architecture

Pascal, Georgios,

In looking to provide input on the framework document I realized I had some basic questions on the architecture document. While I also have more detailed comments/questions on the Architecture document, I'll stick to the high level comments/questions here. Also, my apologies for not getting them out sooner, but I figured it was still better to document here than just "at the mic" in tomorrow's session.

1) What does the term "RAW" refer to in the context of the architecture? 
Is it a new/standalone set of mechanisms or is it an addition or an extension, or a usage of IETF defined technologies?

I find that reading the architecture, I'm really  unsure.  The current working is a bit mixed, e.g.,

    Reliable and Available Wireless (RAW) provides for high reliability
    and availability for IP connectivity over a wireless medium.

this sounds like something new/independent

    It builds on the DetNet Architecture and
    discusses specific challenges and technology considerations needed to
    deliver DetNet service utilizing scheduled wireless segments and
    other media, e.g., frequency/time-sharing physical media resources
    with stochastic traffic.

this sounds evolutionary.

I was expecting the RAW WG to build on DetNet and other IETF Traffic Engineering (TE)  bodies of work. In other works something along the lines of:

     The RAW Architecture builds on the DetNet Architecture and
     standard IETF Traffic Engineering concepts and mechanisms to
    deliver service across any combination of wired and wireless
    network segments. ...

I think the document and the used terminology must be clear even we're
(understandably) loose in the usage of the "RAW" term in our discussions.

2) Are RAW solutions limited to IPv6 and a limited set of wireless technologies?  I think the framework says/implies no, but the architecture is less inclusive. e.g.,
    RAW provides DetNet elements that are specialized for IPv6 flows
    [IPv6] over selected deterministic radios technologies [RAW-TECHNOS].

I would expect that at least at the Architecture level that there would be no exclusion of IETF networking technologies (including v4 and MPLS) and any SDO-defined wireless technology.  I certainly understand needing to focus and prioritize work on specific technologies, but that is practical choice not a limitation that should be codified in the architecture.

Somewhat related, but of less importance, it's probably worth mentioning that RAW forwards/switches at the IP, not link layer.

3) How do tracks differ from TE protection paths?

In reading the definition of the tracks, the term seems quite aligned/similar to TE protection paths and segments.  Keep in mind that DetNet PREOF is just one form of service restoration supported in IETF TE, i.e., the 1+1 form.  A track reads to me to be something that can be composed or combine 1:1, 1:N and even 1+N, and have interesting
(uncoordinated) protection switching based on actual network/link
(channel) state.  I suspect we can accomplish the same objectives as Tracks and stay consistent with existing DetNet and TE(AS) terminology.

4) Is RAW limited to PCE-based centralized solutions?

DetNet introduced the term Controller Plane to cover all types of control supported by the IETF TE architecture, i.e., fully centralized, fully distributed, or any hybrid combination of centralized/distributed control.  The Architecture reads as supporting only one combination of - PCE for paths, PSEs for tracks (aka protection segments) .   PSEs read as also doing the actual protection switching, but this is outside the scope of this comment.

Hereto, I see no reason for the architecture to limit the scope of the Controller Plan solutions that could be standardized as part of RAW. (Yes PCE-based approaches are likely the first to be standardized, but that's not an architecture level decision.)


Those are my top comments.  While substantive, I suspect addressing these comments will result in some refactoring and rewording -- but not a major change to the document.

Thank you, and speak to you soon. (Unfortunately, just virtually this
meeting...)

Lou