Re: [Raw] Some comments/questions on RAW Architecture

[Lou Berger <[e-mail]>]

Hi Pascal

See below.

----------
On September 16, 2022 11:31:31 AM "Pascal Thubert (pthubert)" 
<[e-mail]> wrote:

 > Hello Lou
 >
 > Starting again from your email on July 26th which forwards the 
original one, so you authored both > and >> below:
 >
 >
 >> Hi Pascal,
 >>
 >> I don't think we ever really closed on the issues I raised below. 
Any chance
 >> you can summarize where you think we are on each of the points below 
- like
 >> you did for Balazs?
 >>
 >> Also some additional comments are in line below...
 >>
 >>
 >> On 3/20/2022 9:25 PM, Lou Berger wrote:
 >> > 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.
 >
 > We discussed that at the last IETF RAW WG meeting. My understanding 
is that with RAW we mean what the architecture defines. So the "RAW 
architecture" would be synonymous to "this document".
 >

Sure, I accept and didn't mean to question that the "RAW architecture" 
would be defined by "this document".

My question is more basic: what is the definition of RAW?

Said another way, what does RAW add to DetNet?
For example:
Does it change what services are supported - I don't think so
Does it define a new wireless technology - I don't think so
Does it define how detnet operates over wireless networks - I think so, 
this is what the charter says, but is this sufficient.

I expected that this document would be the place which identified which 
aspects of wireless networks are being leveraged and abstracted to 
support DetNet.  Does this make sense?

For example, I'd expect topics such as "Promiscuous Overhearing", 
"Partial Connectivity" (where not all endpoints are always reachable), 
"Changing Resource Availability", and the ability of the wireless layer 
to provide information to the routing layer (e.g., via DLEP)  to be 
identified as an important aspects.  Of course most of these topics are 
not really unique to wireless (consider the UNI/NNI/multi-layer work 
done for G.709) so the commonality and uniqueness should be called out.

This is the part I think is missing from the RAW definition.

 >> >

 >> > 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.
 >> >
 >> >
 >> I think the abstract is a bit better, but the document remains 
confusing to
 >> me -- for example there's a new section title "RAW vs. DetNet" which 
again
 >> leads to the conclusion that a RAW enabled network is not a superset or
 >> compatible with a DetNet enabled network.  Perhaps changing the 
title of the
 >> section (s/vs/and) and adding a discussion of how a wired and 
wireless Detnet
 >> work with, or over, each other.
 >
 >
 > Renamed to RAW and DetNet.
 >
 > Proposed addition:
 >
 > "
 > 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.
 > "

I think this helps. Thank you.

 >
 >
 >
 >> 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.
 >
 > I answered that one separately. Bottom line is that a Track is the 
potential of any packet that is available at ingress and which usage is 
statistical whereas the path is the experience of one packet than can 
only be known when the packet is observed at arrival. The link between 
the two is the action of PREOF / PAREO all along the path, which can be 
a local decision based on the statistical shape of the potential next 
hop links. The text already covers that but I'd be happy to take 
suggestions that would help the reader understand this with more clarity.
 >

I responded to that mail too, so will look to discuss the specifics there.

I do think this brings up the question of PAREO -- can a RAW network 
operate without protection or a different protection mechanism? (Keep in 
mind the DetNet architecture does *not* require PREOF, certainly the 
current specs do, but other mechanisms.)

 >
 >> > 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...)
 >> >
 >>
 >> I have some additional questions:
 >>
 >> Does the architecture allow for a Wireless DetNet operate without ARQ?
 >> Would it still be called a RAW network?
 >
 > Yes and yes. ARQ is at most a hint that we pass to L2 which is free 
to translate that abstraction in its own terms.
 >
 > I added the following in the PAREO section:
 > "
 >     Because RAW may be leveraged on wired links, e.g., to save power, 
it is not
 >     expected that all lower layers support all RAW capabilities. 
Either way,
 >     RAW will manipulate the abstractions of the lower layer services 
and hint on
 >     the expected outcome, and the lower layer will act on those hints 
to provide
 >     the best approximation of the desired outcome, e.g., a level of 
reliability
 >     for one-hop transmission within a bounded budget.
 > "
 >
 > Please note that Georgios authored that section and I'd rather go by 
him for any major change.

Okay, I'll wait for Georgio.

 >
 >>
 >> What about a Wireless DetNet which operates over a radio technology 
that has
 >> built-in (sub-layer) ARQ - is this allowed? would it still be called 
a RAW
 >> network?
 >
 > I suspect yes if DetNet has an abstraction for it. OTOH, if a plain 
DetNet stack operates over that medium but does not abstract the retries 
(e.g., in the form of a budget of bandwidth and latency) then tis 
becomes a hidden L2 property and this would not really be RAW. E.G., we 
can already do DetNet over TSN over 5G and that's not RAW.

 > RAW adds models and APIs for the PAREO functions,

I think this is a very important point and one that should be one of the 
key points/topics in the architecture document. These APIs are very 
briefly mentioned in section 3.3 and as far as I can tell not 
represented in the figures. Expanding and clarifying this would 
definitely help.

 >and the OODA loop that controls the use of the redundancy dynamically.
 >

The use of an ooda loop in networking is nothing new and I personally 
find the focus on the term not helpful, but accept that this may be a 
style point.

 >>
 >> I think these points are not clear in the architecture document and 
should
 >> be.
 >>
 >
 > I committed 
https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-07.txt so 
you can observe the proposed text, ready for more new text or fixes.
 >

Thanks and I have reviewed the latest version in my comments.

Thank you again for the discussion/responses.

Lou

 > All the best, and many thanks again, Lou.
 >
 >
 >> Thanks!
 >> Lou
 >>
 >> > Lou
 >> >
 >> >