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

From: Chongfeng Xie <[email-masked]>
Date: Tue, 2 Nov 2021 21:20:26 +0800

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，[email-masked] 写道：
> 
> 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-masked] <[email-masked]> 
> Envoyé : vendredi 22 octobre 2021 13:57
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Oscar Gonzalez de Dios <[email-masked]>; Oscar de Dios <[email-masked]>; Qin WU <[email-masked]>; Qin Wu <[email-masked]>; Samier Barguil <[email-masked]>; Victor Lopez <[email-masked]>; samier barguil <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Qin Wu <[email-masked]>
Date: Thu, 4 Nov 2021 06:12:46 +0000

Thank Chongfeng for valuable comments to this draft. See reply inline below.
发件人: OPSAWG [mailto:[email-masked]] 代表 Chongfeng Xie
发送时间: 2021年11月2日 21:20
收件人: <[email-masked]> <[email-masked]>
抄送: [email-masked]; Lopez, Victor (Nokia - ES/Madrid) <[email-masked]>
主题: 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-masked]<mailto:[email-masked]> 写道：

Hi all,

Cheers,

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 22 octobre 2021 13:57
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; Oscar Gonzalez de Dios <[email-masked]<mailto:[email-masked]>>; Oscar de Dios <[email-masked]<mailto:[email-masked]>>; Qin WU <[email-masked]<mailto:[email-masked]>>; Qin Wu <[email-masked]<mailto:[email-masked]>>; Samier Barguil <[email-masked]<mailto:[email-masked]>>; Victor Lopez <[email-masked]<mailto:[email-masked]>>; samier barguil <[email-masked]<mailto:[email-masked]>>
Objet : New Version Notification for draft-dbwb-opsawg-sap-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg