Subject: RE: Hello Extension - destination IP address

From: "Feng, Mark" <[email-masked]>
Date: Tue, 13 Nov 2001 13:26:32 -0800

I agree with most of the comments; but I have one doubt. Please see comments
below.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 9:35 AM
> To: [email-masked]'
> Subject: Re: Hello Extension - destination IP address
> 
> 
> "KHARE,MADHUKAR (A-NewEngland,ex1)" wrote:
> > 
> > This is regarding the Hello extension for RSVP.  We are unsure what
> > to use for the destination IP address for a Hello Request message.
> > 
> > The draft just says "The IP destination address is the IP address
> > of the neighbor node".  When the first Hello Req is sent out, we
> > don't know the address of the neighbor node".
> > 
> > Are we supposed to use a broadcast IP address first time around?
> 
> No.  Hellos are not sent to broadcast addresses.  They are 
> not used for
> discovering neighbors.
> 
> If your router doesn't have neighbor addresses configured, then you
> won't know your neighbor addresses until after you receive 
> other packets
> from them - like Path and Resv messages.  Once you know the 
> address, you
> can begin sending Hellos.
> 
> 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? 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. This should be applicable in the
case when the neighbour is configured.

By stopping the Hello exchange, the neighbour might incorrectly think that
there is a problem communicating with the current node.
 
> -- David

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Nov 2001 17:40:36 -0500

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

> 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: Kireeti Kompella <[email-masked]>
Date: Tue, 13 Nov 2001 22:02:54 -0800 (PST)

> Why is it necessary to stop sending the Hello in this case?

Excellent question.

Kireeti.

---

From: Eric Gray <[email-masked]>
Date: Wed, 14 Nov 2001 10:30:02 -0500

David,

    Sorry, I don't buy this.  Entirely aside from whether or not this is what
was being proposed, it doesn't make sense to conclude that a peer has gone
away because it has torn down all current signaling state.  Not that I will
necessarily agree that it makes sense to 'discover' RSVP peers using setup
messages, either...

You wrote (in part, and out of context):

> ...
> ...

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

---

From: Eric Gray <[email-masked]>
Date: Wed, 14 Nov 2001 12:03:30 -0500

> David,
>
>     Interesting.  Are you perhaps referring to 'reading you own messages' as
> snooping?  If you are, then the rest of what you say makes perfect sense.

For the sake of clarity, 'your own messages' relates to messages addressed to
you rather than messages sent by you - wher 'you' refers to the implementation
or peer in question.

>
>
> You wrote:
>
> > Eric Gray wrote:
> > > David Charlap wrote:
> > >>
> > >> If you discover a peer by snooping RSVP setup messages, then it
> > >> makes sense to "un-discover" it by snooping RSVP tear messages.
> > >
> > > Sorry, I don't buy this.  Entirely aside from whether or not this
> > > is what was being proposed, it doesn't make sense to conclude that
> > > a peer has gone away because it has torn down all current signaling
> > > state.  Not that I will necessarily agree that it makes sense to
> > > 'discover' RSVP peers using setup messages, either...
> >
> > OK then.
> >
> > How do you propose that a router determines what addresses to send
> > hellos to?  Do you want to mandate that this be configured?  If not, how
> > would you propose learning about neighbors?  Inspecting the routing
> > table for peers may result in a lot of non-RSVP neighbors, which you
> > will be flooding with Hellos for no good reason.  The only way to ensure
> > that the neighbor is using RSVP is to note any RSVP messages that may
> > come from that neighbor.
> >
> > Once you use this mechanism, how would you propose removing a neighbor
> > from your list of neighbors to send hellos to?  Surely you don't want to
> > keep sending them forever, simply because you received one message a
> > long time ago.  When do you stop if you don't stop when the last Path
> > adjacency goes away?
> >
> > Finally, keep in mind that the purpose of Hello is to summarily tear
> > down state without waiting for a soft-state timeout.  If you have no
> > established state, what do you gain be sending them?
> >
> > -- David
>
> --

---

From: David Charlap <[email-masked]>
Date: Wed, 14 Nov 2001 11:48:31 -0500

OK then.

-- David

---

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

