The MPLS WG Archive

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

A phone call from Yakov in response to my original message has highlighted
two points I didn't cover; one an assumption that I didn't clearly state,
and the other an important corollary I didn't pick up on. Here they are.


    > In the optical case, we have an *additional* constraint, which is
    > that even if people *outside* the optical part *did* have a full map,
    > they wouldn't necessarily be able to use it - because finding optical
    > paths is a process that has unusual constraints.

I'm making an unstated assumption here, one that I'll now put openly.

To begin with, my (limited :-) understanding of optical constraints is that
they fall into two classes; i) constraints associated with a particular
toplogy element (e.g. some OXC's can only switch in groups of lambdas), and
ii) constraints which are related to a path, rather than a particular
topology elements (e.g. total loss of signal strangth over a path).

(The difference is important because they are supported very differently by
the routing mechanism: the first kind one would typically see advertised as
attributes of the appropriate topology element; the second kind are ones
that the path-selection algorithm has to have built in.)

Now, the important issue in finding paths which meet optical constraints is
not whether you are 'inside' or 'outside', but *whether you understand
these constraints*! If you do understand them, then you can select paths
yourself, and it doesn't matter whether you are inside or outside.

In my original comment above, I was assuming that these special constraints
of the optical network were not understood by path-selection agents outside
the optical part of the mesh. Obviously, if that assumption is not true,
then the conclusions I drew from it (that "you're forced to produce a model
of the connectivity across [the optical] part of the connectivity graph")
don't happen.


    > Obviously, in a real network, everyone can't have a full graph of the
    > network. So you *have* to produce simplified representations - and
    > accept that some paths are going to be non-optimal. In other words,
    > you have to trade-off two kinds of overhead: routing overhead ..
    > and non-optimal paths. ...
    > you're forced to produce a model of the connectivity across that part
    > of the connectivity graph; i.e. select a set of paths, and advertise
    > that set of paths as the connectivity graph which is a virtual
    > representation of the connectivity of that part of the network.

I missed something important here.

I implied that bounding the overhead cost of the routing is the principal
reason why one would do an abstraction (with its attendant costs in
obscuring useful paths). However, I missed something important, something
connected to something I said below:

    > the problem will be easier to tackle in a system which uses a uniform
    > routing system at both the local and higher layers. Whatever
    > information flow you *do* decide to do (i.e. whatever virtual
    > representation of the local topology you do decide to propogate out
    > to the higher layer), you will have more flexibility in doing so if
    > the two are using the same routing system.

Sometimes you *don't want* to do an abstraction. However, when one is using
separate routing systems for 'inside' and 'outside', there's often *no way* to
provide the 'real' map - and you wind up providing an abstraction, whether you
like it or not. (I.e. the tradeoff you would prefer, between the two kinds of
overhead above, is to pay the routing cost, and not lose any potential paths.)

So there are real-world circumstances (driven by what tools exist) where one
winds up doing abstraction - but not because one has any fundamental need or
desire to (because of the inevitable costs of abstraction), but only because
that's the only choice the current technology gives you.

However, e.g. use of separate control planes for 'inside' and 'outside' has
basically made it impossible to do anything *but* provide an abstraction. And
that abstraction is usually one that has negative effects on the routing - N^2
links, or extra hops, or whatever.


(Now that I think about it, I guess this actually does fall under the
general statement that:

    > Whatever information flow you *do* decide to do (i.e. whatever virtual
    > representation of the local topology you do decide to propogate out
    > to the higher layer), you will have more flexibility in doing so if
    > the two are using the same routing system.

but I guess it's not necessarily immediately obvious, from this generic
statement, that this particular problem is an example of "[less]
flexibility"!)

	Noel