[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A few comments on the draft.
1) Seems to give wrong impression about the effectiveness of this
mechanism. I believe (I'm collecting and analyzing some data too) that a
significant portion of multihomers do it because they want to obtain
operator independence. They usually don't have PI addresses, but what I'd
call "PA sold off as PI" or "PA advertised as PI". (Esp 5.3)
There must be an applicability section or statement early on what this
tries to accomplish.
2) If we really need to go down with longer prefixes approach, I'd really
want to restrict hem to peerings (and even smaller upstreams) only, _NOT_
More specifics (:-):
Longer prefix multihoming SHOULD NOT
be used as an excuse to disable RPF checks.
==> there are usually many ways to do uRPF. One is a "feasible paths"
approach, where sourcing a packet is ok as long as there is route towards
the source in that interface (even if it is not active, due to a policy
This seems rather nice way to do uRPF in the multihoming case.
This paper builds on a discussion at the IETF-55 in Atlanta. People
who was part in the idea is Thomas Narten and Chirstian Huitema but
also all the people who where are the unofficial multi6 meeting.
==> The idea of longer prefixes is ages old but rightfully scorned. I
think you should mention that this is not a new idea at all.
In the current IP version 4 Internet, many organizations that are not
Internet Service Providers are still getting their Internet
connectivity through multiple providers by having address space that
are announced via multiple paths.
==> s/that are //
==> this is one example of multihoming (though only really visible one)
connections. For this they have also applied for similar blocks an
their own AS numbers just as the ISPs use today. This document how
==> s/document/document describes/
In order to make use of the methods for achiving multihoming as
addresses from their network service provide. In the case of already
existing multiple service providers, only one of the should allocate
a address block to be used
==> s/a address/an address/
These upstreams SHOULD accept a
prefix length of 48 bits from their peers, and SHOULD NOT aggregate
these routes. For the provider that have allocated
==> s/aggregate/automatically aggregate/ (or clarify that it's still ok to
advertise the aggregate route :-)
==> s/have allocated/has allocated/
should configure it's border routers to announce the prefix it have
will prove that claim either false or right. the second advantage of
of concern for some enterprises to stay way from IPv6, but it does at
popular reason in the IPv4 Internet have also been the fact that you
with a multihoming setup would get so called Provider Independent
addresses. These PI addresses are allocated directly from the RIRs
to the enterprise.
==> move 'you' to before 'would'.
In the IPv4 Internet routing table, also know as the Default Free
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords