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

[Lou Berger <lberger@movaz.com>]

Ben,
         see below for topics not covered in other threads.

Lou

At 09:37 AM 12/11/2001, Ben Mack-Crane wrote:

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

[covered in other threads]


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

I can't speak for others.  My belief is that there is a very concrete 
definition.   I thought the text in the draft was clear as well, but let me 
try again:


         Switching Type: 8 bits

         Indicates the type of switching that should be performed
         on a particular link.  This field is needed for links that
         advertise more than one type of switching capability.
         This field contains one of the values advertised for the
         corresponding link in the routing Switching Capability
         field as defined in [GMPLS-RTG].

In other words, on links where one Switching Capability is advertised 
(which will be all the time for most equipment) Switching Type is set to 
the same value as advertised in routing.  On links where multiple Switching 
Capabilities are advertised, Switching Type is set to the value advertised 
in Switching Capability that matches the type of switching to be performed.

[I'll put the revised text in the next rev...]

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

There was text to this affect in one version.  We removed it based on a 
comment that as the drafts are not technology specific, the comment was 
inappropriate.  As we clearly can't please everyone all the time, the 
current text will stand.

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

The document will be updated when values are assigned in the appropriate 
places.  Most are marked by TBA.

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

no.  This precludes unique identification of the originator of the D bit.

Lou.

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