Draft: draft-ooms-v6ops-bgp-tunnel-06.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Wednesday 8/16/2006 3:17 PM CST IETF LC Date: 8/23/2006 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.