Re: Moving right along ... generalized-signaling-06

[Lou Berger <lberger@movaz.com>]

At 01:09 PM 10/29/2001, Ben Mack-Crane wrote:

>After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have
>a few comments and questions:
>
>1) There seems to be no difference as far as label allocation
>    is concerned between LSP Encoding Types Ethernet V2/DIX (2)
>    and Ethernet 802.3 (10).  One Encoding type would seem to
>    be sufficient.

I agree, but some feel that this is needed to properly establish LSPs in 
systems what would terminate each type differently.

>2) G-PID types (19), (20), and (21) are repeats of (16), (17),
>    and (18).

see latest draft...

>   Since the Siganl Type will indicate whether the
>    LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant.

the fields serve different purposes.


>3) G-PID type (37) Lambda seems insufficient (too vague) to
>    support interoperability.  Is there any practical use for this
>    value?

yes, it's needed when doing fiber/port switching.

>4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it
>    is useful to define discrete values to identify the bandwidth of the
>    LSP."  For SONET/SDH this is unnecessary given the Signal Type is
>    provided.  For the other non-packet LSP types (Lambda and Fiber)
>    it is not clear that all the values cited in the example are relevant
>    (for example, a DS0 lambda would seem wasteful...).


>    This is confusing, and should be clarified.  In fact, a description of
>    exactly why this field is required is needed.

We've gone over this text multiple times.  Do you have any suggested wording.

>5) The Waveband ID "is selected by the sender and reused in all
>    subsequent related messages."  This seems more the sort of thing that
>    should be negotiated by LMP rather than during connection setup.

The ID has significance within signaling context of the sender. (like 
message id). I don't think using another layer of complexity for provate 
information makes sense.

>6) The definition of Start Label and End Label in waveband switching seems
>    inconsistent with the behavior described in generalized-rsvp-te-05.

I don't see this.  Feel free to suggest wording.

>
>7) In Protection Information it states "The resources allocated for a
>    secondary LSP MAY be used by other LSPs until the primary LSP fails
>    over to the secondary LSP."  This may not always be the case.  An
>    explicit flag indicating whether or not extra traffic may use the
>    secondary path resources is needed.

??? This is the purpose of this bit.

>8) The Administrative Status Information includes a bit indicating
>    "Administratively down," but there is no reference to a definition
>    of this state.  Is this intended to mirror the MIB variable?  If so,
>    a reference is needed.  If not, more definition is needed to ensure
>    the local behaviors driven by this bit are in some way consistent.
>    Whether this state defintion is consistent with current transport
>    network operations should also be considered.

Per the document:
   The actions taken by a node based on a state local decision.

>9) In Interface Identification, the IP Address for types 3,4, and 5 is
>    described as possibly "an IP address associated with the router ID."
>    Is this intended to mean the Router ID or any IP address owned by
>    the node?  It seems the Router ID is the simplest solution, but the
>    wording is not clear.

Text has been reworded in 07. It's any IP address configured on a node.

>10)In describing the Interface ID the statement "The special value
>    0xFFFFFFFF can be used to indicate the same label is to be valid
>    across all component links."  What is the "label" referred to in
>    this case?

I'll reword in the post IETF last call rev of the document.

Lou

>Regards,
>Ben Mack-Crane