Subject: [mpls] I-D Action: draft-george-mpls-ipv6-only-gap-04.txt

From: [email-masked]
Date: Thu, 13 Feb 2014 14:38:47 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Gap Analysis for Operating IPv6-only MPLS Networks
        Authors         : Wesley George
                          Carlos Pignataro
	Filename        : draft-george-mpls-ipv6-only-gap-04.txt
	Pages           : 25
	Date            : 2014-02-13

Abstract:
   This document reviews the MPLS protocol suite in the context of IPv6
   and identifies gaps that must be addressed in order to allow MPLS-
   related protocols and applications to be used with IPv6-only
   networks.  This document is not intended to highlight a particular
   vendor's implementation (or lack thereof) in the context of IPv6-only
   MPLS functionality, but rather to focus on gaps in the standards
   defining the MPLS suite.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-george-mpls-ipv6-only-gap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-george-mpls-ipv6-only-gap-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Tinka <[email-masked]>
Date: Fri, 14 Feb 2014 13:20:44 +0200

Glad to see this work getting a lot more attention, as it is 
one concern of mine as an operator.

Just a few comments, for my own clarity:

	1. This document focuses on a single-stack IPv6
	   backbone, but for practical operations as well, I
	   think it might be necessary to look at dual -
	   stack scenarios as well, where a an operator
	   would like to transport both IPv4 and IPv6 over
	   an MPLS network, but natively for each protocol.
	   I concede that this may have to be done in
	   another document.

	2. Section 3.2.3.1 (IGP) speaks to OSPFv2. Not sure
	   why given OSPFv2 does not support IPv6.

	3. Curious why section 3.3.2.4.3 (PE-PE Multicast
	   Routing Protocol) out of scope for this gap
	   analysis.

	4. While work is still ongoing for Segment Routing,
	   perhaps it might be good to make a reference to
	   it like you did for EVPN.

Cheers,

Mark.

On Friday, February 14, 2014 12:38:47 AM internet-
[email-masked] wrote:
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories. This draft is a work item
> of the Multiprotocol Label Switching Working Group of
> the IETF.
> 
>         Title           : Gap Analysis for Operating
> IPv6-only MPLS Networks Authors         : Wesley George
>                           Carlos Pignataro
>    This document reviews the MPLS protocol suite in the
> context of IPv6 and identifies gaps that must be
> addressed in order to allow MPLS- related protocols and
> applications to be used with IPv6-only networks.  This
> document is not intended to highlight a particular
> vendor's implementation (or lack thereof) in the context
> of IPv6-only MPLS functionality, but rather to focus on
> gaps in the standards defining the MPLS suite.
> 
> 
> Please note that it may take a couple of minutes from the
> time of submission until the htmlized version and diff
> are available at tools.ietf.org.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Sun, 16 Feb 2014 23:31:58 +0700

Mark, Working Group,

The authors of this draft have told me that it is ready to be
made a working group document, the process involves a couple of
steps

- a MPLS-RT review, mail have been sent to reviewers
- IPR poll, expect that to be started within a few days
- the actual poll, that will start as soon as the mpls-rt review or
   the IPR poll is done

I suggest that the authors look at the comments from as part of
resolving the mpls-rt review comments

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Mark Tinka <[email-masked]>
Date: Mon, 17 Feb 2014 04:15:35 +0200

Thanks, Loa.

Mark.

On Sunday, February 16, 2014 06:31:58 PM Loa Andersson 
wrote:
> Mark, Working Group,
> 
> The authors of this draft have told me that it is ready
> to be made a working group document, the process
> involves a couple of steps
> 
> - the actual poll, that will start as soon as the mpls-rt
> review or the IPR poll is done
> 
> I suggest that the authors look at the comments from as
> part of resolving the mpls-rt review comments
> 
> /Loa
> 
> > Glad to see this work getting a lot more attention, as
> > it is one concern of mine as an operator.
> > 
> >> 	Filename        : draft-george-mpls-ipv6-only-
> > 
> > gap-04.txt
> > 
> >> 	Pages           : 25
> >> 	Date            : 2014-02-13
> >> 
> >> Abstract:
> >> addressed in order to allow MPLS- related protocols
> >> and applications to be used with IPv6-only networks. 
> >> This document is not intended to highlight a
> >> particular vendor's implementation (or lack thereof)
> >> in the context of IPv6-only MPLS functionality, but
> >> rather to focus on gaps in the standards defining the
> >> MPLS suite.
> >> 
> >> 
> >> https://datatracker.ietf.org/doc/draft-george-mpls-ipv
> >> 6-o nly-gap/
> >> 
> >> http://tools.ietf.org/html/draft-george-mpls-ipv6-only
> >> -ga p-04
> >> 
> >> http://www.ietf.org/rfcdiff?url2=draft-george-mpls-ipv
> >> 6-o nly-gap-04
> >> 
> >> 
> >> Please note that it may take a couple of minutes from
> >> the time of submission until the htmlized version and
> >> diff are available at tools.ietf.org.
> >> 
> >> Internet-Drafts are also available by anonymous FTP
> >> at: ftp://ftp.ietf.org/internet-drafts/
> >>

