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

<> Mon, 03 August 2015 14:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 48E861A1BB8 for <>; Mon, 3 Aug 2015 07:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g3rzRUg_V1CA for <>; Mon, 3 Aug 2015 07:54:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 138731A89F9 for <>; Mon, 3 Aug 2015 07:54:31 -0700 (PDT)
Received: from (unknown [xx.xx.xx.199]) by (ESMTP service) with ESMTP id 5D1851901D8; Mon, 3 Aug 2015 16:54:29 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 3C965C8085; Mon, 3 Aug 2015 16:54:29 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0248.002; Mon, 3 Aug 2015 16:54:28 +0200
To: Eric C Rosen <>, "" <>
Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model
Date: Mon, 03 Aug 2015 14:54:28 +0000
Message-ID: <12423_1438613669_55BF80A5_12423_1580_1_9E32478DFA9976438E7A22F69B08FF92166BD5DB@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <> <> <29351_1437643806_55B0B41E_29351_10618_1_9E32478DFA9976438E7A22F69B08FF92166A402F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <12269_1437986269_55B5EDDD_12269_740_1_9E32478DFA9976438E7A22F69B08FF92166A4D53@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166BD5DBOPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.7.16.85415
Archived-At: <>
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2015 14:54:44 -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 []
Sent: Tuesday, July 28, 2015 17:34
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

On 7/27/2015 4:37 AM,<> 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.