Subject: [L3sm] comments on draft-ietf-l3sm-l3vpn-service-model-01

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 2 Nov 2015 19:02:09 +0900

Dear authors,

I just read the draft and would like to make comments on that as one of operators.

5.2.1.2. Site availability
"sites/availability/access-type" should be set under "attachment"?
If a site is dual-homing, we have to identify which link(attachment) is primary or backup, not site itself.

ex.)
+--rw availability
|  +--rw availability-type
|  |  +--rw service-type?   identityref
|  +--rw loadsharing-type?    identityref

+--rw attachment
|  +--rw availability
|  |  +--rw availability-type
|  |  |  +--rw access-type?    identityref

5.2.2. VPN policy
"sites/vpn-poicy/entries/vpn" should also allow to be set under "l3vpn-svc"?
Section 5.2.2. provides the method to specify route exchange policies per site, however we want to do so per vpn, for extranet.

ex.)
+--rw vpn-svc* [name]
|  +--rw vpn-policy
|  |  +--rw entries* [id]
|  |     +--rw id        uint32
|  |     +--rw vpn
|  |        +--rw vpn?         leafref

5.2.5.2.1. IP addressing
When CE is customer-managed, a customer want to specify addresses of both PE and CE on the PE-CE WAN link. Then, each address of PE and CE on that link should also allow to be set under "/sites/attachment/ip-connection".

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw ipv4
|     |  +--rw address-allocation-type?   identityref
|     |  +--rw pe-address?                inet:ipv4-address
|     |  +--rw ce-address?                inet:ipv4-address
|     |  +--rw subnet-prefix?             inet:ipv4-prefix
|     +--rw ipv6
|     |  +--rw address-allocation-type?   string
|     |  +--rw pe-address?                inet:ipv6-address
|     |  +--rw ce-address?                inet:ipv6-address
|     |  +--rw subnet-prefix?             inet:ipv6-prefix

5.2.5.2.2.4. Static routing and 5.2.5.2.2.4. BGP routing
A minimum requirement is here. "remote-as" in bgp should be specified as the autonomous system of PE side, because the customer has to know the remote-as to be configured on their CE when CE is customer-managed.

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw routing-protocols* [type]
|        +--rw bgp
|        |  +--rw address-family*   identityref
|        |  +--rw remote-as	      uint16
|        +--rw static
|        |  +--rw address-family*   identityref
|        |  +--rw ipv4-lan-prefixes* [lan]
|        |  |  +--rw lan            inet:ipv4-prefix
|        |  |  +--rw lan-tag?       string
|        |  +--rw ipv6-lan-prefixes* [lan]
|        |     +--rw lan            inet:ipv6-prefix
|        |     +--rw lan-tag?       string

5.2.6.1.1. QoS classsification
"sites/service/qos/qos-classification-policy/rules/match-flow" should also allow to be set with ToS/DSCP.

ex.)
+--rw qos
|  +--rw qos-classification-policy
|  |  +--rw rules* [id]
|     |  |     +--rw id                 uint16
|     |  |     +--rw match-flow
|     |  |     |  +--rw dscp-field?    identityref

5.2.6.1.2. QoS profile
As similar as site availability, "sites/service/svc-input-bandwidth" and "svc-output-bandwidth" should also allow to be set under "attachment"?
We may want to differentiate the bandwidth per link.

ex.)
+--rw attachment
|  +--rw service
|     +--rw svc-input-bandwidth?    uint32
|     +--rw svc-output-bandwidth?   uint32

5.2.6.3. Traffic protection
Does this section overwrap Site availability section from a service perspective?

5.2.7. Customer specific information
"/sites/customer-specific-information/customer-lan-connection" should have pairs of CE address and prefix, because the management system cannot set CE LAN interface without the prefix when CE is provider-managed.
To identify the next-hop of customer lan addresses, should we set "sites/customer-specific-information/cascaded-lan-prefixes/ipv4-lan-prefixes/next-hop" as a mandatory entity? 

ex.)
+--rw customer-specific-information
|  +--rw customer-lan-connection* [address]
|  |  +--rw address        union
|  |  +--rw lan            union
|  |  +--rw lan-protocol?  identityref
|  +--rw cascaded-lan-prefixes
|     +--rw ipv4-lan-prefixes* [lan]
|     |  +--rw lan         inet:ipv4-prefix
|     |  +--rw lan-tag?    string
|     |  +--rw next-hop    inet:ipv4-address
|     +--rw ipv6-lan-prefixes* [lan]
|        +--rw lan         inet:ipv6-prefix
|        +--rw lan-tag?    string
|        +--rw next-hop    inet:ipv6-address

-Editorials

5.1.1.3.
 -3rd sentence
  "a any-to-any IPVPN service" should be "a hub and spoke IPVPN service".

5.1.1.4.
 -3rd sentence
  "a any-to-any IPVPN service" should be "a hub and spoke disjoint IPVPN service".

5.2.1.1.
 -2nd paragraph, 1st sentence
  "In the example below" should be "in the example above".

5.2.7.1.
"203.0.113.0.0/24" of CE LAN prefix should be replaced by another one, because this prefix is used as the CE WAN prefix later. This may let be confused.

5.2.7.2. and 5.2.7.3.
"CE1 owned by service provider is attached to 203.0.113.0/24 LAN of the customer." should be "CE1 owned by service provider is attached to 192.0.2.0/24 LAN and 198.51.100.0/24 LAN of the customer."

6.
"<connection>" in the configuration Spoke1 should be "<ip-connection>"

7.
"sites/attachment/connection/routing-protocol/name" is not defined.

All the best,
Kenichi

-- 
Kenichi Ogaki
KDDI Corp. | IP Network Dept.
+81-(0)80-5945-9138 | www.kddi.com

---

From: <[email-masked]>
Date: Mon, 2 Nov 2015 10:34:01 +0000

Hi,

Inline comments

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 11:02
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-l3sm-l3vpn-service-model-01

Dear authors,

[SLI] In the current model, a site = an access, if you have a customer site with two accesses, you have to configure two sites, one would be primary, the other one , would be backup. We have some discussion on going to enhance to support M to N backup support. At the current time, there is no value added to put this info into attachment.

ex.)
+--rw availability

+--rw attachment
|  +--rw availability

5.2.2. VPN policy

ex.)
+--rw vpn-svc* [name]
|  +--rw vpn-policy
|  |  +--rw entries* [id]
|  |     +--rw id        uint32
|  |     +--rw vpn
|  |        +--rw vpn?         leafref

[SLI] Could you explain the exact use case in detail ?

5.2.5.2.1. IP addressing

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw ipv4

[SLI] Is there a real need to specify each address ? IMO, subnet-prefix was enough and let the orchestration allocating the addresses in the subnet.
The subnet-prefix is useful if the customer is providing the ip block.

5.2.5.2.2.4. Static routing and 5.2.5.2.2.4. BGP routing A minimum requirement is here. "remote-as" in bgp should be specified as the autonomous system of PE side, because the customer has to know the remote-as to be configured on their CE when CE is customer-managed.

[SLI] In the current version, those informations are part of the customer-specific-information container.
There was some discussions on the list if moving from customer-specific-info to routing-protocols (see date 08/25), but it is not integrated yet.

ex.)
+--rw attachment
|  +--rw ip-connection

ex.)
+--rw qos

[SLI] We can add ToS support

5.2.6.1.2. QoS profile

ex.)
+--rw attachment
|  +--rw service

[SLI] Bandwidth is a service subscribed. A site has currently a single access. If Dual access, two sites need to be created.

5.2.6.3. Traffic protection
Does this section overwrap Site availability section from a service perspective?
[SLI] Traffic protection is FRR.

