Subject: Re: [yang-doctors] YANG doctor comments on draft-ietf-l3sm-l3vpn-service-model-16

From: <[email-masked]>
Date: Thu, 6 Oct 2016 08:12:58 +0000

Hi Giles,

Some global comments :
I prefer to keep enabled leaf rather than using presence container. Using enabled leaf allows to disable the feature (BFD, FRR, or whatever) at anytime while keeping the configuration.
If we move to presence container, deactivation of such parameter will require to remove the associated configuration parameters.

For identities vs enum => I moved AF to enum, but I prefer to keep identities for others (more extensible).

>26) ipv4-lan-prefixes and ipv6-lan-prefixes should probably be leaf-lists and should probably have singular names.
I do not understand how I can use a leaf list , as I have multiple leaves inside.

For any-to-any role, I added a default any-to-any-role to the site-role, does it work for you ?

Brgds,

-----Original Message-----
From: Giles Heron (giheron) [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2016 01:34
To: [email-masked]
Cc: YANG Doctors
Subject: YANG doctor comments on draft-ietf-l3sm-l3vpn-service-model-16

Some comments from a YANG-doctor perspective

a couple of meta-issues first - these are perhaps things the YANG Doctors need to discuss amongst themselves.

1) I tend to the view that service models should be augments of the I2RS network and topology model rather than being standalone models. 

2) I wonder if the IETF should really be focussing on the interface between the “service component” and the “config component” in your draft.  at that layer we can look at e.g. route targets and route distinguishers so we can focus on IETF technologies, but still take a network and service-centric view rather than a device-centric one.    The true technology-neutral “service” layer is being worked on in e.g. MEF - certainly for L2 and I think for L3 also.   Sure, in the L3 case we could probably argue it’s more IETF’s expertise than MEF’s, but I think there’s still value in having both layers, and I think we do need to make sure IETF and MEF don’t tread on each others’ toes too much.

In terms of more specific comments on the model:

3) the address-families could possibly use an enum rather than identities (as hopefully v4 and v6 is all we’ll ever have!)

4) again if you think the site-vpn-flavors, transport constraints, management types, address allocation types, vpn-topologies, multicast tree types, multicast rp discovery types etc. are definitive lists you could use enums for them.

5) re the site-roles we only really need hub and spoke if we have any-to-any as a default.

6) for the cloud-access perhaps the if-feature should be at the cloud-accesses container level.  given the indentation I suspect you added the container later?

7) for the authorized/denied sites there might be a better way to do that (using a choice - so you have either one list or the other).

8) nat-enabled could maybe be a presence container with customer-nat-address as an optional leaf inside it (since the customer nat address only applies if nat is enabled)

9) again the multicast container inside the vpn-service-multicast could be a presence container indicating that multicast is enabled and then have other various containers as sub-containers within that.

10) tree-flavor could be a leaf-list (it only has one leaf in it).

11) again provider-managed could be a presence container instead of having an enabled leaf.  that also avoids the when statements for the other leaves.

12) bsr-candidate could be a leaf-list (only one leaf in the list).

13) you could use an empty presence container rather than a leaf for carrrierscarrier.

14) the customer location info feels like it may be at too high a level for a service model.

15) do you need two levels of container in the site-diversity grouping?

16) the groups container is used in both site-diversity and access-diversity.  So you could use a grouping for it.   In fact you could probably just have the group list and constraint list - there’s less need for an enclosing container for a list when the list is already embedded in a container.

17) it might be possible to pull in the flow matching definitions from another model - they seem fairly generic.

18) the fast-reroute stuff could again use a presence container.

19) site-security-authentication looks kind of empty.

20) site-security-encryption could again use a presence container instead of an enabled leaf.

21) I’m guessing the layer should be a mandatory leaf for encryption and have a default?

22) I’m guessing the mask for the static address case ought to be in the range 0..31 for IPv4 and 0..127 for IPv6 (as you can’t have a /32 with 2 addresses in it).

23) again for BFD you could use a presence container

24) the container "vpn-policy-list" should perhaps be called “vpn-policies”.

25) the list “entries” should probably be called “entry”.

26) ipv4-lan-prefixes and ipv6-lan-prefixes should probably be leaf-lists and should probably have singular names.

27) the site-role for a VPN site could be made optional if the default was any-to-any (so you’d only need a role for hubs and spokes).

28) shouldn’t the multicast traffic constraints have a leaf-list for the dst-site rather than just a leaf? (you’d most likely want the same constraint for multiple destinations).

29) vpn-svc should probably be called vpn-service for consistency with the enclosing container.

Giles

_________________________________________________________________________________________________________________________

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: "Giles Heron (giheron)" <[email-masked]>
Date: Fri, 7 Oct 2016 00:33:37 +0000

Thanks Stephane

> On 6 Oct 2016, at 01:12, [email-masked] wrote:
> 
> Hi Giles,
> 
> Some global comments :

yeah, I guess we can’t assume that NETCONF/YANG is the only means of config? (CLI users are bound to want the equivalent of “shutdown” rather than removing/re-adding the entire stanza).

> For identities vs enum => I moved AF to enum, but I prefer to keep identities for others (more extensible).

ok.  Like I say, it comes down to whether you see the need for future extensibility.

> I do not understand how I can use a leaf list , as I have multiple leaves inside.

I was looking at the lists in the site-vpn-policy grouping.  Those only have one leaf each. 

you could also simplify further by removing the lan-prefixes container so the filter either contains leaf-lists of prefixes or a leaf-list of LAN tags. 

you’d end up with something like:

  container filter {
    choice lan {
      case prefixes {
        leaf-list ipv4-lan-prefix {
          if-feature ipv4;
          type inet:ipv4-prefix;
          description
            “list of IPv4 prefixes to be matched.";
        }
        leaf-list ipv6-lan-prefix {
          if-feature ipv6;
          type inet:ipv6-prefix;
          description
            “list of IPv6 prefixes to be matched.";
          }
        description
          "LAN prefixes from the customer.";
      }
      case tags {
        leaf-list lan-tag {
          type string;
          description
            "List of lan-tags to be matched.”;
        }
      }
      description
        "Choice for LAN matching type";
    }
    description
      "If used, it permit to split site LANs
      among multiple VPNs.
      If no filter used, all the LANs will be
      part of the same VPNs with the same
      role.";
  }

> For any-to-any role, I added a default any-to-any-role to the site-role, does it work for you ?

sure.  I guess I was thinking more of just leaving the role out if it’s any-to-any, but making it default is probably ok.

Giles

---

From: <[email-masked]>
Date: Fri, 7 Oct 2016 07:11:42 +0000

Hi,

Ok we are in sync. I'm finishing to update the doc accordingly.

Brgds,

-----Original Message-----
From: Giles Heron (giheron) [mailto:[email-masked]] 
Sent: Friday, October 07, 2016 02:34
To: LITKOWSKI Stephane OBS/OINIS
Cc: [email-masked]; YANG Doctors
Subject: Re: YANG doctor comments on draft-ietf-l3sm-l3vpn-service-model-16

