[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on requirements-05
On Tue, 6 May 2003, Joe Abley wrote:
> 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.
Indeed. However, the misleading names have often caused confusion at IETF
LC and IESG review time, from those who haven't read it properly.
However, IETF LC is not necessary for this document, and it states rather
clearly in the abstract that these are goals, not requirements -- so this
seems ~OK.
> > 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.
Typically "site" is considered to be an "end-site", in the transit
provider's case, the NOC of the transit provider. The backbone of the
transit provider, possibly spanning contininents, seems to stretch the
definition and the mental picture of a "site" pretty far.
> > 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.
I'm not sure if these are OK. In some cases in the document,
at least, it is important to refer to the upstreams of the first-hop
ISP's. With the current terminology, that's difficult.
Also, the text may be rather ambiguous as it doesn't seem to match the
common understanding of what "transit provider" typically is.
XXXX
> > 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.
There is a slight difference there, in my eyes.
The first item separates "multihomed site and its ISP(s) and possibly
their transits" and "everyone else".
The second item separates "multihoming end-site" and "everyone else
(including their ISPs)".
I was not sure how to reword that better, but I do believe there are
differences here.
> > 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.
Real world is not set in stone, the procedures can change. I fear we'll
fail if they don't, and we have an attitude "something is done like this,
so we must always be able to do the same thing, unchanged".
But..
> 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".
.. yes.
> > 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.
I feel it's important, but I'm willing to hear what others think.
> > 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"?
Let's try to illustrate:
Site S
/ \
ISP A -- ISP B
| |
Transit1 - Transit2 -- [ Internet ]
| \
[Internet] [Internet]
Co-operation is currently a goal with Site S <-> ISP A and Site S <-> ISP
B. It is not with ISP A <-> ISP B.
This doesn't take a stance on even more non-goal co-operation, with e.g.
- Site S <-> Transit1
- ISP A <-> Transit1
- ISP A <-> Transit2
- Site S <-> [Internet]
- ISP A <-> [Internet]
- Transit1 <-> [Internet]
> > 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.
There certainly is, if you can, and in practice do, take the portion of
the PA with you, to another provider. The text in the introduction does
not require the site to advertise the more specific from the behind the
direct ISP: as long as a covering aggregate (from somewhere else) exists,
you're fine.
But why do you then say:
the multihomed address blocks, which are
almost always a longer prefix than the provider aggregate,
==> there is no "coverage" if it is not a longer prefix.
In any case, the introduction is incomplete. Multihoming is also done
with PI addresses, without covering aggregates.
The introduction should be either modified to be a bit more descriptive
(or generic), or make a reference to the v4 multihoming draft (which would
require us to start working on it again) -- which should be there anyway,
at least as an informational ref.
> > This contributes to the rapidly-increasing size of the
> > global routing table.
> >
> > ==> s/size/size and dynamicity/ (better word than dynamicity?!?!)
>
> complexity?
Complexity is too generic a term unfortunately, it doesn't imply anything
about the advertise/withdraw cycles caused by site multihoming.
> > 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.
Nothing major but:
http://www.rfc-editor.org/policy.html
states "s. Normative References" and "s+1. Informative References".
> > 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
A bit too technical term, when a simpler, generally understandable way to
say something to the same effect might be 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