Skip to main content

Early Review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
review-ietf-opsawg-ac-lxsm-lxnm-glue-06-rtgdir-early-mishra-2024-03-29-00

Request Review of draft-ietf-opsawg-ac-lxsm-lxnm-glue
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-03-08
Requested 2024-02-16
Requested by Tianran Zhou
Authors Mohamed Boucadair , Richard Roberts , Samier Barguil , Oscar Gonzalez de Dios
I-D last updated 2024-03-29
Completed reviews Rtgdir Early review of -09 by Gyan Mishra
Rtgdir Early review of -06 by Gyan Mishra (diff)
Yangdoctors Early review of -04 by Martin Björklund (diff)
Comments
There are four related drafts:
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
You may consider them together.
Assignment Reviewer Gyan Mishra
State Completed
Request Early review on draft-ietf-opsawg-ac-lxsm-lxnm-glue by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/f5TeJdhHUnSNkrWnR1w8tIdXqKU
Reviewed revision 06 (document currently at 09)
Result Has issues
Completed 2024-03-29
review-ietf-opsawg-ac-lxsm-lxnm-glue-06-rtgdir-early-mishra-2024-03-29-00
I have been selected as the Routing Area Directorate Reviewer for the draft
below:

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

I reviewed the latest version 6 and the ideas behind the concept of the draft
makes sense, however some additional recommendations on clarity of the draft I
believe is necessary before publication.

This draft was presented at IETF 117 last summer by Mohamed Boucadair and
adopted on November 6th 2023.  As the draft was adopted fairly recently, my
goal is to catch any issues with the draft before publication.

The 3 additional drafts below were reviewed together as requested.

! Draft being reviewed
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

! Additional drafts reviewed
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

All 4 drafts were adopted on November 6th 2023.

I ran IDNITS against all 4 drafts and result was “no issues found here”

Routing Area Directorate Review request Main Draft
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

Major Issues:
None

Minor Issues:
The main use case for this draft is for network slicing that is to be used as
discussed in TEAS WG IETF 117 by author Mohamed Boucadair.  As that is the main
use case I wonder if it makes sense to add that to the introduction.  RFC 8466
L2SM, RFC 8299 L3SM Service modules were published in 2018 and RFC 9291 L2NM,
RFC 9182 L3NM were published in 2022.  So it has been pretty recent since the
Network Modules have been published but not as recent for the Service modules. 
The idea and concept of an AC or AC Glue has not been developed until just this
past November.  As Network slicing is the main use case for the glue model
would it be possible to add Network slicing as the example in Appendix A.  Do
you see in the future a Yang Data model for the examples mentioned in Appendix
A.  Also if the other examples are not as likely to be used would it make sense
to remove.

With this draft AFAIK are we really trying to show with the yang model the main
use case for this draft to be network slicing.

I think it would be relevant to add the Network Slicing framework RFC 9543 as
an informative reference.

The Network Slicing NBI Yang Data model provides the Yang Data model for
Network Slice Services for all the connectivity constructs defined in the
network slicing framework draft for provisioning network slicing for “ac-svc”
services.   So what is the gap that these 4 drafts provide that is missing  for
Network Slicing that is not provided by the Network Slice NBI Yang Data model
draft below.

draft-ietf-teas-ietf-network-slice-nbi-yang

I would recommend having a section & maybe even a figure that shows how the 4
drafts are related in detail.  I think in this draft and the NTW draft and show
the parent  / child or hierarchy relationship between the 4 drafts in a flow
chart that shows the interaction and relationships between the drafts and
sequencing order of the drafts.

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

Interpretation of the abstract –
The document specifies a module that updates existing service and network
Virtual Private Network (VPN) modules with the required information to bind
specific services to ACs that are created using the Attachment Circuit (AC)
service and network models.

This document provides the Yang data model that updates the existing L2SM RFC
8466, L3SM RFC 8299 Service modules and L2NM RFC 9291, L3NM RFC 9182 Network
modules with the required ac-glue “ac-svc:attachment-circuit-reference”
reference information to bind specific services to ACs that are created using
the 4 L2NM & L2SM models.

So AFAIK what this draft is doing is it creates a this concept called a ac-glue
“ac-svc:attachment-circuit-reference” which is basically pointers to bind
specific L2 & L3 VPN services to ACs that are provisioned using the 4 L2NM &
L2SM models.   So now when the L2 & L3 VPN Network & Services are provisioned,
this draft then augments the provisioning process with an “ac-glue”  the
abstract is saying its using the AC service and network modules.  When you say
AC Service and network modules the reader may think you are referring to the 4
L2NM & L2SM models and not what the introduction states which is using the
draft-ietf-opsawg-teas-attachment-circuit-06 model which is the intention in
the abstract.  I would recommend making the abstract more clear.

So the introduction says the same but slightly differently.  Both introduction
& abstract should be aligned saying the same thing.

