The MPLS WG Archive

["Arvind, K" <arvind@tenornetworks.com>]

	> LSP state) will detect it. Also, there are mechanisms in the 
	> HELLO protocol
	> that allow the protocol optionally to go into a suspended state,
if a
	> neighbor becomes unreachable for whatever reason - this can 

	>>One curious thing mentioned above is the "suspension" of Hello.
How's that
	>>work? I don't remember seeing that in the RFC. Thanks.

	Mark:

	The terminology "go into a suspended state" is not from the draft.
By this phrase, I meant the ability to time out a neighbor and then to
choose not to reinitiate HELLOs, perhaps until the neighbor is rediscovered
through other means. (See section on "Hello Usage"):

	"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 ...
	When communication is lost or presumed to be lost as described
above, a node MAY re-initiate HELLOs."

	Regards,
	Arvind.




> -----Original Message-----
> From:	Feng, Mark [SMTP:m_feng@trillium.com]
> Sent:	Wednesday, November 14, 2001 1:21 PM
> To:	'Arvind, K'; 'David Charlap'
> Cc:	'mpls@uu.net'
> Subject:	RE: Hello Extension - destination IP address
> 
> 
> 
> > -----Original Message-----
> > From: Arvind, K [mailto:arvind@tenornetworks.com]
> > Sent: Wednesday, November 14, 2001 10:04 AM
> > To: 'David Charlap'
> > Cc: 'mpls@uu.net'
> > Subject: RE: Hello Extension - destination IP address
> > 
> > The point of contention really was whether it is necessary to 
> > stop sending
> > Hellos when all of a neighbor's RSVP state  is torn, "since 
> > you won't be
> > able to tell whether the neighbor went offline, changed 
> > address, or simply
> > doesn't have state" (quoted from an earlier message in this thread) . 
> > I interpreted RSVP state to mean LSP state (for LSPs traversing the
> > neighbor). If this interpretation is wrong, then this was the 
> > source of
> > confusion.
> >  If it is correct, I still don't see the need to stop the 
> > HELLO protocol
> > (except for reasons of CPU/bandwidth conservation, if that is 
> > a requirement)
> > because "you won't be able to tell whether the neighbor went offline,
> > changed address, or simply doesn't have state". There is no such need
> > because if a neighbor that is running the HELLO protocol went 
> > offline or
> > changed address, the HELLO protocol (if left running even 
> > after removing all
> > LSP state) will detect it. Also, there are mechanisms in the 
> > HELLO protocol
> > that allow the protocol optionally to go into a suspended state, if a
> > neighbor becomes unreachable for whatever reason - this can 
> > take care of
> > cpu/bandwidth utilization issues, if deployed.
> > Regards,
> > Arvind
> > 
> 
> I think, based on the previous discussion, stopping the Hello exchange is
> to
> save CPU/bandwidth. It's been mentioned previously that, even if the Hello
> is not stopped, the Hello state machine itself will come to the correct
> state.
> 
> In case the neighbours are configured, there might be issues related to
> how
> much control/responsibility the user should have, e.g.
> stopping/re-starting
> of Hello.
> In case of discovering neighbours by "snooping" messsages received, the
> Hello machine is controlled entirely by the implementation. In this case,
> I
> feel you can do either, i.e. stopping/continue when all the states are
> torn.
> 
> One curious thing mentioned above is the "suspension" of Hello. How's that
> work? I don't remember seeing that in the RFC. Thanks.
> 
> - Mark