Re: [Detnet] WG Last Call: draft-ietf-raw-architecture-11

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

Hello Lou



  *   I think you should feel free to use as many references as needed to help give context to the reader.

Yes, without inundating the reader with references that he will not look at because there are too many. I’m concerned about pushing too many MPLS spec towards wireless people when the traffic we observe in that space is purely IP.

The main thing I appear to be missing when incorporating RFC 4427 is protection path. RFC 6372 uses it a lot but does not define it does it?. 2 questions there: 1) is there an architecture/ terminology reference for it or does it only show up in specs; 2) are the definitions in 4427 the ones that are still currently agreed upon by the community?



  *   Two other terms we discussed as being relevant:
  *   Recovery Domain [RFC4427]  This is also sometimes referred to as a Protection Domain when preprovisioned paths are used to provisioned ("protection") paths are used to support recovery.

Yes, this is one of the reasons why I picked that reference. It has ample discussion and definitions on recovery. My intention in the draft it to craft text indicating that as the introduction to the reference in the terminology section.

  *   While less used we did find the terms "protection group" used to represent the set of protection paths used to support service protection.  "recovery group" is similarly defined [RFC6372] as a more general term.
OK, RFC 6372 is a great reference, ultra rich and quite heavy read. Section 4.7 might be particularly relevant. I’m a bit concerned about using it though. 1) the terminology section is so short, takes many things for granted, I’m still lacking the definitions of protection path and groups which is what I’m after. And 2) then again, the context and mindsets are MPLS which is not the natural background for wireless people, so 3) implicit does not work well for the non-MPLS-educated reader and 2) the term “label” all over the place seems to constrain the applicability of the text by RAW and seems to implicitly indicate that RAW requires MPLS, which is not desirable considering the wireless context

The outcomes could be either that a) we find definitions that do not rely on labels or b) we redo our definitions such that the label-based technologies in the MPLS references fit as instances of the definitions.

All the best,

Pascal
From: Lou Berger <[e-mail]>
Sent: Thursday, July 27, 2023 6:56 AM
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Eve Schooler <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; John Scudder <[e-mail]>
Subject: Re: [Detnet] WG Last Call: draft-ietf-raw-architecture-11


Pascal,

The slide didn't come through too well, so I've cut and past from the posted deck, as well as added some responses.
Terminology
• Lou’s issues against north/south (overload), and Track (new term, useful?, existing alternative?)
• Short list of MPLS related art (with definitions)
• RFC 3469 Framework for Multi
Protocol Label Switching (MPLS) based Recovery RFC 4090 Fast Reroute Extensions to RSVP TE for LS P Tunnels RFC 4426 Generalized Multi Protocol Label Switching (GMPLS) Recovery Functional
Specification RFC 4427 Recovery (Protection and Restoration) Terminology for Generalized Multi Protocol Label Switching (GMPLS) RFC 4428 Analysis of Generalized Multi Protocol Label Switching (GMPLS) based Recovery
Mechanisms (including Protection and Restoration) RFC 4872 RSVP TE Extensions in support of End to End Generalized Multi Protoc ol Label Switching (GMPLS) Recovery RFC 4873 GMPLS Segment Recovery RFC 5286 Basic
Specification for IP Fast Reroute: Loop Free Alternates RFC 5298 Analysis of Inter Domain Label Switched Path (LSP) Recovery RF C 6372 MPLS Transport Profile (MPLS TP) Survivability Framework RFC 6378 MPLS Transport
Profile (MPLS TP) Linear Protection RFC 7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile ( MPLS TP) Internet Drafts and RFCs in the Context of the ITU T's Transport Network
Recommendations RFC 7271 MPLS Transport Profile (MPLS TP) Linear Protection to Match the Operational Expectations of Synchronou s Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators .
G.8031 International Telecommunication Union, "Ethernet Linear Protection Switching", ITU T Recommendation G.8031/Y.1342, Jun e 2011 G.841 International Telecommunication Union, "Types and characteristics of SDH
network protection architectures", ITU T Recommendation G.841, October 1998 G873.1 International Telecommunication Union, " Optical Transport Network (OTN): Linear protection", ITU T Recommendation G.873.1, July 2011
• From wireless: very little, concept of Track
• Met with Adrian Lou / Greg
• Proposal (MLPS oriented): use o ne reference, RFC 4427 as opposed to all the above
I think you should feel free to use as many references as needed to help give context to the reader.

Two other terms we discussed as being relevant:

Recovery Domain [RFC4427]  This is also sometimes referred to as a Protection Domain when preprovisioned paths are used to provisioned ("protection") paths are used to support recovery.

While less used we did find the terms "protection group" used to represent the set of protection paths used to support service protection.  "recovery group" is similarly defined [RFC6372] as a more general term.


