Subject: RE: RSVP Hello

From: "Sanford, Bill" <[email-masked]>
Date: Fri, 24 Aug 2001 09:26:52 -0400

> -----Original Message-----
> From: Martin, Christian [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 6:42 PM
> To: 'Sanford, Bill'; [email-masked]'
> Subject: RE: RSVP Hello
> 
> 
> If I may comment here from an operational perspective...
> 
> I think the Hello mechanism, as specified, could be extended 
> to occur upon
> link initialization.  One of my most frustrating experiences 
> with RSVP state
> was when a new link was turned up with a fat-fingered 
> authentication key.
> Since there is no initial RSVP state acorss the link until a 
> PATH message
> needs to be sent, I was unaware of it until I had to 
> troubleshoot a label
> request across 13 routers.  Were it part of the specification to send
> Hello's and build an adjaceny during link intialization, it 
> would have been
> something detectable during configuration.

That sounds like a RSVP-TE that wants to be LDP. RSVP doesn't do this. Why
have LDP if RSVP is going to behave like it.

> Perhaps the draft can be extended to address this operational 
> need?  How
> difficult would it be to add:
> 
> "Upon link initialization, an interface MAY/SHOULD 
> immediately send an RSVP
> hello to the all routers multicast address on broadcast 
> media, or to its
> direct neighbor on ptp media.  For each RSVP hello received, 
> record the
> source IP address in the RSVP adjacency table.  Transmit hello's every
> configurable interval."

Adding more confusion to who is going to do what, when, and how it will
interoperate with RSVP (not-TE) and the omnipotent "cloud" brings another
level of frustration to the already miniscule timelines of project
completion. But, maybe it's just me. I cringe every time I hear "It will be
easy to add this fuctionality" or "how hard can this be?" 

> Of course, this example discusses authenticated RSVP 
> messages, but other
> types of issues can impair RSVP without easy detection.  As 
> it is today, you
> can either send a test PATH message across the network to 
> build state, or
> you can hope it works when you need it.  Neither is operationally
> acceptable, IMHO.

You can always submit a draft. ;-)

Regards,
Bill