MVPN with bidirectional P-tunnels
Eric Rosen <erosen@cisco.com> Mon, 28 March 2011 20:29 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 A7AE23A6A6B for <l3vpn@core3.amsl.com>; Mon, 28 Mar 2011 13:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 nPcYqHb+zThv for <l3vpn@core3.amsl.com>; Mon, 28 Mar 2011 13:29:51 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9E56A3A6A69 for <l3vpn@ietf.org>; Mon, 28 Mar 2011 13:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=3559; q=dns/txt; s=iport; t=1301344289; x=1302553889; h=to:subject:reply-to:mime-version:date:message-id:from; bh=CR3OPEXRbrPgtzn30pHFCR+f0SrNFIW4Tjz4P36ItUI=; b=dZ/fwVJIEgck1loxvqJlXE+1ShpSxnjhhNEE3m/jDPGKCgQ44rw42F+1 f/nHt0DNlq9Q/mkZV/OI1DzBsVB3rPmiVvZ1LJkR05wBi7MZqNuFRpIVV XP34llFMMmmCtGZkVL+gVbY2oDtgKIsuK20TubjUqZMM2evVdirAL/FdJ c=;
X-Files: None : None
X-IronPort-AV: E=Sophos;i="4.63,257,1299456000"; d="scan'208";a="419733780"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 28 Mar 2011 20:31:29 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2SKVSEe010844; Mon, 28 Mar 2011 20:31:29 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 p2SKVSiK014675; Mon, 28 Mar 2011 16:31:28 -0400
To: l3vpn@ietf.org
Subject: MVPN with bidirectional P-tunnels
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Date: Mon, 28 Mar 2011 16:31:28 -0400
Message-ID: <14674.1301344288@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
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: Mon, 28 Mar 2011 20:29:52 -0000
Given the following from the new charter:
The WG will continue to extend and enhance the Multicast over BGP/MPLS
VPN solution
Perhaps it is also a good time to ask the WG to adopt draft-rosen-l3vpn-
mvpn-bidir-03.txt.
Attached is a message from July, 2010 explaining the need for this document.
--- Begin Message ---I would like to call the WG's attention to draft-rosen-l3vpn-mvpn-bidir- 01.txt. This draft provides the specification for the use of bidirectional tunnels to instantiate I-PMSIs or S-PMSIs. The bidirectional tunnels can be created by using BIDIR-PIM (already standardized) or by using mLDP (already adopted by the MPLS WG). The use of bidirectional P-tunnels is discussed in draft-ietf-l3vpn-2547bis- mcast-10.txt in numerous places. In draft-ietf-l3vpn-2547bis-mcast-bgp-08, the means of using the PMSI Tunnel Attribute in BGP MCAST-VPN routes to identify bidirectional P-tunnels has already been standardized. Draft-ietf-l3vpn-2547bis-mcast-10.txt specifies a method of supporting customer BIDIR, known as "partitioned sets of PEs". This method is also recommended by draft-ietf-l3vpn-mvpn-considerations-06.txt. The use of MP2MP LSPs is one of two possible methods of implementing "partitioned sets of PEs", and is the only method of implementing this recommended method when upstream-assigned MPLS labels are not available. Given the above, the detailed specification of the use of bidirectional P-tunnels is an obvious "next step" for the WG to take on. Most of the material in this draft has been available for several years, and as of today I am not aware of any competing drafts. Note that in the -01 version of this draft, it is no longer always required for the root of an MP2MP LSP P-tunnel to be a PE router. This removes (I hope) one of the objections that was made in Anaheim during a brief discussion of this topic. I regret that I will not be in Maastricht to discuss this in person, but comments on the mailing list are welcome.--- End Message ---
- MVPN with bidirectional P-tunnels Eric Rosen