From euan.harris at cl.cam.ac.uk  Thu Jan  4 12:14:10 2007
From: euan.harris at cl.cam.ac.uk (Euan Harris)
Date: Thu, 4 Jan 2007 20:14:10 +0000
Subject: [Xorp-hackers] BGP Minimum Route Advertisement Interval
Message-ID: <64C87F56-0193-4707-9116-F1037337EAC7@cl.cam.ac.uk>

Hi,

I'm working on a project with Xorp and Quagga and have recently been  
looking at the effect of the minimum route advertisement interval  
(MRAI).   Since Xorp doesn't seem to support MRAI I've had a go at  
implementing it.   I've attached a patch against the 1.3 release -  
apply with patch -p 1.   I'm looking forward to your comments or  
suggestions!

SUMMARY

I've added a new route table, called MraiTable, which goes in the  
central plumbing between the aggregation table and the fanout  
table.   MraiTable delays add, replace and delete messages coming  
from the decision tables upstream, stores them up and sends them on  
to the fanout table when a timer goes off.    It's a bit like using a  
latch to synchronise the output of an asynchronous electronic  
circuit.   The overall effect is not quite to the letter of the RFC  
but is similar to the behaviour of Quagga and Cisco - from the  
outside it looks like the router recomputes the world and pushes new  
routes every MRAI seconds.

If MraiTable receives several route messages for a given prefix  
between timer ticks, it aggregates them according to the following  
rules, so that when the timer ticks at most one message per route  
will be sent downstream:

	add x, add ? -> error
	add x, replace x y -> add y
	add x, delete x -> do nothing

	replace x y, add ? -> error
	replace x y, replace y z -> replace x z
	replace x y, delete y -> delete x

	delete x, add x -> do nothing
	delete x, add y -> replace x y
	delete x, replace x ? -> error
	delete x, delete x -> error

(all messages are for the same prefix;  x and y are routes; ? is any  
route)

By adding the table after the decision processes but before the  
fanout table I should only have to deal with a well formed stream of  
updates - i.e. MraiTable should never actually see two adds for the  
same prefix.

IMPLEMENTATION

MraiTable is a subclass of BGPRouteTable.   I made some small changes  
to plumbing.cc to plumb it in between the aggregation table and the  
fanout table;  apart from that all the other changes are in  
MraiTable.cc and MraiTable.hh.    I've also added and XRL interface  
to set the MRAI from xorpsh - set protocols bgp mrai <int> from  
configure mode.

Within MraiTable, delayed messages are stored as MraiCachedMessage  
objects in a RefTrie.   There are three subclasses of  
MraiCachedMessage, for Add, Replace and Delete messages.   Each  
subclass knows how to combine itself with an incoming message  
according to the rules above, so for instance calling  
merge_with_replace_message with message Y on an MraiCachedAddMessage  
containing message X will return a new MraiCachedAddMessage  
containing message Y.   If the result of the merge is to do nothing,  
the merge method returns NULL and the route's record is removed from  
the RefTrie.

Each CachedMessage subclass knows how to apply itself to the next  
table.   When the timer goes off, we iterate through all the cached  
messages calling apply_self_to_table with the next table in the  
plumbing as an argument.   For cached adds and deletes this method  
just calls the relevant method on the downstream table.   For cached  
replace messages, it has to consider whether the peer advertising the  
route has changed;  if so it calls delete followed by add, otherwise  
it can call replace directly.

The timer callback registers itself as a one-shot timer on the BGP  
master's event loop.  On every tick it reschedules itself, with some  
jitter.

STATUS AND QUESTIONS

I've tested this code in a simple EBGP clique topology, with no route  
filtering.   It seems to do the right thing in this context and  
doesn't crash, but it may be that it doesn't handle some other  
configuration that I haven't tried.  Please let me know if you think  
of one, or if you try it out and find a bug.

It almost certainly leaks memory.  I'm a C++ newbie and usually code  
in languages with garbage collection.   Any, umm, pointers on my  
memory management would be appreciated! ;-P

