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

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

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.

2) G-PID types (19), (20), and (21) are repeats of (16), (17), 
   and (18).  Since the Siganl Type will indicate whether the
   LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant.

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

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.

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.

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

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.

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.

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?

Regards,
Ben Mack-Crane