The MPLS-OPS Archive

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



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

Re: IGP Routes calculation over TE Tunnel

  • From: "Eric Osborne" <eosborne@cisco.com>
  • Date: Tue, 18 May 2004 11:57:15 -0400
  • Cc: elkou141061@hotmail.com
  • Organization: Cisco Systems, Inc.
  • Resent-Date: Tue, 18 May 2004 12:39:25 -0400
  • To: "M. ELK" <elkou141061@hotmail.com>, mpls-ops@mplsrc.com
  • User-Agent: Opera M2/7.50 (Win32, build 3778)
  • X-BrightmailFiltered: true

On Tue, 18 May 2004 15:30:06 +0000, M. ELK <elkou141061@hotmail.com> wrote:

> Hi Eric
>
> Thanks for the clarification ,Appreciate if U could answer the 2nd  
> question in my initial msg :
>
> Quote
>>> Now :
>>> Config T2 from R4 to R1 with absolute metric 1 .
>>> R1 and R4 are config to advertise T1,T2  as link in the IGP .
>>>
>>> at R1 :  could we expect that it is now case 2 ???
>
> Unquote
>
> To use CSCO terminology this is the  case of FA configured at R1 and R4  
> and the link cost is set to
> 1 in both end . what will be the RIB at R1 ,is it same as Case 2 ?? . ie:
>

FA is different.  In FA, you give a cost to the tunnel, and that cost is  
used in the IGP SPF.  In autoroute, if changing metrics, you apply the  
metric changes *after* the IGP SPF has been done, and the IGP SPF uses the  
TE tunnels in much the way described in the draft you reference.

>>> Case 2 :
>>>
>>> Prefix      Cost    Via
>>> P2           10       a
>>> P3           11      T1
>>> p4           1        T1
>
> My guess is yes , as R1 will insert R4 as one of his own neighbor  
> (despite no real "adjacency" with R4,
> by "no real" i mean no IGP Hello  making the adjacency ) when filling  
> the TENT list .

If you take the topology

R1-a-----R2-----R3-----R4

Prefix      Cost    Via
P2           10       a
P3           20       a
p4           30       a

and you build a TE tunnel from R1 to R4 and use the tunnel as a  
forwarding-adjacency with cost of 1, then {R1 R2 R3} all think that R1 has  
a direct link to R4 with a cost of 1.  So R1's RIB will be

p2   cost 10  via a
p3   cost 11  via tunnel to r4
p4   cost 1   via tunnel to r4

With autoroute and a metric of 1 on the tunnel to r4(makes no difference  
here whether it's relative or absolute)

p2   cost 10  via a
p3   cost 20  via a
p4   cost 1   via r4

because the metric adjustment is done *after* SPF.



eric

>
> Brgds
>
>> From: "Eric Osborne" <eosborne@cisco.com>
>> To: "M. ELK" <elkou141061@hotmail.com>, mpls-ops@mplsrc.com
>> Subject: Re: [MPLS-OPS]: IGP Routes calculation over TE Tunnel Date:  
>> Tue, 18 May 2004 08:12:37 -0400
>>
>> On Tue, 18 May 2004 10:41:03 +0000, M. ELK <elkou141061@hotmail.com>  
>> wrote:
>>
>>> Hi
>>>
>>> Despite it was explained to me previously still facing some difficulty.
>>> Consider the following :
>>>
>>>
>>> R1-a-----R2-----R3-----R4
>>>
>>> P1 prefix associated with R1 ,P2 with R2 ...etc .
>>>
>>> All link with 10 as cost . "a" is the interface of R1
>>>
>>> currently at R1 :
>>>
>>> Prefix      Cost    Via
>>> P2           10       a
>>> P3           20       a
>>> p4           30       a
>>>
>>> Set T1 from R1 to R4 with absolute metric 1 :
>>>
>>> Case 1 :
>>>
>>> Prefix         Cost         Via
>>> P2              10          a
>>> P3              20          a
>>> p4              1           T1
>>>
>>> Case 2 :
>>>
>>> Prefix      Cost    Via
>>> P2           10       a
>>> P3           11      T1
>>> p4           1        T1
>>>
>>> Is it case 1 or case 2 (mainly for P3) ??
>>
>> The details are probably going to be implementation-specific, but in  
>> the  case of the implementation I know the most about, it will be case  
>> 1.   Costs are changed *after* the IGP SPF is computed, which means  
>> that the  cost to p4 has no impact whatsoever on p2 and p3.  This is,  
>> of course,  assuming you are talking about our autoroute feature.  We  
>> have this other  thing, forwarding-adjacency, that doesn't behave like  
>> this at all, and  other vendors are free to do whatever they like with  
>> metrics.
>>
>>> My guess it will be case 1 to follow  
>>> draft-ietf-rtgwg-igp-shortcut-00.txt
>>
>> I just looked at this draft, and it basically explains how our  
>> autoroute  works.  This leads me to believe that at least one other  
>> implementation  works basically the same way.
>>
>> As an aside, the special case in section 5 of the draft looks a *lot*  
>> like
>> http://www/en/US/products/sw/iosswrel/ps1612/products_feature_guide09186a0080080850.html#1019729.
>>
>>> , but what are the reason
>>> to prefer this approach , is it to avoid any possible loop ??? If yes  
>>> :  could U pls provide an
>>> example of topology where loop could exist .
>>>
>>
>> I've not seen too many people play with autoroute metrics; they are   
>> confusing to most people, and tend to be used to solve the last 5% or  
>> 10%  of problems after you've applied lots of other tricks.  But that's  
>> just  me, others may have different exposure.
>>
>> As far as loops, in the autoroute metric case there won't be any  
>> loops,  because of where the cost adjustment is done.
>>
>>
>>
>>
>> eric
>>
>>> .
>>>
>>> Now :
>>> Config T2 from R4 to R1 with absolute metric 1 .
>>> R1 and R4 are config to advertise T1,T2  as link in the IGP .
>>>
>>> at R1 :  could we expect that it is now case 2 ??? .
>>>
>>>
>>> Brgds
>>>
>>> _________________________________________________________________
>>> The new MSN 8: advanced junk mail 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
>>
>>
>
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 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