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

[Eric C Rosen <[e-mail]>]

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?