The MPLS-OPS Archive

["M. ELK" <elkou141061@hotmail.com>]

Hi & happy new year

below doc (white paper) address the above :
http://www.juniper.net/solutions/literature/white_papers/200160.pdf

Indicated in the paper :

Quote

The BGP extensions that allow for the propagation of Route Target 
information in BGP are
defined in “draft-ietf-rt-constrain”, currently going through the IETF 
standardization process.
The document defines a new “route-target” network reachability information 
type in which to
encode route target prefixes. These are treated internally by BGP similarly 
to an IP unicast
destination prefix, being stored in and advertised from a routing table 
specific to this NLRI.
The difference is in the semantics of a prefix once installed in the local 
routing-table (RIB-LOC
in the BGP specification terminology). IP unicast prefixes result in an 
entry in the router’s
forwarding engine destination lookup table. Entries in the “route-target” 
table are applied as
a filter to outbound route updates of a separate address family, namely the 
address family
containing VPN routing information.

Unquote

Question :

1- Unable to locate draft "draft-ietf-rt-constrain" , any clue ??

2- Draft Cooperative Route Filtering Capability for BGP-4
   http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-12.txt
   Provide silimar result without the need to define a new NLRI .
   What is the advantage of the solution in draft draft-ietf-rt-constrain 
versus route-filter draft ??
   Note : It is clear that route-filter is one to one ie: peer to peer while 
rt-constrain is one to many
             ie: the route filter from one Peer will reach all peer (either 
through direct meshing or RR).
             but what other advantage ??

3- From vendor prespective , what is the main issue in RR scalability ?
    is it "Processing Power " or is it "memory size" .
    the classical answer they are both , but in priority which one is more 
severe ???
    My guess it is the "Processing Power " .
    if yes : The solution provided impose even more load on the processor , 
either in term of
              extra filtering (draft route filter) or in term of extra 
filtering + running BGP for another
              family (draft rt-constrain ) .
    So the question , in real deployement enviroment do U expect both 
solution will have any impact
    on RR scalability ???.

4- is the router hardware is the righ setup to run RR software ??
    Could a general hardware (Work Station ) provide beeter processing power 
and memory ??
    If yes : why no vendor take this approach  ??
    N.B: i posted same almost year back and as far as i figure out from the 
reply that no vendor is
          interested to port the RR software with no reason given  .
Brgds

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml