Re: draft-rosen-l3vpn-mvpn-spmsi-joins-00.txt

Eric Rosen <erosen@cisco.com> Wed, 28 April 2010 13:41 UTC

Return-Path: <erosen@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F533A6AEA for <l3vpn@core3.amsl.com>; Wed, 28 Apr 2010 06:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.366
X-Spam-Level:
X-Spam-Status: No, score=-9.366 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOS0TWvRJaJd for <l3vpn@core3.amsl.com>; Wed, 28 Apr 2010 06:41:14 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 69BBE3A6BC3 for <l3vpn@ietf.org>; Wed, 28 Apr 2010 06:39:56 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,288,1270425600"; d="scan'208";a="106044814"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2010 13:39:43 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3SDdhRW028512; Wed, 28 Apr 2010 13:39:43 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id o3SDdg6E000758; Wed, 28 Apr 2010 09:39:42 -0400
To: Thomas Morin <thomas.morin@orange-ftgroup.com>
Subject: Re: draft-rosen-l3vpn-mvpn-spmsi-joins-00.txt
In-reply-to: Your message of Wed, 28 Apr 2010 10:13:23 +0200. <4BD7EE23.2000207@orange-ftgroup.com>
Date: Wed, 28 Apr 2010 09:39:42 -0400
Message-ID: <757.1272461982@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
Cc: erosen@cisco.com, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2010 13:41:15 -0000

> a control plane design tied too closely to a specific P-tunnel type was a
> bad idea.

Exactly.  That's why it doesn't make any sense to say that the use of S-PMSI
Joins should be tied to the use PIM/GRE tunnels.  

> even hypothetically extended to mLDP-based MPLS P-tunnels, would still
> have the drawback of being designed for leaf-initiated P-tunnels only.

I don't know why you say that, it's easily extended to RSVP-TE P-tunnels.     

> draft-ietf-l3vpn-mvpn-considerations is part of the IETF process.

It is not a standards track document, and therefore is not part of any IETF
standard.  You should not refer to it as part of a standard.  

Even so, I'm not suggesting that anyone should fail to implement the BGP A-D
mechanisms, just pointing out that an SP should be able to migrate its data
plane to MPLS independently of migrating its MVPN control plane to BGP.
This will happen no matter what the IETF says, the only question is whether
the formats and codepoints used to do it are archived as RFCs.

While it is true, as Yakov says, that the IETF is under no obligation to
standardize everything that service providers want, it's generally a good
thing to standardize things that are useful to SPs, and one would expect
MPLS-oriented WG like this one to help make it easy to migrate to MPLS
multicast!  But then I think that the value add of the IETF is the
production of public, reviewed, interoperable standard; it's not the IETF's
job to tell SPs what to deploy, or how to build their networks.

> You insist on the IPv6 promise made during IESG review. Let me note that
> the publication of draft-ietf-l3vpn-mvpn-considerations was *also* key
> to have draft-ietf-2547bis-mcast get through IESG.

I don't happen to believe that, but if we grant this point for the sake of
argument, I think it's fair to say that what interests the IESG here is the
creation of a  "mandatory to implement" status for some features, not a
"mandatory to not implement"!  I don't think the spmsi-joins draft will have
any trouble making it through IESG review.