draft-ietf-l3vpn-gre-ip-2547-04.txt
Scott Wainner <swainner@cisco.com> Fri, 29 July 2005 19:18 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaNY-00055b-3a; Fri, 29 Jul 2005 15:18:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaNW-00052S-5q for l3vpn@megatron.ietf.org; Fri, 29 Jul 2005 15:18:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02261 for <l3vpn@ietf.org>; Fri, 29 Jul 2005 15:18:39 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyatE-000315-Vq for l3vpn@ietf.org; Fri, 29 Jul 2005 15:51:29 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2005 12:18:32 -0700
X-IronPort-AV: i="3.95,153,1120460400"; d="scan'208"; a="651910346:sNHT38043226"
Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6TJIQul022788 for <l3vpn@ietf.org>; Fri, 29 Jul 2005 12:18:26 -0700 (PDT)
Received: from cisco.com (dhcp-hrn-64-100-233-141.cisco.com [64.100.233.141]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA02798 for <l3vpn@ietf.org>; Fri, 29 Jul 2005 12:18:32 -0700 (PDT)
Message-ID: <42EA8107.1010104@cisco.com>
Date: Fri, 29 Jul 2005 15:18:31 -0400
From: Scott Wainner <swainner@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: l3vpn@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l3vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
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>
Sender: l3vpn-bounces@ietf.org
Errors-To: l3vpn-bounces@ietf.org
In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the following that requires some clarification: >4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE > > The following description is not meant to specify an implementation > strategy; any implementation procedure which produces the same result > is acceptable. > > When an ingress PE router receives a packet from a CE router, it > looks up the packet's destination IP address in a VRF that is > associated with packet's ingress attachment circuit. This enables > the (ingress) PE router to find a VPN-IP route. The VPN-IP route > will have an associated VPN route label and an associated BGP Next > Hop. The label is pushed on the packet. Then an IP (or IP+GRE) > encapsulation header is prepended to the packet, creating an > MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in- GRE implying that the egress MUST be able to perform both forms of decapsulation. If the egress PE can only perform one form of decapsulation, how does the ingress PE determine which form of encapsulation is preferred or required? The IP source > address field of the encapsulation header will be an address of the > ingress PE router itself. The IP destination address field of the > encapsulation header will contain the value of the associated BGP > Next Hop; this will be an IP address of the egress PE router. QoS > information can be copied from the VPN packet to the GRE/IP tunnel > header so that required forwarding behaviors can be maintained at > each hop along the forwarding path. > The effect is to dynamically create an IP (or GRE) tunnel between the > ingress and egress PE routers. Presumably, the ingress PE and/or egress PE are also capable of forwarding packets via label switched paths (either between themselves or to other PE's or ASBR's). In a mixed environment, its conceivable that two PE's could only communicate via GRE or IP while a third could use an LSP to the one or the other PE. What means does the ingress PE use to determine that the LSP should be used verses the GRE or IP encap? > No apriori configuration of the > remote tunnel endpoints is needed. Note that these tunnels SHOULD > NOT be IGP-visible links, and routing adjacencies SHOULD NOT be > supported across these tunnel. Note also that the set of remote > tunnel endpoints is not known in advance, but is learned dynamically > via the BGP distribution of VPN-IP routes. The IP address of the > remote tunnel endpoints is carried in the Network Address of the Next > Hop field of the MP_REACH_NLRI BGP attribute [4] This model assumes that the Network Address of the Next Hop field is the destination tunnel address. This may or may not be true. The provider may in fact want the externally accessible tunnel address to be distinct from the Next Hop address for a variety of reasons including security, transitive tunnels, etc. How does the egress PE indicate to the ingress PE that the tunnel should NOT be built to the Next Hop address, but to a designated tunnel address assigned on the egress PE? Likewise, how does an ASBR determine that traffic to prefixes to a peer ASBR should not be tunneled while prefixes to a peer PE should be tunneled. Seems that some form of signaling is required which is not defined in this draft. Scott Wainner Message: 1 Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) From: Rick Wilder <rick@rhwilder.net> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. To: l3vpn@ietf.org Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" L3VPN participants, This begins a two-week last call for comments on draft-ietf-l3vpn-gre-ip-2547-04.txt. Rick
- draft-ietf-l3vpn-gre-ip-2547-04.txt Scott Wainner
- Re: draft-ietf-l3vpn-gre-ip-2547-04.txt Robert Raszuk
- Re: draft-ietf-l3vpn-gre-ip-2547-04.txt Scott Wainner
- Re: draft-ietf-l3vpn-gre-ip-2547-04.txt Ron Bonica
- Re: draft-ietf-l3vpn-gre-ip-2547-04.txt Robert Raszuk
- Re: draft-ietf-l3vpn-gre-ip-2547-04.txt Scott Wainner
- Re: draft-ietf-l3vpn-gre-ip-2547-04.txt Ron Bonica