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

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

Hello Lou:

Action on the todo below. I reduced the intro to focus a new section on what RAW is, reusing the extensive text that made the intro so long. In that process, I added text to your point below. This text makes up for most of the diff from 07 to 08 https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-08. 

I then pushed 09 which is a reshuffle rather than an addition, separating the diffs for your convenience. 09 is hopefully more readable for the new reviewers with a better ordering of the way things are introduced / presented.

Since it seems the text may have been read as if we are changing the wireless technology I  touched a bit the sentence about the L3 operation to make it even more clear that we do not touch L2.
"
   Operating at the Layer-3, RAW does not change the wireless technology
   at the lower layers.  OTOH, it can further increase diversity in
   the spatial, time, code, and frequency domains...
"

To you other point about not adding new conceptual services, the text now reads:
"
   RAW improves the DetNet services by providing elements that are
   specialized for transporting IP flows over deterministic radios
   technologies such as listed in [RAW-TECHNOS].
"

I hope 09 provides the appropriate improvements per your suggestions below.

All the best;

Pascal
> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mercredi 19 octobre 2022 18:34
> To: Lou Berger <[e-mail]>; [e-mail]
> Cc: RAW WG <[e-mail]>
> Subject: RE: Some comments/questions on RAW Architecture
> 
> Hello Lou
> 
> Many thanks for your comments!
> 
> 
> > 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.
> We are in sync here
> > 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?
> It does. We have introduced https://www.ietf.org/archive/id/draft-ietf-
> raw-architecture-07.html#name-raw-vs-upper-and-lower-laye with this goal
> in mind. We could list more aspects of wireless that are abstracted to L3,
> but I would not claim to be exhaustive, because forgetting something now
> would mean ignoring it in the future.
> 
> > 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.
> 
> WFM, todo for me, to propose text along those lines before cut off.
> 
> >> 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.)
> 
> I believe that the current RAW work is all about optimizing the use of
> protection that is necessary to compensate for the unreliability that is
> inherent to wireless links. Compared to PREOF, PAREO has a richer panel
> and that' s good news because all this is much needed to achieve a
> reliable delivery.
> 
> Let me dig the other draft and answer that.
> 
> All the best
> 
> Pascal
> 
> 
> 
> From: Lou Berger <[e-mail]>
> Sent: mercredi 28 septembre 2022 14:21
> To: Pascal Thubert (pthubert) <[e-mail]>; draft-ietf-raw-
> [e-mail]
> Cc: RAW WG <[e-mail]>
> Subject: Re: Some comments/questions on RAW Architecture
> 
> Hi Pascal
> See below.
> ----------
> On September 16, 2022 11:31:31 AM "Pascal Thubert (pthubert)"
> mailto:[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
> >> >
> >> >