Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

Gargi <gargi@cisco.com> Fri, 06 February 2004 22:29 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26262 for <l3vpn-archive@odin.ietf.org>; Fri, 6 Feb 2004 17:29:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApETD-0005Ln-0U for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 17:29:07 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MT6Ro020561 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 17:29:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApETC-0005LY-PT for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:29:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26205 for <l3vpn-web-archive@ietf.org>; Fri, 6 Feb 2004 17:29:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApETA-00005J-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:29:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApES8-0007mK-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:28:01 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApERD-0007iZ-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:27:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApERB-0005CW-Lq; Fri, 06 Feb 2004 17:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApERA-0005Bt-AP for l3vpn@optimus.ietf.org; Fri, 06 Feb 2004 17:27:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26120 for <l3vpn@ietf.org>; Fri, 6 Feb 2004 17:26:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApER7-0007hb-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 17:26:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEQB-0007eI-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 17:25:59 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApEPE-0007YY-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 17:25:00 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2004 14:31:09 +0000
Received: from cisco.com ([128.107.177.23]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i16MOS9T026959; Fri, 6 Feb 2004 14:24:28 -0800 (PST)
Message-ID: <4024141A.8060105@cisco.com>
Date: Fri, 06 Feb 2004 14:24:26 -0800
From: Gargi <gargi@cisco.com>
Reply-To: gargi@cisco.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Rekhter <yakov@juniper.net>
CC: "W. Mark Townsley" <townsley@cisco.com>, mpls@UU.NET, l3vpn@ietf.org
Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs
References: <200402061946.i16Jk3h27311@merlot.juniper.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.1.1.86173
Content-Transfer-Encoding: 7bit
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Yakov,

>>every participating 2547-PE for VPN traffic destined to that PE (much like a 
>>single IP address is distributed to every participating PE for VPN traffic 
>>destined to that PE).
> 
> 
> Are you saying that just because an application uses BGP, the application
> should use BGP, instead of l2tp for l2tp signaling ?
> 
> Or you saying that only when both (1) *and* (2) hold, then the application
> should use BGP, instead of l2tp for l2tp signaling ?

The l3vpn-l2tpv3 draft is no different from ppvpn-mpls-ip-gre-sig-00.txt
Both describe how the same information about L2TPv3/GRE tunnel endpoints
can be exchanged via BGP as one of the mechanisms. Neither draft
mandates the use of BGP. One could use static configuration, LDP/l2tp
signalling or BGP for the relevant tunnel endpoints to know this
information. The use of the mechanism is upto the respective operator
who chooses the machanism that suits their particular network.

Also, the information carried in BGP (when BGP is chosen as the
mechanism) is no different than the inner label that is exchanged
via BGP. The inner label may be per-prefix, per VRF or whatever
granularity depending on the implementation's choice and it is
exchanged via BGP. It identifies to the rcvg router of the data
packet how the packet is to be switched. In case of the tunnel
endpoints for l2tp or gre tunnels, the tunnel information sent
through BGP, also identifies to the receiver of the BGP update
(and sender of the data packet) how the packet is to be switched.
For the IP-VPN application, if there is no label-switching enabled
in the core, and the tunnel endpoint becomes unreachable from
the sender (of the data pkt) PE, the prefix loses reachability.
In that sense, this is reachability information.

Yes, the tunnel endpoint information - in case of generic l2tp &
gre tunnels, could be exchanged through different signalling
protocols. The application that justifies carrying the endpoint
information in BGP is that in case of some applications such as
IP-VPNs, this is indeed reachability information. And it is very
analogous to the IGP reachability which sometimes gets injected
into BGP.


>>>>extend this draft to cover other L3VPN models any more than 
>>>>draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt 
>>>>should. Shall I rename it to something with "2547" in the title to be 
>>>>more clear?

If it is ok to carry either of the above information in BGP, the
l3vpn-l2tp draft just specifies on emore such class of information
that could be exchanged via BGP. I see no difference.


> Based on the feedback received so far on the mailing list, I do
> plan to generalize draft-ietf-l3vpn-gre-ip-2547-00.txt.

Excellent! I would vote for generalizing it such that doesnt matter
whether  the information is gre, l2tp or ipsec related - it could use
the same BGP mechanism whenever BGP is the protocol to exchange any
part of the information.

Thanks,
Gargi