Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

[Gyan Mishra <[e-mail]>]

Hi Med


I reviewed the updates in the -latest version with each draft having a
section 3 added “Relationship to other AC data models” is perfect.

I believe this 4 draft solution for AC provisioning  decoupling the bearer
from the services will be very helpful for network slicing provisioning as
well as other future use cases for AC work.

This draft is ready for publication.

Thank you


Gyan




On Tue, Apr 2, 2024 at 2:06 AM <[e-mail]> wrote:

> Hi Gyan,
>
> Thank you for the review.
>
> The candidate revisions can be tracked here:
>
> *
> https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
> *
> https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff
> *
> https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ntw-attachment-circuit.diff
> *
> https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.diff
>
> See more context inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Gyan Mishra via Datatracker <[e-mail]>
> > Envoyé : vendredi 29 mars 2024 18:05
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]
> > Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06
> >
> >
> > Reviewer: Gyan Mishra
> > Review result: Has Issues
> >
> > 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
>
> [Med] Actually, no. This draft focuses on binding LxVPN to ACs. The
> required functionality to bind a slice service with ACs is built as part of
> the service slice model itself. FWIW,
> draft-ietf-teas-ietf-network-slice-nbi-yang includes the following:
>
>    *  "ac-svc-name": Indicates the names of AC services, for association
>       purposes, to refer to the ACs that have been created.  When both
>       "ac-svc-name" and the attributes of "attachment-circuits" are
>       defined, the "ac-svc-name" takes precedence.
>
>          |     +--rw ac-svc-name*              string
>          |     +--rw attachment-circuits
>          |     |  +--rw attachment-circuit* [id]
>          |     |     +--rw id                       string
>          |     |     +--rw description?             string
>          |     |     +--rw ac-svc-name?             string
>
>  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.
>
> [Med] We already have such example in
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-08#name-binding-attachment-circuits
> (Figure 40), where this makes more sense.
>
>   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.
>
> [Med] I'm afraid no. see the reasons above.
>
> >
> > 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.
>
> [Med] There is no gap to fill for slicing as we have ac-svc-name part of
> the slice service itself. This draft focuses on LxVPN.
>
> >
> > 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
> >
>
> [Med] Added a new section to the 4 drafts.
>
> > 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.
>
> [Med] Updated the abstract for better clarity.
>
> >
> > So the introduction says the same but slightly differently.  Both
> > introduction & abstract should be aligned saying the same thing.
> >
>
> [Med] Hope this is better with the new edits.
>
> > 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.
>
> [Med] Exactly.
>
> >
> > 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.
>
> [Med] Great!
>
>    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.
>
> [Med] I hope this is now better with the new section.
>
> >
> > 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
> >
>
> [Med] Updaed the terminlogy section.
>
> > 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
> >
>
> [Med] Added a new section to describe that relationship.
>
> > 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.
>
> [Med] "network". Updated the terminology section accordingly.
>
> >
> > This draft has routing section 4.6 for bgp, ospf, isis, rip, vrrp
> > (static is
> > missing)
> >
>
> [Med] Hmm, static routing is also present:
>
>      4.6.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  20
>        4.6.1.  Static Routing  . . . . . . . . . . . . . . . . . . .  22
>        4.6.2.  BGP . . . . . . . . . . . . . . . . . . . . . . . . .  24
>        4.6.3.  OSPF  . . . . . . . . . . . . . . . . . . . . . . . .  31
>        4.6.4.  IS-IS . . . . . . . . . . . . . . . . . . . . . . . .  33
>        4.6.5.  RIP . . . . . . . . . . . . . . . . . . . . . . . . .  35
>        4.6.6.  VRRP  . . . . . . . . . . . . . . . . . . . . . . . .  38
>
>
> > 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.
>
> [Med] We would like to gave these specs independent of the VPN models as
> they can be used for any service.
>
>    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.
>
> [Med] We need to find a balance between the narrative text and full
> mirroring of the description clauses. Updated the text with some missing
> info.
>
> >
> > 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.
> >
>
> [Med] Same answer as above.
>
> > 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
> >
>
> [Med] Added a new section.
>
> > 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.
> >
>
> [Med] Done
>
> > ! 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
> >
>
> [Med] Done.
>
> > 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
> >
> >
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>