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

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

See comments below.

Regards,
Ben

Lou Berger wrote:
> 
> 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.

Will these tell me that an FA is a type of switching?  I still think
that's not accurate.

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

Switching Type continues to be ill-defined.  I have heard that the real
definition is different from that given in the current drafts.  If the 
signaling information is not clearly defined and it's use described, we
can hardly expect interoperability.

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

It was discussed and rejected for TDM.  At least we should clarify the
applicability for this use of the Intserv Tspec.

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

Is this to be added to the IANA Considerations section or is it a new document?

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

Well?  Does anyone else have thoughts on this?

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

So perhaps we should change 

   1.  The egress node indicates its desire for deletion by inserting
       an Admin Status Object in a Resv message and setting the Reflect (R)
       and Delete (D) bits.

to

   1.  The egress node indicates its desire for deletion by inserting
       an Admin Status Object in a Resv message and setting the
       Delete (D) bit.


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