Frank,
Some feedback on a few of the Editor's notes section.
Search for RJS.
<snip>
3.7 Routing System Security
<snip>
Data Consistency
A router should be able to detect and recover from any data
that is received from other routers which is inconsistent.
That is, it MUST NOT be possible for data from two routers,
neither of which is malicious, to "break" a third router.
Editor's Note:
This is poorly worded. I'm trying to say that there
should be no otherwise good data that, when combined on
some other router, conspire to break that router or
routing in general. Good text desperately sought!
RJS: How about
A router must be able to detect, and should be able to recover from transitive
data inconsistencies. Good, valid data from 1 or more sources must not
be combined together with existing or received data to create a destabilizing
effect(for some value of destabilizing) . If a router is not able to recover, it
must not propagate the inconsitent data if the router is a propagator of control
information.
<snip>
3.9 Rich Policy
RJS: Perhaps some language differentiating policy specification from policy
implementation. The motivations you list under transit rules, business decisions
and load management may be examples of policy specifications, whereas the
items listed in examples of things "not policy" are eaxmples of tools/information
that one might use to effect the larger policy specification.
Are you attempting to say things like prefix x should follow
"the gold service path" or "traffic to prefix z or provider y should/should
not be constrained to a set of paths" ,without specifying the
mechanisms/tools/attributes that are used to effect that policy specification.
This section seems to indicate that you want to talk about policy at something
like an administrative domain level not at a box level, but seems to flop back
and forth between "systemic" things and box things.
Or were you trying to convey something completely different here ?
Editor's Note
I am unhappy with this section. I think it says what I
think I heard people say they think they want out of what
they think they call "policy" (!). But I, obviously, am
not sure. Also, I do not like the way the wording has
turned out, editorially. And I still feel that something
is "missing" (though I can't say what). Sigh.
Before setting out Policy requirements, we need to define the
term. Like "security", "policy" means many things to many
people. For our purposes, we define policy as
Policy is the administrative influences that alter the
criteria used in the path and next-hop selection procedures
of the routing software.
That is, policy is what drives the configuration information
that administrators enter into the system in order to change
what next hops, paths, and so on, the routing system chooses.
The main motivators for influencing path and next-hop selection
seem to be transit rules, business decisions and load
management.
The transit rules define for whom a given service provider will
carry traffic. Backbone networks tend to carry traffic going
to any destination in the Internet while access networks tend
to limit traffic to that going to or from their customers.
There are, of course, many other variants.
The business reasons for altering path selection are as varied
as the number of service providers. Some considerations are
NEED MORE ABOUT THE BUSINESS MODEL GLORP
1. Giving different routing information to different peers,
Kastenholz Informational -- Expires 2/2002 12
Inter-domain Routing Requirements August, 2001
2. Causing certain customers' traffic to take "special" routes
(e.g., a 'gold' customer's traffic might get shunted to a
special path)
Load Management is sometimes called traffic engineering today.
Some of the basic goals are
1. To prevent overloads (and to route around them when they
appear)
2. To prevent imbalances in traffic flows (eg, if there are two
otherwise equally valid paths, traffic should be relatively
balanced over them
3. To try and get outbound traffic off of a provider's network
as soon as possible (and to keep inbound traffic out of the
network for as long as possible). Of course, these are
conflicting goals in a multi-provider environment.
WHAT ELSE DO I PUT IN HERE?????????????????????????????
For the purposes of this note, "policy" does not does not cover
things that are local to a single router. We believe that
these are implementation issues. I NEED MORE DETAIL ON WHAT IS
"NOT" A POLICY HERE!!!!
The new Architecture must support rich policy mechanisms.
Furthermore, the policy definition and dissemination processes
should be separated from the network topology and connectivity
dissemination processes. Policy must inform and control the
generation of the forwarding table and the abstraction,
filtering, aggregation, and dissemination of topology
information.
The finest granularity of a policy is an IPv4/6 prefix. The
prefix could be the source prefix or the destination prefix.
Things that are explicitly outside the scope of Policy are:
o Protocol and port based functions,
o TOS/QOS/DiffServ related operations
o Per-host operations (i.e. /32s for IPv4 and /128s for
IPv6),
o Traffic matrices (e.g., traffic from prefix X and to
prefix Y).
RJS: An observation the description of traffic matrices seems to be in contradiction
to the statement "the finest granularity of a policy is an IPv4/6 prefix"
Did you mean to say hosts instead of prefix's in the traffic matrices
description or something else? Why are prefix's the finest units of
policy but traffic matrices between them are not policy ??
paraphrasing from your examples above...
Would "traffic from prefix X to prefix Y should be dropped" not be a
policy, but "all traffic to prefix Y should not use gold/special
paths" be a policy?
<snip>
3.10 Incremental Deployment
<snip>
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT