Subject: Re: [v6ops] RTGWG last call draft-ietf-rtgwg-enterprise-pa-multihoming-03

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Apr 2018 13:49:22 +1200

Hi,

Generally I like this draft, but there are a couple of issues IMHO:

> 5.1.  Shim6
...>    We do not consider Shim6 to be a viable solution.  It suffers from
>    the fact that it requires widespread deployment of Shim6 on hosts all
>    over the Internet before the host at a PA multihomed site sees
>    significant benefit.  However, there appears to be no motivation for
>    the vast majority of hosts on the Internet (which are not at PA
>    multihomed sites) to deploy Shim6.  This may help explain why Shim6
>    has not been widely implemented.

I don't think the chicken-and-egg issue was the main problem with shim6.
IMHO there were three problems:
1) The fact that the Internet is not transparent to shim6 headers;
2) The fact that source-address based routing is not readily
available (sounds familiar?);
3) The rather surprising negative reaction to shim6 from many
ISPs, apparently because they viewed it as a loss of control.
Those three facts made the incremental deployment model infeasible.

But does it matter? I'd tend to delete the whole paragraph. The
only fact that matters is the lack of deployment.

> 5.2.  IPv6-to-IPv6 Network Prefix Translation
...
>    Until that occurs, NPTv6 should still
>    be considered a viable option to enable PA multihoming for
>    enterprises.

Most of this section is not about NPTv6; it's about deployment
challenges for your main proposal. That's fine and worth explaining.
However, the real issue is that advocating NPTv6 will delay progress
on this draft for something that really doesn't belong in the routing
area. In many peoples' opinion, this is not something the IETF
should say, and it's definitely contentious.

Much better, IMHO, to simply ignore NPTv6 in this draft, and
stick to your own knitting.

draft-ietf-v6ops-ula-usage-considerations should be the place to
discuss this issue, although it seems to be on hold.

Regards
   Brian

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Apr 2018 16:15:32 +1000

Brian,

Thanks a lot for reading such a long document and for your comments!

> ....>    We do not consider Shim6 to be a viable solution.  It suffers from

I believe the point here is a particular multihomed enterprise can not
use Shim6 as a solution because Shim6 has to be globally supported
first and it's not happening (as opposed to NAT-PT, for example: if a
given network really wants to use it, it could be enabled and used).
How about I remove the second part of the paragraph, starting from
'However, there appears to be no motivation.."?

> ....

So do you think the whole section 5 shall be removed? (the deployment
challenges could be discussed in the separate section)

-- 
SY, Jen Linkova aka Furry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Apr 2018 08:44:09 +1200

> 'However, there appears to be no motivation.."?

Sure. That avoids the discussion, which is an academic question anyway;
that fact that Shim6 failed to deploy is enough...

> challenges could be discussed in the separate section)

Personally, yes. You know the strength of feelings in the IETF on this
issue, which is why NPTv6 is Experimental anyway. So why start a flame
war when it's a side-issue for your draft anyway?

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Apr 2018 12:33:59 +0900

> war when it's a side-issue for your draft anyway?

Indeed. If you mention NPTv6 at all, I would just say it's not a solution
because it breaks end-to-end connectivity.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 12 Apr 2018 15:38:33 +1000

Brian, Lorenzo,

Thanks a lot for the feedback.
It's all makes sense, I'm going to post an updated version of the
draft before the end of the week to address your comments, stay tuned!

NPTv6 will be still mentioned - I believe the draft should explain why
it's not a good option. From my experience almost every discussion
about v6 multihoming starts with 'we can just do NPTv6, can't we?', so
it's a topic worth discussing.

Actually there is one more thing about address/prefix
translation....we are seeing more and more work to make
host/applications path-aware so they could make educated decisions
about available paths and choose between them. Selecting the source
address might be one of the possible mechanisms path-aware hosts use.
Taking multiple addresses (with different properties) from a host and
replacing them with ULAs takes some control away from hosts and might
be considered as a step backward.

On Fri, Apr 6, 2018 at 1:33 PM, Lorenzo Colitti <[email-masked]> wrote:
> On Fri, Apr 6, 2018 at 5:44 AM, Brian E Carpenter
> <[email-masked]> wrote:
>>

---

From: Jen Linkova <[email-masked]>
Date: Sat, 14 Apr 2018 17:42:07 +1000

The -05 version of the draft has been posted to address comments received.

https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-05

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Apr 2018 09:02:56 +1200

This version looks good to me.

Thanks
   Brian

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 14 Apr 2018 14:23:45 -0700

Thanks Brian!
We are going to proceed with the WGLC in the RTGWG.

Regards,
Jeff

> On Apr 14, 2018, at 14:02, Brian E Carpenter <[email-masked]> wrote:
>