Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt

Sorry but I needed a little bit of clarification to my comment #7. It should read as follows:

"
7. Section 3.3.2 - L3VPN
Section 3.2.1.1 *of RFC 4659* "BGP Speaker Requesting IPv6 Transport" does actually specifies a 128-bit BGP next-hop. No?
"

Regards,
Mustapha.
-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Sunday, March 02, 2014 12:21 PM
To: mpls@ietf.org
Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt

Dear all,
I read this document and I can say that it is useful for identifying gaps in MPLS related standards for interoperable deployment of IPv6 control plane and data plane in operators networks. It should be progressed as a working group document.

I compiled a list of comments below.

Regards,
Mustapha.
------------------------------
1. Section 2 - Use Case
A common use case I have seen is that of a wireless operator that moved its 4G/LTE subscribers into IPv6 but their management and backend infrastructure is still IPv4. In many of these networks, it is it is the management and OAM traffic which needs to be carried in a MPLS VPN in order to separate it from the subscriber traffic. The latter is IPv6 routed in most use cases I know of. As the number of devices (specifically cell site routers) to manage increases, the operator is compelled to move to IPv6.

2. Section 3 - Gap Analysis
The reference to RSVP-TE spec is no correct. I assume the authors meant RFC 3209.

3. Section 3.1 - MPLS Data Plane
In the case where an IPv4 prefix is resolved over an IPv6 LSP, there may be a need to push the IPv4 explicit null label value first before pushing the IPv6 label. The reason for this is if the egress LSR advertised the IPv6 explicit null label for the outer IPv6 LSP, it may drop the packet if it is not an IPv6 one.  

4. Section 3.2.1 - LDP
While reviewing draft-ietf-mpls-ldp-ipv6 on the MPLS WG mailing list, there were a couple of comments which were made by a number of operators and which I consider as gaps in LDP IPv6:
a. the need for extending LDP to use a 128-bit LSR-ID. The idea was to allow for using an IPv6 loopback to identify the LSR. In many cases, the LSR ID matches a routable address in the operator's network.
We wrote the following draft to address this (needs a refresh):
http://tools.ietf.org/html/draft-pdutta-mpls-ldp-v2-00
b. the need to support separate IPv6 and IPv4 LDP sessions when LSR peers over a dual-stack interface. We wrote the following draft to achieve this:
http://tools.ietf.org/html/draft-pdutta-mpls-multi-ldp-instance-00

5. Section 3.2.2 - Multipoint LDP
RFC 6388 provides a single session level LDP capability for mLDP P2MP and MP2MP FECs. There is no distinction between IPv4 and IPv6. We need to add a separate capability for IPv6 for each type.

6. Section 3.3.1 - L2VPN
We need to add a reference to RFC 6073 which defined the LDP SP-PE TLV and which already supports IPv4 and IPV6 addresses of the S-PE nodes.
We also need a reference to draft-ietf-pwe3-dynamic-ms-pw-20 for dynamic MS-PW. I checked it and it seems the discovery part which is consistent with RFC 4760 supports IPv6 PE address.

7. Section 3.3.2 - L3VPN
Section 3.2.1.1 "BGP Speaker Requesting IPv6 Transport" does actually specifies a 128-bit BGP next-hop. No?

8. Section 3.4.2 - LSP Ping
I do not understand the issue described in the case of LSP trace. Why would the ingress LSR send an IPv4 echo request message? The LSP is signaled with IPv6 control plane and its target FEC stack TLV is IPv6 (LDP, RSVP, or BGP LSP), the MPLS echo request and reply packets must be IPv6. 

9. Section 3.4.4 - PW OAM
I think the reference to RFC 6829 which defined the FEC 128 and FEC 129 target FEC Stack TLVs in a IPv6 environment should be added here instead of Section 3.4.2.
------------------------------------------------------------------------------------------

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls