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

Peter, thanks for your replies.  I'll reply to the points that Tony
brought up separately.  Please see below: 
 
> > 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

I don't think that the existing text is saying the above bullets, or at
least, it is possible to interpet it differently (as I apparently did).

Is the following what you want to say?
"Sending of OSPF control packets is unchanged from RFC2328, except in
the case of sending OSPF packets across virtual links, in which case the
intra-area path of the virtual link MUST only be composed of links on
the default topology, and OSPF control packets being forwarded MUST be
forwarded using the default topology."

If so, I would suggest changing 3.3 to the above, and removing 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."
> 
> 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.
> 

(reply in another message)

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

OK, with the clarification, I am fine with reserving the value.

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

(reply in another message)

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

OK, can leave this as is for consistency's sake.

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

I don't know how to sense the majority consensus.  Would you agree that
Default Exclusion Capability would be more precise?  The way that it is
named and defined does not hint very well at what it is functionally
doing:

>    MTRoutingExclusionCapability
>      This is a configurable parameter that will be used to facilitate
>      the introduction of MT routers in an area and ensure backward
>      compatibility.

vs.
     DefaultExclusionCapability
       This configurable parameter, if enabled, enforces that all
adjacent neighboring routers have the same capability enabled, such that
the default topology can be disabled on a link without causing backward
compatability problems.

Tom