comments on requirements-05

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 5 May 2003, Kurt Erik Lindqvist wrote:
> > Could we restart the last call, on the basis of the -05 draft?
> > My answer on that is: ship it!
> 
> Me and Sean have discussed around this last-call in private and we are 
> both really in favor of getting this shipped ASAP. Unless anyone have 
> come up with a really compelling reason not to ship it by Wen 12.00 CET 
> we will ship it. The -05 draft that is.

I've done a quick review on the document.

There are lots of things that should be clarified, but all should be
rather easily editable.  The document name should also be changed
(s/requirements/goals/) if that's possible.

substantial
-----------
1) the terminology should be improved to be more precise.

   A "transit provider" operates a site which directly provides
   connectivity to the Internet to one or more external sites. The
   connectivity provided extends beyond the transit provider's own site.
   A transit provider's site is directly connected to the sites for
   which it provides transit.

==> should be reworded to remove references to "transit provider is a
site" -concept, which is irrelevant and confusing in this context.

   A "multihomed" site is one with more than one transit provider.
   "Site-multihoming" is the practice of arranging a site to be
   multihomed.

==> this also needs rewording.  In general, the term "transit provider" 
is applied to network service providers which are in the middle of the 
packet forwarding chain.  I do not call first-hop upstream providers 
transit providers.  The term "transit" here is also misleading because 
it IMO points to the difference between "transit" and "peering", 
which do not apply to end-sites.

==> therefore, I think the last three terms could be reworded a bit.
(I might be able to try to help with some text if needed and folks agree.)

==> similar consideration wrt. "transit" applies to the rest of the 
document.

2) simplicity for the internet and/or the site should be made explicit.

3.1.5 Simplicity

   As any proposed multihoming solution must be deployed in real
   networks with real customers, simplicity is paramount. The current
   multihoming solution is quite straightforward to deploy and maintain.
   A new IPv6 multihoming proposal should not be substantially more
   complex to deploy and operate than current IPv4 multihoming
   practices.

==> there are two aspects to the simplicity, with two different axes: 
- simplicity to those who deploy it, and to those that don't
- simplicity to the Big Internet as a whole and the end-site itself

Solutions will probably not be simple for all of these; stating these 
explicitly will make the solution designers aware of different aspects of 
simplicity which should be considered.

3) there are a few especially worrisome goals.

3.1.2 Load Sharing

   By multihoming, a site should be able to distribute both inbound and
   outbound traffic between multiple transit providers.

3.1.3 Performance

   [...]

   A multihomed site should be able to distribute inbound traffic from
   particular multiple transit providers according to the particular
   address range within their site which is sourcing or sinking the
   traffic.

==> typically "inbound traffic balancing", especially as made a very
specific and detailed goal by "performance", go a long way in the "very
potentially unscalable" territory.

Therefore, I'd like to add some disclaimers or a few additional words to 
these goals -- but I don't know how and what in particular.

Anyone else worried?

4) document assumes the Internet transit/ISP architecture is a single 
administrative entity

3.1.8 Packet Filtering

   Multihoming solutions should not preclude filtering packets with
   forged or otherwise inappropriate source IP addresses at the
   administrative boundary of the multihomed site.

==> replace from the end (remove the period):

                                                 , or administrative
   boundaries between any transit providers in the Internet.

   (this is done to facilitate for the fact that the Internet is *not* just 
    a homogenous single routing blob -- "once you're in, you're in for good").

5) co-operation (non)goals are not explicit about third party ISP's and 
non-direct transit ISP's

3.2.6 Cooperation between Transit Providers

   A multihoming strategy may require cooperation between a site and its
   transit providers, but should not require cooperation (relating
   specifically to the multihomed site) directly between the transit
   providers.

==> particularly if the "transit provider" terminology is not redefined,
this needs to be very much clarified.  I believe the above text is used to
refer to the direct first-hop upstream providers of the site only.  It
should also say that co-operation with any of the site's transit providers
and any of their peers or transits should not be required ("no requirement
for third parties", here transit of the transit being a 2 1/2 party)



semi-editorial/substantial
--------------------------
For purposes of
   redundancy and load-sharing, the multihomed address blocks, which are
   almost always a longer prefix than the provider aggregate, are
   announced along with the larger, covering aggregate originated by the
   provider.

==> s/redundancy/redundancy, independence/

 This contributes to the rapidly-increasing size of the
   global routing table.

==> s/size/size and dynamicity/ (better word than dynamicity?!?!)

   By multihoming, a site should be able to distribute both inbound and
   outbound traffic between multiple transit providers. This requirement
   is for concurrent use of the multiple transit providers, not just the

==> s/requirement/goal/

3.2.2 Impact on Routers

   The solution may require changes to IPv6 router implementations, but

==> s/solution/solutions/ -- many more under section 3.2.x.  The text
seems to indicate that a single solution would fit the bill.

Normative References

==> references section should be numbered.

   [4]  Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
        Global Unicast Address Format", RFC 2374, July 1998.

==> this ref is no longer used in the body, and good riddance.  Remove.

   [7]  Huston, G., "Analyzing the Internet's BGP Routing Table",
        January 2001.

==> especially for a *normative reference*, the reference should IMO be 
much 
more explicit (e.g. refer to a publication and give a URL or the like).


editorial
---------
   site-multihoming

==>s/site-multihoming/site multihoming/ (everywhere) ?  This seems a more 
common practice..?

   providers may share a single conduit from the street into a building;
   in this case backhoe-fade of both circuits may be experienced due to

==> "backhoe-fade" ?  No idea what that means, and couldn't find it 
in a dictionary either.

   demonstrate that the modified name resolution system required to
   support them are readily deployable.

==> s/are/is/

   The multihoming solution may allow host or application changes if
   that would enhance session survivability.

==> s/session/transport-layer/ (to make a more explicit reference to 
the goal presented earlier)

   It should be posssible for staff responsible for the operation of a

==> s/posssible/possible/


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings