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

[Ray Hunter <[e-mail]>]

> Ole Troan <mailto:[e-mail]>
> 10 April 2015 08:15
>
> fully agree. SADR might not be the best name for the host portion.
> perhaps something like "IPv6 Multi-homed host gaps”?
>
> Ole
> Brian E Carpenter <mailto:[e-mail]>
> 9 April 2015 22:51
> On 08/04/2015 05:02, Behcet Sarikaya wrote:
>> Hi Ray,
>>
>> On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter<[e-mail]>  wrote:
>
> ...
>>> But I'd expect any "SADR overview" to also cover router - router forwarding
>>> behaviour. Not just end host - router.
>> Can you offer some text?
>
> 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
> Behcet Sarikaya <mailto:[e-mail]>
> 7 April 2015 19:02
> Hi Ray,
>
> On Tue, Apr 7, 2015 at 11:40 AM, Ray Hunter<[e-mail]>  wrote:
>> 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.
>
> 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.
>
>> I also still wonder whether the WG really needs three drafts that have
>> considerable overlap, and yet still leave considerable gaps:
>>
>
> One is overview the other two are solution documents.
>
>> 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.
>
> Can you offer some text?
>
>> 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
>
> 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
>> 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
>>
>
> 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.
>
>> 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.
>
> 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.
>
>
>> regards,
>> RayH
>>
>>
>>
>
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