Subject: Re: Comments at the mic: draft-sarikaya-6man-next-hop-ra

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Dec 2014 11:11:02 -0600

Bonjour Pierre,

On Thu, Nov 27, 2014 at 3:20 AM, Pierre Pfister <[email-masked]> wrote:
> (Interesting bug with the empty message…)
>
> Hello Behcet,
>
> Sorry for taking that long to answer. I promised you some comments at the
> mike, here they are.

Sure.

>
>
> 1. As other said. I don’t think the next-hop address is a good idea.
> If another router wants to be a router for hosts, it can send its own RAs.

The idea is not just next hop, it is to configure the host with what
that next hop supports. So we need the other options as well.

>
> Similarly, I don’t see why we need that many new options.

Originally we had 7 options, now we are down to 5, I think it is the
minimized form.

> One Source-Specific Route option would be enough.
> IMHO, we should try to make it compatible with RIOs.
> Define a new option (similar to RIO options) with Source-Prefix, and specify
> a new bit flag in RIO option saying
> the option can be ignored by hosts capable of understanding the
> Source-Specific RIO (basically it means there is a source-specific RIO in
> the message, and the RIO may be ignored by those hosts capable of
> understanding the Source-Specific ones).
>
>
> 2. Concerning DHCPv6. I don’t think we need that here. Hosts MUST parse RAs.
> I don’t see why we would need it in DHCPv6.
>

We said that DHCPv6 would be used in some networks for configuration
of hosts so DHCPv6 solution is for that case.
See also Brian's comments.

>
> 3. Trying to answer to ‘why rule 5.5 in RFC6724 is not enough’.
>
> The draft says the reason why we need this new feature is to avoid egress
> filtering problems for hosts connected to multiple interfaces.
> I think rule 5.5 solves that problem when an application sends a packet with
> an unspecified source address.
> In the presence of two default routes, one route will be chosen, and rule
> 5.5 will make sure the right source address is used  (The next-hop is chosen
> before the source-address).
> (That said, rule 5.5 is quite complex to implement. I think a RIO-based
> solution would be simpler, as it would just require a few more line of code
> compared to existing RIO option).

Speaking of implementation, I think the options in my draft are very
easy to implement due to the structure as contributed by Dan Ludtke (u
with dots that I can not get here).

>
> Now when the application selects a source address, I think rule 5.5 doesn’t
> solve the problem (The source address is chosen before next-hop selection).
> The source address is a way for the application to select the exit point
> (MIF will probably provide an API for applications to select a PvD, but it
> is not there yet and I think defining that option could also be useful to
> MIF in order to provide information about PvDs, like source-specific routing
> capabilities).

Sure. In a way the draft is providing PvD container or part of the container.

> In the presence of multiple default routes, one will be picked, ignoring the
> source address which was selected by the application. Therefore, the
> next-hop router may not be the correct one, and the packets may be filtered.
>
>
> 4. I would also like to point-out a use-case which seems to be ignored in
> this document, and which may appear in homenet scenarios.
>
> You have one link, a host, and two CPEs.
>
> Host — — Router 1 — ISP1
>       |
>       |_ _ Router 2 — ISP2
>
>
> Each ISP provides a different prefix, and so do the two routers to the host.
> Using a source/dest aware routing protocol (which is how homenet works), the
> two routers are both able to route traffic correctly, no matter which
> next-hop router and source address the host selects.
> But if we don’t let the host know which router to choose:
> - The link bandwidth may be halved (We don’t use redirects)
> - We may have a redirect ping-pong between the two routers (When we use
> redirects).
>
> The problem with redirects is that they are not source-specific, so if the
> host tries to send packets to the same destination using both source
> addresses, we happen to have an erratic situation with ping-pong redirects
> being sent by the routers.
>
> Defining a Source-Specific RIO would allow solving that issue, and let hosts
> select the right router no matter what.

Thanks for this use. I am going to add it to SADR Overview Draft.

If I remember well, a similar use case was mentioned in the great
Huitema's draft.

Regards,

Behcet
>
>
> Regards,
>
> - Pierre
>
>
>
> Le 17 nov. 2014 à 22:37, Behcet Sarikaya <[email-masked]> a écrit :
>
> Hello Folks,
>
> Last Friday at IETF 91 6man session many people expressed opinions on
> the source address dependent routing related drafts.
>
> Will each of you please put your comments in writing and let us see them?
>
> If no one comes up, I am going to wait for the minutes and make calls
> for each of you separately.
>
> Regards,
>
> Behcet
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Dec 2014 11:56:06 -0600

... snipped

> One Source-Specific Route option would be enough.

See below.

> Define a new option (similar to RIO options) with

> Source-Prefix,

This is Option 1.

> and specify
> a new bit flag in RIO option

This is Option 2

>saying

> Source-Specific RIO

This is Option 3

> (basically it means there is a source-specific RIO in

As above, you are talking about three options not one.

Option 1 and Option 2 above are already defined.
I added the combination option, Option 3 for use in homenets.

I am not using PIO, I think you explained it very well above why.

Please find the new drafts at

http://www.ietf.org/internet-drafts/draft-sarikaya-6man-next-hop-ra-04.txt

and

http://www.ietf.org/id/draft-sarikaya-6man-sadr-overview-03.txt

Regards,

Behcet