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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
