Re: Moving right along ... generalized-rsvp-te-05

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt
I have the following comments and questions:

1) In the procedures regarding the Generalized Label Request 
   object, the statement is made that "The node may either 
   directly support the LSP or it may use a tunnel (FA), 
   i.e., another class of switching."  A Tunnel (FA) is a type
   of link, not a class of switching.  This adds to the 
   confusion I've noted about the need for and use of Switching 
   Type.

2) Bandwidth Encoding use of the Intserv Tspec object seems
   quite unusual since this use is not consistent with existing
   uses of this object, and new uses could easily use a new
   C-Type.

3) In the procedures for Generalized Label it states "If the label is
   unacceptable then the recipient MUST generate a ResvErr message with
   a "Routing problem/MPLS label allocation failure" indication."
   I think "Unacceptable Label Value" would be more appropriate.

4) In the Waveband Switching section it says "For compatibility reasons, 
   a new RSVP C-Type (3) is assigned."  What is the compatability
   problem this is solving?

5) In the Label Set object, why is the Label Type field 14 bits if 
   only the low order 8 bits are used?

6) Some new error strings are defined, "Label Set" and "Unsupported Link 
   Protection," but no values or placeholders are included. Where are new 
   error values to be documented?  

7) The Notify message is intended to "enable expedited notification of 
   failures," but it relies on the IP layer which may be affected by the
   failure that the Notify is reporting.  This could defeat the goal
   of rapid notification.  Without some means of guaranteeing the Notify
   doesn't have to wait for IP routing convergence to be delivered, 
   it isn't a satisfactory solution.

8) The description of the C-Type field in the Label ERO subobject suggests
   that this subobject contains a Label Object.  Is this the case, or does
   the Label ERO subobject simple contain label values, and the C-Type
   matches the C-Type that would be used if the same label values were
   included in a Label object?

9) In deleting an LSP from the egress, the R bit is set in the Admin Status
   object.  The ingress responds with a PathTear message.  Does this PathTear
   contain the Admin Status object or should the R bit be cleared?

10)The Notify message may contain a new setting of the Admin Status.
   Under what conditions would an intermediate or egress node change
   Admin Status?  What happens if the Notify receiver is not the ingress?

11)In Interface Identification it says "Data channels are specified from the view point
   of the sender of the Path message."  Is this true even for Resv messages
   or should it read "Data channels are specified from the viewpoint
   of the sender of the message."?

12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be 
   suppressed during this waiting period."  I assume this is refreshes
   toward the failed neighbor, not to all neighbors for that LSP.  True?

Regards,
Ben Mack-Crane