Thanks Oscar, please see my follow up comments.
发件人: Oscar González de Dios [mailto:[email protected]]
发送时间: 2019年6月28日 20:29
收件人: Qin Wu <[email protected]>; [email protected]
主题: RE: Feedback and operators+implementers input for L3NM
draft-aguado-opsawg-l3sm-l3nm-00
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.
[Qin]: Agree, so we should made good use of the service level model and network
level model to automate the network management, everything relying on automated
tool and software development is expensive, error prone and the time to take
CICD process, especially test process is long.
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.
[Qin]: Make sense, the resource parameters such as RT,RD, PE address, port, VRF
need to decided and correlated with the service, e.g., 1:1,1:n, then we can
convert resource back to the service or we can provide service assurance based
on the resource change monitoring
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.
[Qin]: Understand, thank for good clarification.
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.
[Qin]: Good, I will review the model and get back to you in the separate email.
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).
[Qin]: I think each site_network_access will represent an interface on PE, we
should make sure each network access is only assigned with one single VPN
nodes, and at the same we can allow Each VPN node have multiple
site-network-accesses.
In the current model, this is not clear:
| +--rw vpn-nodes
| | +--rw vpn-node* [vpn-node-id ne-id]
| | +--rw vpn-node-id string
……
| | +--rw site-attachments
| | +--rw site-attachment* [site-id]
| | +--rw site-id ->
/l3vpn-ntw/sites/site/site-id
| | +--rw site-network-access-id* ->
/l3vpn-ntw/sites/site/site-network-accesses/site-network-access/site-network-access-id
unless you add constraint to restrict one site-network-access-id only having
one vpn node. Simply way to address this is to delete site-attachments, and add
vpn-attachment as follows:
+--rw site-network-accesses
+--rw site-network-access* [site-network-access-id]
+--rw site-network-access-id svc-id
+--rw site-network-access-type? identityref
+--rw vpn-attachment
+--rw vpn-node-id string
In this case, we don’t need to associate site-id together with
site-network-access-id with one VPN node.
Another benefit is to make it easy to map L3NM to Network instance model in
RFC8529, which establish one to one relationship between interface and network
instance.
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.
[Qin]: Do we need to keep cloud access and multicast global cross sites
parameters under VPN-service?
Best Regards and looking forward to continue the discussions,
Oscar
-Qin
发件人: OPSAWG [mailto:[email protected]] 代表 Oscar González de Dios
发送时间: 2019年5月28日 1:16
收件人: [email protected]<mailto:[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
________________________________
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
