RE: Multihoming by IP Layer Address Rewriting (MILAR)

[Michel Py <py_michel@yahoo.com>]

Iljitsch -

--- Iljitsch van Beijnum <iljitsch@muada.com> wrote:
>>>>>> "the subset of routers that do not receive a
>>>>>> full routing table from a single peer or a
>>>>>> default route".

>>>> Or: "The subset of routers that do not use a
>>>> default route, and peer with two or more other
ASNs."
 
>> I want to exclude the routers that run defaultless
>> by choice, rather than out of necessity. You want
>> to include those.

That is where I don't follow you. In defining the
semantics
of what is the DFZ, why would you exclude the routers
that
run defaultless by choice? I thought that the
definition
if the DFZ should match WHAT the routers actually do
and
not WHY.


>> but only 32 MB on one of the VIP cards. Those cards
need
>> a copy of the forwarding table and 32 MB
>> leaves to little room for error.

Selling the customer Cisco 12416s would solve the
problem ;-)
Then you can scrounge the 7500 for your CCIE lab :-)

>>>> What should I change in 6.2.9 of
>>>>
http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt
>> The problem is that it is hard to find specific
>> information I'm looking for. MHTP rendevous points
>> keep the mapping between multihomed addresses
>> and single homed addresses, right? But is this a
>> static mapping or a dynamic one?

The MHTP routing table is a standard BGP routing
table,
dynamic naturally. However, the rendezvous point is
used
in the bootstrap phase only, then the client and the
endpoint

 
>> Back to the problem at hand. If we are going to
>> translate addresses, we need to know two things:
>> what are possible valid addresses to translate to,
>> and which of the possible addresses are actually
>> valid/reachable. Unless I'm reading the draft
wrong,
>> you try to solve both in one go.

Correct.

>> I think that's not the best solution, since this
way a
>> continuous stream of reachability information flows
>> around the globe, whether this information is of
use
>> at a certain point at a certain moment or not.

I am unsure of what you are refering to here. If you
are
talking about the MHTP routing table, The way I
understand
BGP is that routes are not exchanged if they do not
change
so there is no reachability information floating
around the
globe unless a change occurs.
If you are referring to MHTP keepalives, these are
sent only
when there is active traffic between an MHTP client
and an MHTP
prefix, the the reachability information that flows
flows only
from/to there is current traffic and times out
quickly.

>> The mapping between MH and SH addresses could
easily be
>> quite static if we employ separate means to
validate
>> the SH addresses.

The mapping between MH and DH addresses is actually
static
(router's configuration if you prefer) in MHTP
endpoints.
In MHTP rendezvous points, it will change only if a
link
goes down or that kind of event.


>> Also, using MH addresses that are reachable without
>> translation makes sense. That way, there is instant
>> compatibility with non-MH-capable hosts
>> and it saves some processing and address space.

That way the implementation can be gradual, and there
are tools (control of proxying rate) that could help
enforce the migration, if desired or required.


>> Disagree: the DNS system has its own redundancy
>> features, which are even better than multihoming.
>> But many people still don't get it and put
>> primary and secondary nameservers in places with

We are actually saying the same thing: The design of
DNS redundancy is better than multihoming. How do we
get people to actually use it?

Michel.


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com