Sorry for the delayed response, this one got lost in
my inbox...
At 10:00 PM 3/14/02 -0500, Dmitri Krioukov wrote:
>1. Sections 3.4, 3.5, and 3.11...
>
>...seem to be very close to each other. Can they be
>packed into a single section (or become subsections
>in such a section) on the denser connectivity mesh?
I'll at least move them all so that they are
adjacent. They are all different parts of the
same, fundamental, issue - as you point out.
I wish to keep them separate sections or
subsections because they represent some of
the more common failures in proposed routing
and addressing architectures. Quite often,
solutions start with a statement of the
form "If we structure the network _this_
way..."
>3. Section 3.7
>
>I have concerns with this portion:
>--
> When the routers are on point-to-point links, with routers
> at each end, there is no need to encrypt the routing
> protocol traffic; there is no possibility of a third party
> intercepting the traffic, and if one of the two routers are
> compromised then it doesn't matter.
>--
>Only when you hold a *physical* point-to-point link in
>you *physical* hands, you can be sure that there is no
>possibility of traffic getting intercepted. Even worse,
>with certain types of links (emanating electro-magnetic
>waves), even this "special handling" is not a guarantee.
>So that you cannot say that there is no need for encryption
>on point-to-point links (especially when they pass through all
>the wonders of a circuit provider).
Yeah, this was brought up by someone else too. I'll
update the section accordingly.
>4. Section 3.9
>
>I think there is a better way to approach policy, and that
>would be more consistent with Section 3.2, which I like.
>
>I'd define policy to be one of (many possible) *external
>constraint* subsystems. Namely, if we want to have a
>separable topology component producing "natural" routing,
>then we need to be able to support *various* components
>of external constraints (to this "natural" routing), what
>many people call "policy routing" today being just an example.
That is one of the things we were trying to say. I'll
work through the document and try to make it a bit
clearer.
>This would be more consistent with the data network routing
>theoretical framework. Plus, this would leave more space for
>the "policy routing vs. traffic engineering" discussion.
That's the idea of the component model for an architecture.
If you want to make a new frotz, you pull out the old one
and plug in the new one. You do not have to go and rebuild
the entire architecture...
>5. Section 3.9.1
>
>While the authors criticize GroupB's draft as too BGP-centric,
>some portions of GroupA's draft become even more BGP-centric
>as the draft version increases... :))
Yeah, well, policy is something that, unfortunately, is
intimately tied in with BGP today. I've been trying
for probably a year now to come up with a "protocol neutral"
way of describing it. That is, trying to describe policy
in terms of what the network operators' desired effects are,
not what tools the use.
The draft is my best shot.
>6. Section 3.9.2
>
>Examples here are suspiciously close to what a great portion
>of those N people from Section 4.2 would call "pure TE",
>whereas Section 4.2 is non-requirement. Quite confusing, I
>think :)
This is partly a technical issue, partly a psychological
one. We intended to figure out what the problems were that
people were trying to solve with TE and then said "solve
these problems". The current TE tools could be used to solve
the problems, or a clever person might invent new, presumably
better, tools. However, if we said "must do traffic engineering"
then the requirements document might unnecessarily limit the
scope of possible solutions to just what is currently in
vogue in the TE world.
>7. Section 3.10
>
>What does that mean to "squeeze out the old architecture"?
>My assumption is that there may be great portions of network
>that would never have to be "touched", -- especially if the
>"Hypernet" deployment scenario takes place.
Well, the idea we were trying to get across is that
there can be no single changeover time. We believe
that the likely scenario for deployment will be
that a number of ISPs will start localized trials
of "the new architecture", the areas 'under the control'
of the new architecture will slowly grow, and eventually
the areas of the different ISPs will touch. And yes,
there may be areas that never get "fully converted" over
to the new architecture (which we missed and I'll add text
to cover this case).
But the important points that we were trying to get across
are
1) No single flag day for converting over and
2) Lots of independent deployments which will, at some time,
have to merge together.
The architecture will have to take these two issues into account.
(I'll try wording the section better.)
>9. Section 3.17
>
>So, what is more important: human understanding or efficient
>code? At the algorithmic level, for example, simpler algorithm
>(from the point of view of a human) does not always allow for
>simpler (less lines of code) implementation (even more so
>for efficiency of the algorithm).
Two comments
First, to a degree, human understanding is more important
than efficient code. One of the big problems we have today
is that the entire routing system is very very complex.
Things happen and we don't always quite know why (or, once
things are working, we don't change them, for fear of the
unknown consequences). Efficient code is nice, but not
important if the people using it don't understand the
system as a whole.
Second, algorithms are different than the architectural
concepts of the system. There is an engineering step
that happens when some beautiful, elegant, bit of
architecture ends up in some nasty, ugly, horrific,
piece of implementation. Then you have to decide "keep
the ugly implementation or sacrifice the elegant bit of
architecture".
>10. Section 3.19
>
>In addition to comments already made on this section, --
>what do authors understand under "IP" here? Based on the
>last paragraph of Section 3.15, one may (erroneously???)
>conclude that "IP" is a synonym for packet switching...
>
>And after all, MUST or MUST NOT "IP" be "agnostic" with
>respect to any "routing" or "topology" at the "sub-IP"
>"layers"? (especially when "IP" "routing" "wishes"
>not to be "agnostic":) (that is, the last paragraph
>seems to be inconsistent with the first one).
For example,
One could postulate an architecture built over
ATM and the method of operation is to establish
an SVC between the source node and destination
node when the source tries to send something.
In this architecture, all topolgy decisions,
path-selection decisions, policy decisions,
and so on are delegated to ATM and IP
routing becomes null. We are saying that
this is not allowed. The routing and addressing
architecture must allow for as wide a variety
of media as possible, and therefore cannot
demand that the lower layers provide particular
routing/topology/policy/... services.
>11 Section 5
>
>...does not reflect the current state of the GroupA drafts.
May well be, will check things out.
Thanks for your comments.
Frank Kastenholz
==================================================
My preferrred signature is:
This information is for the sole use of
whoever receives it and may contain confusing,
enlightening, enraging, entertaining,
irritating, or just plain stupid information,
including without limitation, double-secret-
probation information belonging to [CENSORED
BY THE NSA/FBI/MOUSE]. Any unauthorized review,
use, disclosure, or distribution outside of an
establishment serving alchohol is prohibited on
days that do not end in Y.
But our ******'d lawyers would rather have:
=======================================
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT