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

From: Kireeti Kompella <[email-masked]>
Date: Tue, 21 Jul 2015 17:00:10 +0200

Hi,

Very happy to see this WG, and to see the l3vpn _service_ YANG model.  Wish I’d been paying attention earlier :)

Some comments:

1) At a high level, I would like to see services as compositions (mash-ups) of service elements.  This is a generalization of the comments that Aijun made.  Here’s why.  As we (either the IETF or other bodies, or SPs on their own) define other services, it would be very convenient to be able to reuse these service elements.  Example: suppose an L2SM module is needed.

Elements to consider:
	availability
	QoS
	access-control-list
	OAM (liveness)
	customer-specific-info

I don’t know how one defines a mash-up of modules in YANG, maybe as simple as “import”.

(Note: this has nothing to do with service chaining!)

2) I think it would be convenient to have certain stanzas directly under vpn-svc, and again under vpn-svc/sites — essentially, a default for the entire service, and overrides for each site.

3) not sure why “bfd” is under “routing protocols”.  You may be better off having a stanza called OAM/Hello/liveness, where one can choose bfd among other mechanisms.

4) might be hard, but define defaults for as many YANG leaves as possible.

5) From comments on the mailing list, it seems OTT VPNs (customer-provisioned) are out of scope; however, doing such a model will help clarify common elements, and might help organize the L3VPN SM better.

6) Philosophical comment: should scrutinize service models to ensure we’re making them as abstract as possible.  E.g., I’m very happy that RDs and RTs are not in the SM.  Question: what else can be trimmed?

Finally, should YANG models (in general) have guidance as to where to place augments?  The theory is, you start with an SM (or data model in general) that everyone agrees on — lowest common denominator.  Then, as people augment a DM, if a certain augmentation appears in several such models, that might be promoted to being a part of the standard DM.  Or maybe I’m a dreamer :)

Kireeti.

---

From: <[email-masked]>
Date: Tue, 21 Jul 2015 15:23:47 +0000

Hi Kireeti,

Thanks for your valuable comments (as usual ;) ).

See inline comments

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Tuesday, July 21, 2015 17:00
To: [email-masked]
Cc: Kireeti Kompella
Subject: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Hi,

Some comments:

Elements to consider:
	availability
	QoS
	access-control-list
	OAM (liveness)
	customer-specific-info

[SLI] Modularization is a really good point, before going to start the work, I would like to ensure that all components are there so we can think the good way to split elements. For sure groupings can be created and being reused.

2) I think it would be convenient to have certain stanzas directly under vpn-svc, and again under vpn-svc/sites — essentially, a default for the entire service, and overrides for each site.
[SLI] Could you elaborate on which stanza you would like to see ?

3) not sure why “bfd” is under “routing protocols”.  You may be better off having a stanza called OAM/Hello/liveness, where one can choose bfd among other mechanisms.
[SLI] Some shortcuts have been taken (like vrrp as routing protocol :) ), this can be fixed.

4) might be hard, but define defaults for as many YANG leaves as possible.
[SLI] Not sure this would be doable, but I will have a look. Defaults may differ for each service providers ...

5) From comments on the mailing list, it seems OTT VPNs (customer-provisioned) are out of scope; however, doing such a model will help clarify common elements, and might help organize the L3VPN SM better.
[SLI] For now yes, but the idea is to see if we can make the model generic enough to fit also customer provisioned VPNs.

6) Philosophical comment: should scrutinize service models to ensure we’re making them as abstract as possible.  E.g., I’m very happy that RDs and RTs are not in the SM.  Question: what else can be trimmed?
[SLI] Multiple eyes are required for that purpose, we are continuously trying to trim and make more abstraction but any new idea is good to take. Idea list is becoming empty on our side ... so new eyes are welcome.

Kireeti.

_______________________________________________
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: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jul 2015 13:28:03 +0100

Hello Kireeti,

Welcome to the party.

> 1) At a high level, I would like to see services as compositions (mash-ups) of
> service elements.  This is a generalization of the comments that Aijun made.
> Here’s why.  As we (either the IETF or other bodies, or SPs on their own) define
> other services, it would be very convenient to be able to reuse these service
> elements.

