[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)
Tom,
please see inline:
Henderson, Thomas R wrote:
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.
- 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
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."
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.
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)?
- 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
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.
- we have MTID-0 reserved for default unicast topology, we felt
reserving one for base multicast topology would make sense
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."
- 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.
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).
- 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
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?
yes. The fact that the neighbor is sending us additional metrics is
harmless.
+---+---+---+---+---+---+---+---+
|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).
I'm fine with whatever name majority of people are happy with.
Section 6:
s/part of an area is upgrade/part of an area is upgraded/
will be fixed.
Peter
Tom