5.2.7. Customer specific information
"/sites/customer-specific-information/customer-lan-connection" should have pairs of CE address and prefix, because the management system cannot set CE LAN interface without the prefix when CE is provider-managed.
[SLI] Management system knows CE address. Nexthop is necessary when cascaded LAN are existing and the leaf already exists. Yes we can put it mandatory as it's not now.

ex.)

-Editorials

5.1.1.3.
 -3rd sentence

5.1.1.4.
 -3rd sentence

5.2.1.1.

5.2.7.1.

5.2.7.2. and 5.2.7.3.

6.

7.

All the best,
Kenichi

_________________________________________________________________________________________________________________________

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,
France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 3 Nov 2015 09:11:00 +0900

Hi Stephane,

Thank you for your prompt reply.

See comments in-line.

Thanks,
Kenichi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 7:34 PM
To: Ogaki, Kenichi; [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi,

Inline comments

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Monday, November 02, 2015 11:02
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-l3sm-l3vpn-service-model-01

Dear authors,

[KO] This should be explicitly described in 5.2. Someone would be confused like me.

ex.)
+--rw availability

+--rw attachment
|  +--rw availability

5.2.2. VPN policy

ex.)
+--rw vpn-svc* [name]
|  +--rw vpn-policy
|  |  +--rw entries* [id]
|  |     +--rw id        uint32
|  |     +--rw vpn
|  |        +--rw vpn?         leafref

[KO] In our service, we provide extranet that a customer can connect VPN1 to different VPN2 by whole VPN level.
I understand the current model also enables this to set VPN2 to "sites/vpn-poicy/entries/vpn" under all sites in VPN1, but it's convenient to control this by VPN level as an option. 

5.2.5.2.1. IP addressing

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw ipv4

[KO] Again, how a customer can know CE address when the orchestrator assigns the address in a customer-managed CE case? The operator must send the information by other means outside this model? If we use this model as the diagrams in 5.1.1.1, this should be used not only for Create a instance but also for Read the information of a instance allocated by the management system in CRUD sense.
It depends on operators, but our service is basically with customer-managed CE and, requires a customer to assign PE address and the prefix on the customer portal.

[KO] I will watch the discussion as well as regarding a following question about 5.2.7.

ex.)
+--rw attachment
|  +--rw ip-connection

ex.)
+--rw qos

5.2.6.1.2. QoS profile

ex.)
+--rw attachment
|  +--rw service

[KO] I do understand, but is it enough for a customer to specify which site is primary or backup as a service model?
FRR, node/link protection, is specific protection technique and a customer don't mind what technique recovers their traffic.

ex.)

-Editorials

5.1.1.3.
 -3rd sentence

5.1.1.4.
 -3rd sentence

5.2.1.1.

5.2.7.1.

5.2.7.2. and 5.2.7.3.

6.

7.

All the best,
Kenichi

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, France Telecom - 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 authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 3 Nov 2015 08:29:46 +0000

More inline

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Tuesday, November 03, 2015 01:11
To: [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi Stephane,

See comments in-line.

Thanks,
Kenichi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 7:34 PM
To: Ogaki, Kenichi; [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi,

Inline comments

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Monday, November 02, 2015 11:02
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-l3sm-l3vpn-service-model-01

Dear authors,

[SLI] Ok will fix the text

ex.)
+--rw availability

+--rw attachment
|  +--rw availability

5.2.2. VPN policy

ex.)
+--rw vpn-svc* [name]
|  +--rw vpn-policy
|  |  +--rw entries* [id]
|  |     +--rw id        uint32
|  |     +--rw vpn
|  |        +--rw vpn?         leafref

[SLI] Why not using site-templates to achieve this ?

5.2.5.2.1. IP addressing

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw ipv4

[SLI] OK, can add it, people may use it or not depending on use case.

ex.)
+--rw attachment
|  +--rw ip-connection

ex.)
+--rw qos

5.2.6.1.2. QoS profile

ex.)
+--rw attachment
|  +--rw service

[SLI] Agree, we cans simplify

ex.)

-Editorials

5.1.1.3.
 -3rd sentence

