RE: GMPLS issues (was - GMPLS Last Calls)

[ananth.nagarajan@mail.sprint.com]

Bala,
Thanks for your reply.  Sorry it took so long to reply back. Please see 
in-line.

Thanks,
Ananth


bala>> > 1) Type of legacy equipment needing NSAP addresses 
bala>> > (also, is
bala>> > this optical network element or client equipment?)
bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
bala>> > (2002, 2005, and 2010)
bala>> > 3) Description of application in which this legacy equipment 
bala>> > will use UNI
bala>> > signaling
bala>I don't recall seeing any response. furthermore, the NSAP
bala>requirement was not unanimously endorsed by all carriers (at
bala>the OIF). 

>From our OIF representatives, although it was not unanimously endorsed, 
there was a significant demand for NSAP support. Well, NSAP is the main 
non-IP type of addressing that is required. The general requirement is 
to be able to support non-IP addresses (probably have an address 
translation from non-IP addresses to routable addresses).

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

NSAP support will be needed always (e.g. support for legacy DCC that 
uses NSAP).  So the timeframe requirement is now. 


Ananth>2) GMPLS is being defined based on assumptions about proprietary 
Ananth>transmission planes without those assumptions being specified. 
How can 
Ananth>we be sure that the control plane support is correct? How can we 
be 
Ananth>sure that it can be combined with other features?  Assumptions 
Ananth>regarding the transmission plane that can affect the control 
plane must 
Ananth>be clearly documented. This creates the additional related 
problem that 
Ananth>there is not a clear inter-working defined for interaction 
between 
Ananth>standard/proprietary control planes/transmission planes.

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

The concatenation/transparency issues are a concern.  In addition, 
management features such as manual protection switching, protection 
switching configuration, billing support (e.g. usage collection) etc 
need to be supported too.

Ananth>3) Assuring separation of the control plane from the data plane 
Ananth>continues to arise.. When the control plane fails it should not 
affect 
Ananth> existing connections.  Also if connections in progress are 
affected 
Ananth>then they should not leave partially setup connections - they 
should 
Ananth>fail gracefully informing the initiator. The GMPLS architecture 
Ananth>document mentions this separation, but it's not clear how the 
GMPLS 
Ananth>signaling specifications reflect the implications of this 
decoupling.  

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

Don't understand how the OIF UNI addresses this. Our concerns are more 
with respect to the NNI (internal separation of control and data). If 
this is not addressed, it is definitely a showstopper.  According to 
our OIF representatives, the OIF is looking at the IETF to specify 
these protocols.

To be specific, existing connections shouldn't be impacted when the 
control plane fails.

Ananth>4) Support for NSAP addresses and in general support such that 
control 
Ananth>plane addressing is independent of clients and vice versa.  Also 
Ananth>scalable naming/addressing scheme such as proposed in OIF.

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

Address translation of some form (for e.g. NSAP address translation) 
should be supported. See comment at the beginning of the email.

Ananth>5) Since the control plane may be supported via multiple 
protocols, 
Ananth>clear statement of what is - and  isn't - covered in the GMPLS 
Signaling 
Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed.

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

Recommend the development of applicability statements to cover this 
(otherwise, it is difficult to understand how the different pieces join 
together to form a coherent picture).

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

bala>BR: Any inconsistencies can be taken care of easily.

Like your comment. Hope it is as easy as it sounds :-) Mapping of 
terminology between standards bodies and also between different drafts 
in the IETF can be painful. Agreed however, that this is not a 
show-stopper.

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

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

Aware of the "iwata-draft". Are there others? 

Ananth>8) Reliable message transfer 

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

'soft-state' signaling protocols may not be acceptable for the optical 
control plane.  Live channels must not be dropped as a result of 
signaling message delivery failures (e.g. timer refresh failures)

Ananth>9) Security concerns have not been fully addressed, particularly 
at the 
Ananth> architectural level.  The use of separate control network may 
Ananth>necessitate the need for 24 hour staff to protect against 
'Denial of 
Ananth>Service' attacks as currently happens for IP router networks. In 
Ananth>general, admission control issues need to be addressed.

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

e.g. in the case of ATM UNI, if a user or users attempt too many call 
setups
simultaneously the switch control processor can become overloaded.  So, 
some form of call pacing/overload handling is needed.  Is there 
something similar in the GMPLS context for optical devices?
 

Ananth>10) The definition of transparency may be overly simplified.  
See 
Ananth>comments by Ben Mack-Crane:
Ananth>I think the debate on transparency indicates that the issue is 
not as 
Ananth>clear
Ananth>as we might think.  The OIF document you cite defines forms of 
Ananth>transparency
Ananth>that are very straightforward (flags 1,2) not the more complex 
forms in 
Ananth>the current GMPLS drafts (flags 3..10).  Also, these are easily 
Ananth>provided in
Ananth>O-E-O or O-O-O networks operating at the lambda level, but there 
is no
Ananth>standard for providing these over TDM multiplexed SONET/SDH 
links.

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

Agreed.

Ananth>If two vendors implement the same signaling but different TDM 
Ananth>multiplexing, that 
Ananth>doesn't achieve interoperability.  Is there any way in the 
drafts to 
Ananth>determine the scope
Ananth>of application of the various signaling elements (that is, 
whether they 
Ananth>apply to UNI or NNI, whether they apply to specific network 
Ananth>layers/technologies)?

Ananth>11) One summary of additional items with issues includes:
Ananth>- SDH/SONET transparency.
Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation.
Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities.
Ananth>- All kinds of end-to-end protection/restoration for any layer, 
except 
Ananth>the IP layer.

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

Potential show-stopper for deployment if restoration is not covered. 
Would agree that it could be addressed separately, though.

Ananth>- The label set object (only used for lambda issues).
Ananth>- LSP encoding type, bandwidth encoding and GPID have to be 
simplified 
Ananth>accordingly.
Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is 
not yet 
Ananth>defined).

bala>BR: A draft is forthcoming on this.

Have been made aware of this. Thanks.

Ananth>12) Support for paths across SONET/SDH gateways

bala>BR: Please clarify the issues/write drafts.

Quoting from Siegfried Giebl's email regarding 
<draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
"If I understand this document correctly, then you are completely
separating SONET and SDH signal types from each other,  thus making it
difficult to deal with paths across SONET/SDH gateways. As an 
alternative, I
suggest you work only with entities of level STS-1 (STM-0) and higher. 
On the other hand why don't you go the full way and also add 64 kb/s 
channels ?"

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

bala>BR: Same as above.

NSAP issue identified above. Elements within a link may not communicate 
using the signaling, i.e., legacy SDH/SONET equipment that does not 
participate in signaling (participate only in connectivity)

Thanks,
Ananth