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

[Lou Berger <lberger@movaz.com>]

At 03:08 PM 10/29/2001, Ben Mack-Crane wrote:

>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."

please see the routing drafts.

>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.

I think either approach work.  This topic was discussed by the authors at 
least 12-18 months. The current approach was decided then.

>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.

okay.

>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?

simply to distinguish types.  I remove the text to avoid such confusion in 
the future.

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

for CR-LDP compatibility.

>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?

As part of IANA assignment.

>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?

per the draft:

       Label: Variable

          This field identifies the label to be used.  The format of this
          field is identical to the one used by the Label field in
          Generalized Label, see Section 3.2.1.

>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?

It's not in the BNF, so no it's not included.

>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?

It may be used at any time that a PathErr or ResvErr is generated.

>  What happens if the Notify receiver is not the ingress?

same action as would be taken if/when the corresponding message is received.

>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."?

current text is correct.

>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?

yes.

thanks for the comments,
lou

>Regards,
>Ben Mack-Crane