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

From: [email-masked]
Date: Mon, 06 Jun 2016 07:17:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the L3VPN Service Model  of the IETF.

        Title           : YANG Data Model for L3VPN service delivery
        Authors         : Stephane Litkowski
                          Rob Shakir
                          Luis Tomotaki
                          Kenichi Ogaki
                          Kevin D'Souza
	Filename        : draft-ietf-l3sm-l3vpn-service-model-07.txt
	Pages           : 153
	Date            : 2016-06-06

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-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l3sm-l3vpn-service-model-07

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/

---

From: <[email-masked]>
Date: Mon, 6 Jun 2016 14:19:54 +0000

Hi L3SM,

Here is a new revision of the service model.
It contains a new way for modeling the site-network-access placement.
Also some fixes thanks to comment of the WG.
It contains also some first text on NNI modeling. I putted for the moment option B and option C out of scope, but this is still a point to be discussed. At least it describes what we think necessary to be modeled for those cases.

Feel free to comment it.

Best Regards,

Stephane

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 06, 2016 16:17
To: [email-masked]
Cc: [email-masked]
Subject: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Abstract:

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.

_______________________________________________
L3sm mailing list
[email-masked]
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.

---

From: David Ball <[email-masked]>
Date: Tue, 7 Jun 2016 18:09:38 +0100

Hi Stephane,

