Subject: Re: [IPTEL] a doubt on TRIP

From: Anirudh Sahoo <[email-masked]>
Date: Sat, 03 Nov 2001 18:09:43 -0800

please see in line:

Nitin Kumar wrote:

> Hello,
>
> My name is Nitin Mahajan and the reason I am writting to you is because I had
> just read the draft on TRIP i.e draft-ietf-iptel-trip-09.txt.
>
> I had some doubts which if you could please clarify (jonathan rosenberg has
> referred me to you).
>
> For decision process architecture the draft says of rules to be followed for
> tie breaks. Now, I could see in Sec 10.2.2.1 the 3 rules to be used for tie
> break (for internal as well as external ) but, the draft  mentions the 2 rules
> to be used for tie breaks (for external peers) again in Sec 10.3.1.1.
>
> Though the rules in the later section boil down to be same, but why are they
> given again , am I missing something ?

This is my understanding:
The rule in 10.3.1.1 does not boil down to the same. 10.2.2 is used when
Ext-TRIB or Loc-TRIB is being updated and as a result a potential change
in Adj-TRIB-out and disseminating routes to external peers (external update).
10.3.1 is for internal updates.  Rule 1 in 10.2.2.1 is really different
from rule 1 of 10.3.1.1. 10.2.2.1 says if the routes are from
the _same_ neighboring ITADs then the route with
_larger_ MultiExitDisc is chosen.
Whereas 10.3.1.1 rule 1, I think, the peers are
from different ITADs. Also, in this case, it will choose the route
with _lowest_ MultiExitDisc.

>
>
> Also, isn't the 2nd point in the later Section 10.3.1.1 mentions the use of
> TRIP Identifier for tie break , shouldn't it be ITAD number ? As otherwise don't
> we leave an another chance of tie ?

I think it should be ITAD number instead of TRIP identifier, since the
routes are from peers of different ITAD.

>
>
> Please correct me if I am going wrong somwhere ( this is my first time reading
> such draft).
>
> Thanks in Advance,
>
> Nitin
> ______________________________________________________
> Get Your FREE FlashMail Address now at http://www.flashmail.com
> It's Free, Easy, & Fun !!!
>
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Nitin Kumar" <[email-masked]>
Date: Mon, 5 Nov 2001 01:27:23 -0800

Hello Anirudh,

First of all, thanks for your reply ..

on that only, I was wondering why would we need two ways to break the tie breaks
.. 

from the way I can see and understand, all internal updates are given birth
( or propagated ) by an LS for only 2 possible cases :

1) when either it gets a "new" route in an update from an LS in it's own ITAD

2) when an update recvd. from an external LS causes change in it's Ext-TRIB
/ Loc-TRIB.

Am I getting it right  ?

Now,  say a route comes from an external LS whose degree of preference is calculated
and found to be higher than rest in the databse. It is thus now incorporated
into the Ext-TRIB and the Loc-TRIB. Now, aren't we supposed to have this route
forwarded to Internal LS, no matter what ? As Loc-TRIB of all the LS needs to
be the same and this is route has been say an external route update / local
injection to this specific LS , so it is his duty to forward this news to everyone
?

So, where did we happen to use the Sec 10.3.1.1 conditions ? for calculation
of route into the Ext -TRIB, we should be using Sec. 10.2.2.1 rules itself,
isn't it ?

Theoretically, we could have used Sec. 10.2.2.1 for route selection into Ext-TRIB
and use 10.3.1.1 rule again on the Adj-TRIB-In data for selection of routes
to be sent to Internal LS, but the outcome of this second phase of tie breaks
is only for selection of routes to be propogated to Internal LS's .. 

(Again -:) ) am I right ? was this what the draft was pointing to ?

If yes, then doesn't it causes an obvious confusion as the route in Ext-TRIB
would be different for sure than the route sent to Internal LS. ?

If No, Please tell me where  am I going wrong ?

Also , is there any logical belief in selecting lowest Multi Exit Desc value
as in Sec 10.3.1.1 ? 

Lastly, Sec 10.3.1.1 doesn't has the word "same" ,  in it's 1st Rule for Multi
Exit Disc, so is it suggesting that we use the Multi Exit Disc even for the
case when the routes being compared are not from same ITAD ? 
My understanding says......... no  .. 

and if that is the case could we have the "same" word added to the rule description
in Sec 10.3.1.1, as it could be misleading.

Thanks in Advance,

Nitin

---

From: "Nitin Kumar" <[email-masked]>
Date: Mon, 5 Nov 2001 01:27:23 -0800

Hello Anirudh,

Am I getting it right  ?

Thanks in Advance,

Nitin