5.1.1.4.
 -3rd sentence

5.2.1.1.

5.2.7.1.

5.2.7.2. and 5.2.7.3.

6.

7.

All the best,
Kenichi

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.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 4 Nov 2015 09:05:45 +0900

Hi Stephane,

See one more comment in-line.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 03, 2015 5:30 PM
To: Ogaki, Kenichi; [email-masked]
Cc: [email-masked]
Subject: Re: [L3sm] comments on draft-ietf-l3sm-l3vpn-service-model-01

More inline

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Tuesday, November 03, 2015 01:11
To: [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi Stephane,

See comments in-line.

Thanks,
Kenichi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 02, 2015 7:34 PM
To: Ogaki, Kenichi; [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi,

Inline comments

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Monday, November 02, 2015 11:02
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-l3sm-l3vpn-service-model-01

Dear authors,

ex.)
+--rw availability

+--rw attachment
|  +--rw availability

5.2.2. VPN policy

ex.)
+--rw vpn-svc* [name]
|  +--rw vpn-policy
|  |  +--rw entries* [id]
|  |     +--rw id        uint32
|  |     +--rw vpn
|  |        +--rw vpn?         leafref

[KO] The current model needs to update all the sites with "apply-template".
When two existing VPNs with a large number of sites want to be connected each other for the first time. It's not good idea to require the customers to update all the sites with this model under the usage of the diagrams in 5.1.1.1. In this case, the customers just want to connect their VPNs and don't want to touch on the detail, and this would easily cause a misconfiguration.

5.2.5.2.1. IP addressing

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw ipv4

ex.)
+--rw attachment
|  +--rw ip-connection

ex.)
+--rw qos

5.2.6.1.2. QoS profile

ex.)
+--rw attachment
|  +--rw service

ex.)

-Editorials

5.1.1.3.
 -3rd sentence

5.1.1.4.
 -3rd sentence

5.2.1.1.

5.2.7.1.

5.2.7.2. and 5.2.7.3.

6.

7.

All the best,
Kenichi

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.

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

---

From: <[email-masked]>
Date: Wed, 4 Nov 2015 08:40:58 +0000

For your VPN policy thread, I will log an issue in the tracker. We need a larger discussion as there is some implication on how OSS will deal with policy information in both VPN and sites.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Wednesday, November 04, 2015 01:06
To: [email-masked]
Cc: [email-masked]
Subject: Re: [L3sm] comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 03, 2015 5:30 PM
To: Ogaki, Kenichi; [email-masked]
Cc: [email-masked]
Subject: Re: [L3sm] comments on draft-ietf-l3sm-l3vpn-service-model-01

More inline

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Tuesday, November 03, 2015 01:11
To: [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi Stephane,

See comments in-line.

Thanks,
Kenichi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 02, 2015 7:34 PM
To: Ogaki, Kenichi; [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-ietf-l3sm-l3vpn-service-model-01

Hi,

Inline comments

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Monday, November 02, 2015 11:02
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-l3sm-l3vpn-service-model-01

Dear authors,

ex.)
+--rw availability

+--rw attachment
|  +--rw availability

5.2.2. VPN policy

ex.)
+--rw vpn-svc* [name]
|  +--rw vpn-policy
|  |  +--rw entries* [id]
|  |     +--rw id        uint32
|  |     +--rw vpn
|  |        +--rw vpn?         leafref

5.2.5.2.1. IP addressing

ex.)
+--rw attachment
|  +--rw ip-connection
|     +--rw ipv4

ex.)
+--rw attachment
|  +--rw ip-connection

ex.)
+--rw qos

5.2.6.1.2. QoS profile

ex.)
+--rw attachment
|  +--rw service

ex.)

-Editorials

5.1.1.3.
 -3rd sentence

5.1.1.4.
 -3rd sentence

5.2.1.1.

5.2.7.1.

5.2.7.2. and 5.2.7.3.

6.

7.

All the best,
Kenichi