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

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

Hi,

On 12/07/2016 10:10, Jen Linkova wrote:
>  Brian,
> 
> First of all - thanks for reviewing the draft and providing your feedback!
> 
> On Sat, Jul 9, 2016 at 3:01 PM, Brian E Carpenter
> <[e-mail]> wrote:
>> 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.
> 
> Ah, good catch, thanks - I'll add the reference.
> 
>> In fact, the behaviour
>> specified by draft-ietf-6man-multi-homed-host seems to be essential for
>> your mechanism to succeed.
> 
> You are right, most of them are required, I'll update the text, thanks
> for pointing this out. Looks like we've completely
> missed the scenario when hosts have addresses assigned by DHCPv6 (or
> manually) and receive RAs...
> 
> However I'm not sure about Section 3.2...
> draft-ietf-6man-multi-homed-host says:
> "Default Router Selection is modified as follows: A host SHOULD select
>    default routers for each prefix it is assigned an address in.".
> 
> I'm not sure it is actually required if routers implement the feature
> described in our draft and send one RA (with PIOs) per
> scoped table (as the whole idea of a SADR-capable router pretending to
> be two or more routers - one router per scoped table is
> to trick the host).

That may be. Fred should comment, but in the 6man draft we were
trying to cover as many cases as possible, while *hoping* that
SADR would become widespread.

> The host SHOULD add a router into its Default Router list upon
> receiving a valid RA with non-zero Router Lifetime, yes (as per
> RFC4191).
> Let's look at the situation when R3 (see Figure 3 at the page 11 of
> draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) sends two RAs: one
> from LLA_A for its forwarding table scoped to 2001:db8:0:a000::/56 and
> another one from LLA_B for its forwarding table scoped to
> 2001:db8:0:b000::/56.
> Even if the first RA has two PIOs (e.g. 2001:db8:0:a020::/64 and
> 2001:db8:0:a021::/64), the host does not need to select two default
> routers for 2001:db8:0:a020::/64 and 2001:db8:0:a021::/64 as it would
> not add any functionality (both prefixes will match the same scoped
> table on SADR-capable routers). Basically,  if packets with source
> addresses from two prefixes are going to be routed differently, then
> those two prefixes belong to two different scoped tables on the
> network side and therefore two RAs will be sent for them.
> Am I missing smth?

I don't think you are. But today, that doesn't happen, and I think
we were trying to have the host do the best it can anyway.

> 
>> 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.
> 
> To be honest I'm a bit confused with the changes described in the Section 3.1 of
> draft-ietf-6man-multi-homed-host...
> Let's assume that
> 1) first-hop routers behave as described in
> draft-bowbakova-rtgwg-enterprise-pa-multihoming-00
> (SADR-capable routers which stop advertizing
> themselves as default routers and/or withdraw the prefixes if source
> address from that prefix should not be used)
> 2) the host uses the rule 5.5 of the source address selection algorithm.
> In that case would not any host which follows RFC6724 and RFC4191
> behave exactly as described in the Section 3.1 anyway?
> (sorry for the stupid question, I feel like I'm missing smth here..).

No, I think that's right, but today many hosts don't use rule 5.5
and many routers don't do SADR. We were trying to make the best of it.

> 
> The Section 3.2 (Default Router Selection) - see my comment above.
> 
> I'll add the reference to the section 3.4 of
> draft-ietf-6man-multi-homed-host to the sections of our draft
> which discuss ICMPv6 error messages as a mechanism to influence the
> address selection on hosts.
> 
>> Also, routers must be capable of sending PIOs with both
>> L and A bits set to zero.
> 
> Oh, I was not consider that as a special feature, assuming any router
> should be capable of doing that.
> Probably you are right and it should be explicitly mentioned, just in case...

People have alleged that current routers won't do that.

Thanks!
   Brian

> 
>> 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.)
> 
> Good point, I'll update the text with extension header issues.
> 
>>
>> Finally, it's helpful in site multihoming proposals to indicate whether
>> they meet the goals in RFC 3582.
> 
> Oh, thanks - we do list RFC3582  in the Normative References section
> but there is no reference to it
> in the text. Will be fixed!
> 
> 
>> 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: <[e-mail]>
>>>> 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 <[e-mail]>, Jen Linkova <[e-mail]>, "Fred Baker" <[e-mail]>, "J. Linkova" <[e-mail]>
>>>>
>>>>
>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
>