Re: [OPSAWG] SAPs and Attachment Circuits Provisioning (was TR: I-D Action: draft-boro-opsawg-ntw-attachment-circuit-01.txt)

mohamed.boucadair@orange.com Tue, 07 March 2023 11:29 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 F149CC14F739; Tue, 7 Mar 2023 03:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 cYkJF5A8D07a; Tue, 7 Mar 2023 03:29:33 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 A7CF1C14E515; Tue, 7 Mar 2023 03:29:33 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4PWCs73r8pz8tLP; Tue, 7 Mar 2023 12:29:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1678188571; bh=1VSlIKDgPoGFNSOJ7ODg/KFGFmz4FPxjCVDAI7cNvsU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=CVsWXy4Zn0QvFsDxEc/zmgYINmu/d+YhkSXfykPOD7qroOKiXXbLRlrbOru6g6eJv uasW6cHft1Vdlk/HPu6bssxXbTBUT2+b4q6m9kwe19pmVGvwU719EIilimx0GMkiKn G2GjmwRSV4BLF/YPkDVyPUa1XTfdfctDbyK1XiSHt74VM+3PRVZa/88UWw+QemvCGt 1tUlYjIEv9fRkDHlzn+l4sgUJFWAm+UxCztsGrvV/9UwJTW8jJV/wW/61UIPLlfrfH etP4AH3pc7ObZ7/bdKtoDZCIxqd7GwAukvyVBsfHqDGo86b37SUMsZ+vKIsN8ca1FK LiQ/EcK/NEURg==
From: mohamed.boucadair@orange.com
To: Moti Morgenstern <Moti.Morgenstern@rbbn.com>, "opsawg@ietf.org" <opsawg@ietf.org>
CC: "draft-boro-opsawg-ntw-attachment-circuit@ietf.org" <draft-boro-opsawg-ntw-attachment-circuit@ietf.org>
Thread-Topic: SAPs and Attachment Circuits Provisioning (was TR: I-D Action: draft-boro-opsawg-ntw-attachment-circuit-01.txt)
Thread-Index: AdlMUD2OLy2R8z9EQ9iMZh9fEP03sQAd1tQAAQGBCIA=
Content-Class:
Date: Tue, 07 Mar 2023 11:29:30 +0000
Message-ID: <10501_1678188571_6407201B_10501_348_1_78c1a76c2dce4bd4b80b97e9baa157d5@orange.com>
References: <167768140289.11250.17458504679431198985@ietfa.amsl.com> <29296_1677683553_63FF6B61_29296_302_1_17d5579d11dc4eec87b10c2cf7477ce6@orange.com> <DM4PR03MB6125E9BBD6812F400A920D9BFAB69@DM4PR03MB6125.namprd03.prod.outlook.com>
In-Reply-To: <DM4PR03MB6125E9BBD6812F400A920D9BFAB69@DM4PR03MB6125.namprd03.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2023-03-07T08:20:28Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=2839b5a8-2b04-420b-9284-2f66e5b42845; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/1vYIjKggLZG4Wr6bu1Zli_QXBaU>
Subject: Re: [OPSAWG] SAPs and Attachment Circuits Provisioning (was TR: I-D Action: draft-boro-opsawg-ntw-attachment-circuit-01.txt)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2023 11:29:38 -0000

Hi Moti, 

Thanks for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Moti Morgenstern <Moti.Morgenstern@rbbn.com>
> Envoyé : lundi 6 mars 2023 14:22
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> opsawg@ietf.org
> Cc : draft-boro-opsawg-ntw-attachment-circuit@ietf.org
> Objet : RE: SAPs and Attachment Circuits Provisioning (was TR: I-D
> Action: draft-boro-opsawg-ntw-attachment-circuit-01.txt)
> 
> Hi,
> 
> Here are my comments so far:
> 
> Introduction ("the same attachment circuit may be used to host
> multiple services") - The hierarchy is unclear.

[Med] What is meant here is the value added services that are delivered/supported via the AC; no the AC-as-Service per se. I agree that we need a better wording to better articulate this. 


 So far I knew that
> in a simple use-case we have a bearer channel that can carry one
> or several ACs and the traffic over each of them is delimited by
> single or double VLAN tags. It is also aligned with the definition
> of "Bearer" in the next chapter. If the sentence above is assumed
> then how do we call the logical connection associated with each
> single service? If not by VLAN(s), then how does the PE determine
> to which service a packet belongs?

[Med] When the same AC multiplexes N services, the classification/access control rules specified for each service will need to be followed. 

> 
> Figure 1:
> Top-Left: Who owns the block/device between PE1 and CE6?
> It cannot be the customer because otherwise both AC endpoints are
> owned by the customer.
> If it is the provider then the SAP is in practice located at the
> block. The customer is not aware to the internal topology of the
> provider's network
> 
> Top-Right: Assuming the AC connects the customer to the PE, it
> means the block is owned by the customer. It also means that the
> provider is not aware to CE2 and CE5. Each of the CEs is served
> separately by
> 

[Med] Good point. The intent was to reflect in the figure that some infrastructure may be in-between the PE/CE, but no need to complexify the figure. Replaced the box with lines.

> Bottom: Do we consider the pair of ACs between CE3 and the
> provider (same for CE4) as independent?

[Med] Yes. 

 If not, then there is a
> single AC that is specified on top of the two SAPs.

[Med] Agree. 

 For CE3 it
> looks like a MC-LAG (or an Ethernet Segment for the case of EVPN).
> For CE4 it looks like a LAG connectivity.
> 
> 4.1 "... an AC is uniquely identified within the scope of a node
> not a network." - What does it mean? Do we need a comma somewhere?

[Med] a comma is needed right before "not a network".

> "... a set of profiled can be defined at the network level" -
> maybe "profiles"?
> 

[Med] Yes. Fixed. Thanks.

> 4.2
> - replace svlan id and cvlan id with outer and inner vlan id,
> which is more generic and clear.

[Med] Agree, but we are trying to ease correlation with other models (rfc9182, rfc9291).

> - In practice, tag operations can be performed on both ingress and
> egress directions

[Med] Agree, however we went with the same simplification assumption as per L2NM: symmetric mode. If there are AC cases that would require asymmetric operations, then the full operation structure has to be modified, IMO.

> - tag1 and tag2 do not necessarily have the same push/pop
> operation.
> 

[Med] Are there cases that you think can't be covered with the current model?

==
             leaf tag-1 {
               when 'not(../pop)';
               type dot1q-types:vlanid;
               description
                 "A first tag to be used for push or translate
                  operations. This tag will be used as the outermost tag
                  as a result of the tag operation.";
             }
             leaf tag-1-type {
               type dot1q-types:dot1q-tag-type;
               default "dot1q-types:s-vlan";
               description
                 "Specifies a specific 802.1Q tag type of tag-1.";
             }
             leaf tag-2 {
               when '(../translate)';
               type dot1q-types:vlanid;
               description
                 "A second tag to be used for translation.";
             }
             leaf tag-2-type {
               type dot1q-types:dot1q-tag-type;
               default "dot1q-types:c-vlan";
               description
                 "Specifies a specific 802.1Q tag type of tag-2.";
             }
==

Thank you. 

> Regards,
> Moti
> -----Original Message-----
> From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Wednesday, March 1, 2023 5:13 PM
> To: opsawg@ietf.org
> Cc: draft-boro-opsawg-ntw-attachment-circuit@ietf.org
> Subject: [EXTERNAL] [OPSAWG] SAPs and Attachment Circuits
> Provisioning (was TR: I-D Action: draft-boro-opsawg-ntw-
> attachment-circuit-01.txt)
> 
> Hi all,
> 
> Now that the base SAP spec is stable, we started exploring an
> augmentation that exposes the set of attachment circuits that are
> terminated by the SAP.
> 
> This network model is designed to ease the correlation between
> "Attachment Circuit-as-a-Service" request and the actual network
> provisioning. The model is also designed to accommodate various
> deployment schemes (a CE that maintains or multiple ACs with the
> same or distinct PEs, same AC terminated on the multiple SAPs,
> same AC terminated by more than one AC, etc.).
> 
> Please review and share comments. If you have an AC deployment
> case which is not covered by the proposed structure, please share
> it and let's discuss to see how to cover it. Thanks.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : I-D-Announce <i-d-announce-bounces@ietf.org> De la part de
> internet-drafts@ietf.org Envoyé : mercredi 1 mars 2023 15:37 À :
> i-d-announce@ietf.org Objet : I-D Action: draft-boro-opsawg-ntw-
> attachment-circuit-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : A Network YANG Data Model for Attachment
> Circuits
>         Authors         : Mohamed Boucadair
>                           Richard Roberts
>                           Oscar Gonzalez de Dios
>                           Samier Barguil Giraldo
>                           Bo Wu
>   Filename        : draft-boro-opsawg-ntw-attachment-circuit-
> 01.txt
>   Pages           : 75
>   Date            : 2023-03-01
> 
> Abstract:
>    This document specifies a network model for attachment
> circuits.  The
>    model can be used for the provisioning of attachment circuits
> prior
>    or during service provisioning (e.g., Network Slice Service).
> A
>    companion service model is specified in
>    [I-D.boro-opsawg-teas-attachment-circuit].
> 
>    The module augments the Service Attachment Point (SAP) model
> with the
>    detailed information for the provisioning of attachment
> circuits in
>    Provider Edges (PEs).
> 
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://clicktime.symantec.com/15t5jY75kXFiwoTTdLTdy?h=QEhrkbWUEsE
> M2oU5iK3WjBmJREvD2gKenIYlHFuMYeI=&u=https://clicktime.symantec.com
> /15t5jY75kbAy4u33ipvus?h=VnjAiocyXlKe_NJEavs_33UqH02HXl_KmiV31AEgZ
> Y8=&u=https://datatracker.ietf.org/doc/draft-boro-opsawg-ntw-
> attachment-circuit/
> 
> There is also an HTML version available at:
> https://clicktime.symantec.com/15t5pNJND8wKMkHPAtrnb?h=szl-
> OrcouWaUsAKFxRw4zoOH5NZxttx73q7TFDWFpJ0=&u=https://clicktime.syman
> tec.com/15t5pNJNDCrZUqryGPL4V?h=p1csu8q40grKPrDPX2pkHhaNZTz8BH-
> rLZemLB5ZDEg=&u=https://www.ietf.org/archive/id/draft-boro-opsawg-
> ntw-attachment-circuit-01.html
> 
> A diff from the previous version is available at:
> https://clicktime.symantec.com/15t5ehuoHua8XrdY5n4VM?h=wrIlzQ_Omyg
> 7M6uxNwR4r-
> cV39983q0j7BCDh3qiFVM=&u=https://clicktime.symantec.com/15t5ehuoHy
> VNexD8BGXmF?h=raz4QI_1SBC040migEE02bQrIeRa06ufOFEGDqNtiYQ=&u=https
> ://author-tools.ietf.org/iddiff?url2%253Ddraft-boro-opsawg-ntw-
> attachment-circuit-01
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://clicktime.symantec.com/15t5uCVefkcumh7JiTFwD?h=J25hFzOG4z8
> hdqqYnIk6K9f8zT9TWxJBzkCvvuyMvnU=&u=https://clicktime.symantec.com
> /15t5uCVefpY9tngtowjD7?h=piClPOzV8NcUniRkHa5Qf-
> qGkaJKbozQKYkCzm03wQQ=&u=https://www.ietf.org/mailman/listinfo/i-
> d-announce
> Internet-Draft directories:
> https://clicktime.symantec.com/15t5ZsiWqHtY7uocYDfLj?h=e80hT1-
> zxhpqcb4gH9mQ_GZggwrDDrr7svWwifVoehM=&u=https://clicktime.symantec
> .com/15t5ZsiWqMonF1PCdi8cd?h=TJpqt3ZSiRSaDoXtP2Zj70JOMUrfdUs8xb_62
> hoT_Gk=&u=http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> __________________________________________________________________
> _______________________________________________________
> 
> 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.
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://clicktime.symantec.com/15t5z2gw8NJWBdwEG1f5q?h=uNiWkWNeLrN
> 4nq2JB6kwT525Y4bBPDp0a7i-
> 3dwOCnE=&u=https://clicktime.symantec.com/15t5z2gw8SDkJjWpMW8Mj?h=
> 5pw4WTDw4TWOH5fD8n5Hb41ZlPdMfRQFI1tvhjGMZiM=&u=https://www.ietf.or
> g/mailman/listinfo/opsawg
> 
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. and its Affiliates that
> is confidential and/or proprietary for the sole use of the
> intended recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is
> strictly prohibited. If you are not the intended recipient, please
> notify the sender immediately and then delete all copies,
> including any attachments.

_________________________________________________________________________________________________________________________

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.