Re: [Rsvp] RE: IANA Considerations for RSVP

[Bob Braden <braden@ISI.EDU>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Friends,

In trying to sort out how we should have handled RSVP_TE and all its
offspring, it is instructive to read RFC 2814 that describes the
Subnet Bandwidth Manager (SBM).  Like RSVP-TE and its offspring,
the SBM was an RSVP-like protocol for signaling at the link layer.
It is carefully documented as a distinct protocol, alhtough in
fact there are RSVP extensions for the SBM.  It leaves RSVP as
a network- (i.e., Internet-)layer protocol, as it was originally
designed.

I believe using the SBM approach for RSVP-TE would have avoided some of
the problems we are seeing today.  To imply, as I often see done, that
RSVP-TE is "just RSVP with a few extensions" was and is dishonest.  Its
semantics are fundamentally different in important ways, even if the
syntax is the same.  There is more to protocols than bit and byte
formats.

Do we need to have this discussion of 3 large mailing lists?

Bob Braden