Thanks Stephane

  container filter {
    choice lan {
      case prefixes {

Giles

> 3) the address-families could possibly use an enum rather than 
> identities (as hopefully v4 and v6 is all we’ll ever have!)
> 
> 8) nat-enabled could maybe be a presence container with 
> customer-nat-address as an optional leaf inside it (since the customer 
> nat address only applies if nat is enabled)
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 7 Oct 2016 11:23:21 +0200

Hi,
>> On Sep 27, 2016:4:33 PM, at 4:33 PM, Giles Heron (giheron) <[email-masked]> wrote:
>>
> 	+1
This point was discussed in the WG. The mapping with a topology will 
happen in orchestrator/controller.
An operator is not asking his customer: "and which I2RS topology node-id 
shall I connect you to?
So I don't believe this service model should be augmenting the topology one.

Regards, Benoit

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Fri, 7 Oct 2016 23:19:09 +0000

On 7 Oct 2016, at 02:23, Benoit Claise (bclaise) <[email-masked]> wrote:
> This point was discussed in the WG. The mapping with a topology will happen in orchestrator/controller.
> An operator is not asking his customer: "and which I2RS topology node-id shall I connect you to?

The draft’s abstract starts with the sentence:

"  This document defines a YANG data model that can be used for
   communication between customers and network operators and to deliver
   a Layer 3 Provider Provisioned VPN service. “

if we’re just dealing with the first half of that sentence then all the stuff in the model re e.g. start time/end time and access constraints makes sense, and yes there’s no need to follow the I2RS topology model (though I’d still argue that it might still make sense - the node-ids can be derived from site names, router names etc. and the link-ids from the site network access data).

Once we get down to delivering the service we probably want a topology, and yes that will live in the layer between this model and the network (whatever we choose to call that layer - controller, orchestrator etc.)   That topology would model the network as instantiated from the SP PoV.

The model also states that it’s only applicable to RFC4364 VPNs.   I’m not sure the customer needs to know that their VPN is delivered using RFC4364 at the point they request it?  In general you’d expect a customer-facing model to be technology neutral and then to be decomposed into one or more technology specific resource-facing models - which can then be used to configure the network elements (conceptually via a standardised network element model - though in reality the elements may be provisioned using CLI or proprietary YANG models).

Giles

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 7 Oct 2016 18:01:27 -0700

> On Oct 7, 2016, at 4:19 PM, Giles Heron (giheron) <[email-masked]> wrote:
> 

I was having a similar discussion with folks in MEF where we are trying to define the service level model for EVC based services. The question of whether the service layer model (Legato interface in MEF speak, see diagram below) needs a topology model of its own, that is somehow different from a i2rs topology model came up. I can see some value in having a service level topology model that describes the topology in terms of a site rather than a particular node in the network. Similar to the comment Benoit makes above. 

> Once we get down to delivering the service we probably want a topology, and yes that will live in the layer between this model and the network (whatever we choose to call that layer - controller, o…

The ask should be that the service layer topology model maps the particular site request to a node in the network.

> The model also states that it’s only applicable to RFC4364 VPNs.   I’m not sure the customer needs to know that their VPN is delivered using RFC4364 at the point they request it?  In general you’d…

Agree. I can see that a EVC based service like E-LAN, E-Line or E-Tree would provide a xVPN service, albeit at layer 2. But does the customer really care to know if it is a L3 or a L2 that is fulfilling the request?

Mahesh Jethanandani
[email-masked]

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Sat, 8 Oct 2016 01:27:13 +0000

Hi Mahesh,

On 7 Oct 2016, at 18:01, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 7, 2016, at 4:19 PM, Giles Heron (giheron) <[email-masked]<mailto:[email-masked]>> wrote:

On 7 Oct 2016, at 02:23, Benoit Claise (bclaise) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
On Sep 27, 2016:4:33 PM, at 4:33 PM, Giles Heron (giheron) <[email-masked]<mailto:[email-masked]>> wrote:

Sure - but a site can be a “node” at that level of abstraction?  Funnily enough I was just looking at the MEF Legato model yesterday and wondering why on earth they had picked their own topology model (and was planning to see if that could be fixed somehow).   Note that the Presto model (at least the one in the ODL Unimgr project) does augment the I2RS topology model.

not sure what you mean here.  do you mean that the orchestrator should use the L3SM model to map the site request to an actual node for each site in the model?  If so then yes, I agree - but I still want to see this handled using the I2RS topology (ideally for both models, but certainly for the one inside the controller/orchestrator that has actual nodes in it).

well - they probably care in this instance as they’re ordering a L3VPN (with routing adjacencies to the SP etc.).  My question was more why they should care that the L3VPN was implemented using RFC4364 rather than (for example) a dedicated set of virtual routers running as x86 VMs.

Giles

<LSO Management Reference Architecture.png>

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

---

From: Benoit Claise <[email-masked]>
Date: Sat, 8 Oct 2016 12:09:11 +0200

On 10/8/2016 3:27 AM, Giles Heron (giheron) wrote:
>>>>>> On Sep 27, 2016:4:33 PM, at 4:33 PM, Giles Heron (giheron) 
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> a couple of meta-issues first - these are perhaps things the YANG 
>>>>>> Doctors need to discuss amongst themselves.
>>>>>> 1) I tend to the view that service models should be augments of 
>>>>>> the I2RS network and topology model rather than being standalone 
>>>>>> models.
>>>>> +1
>>> if we’re just dealing with the first half of that sentence then all 
>>> the stuff in the model re e.g. start time/end time and access 
>>> constraints makes sense, and yes there’s no need to follow the I2RS 
>>> topology model (though I’d still argue that it might still make 
>>> sense - the node-ids can be derived from site names, router names 
>>> etc. and the link-ids from the site network access data).
>>
>> I was having a similar discussion with folks in MEF where we are 
>> trying to define the service level model for EVC based services. The 
>> question of whether the service layer model (Legato interface in MEF 
>> speak, see diagram below) needs a topology model of its own, that is 
>> somehow different from a i2rs topology model came up. I can see some 
>> value in having a service level topology model that describes the 
>> topology in terms of a site rather than a particular node in the 
>> network. Similar to the comment Benoit makes above.
>
> Sure - but a site can be a “node” at that level of abstraction? 
>  Funnily enough I was just looking at the MEF Legato model yesterday 
> and wondering why on earth they had picked their own topology model 
> (and was planning to see if that could be fixed somehow).
Thanks.
> Note that the Presto model (at least the one in the ODL Unimgr 
> project) does augment the I2RS topology model.
>
>>>
>>> Once we get down to delivering the service we probably want a 
>>> topology, and yes that will live in the layer between this model and 
>>> the network (whatever we choose to call that layer - controller, 
>>> orchestrator etc.)   That topology would model the network as 
>>> instantiated from the SP PoV.
>>
>> The ask should be that the service layer topology model maps the 
>> particular site request to a node in the network.
>
> not sure what you mean here.  do you mean that the orchestrator should 
> use the L3SM model to map the site request to an actual node for each 
> site in the model?  If so then yes,
Yes.
> I agree - but I still want to see this handled using the I2RS topology 
> (ideally for both models, but certainly for the one inside the 
> controller/orchestrator that has actual nodes in it).
Obviously yes.
>
>>>
>>> The model also states that it’s only applicable to RFC4364 VPNs. 
>>>   I’m not sure the customer needs to know that their VPN is 
>>> delivered using RFC4364 at the point they request it?  In general 
>>> you’d expect a customer-facing model to be technology neutral and 
>>> then to be decomposed into one or more technology specific 
>>> resource-facing models - which can then be used to configure the 
>>> network elements (conceptually via a standardised network element 
>>> model - though in reality the elements may be provisioned using CLI 
>>> or proprietary YANG models).
>>
>> Agree. I can see that a EVC based service like E-LAN, E-Line or 
>> E-Tree would provide a xVPN service, albeit at layer 2. But does the 
>> customer really care to know if it is a L3 or a L2 that is fulfilling 
>> the request?
>
> well - they probably care in this instance as they’re ordering a L3VPN 
> (with routing adjacencies to the SP etc.).  My question was more why 
> they should care that the L3VPN was implemented using RFC4364 rather 
> than (for example) a dedicated set of virtual routers running as x86 VMs.
Would it solve the issue?
OLD:

    The document is limited
    to the BGP PE-based VPNs as described in [RFC4026 <https://tools.ietf.org/html/rfc4026>], [RFC4110 <https://tools.ietf.org/html/rfc4110>] and
    [RFC4364 <https://tools.ietf.org/html/rfc4364>].

NEW:

    The document is optimized for
    the BGP PE-based VPNs as described in [RFC4026 <https://tools.ietf.org/html/rfc4026>], [RFC4110 <https://tools.ietf.org/html/rfc4110>] and
    [RFC4364 <https://tools.ietf.org/html/rfc4364>].

OR
    The primary target is ...

Regards, Benoit
>> [email-masked] <mailto:[email-masked]>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 25 Oct 2016 09:46:53 +0200

Hi Giles,

version 18 has been posted today.
Would you mind checking that, from a semantic point of view, the changes 
between 16 and 18 are fine.
I checked from a compilation point of view, and this is alright 
(http://www.yangvalidator.org/), except a small warning related to the 
date (no big deal, could be fixed later on)
Note that this draft is on telechat this Thursday, so a quick read would 
be appreciated.

Regards, Benoit
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Tue, 25 Oct 2016 18:50:05 +0000

yes - looks ok to me.

G.

> On 25 Oct 2016, at 08:46, Benoit Claise (bclaise) <[email-masked]> wrote:
> 
> Hi Giles,
> 
> Would you mind checking that, from a semantic point of view, the changes between 16 and 18 are fine.
> I checked from a compilation point of view, and this is alright (http://www.yangvalidator.org/), except a small warning related to the date (no big deal, could be fixed later on)
> Note that this draft is on telechat this Thursday, so a quick read would be appreciated.
> 
> Regards, Benoit