Subject: RE: Hello Messages in RSVP-TE

From: Arumugam R <[email-masked]>
Date: Mon, 18 Dec 2000 11:28:51 +0530

Hi,
Please find inline comments.

-----Original Message-----
From:	Gaitonde Anandprasanna [SMTP:[email-masked]]
Sent:	Sunday, December 17, 2000 2:04 PM
To:	[email-masked]
Subject:	Hello Messages in RSVP-TE

I have some doubts about the Hello Message extension of RSVP-TE
Draft of RSVP-TE 07.txt

One basic doubt is this :

 If no Instance values are received, via either REQUEST or ACK
   objects, from a neighbor within a configured number of
   hello_intervals, then a node MUST presume that it cannot communicate
   with the neighbor.  The default for this number is 3.5.   

>From this paragraph i feel that if my nighbour does not support Hello
messages then obviosly he will just discrad  them and i wont get any
response to my Hello request messages. the i mght consider the
communication to be lost. Though this is not the case .
 I am confused about this??

And as per the above argument even the part of the draft(shown below)is
not well understood by me.

 The Hello extension is specifically designed so that one side can use
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the mechanism while the other side does not.  Neighbor failure
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   detection may be initiated at any time.  This includes when neighbors
   first learn about each other, or just when neighbors are sharing Resv
   or Path state.

Please let me know.
[<Aru>]   Yes, I think you are bit confused. As you said, if the neighbor does not support 
Hello message, then it will discard the messages. In this case the node which is initiating 
Hello message should not treat the non receipt of Hello message as Node failure. 
Rather it should consider the neighbor as Hello non supporting neighbor.

If the neighbor had at least responded once for the Hello Req. with a Hello Ack
                            ^^^^^^^^^^^^^^^^^^^^^^
and further being silent or responding with improper values, then only it may be treated as node failure.
Regarding
 The Hello extension is specifically designed so that one side can use
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the mechanism while the other side does not.  
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
what I feel the statement conveys all about is the association of timers 
(Refresh interval & Max wait interval) could be maintained in any 
one of the neighbor alone. 

Second difficulty:

Please refer Section 5.3:

 The receiver of a HELLO REQUEST object SHOULD also verify that the
   neighbor is reflecting back the receiver's Instance value.  This is
   done by comparing the received Dst_Instance field with the
   Src_Instance field value most recently transmitted to that neighbor.
   If the neighbor continues to advertise a wrong non-zero value after a
   configured number of intervals, then the node MUST treat the neighbor
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   as if communication has been lost. 

And one more paragraph for ACK meesages

 The receiver of a HELLO ACK object MUST also verify that the neighbor
   is reflecting back the receiver's Instance value.  If the neighbor
   advertises a wrong value in the Dst_Instance field, then a node MUST
   treat the neighbor as if communication has been lost. 

In this paragraph there is no menion of whether we should wait for some
number of hello intervals before considering the communication to be
lost.??
I think we should consider the number of hello intervals here also right??

[<Aru>]   I think the statement 
configured number of intervals
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
should be changed to once, since it adds the complexity of maintaining 
the maximum count of wrong value received.
Hence I feel the statement could be changed in sink with the next paragraph. 

Also where this type of scenario can happen, the neighbor being fine but the values 
alone being changed due to noises in the Link, then the checksum mechanism with the
RSVP will take care.
Secondly if the neighbor is rebooted is it possible to bring up the node as well as 
sending a Hello message within 17.5 milliseconds, because once the neighbor 
reboots itself the neighbor info associated with it also will be washed out. Learning 
a neighbor from smoother means & sending a Hello message within 17.5 ms, I think 
it is too practical.

Thanx in advance

Pras

Regards
Aru
--------------------------------------------------------------------------------
Arumugam R
Senior Software Engineer,
Future Software Ltd.
Chennai - 35
Fone-4330550 Ext-363
--------------------------------------------------------------------------------

---

From: Gaitonde Anandprasanna <[email-masked]>
Date: Mon, 18 Dec 2000 16:14:31 +0530 (IST)

Please see some queries which i have below...

> a neighbor from smoother means & sending a Hello message within 17.5 ms, 
I think 

Thanx for the reply. Well i think in the last part of the mail u are
asking
a question . Am in right??
and as per my understanding the question is . If a machine reboots and
comes up  well before 17.5 ms, then what will happen is that though the
node
have lost the whole RSVP-TE soft state , it still will be sending hello
messages to the adjacent nodes. and then the adjacent nodes will not come
to know that the machine has rebooted through hello messages. (Well it can
 know that if after rebooting the hello message instance value changes.
Does this happen  ??)

Also i did not know get what u mean by u 'r last  line 
"Learning
> a neighbor from smoother means & sending a Hello message within 17.5 ms,
I think
"

Some how i feel that the default value of 5 ms which is given for the
Hello messages, will cause much traffic on the network and the other
mesages of RSVP-TE and also the data traffic  might get affected . Is it
not the case that the hello interval i too less????

Please explain . 

Thanx in advance

Pras

> Aru

                     _____________________________                  
                   _ |ANANDPRASANNA GAITONDE     | _ 
                  / )|COMP. SCIENCE & AUTOMATION |( \
                 / / |D-7,IISc HOSTEL            | \ \
                / /  |INDIAN INSTITUTE OF SCIENCE|  \ \
              _( (_  |BANGALORE-560012.          |  _) )_
              (((\ \>|_/->___________________<-_|</ /)))
              (\ _/ /LAB Ph.(080)3092906  \ _/ ////)
               \       /HOSTEL Ph.-            \       /  
                \    _/     (080)3092452        _    /     
                /   /-----------------------------\   \                  
               /  Email Id-                            \ 
              /      [email-masked]         \
	     ---------------------------------------------
            -----------------------------------------------

*************************************************************************  
| | | | __ ___   _____     __ _    _ __ (_) ___ ___     __| | __ _ _   _
| |_| |/ _` \ \ / / _ \   / _` |  | '_ \| |/ __/ _ \   / _` |/ _` | | | |
|  _  | (_| |\ V /  __/  | (_| |  | | | | | (_|  __/  | (_| | (_| | |_| |
|_| |_|__,_| _/ ___|   __,_|  |_| |_|_|______|   __,_|__,_|__, |
*************************************************************************