The MPLS WG Archive

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

David:

I do agree that reinitiating Hellos after a neighbor failure is detected is
optional, and this was stated clearly in my response. If an implementation
chooses to reinitiate HELLOs only when a neighbor address is configured
rather than when it is learned, I have no problem with that. I didn't state
or imply that a neighbor's failure to respond to a HELLO always indicates a
node failure - if it never responded to HELLOs in the past and continues not
to, of course you cannot conclude that the neighbor has failed.  

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



> -----Original Message-----
> From:	David Charlap [SMTP:David.Charlap@marconi.com]
> Sent:	Wednesday, November 14, 2001 12:00 PM
> To:	'mpls@uu.net'
> Subject:	Re: Hello Extension - destination IP address
> 
> "Arvind, K" wrote:
> >>> 
> >>> Why is it necessary to stop sending the Hello in this case?
> >>
> >> It's not necessary.  But you don't want to waste CPU time and
> >> bandwidth sending Hellos to a non-existant peer.
> > 
> > If the peer were non-existent, wouldn't the Hello protocol detect
> > that and stop sending Hellos automatically?
> 
> It's not required to.
	KA>I meant "stop sending Hellos, if it chooses to do so" as must be
clear from the rest of the paragraph
	(quoted below).

> > According to
> > draft-ietf-mpls-rsvp-lsp-tunnel:
> > "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." At this point a node has the option of either
> > reinitiating or suspending the HELLO protocol ("When communication
> > is lost or presumed to be lost as above, a node MAY reinitiate
> > HELLOs."). If conserving  CPU time and bandwidth is an important
> > requirement, an implementation can choose not to reinitiate HELLOs
> > at this point.
> 
> Please read more than just the part you want to see.
> 
> A router does not have to stop sending hellos after detecting a neighbor
> failure.  It is allowed to automatically reinstate hellos, and it is
> allowed stop sending them.
> 
	KA> I think this is exactly what I stated above - reinitiation of
HELLOs is
	KA>optional.

> It is wrong to assume that everybody is going to stop sending hellos
> after a failure, just as it is wrong to assume that everybody is going
> to continue sending them after that same failure.
> 
	KA>I don't think I made any such assumption. All I pointed out was
that the
	KA>draft says that reinitiation of HELLOs is optional, and can be
omitted if conserving
	KA>CPU time and bandwidth is an important requirement.

> If a neighbor address is configured (and therefore does not have to be
> discovered), it makes sense to resume hellos immediately.  This allows
> us to detect our neighbor's hello instance ID as soon as it starts
> responding to hellos again (instead of waiting for some external trigger
> to restart hellos), which may be advantagious to some implementations.
> 
	KA> Maybe so. 

> >>> IMO, the way the Hello state machine works is independant of the
> >>> means to discover the neighbour. Even if the neighbour's RSVP
> >>> states are gone, the neighbour should still respond to the Hello
> >>> messages.
> >> 
> >> If all the state is gone, how can you be sure the switch's is still
> >> running?
> >> 
> >> Suppose the state goes away due to a link failure (lost carrier on
> >> the fiber).  When the link comes back up, there may be a different
> >> switch at the other end of the fiber.  If so, that switch may not
> >> be running RSVP, or it may not support Hello, or it may simply have
> >> a different IP address.
> > 
> > Wouldn't the HELLO protocol automatically detect that the neighbor
> > is down in this case as before?
> 
> A neighbor's failure to respond to Hello does not indicate failure
> unless that neighbor was previously responding and later stopped.  
> 
	KA> I believe this is the case we are discussing (i.e., the neighbor
was previously responding and later stopepd), not the case where a neighbor
that never responds but is perfectly operational.

> A
> neighbor that never responds may be perfectly operational, but doesn't
	>support Hello (or has Hello disabled).

> Hello-detected neighbor failure is an edge-triggered event.  You can
> detect an instant of failure.  You can not use it to detect the duration
> of that failure.
> 
> -- David