Re: [L3sm] Inventory ops state

Qin Wu <bill.wu@huawei.com> Wed, 19 August 2015 02:57 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C041AC402 for <l3sm@ietfa.amsl.com>; Tue, 18 Aug 2015 19:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.16
X-Spam-Level:
X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkNdOECuC4kh for <l3sm@ietfa.amsl.com>; Tue, 18 Aug 2015 19:57:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B3B1AC3FF for <l3sm@ietf.org>; Tue, 18 Aug 2015 19:57:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAB05414; Wed, 19 Aug 2015 02:57:19 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 19 Aug 2015 03:57:18 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Wed, 19 Aug 2015 10:57:14 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "l3sm@ietf.org" <l3sm@ietf.org>
Thread-Topic: Inventory ops state
Thread-Index: AdDY0m/bm5MlBeIySwyOIunTMQUGYwAxFZ3AAAMJqIAAAEKw0AAAp0YQACCSm3A=
Date: Wed, 19 Aug 2015 02:57:13 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8480F910@nkgeml501-mbs.china.huawei.com>
References: <10923_1439805318_55D1AF86_10923_3142_12_9E32478DFA9976438E7A22F69B08FF92166C0ABC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <B8F9A780D330094D99AF023C5877DABA8480F51F@nkgeml501-mbs.china.huawei.com> <31834_1439894909_55D30D7C_31834_2110_1_9E32478DFA9976438E7A22F69B08FF92166C0EE4@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <B8F9A780D330094D99AF023C5877DABA8480F585@nkgeml501-mbs.china.huawei.com> <11721_1439896436_55D31374_11721_5840_1_9E32478DFA9976438E7A22F69B08FF92166C0F2D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <11721_1439896436_55D31374_11721_5840_1_9E32478DFA9976438E7A22F69B08FF92166C0F2D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: multipart/related; boundary="_004_B8F9A780D330094D99AF023C5877DABA8480F910nkgeml501mbschi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/l3sm/GhD46ijExwYvC7ZFCkzZL5sxCjA>
Subject: Re: [L3sm] Inventory ops state
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2015 02:57:27 -0000

From the example below, I tend to agree native-vpn is not needed.
It seems to me vpn policy can also be used to specify which VPNs are attached to a particular site or specify one site belonging to multiple VPN,
Do we need to add association between site and VPN also in the operational state subtree?

In addition, I feel, entries list should be entry list, when  VPN-policy as container contains multiple entries, e.g.,
<vpn-policy>
       <entry>
           <id>1</id>
           <vpn>
               <vpn>VPN1</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entry>
       <entry>
           <id>2</id>
           <vpn>
               <vpn>VPN2</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entry>
   </vpn-policy>
The Corresponding service model structure for VPN policy should be

         |  +--rw vpn-policy
         |  |  +--rw entry* [id]

-Qin
发件人: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
发送时间: 2015年8月18日 19:14
收件人: Qin Wu; l3sm@ietf.org
主题: RE: Inventory ops state

PVN policy is used to attach a site to one or multiple VPNs.

Example :
                Site attached to a single VPN :
<vpn-policy>
       <entries>
           <id>1</id>
           <vpn>
               <vpn>VPN1</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entries>
   </vpn-policy>

Site attached to a multiple VPNs :

<vpn-policy>
       <entries>
           <id>1</id>
           <vpn>
               <vpn>VPN1</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entries>
       <entries>
           <id>2</id>
           <vpn>
               <vpn>VPN2</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entries>
   </vpn-policy>

Site attached to a multiple VPNs with LAN separation :

<vpn-policy>
       <entries>
           <id>1</id>
           <filter>
               <lan-tag>LAN1</lan-tag>
           </filter>
           <vpn>
               <vpn>VPN1</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entries>
       <entries>
           <id>2</id>
           <filter>
               <lan-tag>LAN2</lan-tag>
           </filter>
           <vpn>
               <vpn>VPN2</vpn>
               <site-role>any-to-any-role</site-role>
           </vpn>
       </entries>
   </vpn-policy>


From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, August 18, 2015 12:58
To: LITKOWSKI Stephane SCE/IBNF; l3sm@ietf.org<mailto:l3sm@ietf.org>
Subject: RE: Inventory ops state

发件人: stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> [mailto:stephane.litkowski@orange.com]
发送时间: 2015年8月18日 18:48
收件人: Qin Wu; l3sm@ietf.org<mailto:l3sm@ietf.org>
主题: RE: Inventory ops state

Some people told that the notion of native VPN was not really clear, especially for the management of a site belonging to multiple VPNs.
So rather than having native VPN+vpn policy, I just kept a simplified vpn policy where we can express rules for VPN attachment.
The VPN policy is a list of entry, where a site or LAN of the site is attached to a VPN (using a ref) and adding its role within the VPN.

[Qin]: To a VPN or To multiple VPN?, can VPN policy still be applied to multiple VPNs?

Since Section 5.2.2 of draft-ietf-l3sm-l3vpn-service-model-01 said:
“

The VPN policy defines the route exchange between multiple VPNs. A
vpn-policy configuration MUST be configured to attach a site to one
or multiple VPNs.
”

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, August 18, 2015 11:57
To: LITKOWSKI Stephane SCE/IBNF; l3sm@ietf.org<mailto:l3sm@ietf.org>
Subject: RE: Inventory ops state

Hi, Stephane:
Before considering Inventory ops state, can you tell me why native-vpn is removed from the (v-01), for better VPN policy abstraction?
Or path statement within the native-vpn is not sufficient to associate one VPN with one site?
Can native-vpn in the earlier version be used to identify the specific VPN one site is belong to? It seems native-vpn parameter can tell us
Which VPN is associated with which site?

-Qin
发件人: L3sm [mailto:l3sm-bounces@ietf.org] 代表 stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>
发送时间: 2015年8月17日 17:55
收件人: l3sm@ietf.org<mailto:l3sm@ietf.org>
主题: [L3sm] Inventory ops state

Hi WG,

Discussing with some colleagues, we were wondering if we can integrate some kind of inventory as operational state within the model.
The idea would be to know easily the sites attached to a particular VPN, which is not easy with the current configuration structure but we can add it in an operational state structure.
Also for cloud services being able to know quickly what VPNs are subscribing to a particular Cloud service.

Thoughts ?


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>



_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.