[OPSAWG] Review of L3NM draft-aguado-opsawg-l3sm-l3nm-0

Qin Wu <bill.wu@huawei.com> Mon, 01 July 2019 02:22 UTC

From: Qin Wu <bill.wu@huawei.com>
To: "OPSAWG@ietf.org" <OPSAWG@ietf.org>
Thread-Topic: Review of L3NM draft-aguado-opsawg-l3sm-l3nm-0
Thread-Index: AdUvrwegtsQg14vvRkuUbrhmysDe3w==
Date: Mon, 01 Jul 2019 02:22:35 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA49BC61F@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA49BC61Fnkgeml513mbxchi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/-8MY2_GV9WMXb3s7ZsGw55HkfNw>
Subject: [OPSAWG] Review of L3NM draft-aguado-opsawg-l3sm-l3nm-0
Precedence: list

Hi, Oscar:
I have reviewed draft proposal you posted on https://github.com/oscargdd/l3nm/tree/master/yang/01 which is subject to changes and have a few comments and suggestions as follows:

1.       ie-profiles is defined under vpn-service in parallel with vpn-node
I am not sure it is necessary to define profile or template for RD and RT in a group,
suppose we only have 3 or 5 RDs, it make sense to define them as profile or template, and reuse these profile or template. However suppose we have tens or hundreds of RDs, we have to define hundreds of ie-profile, which is not desirable,
Suggested change is to consolidate parameters within ie-profiles into parameters within vpn-node.


2.       Since we have already allocated RT, RD associated with the sevice, VPN-policy became useless, suggest to remove it.


3.       Group-id defined in site level and site-network-access level become useless, since it is used in L3SM model as access constraints parameters to select PE, in L3NM model, PE has already been selected.
However in L3NM model, we still want to classify the network access associated with the VPN service into several groups and want to know which network accesses associated with the same VPN belong to which group, e.g., when one site connect to two VPN, this site has three network accesses, let's say access A, Access B, Access C
Access A, Access B connect to VPN A, Access C connect to VPN B, we can classify them into two group, Access A and Access B belong to dual home group, Access C belong to single home group.
Suggest change is to introduce access group level between site level and network access level, looks like this:
     +--rw sites
        +--rw site* [site-id]
           +--rw site-id                  svc-id
           +--rw access-groups
              +--rw access-group* [group-id]
                 +--rw group-id      svc-id
                 +--rw site-network-accesses
                     +--rw site-network-access* [site-network-access-id]
                         +--rw site-network-access-id      svc-id
                         +  vpn-node
                         +--rw bearer
                         |  +--...
                         +--rw availability


4.       Go back to the vpn-attachments proposal in the previous email to address the relationship between site-network-access and vpn-node, we can optimize that proposal a little bit further,i.e., remove vpn-attachment container, directly introduce vpn-node-id under each site-network-access. What do you think of it?

5.       Regarding  tg-type and  cvlan-id under dot1q-vlan-tagged, it is not clear we should define multiple tag types, what is the real use case ? Also usually one interface will be configured with multiple cvlan-ids, how to deal with it?
Hope these comments help. Thanks!

-Qin Wu

[OPSAWG] Review of L3NM draft-aguado-opsawg-l3sm-… Qin Wu
Re: [OPSAWG] Review of L3NM draft-aguado-opsawg-l… Chongfeng Xie