[Gen-art] Gen-ART Last Call review of draft-ooms-v6ops-bgp-tunnel-06.txt

"Spencer Dawkins" <spencer@mcsr-labs.org> Wed, 16 August 2006 20:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRqg-0001RV-0b; Wed, 16 Aug 2006 16:18:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRqe-0001Or-Qg for gen-art@ietf.org; Wed, 16 Aug 2006 16:18:44 -0400
Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDRqd-0007XI-Fg for gen-art@ietf.org; Wed, 16 Aug 2006 16:18:44 -0400
Received: from s73602 (futurewei.com?[65.104.224.98]) by comcast.net (sccrmhc15) with SMTP id <2006081620183701500liebre>; Wed, 16 Aug 2006 20:18:38 +0000
Message-ID: <0bb901c6c170$f4204010$0600a8c0@china.huawei.com>
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: General Area Review Team <gen-art@ietf.org>
Date: Wed, 16 Aug 2006 15:16:59 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Cc: jeremy.de_clercq@alcatel.be, Susan Hares <skh@nexthop.com>, dirk@onesparrow.com, Bill Fenner <fenner@research.att.com>, Yakov Rekhter <yakov@juniper.net>, stuart.prevost@bt.com, flefauch@cisco.com
Subject: [Gen-art] Gen-ART Last Call review of draft-ooms-v6ops-bgp-tunnel-06.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Hi,I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ 
at<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Summary - this draft is almost ready for publication as a Proposed Standard. 
I do have two questions, both from Section 3, listed below.

Please look at these comments along with any other Last Call comments you 
may receive.

During my review, I noted some editorial questions/suggestions, flagged as 
"Spencer (Editorial)". They are not part of the technical review, but are 
included for editors who may be changing the text during publication.

Thanks,

Spencer Dawkins

1. Introduction

   This document specifies operations of the 6PE approach for
   interconnection of IPv6 islands over an IPv4 MPLS cloud. The approach
   requires the edge routers that are connected to IPv6 islands to be
   Dual Stack MP-BGP-speaking routers while the core routers are only
   required to run IPv4 MPLS. The approach uses MP-BGP over IPv4, relies

Spencer (Editorial): "MP-BGP" isn't quite common enough to avoid expanding 
on first use (I'm good for "BGP", just not "MP-BGP"). Is there an obvious 
reference that should be included here?

   on identification of the 6PE routers by their IPv4 address and uses
   IPv4-signaled MPLS LSPs that don't require any explicit tunnel
   configuration.

   The interconnection method described in this document typically
   applies to an ISP that has an IPv4 MPLS network and is familiar with

Spencer (Editorial): "ISP" should be expanded on first use.

   BGP (possibly already offering BGP/MPLS VPN services) and that wants
   to offer IPv6 services to some of its customers.  However, the ISP
   may not (yet) want to upgrade its network core to IPv6 nor use only
   IPv6-over-IPv4 tunnelling. With the 6PE approach described here, the
   provider only has to upgrade some Provider Edge (PE) routers to Dual
   Stack operations so they behave as 6PE routers (and route reflectors
   if those are used for exchange of IPv6 reachability among 6PE
   routers) while leaving the IPv4 MPLS core routers untouched. These
   6PE routers provide connectivity to IPv6 islands. They may also
   provide other services simultaneously (IPv4 connectivity, IPv4 L3VPN
   services, L2VPN services, etc.). Also with the 6PE approach, no
   tunnels need to be explicitly configured, and no IPv4 headers need to
   be inserted in front of the IPv6 packets.

Spencer (Editorial): I think I understand the final phrase, but "in front of 
the IPv6 packets between the customer and provider edge" might be clearer.

2. Protocol Overview

   Each IPv6 site is connected to at least one Provider Edge router that
   is located on the border of the IPv4 MPLS cloud.  We call such a
   router a 6PE router. The 6PE router MUST be dual stack IPv4 and IPv6.
   The 6PE router MUST be configurable with at least one IPv4 address on

Spencer (Editorial): "configured"?

   the IPv4 side and at least one IPv6 address on the IPv6 side.  The
   configured IPv4 address needs to be routable in the IPv4 cloud, and
   there needs to be a label bound via an IPv4 label distribution
   protocol to this IPv4 route.

   (1) Exchange IPv6 reachability information among 6PE routers with
   MP-BGP [MP-BGP-v6]:

      The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP
      sessions as per [MP-BGP-v6] running over IPv4. The MP-BGP AFI used

Spencer (Editorial): should expand "AFI" on first use. Same with "SAFI", 
later in the same paragraph.

      MUST be IPv6 (value 2). In doing so, the 6PE routers convey their
      IPv4 address as the BGP Next Hop for the advertised IPv6 prefixes.
      Since MP-BGP assumes that the BGP Next Hop is of the same address
      family as the NLRI, the IPv4 address needs to be embedded in an
      IPv6 format. The IPv4-mapped IPv6 address is defined in [V6ADDR]
      as an "address type used to represent the addresses of IPv4 nodes
      as IPv6 addresses" which precisely fits the above purpose.
      Therefore, the IPv4 address of the egress 6PE router MUST be
      encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field.
      In addition, the 6PE MUST bind a label to the IPv6 prefix as per
      [LABEL]. The SAFI used in MP-BGP MUST be the "label" SAFI (value
      4) as defined in [LABEL]. Rationale for this and label allocation
      policies are discussed in section 3.

3. Transport over IPv4-signaled LSPs and IPv6 label binding

   The IPv4-signaled LSPs can be established using any existing
   technique (LDP, RSVP-TE, ...).

Spencer: A tiny bit vague for me - at least "any existing technique for 
label setup"? Editorially, is there a reference that could be used to cover 
"any technique"?

   While this approach could conceptually operate in some situations
   using a single level of labels, there are significant advantages in
   using a second level of labels which are bound to IPv6 prefixes via
   MP-BGP advertisements in accordance with [LABEL].

Spencer: This paragraph seems looser than the text which follows two or 
three paragraphs down:

   This is why a second label is always used with the 6PE approach.

Spencer: "is always used" seems like an uncapitalized "MUST" to me - or are 
you saying "anyone who thinks about it will figure this out on their own"? 
I'd like to see something like "While this approach could theoretically 
operate using a single set of labels, in practice a second label is always 
used with the 6PE approach", at a minimum - if you tell me it's not a 
"MUST", because single-level labels would work in specific cases, I could 
live with that, but it seems misleading to treat it as a possibility.

4. Crossing Multiple IPv4 Autonomous Systems

   The considerations described for procedure (c) in section 10 of [VPN]
   with respect to possible use of multi-hop EBGP connections via
   route-reflectors in different ASes, as well as with respect to the
   use of a third label in case the  IPv4 /32 routes for the (6)PE

Spencer (Editorial): this is the first occurance of "(6)PE". Is this the 
same as "6PE"? Should be consistent, if these are the same concepts.

   routers are NOT made known to the P routers, apply equally to this
   approach for IPv6. 



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art