The MPLS WG Archive

["Martin, Christian" <cmartin@gnilink.net>]

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

Bill, I'm not sure I'd go that far. ;)  Adding neighbor discovery does not
completely warp the protocol.  Some may say (read: me) that it enhances it.

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

I apologize for trivializing the complexity of implementing _anything_ that
adds functionality outside the original spirit of the protocol.  I agree
that this is often the cause of many problems with software stability on
today's implementations - hacks for customers that aren't properly thought
out by those who haven't followed the implementation and design of the
protocol from the beginning.  But we are talking about RSVP-TE here, which
has been extended to support new functionality that was outside the scope of
its original design.

Perhaps this has been discussed before (I need to review the archives -
apologies if it has), but IMHO, a distributed control plane that is
non-verifiable during configuration is inadvisable.  Imagine IP without
ICMP, on an Dual IS-IS network.  The core of the network could be IP-less,
and in theory, the IP-enabled edges would have  a path to each other.  But
packets would not flow.  Just having an end-to-end IP path does not mean
that RSVP messages can get through the network end-to-end, and there is no
easy way to detect the location of the hole.

> 
> You can always submit a draft. ;-)

Good idea!

> 
> Regards,
> Bill
>