Oscar: Speak as contributor or for software implementers, I would like to thank you to initiate this work, a few thoughts on this model design choice: 1.It is not clear to me whether L3NM model is positioned as Network model or service model.
l Service model focus on describing what the service is while network model focusing how to realize the service. l Service model is used as input to automated control and configuration applications while network model is translated or derived from service model and is used to describe instantiated L3VPN with various resource allocation (e.g., RT,RD, endpoint/attachment point), therefore network model doesn’t need to take the same model structure as L3SM model. 2.L3SM describes customer view of L3VPN service and can be used to describe multiple sites belonging to multiple VPNs, spanning across multiple domains. However L3NM model is described domain controller view of L3VPN service, it will be great to allow automated control and configuration applications decomposed L3SM with multiple VPNs support into multiple per VPN Network model (per VRF or VRF centric), then domain controller can manage VPN service one by one, it also will be convenient to allow Domain controller further decompose per VPN Network model into various device model or network element models(e.g., Network instance model, BESS L3VPN model). 3. If we can model L3NM model as per VPN Network model, describe the relationship between VPN service and site/endpoints as parent child relationship instead of sibling relationship defined in L3SM model, then cross reference(e.g., using leafref) between VPN service and site/endpoint is not needed. Therefore I think taking “Prune and extend” approach make us easily decompose abstract view of VPN service from customer perspective spanning multi-domain, multi-layer to domain specific view of VPN service or resource level of VPN. -Qin 发件人: OPSAWG [mailto:[email protected]] 代表 Oscar González de Dios 发送时间: 2019年5月28日 1:16 收件人: [email protected] 主题: [OPSAWG] Feedback and operators+implementers input for L3NM draft-aguado-opsawg-l3sm-l3nm-00 Dear Opsawg colleagues, I would like to ask for feedback on an operator-led initiative to build a L3VPN Network Yang model (let’s refer to it as L3NM). The first draft is available in https://tools.ietf.org/html/draft-aguado-opsawg-l3sm-l3nm-00. Please note that the yang model itself is still a work in progress, and the first intention is to show the need of having such a model and how it related to current initiatives. The starting point of the work is the L3VPN Yang model defined in RFC 8299. More complex deployment scenarios involving the coordination of different VPN instances and different technologies to provide end-to-end VPN connectivity is out of scope of this document, but is discussed in https://tools.ietf.org/html/draft-evenwu-opsawg-yang-composed-vpn-03 . RFC 8309 splits the service models into “Customer Service Model” and “Service Delivery Model”. The L3SM Yang model, defined in RFC 8299, is valid for the customer to network operator conversation, but if operators want to use it for the conversations between the B/OSS (business and operation support systems) and the network orchestrator (or controller, depending on the terminology used) then the model has some gaps. There are two options: A) “Augment” approach. This is the approach shown in version 00. The model in RFC 8299 is extended via augmentation to cover the gaps. Still, some parameters defined by L3SM may not be necessary for the network version of the service model (those more related to the customer, which are mandatory for the direct customer interface). B) “Prune and extend” approach. This approach will present an easier way to ignore and prune unnecessary information defined at L3SM. At the same time, any extension can be presented as part of the main module, and not as augments of an existing model. However, many content would be similar to L3SM In the draft you can find a first set of topics covered by the model. The scenarios covered include: the integration of ethernet and encapsulation parameters, the extension for transport resources (e.g. RTs and RDs) to be orchestrated from the management system, far-end configuration of PEs not managed by the management system and the definition for PE identification. Note the end customer does not really care about the internal network resources, neither does care exactly which PE is used. Those decisions are taken by the operator, that then with the help of the control systems will deploy the service. We would like to ask input from operators/service providers who might use this model and from software implementers who might code the model. Best Regards, Oscar ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
