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

[Jen Linkova <[e-mail]>]

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

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

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

> 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



-- 
SY, Jen Linkova aka Furry