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

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

in line...

On 12/07/2016 20:44, Jen Linkova wrote:
> 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?

That looks good to me, assuming Fred agrees.

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