Subject: [Tsvwg] Review of RSVP Proto

From: "James M. Polk" <[email-masked]>
Date: Mon, 24 Mar 2008 17:52:09 -0500

TSVWG

This is my chair review of
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-proto/

This is also an excellent document.

I have a few comments

About the Abstract

The RFC-Editor will make a push for you to at least start the 
Abstract on the first page...

Intro, 2nd paragraph, has
   "Since both the data sender and receiver may be unaware of RSVP, there
   are two distinct RSVP Proxy use-cases."
                               ^^^^
                               add

As stated in the Approaches review, I think there are 3 use-cases, 
the 3rd being proxy to proxy where both endpoints are RSVP-unaware.

Section 2, there's this bullet, that shouldn't be a bullet

   o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
      Regular RSVP Router are all relative to one unidirectional flow.
      A given router may act as the RSVP Receiver Proxy for a flow, as
      the RSVP Sender Proxy for another flow and as a Regular RSVP
      router for yet another flow.

This paragraph should *not* be bulleted, and should be indented 
differently, something like this

   Note: that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
      Regular RSVP Router are all relative to one unidirectional flow.
      A given router may act as the RSVP Receiver Proxy for a flow, as
      the RSVP Sender Proxy for another flow and as a Regular RSVP
     router for yet another flow.

Section 3, there's this message flow in Figure 1 (and in Figure 2 for 
that matter)

  |----|       ***       ***       ***       |----------|     |----|
  | S |--------*r*--------*r*--------*r*--------| RSVP    |------| R |
  |----|        ***       ***       ***       | Receiver |     |----|
                                                | Proxy   |
                                                |----------|

      ************************************************************>

      ===================RSVP===================>

      --Path---> --Path---> --Path---> --Path--->

      <---Resv-- <---Resv-- <---Resv-- <---Resv--

It may be getting late here, and a reservation is in the direction of 
the PATH messages, yet this diagram has the reservation *before* the 
PATH message, which is inconsistent from how you have it in 
Approaches I believe, and what is normally possible from RSVPv1 
(unless I missed that part ;-)

In section 3.1.3, in the 4th paragraph, starting with " 
Optionally..." there is a 2119 "MAY", when this appears to be a 
configuration option, and not for future extensions for implementers.

In other words, I'm not sure this is the correct usage of 2119 
language. "MAY" means there could be a future RFC which specifies 
this as a SHOULD or MUST. Here I think you man 2119 "OPTIONAL", 
whereby support is the choice the implemtator to code or not. If this 
feature SHOULD be coded, but optionally configured for usage, then 
this needs to be either a SHOULD or a MUST, where configuration 
decides if this option is used or not.

In the same paragraph as the above MAY, there is a comment about "old 
router". Does this really mean a non-RSVP capable router or a router 
that doesn't support this extension. I'd recommend saying which is true.

Cheers,
James
IETF TSVWG co-chair

              ***********************************
     "It should NEVER be inconvenient to do the right thing"