Subject: [L3sm] draft-zaalouk-supa-vpn-service-management-model

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Mar 2015 10:59:35 +0100

Dear all,

FYI. 
http://tools.ietf.org/id/draft-zaalouk-supa-vpn-service-management-model-02.txt

Regards, Benoit

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 11 Mar 2015 14:23:31 +0100

> FYI. http://tools.ietf.org/id/draft-zaalouk-supa-vpn-service-management-model-02.txt <http://tools.ietf.org/id/draft-zaalouk-supa-vpn-service-management-model-02.txt>

I took a little while to review this model from a YANG Doctor point of view. This model seems pretty good from a YANG perspective, I think.

ietf-supa-l3vpn.yang:
- list l3vpn-Instance; suggest name change to “l3vpn-instance” to conform to IETF naming conventions
- it is customary to surround the top level list with a container, e.g. container l3vpn-instances
- max-elements 65535; // to be discussed — what is the point with this limit?
- leaf instance-name pattern; why is this pattern here?
- mandatory true; on a key leaf is superfluous, suggest removing it
- leaf servic-type; should presumably be “service-type”?

- list access-interface-id; somewhat odd name for a list, wouldn’t “access-interface” be more appropriate?
- max-elements 65535 — what is the point with this limit?
- leaf access-interface-id; should this be a reference to the interface table in ietf-interfaces.yang?
- mandatory true; on a key leaf is superfluous, suggest removing it
- leaf access-interface-address, ip-address-mask-length, maybe replace with "ip-prefix” of type “inet:ip-prefix”? This type allows both IPv4 and IPv6 prefixes (IP/mask)
- leaf role; since this leaf seems relevant only for hub-spoke service types, maybe add a when-expression?   when "../../service-type = ‘hub-spoke’”;

- leaf user-name, leaf user-password; I seriously doubt that we want to have device management information in the l3vpn model. That kind of information should be stored in a separate model, or left out of scope. It’s not the customer defining the VPN that should fill in these credentials.
- leaf physical-node-id; I think this should be a reference to another module where the managed physical nodes are listed. An arbitrary string value will not do.
- leaf physical-access-interface; I think this should be a reference to the list of interfaces on that device. An arbitrary string value will not do. Also, is the the interface referenced always going to be a “physical” interface? How does this leaf differ from the leaf access-interface-id above? Maybe a clarifying description would help.

- container protocol; the description is a little short; expand or remove.
- leaf protocol-type; are the only relevant protocols ever going to be “bgp”, “ospf”, “isis”? If this set could grow over time, potentially, then an identity-ref might be a better idea. This way it’s easy to define a module with additional alternatives in the future. Even proprietary ones.
- container igp-attribute and container bgp-attribute would probably be better integrated with the protocol-type, perhaps making the whole construct a choice between igp and egp protocols, with an identityref inside (if it is conceivable that the set of protocols could grow). That would also remove the current issue with strange default “0” statements.
- leaf remote-peer-address is currently defined as mandatory in such a way that it has to be specified even if the selected protocol is an igp protocol. Reworking the protocol-type into a choice would fix that.

ietf-supa-ddc.yang:
- container ddc-service; suggest name “ddc-services” to conform to conventions
- leaf name; mandatory true; superfluous for a key, suggest to remove this
- leaf tenant-name; mandatory true; if an operator wants to leave this blank, is that a problem?
- leaf-list dc-name; should this be a reference to a list of data centers? keeping this as a string is weak
- leaf-list interface-name; modeling this as a leaf-list of strings seems very weak to me. Could we turn this into references of some kind?

- leaf connection-type; suggest “L2VPN” is named “l2vpn”, “L3VPN” is named “l3vpn”, why is native-ipv4 described as “L4VPN”?
- leaf connection-name; this should be a reference to the l3vpn instance, type leafref { path "/l3vpn:l3vpn-instance/instance-name”; }
- leaf vlanId; suggest name “vlan-id”; description could tell what happens if vlan-id is not set
- leaf bandWidth; suggest name “bandwidth” or “speed”; would be good to use a larger type, e.g. uint64; would be good to specify unit, e.g. units “bps”;
- leaf latency; is this something that is configured? would be good to specify unit, e.g. units “ns”;

In other l3vpn models I have seen, there have usually been some qos configurations as well. Would we want to add that?

/Jan Lindblad

---

From: Vikram Choudhary <[email-masked]>
Date: Wed, 18 Mar 2015 05:20:10 +0000

Hi All,

Can you please provide your thought on my queries.

Thanks
Vikram

-----Original Message-----
From: Vikram Choudhary 
Sent: 10 March 2015 18:26
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]; Dongfeng (C); Jixiaofeng (Steven); Dhruv Dhody; Kalyankumar Asangi
Subject: RE: [L3sm] draft-zaalouk-supa-vpn-service-management-model

Hi All,

Request you to kindly help me to understand below points as proposed in the draft.

1. Section: 3.1.1.
	>> Why do we need both "access-interface-id" and "access-interface-address + ip-address-mask-length" as mandatory parameter for identifying an access interface. 
		-> As per my understanding access-interface-id will be unique for each interface and hence will be sufficient for identifying access-interface.
		-> Moreover, 2 interfaces can't have same ip address so only "access-interface-address + ip-address-mask-length" will be enough for identifying access interface.
		-> I feel these parameters are mutually exclusive and anyone of them can serve the purpose. No need of making all of them as mandatory.
	
	>> "protocol-type" can be extended to include "RIP" and "STATIC" protocol-type.

	>> "igp-attribute" container needs to be extended as per the "protocol-type". Currently, only the "protocol-id" field is defined which may not be sufficient for forming IGP peer
	relationship between CE and PE device's.
		-> Example: OSPF needs area, hello time-interval, dead time-interval and etc for establishing adjacencies. 
			(Assume CE devices have different hello and dead time-interval configuration)
 
2. Section: 3.2.1.
	>> Provision for "vlanId" is only available. Since vxLan is also used in DDC now, how to handle these cases? I feel this part may be made more generic to handle any L2 technology.

Thanks
Vikram

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 10 March 2015 15:30
To: [email-masked]
Subject: [L3sm] draft-zaalouk-supa-vpn-service-management-model

Dear all,

FYI. 

Regards, Benoit

_______________________________________________
L3sm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l3sm

---

From: Ying Cheng <[email-masked]>
Date: Thu, 19 Mar 2015 17:49:05 +0800

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

Subject: Re: RE: [L3sm] draft-zaalouk-supa-vpn-service-management-model
From: Ying Cheng <[email-masked]>
To: "Vikram Choudhary" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Dongfeng (C)" <[email-masked]>, "Jixiaofeng (Steven)" <[email-masked]>, "Kalyankumar Asangi" <[email-masked]>
Date: Thu, 19 Mar 2015 17:49:05 +0800

Hi Vikram,

Thanks for your commetns. We will update the model based on them. Below please see my response inline. 

2015-03-19 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： Vikram Choudhary 
发送时间： 2015-03-18  13:20:22 
收件人： [email-masked]; [email-masked]; [email-masked]; Ying Cheng(联通集团联通网络技术研究院); [email-masked] 
抄送： Dongfeng (C); Jixiaofeng (Steven); Kalyankumar Asangi 
主题： RE: [L3sm] draft-zaalouk-supa-vpn-service-management-model 
 
Hi All,
-----Original Message-----
From: Vikram Choudhary 
Sent: 10 March 2015 18:26
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]; Dongfeng (C); Jixiaofeng (Steven); Dhruv Dhody; Kalyankumar Asangi
Subject: RE: [L3sm] draft-zaalouk-supa-vpn-service-management-model
Hi All,

[Ying]You're right. I remember a previous email from Jan also pointed this out. We will remove this mandatory lines only leave one for access-interface-id. 

>> "protocol-type" can be extended to include "RIP" and "STATIC" protocol-type.

[Ying]Right, in fact, in my previous response to Jan, I also mentioned to add this.:)

[Ying]It's true. We should have taken this into consideration. Thank you for the example. We will address this by adding the info you mentioned into attributes.  

2. Section: 3.2.1.
>> Provision for "vlanId" is only available. Since vxLan is also used in DDC now, how to handle these cases? I feel this part may be made more generic to handle any L2 technology.

[Ying]Sorry. I am not sure whether I captured your points. Could you please kindly elaborate it?

Thanks
Vikram

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 10 March 2015 15:30
To: [email-masked]
Subject: [L3sm] draft-zaalouk-supa-vpn-service-management-model
Dear all,
FYI.