ietf
[Top] [All Lists]

Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

2004-08-24 10:27:16
  *> 
  *>  - RSVP doesn't have "network indication of support": the nodes keep 
  *> spewing RSVP messages to the network even if every router is happily 
  *> ignoring them, and the destination node does not support them.
  *> 

Pekka,

Well, actually, that's not true.  RSVP does have mechanisms to detect
nodes that do not support it, and nodes that do support it but fail
to respond.

  *> Possible fix: have the signalling engine contact the local network 
  *> administrator with a protocol to confirm if it supports the 
  *> reservations or not.

This is an ideal application of RFC 3751.


  *> 
  *>  - path-coupled messages require significant processing at the
  *> routers.  This probably needs to happen in "slow path", in software.  
  *> A draft mentioned an implementation being able to support a whopping
  *> (NOT!)  7000 sessions.  That works for the first hop, and possibly
  *> even to a degree inside an enterprise where you can have software
  *> based routers and not too many hosts, but it's not a useful model for
  *> larger routers, deployed at more central places in the network.
  *> 

Please see RFC 2998 and RFC 3175.

 *> Possible fix: instead of on-path processing, contact a node off-path,
  *> which performs all the processing, checks the policies, etc., and
  *> ensures that appropriate QoS metrics are configured at the appropriate
  *> routers (these could be bulk DiffServ guarantees, more specific
  *> reservations and whatever).
  *> 
  *>  - the policy checks are distributed to all the routers: the real
  *> policy, within an administrative domain, is however made in a
  *> centralized fashion, so it would be useful not to have to distribute
  *> the policy to every router, but rather just process it in one place.
  *> 
  *> Possible fix: BB model provides this capability.

RSVP does not put the policy in every router. Have you ever heard
of COPS?

The rest of your message seems to move away from tell us what
is wrong with RSVP in particular and path-coupled signaling in
general, to telling us what is wrong with Integrated Service.
Those are old, and endless, arguments, but they don't seem to
have anything to do with the topic you started on.

Bob Braden

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf