Re: comments on requirements-05

[Brian E Carpenter <brian@hursley.ibm.com>]

Harold, this sort of issue is exactly why we agreed to convert it from
a requirements document into a simple list of goals. Personally, I'd
like to see it out as an RFC as soon as Joe has tweaked it for the
latest round of comments, so that we can all use it as a thinking aid
when analysing specific proposals. There is nothing to be gained by
trying to make a list of goals perfect or watertight, and I see no
harm in some of the goals being manifestly subjective. It's time to
move on from this document.

   Brian

"Grovesteen, Harold" wrote:
> 
> Requirements/goals which are subjective and arbitrary should be avoided.
> "Simplicity" is subjective.  How is something determined to be simple or
> not?  Simplicity is in the eye of the beholder.  Some things are simple by
> nature others are not.  Whatever architecture is developed here may or may
> not be simple and that depends upon who looks at it.
> 
> The entire set of goals about traffic engineering are arbitrary.
> Organizations engineer traffic for totally non-technical reasons which can
> be neither anticipated nor guaranteed architecturally because they tend to
> be capabilities offered by specific implementations.
> 
> We can not seem to agree on basic functionality or requirements that truly
> are such. Subjective and arbitrary goals simply muddy the waters.
> 
> Of course, since everything is "should" or "should not," I am not sure that
> any content has real value.  It can always be argued that although something
> only should or should not be there no requirement actually exists.  I am
> hoping Vienna will sort some of these issues out and provide a clear
> direction which may make the "requirement" document somewhat moot.
> 
> Harold Grovesteen
> 
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Tuesday, May 06, 2003 4:11 PM
> To: Kurt Erik Lindqvist
> Cc: Joe Abley; multi6@ops.ietf.org
> Subject: comments on requirements-05
> 
> 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