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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Rick,

I do see value.

Thanks,

Carlos


On Mon, Jun 6, 2022 at 9:11 PM Rick Taylor <[e-mail]>
wrote:

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