[Raw] IPv6 - only ? [was Some comments/questions on RAW Architecture]

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

Dear Lou and all:

Lou asked (more below): Are RAW solutions limited to IPv6 and a limited set of wireless technologies?  

<Pascal> 

For IPv6, our charter has no such restriction, so I agree there's a need to rephrase anything that could be confusing.

The quoted text to the water not the pipe. Since we are reusing DetNet flow recognition we could support the exact same flows. 

My understanding is that regardless of how they are encapsulated for transport, the application flows are still IP flows.
The current text recognizes IP using the DetNet framework based on the 5-6 tuple. The issue seems to be really with the v6 piece.
So my suggestion is to remove the "v6" in "IPv6 flows". 

For the technologies, the charter is not restrictive but does not boil the ocean either. So it lists the technologies that we claim to support, and we echoes that with [RAW-TECHNOS].

Suggestion 

OLD TEXT


NEW TEXT:

    RAW provides DetNet elements that are specialized for IP flows over deterministic radios technologies such as listed in [RAW-TECHNOS].

</Pascal>

Works?

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
>