The document specifies a YANG module ("ietf-ac-glue", Section 5) that updates
existing service and network Virtual Private Network (VPN) modules with the
required information to bind specific services to Attachment Circuits (ACs)
that are created using the AC service model
[I-D.ietf-opsawg-teas-attachment-circuit], specifically the following modules
are augmented:¶ •       The Layer 2 Service Model (L2SM) [RFC8466]¶ •       The
Layer 3 Service Model (L3SM) [RFC8299]¶ •       The Layer 2 Network Model
(L2NM) [RFC9291]¶ •       The Layer 3 Network Model (L3NM) [RFC9182]¶ Likewise,
the document augments the L2NM and L3NM with references to the ACs that are
managed using the AC network model [I-D.ietf-opsawg-ntw-attachment-circuit].¶
Interpreting the introduction paragraph above.

This document specifies a Yang data model “ac-glue” that updates existing 4
L2NM & L2SM AC provisioning modules with the required information
“ac-svc:attachment-circuit-reference” reference pointers to bind specific L2 &
L3 VPN services to ACs that are created using the AC service model “the
draft-ietf-opsawg-teas-attachment-circuit-06”.

So interpreting this a bit further is we are using the “ac-glue”
“ac-svc:attachment-circuit-reference” is being used to bind the specific L2 &
L3 VPN services that are being provisioned to ACs that are created using the AC
service model draft-ietf-opsawg-teas-attachment-circuit-06.

So the goal of “draft-ietf-opsawg-teas-attachment-circuit-06”  for AC service
provisioning, and to manage the bearers over which the ACs are built.  Doing so
by design decouples the management of the ACs using the AC service model from
the provisioning of the ACs.

So now interpreting this draft a bit further.  So the AC service model is
“draft-ietf-opsawg-teas-attachment-circuit-06” is your OSI model Layer 1 bearer
facilities for the AC on top of which your L2 & L3 VPN Network and services are
to be provisioned with the help of the “ac-glue” reference information 
information “ac-svc:attachment-circuit-reference” to bind the L2 & L3 VPN
services to the L1 bearer physical AC infrastructure.

It took me a while to boil it down to what the 4 drafts solution is trying to
do and the importance of the draft is clear to me now.   I think it would be
good to show clearly the gap that exists today that we don’t have a way to map
the L2 & L3 VPN services to the Layer 1 Metro Ethernet or transport network 
facilities being provisioned and the group of these 4 drafts provide a means of
doing so efficiently without overlapping data models and creating reusability
and sustainability with the data models as much as possible.

My recommendation would be to show maybe a hierarchy and how the 4 drafts are
inter connected together to form a solution for OPSAWG WG Attachment Circuits
provisioning using the four Yang Data models.

Section 2 Conventions & Definitions refers to below for terms
This document uses terms defined in [I-D.ietf-opsawg-teas-attachment-circuit].
AFAIK any terms should be displayed in the draft itself and not referred to
another draft for reference.

Acronyms terms below are abbreviated that should be expanded and definition
provided.

SAP, NTW, AC-NTW, SVC, AC-SVC-REF, AC-NTW-REF

Nits:
None

! Additional drafts reviewed
draft-ietf-opsawg-ntw-attachment-circuit-05

Major Issues:
None

Minor Issues:
I would recommend showing how all 4 drafts work together in each of the 4
drafts as they all work together to provide the overall AC solution.

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

Is there any way to merge some of these drafts together or do they all have to
be separate. It makes it difficult for the reader to follow the solution.

What does “ntw” mean please expand.

This draft has routing section 4.6 for bgp, ospf, isis, rip, vrrp (static is
missing)

Could the routing protocols section just refer to L3NM L3SM RFC for any details
on the routing protocol necessary or point to the LXNM Glue draft that glues 4
NM & SM modules together.   I think that would simplify the draft so not
providing redundant yang data models that has already been documented in other
RFCs.

Section 4.4 L2 connection & Section 4.5 IP connection and then 4.6 goes into
detail about each routing protocol however there is no corresponding detailed
section for L2 services as there is for L3 services on the AC.

Nits:
None

! Additional drafts reviewed
draft-ietf-opsawg-teas-attachment-circuit-06

Major Issues:
None

Minor Issues:

This draft has routing section 4.2.5.3 for static, bgp, ospf, isis, rip, vrrp

Could the routing protocols section just refer to L3NM L3SM RFC for any details
on the routing protocol necessary or point to the LXNM Glue draft that glues 4
NM & SM modules together.   I think that would simplify the draft so not
providing redundant yang data models that has already been documented in other
RFCs.

I would recommend showing how all 4 drafts work together in each of the 4
drafts as they all work together to provide the overall AC solution.

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

Is there any way to merge some of these drafts together or do they all have to
be separate. It makes it difficult for the reader to follow the solution.

Nits:
Remove all the bold of lines within the draft.  AFAIK it makes it difficult for
the user to read.

! Additional drafts reviewed
draft-ietf-opsawg-teas-common-ac-05

Major Issues:
None

Minor Issues:

Is the goal of this draft to take items that are common between all ACs for the
L2NM & L2SM modules.  Why not make this part of one of the other drafts like
the ac-glue or even the ACAAS draft.

I would recommend showing how all 4 drafts work together in each of the 4
drafts as they all work together to provide the overall AC solution.

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

Is there any way to merge some of these drafts together or do they all have to
be separate. It makes it difficult for the reader to follow the solution.

Nits:
None