[Rsvp] RE: IANA Considerations for RSVP

[Bob Braden]

  *> 
  *> 
  *> 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,

I apologize for a misstatement here; I should not have singled out
RSVP-TE for abuse.  In fact, there are at least two or three distinct
flavors of RSVP offspring: RSVP-TE for MPLS setup, the OIF folks who
have an RSVP-like protocol for link-layer signaling at the UNI,
and maybe the ATM folks.  (I assume the GMPLS folks fall into the
RSVP-TE camp.) The same comment about SBM applies equally to all these
"illegitimate offspring" of RSVP.

(They are each fine upstanding protocols in their own right, no
doubt; it is only their parentage that is shady.)

Bob Braden

  *> 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
  *> _______________________________________________
  *> Rsvp mailing list
  *> Rsvp@mailman.isi.edu
  *> http://mailman.isi.edu/mailman/listinfo/rsvp
  *>