Re: [OPSAWG] New Version Notification for draft-dbwb-opsawg-sap-00.txt

Chongfeng Xie <xiechf@chinatelecom.cn> Tue, 02 November 2021 13:20 UTC

Return-Path: <xiechf@chinatelecom.cn>
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 3D03C3A1196 for <opsawg@ietfa.amsl.com>; Tue, 2 Nov 2021 06:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtW5jkXvZZnP for <opsawg@ietfa.amsl.com>; Tue, 2 Nov 2021 06:20:37 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFED3A1193 for <opsawg@ietf.org>; Tue, 2 Nov 2021 06:20:34 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.48:40636.728241734
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-114.250.180.95 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id BE64E280090; Tue, 2 Nov 2021 21:20:24 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([172.18.0.48]) by app0024 with ESMTP id 1f72fadbc09f4bddb545d8a9041ea3dc for mohamed.boucadair@orange.com; Tue, 02 Nov 2021 21:20:28 CST
X-Transaction-ID: 1f72fadbc09f4bddb545d8a9041ea3dc
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 172.18.0.48
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
From: Chongfeng Xie <xiechf@chinatelecom.cn>
Message-Id: <7913FD0A-E221-470A-B506-83974C4AFE16@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3F6C0B1B-6C62-4557-9213-0C7C973DD88A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 02 Nov 2021 21:20:26 +0800
In-Reply-To: <22605_1634904259_6172A8C3_22605_65_1_787AE7BB302AE849A7480A190F8B933035430DAD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "Lopez, Victor (Nokia - ES/Madrid)" <victor.lopez@nokia.com>
To: "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
References: <163490381865.17250.10018953236125318819@ietfa.amsl.com> <22605_1634904259_6172A8C3_22605_65_1_787AE7BB302AE849A7480A190F8B933035430DAD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/tDK-kKrps4wWwujL04EuE2pzF-E>
Subject: Re: [OPSAWG] New Version Notification for draft-dbwb-opsawg-sap-00.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Nov 2021 13:20:42 -0000

Hi, all,

I have read this short draft and it is well written. I support the adoption of it since it provides a good management tool for service attachment management. A few suggestions to this drafts:

1. If the customer want to open a new line, can we add an usage example to show what kind of capability can be exposed from domain controller to the upper layer application?

2. I think we should emphasize L3NM or L2NM used to configure VPN while this model is used for capability exposure.

3. if L3VPN service is allocated to an logical interface, for instance, an ethernet sub-interface, how do we support this interface type? e.g., extend  if:interface-type to support such interface type? or reference IANA Interface Type defined in RFC7224?


Chongfeng Xie

> 2021年10月22日 下午8:04,mohamed.boucadair@orange.com 写道:
> 
> Hi all, 
> 
> We updated the uni draft to address some of the comments we received in the past. For better clarity, we abandoned the uni terminology and went with service attachment points that is more generic. It can be used to build a network topology to be consumed by an orchestrator to handle a service request. SAPs can be the PE endpoint facing a CE or a peer PE (for services such as inter-AS VPN). 
> 
> Comments, questions, and suggestions are more than welcome.
> 
> Cheers,
> Oscar, Samier, Qin, Victor, & Med
> 
> -----Message d'origine-----
> De : internet-drafts@ietf.org <internet-drafts@ietf.org> 
> Envoyé : vendredi 22 octobre 2021 13:57
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Oscar Gonzalez de Dios <oscar.gonzalezdedios@telefonica.com>; Oscar de Dios <oscar.gonzalezdedios@telefonica.com>; Qin WU <bill.wu@huawei.com>; Qin Wu <bill.wu@huawei.com>; Samier Barguil <samier.barguilgiraldo.ext@telefonica.com>; Victor Lopez <victor.lopez@nokia.com>; samier barguil <samier.barguilgiraldo.ext@telefonica.com>
> Objet : New Version Notification for draft-dbwb-opsawg-sap-00.txt
> 
> 
> A new version of I-D, draft-dbwb-opsawg-sap-00.txt has been successfully submitted by Mohamed Boucadair and posted to the IETF repository.
> 
> Name:		draft-dbwb-opsawg-sap
> Revision:	00
> Title:		A Network YANG Model for Service Attachment Points
> Document date:	2021-10-22
> Group:		Individual Submission
> Pages:		21
> URL:            https://www.ietf.org/archive/id/draft-dbwb-opsawg-sap-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dbwb-opsawg-sap
> 
> 
> Abstract:
>   This document defines a YANG data model for representing an abstract
>   view of the provider network topology containing the points from
>   which its services can be attached (e.g., basic connectivity, VPN,
>   network slices).  The data model augments the 'ietf-network' data
>   model by adding the concept of service attachment points (SAPs).  The
>   service attachment points are the points to which network services
>   (such as L3VPN or L2VPN) can be attached.  The customer endpoint of
>   an attachment circuits are not covered in the SAP network topology.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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://www.ietf.org/mailman/listinfo/opsawg