BOUNCE ccamp@ops.ietf.org: Header line too long (>128)

[owner-ccamp@ops.ietf.org]

>From owner-mpls@UU.NET Thu Jun 21 17:03:54 2001
Message-ID: <46f301c0faae$bebd1490$0e03ca0a@cp98suwbm02>
Date: Thu, 21 Jun 2001 17:03:19 -0700
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
MIME-Version: 1.0
To: <naderv@msn.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>
Sender: <owner-mpls@UU.NET>
Precedence: bulk

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