[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working Group Last Call on "Multi-Topology (MT) Routing in OSPF" (draft-ietf-ospf-mt-03.txt)

Henderson, Thomas R wrote:

I took a fresh read of this and have the following comments:




We (and at least one other implementer that I know of) have implemented
an option that allows for this rule to be relaxed in special cases in
which not all routers are upgraded simultaneously.  The concern is that
there may be a router somewhere in the area that can not be upgraded
immediately, but is in a particular upstream location such that i) its
lack of support for MT is blocking the effective use of MT downstream,
and ii) the use of its default links as surrogates for MT links would
not cause routing loops.  It is therefore possible to implement a
variant that mixes MT links and default links in the SPF computation, if
a fully MT path does not exist.

I propose that Section 3.6 remain as it is (because I believe that it is
important to enforce the above statement for the common case), but in
the transition section (Section 6), I suggest the following new
paragraph be inserted at the end:

"The above specification of MT routing does not allow for forwarding
paths to be constructed with a mix of MT links and default links, in
such cases for which a fully MT path does not exist. For the purpose of
transition, it is possible to implement an option that relaxes the
constraint that all links in an MT path only use MT links. Such an
option, if used, MUST be applied consistently for a given MT in a
routing domain (so that consistent forwarding decisions are made), and
SHOULD be used with caution by operators because of its potential to
enable routing loops if configured incorrectly."


There is a _lot_ of looping potential here from experience. I am not clear
first which scenario you are pursuing. Either

1) all routers are MT aware in the deployment, then why don't you just add the necessary links to the
desired MT topology and you don't need any such hacks.
2) If you desire to have some routers being non-MT capable, unless you give
an exact algebra (or worded more simply, rules) that the operators must follow to avoid the
loops you allure to, how is he supposed to know how to deploy your hack ?
As well, you have to precisely specify the SPF algorithm you're using ?
Otherwise I think including anything like that in the spec is an accident
waiting to happen in terms both of interoperability and practical deployment.


Section 3.7:


1 - Reserved for advertising the metric associated with the
default multicast topology



Does something more need to be said about multicast than just this brief
statement? If MT-1 is not there, is the link invisible from multicast
perspective? Or does it depend on the RoutingExclusion bit? Should it
even be constrained in this manner (i.e., might I want to define
possibly multiple multicast topologies)? 

I would suggest to leave out MT-1 definition, since it is otherwise
stated (e.g., Section 3.8) that it is outside of the scope of the
document how to map packets to MTs.

Section 3.8 (Forwarding in MT):
The specification is ambiguous as to how to treat packets that a) map to
a defined MT in the area, but b) do not have a path to the desired
prefix in the MT topology, yet do have a default path there. In the
1583 TOS routing, such packets would fall back to the default topology.


I would recommend that such behavior be preserved here, because it is
more robust, especially in light of the new capability to exclude links
from the default topology if so desired. In fact, it should be possible
to define the behavior as an option; i.e., one could configure a
particular MT-ID to either fallback to default or not.


MT is _not_ TOS routing (any claim as to that is made purely to generate confusion IMO).
MT is a solution to generate multiple, _independent_ topologies in the same
routing protocol and not a 'special-capability link' vs. 'general-link' solution.
Simply forwarding along the default path
if a link lacks a MT metric will lead to routing loops very easily. Example:

+------ #0/1 ----------------------->C
| ^
v |
A <-- #1/10 ---> B <---#0/10---------+
^ ^ | |
+-----#0/1-------+


(where #1/X denotes link in topology 1 with metric X, assume all links
bidirectional with same metric, A, B and C all understand MT). If A
forwards to B in topology #1 but B forwards along the shortest 'default' path you'll have a
persistent loop. Now start to imagine what will happen if you start to deal
with subset of routers that do not understand MT on the way.

I would strongly suggest to leave anything out as to general fallback-default-topology
forwarding from the spec (you're free of course attempting any little
private hack you can get people to pick up) unless the implications
and algorithms are very tightly written down
(as footnote: there exists an algebra [and algorithm] that deals with
this problem precisely [i.e. default topology being a subset of the MT topology]
but it delivers non-obvious results, especially the Bellman-suboptimality
doesn't hold [i.e. the resulting set of shortest-paths is not a tree] which
is enough to make most people heads spin and decide they don't care about
this problem all THAT much)

   -- tony