Re: [OPSAWG] Feedback and operators+implementers input for L3NM draft-aguado-opsawg-l3sm-l3nm-00

[Oscar González de Dios <[e-mail]>]

Hi Quin,

                Thanks for the comments, let me answer inline:
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).

[Oscar]
                As you mention, L3SM describes the customer view of the service. And precisely it can be used in interactions between customers and network operators. Any hint on the “internals” of the VPN within the operator’s network are explicitly out of the model. The strength of the L3SM model is giving a clear definition of what the service is and what exactly will be the interactions from the customer equipment. So, I think L3SM qualifies perfectly as “Customer Service Model”, as you define in RFC 8309.

                Based on a “Customer Service Model”, the operator will need to do perform some operations, not all of them can be automated tools. For example there are initial phases in which the operator has to solve the physical connectivity, or decide which is the closest central office to which the customer will be connected. Then, after physical connectivity is solved, the operator, either by automated means, or by human decisions, has made some decisions on how to provide the desired service by the customer, e.g. the exact Provider Edge and port used, which encapsulation will be used, etc, the L3NM model can be used.

                The L3NM is aimed at being the view of the service in the operator for a given network domain and can be sent as input to automated tools to provision the VPN service. This automated tools (e.g. a “domain controller”) can further use device models to configure the network elements or other specific model . The assumption is that the L3NM model CAN include, optionally, some resource information that is used to construct the service. By resources I mean any kind of configuration that its assignment impacts other services and cannot be randomly allocated. The reason to include those resources as optional is to allow different ways of operating the network, from the extreme case of leaving everything to the controller, or doing the allocation in the Operation Support System.

                I would classify the model as L3VPN Network Model and it can be called from OSS systems/Orchestrators and exposed by network controllers (responsible for a set of nodes of the operator’s network, not necessarily all the nodes). Honestly, I’ve read many times RFC 8309 and 8199, but can’t find the perfect definition for it ☺. I hope with the explanations the aim is clear, and with some discussions on the mailing list, we reach a consensus on the terminology.



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.

[Oscar] Please find in https://github.com/oscargdd/l3nm/tree/master/yang/01 a draft proposal of the model with the “prune and extend” approach. Our aim is to submit a new version of the draft with this changes.

I think that in order to avoid the cross reference that you mention, we would need to go further than just “prune and extend” and make deeper changes in the model. Nevertheless, let me explain current proposal that covers partially the parent-child relation that you just mentioned:

The proposal is that services contain vpn_nodes.  Each vpn_node will be associated to a certain PE (identified by a router_id) and will have site_attachments (that identify the the site_network accesses which will include a reference to the site and bearer).

Note that, in current version, as we still follow the same base structure as L3SM, we keep the list of sites separately. And for each site, the list of bearers and the list of site network accesses. Each bearer belongs to a PE node and can be shared among serveral site_network acceses.

Best Regards and looking forward to continue the discussions,

                Oscar





-Qin
发件人: OPSAWG [mailto:[e-mail]] 代表 Oscar González de Dios
发送时间: 2019年5月28日 1:16
收件人: [e-mail]<mailto:[e-mail]>
主题: [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

________________________________

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