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

Hi, Mustapha,

Thank you so much for your review, these comments, and the support.

Some follow-ups inline.

On Mar 2, 2014, at 5:21 PM, Aissaoui, Mustapha (Mustapha) <mustapha.aissaoui@alcatel-lucent.com> wrote:

> 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.
> 

Added.

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

Fixed.

> 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.  
> 

Added.

> 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

This one should be discussed in the context of draft-ietf-mpls-ldp-ipv6, this draft can follow.

I believe this was already discussed there. 

> 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
> 

This seems out of scope, because draft-george-mpls-ipv6-only-gap is for IPv6-only, not dual stack.

> 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.
> 

This seems covered by item #1 of S3.2.2.

> 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.
> 

Added.

> 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?
> 

I do not understand this comment -- There is no section 3.2.1.1, or that title you quote.

> 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. 
> 

In case the destination is IPv4.

> 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.

Good point, moved.

Thanks,

Carlos.

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