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

[Brian E Carpenter <[e-mail]>]

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