draft-kurtis-multihoming-longprefix comments

[Pekka Savola <pekkas@netcore.fi>]

Hello,

A few comments on the draft.

Major comments:

 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_
DMZ.

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
reason).

This seems rather nice way to do uRPF in the multihoming case.

8. Acknowledgments

   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.

Editorials:

   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/an/and/
==> s/document/document describes/

   In order to make use of the methods for achiving multihoming as

==> s/achiving/achieving/

   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/provide/provider/
==> 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
   
==> s/have/has/

   will prove that claim either false or right.  the second advantage of
   
==> s/the/The/

   of concern for some enterprises to stay way from IPv6, but it does at
   
==> s/way/away/

 Another
   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
   
==> s/know/known/

-- 
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