---

From: "George, Wes" <[email-masked]>
Date: Tue, 18 Feb 2014 15:59:31 -0500

Hi Mark - thanks for the comments. My responses inline below.

>> >       I concede that this may have to be done in
WG] My view is that there is generally no gap if someone wants to operate
this way, since IPv4 (and IPv4-only) works today, and IPv6-only/native is
dealt with in this draft. Dual stack native (vs encapsulating one
protocol) simply runs both in parallel, and the only differences I could
see would be to ensure that there are no dependencies between the address
families such as there is today, meaning that if you address the gaps for
IPv6-only operation, you’re covered. Do you have something specific in
mind that you think is missing from this gap analysis to cover this
dual-stack use case, or is it more a matter of simply mentioning it as a
possible mode of operation and that it’s a non-issue?

>> >       why given OSPFv2 does not support IPv6.
WG] It is establishing that a feature exists in IPv4 (via OSPFv2) that
needs to be supported in IPv6. The following sentence notes that the
equivalent functions for IPv6 have been added to OSPFv3. Open to
suggestions on how to make that clearer.

>> >       Routing Protocol) out of scope for this gap
WG] The wording could probably be improved to clarify, but speaking as
editor, and not author of that specific section I think the rationale is
as follows: PIM and BGP are both used outside of this application, so if
they have problems with IPv6-only operation, they need to be addressed
outside of MPLS, unless there are issues specific with their
implementation as an MPLs PE-CE or PE-PE protocol that we haven’t
discussed. The contributor for that section will have to chime in if I’m
misrepresenting.

>> >       it like you did for EVPN.
WG] We’re skirting a fine line between noting a few big things in progress
that need to consider this gap analysis due to likely having impacts, and
having the draft collapse under its own weight/never be complete due to
needing an exhaustive list of all of the things that are in progress in
MPLS and related WGs. Part of me thinks it might be better to remove the
EVPN section and/or replace it with a more generic statement about things
in progress being out of scope and responsible for their own evaluation of
IPv6-only MPLS operation. Open to suggestions from the WG.

Thanks again!

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Mark Tinka <[email-masked]>
Date: Wed, 19 Feb 2014 11:16:36 +0200

On Tuesday, February 18, 2014 10:59:31 PM George, Wes wrote:

> WG] My view is that there is generally no gap if someone
> wants to operate this way, since IPv4 (and IPv4-only)
> works today, and IPv6-only/native is dealt with in this
> draft. Dual stack native (vs encapsulating one protocol)
> simply runs both in parallel, and the only differences I
> could see would be to ensure that there are no
> dependencies between the address families such as there
> is today, meaning that if you address the gaps for
> IPv6-only operation, you’re covered. Do you have
> something specific in mind that you think is missing
> from this gap analysis to cover this dual-stack use
> case, or is it more a matter of simply mentioning it as
> a possible mode of operation and that it’s a non-issue?

Perhaps the latter.

I just wonder whether implementations might find themselves 
in conflict for how to data plane IP-in-MPLS encapsulations 
depending on:

	- What type of traffic it is (IPv4, IPv6, Ethernet,
	  e.t.c.).

	- Whether the destination is an IPv4 or IPv6
	  destination.

	- What control plane signaled the IPv4 or IPv6 LSP,
	  and whether there is any congruency between the
	  signaled LSP and underlying carriage.

I expect this might be easy for implementors to resolve if 
the incoming traffic is IP, e.g., if incoming traffic is 
IPv4, use MPLSv4; and if incoming traffic IPv6, use MPLSv6 
(where MPLSv4|v6 has congruency between the control and data 
plane).

However, if inbound traffic is IP-protocol agnostic, e.g., 
Ethernet, PPP, e.t.c., how does the router determine whether 
to place that traffic on MPLSv4 or MPLSv6 (without 
considering potentially complex options like looking into 
the Ethernet frame to determine the Layer 3 payload)?

Again, not sure whether this draft should cover this, but 
given successful operator deployments of MPLSv6 (both 
control and data planes) are very likely to live in dual-
stack environments initially (especially with very little 
MPLSv6 experience), it might be good to think about the 
concerns mentioned above. What I'm not sure about is if this 
"thinking" is best done here, or somewhere else.

> WG] It is establishing that a feature exists in IPv4 (via
> OSPFv2) that needs to be supported in IPv6. The
> following sentence notes that the equivalent functions
> for IPv6 have been added to OSPFv3. Open to suggestions
> on how to make that clearer.

Okay, understand.

I can think of ways to make it clearer, but since assertions 
to both OSPFv2 and OSPFv3 are reasonably generic in the 
context of Traffic Engineering extensions, I'm happy to 
leave it this way without delving too much into how those 
extensions aid MPLS operations.

On a side note, it would be interesting to find out whether 
there has been any thought toward RFC 5838 implementations 
for operational deployment of IPv4 address families over 
OSPFv3, and how they are affected by MPLS-TE for IPv4 across 
this scenario. But I digress...

> WG] The wording could probably be improved to clarify,
> but speaking as editor, and not author of that specific
> section I think the rationale is as follows: PIM and BGP
> are both used outside of this application, so if they
> have problems with IPv6-only operation, they need to be
> addressed outside of MPLS, unless there are issues
> specific with their implementation as an MPLs PE-CE or
> PE-PE protocol that we haven’t discussed. The
> contributor for that section will have to chime in if
> I’m misrepresenting.

Well, looking at RFC 4659 and 6514, it would certainly be an 
implementation issue if BGPv6 was not supported as a PE-PE 
Multicast routing protocol, i.e., the RFC's appear to cover 
support for IPv6 reasonably well. I'll make some time to go 
over them with a finer comb just in case there are any gaps 
from a spec. perspective.

I can't speak to PIM as a PE-PE Multicast routing protocol 
in the context of MPLSv6. Perhaps someone else on this list 
is willing to go through that and report back...

In practice (and speaking to my first concern, above), it 
would be interesting to see how the network handles IPv4 and 
IPv6 Multicast traffic carried over an NG-MVPN architecture 
at the same time, with native MPLSv4 and MPLSv6 control and 
data planes.
 
> WG] We’re skirting a fine line between noting a few big
> things in progress that need to consider this gap
> analysis due to likely having impacts, and having the
> draft collapse under its own weight/never be complete
> due to needing an exhaustive list of all of the things
> that are in progress in MPLS and related WGs. Part of me
> thinks it might be better to remove the EVPN section
> and/or replace it with a more generic statement about
> things in progress being out of scope and responsible
> for their own evaluation of IPv6-only MPLS operation.
> Open to suggestions from the WG.

I would be in support of not listing ongoing work as well, 
in this particular case, as it may infer a responsibility 
(even if it shouldn't) to consider all other in-progress 
work that may or may not be looking at a gap analysis of 
MPLS services or features between IPv4 and IPv6 networks in 
their specific contexts.

As mentioned in this draft, ideal is that all independent 
work implements RFC 6540 as a best practice.

Cheers,

Mark.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 19 Feb 2014 13:29:50 +0000

Hi Mark,

<Nagendra> Thanks. I also think any gap raises as part of the same may not
be related to this document. BGP I sussed as overlay and the underlying
path (or the PMSI tunnel) can be GRE, IP or LSP. Any gap when LSP is used
as PMSI will be covered in section 3.3.2.4.2. Any gaps when GRE or IP is
used IMO is not within the scope of this document.

<Nagendra> When PIM is used as PE-PE protocol, it doesn't impose any need
or signal what would be the PMSI tunnel to be used. It is more like a
local matter and can be LSP or GRE. So any gaps can be covered as part of
the respective protocol and I think is not related to this document.

Thanks,

Nagendra

On 2/19/14 4:16 AM, "Mark Tinka" <[email-masked]> wrote:

>> IPv6-only operation, you¹re covered. Do you have
>> a possible mode of operation and that it¹s a non-issue?
>
>Perhaps the latter.
>
>> PE-PE protocol that we haven¹t discussed. The
>> I¹m misrepresenting.
>> WG] We¹re skirting a fine line between noting a few big

---

From: Mark Tinka <[email-masked]>
Date: Thu, 20 Feb 2014 04:03:13 +0200

On Wednesday, February 19, 2014 03:29:50 PM Nagendra Kumar 
Nainar (naikumar) wrote:

> <Nagendra> Thanks. I also think any gap raises as part of
> the same may not be related to this document. BGP I
> sussed as overlay and the underlying path (or the PMSI
> tunnel) can be GRE, IP or LSP. Any gap when LSP is used
> as PMSI will be covered in section 3.3.2.4.2. Any gaps
> when GRE or IP is used IMO is not within the scope of
> this document.

That's reasonable.

In NG-MVPN, BGP is used both for PIM functionality 
(Multicast routing) as well as signaling the PMSI tunnel 
type (PMSI Tunnel BGP attribute), but this is already part 
of today's implementations so there is no gap. 

And also, as you mention, BGP is an overlay. All it needs to 
do is signal the underlying carriage to the network (MPLS, 
IP or GRE).

Operationally, we just need to make sure that signaling of 
the PMSI tunnel type works fine for both MCAST-VPNv6 as it 
does for MCAST-VPNv4. Spec-wise, no reason it shouldn't.

> <Nagendra> When PIM is used as PE-PE protocol, it doesn't
> impose any need or signal what would be the PMSI tunnel
> to be used. It is more like a local matter and can be
> LSP or GRE. So any gaps can be covered as part of the
> respective protocol and I think is not related to this
> document.

Agree.

Mark.