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

[Xavi Vilajosana Guillen <[e-mail]>]

works for me too and I do see value on them.

kind regards
X

Missatge de Pascal Thubert (pthubert) <pthubert=[e-mail]>
del dia dc., 8 de juny 2022 a les 15:38:

> 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
> --
> RAW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
([phone]
[e-mail] <[e-mail]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­

-- 



INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE 
CATALUNYA (UOC)

Us informem que les vostres dades identificatives i les 
contingudes en els missatges electrònics i fitxers adjunts es poden 
incorporar a les nostres bases de dades amb la finalitat de gestionar les 
relacions i comunicacions vinculades a la UOC, i que es poden conservar 
mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a 
accedir a les vostres dades, rectificar-les i suprimir-les i altres drets 
reconeguts normativament adreçant-vos a l'adreça de correu emissora o a 
[e-mail] <mailto:[e-mail]>.

Aquest missatge i qualsevol 
fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i 
s'adrecen únicament a la persona o entitat a qui s'han enviat.

Així 
mateix, posem a la vostra disposició un delegat de protecció de dades que 
no només s'encarregarà de supervisar tots els tractaments de dades de la 
nostra entitat, sinó que us podrà atendre per a qualsevol qüestió 
relacionada amb el tractament de dades. La seva adreça de contacte és 
[e-mail] <mailto:[e-mail]>.
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE 
LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)
Os informamos de que vuestros 
datos identificativos y los contenidos en los mensajes electrónicos y 
ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin 
de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que 
pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis 
ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos 
y otros derechos reconocidos normativamente dirigiéndoos a la dirección de 
correo emisora o a [e-mail] <mailto:[e-mail]>.
Este mensaje y 
cualquier fichero que lleve adjunto, si procede, tienen el carácter de 
confidenciales y se dirigen únicamente a la persona o entidad a quien se 
han enviado.
Así mismo, ponemos a vuestra disposición a un delegado de 
protección de datos que no solo se encargará de supervisar todos los 
tratamientos de datos de nuestra entidad, sino que podrá atenderos para 
cualquier cuestión relacionada con el tratamiento de datos. Su dirección de 
contacto es [e-mail] <mailto:[e-mail]>.


UNIVERSITAT OBERTA DE 
CATALUNYA (UOC) DATA PROTECTION INFORMATION
Your personal data and the data 
contained in your email messages and attached files may be stored in our 
databases for the purpose of maintaining relations and communications 
linked to the UOC, and the data may be stored for as long as these 
relations and communications are maintained. If you so wish, you can 
exercise your rights to access, rectification and erasure of your data, and 
any other legally held rights, by writing to the sender’s email address or 
to [e-mail] <http://[e-mail]>.
This message and, where 
applicable, any attachments are confidential and addressed solely to the 
individual or organization they were sent to.
The UOC has a data protection 
officer who not only supervises the data processing carried out at the 
University, but who will also respond to any questions you may have about 
this data processing. You can contact our data protection officer by 
writing to [e-mail] <http://[e-mail]>.