Subject: Re: 6MAN Adoption Call for: draft-baker-6man-multi-homed-host-03

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 6 Oct 2015 16:14:07 -0500

Hi Ole,

Here are my comments on this short (about 6 pages) draft.
First, I don't know if I am qualified to comment on a draft
co-authored by two ex-ADs and ex-IETF chairs, maybe I am not :-)

Section 1.
It says:
The combination of existing recommendations for home
   gateways [RFC6092] [RFC7084] can also result in such filtering.

 how could a set of  requirements text result in such a normative
looking behavior?

It says:

Therefore, the only safe solution is to
   implement the features defined in this document.

It is not explained why (is it safe and secure)?
End of Section 1:
This section is normally about scope and related work. However the
related work discussion seems to have completely overlooked 6man WG
discussions that happened over quite long time period. Also related
solution proposals such as draft-pfister-6man-sadr-ra, etc.

Section 2.

A host receives prefixes in a Router Advertisement [RFC4861]

what about RFC 4191? 4191 also gives prefixes and the host may receive them?

Section 3.2

This selection rule would be applicable in a host
   following the recommendation in the previous paragraph.

 This is a single paragraph section. Which paragraph is the previous paragraph?

Lastly the title:

Host routing in a multi-prefix network

This title gives the impression that the draft is about "host routes"
while it seems like this draft has nothing to do with host routes.

Regards,

Behcet

On Wed, Sep 30, 2015 at 3:06 PM,  <[email-masked]> wrote:
> This message starts a two week 6MAN call on adopting:
>
>    Title     : Host routing in a multi-prefix network
>    Authors   : F. Baker, B. Carpenter
>    Filename  : draft-baker-6man-multi-homed-host-03
>    Pages     : 9
>    Date      : 2015-09-03
>
>    http://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host-03
>
> as a working group item. Substantive comments and statements of support
> for adopting this document should be directed to the mailing
> list. Editorial suggestions can be sent to the authors.  This adoption
> call will end on October 14th, 2015.
>
> Regards,
>
> Bob Hinden & Ole Trøan
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Oct 2015 15:39:50 +1300

Hi Behcet,

>  how could a set of  requirements text result in such a normative

I guess we mean "Implementations that combine existing recommendations..."

> It is not explained why (is it safe and secure)?

It doesn't mean "safe" in the sense of security. It means "safe" in
the sense that it will work in all scenarios. Needs rephrasing.

> solution proposals such as draft-pfister-6man-sadr-ra, etc.

IMHO we can trace discussions of this problem back at least ten years
(e.g. draft-huitema-multi6-ingress-filtering from 2004). If the WG adopts
the draft and wants us to add a literature review, we can certainly do
that (IMHO as an appendix to help the simplicity of the main text).
Of course it would include your work and Pierre's.

> what about RFC 4191? 4191 also gives prefixes and the host may receive them?

Good catch. We need to clarify that source-based next hop selection
has priority over router preferences.

>  This is a single paragraph section. Which paragraph is the previous paragraph?

It should be "previous section". This is an editing mistake.

> while it seems like this draft has nothing to do with host routes.

Yes, perhaps "Routing packets from hosts in a multi-prefix network"
would be clearer.

Thanks for the review. We'll hold these points until the WG adoption
call is resolved.

     Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Oct 2015 15:14:27 +0200

> the sense that it will work in all scenarios. Needs rephrasing.

I agree with the doubt on the word "safe" and the need to clarify.

Something "safe" to assume is something which will always work, compared 
to the existing situation which works anyways.

It is worth mentioning the situation today: when two default routers are 
in the table the Host typically selects the last in the list.  This has 
some problems, ranging from "acceptable" (outgoing path different than 
incoming) to breaking (ingress filtering is present.)

A better selection algorithm matches exactly len bits of the src (len 
present in PIO) against the list of prefixes in all PIOs and then takes 
the corresponding default router.  There is still a question of _which_ 
len should be used in that exact match: the shortest?  The first len in 
the list?  The /64?

Or do we mean "longest prefix match"?  I think we should not mean 
longest prefix match when designing source-based routing.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 Oct 2015 11:17:03 -0500

> Of course it would include your work and Pierre's.

Disagree.

I think you are missing the main point. Yes this topic goes way back
to Huitema's draft in 2004, but I think that the idea that the host
should do something has been introduced only recently.

No, I did not mean the whole literature survey, I meant past work
related to 6man should be included.

Behcet