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

[Jen Linkova <[e-mail]>]

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

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

-- 
SY, Jen Linkova aka Furry