Subject: Re: RSVP hello message

From: "Hong Liao" <[email-masked]>
Date: Wed, 9 May 2001 13:07:23 -0400

David,

Thanks for your reply.
Please see my comments.

>>RSVP must not be run synchronously.

>>If a Path message is sent out, it MUST NOT block waiting for a Resv to
>>come back.  It may receive a thousand other Path messages before then,
>>and it can't block them all.

[Julia]       I was confused. Ingress is the one which sends out Path
message,
                  and LSR will just forward the Path message sent from
Ingress to Egress.  In your email, you mentioned that
                    "It may receive a thousand other Path messages before
then", what does that mean?

>>Since Hello messages are not dependant on any RSVP state, it should be
>>possible to handle them as they arrive, without regard for what other
>>messages may or may not have been received.

>>Keep in mind that if you delay responding to a Hello message, your
>>neighbor may decide that you have reset, tearing down all your
>>sessions.  If the draft's recommended interval/multiple for Hello is in
>>use, you will only have 17.5ms to get your response out.

[Julia]      I agree with you.  Hello request message should be responsed
as soon as possible since the neighbour may tear down the session after the
Hello interval.

[Julia]     So I think if the Ingress sends out the Path message, and
before the Resv message back from the Egress router, if there is a Hello
request message sent from the neighbour, it should send out Hello ACK
message back and then wait the Resv back from Egress.  I hope I understand
correctly.

Julia

---

From: David Charlap <[email-masked]>
Date: Wed, 09 May 2001 13:40:17 -0400

Hong Liao wrote:
> message, and LSR will just forward the Path message sent from
> Ingress to Egress.

You do not understand how RSVP operates.

Transit routers do NOT just forward Path messages.  They must intercept
the messages (which is why the router-alert option is used), establish
path state, and then generate a new Path message (which will not be
identical to the one it received) to send downstream.

> In your email, you mentioned that "It may receive a thousand other
> Path messages before then", what does that mean?

Isn't this obvious to you?  A transit router doesn't work with just one
LSP.  A network may try to establish thousands of LSPs through a transit
router.

If you receive a Path, and then block the entire router waiting for the
matching Resv (as your comment about Hello messages seems to imly), you
will destroy the entire network's performance.  It is quite possible
that you can receive thousands of Path messages - corresponding to
thousands of LSPs - before you receive your first Resv message.

> before the Resv message back from the Egress router, if there is a
> Hello request message sent from the neighbour, it should send out
> Hello ACK message back and then wait the Resv back from Egress.  I
> hope I understand correctly.

Your router shouldn't be _waiting_ for anything.  It should handle every
message as it arrives.  If the proper handling means establishing
partial state, pending receipt of another message, then so be it.  It is
always wrong for a router to halt awaiting some specific kind of packet.

If the reason for this is not obvious to you, please arrange a meeting
with an engineer at your own site.  This is all very basic information
that everybody developing router software should know.

-- David