Subject: Re: [IPTEL] a doubt on TRIP

From: "Nitin Kumar" <[email-masked]>
Date: Thu, 8 Nov 2001 07:36:24 -0800

Hello Everyone,

Just looking into the state machine diagram at the back of the draft for iptel-trip-09.
A small doubt.

Don't we have this scenario, if I have got the picture correctly, that on getting
the start event we try and set up connection with the external LS acting as
a client ( trying an outbound connection in other words ), as well as start
looking for any inbound connection requests from the peer LS, in essence act
as a server also. 

Now, say if we first have a transport connection succes as a client, don't we
get the transport connection open event ? 

If yes, fine we do go ahead and send an open on this connection and say also
get an open back on this connection from peer. Making our state for this peer
LS as 'Open Confirm'.

Now, say if we get an inbound connection request on the server side of our's,
don't we still accept it and thus get an 'Transport Connection Open' event again
??

If yes, then why is it that on getting this event as per the FSM table in Appendix,
in the 'Open Confirm' State we move back to Idle. 

From, what I can think this is where we get to do connection collision detection
and select one of the transport connections now after getting an 'open message'
?

Also, I had written a mail some time back on the mailing list but didn't get
any response regarding the need for 2 different  tie break mechanisms, could
anyone please tell me where, I was so wrong.

(Attaching the last 2 mails for your reference)

Thanks,
Nitin

>
>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
>
>
>>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
>>
>>
>>
>______________________________________________________
>Get Your FREE FlashMail Address now at http://www.flashmail.com
>It's Free, Easy, & Fun !!!
>
>
______________________________________________________
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

---

From: Manjunath Bangalore <[email-masked]>
Date: Fri, 09 Nov 2001 00:56:39 -0800

Hi Nitin,

  Please refer inline:

> in the 'Open Confirm' State we move back to Idle.

The example that you have is a connection collision where two parallel connections between
the same peers exist at some point in time. In this case, (where one connection is in the
OpenConfirm state), and you receive an event 'Transport Connection Open', the LS should
check for the presence of any connection with that peer that are in the Established,
OpenConfirm or in the OpenSent state. If there are any, the LS should unconditionally close
the newly created connection.
The state table in the draft should be changed to reflect this.

It could well happen that both the peers use the above logic at their respective ends and
close the newly created connection hence leaving the connection in the OpenConfirm state
untouched.

Sec 6.8 discusses a Connection Collision Detection procedure that applies on the receipt of
an OPEN message but that cannot be applied here.  The example that you have reflects a
collision at an earlier stage.

> (Attaching the last 2 mails for your reference)

I haven't had a chance to look at your other mail. Will try to respond to that one...

Regards,
-Manjax