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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
