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

[Jen Linkova <[e-mail]>]

On Tue, Jul 12, 2016 at 9:01 AM, Brian E Carpenter
<[e-mail]> wrote:
>>> 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.

Ah, I see, it's more clear now, thanks for the explanation.
So basically the changes described in draft-ietf-6man-multi-homed-host
are required unless the network (and the first-hop routers in particular)
support SADR and the features described in
draft-bowbakova-rtgwg-enterprise-pa-multihoming.

What if the Section 4.2.4 is re-phrased in the following way:
=== old text===

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.  First-hop routers in the
   enterprise network need to be able of sending different RAs for
   different SLAAC prefixes (either based on scoped forwarding tables or
   based on pre-configured policies).
===== new text =====
At the same time Router Advertisements provide a reliable mechanism
   to influence source address selection process via PIO, RIO and
   default router preferences (all those options have been
   standardized by IETF). In SADR-capable network where first-hop routers
are capable of sending different RAs for different SLAAC prefixes
(either based on scoped forwarding tables or
   based on pre-configured policies), no changes in hosts behavior are
required. However to fully benefit of RA-based solution,
hosts are required to support RFC4191 and use the Rule 5.5 of source
address selection algorithm as specified in RFC6724.
If first-hop routers do not support SADR and scoped RAs as described
in the Section 4 of this document, hosts behavior needs to
be changed as described in draft-ietf-6man-multi-homed-host
======

(Section 4.6 will be updated accordingly).

What do you think?

>From deployment perspective requesting a new feature from my router
vendor(s) and upgrading X (where X < 100 usually) routers is much
simpler than requesting a behavior change of thousands of end devices
(well, some of them might not support Rule 5.5 and RFC4191 but at
least some of them do...), especially in 'Bring Your Own Device'
model.  IMHO it would be nice to make it clear in the document that
SADR helps deploying multihoming with minimal changes on hosts side
(comparing to changes required if the network is not SADR-capable).

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

I'll update the text with the requirement, thanks!

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