RE: GMPLS Last Calls

[ananth.nagarajan@mail.sprint.com]

All,
Sprint has remained fairly quiet on the issues regarding the control 
plane as we have been working to formulate our internal views.  We are 
very concerned about the many issues that have been raised regarding 
the proposed draft GMPLS standard over the past few weeks. These are 
the collective opinions of me and my colleagues who are 
involved/interested in optical control plane issues.

Issues raised by others and some added here are of particular concern.  
In order to move forward, it is recommended that the scope of this 
version of the standard be re-evaluated and all issues related to that 
scope of work resolved before standardization. We tried to include here 
as many items that we could although it is not all inclusive as there 
were so many issues raised.  We believe it is not in the best interest 
of any of the parties involved to standardize as things stand with so 
many known issues outstanding. Depending on determined scope (i.e. this 
list could change depending on scope of GMPLS determined by the group), 
here are some items that we currently believe must be addressed before 
final approval:
1) GMPLS is being specified without clear requirements identified 
first.  As such, there is no way to ensure all needed features have 
been provided by the specification.  For example, control plane 
management requirements have not adequately been identified and there 
is concern that the addition of management requirements may cause 
modifications to GMPLS functions/protocol.
2) GMPLS is being defined based on assumptions about proprietary 
transmission planes without those assumptions being specified. How can 
we be sure that the control plane support is correct? How can we be 
sure that it can be combined with other features?  Assumptions 
regarding the transmission plane that can affect the control plane must 
be clearly documented. This creates the additional related problem that 
there is not a clear inter-working defined for interaction between 
standard/proprietary control planes/transmission planes.
3) Assuring separation of the control plane from the data plane 
continues to arise.. When the control plane fails it should not affect 
existing connections.  Also if connections in progress are affected 
then they should not leave partially setup connections – they should 
fail gracefully informing the initiator. The GMPLS architecture 
document mentions this separation, but it's not clear how the GMPLS 
signaling specifications reflect the implications of this decoupling.  
4) Support for NSAP addresses and in general support such that control 
plane addressing is independent of clients and vice versa.  Also 
scalable naming/addressing scheme such as proposed in OIF.
5) Since the control plane may be supported via multiple protocols, 
clear statement of what is - and isn't - covered in the GMPLS Signaling 
Description, RSVP Extensions, LDP Extensions drafts is needed.
6) Terminology is an issue (e.g.waveband switching, link)
7) Transaction support for connection set-up and release is needed for 
connection oriented networks (e.g. crankback capability).
8) Reliable message transfer 
9) Security concerns have not been fully addressed, particularly at the 
architectural level.  The use of separate control network may 
necessitate the need for 24 hour staff to protect against 'Denial of 
Service' attacks as currently happens for IP router networks. In 
general, admission control issues need to be addressed.
10) The definition of transparency may be overly simplified.  See 
comments by Ben Mack-Crane:
I think the debate on transparency indicates that the issue is not as 
clear
as we might think.  The OIF document you cite defines forms of 
transparency
that are very straightforward (flags 1,2) not the more complex forms in 
the current GMPLS drafts (flags 3..10).  Also, these are easily 
provided in
O-E-O or O-O-O networks operating at the lambda level, but there is no
standard for providing these over TDM multiplexed SONET/SDH links.

If two vendors implement the same signaling but different TDM 
multiplexing, that 
doesn't achieve interoperability.  Is there any way in the drafts to 
determine the scope
of application of the various signaling elements (that is, whether they 
apply to UNI or NNI, whether they apply to specific network 
layers/technologies)?
11) One summary of additional items with issues includes:
- SDH/SONET transparency.
- SDH/SONET arbitrary concatenation, flexible concatenation.
- AUG-X, TUG, STS Groups signal types and LSP capabilities.
- All kinds of end-to-end protection/restoration for any layer, except 
the IP layer.
- The concept of LSC and FSC layers, i.e. concept of lambda and fiber 
switching.
- The label set object (only used for lambda issues).
- LSP encoding type, bandwidth encoding and GPID have to be simplified 
accordingly.
- MPLS extensions to control G.709 (since multiplexing, etc is not yet 
defined).
12) Support for paths across SONET/SDH gateways
13) Compatibility is required/desired with legacy SDH/SONET equipment 
[and also legacy DWDM]
14) Just so that we don't stop at 13 :-)

Thanks,
Ananth