Subject: RE: Hello Extension - destination IP address

From: "Hariom P" <[email-masked]>
Date: Tue, 13 Nov 2001 14:28:04 -0800

I totally agree with David. RSVP hellos are designed for "faster node 
failure detection" and there is no point in doing this detection when no 
RSVP sessions are active between two peers..

with regards,
hmp

>From: "Feng, Mark" <[email-masked]>
>To: "'David Charlap'" <[email-masked]>,        "[email-masked]'" 
><[email-masked]>
>Subject: RE: Hello Extension - destination IP address
>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
> >

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

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

That's not the point I am trying to make. If it is so desired that, when
there is no active sessions, the Hello exchange is stopped, this should be
done even when the neighbours are configured, instead of discovered.

As to whether to maintain the Hello exchange when there is no active
sessions, my only concern is that, by stopping the exchange, the RSVP
neighbour might think that the communication has been lost. Whether this is
OK as to the original intent of the RFC, I am not sure.

- Mark

> From: Hariom P [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 2:28 PM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: "Feng, Mark" <[email-masked]>
Date: Tue, 13 Nov 2001 15:21:02 -0800

> Sent: Tuesday, November 13, 2001 3:07 PM
> To: [email-masked]'
> "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.
>

Right.
 
> > In either case, wouldn't the Hello state machine itself eventually
> > settle to the correct state in the above cases?
> 
> 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.
>

I agree. It makes more sense to start/re-start the Hello when we receive
messages (again) from the neighbour.

---

From: "Arvind, K" <[email-masked]>
Date: Wed, 14 Nov 2001 13:03:32 -0500

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

> From:	David Charlap [SMTP:[email-masked]]
> Sent:	Wednesday, November 14, 2001 12:00 PM
> To:	[email-masked]'
> "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?
> >> 
> >> 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

---

From: "Feng, Mark" <[email-masked]>
Date: Wed, 14 Nov 2001 10:21:06 -0800

> From: Arvind, K [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 10:04 AM
> To: 'David Charlap'
> Cc: [email-masked]'

I think, based on the previous discussion, stopping the Hello exchange is to
save CPU/bandwidth. It's been mentioned previously that, even if the Hello
is not stopped, the Hello state machine itself will come to the correct
state.

In case the neighbours are configured, there might be issues related to how
much control/responsibility the user should have, e.g. stopping/re-starting
of Hello.
In case of discovering neighbours by "snooping" messsages received, the
Hello machine is controlled entirely by the implementation. In this case, I
feel you can do either, i.e. stopping/continue when all the states are torn.

One curious thing mentioned above is the "suspension" of Hello. How's that
work? I don't remember seeing that in the RFC. Thanks.

- Mark

---

From: "Arvind, K" <[email-masked]>
Date: Wed, 14 Nov 2001 15:34:16 -0500

> neighbor becomes unreachable for whatever reason - this can 

	>>work? I don't remember seeing that in the RFC. Thanks.

	Mark:

	The terminology "go into a suspended state" is not from the draft.
By this phrase, I meant the ability to time out a neighbor and then to
choose not to reinitiate HELLOs, perhaps until the neighbor is rediscovered
through other means. (See section on "Hello Usage"):

	"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 ...
	When communication is lost or presumed to be lost as described
above, a node MAY re-initiate HELLOs."

	Regards,
	Arvind.

> From:	Feng, Mark [SMTP:[email-masked]]
> Sent:	Wednesday, November 14, 2001 1:21 PM
> To:	'Arvind, K'; 'David Charlap'
> Cc:	[email-masked]'