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

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 17 Apr 2005 07:56:47 -0700

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Apr 2005 12:11:56 +0200

Tom,

please see inline:

> Related to this, I don't quite understand what is meant by Section 4.4.

- sending of OSPF control packets is unchanged from RFC2328
- link being enabled/disabled in the default topology only affects what 
is being advertised by OSPF. It does not affect installation of 
connected routes to the RIB that corresponds to the default topology

> enable routing loops if configured incorrectly."

If some implementations give user such an option, that's fine.
I'm not sure though if we want to specify this in the draft, especially 
if we agree that such an option can cause routing loops.

> possibly multiple multicast topologies)?

- if the link is not advertised with the MTID-1 metric, then the link 
does not participate in the default multicast topology
- user can define multiple multicast topologies, there is no restriction
- RoutingExclusion bit relates to default unicast topology only, we will 
make that clear in the draft

> document how to map packets to MTs.

- we have MTID-0 reserved for default unicast topology, we felt 
reserving one for base multicast topology would make sense

> configuration MUST be consistently applied throughout the network."

- one can define various forwarding behaviors with different results. As 
you said implementation can provide a configurable forwarding behavior.
- what we specified in the draft was how OSPF should compute paths and 
populate topology specific RIB. I'm not sure the specification of how 
the forwarding entries in various RIBs/FIBs are used during the 
forwarding belongs to this draft.

> excluded (as was pointed out in a previous post).

- current behavior is consistent for all MTIDs (including MTID-0). If 
the MTID metric is not advertised, link/prefix does not participate in 
the given topology
- 0xFFFF is a valid metric in RFC232, so we can not use it to signal 
unreachability. Defining 0xFFFF as unreachable metric for MTID-0 only 
would be ugly
- with your proposal, you would have to look for two metrics during SPF 
as you process each link (TOS 0 and MTID-0) to be able to behave correctly
- with your proposal, ambiguity problem still exist, just has been moved 
to a different case

> peer is MT capable, other than seeing MT metrics show up in the LSAs.

yes. The fact that the neighbor is sending us additional metrics is 
harmless.

> DE (DefaultExclusionCapability).

I'm fine with whatever name majority of people are happy with.

> s/part of an area is upgrade/part of an area is upgraded/

will be fixed.

Peter

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 18 Apr 2005 20:06:15 +0000

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

>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