Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt

[<[e-mail]>]

Hi,

Please find inline comments.

From: L3sm [mailto:[e-mail]] On Behalf Of Aijun Wang
Sent: Thursday, July 09, 2015 09:10
To: [e-mail]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt

Hi, All:
I read through this draft and the corresponding YANG model, and has the following opinions and suggestions, please to see whether are they appropriate?

General Questions:

1.       Can we divide the contents in more service modules? Such as l3vpn, Internet access, multicast service etc.

[SLI] This is something that can be discussed, but I’m interested in arguments. For Cloud access (including Internet), I had in mind to propose to take it out of the vpn cfg.
2.  Can we omitted the background information for VPN topology?. [SLI] What info are you talking about ?
3.  we need one standalone document to describe clearly the relationship between the service orchestrator module and other system, such as OSS system。
4.  can we make one clear boundary for what should be consider by service model and what should be considered by device model, to reduce the overlapping between them?
5.  Is there any mechanism to decompose the l3vpn service to underlying device model automatically? Or else there is no more merit to use the YANG model to describe the service.
[SLI] It would be a role between orchestration and PNF manager to do the translation.

Detailed suggestion about the YANG model:

1.         About “Site-availability”

a)         Identity "Single" should be "Single-Site" [SLI] Agree



2.         About “Site-type”

a)         Identity “Site-type” should be “site-role” [SLI] Sounds good to me

b)         Identity “any-to-any site” should be “normal role(can access all other sites)”

c)         Identity “spoke-site” should be “spoke-role” [SLI] I’m fine, if other people think this is useful to change

d)         Identity “hub-site” should be “hub-role” [SLI] I’m fine, if other people think this is useful to change



3.  About “vpn-topology”

   There is no restriction or relationship description for the “site-type” and ”vpn-topology”. For example, if one vpn service is “any-to-any”, then the role of all sites within it will be “normal-role”. And the “hub-role”, “spoke-role” should only exist within the “hub-spoke” or “hub-spoke-disjoint” vpn topology.  Can we organize these two identity within one container?

[SLI] I will see how to do this.



4.  About “routing-protocol-type”

a)         Why not include the isis protocol identity?

b)         “vrrp” identity is not one routing-protocol

[SLI] about a) , do you know someone using isis as PE-CE routing protocol ? we can add it, but is it useful ? about vrrp, I agree that’s it not a routing protocol but I wanted to keep the model simple and let all the “routing methods” within the same container. If you find a better name than routing protocol, I would be fine to change it.



5. About “l4-protocol-type”

a)         This should be changed to “traffic protocol type” ? This value only be used within the Qos match action and “icmp”, “icmp6”, “hop-by-hop” etc. identity are not belong to l4 protocol.

[SLI]  I agree that there is a misuse of the name, but I think protocol is maybe too generic as it can refer to any layer. I want only to refer to the protocol type in IP header.



6. About “cloud-access”

  Can its name be changed to “Internet-Access”? [SLI] No, because it also permit to access to some Private cloud



7. About “Anycast-rp-locatioin”

 Can its name be changed to “rp-location”?



8. What is meaning and usage of “native-vpn”?

[SLI] There was some issue to model sites belonging to multiple VPNs with complex policies. So we decided that a site is primarly belonging to one VPN (the native VPN) and then can define some policies to open access to other VPNs.



9. About VPN service start and end leaf type.

  Is it useful to introduce the following leaf type : “requested-site-start”/“requested-site-stop”/”actual-site-start”/” actual-site-stop” if we use the http restful API to provide the service to customer?

[SLI] There was a discussion thread on the list regarding that.



10. what is the meaning of “site-diversity”

[SLI] Site diversity opens the ability to provision multiple sites within a VPN that are not sharing the same fate.



11. “maximus-routes” should be included within the “vpn-policy” under the import-policy/export-policy

[SLI] What’s the reason to do that ?



12. “lan-prefix” should be “site-prefix”. Also for “ipv4-lan-prefixes/ipv6-lan-prefixes/lan-tag”

[SLI] I personally don’t care, so I will people comment on this.




Best Regards.
Aijun Wang

China Telecom Corporation Limited Beijing Research Institute
Intelligent Network Product Line

Tel : [phone]
Mobile:  [phone]








-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, July 02, 2015 9:06 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the L3VPN Service Model  Working Group of the IETF.



        Title           : YANG Data Model for L3VPN service delivery

        Authors         : Stephane Litkowski

                          Rob Shakir

                          Luis Tomotaki

                          Kevin D'Souza

         Filename        : draft-ietf-l3sm-l3vpn-service-model-00.txt

         Pages           : 82

         Date            : 2015-07-02



Abstract:

   This document defines a YANG data model that can be used to deliver a

   Layer 3 Provider Provisioned VPN service.  The document is limited to

   the BGP PE-based VPNs as described in RFC4110 and RFC4364.  This

   model is intended to be instantiated at management system to deliver

   the overall service.  This model is not a configuration model to be

   used directly on network elements.  This model provides an abstracted

   view of the Layer 3 IPVPN service configuration components.  It will

   be up to a management system to take this as an input and use

   specific configurations models to configure the different network

   elements to deliver the service.  How configuration of network

   elements is done is out of scope of the document.







The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-00





Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

L3sm mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/l3sm

_________________________________________________________________________________________________________________________

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.