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

Hi Eric,

Pleas find some inline comments

Best Regards,

Stephane

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

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.
[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.

_______________________________________________
L3sm mailing list
L3sm@ietf.org
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.