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

Tony, replies inline below. 

> -----Original Message-----
> From: Tony Przygienda [mailto:prz at XEBEO.COM] 
> Sent: Monday, April 18, 2005 1:06 PM
> To: OSPF at PEACH.EASE.LSOFT.COM
> Subject: Re: Working Group Last Call on "Multi-Topology (MT) 
> Routing in OSPF" (draft-ietf-ospf-mt-03.txt)
> 
> >
> >"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 ?

I had in mind #2-- a specific scenario customer for which
i) it is operationally difficult to upgrade all routers to MT in same
timeframe
ii) one or two routers at key points (e.g. network border) are blocking
the effective use of MT
iii) by inspection of the topology, loops are avoided

I agree that the above is a hack and is dangerous in general.  Because
of that, I will concede that it may be best to leave out of the spec,
and treat it as a hack.

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

I am not saying (here) to mix and match default and MT links-- clearly,
that can lead to loops.  Instead, in your example, if A forwards to B in
topology #1, it can only do so if the remainder of the path from B to
the destination exists in topology #1-- the packet does not (must not)
jump out of this topology downstream.  If A doesn't have the end-to-end
MT path, A will choose the default topology, and B will likewise do
so... until (if the case arises) the MT topology does exist to the last
hop, in which case the packet can be sucked into the MT topology.

To be clear, the two use cases that I have in mind are that i) every
router does not necessarily need to enumerate MT-ID for every link in
the topology, or ii) not every router is MT capable.

> Now start to imagine what will happen if you 
> start to deal with subset of routers that do not understand 
> MT on the way.

Consider packets that have been traversing a set of non-MT routers, and
then suddenly hit an intermediate patch of MT routers (not contiguously
connecting to the last hop) for which the packet matches an MT.  What
should be done with such packets?  They cannot be routed to the
destination on an MT topology exclusively.  Should they be dropped?
Maybe, but I would argue that an operator may instead want them to fall
back to the default topology in this case.

That is, while MTR is not TOS routing, 1583 TOS forwarding behavior
should not be precluded (or mandated either-- it should be configurable
option).

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

This I would argue is not a hack, but affects how gradual deployment can
behave.


Returning to a point that Peter made:

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

If you want to take the stance that forwarding is out of scope of the
draft (that it only deals with how to build MT RIB-- not how to convert
that RIB into a FIB), then I would suggest that the wording in 3.8 be
tweaked, because it is making statements about how forwarding works that
preclude the forwarding behavior described above.  

New suggestion:

"This document describes how multiple topologies can be built in OSPF's
routing information base.  It is outside of the scope of this document
to describe how these routes are mapped to forwarding rules.  It is also
outside of the scope of this document to consider different methods of
associating an incoming packet to a corresponding topology.  User
configuration MUST be consistently applied in a network to avoid
incorrect forwarding behavior."

Tom