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

From: <[email-masked]>
Date: Mon, 3 Aug 2015 14:54:28 +0000

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]
Cc: [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.

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Aug 2015 10:37:25 +0000

Not from operators, my take on this is modularization approach is really important for service automation, service agility.
Based on the L3SM prototype demonstrated in Prague Bits-N-Bytes, modular approach enables faster service creation, modification, e.g., we can use site template to create site more quickly,
I am happy to see the new version of draft-ietf-l3sm-l3vpn-service-model get in line with this idea.
In addition, modularization approach can help us to develop other new service model more quickly by reusing common components defined in the existing service model.

-Qin
发件人: L3sm [mailto:[email-masked]] 代表 Scharf, Michael (Michael)
发送时间: 2015年7月23日 18:40
收件人: Rob Shakir; 'Kireeti Kompella'; [email-masked]; [email-masked]; [email-masked]
主题: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

On 23 July 2015 at 11:15:26, Scharf, Michael (Michael) ([email-masked]<mailto:[email-masked]>) wrote:
> > 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.

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.