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

[Lou Berger <[e-mail]>]

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.
>
> regards,
>
> Pascal
>
> *From:* Lou Berger <[e-mail]>
> *Sent:* Saturday, July 22, 2023 3:25 AM
> *To:* Pascal Thubert (pthubert) <[e-mail]>; Lou Berger 
> <[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
>
> ----------
> On July 21, 2023 11:51:37 PM "Pascal Thubert (pthubert)" 
> <[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]> 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]
> > https://www.ietf.org/mailman/listinfo/detnet
>