RE: Re: GMPLS Last Calls

[Bala Rajagopalan <BRaja@tellium.com>]

Ananth:

I see that some of the issues you bring up are
not show stoppers. Others need some clarification
from you (please see below). Also, if you
have any suggestions on how to resolve (what you
consider are) the issues, please post them/write
some drafts. This is the most constructive way
going forward.

With regard to NSAP, Dan Speers posted a note
in the OIF mailing list soliciting response to the following:

> > 1) Type of legacy equipment needing NSAP addresses 
> > (also, is
> > this optical network element or client equipment?)
> > 2) Rough estimate of number of UNI ports needing NSAP address 
> > (2002, 2005, and 2010)
> > 3) Description of application in which this legacy equipment 
> > will use UNI
> > signaling

I don't recall seeing any response. furthermore, the NSAP
requirement was not unanimously endorsed by all carriers (at
the OIF). 

It would also be nice if you can give some insight on
the timeline in which you need various features, and whether
the current GMPLS developments are inadequate within
that timeline. (We can always have a progression of features).

Please see below. On the whole, I believe that there is no
need for alarm or panic now (or even to be "very" concerned :-)).


Regards,

Bala


Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com 

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

BR: Please be more specific about what you need now that's missing, and
how we can address this?

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.

BR: I get the feeling you're referring to the concatenation/transperency
issues discussed recently. While the debate has been hot, there's
no show stopper here. Several suggestions are being considered for
clarifying standard/non-standard features supported.


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.  

BR: This issue has been discussed for the OIF UNI signaling (GMPLS
based, as you know), and solutions in the RSVP/LDP space have been
proposed (some drafts may be written).
This is also not a show stopper by any means.


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.

BR: NSAP, see my initial comments. The OIF is not dealing with
names/resolution, etc. This has been decided to be out of the
scope of UNI signaling, and considered as a separate function.


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.

BR: Don't understand this, but doesn't look like a major issue from
your phrasing.

6) Terminology is an issue (e.g.waveband switching, link)

BR: Any inconsistencies can be taken care of easily.

7) Transaction support for connection set-up and release is needed for 
connection oriented networks (e.g. crankback capability).

BR: Internet drafts have already been written on crankback. I suggest
that you please consider writing some drafts if there is something
missing.

8) Reliable message transfer 

BR: Very much a part of signaling. the OIF work has considered this
aspect also. 

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.

BR: Please elaborate on these, specifically, what's new in the
context of GMPLS.

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.

BR: This is an ongoing topic of discussion. Doesn't break down
the rest of the proposal.

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.

BR: Restoration is not actually covered in the current set of drafts.
An earlier thread discussed this, and my suggestion is that this
feature be dealt with separately.

- The concept of LSC and FSC layers, i.e. concept of lambda and fiber 
switching.

BR: What are the issues here?

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

BR: A draft is forthcoming on this.

12) Support for paths across SONET/SDH gateways

BR: Please clarify the issues/write drafts.

13) Compatibility is required/desired with legacy SDH/SONET equipment 
[and also legacy DWDM]

BR: Same as above.

14) Just so that we don't stop at 13 :-)


Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com