RE: host-centric draft

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Iljitsch,

thanks for commenting the draft

I include my own answers to your comments, Christian and Richard perhaps
think different


> I've been catching up on drafts, reaching draft-huitema-multi6-hosts-03
> just now. A few questions:
>
>    "A strong assumption of the IPv6 architecture is that all prefixes of
>     a site will have the same length; it is thus possible to derive a
>     prefix from the source address of a "misdirected" packet, by
>     combining this prefix with a conventional suffix."
>
> This is very unclear as the reason to have such an anycast address in
> the first place is only given 30 or so pages later.

Ok.
We could add a pointer to the explanation 30 pages later, or even we could
remove some unclear details at this point and leave all the explanation for
later.
Just mentioning that it would be good if the prefix can be derived
automatically and leave for later the explanation on how to do this.

>
> About ICMP/ingress filtering: if it is actual ingress filtering we're
> talking about (ie, an ISP filters packets it receives from a customer)
> ICMP error messages aren't likely to be forthcoming when an improper
> source address was used by the customer, as the ISP in question doesn't
> know that the addresses which are filtered out should go back to the
> customer in question. So in order for this to work reliably customers
> must install filters that perform the same function, but then for
> egress, as the customer border router has a good return path for the
> ICMP message.

Yes, this is what i think is described in the draft...

I mean, we assume that the isp is performing ingress filtering, so the idea
is not to send packets with a incompatible source address.
We then explore different forms to do this, one of them involves sending an
ICMP error back to the host, indicating the correct source address. Now,
this ICMP error message is not generated by the ISP border routers but it is
generated by the site exit routers, since it is the site itself that is
interested in providing feedback to the hosts. All this is an intrasite
mechanism.
So, i think that i agree with you and the draft states what you are
saying...


>
> A general problem that I have with this draft is that it explores some
> very specific mechanisms, but at the same time doesn't explore some
> other mechanisms that could lead to similar results. (For instance, a
> situation where two distinct layer 3 networks exist in parallel isn't
> explored. For source address rewriting using a special "rewrite this"
> prefix would be a possibility.) It would be better to either be brief
> or complete.

Well, i think that the idea of the draft is to analyze all the options that
seemed reasonable to us. The problem may be that we didn't came up with all
the possible solutions, so we didn't include them in the draft.
The draft starts with an analysis of all the options that we had identified
(not so much detail in this part) and then selects and describes the
preferred solution (much more detail in this part)

IMHO, the analysis is as important as the solution proposed since it is
aimed to discuss different approaches.

So if there are some points missing in the analysis, the selected solution
may well change

I would be glad to try to include another options in the analysis.

for instance, the options that you were mentioning that is missing, could
you expand on this?

The two layer 3 network that you mention, would this be like a multihomed
host?


>
> The problem that rerouting could invalidate an earlier source address
> choice isn't mentioned.

Could expand this too? perhaps an example?

>
> I'm unsure why we would want to inject BGP information into hosts.

I don't think that injecting BGP routing table has been considered in the
draft (but i may be forgetting something)

> Reachability yes/no isn't very useful as the actual reachability status
> of the other side is in almost all cases hidden by aggregation. So
> basically this only indicates whether the ISP in question is available.
> Determining preference based on BGP information is also a relatively
> futile endeavor as path lengths are very often the same and relevant
> differences in topology typically don't show up in BGP. (Many large
> networks use a single AS for an entire continent or even the world,
> while obviously small networks don't.)

Well,
as i see it, there are two systems that can be aware of reachability: the
routing system or the end host itself

The end host can discover reachability by itself, simply trying to send
packets to the other end. This is more reliable way to discover
reachability, since the host is actually reaching the target.

The other option is to use the routing system. As you mention, the
information provided by the routing system is aggregated, so it hides some
information.
However, the routing system has the information in advance, while the host
has to discover it when it needs it.

So the host obtained by the host is more accurate, but the routing system
provides it faster, i guess.

both options are explored in the draft and some of the drawbacks are
analyzed, perhaps this particular pov in really included, though

The other problem with bgp is that it seems unsuitable for small sites,
where the is not likely to be bgp expertise available, so the host option is
considered more suitable for this scenario

Large sites that have networks manager are likely to be capable of running
bgp. Additionally, it seems that the bgp option provides more centralized
policy management, so perhaps it would be preferred by large sites.

But one of the goal of the draft is to foster discussion on this topics...

>
> The 6 level deep heading numbering is somewhat excessive.

Yes, but i guess that merging sections would render the draft even more
unreadable

>
> 9.1.4.19 What new information should applications be aware of?
>
>     None
>
> I don't really agree. Applications need to try all addresses for a
> correspondent. Some do this today, most don't. And this needs to be
> done in a smart way, a four minute timout between trying successive
> addresses isn't acceptable.

Well, rfc 3484 already states that
"Well-behaved applications SHOULD iterate through the list of
addresses returned from getaddrinfo() until they find a working
address."

But i agree with you, something about this can be included here.

The other point about this is when considering retrying with different
source addresses.
If you do this sequentially, i think that it would be up to the app to
retry.

However if you do it in parallel, i think that the ip layer could simply
generate multiple packets and send them in parallel, so no need to change
the apps.

Reagrds, marcelo

>
>