•PSE
PLR (Point of Local Repair), belongs to management plane (separate from controller
• Track
--> Recovery graph, that contains all the possible protection path,
I thought we ended up with [RFC6372]:



A recovery group is defined within a recovery domain and consists of

   a working (primary) entity and one or more recovery (backup) entities

   that reside between the end points of the recovery domain.



or

Protection group --

A protection group is defined within a protection domain and consists of

   the set of working and protection paths

   that reside between the end points of the protection domain.



Track is replaced by the term: Recovery (or protection) <TERM_TBD> - the set of all links and nodes used in a Recovery (or protection) group.



For TERM_TBD we discussed several options including 'graph', 'network', 'sub-network', and others that I can't recall.   I'm still not convinced of the need for this new term, but if we do introduce it, I have a slight preference for the other options, but can live with graph.




• PAREO is described as a new r ecovery function
Agreed on this.



Thank you for the good discussion.

Lou
On 7/26/2023 11:40 PM, Pascal Thubert (pthubert) wrote:
Hello Lou and all

I captured some of the meeting conclusions in one slide that I added to the presentation on architecture for DetNet / RAW tomorrow. Please let me know if you have any issue with it. We still have to discuss the new North.

[cid:image001.png@01D9C05A.C5F09BD0]

regards,

Pascal
From: Lou Berger <[e-mail]><mailto:[e-mail]>
Sent: Saturday, July 22, 2023 3:25 AM
To: Pascal Thubert (pthubert) <[e-mail]><mailto:[e-mail]>; Lou Berger <[e-mail]><mailto:[e-mail]>
Cc: Eve Schooler <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]><mailto:[e-mail]>
Subject: Re: [Detnet] WG Last Call: draft-ietf-raw-architecture-11


Pascal

----------
On July 21, 2023 11:51:37 PM "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>> wrote:

> Hello Lou;
>
> For the term tracks I believe we spent half the London meeting on just that item with the group in the room and settled to what we have now. It is not track vs protection path. A track is a collection of protection paths. We cannot keep reopening the subject.
>

Agreeing  on  terminology is often really hard - particularly when different groups come from different backgrounds and years of independent work.  6TISCH has tracks, TE/DetNet has protection paths, and more generally recovery.  I continue to view what is being described in the raw architecture is a wireless tailored form of protection (and actually not radically different from traditional 1+n protection, where outside the protection domain it is impossible to know which protection path was used.)

I don't recall the 115 discussion closing on this point.  Rereading https://datatracker.ietf.org/doc/minutes-115-raw-202211110930/ leaves me with just the opposite impression. I do see that some volunteered to work with you on a terminology alignment discussion.  Did those conversations ever happen?

> For the other terms I’m fully open to discussion and have no objection converging the SL definitions with TEAS, happy to work that out along your recommendations.
>
> For PSE and aCPF, they are functions that RAW adds incrementally to DetNet. How can they collide? What would be the equivalent protection functionality defined elsewhere?
>

I think you are definining something new - a wireless tailored protection function.  I'm not suggesting getting rid of it, just that it is described reusing existing terminology wherever possible.

Thanks,

Lou

> Regards,
>
> Pascal
>
> Le 21 juil. 2023 à 15:58, Lou Berger <[e-mail]<mailto:[e-mail]>> a écrit :
>
> 
>
> Hi,
>
> I'm going to fail to get all my comments in by today's deadline, but will write them on on the plane tomorrow.  They are going to build on my previous comments sent to the RAW list that were never fully addressed in [1] and in previous sessions.
>
> The big one is alignment of terminology of the document with the rest of DetNet/TE, including (for example):
>     Track vs protection path
>     RAW SLA/SLO/SL vs TEAS definitions
>     aCPF/PSE vs  detnet  (and other WG) protection terminology
>
> Others include description of DetNet domains that span wireless (RAW) and wired networks, and operation of RAW over wireless networks defined by outside of IETF (which may or may not support DLEP).
>
> I'll send more  tomorrow.
>
> Thanks,
>
> Lou
>
> [1] https://mailarchive.ietf.org/arch/msg/raw/1czSAxtRt94lpv_KZPGb5N3l3ko/
>
> On 6/23/2023 1:11 PM, Eve Schooler wrote:
>
> All,
>
> This starts working group last call on draft-ietf-raw-architecture-11
> https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/<https://datatracker.ietf.org/doc/draft-ietf-detnet-pof/>
>
> The working group last call ends on Friday, July 21st, the Friday before IETF 117.
> Please send your comments to the working group mailing list.
>
> Two IPR disclosures have been made for this document thus far (in tandem with WGLC, in a separate e-mail, we will solicit all co-authors/contributors for any additional disclosures).
>
> All comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome.
> This is useful and important, even from authors.
>
>
> In preparation for the transition of the RAW WG to roll back into the DetNet WG, we are issuing this as a joint WGLC to both WGs.
>
> Thank you,
> Eve (RAW Co-Chair & doc Shepherd)
>
> _______________________________________________
> detnet mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/detnet