From mjethanandani@gmail.com Tue Apr 2 14:09:32 2024 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF01C14CE29; Tue, 2 Apr 2024 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AfGK_Me1zyW; Tue, 2 Apr 2024 14:09:28 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACD9C151070; Tue, 2 Apr 2024 14:09:28 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1e27e174ccbso6491985ad.2; Tue, 02 Apr 2024 14:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712092168; x=1712696968; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=hj8uF/OY7F1K4VHg8WJJIaHz42I3FZmbxj2MtcvwWtA=; b=ZoO8Vr7GC0SrERcQXGbK/a52VTqutwxr8lY9w5nGQbiylTqn9CsR42v4vuLeRgbmCJ y9W3BYFkNHz0U2VCq5I/65xQRmCBREddxfmJY3H5lNmt/B3ruzX63W+mWU+lKPDguIvJ NS+4VlwH5UiVWHizBR6xPzr+0pFqJGQHUGE+Rqp9mJryrgkd5t/ruSpF2NdN1i3iiZOC rx7imDWTtlvte1LpdlfKWQDDmduHQRK58eLfPew8CRI2LC2KpelaTyvZAbxiiW0xgKk/ fXIDMel0w0hoHn0bnQ9BY26YODCCO7b7qec5dA5Eiv2hNbKdjjYNb1x1/0bVwImh6IUi 9x3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712092168; x=1712696968; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hj8uF/OY7F1K4VHg8WJJIaHz42I3FZmbxj2MtcvwWtA=; b=gBxnJ7K20fpELeIsE86dq0478aNs442/QdNIDoZq0xhoYyP/LqF08GRdA1OSQBS4Hh SXFEjn/n+h5A09CN1gKyEeW2cswH2vLSrmwCdT4kRXrFH6iiEzriNbGenkf2aEGkAnqE W1Y44cHau59KW8BhyygLTOojS8dSxgbQuLheuBfAcZF6IhytpAeGje8vLYqG0UGcDYrQ Rhg7mu9QKscRt6Npbkc8nB4mnc/Ed7XozN6NFY/pm8PxgZVia74KlwombN1OHrIPxTWz Eqvqgc/qAWn3L+TzrvGbziMXqxXfe57dDRBjberFbaWjSednuTSOI7pDyKJMU1R2KflR UtpA== X-Forwarded-Encrypted: i=1; AJvYcCWn6Lv+2WEWBVPojNO30qkJsZftYligen5R4nzjISiEKYXt6CdrP4AhWIvlL7ZPlB2pSGFVCmHyrUsInnzxxKN/IDvB0dq8WAj2FMRgQcxcQ6l3AgJ1XjACWPmURrVIUjaoyQuUMUmqTWOaf+ZK9na67fOqlDw+1j5Y2xro/iElIZBFOg== X-Gm-Message-State: AOJu0YxtWn1U2EU993JDWmppl/+GE6iSMj66jAroKTnrguGPr0QMvv9u 71MGgAH58U4HOEPfQKzh4o1JwmICrnMnr8iEMUSYAZrcVxaWqpsun+ErShSI0LQ= X-Google-Smtp-Source: AGHT+IGHu2ARSPCWcN/Ka4VMEqapwx9BwZmbVOCn176VTXSJ6MH6YBIsFuEUvKxeoUeUb+6SAwnkfA== X-Received: by 2002:a17:902:d58e:b0:1e2:45d9:4e78 with SMTP id k14-20020a170902d58e00b001e245d94e78mr12821879plh.47.1712092167531; Tue, 02 Apr 2024 14:09:27 -0700 (PDT) Received: from smtpclient.apple (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id p7-20020a170902e74700b001e1072382a1sm11632642plf.142.2024.04.02.14.09.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2024 14:09:26 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6893D56E-094B-4714-98E0-5F6105AF6FE5" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Tue, 2 Apr 2024 14:09:21 -0700 In-Reply-To: Cc: Gyan Mishra , "rtg-dir@ietf.org" , "draft-ietf-opsawg-ac-lxsm-lxnm-glue.all@ietf.org" , "opsawg@ietf.org" To: BOUCADAIR Mohamed IMT/OLN References: <171173189401.29443.18273877926431009752@ietfa.amsl.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) Archived-At: Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2024 21:09:33 -0000 --Apple-Mail=_6893D56E-094B-4714-98E0-5F6105AF6FE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Med, Just one comment. See inline with [mj] > On Apr 1, 2024, at 11:05 PM, mohamed.boucadair@orange.com wrote: >=20 > Hi Gyan,=20 >=20 > Thank you for the review.=20 >=20 > The candidate revisions can be tracked here:=20 >=20 > * = 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 = >=20 > See more context inline.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Gyan Mishra via Datatracker >> Envoy=C3=A9 : vendredi 29 mars 2024 18:05 >> =C3=80 : rtg-dir@ietf.org >> Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue.all@ietf.org; = opsawg@ietf.org >> Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 >>=20 >>=20 >> Reviewer: Gyan Mishra >> Review result: Has Issues >>=20 >> I have been selected as the Routing Area Directorate Reviewer for the >> draft >> below: >>=20 >> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 >>=20 >> 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. >>=20 >> 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. >>=20 >> The 3 additional drafts below were reviewed together as requested. >>=20 >> ! Draft being reviewed >> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 >>=20 >> ! Additional drafts reviewed >> draft-ietf-opsawg-ntw-attachment-circuit-05 >> draft-ietf-opsawg-teas-attachment-circuit-06 >> draft-ietf-opsawg-teas-common-ac-05 >>=20 >> All 4 drafts were adopted on November 6th 2023. >>=20 >> I ran IDNITS against all 4 drafts and result was =E2=80=9Cno issues = found >> here=E2=80=9D >>=20 >> Routing Area Directorate Review request Main Draft >> draft-ietf-opsawg-ac-lxsm-lxnm-glue-06 >>=20 >> Major Issues: >> None >>=20 >> Minor Issues: >> The main use case for this draft is for network slicing >=20 > [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: >=20 > * "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? >=20 > | +--rw ac-svc-name* string > | +--rw attachment-circuits > | | +--rw attachment-circuit* [id] > | | +--rw id string > | | +--rw description? string > | | +--rw ac-svc-name? string >=20 > 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. >=20 > [Med] We already have such example in = https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-ci= rcuit-08#name-binding-attachment-circuits = (Figure 40), where this = makes more sense. >=20 > 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. >>=20 >> 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. >>=20 >> I think it would be relevant to add the Network Slicing framework RFC >> 9543 as an informative reference. >=20 > [Med] I'm afraid no. see the reasons above. >=20 >>=20 >> 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 =E2=80=9Cac-svc=E2=80=9D >> 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. >=20 > [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. >=20 >>=20 >> draft-ietf-teas-ietf-network-slice-nbi-yang >>=20 >> 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. >>=20 >> 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 >>=20 >=20 > [Med] Added a new section to the 4 drafts. >=20 >> Interpretation of the abstract =E2=80=93 >> 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. >>=20 >> 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 = =E2=80=9Cac-svc:attachment- >> circuit-reference=E2=80=9D >> reference information to bind specific services to ACs that are >> created using the 4 L2NM & L2SM models. >>=20 >> So AFAIK what this draft is doing is it creates a this concept called >> a ac-glue =E2=80=9Cac-svc:attachment-circuit-reference=E2=80=9D 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 = =E2=80=9Cac-glue=E2=80=9D >> 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. >=20 > [Med] Updated the abstract for better clarity. >=20 >>=20 >> So the introduction says the same but slightly differently. Both >> introduction & abstract should be aligned saying the same thing. >>=20 >=20 > [Med] Hope this is better with the new edits. >=20 >> 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:=C2=B6 =E2=80=A2 The Layer 2 Service Model (L2SM) = [RFC8466]=C2=B6 =E2=80=A2 >> The >> Layer 3 Service Model (L3SM) [RFC8299]=C2=B6 =E2=80=A2 The = Layer 2 Network >> Model >> (L2NM) [RFC9291]=C2=B6 =E2=80=A2 The Layer 3 Network Model = (L3NM) [RFC9182]=C2=B6 >> 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].=C2=B6 >> Interpreting the introduction paragraph above. >>=20 >> This document specifies a Yang data model =E2=80=9Cac-glue=E2=80=9D = that updates >> existing 4 L2NM & L2SM AC provisioning modules with the required >> information =E2=80=9Cac-svc:attachment-circuit-reference=E2=80=9D = reference pointers >> to bind specific L2 & >> L3 VPN services to ACs that are created using the AC service model >> =E2=80=9Cthe draft-ietf-opsawg-teas-attachment-circuit-06=E2=80=9D. >>=20 >> So interpreting this a bit further is we are using the =E2=80=9Cac-glue= =E2=80=9D >> =E2=80=9Cac-svc:attachment-circuit-reference=E2=80=9D 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. >>=20 >> So the goal of =E2=80=9Cdraft-ietf-opsawg-teas-attachment-circuit-06=E2= =80=9D 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. >=20 > [Med] Exactly. >=20 >>=20 >> So now interpreting this draft a bit further. So the AC service = model >> is =E2=80=9Cdraft-ietf-opsawg-teas-attachment-circuit-06=E2=80=9D 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 = =E2=80=9Cac- >> glue=E2=80=9D reference information information = =E2=80=9Cac-svc:attachment-circuit- >> reference=E2=80=9D to bind the L2 & L3 VPN services to the L1 bearer = physical >> AC infrastructure. >>=20 >> 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. >=20 > [Med] Great! >=20 > I think it >> would be >> good to show clearly the gap that exists today that we don=E2=80=99t = 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. >>=20 >> 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. >=20 > [Med] I hope this is now better with the new section. >=20 >>=20 >> 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. >>=20 >> Acronyms terms below are abbreviated that should be expanded and >> definition provided. >>=20 >> SAP, NTW, AC-NTW, SVC, AC-SVC-REF, AC-NTW-REF >>=20 >=20 > [Med] Updaed the terminlogy section. >=20 >> Nits: >> None >>=20 >> ! Additional drafts reviewed >> draft-ietf-opsawg-ntw-attachment-circuit-05 >>=20 >> Major Issues: >> None >>=20 >> 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. >>=20 >> 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 >>=20 >=20 > [Med] Added a new section to describe that relationship. >=20 >> 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. >>=20 >> What does =E2=80=9Cntw=E2=80=9D mean please expand. >=20 > [Med] "network". Updated the terminology section accordingly. >=20 >>=20 >> This draft has routing section 4.6 for bgp, ospf, isis, rip, vrrp >> (static is >> missing) >>=20 >=20 > [Med] Hmm, static routing is also present: >=20 > 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 >=20 >=20 >> 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. >=20 > [Med] We would like to gave these specs independent of the VPN models = as they can be used for any service. >=20 > I think that would simplify the draft so >> not >> providing redundant yang data models that has already been documented >> in other RFCs. >>=20 >> 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. >=20 > [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. >=20 >>=20 >> Nits: >> None >>=20 >> ! Additional drafts reviewed >> draft-ietf-opsawg-teas-attachment-circuit-06 >>=20 >> Major Issues: >> None >>=20 >> Minor Issues: >>=20 >> This draft has routing section 4.2.5.3 for static, bgp, ospf, isis, >> rip, vrrp >>=20 >> 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. >>=20 >=20 > [Med] Same answer as above. >=20 >> 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. >>=20 >> 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 >>=20 >=20 > [Med] Added a new section. >=20 >> 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. >>=20 >> Nits: >> Remove all the bold of lines within the draft. AFAIK it makes it >> difficult for the user to read. >>=20 >=20 > [Med] Done >=20 >> ! Additional drafts reviewed >> draft-ietf-opsawg-teas-common-ac-05 >>=20 >> Major Issues: >> None >>=20 >> Minor Issues: >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 >>=20 >=20 > [Med] Done. >=20 >> 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. >>=20 >> Nits: >> None >>=20 >>=20 >=20 > = __________________________________________________________________________= __________________________________ > 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. >=20 > 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 mjethanandani@gmail.com --Apple-Mail=_6893D56E-094B-4714-98E0-5F6105AF6FE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Med,

Just one = comment. See inline with [mj]

On Apr = 1, 2024, at 11:05 PM, mohamed.boucadair@orange.com 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 <noreply@ietf.org>
Envoy=C3=A9 : = vendredi 29 mars 2024 18:05
=C3=80 : rtg-dir@ietf.org
Cc : draft-ietf-opsawg-ac-lxsm-lxnm-glue.all@ietf.org; opsawg@ietf.org
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 =E2=80=9Cno issues found
here=E2=80=9D
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* =             &n= bsp;string
        | =     +--rw attachment-circuits
        | =     |  +--rw attachment-circuit* [id]
        | =     |     +--rw id =             &n= bsp;         string        | =     |     +--rw description? =             st= ring
        | =     |     +--rw ac-svc-name? =             st= ring

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-at= tachment-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 = =E2=80=9Cac-svc=E2=80=9D
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 =E2=80=93
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 =E2=80=9Cac-svc:attachment-=
circuit-reference=E2=80=9D
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 = =E2=80=9Cac-svc:attachment-circuit-reference=E2=80=9D 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 = =E2=80=9Cac-glue=E2=80=9D
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:=C2=B6 =E2=80=A2=       The Layer 2 Service Model (L2SM) = [RFC8466]=C2=B6 =E2=80=A2
The
Layer 3 = Service Model (L3SM) [RFC8299]=C2=B6 =E2=80=A2 =       The Layer 2 Network
Model
(L2NM) [RFC9291]=C2=B6 =E2=80=A2 =       The Layer 3 Network Model (L3NM) = [RFC9182]=C2=B6
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].=C2=B6
Interpreting the = introduction paragraph above.

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

So interpreting this a bit further is we are using the = =E2=80=9Cac-glue=E2=80=9D
=E2=80=9Cac-svc:attachment-circuit-reference=E2=80=9D 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 = =E2=80=9Cdraft-ietf-opsawg-teas-attachment-circuit-06=E2=80=9D  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 = =E2=80=9Cdraft-ietf-opsawg-teas-attachment-circuit-06=E2=80=9D 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 =E2=80=9Cac-
glue=E2=80=9D = reference information information =E2=80=9Cac-svc:attachment-circuit-
reference=E2=80=9D 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=E2=80=99t 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 =E2=80=9Cntw=E2=80=9D 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
mjethanandani@gmail.com






= --Apple-Mail=_6893D56E-094B-4714-98E0-5F6105AF6FE5--