Eric Gray wrote:
> 
> Interesting.  Are you perhaps referring to 'reading you own
> messages' as snooping?  If you are, then the rest of what you say
> makes perfect sense.

Yes.  I'm talking about using incoming Path/Resv messages for a purpose
additional to simply creating Path/Resv state.

When you receive a Path or a Resv from a neighbor, and the TTL indicates
that there were no non-RSVP routers between you and the neighbor, you
can assume that the address in the HOP object is a directly-attached
RSVP-capable router.  It is therefore an address you may want to start
exchanging Hellos with.

Once the last amount of state goes away, however, you can no longer make
that assumption.

If you continue sending Hellos, you can still detect a failure, if you
stop getting acknowledgements, or if the neighbor's instance ID
changes.  If the ID changes, you can even continue sending Hellos, since
you know that the box is still there.  If the acknowledgements stop,
however, you don't know if the box is administratively down, rebooting,
crashed, or turned off.

And it serves no purpose (other than perhaps in a debugging effort) to
detect a neighbor failure when there is no established state, since
there's nothing to tear down.

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 14 Nov 2001 13:21:33 -0500

David,

    As I said, this makes perfect sense - though I would be inclined to
look at at least two aspects of this behavior in a different way.  For
one, I do not think of this as 'peer discovery' so much as I realize that
the purpose of the 'Hello' messages is to prolong the validity of state
information (in this sense, calling them 'Hello' messages, rather than
'Keep Alive' messages is misleading).  Clearly, there is no point in
preservation of an empty set of state information.  For the other, I am
inclined to think of snooping as listening to messages not intended to
the 'snooping' implementation.  I guess you could think of this as
snooping, if - in a specific implementation - there is an intermediate
(software) entity that redirects RSVP setup and teardown messages
sending them to a separate (software) entity.  But that reflects a
particular implementation's view of the world.

---

From: David Charlap <[email-masked]>
Date: Wed, 14 Nov 2001 16:48:46 -0500

Eric Gray wrote:
> look at at least two aspects of this behavior in a different way.
> For one, I do not think of this as 'peer discovery' so much as I
> realize that the purpose of the 'Hello' messages is to prolong the
> validity of state information (in this sense, calling them 'Hello'
> messages, rather than 'Keep Alive' messages is misleading).

No.  The purpose is exactly opposite.  The purpose of RSVP Hello is to
terminate connections earlier than they would otherwise be terminated
(via soft-state timeouts.)

The only way to keep a connection alive is to refresh it (using the
features of RFC 2961, if available.)

> Clearly, there is no point in preservation of an empty set of state
> information.  For the other, I am inclined to think of snooping as
> listening to messages not intended to the 'snooping' implementation.
> I guess you could think of this as snooping, if - in a specific
> implementation - there is an intermediate (software) entity that
> redirects RSVP setup and teardown messages sending them to a
> separate (software) entity.  But that reflects a particular
> implementation's view of the world.

Maybe it was a bad choice of words.

I've always pictures RSVP Hello as something that can run independantly
of the rest of RSVP, issuing "tear all state of this interface" commands
to RSVP when Hello detects a neighbor failure.

In this sense, if non-Hello packets have an affect of Hello processing
it can be thought of as snooping.  But you're right that this sense is
not necessarily applicable, depending on how you visualize the protocol
and/or implement it.

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 14 Nov 2001 11:57:41 -0500

David,

---

From: Ping Pan <[email-masked]>
Date: Thu, 15 Nov 2001 09:30:05 -0800

David,

> (via soft-state timeouts.)

Agree. In addition, for interfaces where the hardware cannot generate 
interface up/down signal (such as Ethernet), Hello is used for the LSR 
to detect the status of the RSVP logic connection with a "neighbor". If 
the connection is down, RSVP needs to reroute the traffic for all 
effected sessions....

Yes. And RSVP refresh intervals can be different at every link, and can 

be dynamically adjusted when using refresh reduction.

> to RSVP when Hello detects a neighbor failure.

Exactly.

> not necessarily applicable, depending on how you visualize the protocol

In this regard, RSVP Hello works similar to that of BGP. RSVP neighbors 
(peers) aliveness can be maintained via RSVP messages other than Hello. 
But if there is no other RSVP messages on the wire, Hello is the one to use.

> -- David

Take care!

- Ping