Subject: RE: Hello Extension - destination IP address

From: "Feng, Mark" <[email-masked]>
Date: Tue, 13 Nov 2001 14:56:58 -0800

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 2:41 PM
> To: [email-masked]'
> Subject: Re: Hello Extension - destination IP address
> 
> 
> "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.
> 
> If you discover a peer by snooping RSVP setup messages, then it makes
> sense to "un-discover" it by snooping RSVP tear messages.
> 
> > 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 exchange timed out before the normal cleanup timer
expiry? In either case, wouldn't the Hello state machine itself eventually
settle to the correct state in the above cases?

But I agree that it is more efficient to stop the Hello exchange.

Thanks for the clarification.

- Mark

> > This should be applicable in the case when the neighbour is
> > configured.
> 
> When you explicitly configure a neighbor's address, then it 
> makes sense
> to assume that the configuration is correct.
> 
> > By stopping the Hello exchange, the neighbour might incorrectly
> > think that there is a problem communicating with the current node.
> 
> So what?  If all state is gone, then what is the neighbor 
> going to do? 
> There's nothing left to tear down or signal an error for anyway.
> 
> -- David
>

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Nov 2001 18:06:41 -0500

"Feng, Mark" wrote:
>>
>> 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 exchange timed out before the normal cleanup
> timer expiry?

Probably.  But if carrier is lost on the fiber, that will likely be
detected in hardware before the Hello times out.

> In either case, wouldn't the Hello state machine itself eventually

Yes, it will successfully tear everything.  But do you want to restart
Hellos immediately or wait for new Path state?

IMO, if a neighbor address is configured, it makes sense to restart
Hellos immediately after tearing down local state, so you can know when
the neighbor comes back up (when you start getting Hello Acks back). 
But it would be foolish to do this if you're auto-discovering your
neighbor, because that neighbor might have disappeared from the network
altogether.

-- David