Re: Opinion requested: Independent submission of draft-sarikaya-6man-sadr-overview-11

[Suresh Krishnan <[e-mail]>]

Thanks for your comments Philip. I do agree with a lot of your comments but 
unlike the IETF stream where we have the possibility to get these addressed 
with extensive text changes, there are only five responses we can provide to 
the ISE for a conflict review request as described in RFC5742

    1. The IESG has concluded that there is no conflict between this
       document and IETF work.

    2. The IESG has concluded that this work is related to IETF work done
       in WG <X>, but this relationship does not prevent publishing.

    3. The IESG has concluded that publication could potentially disrupt
       the IETF work done in WG <X> and recommends not publishing the
       document at this time.

    4. The IESG has concluded that this document violates IETF procedures
       for <Y> and should therefore not be published without IETF review
       and IESG approval.

    5. The IESG has concluded that this document extends an IETF protocol
       in a way that requires IETF review and should therefore not be
       published without IETF review and IESG approval.

Regards
Suresh

On 09/22/2016 05:01 AM, Philip Homburg wrote:
> In your letter dated Thu, 22 Sep 2016 05:33:22 +0000 you wrote:
>> Hi all,
>>   The draft describing a problem space overview for Source Address Dependent
>> Routing and Source Address Selection for IPv6 Hosts available at
>>
>> https://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-11
>>
>> has been submitted through the Independent stream for publication.
>
> I find this a rather confusing draft.
>
> It seems to combine a number of ideas in a random way.
>
> That starts in Section 2, where, at least to me, the scenarios appear in a
> random order. For readability it would be nice if the most basic scenarios are
> described first and gradually build up to more complex versions.
>
> For me it helps to keep host behavior separate from router behavior. Trying
> to think about all the complexity of hosts at the same time as thinking about
> all the different ways to configure routers doesn't really help.
>
> So it is best to focus on the host-router protocols and describe where they
> are currently lacking.
>
> Looking at the problem from a host point of view: source address selection is
> to a large degree independent of next hop router selection. I.e., the
> source address is selected first, and then with dest/src routing the source
> is taken into account to select the next hop router.
>
> I think it would help to make this split explicit in the draft. In simple
> cases, source selection is almost trivial (two prefixes that are equivalent
> from the perspective of the host), but next hop selection still requires
> the source address.
>
> In other cases, source address selection is complex, but doesn't really make
> next hop selection more complex.
>
> Based on this it is possible to define what information the host needs, both
> for source address selection and for next hop selection.
>
> If I ignore source address selection for the moment, then in many cases
> a host already has all the information it needs for dest/src routing.
>
> Even in the redirect ping-pong case, the host can just extract the source
> address from the copy of the original packet.
>
> So in a lot of cases, there is no need to change bits on the wire, we just
> need to redefine how hosts should behave.
>
> Then what remains (as far as I know only the lack of a PIO option when a host
> gets its address from DHCPv6) can be addressed.
>
>
>