I've had some problems running the bootstrap script on my Ubuntu  
Dapper machine.   Automake bails with errors like "automake: pim/ 
Makefile.am: not supported: source file `$(top_srcdir)/rib/ 
redist_xrl.hh' is in subdirectory".   There are also warnings from  
autoheader.   Since I'm only adding a couple of files I updated the  
Makefile manually;  I hope it works better for you on FreeBSD!

I'm looking forward to your comments! :-)

Thanks,
Euan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mrai.patch.gz
Type: application/x-gzip
Size: 9127 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070104/48599807/attachment.gz 
-------------- next part --------------


From atanu at ICSI.Berkeley.EDU  Fri Jan  5 18:32:50 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 05 Jan 2007 18:32:50 -0800
Subject: [Xorp-hackers] BGP Minimum Route Advertisement Interval
In-Reply-To: Message from Euan Harris <euan.harris@cl.cam.ac.uk> of "Thu,
	04 Jan 2007 20:14:10 GMT."
	<64C87F56-0193-4707-9116-F1037337EAC7@cl.cam.ac.uk> 
Message-ID: <77165.1168050770@tigger.icir.org>

Hi,

The MRAI code seems to have been correctly introduced but I have a
number of concerns.

The XORP BGP is event driven, an incoming route is typically processed
to completion. Other implementations have adopted a route scanner
approach which fits better with the concept of MRAI, where an artifact
of the implementation introduces a delay. Figure 13 in
<http://www.xorp.org/papers/xorp-nsdi.pdf> demonstrates the issue
nicely, XORP and MRTD don't introduce a delay, whereas Quagga and Cisco
do. We have never implemented MRAI in XORP because as RFC 4271 states to
implement it correctly would require a timer per destination, although
the RFC goes on to state that other techniques are acceptable.

The RFC states that the timer for internal peer should be shorter than
for external peers, it recommends five and thirty seconds
respectively. With the current placement of the MraiTable both peerings
will be treated the same. We have for a while been considering having
two fanout tables one for I-BGP and another for E-BGP. If we make this
change then two instances of the MraiTable table should solve this
problem.

As far as I can tell when the timer fires all the queued routes are sent
in a single loop. The default timer value, as recommended, is thirty
seconds a lot of routes could get queued in that time. We don't use
threads in XORP, so a single event such as a timer firing should not
take too much time. The clock() method should send a few routes and then
schedule a background task (eventloop().new_task()).

I wonder if it would be better to call this setting out-delay (Juniper's
name) rather than MRAI as what it seems to be doing is delaying all
routes until the timer fires, turning an event driven implementation
into a scanning implementation:-).

If the default setting for out-delay/mrai was zero and no resources are
consumed then we could consider adopting this code.

The transition from a non zero to a zero value out-delay should also
work correctly.

At the moment if the out-delay value is set to thirty seconds then an
update is delayed by zero to thirty seconds depending on when the update
arrives. It would be good if the incoming routes were stored such that
they are all delayed by thirty seconds. Perhaps by having the timer fire
every second and sending the oldest routes.

	Atanu.

>>>>> "Euan" == Euan Harris <euan.harris at cl.cam.ac.uk> writes:

    Euan> Hi,
    Euan> I'm working on a project with Xorp and Quagga and have recently been
    Euan> looking at the effect of the minimum route advertisement interval
    Euan> (MRAI).   Since Xorp doesn't seem to support MRAI I've had a go at
    Euan> implementing it.   I've attached a patch against the 1.3 release -
    Euan> apply with patch -p 1.   I'm looking forward to your comments or
    Euan> suggestions!

    Euan> SUMMARY

    Euan> I've added a new route table, called MraiTable, which goes in the
    Euan> central plumbing between the aggregation table and the fanout  table.
    Euan> MraiTable delays add, replace and delete messages coming  from the
    Euan> decision tables upstream, stores them up and sends them on  to the
    Euan> fanout table when a timer goes off.    It's a bit like using a  latch
    Euan> to synchronise the output of an asynchronous electronic  circuit.
    Euan> The overall effect is not quite to the letter of the RFC  but is
    Euan> similar to the behaviour of Quagga and Cisco - from the  outside it
    Euan> looks like the router recomputes the world and pushes new  routes
    Euan> every MRAI seconds.

    Euan> If MraiTable receives several route messages for a given prefix
    Euan> between timer ticks, it aggregates them according to the following
    Euan> rules, so that when the timer ticks at most one message per route
    Euan> will be sent downstream:

    Euan> 	add x, add ? -> error
    Euan> 	add x, replace x y -> add y
    Euan> 	add x, delete x -> do nothing

    Euan> 	replace x y, add ? -> error
    Euan> 	replace x y, replace y z -> replace x z
    Euan> 	replace x y, delete y -> delete x

    Euan> 	delete x, add x -> do nothing
    Euan> 	delete x, add y -> replace x y
    Euan> 	delete x, replace x ? -> error
    Euan> 	delete x, delete x -> error

    Euan> (all messages are for the same prefix;  x and y are routes; ? is any
    Euan> route)

    Euan> By adding the table after the decision processes but before the
    Euan> fanout table I should only have to deal with a well formed stream of
    Euan> updates - i.e. MraiTable should never actually see two adds for the
    Euan> same prefix.

    Euan> IMPLEMENTATION

    Euan> MraiTable is a subclass of BGPRouteTable.   I made some small changes
    Euan> to plumbing.cc to plumb it in between the aggregation table and the
    Euan> fanout table;  apart from that all the other changes are in
    Euan> MraiTable.cc and MraiTable.hh.    I've also added and XRL interface
    Euan> to set the MRAI from xorpsh - set protocols bgp mrai <int> from
    Euan> configure mode.

    Euan> Within MraiTable, delayed messages are stored as MraiCachedMessage
    Euan> objects in a RefTrie.   There are three subclasses of
    Euan> MraiCachedMessage, for Add, Replace and Delete messages.   Each
    Euan> subclass knows how to combine itself with an incoming message
    Euan> according to the rules above, so for instance calling
    Euan> merge_with_replace_message with message Y on an MraiCachedAddMessage
    Euan> containing message X will return a new MraiCachedAddMessage
    Euan> containing message Y.   If the result of the merge is to do nothing,
    Euan> the merge method returns NULL and the route's record is removed from
    Euan> the RefTrie.

    Euan> Each CachedMessage subclass knows how to apply itself to the next
    Euan> table.   When the timer goes off, we iterate through all the cached
    Euan> messages calling apply_self_to_table with the next table in the
    Euan> plumbing as an argument.   For cached adds and deletes this method
    Euan> just calls the relevant method on the downstream table.   For cached
    Euan> replace messages, it has to consider whether the peer advertising the
    Euan> route has changed;  if so it calls delete followed by add, otherwise
    Euan> it can call replace directly.

    Euan> The timer callback registers itself as a one-shot timer on the BGP
    Euan> master's event loop.  On every tick it reschedules itself, with some
    Euan> jitter.

    Euan> STATUS AND QUESTIONS

    Euan> I've tested this code in a simple EBGP clique topology, with no route
    Euan> filtering.   It seems to do the right thing in this context and
    Euan> doesn't crash, but it may be that it doesn't handle some other
    Euan> configuration that I haven't tried.  Please let me know if you think
    Euan> of one, or if you try it out and find a bug.

    Euan> It almost certainly leaks memory.  I'm a C++ newbie and usually code
    Euan> in languages with garbage collection.   Any, umm, pointers on my
    Euan> memory management would be appreciated! ;-P

    Euan> I've had some problems running the bootstrap script on my Ubuntu
    Euan> Dapper machine.   Automake bails with errors like "automake: pim/
    Euan> Makefile.am: not supported: source file `$(top_srcdir)/rib/
    Euan> redist_xrl.hh' is in subdirectory".   There are also warnings from
    Euan> autoheader.   Since I'm only adding a couple of files I updated the
    Euan> Makefile manually;  I hope it works better for you on FreeBSD!

    Euan> I'm looking forward to your comments! :-)

    Euan> Thanks,
    Euan> Euan


    Euan> _______________________________________________
    Euan> Xorp-hackers mailing list
    Euan> Xorp-hackers at icir.org
    Euan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From hasso at linux.ee  Tue Jan 23 01:51:40 2007
From: hasso at linux.ee (Hasso Tepper)
Date: Tue, 23 Jan 2007 11:51:40 +0200
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/etc/templates
	xorp/static_routes xorp/xrl/interfaces xorp/xrl/targets
In-Reply-To: <200701230157.l0N1vdp8015013@xorpc.icir.org>
References: <200701230157.l0N1vdp8015013@xorpc.icir.org>
Message-ID: <200701231151.40568.hasso@linux.ee>

Pavlin Radoslavov wrote:
> Log message:
> 	Implement support for floating static routes (i.e., static routes
> 	for the same prefix with different next hop and metrics).
> 	
> 	A floating static route (also called "qualified" by some router
> 	vendors) can be added with a configuration like:
> 	
> 	protocols {
> 	    static {
> 	        route 10.10.0.0/16 {
> 	            next-hop: 1.1.1.1
> 	            metric: 1
> 	            qualified-next-hop 1.1.1.2 {
> 	                metric: 10
> 	            }
> 	        }
> 	        interface-route 10.30.30.0/24 {
> 	            next-hop-interface: "rl0"
> 	            next-hop-vif: "rl0"
> 	            next-hop-router: 1.2.3.4
> 	            metric: 1
> 	            qualified-next-hop-interface rl0 {
> 	                qualified-next-hop-vif rl0 {
> 	                    next-hop-router: 5.6.7.8
> 	                    metric: 10
> 	                }
> 	            }
> 	        }
> 	    }
> 	}

Why so complicated? It's already UI nightmare, you shouldn't make it
worse.

protocols {
    static {
        route 10.10.0.0/16 {
            next-hop 1.1.1.1 {
                metric: 1
            }
            next-hop 1.1.1.2 {
                metric: 10
            }
        }
        interface-route 10.30.30.0/24 {
            next-hop 1.2.3.4 {
                next-hop-interface: "rl0"
                next-hop-vif: "rl0"
                metric: 1
            }
            next-hop 5.6.7.8 {
                next-hop-interface: "rl0"
                next-hop-vif: "rl0"
                metric: 1
            }
        }
    }
}

Note, that I actually don't understand why there is separate interface
route node at all. It should be same route note just handled in the
backend - if there is interface specified, it's interface route, if there
isn't interface specified, it isn't interface route.

protocols {
    static {
        route 10.10.0.0/16 {
            next-hop 1.1.1.1 {
                metric: 1
            }
            next-hop 1.1.1.2 {
                interface "rl0" {
                    vif: "rl0"
                }
                metric: 10
            }
        }
    }
}


with my best wishes,

-- 
Hasso Tepper


From mhorn at vyatta.com  Tue Jan 23 07:39:48 2007
From: mhorn at vyatta.com (Mike Horn)
Date: Tue, 23 Jan 2007 08:39:48 -0700
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit:
	xorp/etc/templatesxorp/static_routes xorp/xrl/interfaces
	xorp/xrl/targets
In-Reply-To: <200701231151.40568.hasso@linux.ee>
Message-ID: <013301c73f04$b6e94b30$0f02a8c0@caddisconsulting.com>

Hi all,

Pavlin - thanks for enhancing XORP!  I do agree with Hasso that the current
implementation seems overly complex, plus I haven't heard the "term"
qualified route used in this context, so that may be confusing to users.

Another issue is that this solution appears to only work for a static route
backing up another static route.  Most implementations use admin cost for
the static route metric which allows a static route to be created with a
higher admin cost than say OSPF.  This is important for features like
dial-on-demand for failover protection.

-mike

> -----Original Message-----
> From: xorp-hackers-bounces at icir.org 
> [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Hasso Tepper
> Sent: Tuesday, January 23, 2007 2:52 AM
> To: xorp-hackers at icir.org
> Cc: Pavlin Radoslavov
> Subject: Re: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: 
> xorp/etc/templatesxorp/static_routes xorp/xrl/interfaces 
> xorp/xrl/targets
> 
> Pavlin Radoslavov wrote:
> > Log message:
> > 	Implement support for floating static routes (i.e., 
> static routes
> > 	for the same prefix with different next hop and metrics).
> > 	
> > 	A floating static route (also called "qualified" by some router
> > 	vendors) can be added with a configuration like:
> > 	
> > 	protocols {
> > 	    static {
> > 	        route 10.10.0.0/16 {
> > 	            next-hop: 1.1.1.1
> > 	            metric: 1
> > 	            qualified-next-hop 1.1.1.2 {
> > 	                metric: 10
> > 	            }
> > 	        }
> > 	        interface-route 10.30.30.0/24 {
> > 	            next-hop-interface: "rl0"
> > 	            next-hop-vif: "rl0"
> > 	            next-hop-router: 1.2.3.4
> > 	            metric: 1
> > 	            qualified-next-hop-interface rl0 {
> > 	                qualified-next-hop-vif rl0 {
> > 	                    next-hop-router: 5.6.7.8
> > 	                    metric: 10
> > 	                }
> > 	            }
> > 	        }
> > 	    }
> > 	}
> 
> Why so complicated? It's already UI nightmare, you shouldn't 
> make it worse.
> 
> protocols {
>     static {
>         route 10.10.0.0/16 {
>             next-hop 1.1.1.1 {
>                 metric: 1
>             }
>             next-hop 1.1.1.2 {
>                 metric: 10
>             }
>         }
>         interface-route 10.30.30.0/24 {
>             next-hop 1.2.3.4 {
>                 next-hop-interface: "rl0"
>                 next-hop-vif: "rl0"
>                 metric: 1
>             }
>             next-hop 5.6.7.8 {
>                 next-hop-interface: "rl0"
>                 next-hop-vif: "rl0"
>                 metric: 1
>             }
>         }
>     }
> }
> 
> Note, that I actually don't understand why there is separate 
> interface route node at all. It should be same route note 
> just handled in the backend - if there is interface 
> specified, it's interface route, if there isn't interface 
> specified, it isn't interface route.
> 
> protocols {
>     static {
>         route 10.10.0.0/16 {
>             next-hop 1.1.1.1 {
>                 metric: 1
>             }
>             next-hop 1.1.1.2 {
>                 interface "rl0" {
>                     vif: "rl0"
>                 }
>                 metric: 10
>             }
>         }
>     }
> }
> 
> 
> with my best wishes,
> 
> --
> Hasso Tepper
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 



From pavlin at icir.org  Tue Jan 23 15:14:27 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 23 Jan 2007 15:14:27 -0800
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/etc/templates
	xorp/static_routes xorp/xrl/interfaces xorp/xrl/targets
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee> of "Tue,
	23 Jan 2007 11:51:40 +0200." <200701231151.40568.hasso@linux.ee> 
Message-ID: <200701232314.l0NNERBm057342@possum.icir.org>

> > Log message:
> > 	Implement support for floating static routes (i.e., static routes
> > 	for the same prefix with different next hop and metrics).
> > 	
> > 	A floating static route (also called "qualified" by some router
> > 	vendors) can be added with a configuration like:
> > 	
> > 	protocols {
> > 	    static {
> > 	        route 10.10.0.0/16 {
> > 	            next-hop: 1.1.1.1
> > 	            metric: 1
> > 	            qualified-next-hop 1.1.1.2 {
> > 	                metric: 10
> > 	            }
> > 	        }
> > 	        interface-route 10.30.30.0/24 {
> > 	            next-hop-interface: "rl0"
> > 	            next-hop-vif: "rl0"
> > 	            next-hop-router: 1.2.3.4
> > 	            metric: 1
> > 	            qualified-next-hop-interface rl0 {
> > 	                qualified-next-hop-vif rl0 {
> > 	                    next-hop-router: 5.6.7.8
> > 	                    metric: 10
> > 	                }
> > 	            }
> > 	        }
> > 	    }
> > 	}
> 
> Why so complicated? It's already UI nightmare, you shouldn't make it
> worse.

I agree it looks complicated, but there are reasons for using such
solution instead of what you suggest. The comments below are
separated for the "route" and the "interface-route" cases.

> protocols {
>     static {
>         route 10.10.0.0/16 {
>             next-hop 1.1.1.1 {
>                 metric: 1
>             }
>             next-hop 1.1.1.2 {
>                 metric: 10
>             }
>         }

The reasons I introduced the new "qualified-next-hop" statement
instead of using the above configuration are:

 * Preserve backward compatibility (configuration wise) about the
   existing "next-hop" and "metric" statements.

 * One of the main router vendors already use same configuration
   structure (and naming) for the "route" and "qualified-next-hop"
   statements.

 * The "next-hop" leaf node statement is mandatory. If we make it a
   multi-value node, then currently we don't have a mechanism
   inside the rtrmgr templates to mandate that there is at least
   one "next-hop" node configured.

Personally, if we didn't have the above factors, I actually do
prefer your example. In fact this was the mechanism I considered
first, but then I had to take into account those factors and modify
it the way it is now.

Though, none of those issues is a real show-stopper:

 * From time to time we change the configuration syntax, so we don't
   have to guarantee that there is always backward compatibility.
 * In general, we follow the configuration syntax of other vendors,
   but we don't have to stick to every word.
 * If we can't make the "next-hop" mandatory, then someone who
   forgets to put at least one "next-hop" entry simply won't have
   the route installed and there won't be an error message pointing
   to the error.

I don't have objections of changing the front-end interface the way
you suggest it, but only if people understand the trade-offs and
agree to accept the drawbacks.

>         interface-route 10.30.30.0/24 {
>             next-hop 1.2.3.4 {
>                 next-hop-interface: "rl0"
>                 next-hop-vif: "rl0"
>                 metric: 1
>             }
>             next-hop 5.6.7.8 {
>                 next-hop-interface: "rl0"
>                 next-hop-vif: "rl0"
>                 metric: 1
>             }
>         }

I should note that for interface-specific routes the next-hop IP
address is optional, hence it can't be used to differentiate the
routes. However, if we are to change the "route" syntax, the
"interface-route" syntax can be like:

	        interface-route 10.30.30.0/24 {
	            next-hop-interface rl0 {
	                next-hop-vif rl0 {
	                    next-hop-router: 1.2.3.4
	                    metric: 1
	                }
	            }
	            next-hop-interface rl1 {
	                next-hop-vif rl1 {
	                    next-hop-router: 5.6.7.8
	                    metric: 10
	                }
	            }
	        }


Alternative solution would be to use some (user-specified) text to
differentiate each interface-specific route. E.g.

        interface-route 10.30.30.0/24 {
            next-hop PRIMARY-ISP-A {
                next-hop-interface: "rl0"
                next-hop-vif: "rl0"
                next-hop-router: 1.2.3.4
                metric: 1
            }
            next-hop BACKUP-ISP-B {
                next-hop-interface: "rl1"
                next-hop-vif: "rl1"
                /* next-hop-router: 5.6.7.8 */
                metric: 10
            }
        }


>     }
> }
> 
> Note, that I actually don't understand why there is separate interface
> route node at all. It should be same route note just handled in the
> backend - if there is interface specified, it's interface route, if there
> isn't interface specified, it isn't interface route.
> 
> protocols {
>     static {
>         route 10.10.0.0/16 {
>             next-hop 1.1.1.1 {
>                 metric: 1
>             }
>             next-hop 1.1.1.2 {
>                 interface "rl0" {
>                     vif: "rl0"
>                 }
>                 metric: 10
>             }
>         }
>     }
> }

Syntax like above is nice, but as I mentioned earlier, for
interface-specific routes we cannot use the optional IP address as
the multi-value key.
If people really want the simplicity of the
above syntax, this can be achieved by the introduction of the
user-specific text like in the interface-route example. E.g.:

        interface-route 10.30.30.0/24 {
            next-hop PRIMARY-ISP-A {
                /* next-hop-interface: "rl0" */
                /* next-hop-vif: "rl0" */
                next-hop-router: 1.2.3.4
                metric: 1
            }
            next-hop BACKUP-ISP-B {
                next-hop-interface: "rl1"
                next-hop-vif: "rl1"
                /* next-hop-router: 5.6.7.8 */
                metric: 10
            }
        }

The drawback of the above solution is that currently there is no
mechanism to specify in the rtrmgr templates that the next-hop
information must contain either next-hop-router or
next-hop-interface/next-hop-vif (or both). Hence, if an user doesn't
specify any of the next-hop-* information, then the xorpsh cannot
catch the configuration error and we need to rely on the backend
(static_routes) code to catch it. Again, this is not a show-stopper
but can be annoying because typically we try to catch such errors as
early as possible.


Finally, I should mention that the backend should support any of the
above frontend changes with no (or very few) modifications.

Regards,
Pavlin

> 
> 
> with my best wishes,
> 
> -- 
> Hasso Tepper
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin at icir.org  Tue Jan 23 15:22:45 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 23 Jan 2007 15:22:45 -0800
Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit:
	xorp/etc/templatesxorp/static_routes xorp/xrl/interfaces
	xorp/xrl/targets
In-Reply-To: Message from "Mike Horn" <mhorn@vyatta.com> of "Tue,
	23 Jan 2007 08:39:48 MST."
	<013301c73f04$b6e94b30$0f02a8c0@caddisconsulting.com> 
Message-ID: <200701232322.l0NNMj6F057457@possum.icir.org>

> Pavlin - thanks for enhancing XORP!  I do agree with Hasso that the current
> implementation seems overly complex, plus I haven't heard the "term"
> qualified route used in this context, so that may be confusing to users.

I just sent a reply to Hasso's email which addresses the front-end
changes and the reason that "qualified-next-hop" was used.

> Another issue is that this solution appears to only work for a static route
> backing up another static route.  Most implementations use admin cost for
> the static route metric which allows a static route to be created with a
> higher admin cost than say OSPF.  This is important for features like
> dial-on-demand for failover protection.

To have something like this we need to be able to change the admin
distance per protocol (inside the RIB). Accidentally, few days ago
Bruce added a patch to the relevant Bugzilla entry:

http://www.xorp.org/bugzilla/show_bug.cgi?id=536

Note that this patch doesn't contain the rib rtrmgr template
changes, because we need to be very careful how we provide the interface
to the user. Also, with this patch the admin distance can be changed only
before the particular protocol has started. E.g., the user won't be
able to change the OSPF admin distance after the OSPF protocol has
been started. After the current patch is committed and tested we can
think of addressing this issue as well.

Regards,
Pavlin

> 
> -mike
> 
> > -----Original Message-----
> > From: xorp-hackers-bounces at icir.org 
> > [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Hasso Tepper
> > Sent: Tuesday, January 23, 2007 2:52 AM
> > To: xorp-hackers at icir.org
> > Cc: Pavlin Radoslavov
> > Subject: Re: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: 
> > xorp/etc/templatesxorp/static_routes xorp/xrl/interfaces 
> > xorp/xrl/targets
> > 
> > Pavlin Radoslavov wrote:
> > > Log message:
> > > 	Implement support for floating static routes (i.e., 
> > static routes
> > > 	for the same prefix with different next hop and metrics).
> > > 	
> > > 	A floating static route (also called "qualified" by some router
> > > 	vendors) can be added with a configuration like:
> > > 	
> > > 	protocols {
> > > 	    static {
> > > 	        route 10.10.0.0/16 {
> > > 	            next-hop: 1.1.1.1
> > > 	            metric: 1
> > > 	            qualified-next-hop 1.1.1.2 {
> > > 	                metric: 10
> > > 	            }
> > > 	        }
> > > 	        interface-route 10.30.30.0/24 {
> > > 	            next-hop-interface: "rl0"
> > > 	            next-hop-vif: "rl0"
> > > 	            next-hop-router: 1.2.3.4
> > > 	            metric: 1
> > > 	            qualified-next-hop-interface rl0 {
> > > 	                qualified-next-hop-vif rl0 {
> > > 	                    next-hop-router: 5.6.7.8
> > > 	                    metric: 10
> > > 	                }
> > > 	            }
> > > 	        }
> > > 	    }
> > > 	}
> > 
> > Why so complicated? It's already UI nightmare, you shouldn't 
> > make it worse.
> > 
> > protocols {
> >     static {
> >         route 10.10.0.0/16 {
> >             next-hop 1.1.1.1 {
> >                 metric: 1
> >             }
> >             next-hop 1.1.1.2 {
> >                 metric: 10
> >             }
> >         }
> >         interface-route 10.30.30.0/24 {
> >             next-hop 1.2.3.4 {
> >                 next-hop-interface: "rl0"
> >                 next-hop-vif: "rl0"
> >                 metric: 1
> >             }
> >             next-hop 5.6.7.8 {
> >                 next-hop-interface: "rl0"
> >                 next-hop-vif: "rl0"
> >                 metric: 1
> >             }
> >         }
> >     }
> > }
> > 
> > Note, that I actually don't understand why there is separate 
> > interface route node at all. It should be same route note 
> > just handled in the backend - if there is interface 
> > specified, it's interface route, if there isn't interface 
> > specified, it isn't interface route.
> > 
> > protocols {
> >     static {
> >         route 10.10.0.0/16 {
> >             next-hop 1.1.1.1 {
> >                 metric: 1
> >             }
> >             next-hop 1.1.1.2 {
> >                 interface "rl0" {
> >                     vif: "rl0"
> >                 }
> >                 metric: 10
> >             }
> >         }
> >     }
> > }
> > 
> > 
> > with my best wishes,
> > 
> > --
> > Hasso Tepper
> > 
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > 
> 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From chintamanisw at gmail.com  Thu Jan 25 05:03:35 2007
From: chintamanisw at gmail.com (chintamani wandhre)
Date: Thu, 25 Jan 2007 05:03:35 -0800
Subject: [Xorp-hackers] Doubt on pim bidir for xorp
Message-ID: <8385815b0701250503n6c6bd36fj4394eb1f52a23289@mail.gmail.com>

Hello Geeks,
We are developing PIM BiDir protocol for Xorp. We have doubt regarding the
same.

       In PIM SM RP sould be router nut in case of  PIM BIDIR  RP can be any
rout able  Address called as RPA.(Not necessary to be a router).As per  the
IETF  draft  (
http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-08.txt)

       So what should be our approach  to  handle  this case.

Thank You
chintamani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070125/acacd490/attachment.html 

From M.Handley at cs.ucl.ac.uk  Thu Jan 25 08:45:43 2007
From: M.Handley at cs.ucl.ac.uk (Mark Handley)
Date: Thu, 25 Jan 2007 16:45:43 +0000
Subject: [Xorp-hackers] Doubt on pim bidir for xorp
In-Reply-To: <8385815b0701250503n6c6bd36fj4394eb1f52a23289@mail.gmail.com>
References: <8385815b0701250503n6c6bd36fj4394eb1f52a23289@mail.gmail.com>
Message-ID: <84a612dd0701250845o222509b5hc46c28632f7885c1@mail.gmail.com>

I don't understand what you think the problem is.  A PIM-Bidir router needs
to be able to discover the RPA.  This can be configured or learned via some
bootstrap protocol - same story as PIM-SM.  The only difference is that the
RPA can be a routable address on a subnet, without there needing to actually
be a router (or a host or anything) at that address.  No other router needs
to know whether there is or isn't a router at that address, so long as the
subnet for that address is reachable.

So isn't the answer that there isn't a case to handle?

 - Mark

On 1/25/07, chintamani wandhre <chintamanisw at gmail.com> wrote:
>
> Hello Geeks,
> We are developing PIM BiDir protocol for Xorp. We have doubt regarding the
> same.
>
>        In PIM SM RP sould be router nut in case of  PIM BIDIR  RP can be
> any rout able  Address called as RPA.(Not necessary to be a router).As per
> the  IETF  draft  (
> http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-08.txt)
>
>        So what should be our approach  to  handle  this case.
>
> Thank You
> chintamani
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070125/c3daf7bd/attachment.html 

From ashishkarpe at gmail.com  Sat Jan 27 05:26:27 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Sat, 27 Jan 2007 18:56:27 +0530
Subject: [Xorp-hackers] pim sm- igmp/mld Doubt
Message-ID: <f87e63a0701270526x1b4e6c36h3e103dbe3c5c10ff@mail.gmail.com>

hi all,
        The Pim Sm module interact with IGMP/MLD module as stated in
XORP Multicast Routing Design Architecture. While studying pim sm code
i was not able to find how pim sm registers with igmp/mld!!!
         Could you please help me in this.(please tell me pin pointed
information.)

thank you
ashish


From pavlin at icir.org  Wed Jan 31 01:57:54 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 31 Jan 2007 01:57:54 -0800
Subject: [Xorp-hackers] pim sm- igmp/mld Doubt
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Sat,
	27 Jan 2007 18:56:27 +0530."
	<f87e63a0701270526x1b4e6c36h3e103dbe3c5c10ff@mail.gmail.com> 
Message-ID: <200701310957.l0V9vs5w060235@possum.icir.org>

>         The Pim Sm module interact with IGMP/MLD module as stated in
> XORP Multicast Routing Design Architecture. While studying pim sm code
> i was not able to find how pim sm registers with igmp/mld!!!
>          Could you please help me in this.(please tell me pin pointed
> information.)

Sorry about the late reply; I was occupied with some other stuff.

The PIM-SM module uses the following XRLs (defined in
xrl/interfaces/mld6igmp.xif) to register/unregister with the
IGMP/MLD module:

mld6igmp/0.1/add_protocol4
mld6igmp/0.1/add_protocol6
mld6igmp/0.1/delete_protocol4
mld6igmp/0.1/delete_protocol6

In case of the PIM-SM implementation those XRLs are transmitted by
the following method:

XrlPimNode::send_add_delete_protocol_mld6igmp()

After a protocol module has been registered with the IGMP/MLD
module, then the IGMP/MLD module sends the following XRLs (defined
in xrl/interfaces/mld6igmp_client.xif) to the registered protocol
when the membership information changes:

mld6igmp_client/0.1/add_membership4
mld6igmp_client/0.1/add_membership6
mld6igmp_client/0.1/delete_membership4
mld6igmp_client/0.1/delete_membership6

Hence, if you have a module that wants to receive membership
information from the IGMP/MLD module, your module must implement the
mld6igmp_client.xif interface.

Regards,
Pavlin


From shamita1010 at gmail.com  Wed Jan 31 02:17:14 2007
From: shamita1010 at gmail.com (shamita pisal)
Date: Wed, 31 Jan 2007 02:17:14 -0800
Subject: [Xorp-hackers] metric used by pim-sm
Message-ID: <cb2733e40701310217p152761c5la46a616514a4f0ac@mail.gmail.com>

hi,
We am implementing PIM-Bidir module in Xorp.Could you please tell us the
metric used by PIM-SM as implemented in xorp.These metrics are stored in
mrt/mrib table.

Thanks a lot ,
shamita.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070131/4bf5e58f/attachment.html 

From pavlin at icir.org  Wed Jan 31 11:34:09 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 31 Jan 2007 11:34:09 -0800
Subject: [Xorp-hackers] metric used by pim-sm
In-Reply-To: Message from "shamita pisal" <shamita1010@gmail.com> of "Wed,
	31 Jan 2007 02:17:14 PST."
	<cb2733e40701310217p152761c5la46a616514a4f0ac@mail.gmail.com> 
Message-ID: <200701311934.l0VJY9sS066645@possum.icir.org>

shamita pisal <shamita1010 at gmail.com> wrote:

> hi,
> We am implementing PIM-Bidir module in Xorp.Could you please tell us the
> metric used by PIM-SM as implemented in xorp.These metrics are stored in
> mrt/mrib table.

Those metrics are used by the PIM protocol when comparing the PIM
Asserts and declaring the PIM Assert winner.

If the fib2mrib module is used to populate the MRIB table (which
probably is the case because currently is the only option), then
those metrics come from the kernel.

Regards,
Pavlin