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

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

See comments below.

Regards,
Ben

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

I don't recall seeing anything on the list about the reasoning about this.
can someone provide a pointer to where this was described?

Since LSP Encoding type is intended to describe the LSP for transit nodes
and G-PID is intended to describe the LSP contents for the purpose of
terminating it at the ends, information relevant only to termination
should be conveyed in G-PID.

Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy"
would make this clearer.

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

Thanks for fixing this.  The new (19) should probably be "VC-11 in TU-12."

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

I would gladly suggest wording if I understood the use for this.  It has no use
for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda
or Fiber.  However, several of the examples are not appropriate for this.
Perhaps this should be moved to a technology specific document since it is
not really general anyway.

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

Does anyone else see an inconsistency here?  I would be interested in hearing
from someone who understands the waveband content.

I am concerned that the waveband proposal is speculative and not ready to
progress toward RFC status.  Perhaps the waveband content should be removed
and the sections marked FFS.

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

This is not clear from the definition.  The bit is defined as indicating
the LSP is a secondary (or protecting) LSP and in 1+1 protection the
secondary LSP may not be used for extra traffic.

Perhaps the problem here is that protection features are being defined
before the protection framework and requirements are done.  Is this
presupposing some particular outcome of the recovery work in CAMP?

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