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

["Henderson, Thomas R" <thomas.r.henderson at BOEING.COM>]

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

Section 1:
I agree with previous posters that a) some brief justification of why MT
is being resurrected would be helpful in the introduction, as well as b)
some text clearly distinguishing the differences between MT and 1583 TOS
based routing.

Section 3.3:   
>   OSPF control packets MUST be sent over the default topology.

This is still not clear to me what happens with e.g., Hellos when the
link is enabled for some MT-ID but disabled for the default topology.
Related to this, I don't quite understand what is meant by Section 4.4.

Section 3.6:
> Each nexthop computed during the MT SPF MUST belong to the same MT.

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."

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.

Therefore, I suggest the following additional paragraph in 3.8, adapting
the language from 1583 Section 2.4:

"It may be the case that no path exists for some MT-ID, even if the
router is calculating paths for that specific MT-ID.  In that case,
depending on the configuration of that MT-ID, packets mapping to that
MT-ID are either routed along the default topology or are dropped.  Such
configuration MUST be consistently applied throughout the network."

Section 4.1:
>   The link exclusion capability requires routers to ignore TOS0
metrics in
>   Router-LSAs in the default topology and to alternately use the
>   MT-ID#0 metric to advertise the metric associated with the default
>   topology.

Assuming that excluding links from the default would be the exception,
not the common case, it would be more efficient to code this inversely
as to how it is specified  (links "opt out" of default rather than "opt
in").  For example, if MT-ID 0 is present for a link, has a metric of
0xFFFF, and the MT-bit is set in the area, then such link is excluded
from default topology.  Note that this would also clear up the ambiguity
as to what to put into the TOS 0 field when the default is being
excluded (as was pointed out in a previous post).

>     The unused T-bit is defined as the MT-bit in the option field in
>     order to  assure that a multi-topology link-excluding capable
router
>     will only form an adjacency with another similarly configured
router.

Previously this bit was used to declare that TOS routing was in effect.
Now, there is no such bit.  If the MTRoutingExclusionCapability is
disabled, then there seems to be no way for a router to tell whether its
peer is MT capable, other than seeing MT metrics show up in the LSAs.
Is this intended?

>           +---+---+---+---+---+---+---+---+
>           |DN |O  |DC |EA |NP |MC |E  |MT |
>           +---+---+---+---+---+---+---+---+
>
>       MT-bit: This bit MUST be set in the Hello packet only if
>               MTRoutingExclusionCapability is enabled (see Section
4.2)

The MTRoutingExclusionCapability name seems like a misnomer to me.  It
sounds from the name like it excludes the MT routing capability, when in
fact, it is referring to Default Routing Exclusion.  Suggest change to
DE (DefaultExclusionCapability).

Section 6:
s/part of an area is upgrade/part of an area is upgraded/

Tom