I completely take your point, but...

When we started the L3SM work we were not certain (and some remain uncertain) that the problem could be addressed even for one of our most simple services (the L3VPN) let alone for a more generic concept of services. Therefore, the WG was explicitly tasked (read the charter) to work with focus and attention on L3VPN only and to exclude consideration of other services.

That, in itself, does not predicate against modularisation, but it does make it hard to consider which modules to have (since some aspects of modularisation must surely consider the other services that might use the modules).

Therefore, my expectation of progress is...

- Continue to progress L3SM towards completion
- Publish an RFC (if it can be agreed and done)
- Start work on another similar service model (e.g. L2SM)
   - If there is energy
   - If the IESG gives us permission
- Look for commonalities and modularisations
   - If they exist it may be necessary to revise L3SM

So, from some aspects this does not look optimal. Perhaps you could have made this comment during chartering. 
But from another perspective it enables some initial progress in a new subject space that the IETF has not previously attempted. If it is successful we can dig deeper.

Overall (setting aside the fact that we are anyway constrained by our charter) I have a fear of ocean-boiling. But some early, precautionary modularisation is not going to be a problem so long as we don't spend too long arguing about exactly what to modularise.

Adrian

---

From: <[email-masked]>
Date: Wed, 22 Jul 2015 12:39:46 +0000

> But some early, precautionary modularisation is not going to be a problem so long as we don't spend too long arguing about exactly what to modularise.

Fully agree ..., some sections Kireeti was mentioning are evident to be as a reusable component so we can do it now, for more complex things, let's think about it after the module is (almost) finished.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, July 22, 2015 14:28
To: 'Kireeti Kompella'; [email-masked]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Hello Kireeti,

Welcome to the party.

> 1) At a high level, I would like to see services as compositions 
> (mash-ups) of service elements.  This is a generalization of the comments that Aijun made.
> Here’s why.  As we (either the IETF or other bodies, or SPs on their 
> own) define other services, it would be very convenient to be able to 
> reuse these service elements.

Adrian

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jul 2015 14:52:54 +0200

Dear all,

+1 to Adrian's message.

My ocean-boiling concern has always been: in order to do the perfect job 
of modularity/grouping/augmentation, we should investigate all existing 
and potential future services. And the L2VPN are technology specific, so 
it's start to be difficult.

This is the reason why the charter is so strict and only focuses on L3VPN.

Obviously, we should follow Adrian's advice: "But some early, 
precautionary modularisation is not going to be a problem so long as we 
don't spend too long arguing about exactly what to modularise."

Regards, Benoit

---

From: Rob Shakir <[email-masked]>
Date: Wed, 22 Jul 2015 14:08:34 +0100

Folks,

+1 to Kireeti’s point that modularisation/mash-ups are the best way forward - we have common network designs for how e.g., an L3 edge interface works, which should not be duplicated between services. Indeed, where they are - this creates inefficiencies - such as having to change code and tooling surrounding multiple service models just to change one parameter of an interface (supporting an IP MTU of $current_value+1).

However, I can see the point that is being made by Adrian/Benoit. I might observe that this is a balance between standardisation (setting in RFC-stone), and building efficient ‘blocks’ of an overall architecture that are usable.

To me, I’m more interested in the latter, than the former. So - can we take an approach that says that we create an L3VPN service model - and stamp it as some final version (figuring out whether we can actually get to this step is interesting in and of itself) but not necessarily get out our chisels and start carving [0]? Subsequently, common elements can be pulled apart into modules that achieve the most efficient architecture.

The balance we have here is one that I think the IESG needs to approach - how do we both iterate on models (that are of course software), and get to things that can be considered ‘standards’ despite the fact that they may be refactored in the future.

Cheers,
r.

[0]: This might be done by, rather than not publishing, determining that the model’s status is really experimental, as we *know* as a WG that modularity would be very useful, if not essential, to have.

On 22 July 2015 at 13:53:04, Benoit Claise ([email-masked]) wrote:

Dear all,

+1 to Adrian's message.

Regards, Benoit

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 22 Jul 2015 15:06:44 -0400

On 7/21/2015 11:00 AM, Kireeti Kompella wrote:
> 6) Philosophical comment: should scrutinize service models to ensure
> we’re making them as abstract as possible.  E.g., I’m very happy that
> RDs and RTs are not in the SM.

It's certainly true that RDs and RTs are not part of the service, since 
they are not known to the customers.  But the draft does seem to presume 
that the SM, together with the provider's RT/RD allocation policies, can 
be used to automatically allocate RTs and RDs that are suitable for 
providing the necessary services.

I note that the SM does not restrict the RD allocation policy.  However, 
some RD allocation policies are incompatible with certain services.  For 
instance, a per-VPN allocation policy will severely constrain the type 
of load-balancing service that can be offered.  A per-VPN allocation 
policy (indeed, anything but a per-VRF allocation policy) is also 
incompatible with NG-MVPN.  Should this kind of interdependency be 
captured in the SM, or in another Yang model, or is it entirely outside 
the scope of the Yang models?

Some providers with multi-AS VPNs do RT-rewriting at the ASBRs.  This 
suggests that for a given VPN, the RT allocation policy in one AS can be 
different than the RT allocation policy in the other.  In order to 
correctly add a new site in a given AS, does the SM have to capture the 
fact that the RT allocation policy is per-AS?  If not, is there some 
Yang model in which this fact does need to be captured, or is it 
entirely outside the scope of the Yang models?

Changing the topic, I have a question about the multicast service model. 
  Some PE products allow the SP to offer a Rendezvous Point service to 
their MVPN customers.  Some allow the SP to offer IGMP/MLD service to 
their MVPN customers, others only allow the SP to offer a PIM peering 
service.  The SM doesn't seem to say anything about these alternatives 
at all, even though these alternatives are customer-visible.  Is that an 
intentional omission?

Changing the topic again, don't SPs often place limitations on the 
number of routes (or the rate of route change) per VRF for either 
unicast or multicast routes or both?  I didn't notice anything about 
that in the SM; is that something that the SM should capture?

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 22 Jul 2015 23:35:17 +0200

On Jul 22, 2015, at 21:06, Eric C Rosen <[email-masked]> wrote:

Agree that there should be hints about RD assignment policy (unless it's always per-VRF :)). 

I won't comment on RTs. 

> Changing the topic, I have a question about the multicast service model.  Some PE products allow the SP to offer a Rendezvous Point service to their MVPN customers.  

l3vpn/vpn-svc/multicast/rp allows specifying RP's IP address. 

> Some allow the SP to offer IGMP/MLD service to their MVPN customers, others only allow the SP to offer a PIM peering service.

Should these be added to
sites/attachment/connection/routing-protocols ?

> Changing the topic again, don't SPs often place limitations on the number of routes (or the rate of route change) per VRF for either unicast or multicast routes or both?  I didn't notice anything about that in the SM; is that something that the SM should capture?

sites/maximum-routes

Has an af -- so, should handle both unicast and multicast. No such variable VPN-wide, though. 

Rate of change not captured, afaict. 

Kireeti

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 23 Jul 2015 15:46:32 +0800

Hi, all:

The reason that we consider to design the L3SM in modular manner is that we should consider its relationship with the device model as early as possible:

1. Can we make use of the Yang Model that defined in other WGs as modules?

2. Or can we leave some spaces for future module definition?

3. The service model should be abstracted in a higher level and  hide the detail technology information into the modules at best. Is this the right way to define the service module from top to down?

4. If there is no more modules for us to refer now,  can we group the related stanza into different modules and make it as the base of the modular prototype?

Aijun Wang

China Telecom Corporation Limited Beijing Research Institute 

Intelligent Network Product Line

From: L3sm [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Wednesday, July 22, 2015 9:09 PM
To: 'Kireeti Kompella'; [email-masked]; Benoit Claise; [email-masked]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Folks,

Cheers,

r.

Dear all,

+1 to Adrian's message.

Regards, Benoit

---

From: <[email-masked]>
Date: Thu, 23 Jul 2015 09:30:05 +0000

Hi Eric,

Pleas find some inline comments

Best Regards,

Stephane

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Wednesday, July 22, 2015 21:07
To: Kireeti Kompella; [email-masked]
Cc: [email-masked]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

> RDs and RTs are not in the SM.

It's certainly true that RDs and RTs are not part of the service, since they are not known to the customers.  But the draft does seem to presume that the SM, together with the provider's RT/RD allocation policies, can be used to automatically allocate RTs and RDs that are suitable for providing the necessary services.
[SLI] Yes, this is the idea. 

I note that the SM does not restrict the RD allocation policy.  However, some RD allocation policies are incompatible with certain services.  For instance, a per-VPN allocation policy will severely constrain the type of load-balancing service that can be offered.  A per-VPN allocation policy (indeed, anything but a per-VRF allocation policy) is also incompatible with NG-MVPN.  Should this kind of interdependency be captured in the SM, or in another Yang model, or is it entirely outside the scope of the Yang models?
[SLI] I agree that RD allocation policy restrict some services. IMO, this is a provider network design issue rather than a service modeling. The model provides enough information (like loadsharing request or multicast request) to let service provider know that there may be something special to do regarding the RD allocation policy to make these services working. We suppose that these basic design rules are well known by SPs and we consider it as out of scope.

Some providers with multi-AS VPNs do RT-rewriting at the ASBRs.  This suggests that for a given VPN, the RT allocation policy in one AS can be different than the RT allocation policy in the other.  In order to correctly add a new site in a given AS, does the SM have to capture the fact that the RT allocation policy is per-AS?  If not, is there some Yang model in which this fact does need to be captured, or is it entirely outside the scope of the Yang models?
[SLI] InterAS case has not been addressed yet. Depending of the design, RT rewrite is needed or not, RT filtering may be applied or not ... we need to look at if there is something special to do here or not.

Changing the topic, I have a question about the multicast service model. 
  Some PE products allow the SP to offer a Rendezvous Point service to their MVPN customers.  
[SLI] Type of tree, rendez vous point type and IP address is available in the vpn-svc definition

Some allow the SP to offer IGMP/MLD service to their MVPN customers, others only allow the SP to offer a PIM peering service.  The SM doesn't seem to say anything about these alternatives at all, even though these alternatives are customer-visible.  Is that an intentional omission?
[SLI] This can be added to the routing protocol list. 

Changing the topic again, don't SPs often place limitations on the number of routes (or the rate of route change) per VRF for either unicast or multicast routes or both?  I didn't notice anything about that in the SM; is that something that the SM should capture?
[SLI] That's available in the model, using maximum-routes leaf.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 23 Jul 2015 10:15:22 +0000

> > But some early, precautionary modularisation is not going to be a
> problem so long as we don't spend too long arguing about exactly what
> to modularise.
>
> Fully agree ..., some sections Kireeti was mentioning are evident to be
> as a reusable component so we can do it now, for more complex things,
> let's think about it after the module is (almost) finished.

There is great value in having a consistent model without complex external dependencies, and we should aim at publishing that model soon. This significantly simplifies implementation.

Michael 

> When we started the L3SM work we were not certain (and some remain
> uncertain) that the problem could be addressed even for one of our most
> simple services (the L3VPN) let alone for a more generic concept of
> services. Therefore, the WG was explicitly tasked (read the charter) to
> work with focus and attention on L3VPN only and to exclude
> consideration of other services.
> 
> That, in itself, does not predicate against modularisation, but it does
> make it hard to consider which modules to have (since some aspects of
> modularisation must surely consider the other services that might use
> the modules).
> 
> So, from some aspects this does not look optimal. Perhaps you could
> have made this comment during chartering.
> But from another perspective it enables some initial progress in a new
> subject space that the IETF has not previously attempted. If it is
> successful we can dig deeper.
> 
> Overall (setting aside the fact that we are anyway constrained by our
> charter) I have a fear of ocean-boiling. But some early, precautionary
> modularisation is not going to be a problem so long as we don't spend
> too long arguing about exactly what to modularise.
> 
> Adrian
> 
> 
> 
> _______________________________________________________________________
> __________________________________________________
> 
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Rob Shakir <[email-masked]>
Date: Thu, 23 Jul 2015 11:19:29 +0100

There is great value in having a consistent model without complex external dependencies, and we should aim at publishing that model soon. This significantly simplifies implementation. 
Can you clarify which implementation you mean here, please? IMHO — there is a set of one off implementation effort to support the model in a network mgmt system - but there is the implementation of changes across a set of services offered by an operator. I expect that more changes happen within the operator’s services (new hardware, new constraints from suppliers or external network dependencies being removed, new customer requirements) than happen for the NMS needing to support different model features (from what I see today), hence, it’d be good to have a debate as to which implementations we want to simplify.

An approach that makes changes to services hard or costly to implement for operators will result in any models produced in the IETF being unusable, or not helping with the current complexities we have.

Best,

r.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 23 Jul 2015 10:39:54 +0000

Hi Rob,

My understanding is that the abstract L3SM model would be offered by a network management system software. Being in R&D, I mean the software “implementation” of the L3SM model.

I fully agree that deploying a corresponding NMS solution is not trivial, in particular if the network operator’s services change. But I don’t really understand why a more modular abstract service model in L3SM would simplify these challenges. But for these type of questions we would really appreciate input from network service providers.

Thanks

Michael

From: Rob Shakir [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 12:19 PM
To: 'Kireeti Kompella'; Scharf, Michael (Michael); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Best,

r.

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 23 Jul 2015 15:23:15 -0400

On 7/23/2015 5:30 AM, [email-masked] wrote:
> [ECR] Some PE products allow the SP to offer a Rendezvous Point
> service to their MVPN customers.

> available in the vpn-svc definition

If the SM specifies a particular RP address (say, an anycast-RP
address), how can you tell whether the RP service is being offered by
the PEs, or whether it is being offered by a system that is owned by the
customer?  Is that what the "anycast-RP-location" is for?

If static-rp is being used, doesn't the SM need to contain the complete
set of customer group-to-rp mappings?  (Presumably the customer provides 
this when the service is provisioned.)

---

From: <[email-masked]>
Date: Mon, 27 Jul 2015 08:37:48 +0000

Hi Eric,

More inline

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Thursday, July 23, 2015 21:23
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Cc: [email-masked]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

> in the vpn-svc definition

If the SM specifies a particular RP address (say, an anycast-RP address), how can you tell whether the RP service is being offered by the PEs, or whether it is being offered by a system that is owned by the customer?  Is that what the "anycast-RP-location" is for?
[SLI] in my mind, if the referenced IP address is an IP address located on a PE, then the RP is the PE. 
For "anycast-RP-location", the idea is to give a list of internal references to encode the location of the different RPs. It can be  PEs, or CEs ...

If static-rp is being used, doesn't the SM need to contain the complete set of customer group-to-rp mappings?  (Presumably the customer provides this when the service is provisioned.)
[SLI] Group to RP mapping is missing today, thanks for pointing it, will be added in the next verison.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 28 Jul 2015 11:34:12 -0400

> located on a PE, then the RP is the PE.

If the referenced address is any anycast address, how do you know 
whether it is "located on a PE" or not?  I'd have thought that the 
decision to assign the anycast address to the RP is based on whether or 
not you are offering the RP-as-PE service to the customer.

Similarly, if you are offering BIDIR-PIM support to a customer by using 
the technique of section 11.1 of RFC6513, I don't think it's enough just 
to specify the RPA in the service model; you have to have some 
information that determines whether or not the PE has to advertise to 
the CE a route to the RPA.

---

From: <[email-masked]>
Date: Fri, 31 Jul 2015 11:19:18 +0000

Agree, we will find a way to express it from an abstraction point of view. Do you have already something in mind ?

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2015 17:34
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Cc: [email-masked]
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

> located on a PE, then the RP is the PE.

If the referenced address is any anycast address, how do you know whether it is "located on a PE" or not?  I'd have thought that the decision to assign the anycast address to the RP is based on whether or not you are offering the RP-as-PE service to the customer.

Similarly, if you are offering BIDIR-PIM support to a customer by using the technique of section 11.1 of RFC6513, I don't think it's enough just to specify the RPA in the service model; you have to have some information that determines whether or not the PE has to advertise to the CE a route to the RPA.