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

Qin Wu <> Thu, 06 June 2019 10:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80E9E12009E for <>; Thu, 6 Jun 2019 03:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eHN4ysfTQ5m0 for <>; Thu, 6 Jun 2019 03:36:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9267F120094 for <>; Thu, 6 Jun 2019 03:36:57 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id F2B68E9A6B137006F839; Thu, 6 Jun 2019 11:36:55 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Jun 2019 11:36:55 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 6 Jun 2019 11:36:55 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 6 Jun 2019 11:36:54 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Thu, 6 Jun 2019 18:36:50 +0800
From: Qin Wu <>
To: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= <>, "" <>
Thread-Topic: Feedback and operators+implementers input for L3NM draft-aguado-opsawg-l3sm-l3nm-00
Thread-Index: AdUcU76eD0hgyvJ6RZK6AKxC2mS0Bw==
Date: Thu, 6 Jun 2019 10:36:50 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA496367Bnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [L3sm] Feedback and operators+implementers input for L3NM draft-aguado-opsawg-l3sm-l3nm-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jun 2019 10:37:01 -0000

Speak as contributor, 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.


发件人: L3sm [] 代表 Oscar González de Dios
发送时间: 2019年5月28日 1:20
主题: [L3sm] Feedback and operators+implementers input for L3NM draft-aguado-opsawg-l3sm-l3nm-00

Dear L3SM 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) building on top of the work that was carried out in the L3SM working group. The first draft is available in As the working group is now formally closed, I have also sent the email and posted the first version of the draft in the context of OPSAWG.

      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 .

    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,



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