The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2004-May> msg00078



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: beginner's query

  • From: Puddinhead Wilson <puddinghead_wilson007@yahoo.co.uk>
  • Date: Thu, 20 May 2004 19:53:51 +0100 (BST)
  • Cc: mpls-ops@mplsrc.com
  • Resent-Date: Thu, 20 May 2004 15:37:21 -0400
  • To: Eric Osborne <eosborne@cisco.com>, Sunil Menon K <k_sunilmenon@rediffmail.com>, Sundeep Singh <singh0de@ee.iitb.ac.in>


> > I would appreciate if someone could help me
> understand
> > this:
> >
> > 4.3.5. Loops
> >
> >  While the EXPLICIT_ROUTE object is of finite
> length,
> > the existence of loose nodes implies that it is
> > possible to construct forwarding loops
> >    during transients in the underlying routing
> > protocol.  This can be
> >    detected by the originator of the explicit
> route
> > through the use of
> >    another opaque route object called the
> RECORD_ROUTE
> > object.  The
> >    RECORD_ROUTE object is used to collect detailed
> > path information and
> >    is useful for loop detection and for
> diagnostics.
> >
> >
> > #1. Does this not assume every intermediate node
> in
> > the LSP that has been setup a unique identifier?
> 
> TE signalling in general always assumes that every
> node has a unique  
> identifier, most commonly referred to as the Router
> ID.
> 

a. Why should it? Do we actually care at the time of
LSP setup as to what "route we take"?
Wouldnt a better example be a "sort of EIGRP database"
based Path Computation where we only get relevant data
and compute an LSP based on the same?
A simple example would be hops and bandwidth.

Does it matter what path I take as long as those
constraints are met? Do I need to know intermediate
node identifiers or even give them such identifiers?




> > #2. If such a scenraio does occur, ie. an LSP is
> > indeed setup where there is a loop, and there are
> no
> > constraints specified, is it safe to assume that
> there
> > is a loop in the original topology itself?
> 
> No, I don't think that's always true.  If the ERO is
> part stric and part  
> loose, and the strict part sends a reservation in
> effect off of the  
> shortest path tree to a destination, then an
> expanding node (the one that  
> deals with the loose ERO) may well decide to send
> the reservation back  
> down the shortest path tree and cross the segments
> it's already gone  
> over.  This seems like the sort of thing that could
> be easily safeguarded  
> against in an implementation, and I've never run
> into this issue in the  
> real world, so I'm kinda speculating here.
> 

Yes that is definately possible...but it does it
affect anything? I am speculating this on a white
board now so pardon me if I make some really dumb
mistakes.

Say we suppose the ERO is the ordered set of "router
ids".

I have a part strict and part loose ERO which says
"use node 1 and then 2" you can use any other node in
the middle but "4" has to be there plus give me say "x
bandwidth through and through till my end point"

you could end up going back to 1 and getting to 4.

However, what is wrong with it?

as long as the "end point" is known, and your
"constraints are met", what would happen in this case
is:

label from 1 to 2, another label from 2 to 1 and then
to another label from 1 to 4.

can you think of wilder examples as the ones I can
think of do not seem to cause any problems?

It seems to me that no matter what I do, if it is
totally loose, I would always end up getting along the
IGP, if it is strict, I may get a looped path but it
really would not matter.

This was one of my questions.


> You could even hit this, I suppose, with a
> succession of loose EROs.  But  
> certainly with *no* ERO, if there's a loop in
> signalling it's because  
> there's a loop in the routing.
> 



	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

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