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

[Richard Douville <Richard.Douville@alcatel.fr>]

On the specific section on the waveband switching, we also agree that
further work is required to achieve a consistent definition of waveband
switching in GMPLS.
In
http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt
and
http://www.ietf.org/internet-drafts/draft-dotaro-ipo-multi-granularity-01.txt
, we try to address some of the issues concerning waveband switching,
notably by the introduction of a waveband switch capable interface
(WBSC). We also try to remain as compliant as possible with the current
proposition (GMPLS-SIG) for the proposed enhancements. However, we
encourage that waveband switching issues be restudied before putting it
back on the standard track.
It is clear that an in-depth analysis of the constraints and
requirements for waveband switching could leed to best suited proposals. 
What are the next step : take it off GMPLS-SIG for further work (ad hoc
design team?), other ideas ?

Regards,
Richard Douville et al.


Ben Mack-Crane wrote:
> 
> 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

-- 
Richard Douville		Richard.Douville@alcatel.fr
Alcatel Research & Innovation	Photonic Networks Unit, URP
Route de Nozay			Tel: 33-1-69.63.44.31
F-91460 Marcoussis, France.	Fax: 33-1-69.63.18.65