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

[Jen Linkova <[e-mail]>]

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


On Fri, Apr 6, 2018 at 6:44 AM, Brian E Carpenter
<[e-mail]> wrote:
> On 05/04/2018 18:15, Jen Linkova wrote:
>> Brian,
>>
>> Thanks a lot for reading such a long document and for your comments!
>>
>>> 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.
>>
>> 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.."?
>
> Sure. That avoids the discussion, which is an academic question anyway;
> that fact that Shim6 failed to deploy is enough...
>
>>>> 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.
>>
>> So do you think the whole section 5 shall be removed? (the deployment
>> 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
>



-- 
SY, Jen Linkova aka Furry