Thanks for posting the new version, here are a few additional comments:

  * I agree with Michael that config:false items should not appear in
    the templates - and more broadly, that templates are not an
    L3SM-specific concept.  I might be better to punt this to the netmod
    WG to create a generic templating mechanism for yang, rather than
    trying to solve it in L3SM.
  * Sn 5.1.1.4: you added a sentence saying "Hub and spoke disjoint can
    also be seen as two hub and spoke VPNs sharing with a common hub
    site." - actually it's the spokes that are common not the hub,
    right?  So it should say "... sharing a common set of spoke sites."
  * Sn 5.4.1: I think with your new diversity constraints, the SubVPN
    flavor is no longer needed, right?  You could model it as separate
    sites, with accesses in the same group and with a "same-bearer"
    constraint on that group, right?  So Sn 5.4.1.3 could be deleted,
    along with the site-vpn-flavor-sub identity in the model.
  * Sn 5.5.3: I think the intent here is that the constraint applies to
    *other* site-network-accesses in the targeted group.  If the
    site-network-access for which the constraint is set is also part of
    the target group, the constraint does not apply to itself (e.g. in
    the first example where all 5 site-network-accesses are in group 10,
    the site-network-access in SITE1 does not need to be pe-diverse with
    itself - that wouldn't make any sense).  So, I think the word
    "other" needs to be inserted in several places.
  * Sn 5.5.3: Need to describe what the behaviour is if conflicting
    constraints are configured.  The simplest example would be 2
    site-network accesses in the same group, where one has a
    "pe-diverse" constraint targeted at that group, and the other has a
    "same-pe" constraint targeted at that group.  To meet both
    constraints, the SP has to connect the site-network-accesses to the
    same PE and also to different PEs, which is clearly impossible.  Of
    course there are lots of more complex ways of creating conflicting
    requirements, so I think we need to say what happens in this case.
  * Sn 5.5.4.2: I can't parse the second paragraph  - I think it should
    say: "... 3 branch offices can be connected to the same PE but not
    on the same linecard."
  * Sn 5.5.4.2: Second bullet after the figure, should say "pop-diverse"
    not "pe-diverse".
  * Sn 5.7: Traffic Protection should be a per-site attribute - it makes
    no sense to enable protection on one network-access for a site and
    disable it on another; it needs to be either enabled on all
    network-accesses for a given site, or on none of them, i.e. at a
    service level it is a per-site attribute.
  * Sn 5.9: If the CE is provider-managed, why is a management address
    needed in the model?  How the provider connects to the device would
    be internal to the provider, right?
    (For co-managed I can see this could be needed, i.e. to tell the
    customer what address to use to connect to the device for
    configuration/monitoring)
  * Sn 5.10.2: You said before that the model can only manage P2P
    connections; but this figure (and the next one) show the PE
    connected to a LAN, not to a CE.  I am not sure how to interpret
    this?  Isn't this a case where the connection is multipoint, not P2P?
  * Sn 5.11.2.2: I don't understand what it means to say that the QoS
    profile will be implemented at the PE or CE side of the WAN link. 
    This is a service model, it should not specify how the SP implements
    their network.  It is still unclear to me whether the QoS profile is
    supposed to apply to traffic flowing from the SP to the customer or
    from the customer to the SP - please can you clarify this?
  * Sn 5.11.2.2: You've added text to the rate-limit bullet about
    whether to use svc-input-bandwidth or svc-output-bandwidth - same
    text also needs to be added to the bullet for guaranteed-bw-percent.
  * Sn 8: I don't think an identity is needed for non-diverse - with the
    new system, that can be achieved simply by not adding any constraints.

Thanks,

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Wed, 8 Jun 2016 09:44:54 +0000

Hi,

Pls find some comments/replies inline

Best Regards,

Stephane

From: David Ball [mailto:[email-masked]]
Sent: Tuesday, June 07, 2016 19:10
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane,

  *   I agree with Michael that config:false items should not appear in the templates - and more broadly, that templates are not an L3SM-specific concept.  I might be better to punt this to the netmod WG to create a generic templating mechanism for yang, rather than trying to solve it in L3SM.
[SLI] Yes, I agree that it would be the best approach. If everyone agree, we can remove the templates.
The config:false items come from the grouping I'm reusing, I need to explode the grouping in order to remove them or put the op-states out.

  *   Sn 5.1.1.4: you added a sentence saying "Hub and spoke disjoint can also be seen as two hub and spoke VPNs sharing with a common hub site." - actually it's the spokes that are common not the hub, right?  So it should say "... sharing a common set of spoke sites."
[SLI] Right ! thanks for the catch

  *   Sn 5.4.1: I think with your new diversity constraints, the SubVPN flavor is no longer needed, right?  You could model it as separate sites, with accesses in the same group and with a "same-bearer" constraint on that group, right?  So Sn 5.4.1.3 could be deleted, along with the site-vpn-flavor-sub identity in the model.
[SLI] From a constraint perspective yes, now from a service point of view, it is still interesting to keep the information of the VPN style the customer wants. Some SP may enforce some parameters based on this information.

  *   Sn 5.5.3: I think the intent here is that the constraint applies to other site-network-accesses in the targeted group.  If the site-network-access for which the constraint is set is also part of the target group, the constraint does not apply to itself (e.g. in the first example where all 5 site-network-accesses are in group 10, the site-network-access in SITE1 does not need to be pe-diverse with itself - that wouldn't make any sense).  So, I think the word "other" needs to be inserted in several places.
[SLI] As mentioned by the text the constraint is expressed as : "I want my current site-network-
   access to be <constraint-type> (e.g. pe-diverse, pop-diverse) from
   those <target> site-network-accesses."
This means that if the current configured site-network-access is part of group 10 and the constraint is targeting group 10, the current site is not taking into account as part as group 10 because it is not placed yet in the network.
I can change the text as follows :
"For a particular currently configured site-network-access , each constraint MUST be
   expressed against a targeted set of site-network-accesses, the currently configured site-network-access MUST never be taken into account in the targeted set  : e.g.  "I want my
   current site-network-access to be not be connected on the same PoP as
   the site-network-accesses (other than the current one) that are part of group 10".
"

  *   Sn 5.5.3: Need to describe what the behaviour is if conflicting constraints are configured.  The simplest example would be 2 site-network accesses in the same group, where one has a "pe-diverse" constraint targeted at that group, and the other has a "same-pe" constraint targeted at that group.  To meet both constraints, the SP has to connect the site-network-accesses to the same PE and also to different PEs, which is clearly impossible.  Of course there are lots of more complex ways of creating conflicting requirements, so I think we need to say what happens in this case.
[SLI] When conflicting rules are configured, no solution can be found, it is expected to return an error in such case. I 'm adding a new small section to talk about impossible placement :
"<t>
                                                Some impossible placement scenarios may be created through the proposed configuration framework. Impossible scenarios could be too restrictive constraints leading to impossible placement in the network or conflicting constraints that would also lead to impossible placement.
                                                An example of conflicting rules would be to ask a site-network-access#1 to be pe-diverse from a site-network-access#2 and to ask at the same time that site-network-access#2 to be on the same PE as site-network-access#1.
                                                When the management system cannot place the access, it SHOULD return an error message indicating that placement was not possible.
                                                </t>
"

  *   Sn 5.5.4.2: I can't parse the second paragraph  - I think it should say: "... 3 branch offices can be connected to the same PE but not on the same linecard."
[SLI] Implementing "linecard-diverse" does not mean that you want to be on the same PE. It means that the system MUST avoid to connect the sites on the same LC, the solution can be to use the same PE with another LC, or another PE also.

  *   Sn 5.5.4.2: Second bullet after the figure, should say "pop-diverse" not "pe-diverse".
[SLI] Right

  *   Sn 5.7: Traffic Protection should be a per-site attribute - it makes no sense to enable protection on one network-access for a site and disable it on another; it needs to be either enabled on all network-accesses for a given site, or on none of them, i.e. at a service level it is a per-site attribute.
[SLI] Agree

  *   Sn 5.9: If the CE is provider-managed, why is a management address needed in the model?  How the provider connects to the device would be internal to the provider, right?
(For co-managed I can see this could be needed, i.e. to tell the customer what address to use to connect to the device for configuration/monitoring)
[SLI] There is a mistake here. You must read "In case of "customer-managed" or "co-managed", the model proposes ..."

  *   Sn 5.10.2: You said before that the model can only manage P2P connections; but this figure (and the next one) show the PE connected to a LAN, not to a CE.  I am not sure how to interpret this?  Isn't this a case where the connection is multipoint, not P2P?
[SLI] That's still point to point. In 5.10.3, customer must order two site network accesses (point to point). Each site network network access may be connected to a switch at customer side (same one or not).

  *   Sn 5.11.2.2: I don't understand what it means to say that the QoS profile will be implemented at the PE or CE side of the WAN link.  This is a service model, it should not specify how the SP implements their network.  It is still unclear to me whether the QoS profile is supposed to apply to traffic flowing from the SP to the customer or from the customer to the SP - please can you clarify this?
[SLI] Agree, that just a hint on what can be done. I will rephrase it to highlight this is just an example. Qos-profile is a scheduling policy, it will affect both traffic sides in case of provider managed and SP to customer only in case of customer managed.

  *   Sn 5.11.2.2: You've added text to the rate-limit bullet about whether to use svc-input-bandwidth or svc-output-bandwidth - same text also needs to be added to the bullet for guaranteed-bw-percent.
[SLI] Ok

  *   Sn 8: I don't think an identity is needed for non-diverse - with the new system, that can be achieved simply by not adding any constraints.
[SLI] I thought I already removed it, it's done now

Thanks,

    David

On 06/06/2016 15:19, [email-masked]<mailto:[email-masked]> wrote:

Hi L3SM,

Feel free to comment it.

Best Regards,

Stephane

-----Original Message-----

From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

                          Rob Shakir

                          Luis Tomotaki

                          Kenichi Ogaki

                          Kevin D'Souza

  Pages           : 153

  Date            : 2016-06-06

Abstract:

L3sm mailing list

[email-masked]<mailto:[email-masked]>

Thank you.

L3sm mailing list

[email-masked]<mailto:[email-masked]>

--

David Ball

<[email-masked]><mailto:[email-masked]>

---

From: Lucy yong <[email-masked]>
Date: Wed, 8 Jun 2016 15:54:44 +0000

Hi Stephane,

I read this version and have some comments.

*         Sn 5 states "A site is composed of at least one site-network-access ...". In data model, site has a site-network-access container and a routing-protocols container; site-network-access also has a routing-protocols container. Why is the routing-protocols container needed at both? If the routing-protocols under site means to apply to all its site-network-accesses, suggest to state that explicitly clear under Sn 5.2 and usage role.

*         Sn 5.14 defining NNIs. It is worth to mention how that relates or applies to interwork with a cloud provider. Sn 5.14.2 touches a bit in example 1. I don't think that we need to care of a site within cloud provider, but need to describe L3VPN provider and cloud provider interworking since L3SM supports cloud access.

*         A dummy question, which tool is used to convert the structure of YANG Module in Sn 5 to the YANG Module in Sn 8?

BRs/Thanks,

Lucy

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 06, 2016 9:20 AM
To: [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi L3SM,

Feel free to comment it.

Best Regards,

Stephane

-----Original Message-----

                          Rob Shakir

                          Luis Tomotaki

                          Kenichi Ogaki

                          Kevin D'Souza

      Pages           : 153

      Date            : 2016-06-06

Abstract:

L3sm mailing list

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.

Thank you.

L3sm mailing list

---

From: <[email-masked]>
Date: Thu, 9 Jun 2016 07:06:20 +0000

Hi Lucy,

Pls find some comments inline

Thanks,

Stephane

From: Lucy yong [mailto:[email-masked]]
Sent: Wednesday, June 08, 2016 17:55
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane,

[SLI] Adding routing-protocols under site-network-access (as other parameters) was requested some time ago by the WG. Configuring at site level will provide a kind of inheritance for all site-network-accesses. I will add a statement for this.

*         Sn 5.14 defining NNIs. It is worth to mention how that relates or applies to interwork with a cloud provider. Sn 5.14.2 touches a bit in example 1. I don't think that we need to care of a site within cloud provider, but need to describe L3VPN provider and cloud provider interworking since L3SM supports cloud access.[SLI] Yes for sure, Cloud is part of NNI. I will fix the text to better highlight it.

*         A dummy question, which tool is used to convert the structure of YANG Module in Sn 5 to the YANG Module in Sn 8?
[SLI] "pyang" does the job. There is an option command to convert yang module to tree.

BRs/Thanks,

Lucy

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, June 06, 2016 9:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi L3SM,

Feel free to comment it.

Best Regards,

Stephane

-----Original Message-----

                          Rob Shakir

                          Luis Tomotaki

                          Kenichi Ogaki

                          Kevin D'Souza

      Pages           : 153

      Date            : 2016-06-06

Abstract:

L3sm mailing list

Thank you.

L3sm mailing list

---

From: David Ball <[email-masked]>
Date: Thu, 9 Jun 2016 10:59:34 +0100

Thanks Stephane.

See inline - I have cut out the points where we're agreed.

On 08/06/2016 10:44, [email-masked] wrote:
> [SLI] From a constraint perspective yes, now from a service point of 
> view, it is still interesting to keep the information of the VPN style 
> the customer wants. Some SP may enforce some parameters based on this 
> information.
>

[DB] Ok - I think in this case it would be useful to say that sub-VPN is 
the same as having 2 sites with a "same-bearer" constraint.

>   * Sn 5.5.4.2: I can't parse the second paragraph  - I think it
>     should say: "... 3 branch offices can be connected to the same PE
>     but not on the same linecard."
>
> [SLI] Implementing “linecard-diverse” does not mean that you want to 
> be on the same PE. It means that the system MUST avoid to connect the 
> sites on the same LC, the solution can be to use the same PE with 
> another LC, or another PE also.
>

[DB] Agreed - my comment was more about the grammar. :)

>     needed in the model?  How the provider connects to the device
>     would be internal to the provider, right?
> [SLI] There is a mistake here. You must read “In case of 
> “customer-managed” or “co-managed”, the model proposes …”
>

[DB] I don't understand what this is for in the customer-managed case 
either.  If it is customer-managed, the customer already knows the 
management address, and the SP doesn't need to know it.  I think it's 
only needed for co-managed, right?

> [SLI] That’s still point to point. In 5.10.3, customer must order two 
> site network accesses (point to point). Each site network network 
> access may be connected to a switch at customer side (same one or not).
>

[DB] If there is an L2 switch, then at L3 it is a multipoint connection 
- the switch is part of the bearer.

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Thu, 9 Jun 2016 19:08:44 +0000

Hi,

More inline

Thanks

From: David Ball [mailto:[email-masked]]
Sent: Thursday, June 09, 2016 12:00
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Thanks Stephane.

See inline - I have cut out the points where we're agreed.
On 08/06/2016 10:44, [email-masked]<mailto:[email-masked]> wrote:

[DB] Ok - I think in this case it would be useful to say that sub-VPN is the same as having 2 sites with a "same-bearer" constraint.

[SLI] Ok, will add it

[DB] I don't understand what this is for in the customer-managed case either.  If it is customer-managed, the customer already knows the management address, and the SP doesn't need to know it.  I think it's only needed for co-managed, right?

[SLI] Yes, I agree, will update accordingly

[DB] If there is an L2 switch, then at L3 it is a multipoint connection - the switch is part of the bearer.
[SLI] From a SP  point of view no, in term of service, the customer will have to order two site-network-accesses. How they are connected to the customer network is not under the SP responsibility. If the customer connects the two site-net-access on the same Lan through a switch, it becomes multipoint, but SP is not essentially aware of it.

    David

--

David Ball

---

From: David Ball <[email-masked]>
Date: Fri, 10 Jun 2016 12:29:23 +0100

Hi Stephane,

More inline:

On 09/06/2016 20:08, [email-masked] wrote:
> [DB] If there is an L2 switch, then at L3 it is a multipoint 
> connection - the switch is part of the bearer.
> [SLI] From a SP  point of view no, in term of service, the customer 
> will have to order two site-network-accesses. How they are connected 
> to the customer network is not under the SP responsibility. If the 
> customer connects the two site-net-access on the same Lan through a 
> switch, it becomes multipoint, but SP is not essentially aware of it.
>

[DB] I think we may be talking about different cases.  I don't mean it 
may be multipoint because there are multiple site-network-accesses, I'm 
talking about the case where there are multiple devices at the customer 
side (could be one or multiple site-network-accesses) - rather than a 
single CE terminating the L3 connection.  This seems to be what the 
figure in Sn 5.10.2 is showing.

   Host1 ------\
   Host2 ---- Switch ---------- PE
   Host3 ------/

I don't think it's entirely true in this case that the SP does not need 
to be aware of it - for instance, if the connection address is dynamic, 
the SP may need to allocate multiple addresses instead of just 1.  It 
also has some impact on other aspects of the model; for instance, the 
routing protocol probably needs to be direct or static (not an absolute 
requirement but probably true in practice), and BFD and IPSec probably 
need to be disabled (since these are inherently P2P).

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Wed, 15 Jun 2016 09:21:16 +0000

Hi David,

I see your point, as a mentioned, it is different from what I was thinking about.
So the question is : do we need to support this kind of architecture (is there a use case ?).
Regarding the two CEs/two PEs cases connected on the same LAN, I think it's interesting to keep it, it usually used to connect some service platforms. We may need to restrict options in this scenario (static address ...) , but I'm afraid that it may be hard to be exhaustive ... any idea ?

Thanks,

From: David Ball [mailto:[email-masked]]
Sent: Friday, June 10, 2016 13:29
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane,

More inline:
On 09/06/2016 20:08, [email-masked]<mailto:[email-masked]> wrote:

[DB] I think we may be talking about different cases.  I don't mean it may be multipoint because there are multiple site-network-accesses, I'm talking about the case where there are multiple devices at the customer side (could be one or multiple site-network-accesses) - rather than a single CE terminating the L3 connection.  This seems to be what the figure in Sn 5.10.2 is showing.

  Host1 ------\

I don't think it's entirely true in this case that the SP does not need to be aware of it - for instance, if the connection address is dynamic, the SP may need to allocate multiple addresses instead of just 1.  It also has some impact on other aspects of the model; for instance, the routing protocol probably needs to be direct or static (not an absolute requirement but probably true in practice), and BFD and IPSec probably need to be disabled (since these are inherently P2P).

    David

--

David Ball

---

From: David Ball <[email-masked]>
Date: Wed, 15 Jun 2016 13:04:51 +0100

Regarding the use case, I'll leave it to SPs such as yourself to answer. 
:)  But if there is no use case, then we should change those examples in 
the doc.

     David

On 15/06/2016 10:21, [email-masked] wrote:
> Regarding the two CEs/two PEs cases connected on the same LAN, I think 
> it’s interesting to keep it, it usually used to connect some service 
> platforms. We may need to restrict options in this scenario (static 
> address …) , but I’m afraid that it may be hard to be exhaustive … any 
> idea ?
>
> Thanks,
>
> *From:*David Ball [mailto:[email-masked]]
> *Sent:* Friday, June 10, 2016 13:29
> *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked]
> *Subject:* Re: [L3sm] I-D Action: 
> draft-ietf-l3sm-l3vpn-service-model-07.txt
>
> Hi Stephane,
>
> More inline:
>
> On 09/06/2016 20:08, [email-masked] 
> <mailto:[email-masked]> wrote:
>
>
>
>         connected to a LAN, not to a CE.  I am not sure how to
>         interpret this?  Isn't this a case where the connection is
>         multipoint, not P2P?
>
>     [SLI] That’s still point to point. In 5.10.3, customer must order
>     two site network accesses (point to point). Each site network
>     network access may be connected to a switch at customer side (same
>     one or not).
>
>
>     [SLI] From a SP  point of view no, in term of service, the
>     customer will have to order two site-network-accesses. How they
>     are connected to the customer network is not under the SP
>     responsibility. If the customer connects the two site-net-access
>     on the same Lan through a switch, it becomes multipoint, but SP is
>     not essentially aware of it.
>
>
> may be multipoint because there are multiple site-network-accesses, 
> I'm talking about the case where there are multiple devices at the 
> customer side (could be one or multiple site-network-accesses) - 
> rather than a single CE terminating the L3 connection.  This seems to 
> be what the figure in Sn 5.10.2 is showing.
>
>   Host1 ------\
> I don't think it's entirely true in this case that the SP does not 
> need to be aware of it - for instance, if the connection address is 
> dynamic, the SP may need to allocate multiple addresses instead of 
> just 1.  It also has some impact on other aspects of the model; for 
> instance, the routing protocol probably needs to be direct or static 
> (not an absolute requirement but probably true in practice), and BFD 
> and IPSec probably need to be disabled (since these are inherently P2P).
>
>
>     David
>
>
>
> -- 
> David Ball
> <[email-masked]> <mailto:[email-masked]>

