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

Qin Wu <bill.wu@huawei.com> Thu, 04 November 2021 06:12 UTC

Return-Path: <bill.wu@huawei.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 20E173A0906 for <opsawg@ietfa.amsl.com>; Wed, 3 Nov 2021 23:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 mWIeCduaXmWH for <opsawg@ietfa.amsl.com>; Wed, 3 Nov 2021 23:12:53 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD613A0902 for <opsawg@ietf.org>; Wed, 3 Nov 2021 23:12:52 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HlCqB3LTYz67PbH; Thu, 4 Nov 2021 14:07:50 +0800 (CST)
Received: from dggeml752-chm.china.huawei.com (10.1.199.151) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.15; Thu, 4 Nov 2021 07:12:49 +0100
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml752-chm.china.huawei.com (10.1.199.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Thu, 4 Nov 2021 14:12:47 +0800
Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.015; Thu, 4 Nov 2021 14:12:47 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Chongfeng Xie <xiechf@chinatelecom.cn>, "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
CC: "opsawg@ietf.org" <opsawg@ietf.org>, "Lopez, Victor (Nokia - ES/Madrid)" <victor.lopez@nokia.com>
Thread-Topic: [OPSAWG] New Version Notification for draft-dbwb-opsawg-sap-00.txt
Thread-Index: AdfRQvk2VfgGwhhYtEyaJ1TMhvgSYQ==
Date: Thu, 04 Nov 2021 06:12:46 +0000
Message-ID: <3b3b2079775242c687471c972dd57f44@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: multipart/alternative; boundary="_000_3b3b2079775242c687471c972dd57f44huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/wzyhu2_goSe7qyAbfLSalRnLIzM>
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: Thu, 04 Nov 2021 06:12:58 -0000

Thank Chongfeng for valuable comments to this draft. See reply inline below.
发件人: OPSAWG [mailto:opsawg-bounces@ietf.org] 代表 Chongfeng Xie
发送时间: 2021年11月2日 21:20
收件人: <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com>
抄送: opsawg@ietf.org; Lopez, Victor (Nokia - ES/Madrid) <victor.lopez@nokia.com>
主题: Re: [OPSAWG] New Version Notification for draft-dbwb-opsawg-sap-00.txt

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

2.      from domain controller to the upper layer application?
[Qin]:Good suggestion, we authors also discuss what usage example we will bring up in the offline discussion and will present one of our usage example in the upcoming IETF 112.
Bear in mind, this model is not customer facing model but a model which can provide management tool for operators to manage their network and provide network visibility to the overlay
topology, even in the end to end service spanning across multiple domains, this model can also provide a mangaement tool for operators to know the sequence of dmomains involves and interconnection points assoicated with each domain.
2. I think we should emphasize L3NM or L2NM used to configure VPN while this model is used for capability exposure.
[Qin]: Agree with your assessment, thanks.

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?
[Qin]:Our initial thought is to investigate IANA interface Type in RFC7224, but it is apparently IANA interface type in RFC7224 is not sufficient to represent ethernet sub-interface,
If you look at RFC7224, it only specify atmSubInterface identity. Therefore we think it is more reasonable to extend if:interface-type to support some new interface type. Thanks
for raising this issue.

Chongfeng Xie
2021年10月22日 下午8:04,mohamed.boucadair@orange.com<mailto: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<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Envoyé : vendredi 22 octobre 2021 13:57
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; Oscar Gonzalez de Dios <oscar.gonzalezdedios@telefonica.com<mailto:oscar.gonzalezdedios@telefonica.com>>; Oscar de Dios <oscar.gonzalezdedios@telefonica.com<mailto:oscar.gonzalezdedios@telefonica.com>>; Qin WU <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>; Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>; Samier Barguil <samier.barguilgiraldo.ext@telefonica.com<mailto:samier.barguilgiraldo.ext@telefonica.com>>; Victor Lopez <victor.lopez@nokia.com<mailto:victor.lopez@nokia.com>>; samier barguil <samier.barguilgiraldo.ext@telefonica.com<mailto: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<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg