RE: Re: GMPLS Last Calls

[shehzad.mirza@bt.com]

Bala,

I am uncomfortable about talking about emails that were made in a different
forum, but I think some clarification to the OIF comments is required.

1. The email that Dan Spears sent to the OIF mailing list made it clear that
if there were no responses then the Paris Agreement that ONA Address shall
be capable of accommodating either of the IP or NSAP families would still
stand. It is wrong to assume that no responses meant that there was no need
to support NSAP.

2. It is unreasonable to expect unanimity between carriers given that they
have to support a diverse range of services and customers and legacy
equipment.  Though I'm sure that smart vendors will find ways of
accommodating the majority of their carrier customers requirements.

I do agree that the work has to continue to ensure that all issues are
addressed.

regards

Shehzad Mirza






> -----Original Message-----
> From:	Bala Rajagopalan [SMTP:BRaja@tellium.com]
> Sent:	01 June 2001 22:26
> To:	'ananth.nagarajan@mail.sprint.com'
> Cc:	wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org;
> Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET;
> lynn.neir@mail.sprint.com
> Subject:	RE: Re: GMPLS Last Calls
> 
> 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 
>