-- 
David Ball
<[email-masked]>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 16 Jun 2016 12:48:41 +0900

Hi David, Stephane,

The use case definitely exists. Then, it's reasonable to keep the example.

We are providing this as an option of our commercial VPN service.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, June 15, 2016 9:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Regarding the use case, I'll leave it to SPs such as yourself to answer. :)  But if there is no use case, then we should change those examples in the doc.

    David

	Hi David,

	Regarding the two CEs/two PEs cases connected on the same LAN, I think it's interesting to keep it, it usually used to connect some service platforms. We may need to restrict options in this scenario (static address .) , but I'm afraid that it may be hard to be exhaustive . any idea ?

	Thanks,

	Hi Stephane,
	
	More inline:

	On 09/06/2016 20:08, <mailto:[email-masked]> [email-masked] wrote:

	
	  Host1 ------\

	    David

---

From: <[email-masked]>
Date: Thu, 16 Jun 2016 13:07:06 +0000

Hi Kenichi,

Do you think we need a special leaf to identify that a particular site-network-access is multipoint rather than p2p ?
Or don't we care ?

As David pointed, for some features, there may be an issue : security features, oam ...
For dynamic IP addressing we may need a additional leaf to precise the number of addresses to be allocated (currently as we assume p2p, it's only 1).
Any idea on how to address it globally ?

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Thursday, June 16, 2016 05:49
To: 'David Ball'; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi David, Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, June 15, 2016 9:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

    David

	Hi David,

	Thanks,

	Hi Stephane,
	
	More inline:

		

	
	  Host1 ------\

	    David

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 17 Jun 2016 11:49:13 +0900

Hi Stephane, David,

IMO, the current model is enough generic to cover the use case.

> and IPSec probably need to be disabled (since these are inherently P2P).

The encryption or oam isn't mandatory even in p2p case, then we can apply the current model without any restriction. Just not specify them.

The current address-allocation-type is provider-dhcp, static-address (and slaac). The provider-dhcp works for assigning multiple addresses. Am I missing something?
In the static-address case, we only have to specify PE side.

>5.2.1.2.1.  IP addressing
>
>   o  static-address : Addresses will be assigned manually on both
>      sides, this is applicable to both IPv4 and IPv6 addressing.

We may be able to change the above sentence to cover this use case like:
   o  static-address : Addresses will be assigned manually on both sides, or one side in the case of Direct LAN connection, this is applicable to both IPv4 and IPv6 addressing.

For the static routing case, a customer may configure the following topology, but this can be also covered with cascaded-lan-prefixes.

	  Host1 ------\
LAN  ---- Router -----/

Here is the simplest one's example.
    <site-network-accesses>
        <site-network-access>
            <site-network-access-id>Spoke_Site1</site-network-access-id>
            <ip-connection>
                <ipv4>
                    <address-allocation-type>static-address</address-allocation-type>
                    <addresses>
                      <provider-address>203.0.113.254</provider-address>
                      <mask>24</mask>
                    </addresses>
                </ipv4>
            </ip-connection>
            <vpn-attachment>
                <vpn-id>12456487</vpn-id>
                <site-role>spoke-role</site-role>
            </vpn-attachment>
            <routing-protocols>
                <routing-protocol>
                    <type>direct</type>
                </routing-protocol>
            </routing-protocols>
        </site-network-access>
    </site-network-accesses>

Am I missing something more?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 16, 2016 10:07 PM
To: Ogaki, Kenichi; 'David Ball'; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Kenichi,

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Thursday, June 16, 2016 05:49
To: 'David Ball'; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi David, Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, June 15, 2016 9:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

    David

	Hi David,

	Thanks,

	Hi Stephane,
	
	More inline:

		

	
	  Host1 ------\

	    David

---

From: <[email-masked]>
Date: Fri, 17 Jun 2016 06:28:40 +0000

Hi Kenichi,

Some comment inline.

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Friday, June 17, 2016 04:49
To: LITKOWSKI Stephane OBS/OINIS; 'David Ball'; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane, David,

The encryption or oam isn't mandatory even in p2p case, then we can apply the current model without any restriction. Just not specify them.
[SLI] Yes it's optional, but the issue is that it may work on p2p but not on mp connections. So if customer requests it and if SP is not aware that it will be a mp connection, oam or encryption may not work.

The current address-allocation-type is provider-dhcp, static-address (and slaac). The provider-dhcp works for assigning multiple addresses. Am I missing something?
[SLI] Yes, but the SP may need to know how many addresses are needed (to implement correctly the DHCP pool)
In the static-address case, we only have to specify PE side.
[SLI] Static is not an issue

	  Host1 ------\

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 16, 2016 10:07 PM
To: Ogaki, Kenichi; 'David Ball'; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Kenichi,

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Thursday, June 16, 2016 05:49
To: 'David Ball'; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi David, Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, June 15, 2016 9:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

    David

	Hi David,

	Thanks,

	Hi Stephane,
	
	More inline:

		

	
	  Host1 ------\

	    David

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 17 Jun 2016 18:38:31 +0900

Hi Stephane,

See comments inline, please.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 17, 2016 3:29 PM
To: Ogaki, Kenichi; 'David Ball'; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Kenichi,

Some comment inline.

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, June 17, 2016 04:49
To: LITKOWSKI Stephane OBS/OINIS; 'David Ball'; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane, David,

[KO] We can restrict to avoid such impossible combinations by using when statement, but this can be also achieved outside of the model. Operator can just reject the impossible request and return the error. 
I think we don't need such a strict modeling without a strong requirement for now. 

[KO] It may be useful as an option. I'm asking my colleague if we need.

	  Host1 ------\

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 16, 2016 10:07 PM
To: Ogaki, Kenichi; 'David Ball'; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Kenichi,

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Thursday, June 16, 2016 05:49
To: 'David Ball'; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi David, Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, June 15, 2016 9:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

    David

	Hi David,

	Thanks,

	Hi Stephane,
	
	More inline:

		

	
	  Host1 ------\

	    David

---

From: <[email-masked]>
Date: Fri, 17 Jun 2016 12:51:12 +0000

More inline

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, June 17, 2016 04:49
To: LITKOWSKI Stephane OBS/OINIS; 'David Ball'; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane, David,

[SLI2] How can we do such restriction if we do not have the information about the access-type (p2p or mp) ? Operator can reject the config as he does not know how the access will be used.
If we want the operator to check this out of the model, the customer needs to provide the info that it is a multipoint access and a new leaf per site-network-access may help here.

[SLI] Ok,we can add a leaf for ipv4 and ipv6 ip-connection like :

Leaf number-of-dynamic-addresses {
	When "../address-allocation-type = pe-dhcp";
	Type uint8;
}

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Sat, 18 Jun 2016 16:36:46 +0900

Hi Stephane,

Isn't enough wheter the customer-address is provided or not?

Whether p2p or mp access can't decide if ipsec/oam can be enabled or not.
If a customer provides his/her customer-address with ipsec or oam, their operator must appropriately configure ipsec or p2p oam *even in mp access*. On the other hand, he/she only provides the provider-address, the operator can't do so.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 17, 2016 9:51 PM
To: Ogaki, Kenichi; 'David Ball'; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

More inline

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, June 17, 2016 04:49
To: LITKOWSKI Stephane OBS/OINIS; 'David Ball'; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane, David,

---

From: <[email-masked]>
Date: Wed, 22 Jun 2016 09:26:24 +0000

Hi,

Using customer-address presence to deduce works but it's not very clear. Did the customer forgot it or is it done on purpose ? Would be better to be more explicit in what the customer wants.

Brgds,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Saturday, June 18, 2016 09:37
To: LITKOWSKI Stephane OBS/OINIS; 'David Ball'; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 17, 2016 9:51 PM
To: Ogaki, Kenichi; 'David Ball'; [email-masked]
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

More inline

Best Regards,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, June 17, 2016 04:49
To: LITKOWSKI Stephane OBS/OINIS; 'David Ball'; [email-masked]
Subject: RE: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-07.txt

Hi Stephane, David,