The MPLS-OPS Archive

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

Spice

Reg

Quote
a. the "map" could be wrong/outdated etc etc?
>b. the chances that the map is wrong is as likely as the suggestions given 
>on the way were wrong [may not be today as maps are a better "industry" 
>than suggestions :)] but in a theoratical sense, that analogy would hold 
>true.

Unquote

The  map could be wrong/outdated only for a brief period ,  any change in 
the map is "flooded" ie: no node will decide to forward or not to forward 
map change . every change have to be forwarded so U always have the latest 
one  (Analogy : we started with a printed map and applied change based on 
the advertisement/sign of road block) .

Reg U idea to model the netw as a tree , sound more like "spanning tree" in 
the bridge domain .
"Spanning tree" used in bridging to solve the pblm of looping but no one 
like "spanning tree" and
we do "routing" instead of bridging . having a path just for backup is not 
very appealing
(for a LAN may be  ok as  B.W is free . For WAN it's another story ) .
have a look to "Perlman" book reg routing and bridging  where the spanning 
tree is explained
(if i recall correctly , Perlman is the one who invented this protocol ) and 
it's convergence was
discussed (also some excellent thought about routing and bridging concept 
beyond bite and byte header ) .

Brgds





>From: Spice Sylvia <falsesylvia@yahoo.co.uk>
>To: "M. ELK" <elkou141061@hotmail.com>, eosborne@cisco.com,  
>mpls-ops@mplsrc.com
>Subject: RE: [MPLS-OPS]: RE: Question on closed loop
>Date: Sat, 28 Feb 2004 09:42:53 +0000 (GMT)
>
>Hi,
>
>A couple of questions as to what is arousing my curiosity:
>
>a. the "map" could be wrong/outdated etc etc?
>b. the chances that the map is wrong is as likely as the suggestions given 
>on the way were wrong [may not be today as maps are a better "industry" 
>than suggestions :)] but in a theoratical sense, that analogy would hold 
>true.
>c. I am not saying "RIP". All I am asking is if there are other solutions 
>to the Bellman Ford problem?
>
>By the logic of eBGP and/or RIP, one could simply do something like this:
>
>"make all your networks as trees"
>
>As in , no loops/feedback/closed graphs. if there is a secondary link, 
>treat it as backup. In that case, bellman ford solutions do not need unique 
>identifiers, or CTI, do u agree?
>
>R1------R2-------R3----------R4--------R5-------R6
>
>we could have branches coming out from each R1 to R6 and still the node Ids 
>would have local signifinace (for example in the above R1 could be the same 
>as R4 etc if they were all RIP peers and I could do away with CTI in the 
>above topology).
>
>The 1st thing that comes to my mind when one sees closed graphs/rings is 
>feedback systems theory.
>
>What was wrong in designing networks as "trees" and not as "rings" and 
>simply using the alternate paths as backups? That would serve the purpose 
>too, would it not?
>
>-Sylvia
>
>
>M. ELK" <elkou141061@hotmail.com> wrote:
>
>Spice
>
>Small story :
>
>In 1990 , went to London for training on certain IP BOX .
>At that time the debate between distance-vector (RIP) and SPF (mainly at
>this time it was
>OSPF , IS-IS was not in the picture) was not yet setlled down .
>
>The training was outside LON so we hired a car to visit central London ,
>with some
>direction from the hotel we started the journey . and stopped for direction
>along the way .
>we found that we are going in circle (loop) , finally we reached .
>
>Next trip , we got a map and followed the sign (road block ..etc ) and we
>reached central
>London very smoothly .
>
>at that time the above case ,triggered an analogy in my mind between the
>above and RIP versus OSPF .
>
>What was wrong with RIP ? simply we stopped for direction and take the
>suggestion
>as faithvalue ie: we fully trusted the suggestion (we have no other choice)
>. some
>of those suggestion was bad and hence we got in a circle .
>
>
>The book "rounting in the internet ,by Huitema" discussed the RIP behaviour
>in details ,
>despite all the trick (poisoning ,reverse poisoing ,hold time ..etc ) still
>in certain topology
>only the count to infinity could sort the pblm .
>
>my guess that the pblm could be sorted out if the recieving node could 
>judge
>if the advertisement recieved from neighbor is good or bad . this imply :
>1) The advertisement packet carry info which could be checked for validity 
>.
>2) the recieving node have some algorithm to check those info and return
>"Good" or "Bad" .
>
>the simplest sort of this info is the "path vector" , the recieving node
>could check
>if any loop very easily .
>
>but now it is no longer rip ,it is something like running eBGP (without
>policy , cost is the path count ie: the nbr of AS in the path . ) between
>all nodes and consider each node an AS .
>
>As Eric indicated , RIP is dead/gone . The requirement of provider is now
>very high that even
>fast convergence of IS-IS/OSPF ( 1-2 sec) is not enough/adequate . The
>provider
>requirement is now 50-100 msec . Their is many paper for msec convergence
>for SPF IGP
>by decreasing the timer , eleminate to run full SPF ..etc ( Toward msec IGP
>convergence ,
>draft-alaettingolu-isis-convergence-00 ,Nov 2000 ) .
>The point is not just if RIP could be changed to eliminate possible loop
>creation but what is
>the convergence time . If RIP could be changed to provide msec convergence
>,the provider's
>will be ready to listen .
>
>Brgds
>
>_________________________________________________________________
>Get a FREE online computer virus scan from McAfee when you click here.
>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
>---------------------------------
>  How much mail storage do you get for free? Yahoo! Mail gives you 6MB! Get 
>Yahoo! Mail

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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