Re: [Raw] The term RAW in RAW Architecture [was Some comments/questions on RAW Architecture]

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

Dear all:

For some reason Fridays appear to be less loaded than other days.
So I could suggest 4PM or 5PM CET every other Friday?

Keep safe;

Pascal



> -----Original Message-----
> From: RAW <[e-mail]> On Behalf Of Rick Taylor
> Sent: lundi 6 juin 2022 21:11
> To: Pascal Thubert (pthubert) <pthubert=[e-mail]>; Lou
> Berger <[e-mail]>; [e-mail]
> Subject: Re: [Raw] The term RAW in RAW Architecture [was Some
> comments/questions on RAW Architecture]
> 
> Hi Pascal, Lou, all,
> 
> At the last IETF a formal interim on the RAW Architecture draft was
> suggested, perhaps as the kickoff of more regular meetings.
> 
> Obviously this has yet to happen; however, do you feel that there is value
> in an interim in June to continue the valuable discussion on the document?
> 
> If so, do you (Pascal) as an author want to suggest some times/dates that
> work for you and we can hone in on a time of least inconvenience for the
> WG?
> 
> Cheers,
> Eve & Rick
> 
> > -----Original Message-----
> > From: RAW [mailto:[e-mail]] On Behalf Of Pascal Thubert
> > (pthubert)
> > Sent: 06 May 2022 15:44
> > To: Lou Berger; [e-mail]
> > Subject: Re: [Raw] The term RAW in RAW Architecture [was Some
> > comments/questions on RAW Architecture]
> >
> > Hello Lou
> >
> >
> > > > The new text does 2 things:
> > > > - use Lou's proposal with the exception of the explicit reference
> > > > to TE
> >
> > > Why drop the reference? DetNet is built on TE, Raw is built on
> > > DetNet, so this means RAW is too.
> >
> > At the conceptual level, sure. In practice, there is an art of TE at
> > the IETF that we might or might not drag in RAW.
> > For instance, the applicability and preferability of techs like of
> > MPLS and pseudowires on wireless needs to be demonstrated.
> > It might be that the work done at IETF in the context of radios
> > applies better than the one done in the context of ISP networks.
> > As this stage I do not want to take a position of where the solution
> > components comes from, e.g., TEAS, 6TiSCH, ROLL, etc... and feel that
> > using TE is already a step there, but I might well be wrong on that.
> >
> >
> > > > - Present this document as a data plane component to the RAW
> > architecture,
> > > more may come.
> > > >
> > > > Along the same line, should we change the title to something more
> > focused
> > > on the PSE or the OODA loop?
> >
> > I was referring to the title of the document "RAW architecture".
> > Depending on what RAW is going to do in the future, this may be only
> > one piece of the end result. So, isn't "RAW architecture" too wide as
> > a name? Could it be "the RAW OIODA Loop architecture" or something?
> >
> > All the best,
> >
> > Pascal
> >
> > > -----Original Message-----
> > > From: Lou Berger <[e-mail]>
> > > Sent: vendredi 6 mai 2022 15:50
> > > To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> > > Subject: Re: The term RAW in RAW Architecture [was Some
> > comments/questions on
> > > RAW Architecture]
> > >
> > > Hi Pascal,
> > >
> > > I was hoping to see comments from others before responding...
> > >
> > > On 4/22/2022 9:50 AM, Pascal Thubert (pthubert) wrote:
> > > > Dear all;
> > > >
> > > > We did not discuss the below till IETF.
> > > >
> > > > I reread the second item (Lou's rewrite of the abstract) and
> > > > suggest the
> > > following trade off:
> > > >
> > > > OLD
> > > >     Reliable and Available Wireless (RAW) provides for high
> reliability
> > > >     and availability for IP connectivity over a wireless medium.
> The
> > > >     wireless medium presents significant challenges to achieve
> > > >     deterministic properties such as low packet error rate, bounded
> > > >     consecutive losses, and bounded latency.  This document defines
> the
> > > >     RAW Architecture following an OODA loop that involves OAM, PCE,
> PSE
> > > >     and PAREO functions.  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
> > > >
> > > > NEW
> > > >
> > > >     Reliable and Available Wireless (RAW) provides for high
> reliability
> > > >     and availability for IP connectivity across any combination of
> wired
> > > >     and wireless network segments.  The RAW Architecture extends the
> > > >     DetNet Architecture and other standard IETF concepts and
> mechanisms
> > > >     to adapt to the specific challenges of the wireless medium.
> This
> > > >     document defines an architecture element for the RAW data plane,
> in
> > > >     the form of an OODA loop, that optimizes the use of constrained
> > > >     spectrum and energy while maintaining the expected connectivity
> > > >     properties.  The loop involves OAM, PCE, and PREOF extensions,
> and a
> > > >     new component called the Path Selection Engine (PSE).
> > > >
> > > >
> > > > The new text does 2 things:
> > > > - use Lou's proposal with the exception of the explicit reference
> > > > to TE
> > > Why drop the reference? DetNet is built on TE, Raw is built on
> > > DetNet, so this means RAW is too.
> > > > - Present this document as a data plane component to the RAW
> > architecture,
> > > more may come.
> > > >
> > > > Along the same line, should we change the title to something more
> > focused
> > > on the PSE or the OODA loop?
> > >
> > > I'm don't follow these comments...
> > >
> > > > Keep safe;
> > > >
> > > > Pascal
> > > >
> > > FYI I missed your in-line comments below due to it all being quoted.
> > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Pascal Thubert (pthubert)
> > > >> Sent: lundi 21 mars 2022 15:20
> > > >> To: Lou Berger ([e-mail]) <[e-mail]>;
> > > >> [e-mail]
> > > >> Subject: The term RAW in RAW Architecture [was Some
> > > >> comments/questions on RAW Architecture]
> > > >>
> > > >> Dear Lou and all:
> > > >>
> > > >> Lou asked (more below): "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?"
> > > >>
> > > >> <Pascal>
> > > >>
> > > >> Effectively we use "RAW Architecture" a but like if what we do
> > > >> here is the alpha and omega to make wireless near deterministic
> > > >> when we're just providing a set DetNet extensions for OODA loop,
> > > >> and functions more may come in the future. Should we call it "RAW
> > > >> OODA Architecture" or something?
> > > >>
> > > >> </Pascal>
> > >
> > > I think having a tight definition of RAW and RAW architecture will
> > > be useful for the WG and users of RAW technologies.
> > >
> > > >> Lou also points out that the text staring at " It builds on the
> > > >> DetNet Architecture" sounds evolutionary.
> > > >>
> > > >> <Pascal>
> > > >> Evolution is key to survival, ask Covid. More seriously, we may
> > > >> be hitting my non-native limits. I wish this architecture to be
> > > >> foldable into the DetNet family, even though it means that the
> > > >> family will extend, which is neat in my book. So:
> > > >> 1) how bad is evolutionary? Does that contradict the charter ?
> > > >> 2) Should we use, e.g., "extends" as opposed to "builds on"?
> > > >>
> > > >> <Pascal>
> > > >>
> > > >> Finally Lou Proposes the following change:
> > > >>
> > > >> OLD
> > > >>
> > > >>      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.
> > > >>
> > > >> Lou's PROPOSAL
> > > >>
> > > >>       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. ...
> > > >>
> > > >> <Pascal>
> > > >>
> > > >> My 2 cents:
> > > >> *   Our charter builds on DetNet and MANET-DLEP, but not TEAS.
> > > >> *   We have not decided to extend TEAS but be inheritance from
> DetNet.
> > > It sounds like we actually agree,  DetNet is built on TE, Raw is
> > > built on DetNet, so this means RAW is built on TE too. (Note I'm
> > > saying
> > TE/technology
> > > TEAS/Working group).
> > > >> *   I'm probably both biased and ill-informed, but I do believe
> that the
> > > >> work at 6TiSCH - which explicitly considered deterministic flows
> > > >> over one of our selected technologies (see RFC 9030 which BTW
> > > >> also defines the concept of a Track) - may be as good a base to
> > > >> build upon for RAW as other IETF work that roots in MPLS, fiber
> optics, and/or SP networks.
> > > >> *  Whether we do use TEAS work, to which extent, or we do not,
> > > >> will be documented in the framework once the WG settles on that,
> > > >> and we certainly hope for your help doing that.
> > > I agree, use of TEAS defined solutions is something to be defined /
> > > worked out. As above, RAW builds on Detnet, DetNet builds on TE, so
> > > stating that "RAW builds on IETF Traffic Engineering concepts" seems
> > > non-
> > contentious.  I'm
> > > fine if you want to drop "and mechanisms". I think we have to be
> > > equally vigilant in ensuring that a 6TiSCH solution-bias isn't
> > > enshrined in the Architecture.
> > > >> *  At the level of this document (architecture), I believe that
> > > >> the core qualification is not how we'll do it but the fact that
> > > >> it will have to support wireless segments and possibly non
> > > >> wireless segments as well, with as a corollary that we selected
> > > >> wireless techs that can be scheduled to offer the expected
> guarantees.
> > >
> > > I suspect we agree on this.
> > >
> > > Thanks,
> > >
> > > Lou
> > >
> > > >>
> > > >> All in all, I might have missed your point but I'd rather keep
> > > >> that text as is.
> > > >>
> > > >> </Pascal>
> > > >>
> > > >> What do you all think?
> > > >>
> > > >> 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
> > > >>
> > --
> > RAW mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/raw
> --
> RAW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw