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

["Chongfeng Xie" <[e-mail]>]

I have read draft-aguado-opsawg-l3sm-l3nm-00 and it is well written and I like it and fully support it if IETF wants to adopt this work.
Since operator not only cares about how to define a service using the service model, but also how to realize the service using e.g.,the model
Proposed in this draft. Here are a few quick comments:
1.       The abstract said
“In some cases, the control of the network is further expanded into per-domain control. ”
What does expanded means? Expanded or broken down into?
s/Control of the network/control of the network spanning across multiple domains

2.       The abstract also said:
”This document uses the L3SM model defined in RFC 8299 [RFC8299], and extends it to facilitate communication between the service orchestrator and transport orchestrator (MSDC), and an MDSC and
domain controllers.  The resulting model is called the L3VPN Network Model (L3NM).”
I think the terminology in this document should be consistent.
s/transport orchestrator/network orchestrator

3.       Section 1, paragraph 2
”The augmentations facilitate the use the resulting model in communications with the transport orchestrator, also known as the MDSC (Multi-Domain Service
Coordinator) in the terminology of the framework for Abstraction and Control of TE Networks (ACTN) defined in RFC 8453 [RFC8453].
”
I feel disconnected about this sentence when it says the use the resulting model, how about
s/the use the resulting model/the use of the resulting model

4.Section 2
”In that context, the "Domain Orchestration" and "Config Manager" roles may be performed by "Controllers".”
Controller or domain controller? Are you assuming config manager is part of the same controller?
 
5.       Section 3 title
s/Yang model extensions/YANG model extensions

Chongfeng



 
From: Qin Wu
Date: 2019-07-01 10:22
To: [e-mail]
Subject: [OPSAWG] Review of L3NM draft-aguado-opsawg-l3sm-l3nm-0
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