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

From: Qin Wu <[email-masked]>
Date: Fri, 27 Nov 2015 07:25:50 +0000

Hi,Stephane:
The “provider-managed” is defined as a parameter for management
“
   o  comanaged : the CE router is managed by the provider and also by
      the customer.

   o  provider-managed : the CE router is managed only by the provider.

   o  customer-managed : the CE router is managed only by the customer.
”
It seems confusing to use provider-maanged for multicast, is there any relationship between provider-managed for management and provider-managed for multicast?
How provider-managed for multicast indicate RPA is located on PE?

-Qin
发件人: L3sm [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2015年8月3日 22:54
收件人: Eric C Rosen; [email-masked]
主题: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Hi Eric,

Here is a proposed change for the multicast part :

VPN config :
      |  +--rw multicast
      |     +--rw tree-flavor*   identityref
      |     +--rw rp
      |        +--rw rp-group-mapping* [rp-address group]
      |        |  +--rw rp-address          union
      |        |  +--rw provider-managed
      |        |  |  +--rw enabled?      boolean
      |        |  |  +--rw anycast-rp?   boolean
      |        |  +--rw group               union
      |        +--rw rp-discovery?       identityref

We can define a list of RP to group mapping. This is useful when :
·         Static RP is used and RP is managed by customer => provider-managed set to false
·         RP is managed by provider, if this case , we also need to know from customer if anycast RP is required. But I’m wondering if it is necessary or not, from a technical point of view yes, from an abstraction point of view, does the customer care if we use anycast RP or just RP redundancy through the discovery mechanism ? Maybe we can just rename anycast-RP to redundant-RP.
In case of provider-managed, I expect the OSS to place the RP in the provider network, maybe we need to add some constraint here also …
If the customer does anycast RP (customer managed RP), IMO, it should be transparent for the provider ?
·         Note that the proposal allows for some groups to be managed by provider and some others by customer.

Site config :
      |     +--rw multicast
      |        +--rw multicast-site-type?            enumeration
      |        +--rw multicast-transport-protocol
      |        |  +--rw ipv4?   boolean
      |        |  +--rw ipv6?   boolean
      |        +--rw protocol-type?

In the site config, I added the protocol-type, which refers to “host” “router” or “both”. “Host” means some hosts are connected to the provider network (so requires IGMP or MLD), “Router” means hosts are behind a customer router (so need of PIM), “both” means need to enable both IGMP/MLD and PIM.

Do you still see something broken with this approach ?

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

On 7/27/2015 4:37 AM, [email-masked]<mailto:[email-masked]> wrote:
> [SLI] in my mind, if the referenced IP address is an IP address
> 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.

_________________________________________________________________________________________________________________________

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.