The MPLS WG Archive

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

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?