Subject: draft-.*-6man-sadr-ra-00

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Mar 2015 14:52:38 +1300

Hi,

I was quite surprised to see two drafts matching the same regexp appear
within a day or so. What I appreciate about draft-sarikaya-6man-sadr-ra-00
is that it provides context (derived from the author's previous drafts).
draft-pfister-6man-sadr-ra-00 doesn't provide much context (and perhaps
surprisingly, doesn't cite prior art like draft-sarikaya-6man-next-hop-ra).
But right now I can't really judge which of them is going in the right
direction.

I still feel we're lacking an agreed problem statement. Where I thought
we'd got to was that draft-sarikaya-6man-sadr-overview shows that the
residual problem area is quite small, but we haven't got consensus on
that and IMHO we won't unless the WG adopts the draft and hammers it
some more.

If there's no consensus on the problem, I am quite certain there will
be no consensus on a solution.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Mar 2015 15:44:24 +0900

> be no consensus on a solution.

We should print that sentence on banners and hang one up over each WG
meeting entrance so participants see it when they go in.

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Mar 2015 09:32:46 +0100

> be no consensus on a solution.

Let me give the problem description a try:

A host is directly connected (single interface) to two border routers on the same link.
 Assuming multiprefix multihoming and BCP38, the problem is, how can we ensure that the host has enough information to:

    - given destination and next-hop can chose the correct source address (matching the border router PA assignment)
    - given a source address and a destination chose the correct next-hop

This is not a problem when a host is further away from the border routers (the network will do SADR).
If the two border routers do SADR and exchange routing, then if host picks wrong next-hop, traffic will still be routed correctly. Otherwise a border router returns a destination unreachable ICMP with code source address failed ingress/egress policy.

Anything more to this problem?

cheers,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 4 Mar 2015 09:36:12 +0100

Hello Brian,

> surprisingly, doesn't cite prior art like draft-sarikaya-6man-next-hop-ra).

Indeed. I am not a big fan of problem analysis. Although I do understand it is important to agree on the problems to solve.
I did not put that much context because it would have been redundant with the pages and pages of discussion we had, and previous drafts. 
The purpose of the draft is to provide one possible way to address the problem. The Introduction section states why I think it is necessary. 
In a too condensed way, maybe.

As I said in my mail to Behcet. I am not willing to overthrow his work. But rather tell that I think the direction he was going was not the right one.

Concerning the citations, you are perfectly right. I should have given more recognition to existing work.

Thanks,

- Pierre

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 4 Mar 2015 09:44:42 +0100

Hello Ole,

> This is not a problem when a host is further away from the border routers (the network will do SADR).

I agree with this problem analysis. Let me just add one little point to the latter assertion.
Although the network would do sadr, e.g., in a home network with multiple uplinks, failure from a host to pick the right next-hop router 
may cause problems if the router needs to send the packet to a router on the same interface it received the packet on:
- If the router sends redirects -> Redirects are not source specific. It may cause issues. I think we should not send redirects when the route is source address dependent (Or define source-address-dependent redirects...).
- If the router does not send redirects -> Consumes link throughput (May halve the throughput).

This problem does not only appear with border routers, but in any case packets would be retransmitted on the same link it was received on based on a source address dependent route.

Cheers,

- Pierre

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Mar 2015 10:42:59 -0600

Hi Ole,

A quote from draft-baker-rtgwg-src-dst-routing-use-cases:

An initial approach was suggested in [RFC3704], which
   assumed that a packet following a default route to an egress CPE
   Router might arrive at the wrong one, and need to be redirected to
   the right CPE Router.

 He goes on to say that SADR solutions are needed and that's what we
are saying at the host while Fred's draft is about what routers should
do.

I think the operators don't like ICMP messages because that's what is
used in DOS attacks.

Regarding Pierre's reply, I already have it in Section 5.1
draft-sarikaya-6man-sadr-overview-05.
We can add the redirect argument there as well, hopefully after it
becomes a WG draft :-)

Regards,

Behcet

On Wed, Mar 4, 2015 at 2:32 AM, Ole Troan <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>