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

[Mahesh Jethanandani <[e-mail]>]

Hi Med,

Just one comment. See inline with [mj]

> On Apr 1, 2024, at 11:05 PM, [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-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-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-ntw-attachment-circuit.diff>
> * https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.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.

[mj] Is there a reason to have both? Should it not be a choice statement?

> 
>         |     +--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 <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.


Mahesh Jethanandani
[e-mail]