Thank Chongfeng for valuable comments to this draft. See reply inline below. 发件人: OPSAWG [mailto:[email protected]] 代表 Chongfeng Xie 发送时间: 2021年11月2日 21:20 收件人: <[email protected]> <[email protected]> 抄送: [email protected]; Lopez, Victor (Nokia - ES/Madrid) <[email protected]> 主题: 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，[email protected]<mailto:[email protected]> 写道： 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 : [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Envoyé : vendredi 22 octobre 2021 13:57 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; Oscar Gonzalez de Dios <[email protected]<mailto:[email protected]>>; Oscar de Dios <[email protected]<mailto:[email protected]>>; Qin WU <[email protected]<mailto:[email protected]>>; Qin Wu <[email protected]<mailto:[email protected]>>; Samier Barguil <[email protected]<mailto:[email protected]>>; Victor Lopez <[email protected]<mailto:[email protected]>>; samier barguil <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
