Subject: Re: New Version Notification for draft-sarikaya-6man-sadr-overview-06.txt

From: Ray Hunter <[email-masked]>
Date: Tue, 07 Apr 2015 18:40:37 +0200

Behcet Sarikaya wrote:
> Hi all,
>
> I submitted Rev. 06 of SADR Overview draft. This revision contains
> changes from IETF 92, namely:
>
> -corporate VPN  scenario in Section 3 contributed by Brian Carpenter
> as discussed in our F2F meeting in Dallas with the chairs, Brian,
> Pfister and myself.
>
> -Third party next hop text in Section 5 where the third part next hop
> issue has been left out of scope.
>
> I think this draft is ready for adoption call.
> Also contributors wishing to coauthor, send me an email.
>
> Regards,
>
> Behcet
>
>
> A new version of I-D, draft-sarikaya-6man-sadr-overview-06.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Name:           draft-sarikaya-6man-sadr-overview
> Revision:       06
> Title:          Source Address Dependent Routing and Source Address
> Selection for IPv6 Hosts
> Document date:  2015-03-31
> Group:          Individual Submission
> Pages:          16
> URL:
> http://www.ietf.org/internet-drafts/draft-sarikaya-6man-sadr-overview-06.txt
> Status:
> https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview/
> Htmlized:       http://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-06
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-sarikaya-6man-sadr-overview-06
>
> Abstract:
>     This document presents the source address dependent routing from the
>     host perspective.  Multihomed hosts and hosts with multiple
>     interfaces are considered.  Different architectures are introduced
>     and with their help, why source address selection and next hop
>     resolution in view of source address dependent routing is needed is
>     explained.  The document concludes with an informative guidelines on
>     the different solution approaches.
>

 > If host configuration is done using router advertisement messages
    then there is a need to define new router advertisement options for
    source address dependent routing.  These options include Route Prefix
    with Source Address/Prefix Option.  Other options such as Next Hop
    Address with Route Prefix option and Next Hop Address with Source
    Address and Route Prefix option will be considered in Section 5.3

Like many others, I still don't get the need for the Next Hop Address 
option, but I guess that could be thrashed out later.

I also still wonder whether the WG really needs three drafts that have 
considerable overlap, and yet still leave considerable gaps:

We have:

https://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-06
https://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-04
and
https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-00

But I'd expect any "SADR overview" to also cover router - router 
forwarding behaviour. Not just end host - router.

And was there ever any agreement reached on which was the more beautiful 
of https://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-04 or 
https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-00 ?

In my mind, https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-00  
is a logical progression from https://tools.ietf.org/html/rfc4191

But that also leaves major gaps on how routers would interact, plus any 
potential issues at an AS-boundary e.g. updating BCP38 to filter inbound 
and outbound SADR routes.

In short: I'm still not convinced we have the right problem statement.

regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Apr 2015 12:02:11 -0500

Hi Ray,

On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter <[email-masked]> wrote:
>> Htmlized:
>> http://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-06
>> Diff:

More or less. Section 5.3 makes the third party next hop work out of
scope, maybe sometime in the future someone will be able to come up
with a good use case, I believe so.

> considerable overlap, and yet still leave considerable gaps:

One is overview the other two are solution documents.

> But I'd expect any "SADR overview" to also cover router - router forwarding
> behaviour. Not just end host - router.

Can you offer some text?

>
> And was there ever any agreement reached on which was the more beautiful of

This should be
draft-sarikaya-6man-sadr-ra

 we do not plan on pursuing draft-sarikaya-6man-next-hop-ra-04 any
further because of the third part next hop issue.

 or
> In my mind, https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-00  is a
> logical progression from https://tools.ietf.org/html/rfc4191
>

The other approach is to define a new option as in
draft-sarikaya-6man-sadr-ra then we don't need an I flag. Also the
point you have below could be discussed there.

> potential issues at an AS-boundary e.g. updating BCP38 to filter inbound and
> outbound SADR routes.

Currently we (Pfister and I) are discussing how to merge these two
solution documents. So I believe there will be one solution document
in the end.

> In short: I'm still not convinced we have the right problem statement.

Overview document is the one we have now after long discussions.
Of course it could be improved, the plan is to improve it as a WG draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2015 08:51:20 +1200

> On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter <[email-masked]> wrote:

...
>> behaviour. Not just end host - router.

At the moment that's covered by draft-baker-rtgwg-src-dst-routing-use-cases.
IMHO the separation into host and router drafts is reasonable, so that
each draft fits mainly into a single WG.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Apr 2015 08:15:46 +0200

> each draft fits mainly into a single WG.

fully agree. SADR might not be the best name for the host portion.
perhaps something like "IPv6 Multi-homed host gaps”?

Ole

---

From: Ray Hunter <[email-masked]>
Date: Fri, 10 Apr 2015 12:39:07 +0200

> Ole Troan <mailto:[email-masked]>
> 10 April 2015 08:15
>
> Brian E Carpenter <mailto:[email-masked]>
> 9 April 2015 22:51
>> On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter<[email-masked]>  wrote:
>
> ...
> Behcet Sarikaya <mailto:[email-masked]>
> 7 April 2015 19:02
> Hi Ray,
>
> On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter<[email-masked]>  wrote:
>> Behcet Sarikaya wrote:
>>> Hi all,
>>>
Both of your comments make sense to me: host portion covered in this WG 
and changing the title.

What about other considerations then?

Such as potentially extending ICMP redirects to include source address 
specific applicability?

I know this has been discussed, but it isn't included in any problem 
statement yet AFAICS.

regards
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 10 Apr 2015 11:36:59 -0500

Hi Ray, all,

On Fri, Apr 10, 2015 at 5:39 AM, Ray Hunter <[email-masked]> wrote:

>   Ole Troan <[email-masked]>
> Isn't this limiting the host gaps, possibly the future ones to source
address selection?
Otherwise I am OK.

> Ole
>   Brian E Carpenter <[email-masked]>
>  9 April 2015 22:51
>
> On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter <[email-masked]> <[email-masked]> wrote:
>
> ...
>
I agree.

snipped some text here.

> draft-sarikaya-6man-sadr-ra then we don't need an I flag.
>
> Snipped some text.

> solution documents. So I believe there will be one solution document
We need more feedback on the above choices for solution approaches.

Regards,

Behcet