[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on requirements-05

Hi,

On Tuesday, May 6, 2003, at 17:11 Canada/Eastern, Pekka Savola wrote:


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.
I don't think it's worth changing the name; if we do that we lose the version control of the document since we have to start again as -00. The name of the draft will become largely irrelevant if it is published as an RFC.

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.
Please explain.


   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.
When I originally put forward these definitions, it was because lots of different people had widely differing opinions about what exactly the terms "transit", "site", "network", etc meant. It was not possible to produce definitions that suited the meanings entrenched in everybody's heads, so I settled on a set that seemed to work for the majority of people.

[The reason these definitions are there at all is to disambiguate the document, given the differing opinions of those terms].

I would prefer to leave those definitions alone, unless there are concepts which need to be understood in the text of the draft which are not accommodated by the definitions that are there.

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
I don't see those as orthogonal; your second line looks to me like a rewording of the first line (taking the Big Internet to be a collection of people who do and don't deploy multihoming). Perhaps you could explain that further.

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?
These two particular requirements (when they were being called requirements) were discussed at some length on this list. The reason they were in the document was that they are capabilities which are widely used by sites which multi-home today, and any replacement multihoming strategy probably needs to support them if it is going to be adopted by people in the real world.

The concern people had about whether any single solution would meet all of these requirements was what led us to replace the "requirements" word with "goals".

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").
I'm not sure that additional sentiment is required, but I wouldn't object to it going in.

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.
Your interpretation is correct. I think this is implicit in the way that "transit provider" is currently defined (it says "A transit provider's site is directly connected to the sites for which it provides transit.").

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)
I'm not sure what you're intending to say here; co-operation between whom and any of the site's transit providers? Who is "their" in "their peers or transits"?

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/
No, I don't think there's any "independence" rationale there; these are covered prefixes describing PA assignments, not announcements of PI space.

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

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

complexity?
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/
Good catch.


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.

Fair enough.


Normative References

==> references section should be numbered.
It will do what xml2rfc decides is right. Unless there is tremendous breakage in xml2rfc's output (in which case let's tell Dr Rose) I'm inclined to leave these bits as they are.

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

Good catch.


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

I will find an URL.
editorial
---------
site-multihoming

==>s/site-multihoming/site multihoming/ (everywhere) ? This seems a more
common practice..?
I have no opinion on this.
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.
http://www.net.oregonstate.edu/netvideo/dugout.html


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

==> s/are/is/

Good catch,


   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)

Good catch, and...


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

==> s/posssible/possible/

Good catch. Thanks :)


Joe