Subject: RE: Hello Extension - destination IP address

From: "Arvind, K" <[email-masked]>
Date: Wed, 14 Nov 2001 10:50:21 -0500

Please see comments (tagged KA>) in-line.

Regards,
Arvind.

"Feng, Mark" wrote:
> David Charlap wrote:
>>
>> If you do this (discovering neighbors for Hellos by snooping other
>> RSVP packets), then you may want to stop sending Hellos when the
>> all of the 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.
> 
> 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.

KA> If the peer were non-existent, wouldn't the Hello protocol detect that
and 
stop sending Hellos automatically? 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.

> 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.

KA> Wouldn't the HELLO protocol automatically detect that the neighbor is
down in this case as before?

---

From: David Charlap <[email-masked]>
Date: Wed, 14 Nov 2001 12:00:23 -0500

"Arvind, K" wrote:
>> 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.

> According to
> "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.

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.

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.

>> 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.  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