The MPLS-OPS Archive

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



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

Re: beginner's query

  • From: "Eric Osborne" <eosborne@cisco.com>
  • Date: Thu, 20 May 2004 15:28:24 -0400
  • Cc: mpls-ops@mplsrc.com
  • Organization: Cisco Systems, Inc.
  • Resent-Date: Thu, 20 May 2004 16:04:10 -0400
  • To: "Puddinhead Wilson" <puddinghead_wilson007@yahoo.co.uk>, "Sunil Menon K" <k_sunilmenon@rediffmail.com>, "Sundeep Singh" <singh0de@ee.iitb.ac.in>
  • User-Agent: Opera M2/7.50 (Win32, build 3778)
  • X-BrightmailFiltered: true

...

>> 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"?

Yes, we do.  This is the whole purpose behind an ERO - to be able to send  
an LSP a specific way across the network.  In order to calculate this on  
the router itself (which is one way, but not the only way, to determine a  
path), we need unique identifiers we can run a constrained SPF [CSPF] with.

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

The less visibility you have past your neighbors, the more crankback,  
explorer packets, and other such odd stuff you need to find a path from  
source to destination.  And since you're dealing with a multi-variable  
problem ("I need to find the lowest cost path with bandwidth X"), your  
EIGRP model wouldn't work real well.  EIGRP does what it does because what  
we know is _minimum_ bandwidth across the path that has the lowest cost.   
To do TE with this, you'd have to build something that says "I have a path  
of cost 100 with BW 10; another of cost 103 with BW 14; another with cost  
110 with BW 75", etc.  The more paths you have, the more information  
explosion you have.


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

Apart from operational stuff like manageability, node identifiers are  
useful for:

- doing offline path calculation and then uploading said calculated paths  
to the routers in question
- things like FRR, which need to know which NHops and NNHops (and in  
theory, NNNNN..NHops) an LSP goes through, so they can do the right thing  
with protection.

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

Rember, there are no stupid questions, only stupid people....:)

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

If you cross the same node X twice in your path, what's the point?  Why  
would I want to drive from Dover to Bristol through London by going  
Dover->London->Birmingham->London->Bristol?  It's unnecessarily  
suboptimal; looping through a node that's in your path later on is, as far  
as I can see, of no benefit and of almost certain drawback.


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

Depends what you mean by "problem".  It's true that packets would  
eventually arrive at their destination, so in the strictest sense, nothing  
is broken if you do what you're suggesting.  However, it's wildly  
suboptimal - I end up reserving BW at point 2 which some other LSP could  
have used, and for no benefit whatsoever.

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

If you are totally loose, it's like you don't have an ERO at all, in which  
case (at least in our implementation), the headend sends the packet to a  
next-hop along the shortest cost path to the destination, and so on down  
the line.  It should be obvious that lack of any explicit routing doesn't  
work when there's a bandwidth requirement, but without bandwidth, this  
essentially means the headend presignals one of the lowest-cost paths from  
the set of ECMPaths to the destination.  I don't generally see the point  
in TE with no ERO, with the possible exception of NNHop FRR.



eric

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