Re: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt

Dear Bowbakova,

This is good stuff. We need SADR on site routers.

draft-ietf-6man-multi-homed-host is listed in the references but not cited
in the text. Since it is all about effective use of RFC6724 rule 5.5, I would
expect it to carefully referenced in section 4.1. In fact, the behaviour
specified by draft-ietf-6man-multi-homed-host seems to be essential for
your mechanism to succeed. You almost say that in section 4.2.2 but again
without citing the draft.

Worse, section 4.2.4 says:

>    At the same time Router Advertisements provide a reliable mechanism
>    to influence source address selection process via PIO, RIO and
>    default router preferences.  As all those options have been
>    standardized by IETF and are supported by various operating systems,
>    no changes are required on hosts. 

That's not true. The changes described in draft-ietf-6man-multi-homed-host
*are* required. Also, routers must be capable of sending PIOs with both
L and A bits set to zero.

The same error occurs in section 4.6:

>    1.  no new (non-standard) functionality needs to be implemented on
>        hosts (except for [RFC4191] support);

Section 5.1, shim6. While not disputing your conclusion, I think this is
misleading:

>    We do not consider Shim6 to be a viable solution.  It suffers from
>    the fact that it requires widespread deployment of Shim6 on hosts...

It is a two-ended solution and we always knew that it could only be deployed
incrementally and opportunistically; that was the plan, not a defect. The real
defect is that the Internet is partly opaque to IPv6 extension headers, and
therefore even incremental deployment of shim6 is not viable. (The same goes
for HIP-based multihoming, which you don't mention.)

Finally, it's helpful in site multihoming proposals to indicate whether
they meet the goals in RFC 3582.

Regards
   Brian

On 07/07/2016 04:33, Fred Baker (fred) wrote:
> At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review.
> 
>> Begin forwarded message:
>>
>> From: <internet-drafts@ietf.org>
>> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
>> Date: July 5, 2016 at 5:58:25 PM PDT
>> To: Chris Bowers <cbowers@juniper.net>, Jen Linkova <furry@google.com>, "Fred Baker" <fred@cisco.com>, "J. Linkova" <furry@google.com>
>>
>>
>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
>> has been successfully submitted by Fred Baker and posted to the
>> IETF repository.
>>
>> Name:		draft-bowbakova-rtgwg-enterprise-pa-multihoming
>> Revision:	00
>> Title:		Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution
>> Document date:	2016-07-05
>> Group:		Individual Submission
>> Pages:		44
>> URL:            https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/
>> Htmlized:       https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00
>>
>>
>> Abstract:
>>  Connecting an enterprise site to multiple ISPs using provider-
>>  assigned addresses is difficult without the use of some form of
>>  Network Address Translation (NAT).  Much has been written on this
>>  topic over the last 10 to 15 years, but it still remains a problem
>>  without a clearly defined or widely implemented solution.  Any
>>  multihoming solution without NAT requires hosts at the site to have
>>  addresses from each ISP and to select the egress ISP by selecting a
>>  source address for outgoing packets.  It also requires routers at the
>>  site to take into account those source addresses when forwarding
>>  packets out towards the ISPs.
>>
>>  This document attempts to define a complete solution to this problem.
>>  It covers the behavior of routers to forward traffic taking into
>>  account source address, and it covers the behavior of host to select
>>  appropriate source addresses.  It also covers any possible role that
>>  routers might play in providing information to hosts to help them
>>  select appropriate source addresses.  In the process of exploring
>>  potential solutions, this documents also makes explicit requirements
>>  for how the solution would be expected to behave from the perspective
>>  of an enterprise site network administrator .
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 