Subject: RE: GMPLS Last Calls

From: [email-masked]
Date: Fri, 1 Jun 2001 11:27:49 -0500

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 01 Jun 2001 09:50:50 -0700

> These are the collective opinions of me and my colleagues

as the ietf is composed of individuals, i have not read your irrelevant
message.  should you have personal expertise you wish to share, i would
be very inteested in hearing it.

randy

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 1 Jun 2001 19:35:43 +0100 (BST)

On Fri, 1 Jun 2001, Randy Bush wrote:

> message. 

Interesting, Randy.

Do you read internet-drafts and RFCs that have multiple authors, where
consensus between the authors is implicit in the author list? If
they'd thrown their comments and criticisms together in draft form,
would you have read it?

L.

oh, and Tammy? The 'individual from Alcatel' is just an individual.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Eric Gray <[email-masked]>
Date: Fri, 01 Jun 2001 15:23:35 -0400

Randy,

    Is this one of your usual insightful comments?  Let's see what our
studio audience has to say - Bzztzzt!  Apparently that was a wrong
answer.  :-)

    Repeatedly we ask for input from carriers.  We get some and we
hear that we're only interested in hearing from individuals?  As Lloyd
said, interesting...

--
Eric Gray

---

From: Randy Bush <[email-masked]>
Date: Fri, 01 Jun 2001 13:00:45 -0700

> Is this one of your usual insightful comments?

nope.  a statement of ietf culture and policy.

randy

---

From: Eric Gray <[email-masked]>
Date: Fri, 01 Jun 2001 16:18:57 -0400

Randy,

    Thanks.  As an individual, I am interested in hearing from other
individuals who can help me to understand what is useful work and
what is not.  I am so interested in hearing this, that I will go to some
lengths to discourage others from censuring them.  I believe it is even
possible that I am not alone among the many individuals participating in,
or listening to, this discussion in feeling this way.

    But I could be wrong, and you're certainly entitled to express your own
opinion.

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Mon, 04 Jun 2001 10:05:57 -0400

Anonymous,

    Look, I know that these IETF mailing lists are prone to flame wars
and that many people prefer to be silent 'lurkers' as a result.  But, unless
people are willing to come forward with their comments directly, it is not
very likely that they will be heard.  Also, in spite of Randy's comments,
people DO want to hear from members of companies.  It is easy to express
high sounding, but meaningless, opinions when posting as 'an individual' -
especially when posting from an anonymous free E-mail account (as so
many people do these days).

    Understand that - if you come forward with an opinion or idea that you
and your colleagues have come up with together - your opinion/idea will have
only the weight of an individual opinion.  In theory, your opinions and ideas
should be considered by IETF participants solely on their merit and not as a
result of who you work for (or what your position is in the IETF).  Also, in
theory, it is understood that your individual opinions and ideas do not reflect
the opinions and ideas of your employer.  And most of us (wink, wink) believe
this too.

    Personally, I think there is entirely too much censure (read 'flames') going

on.  If you and your colleagues each individually express the same opinion,
you will hear comments like 'well, one company heard from'.  On the other
hand, if one of you expresses a common opinion, he/she will be censured for
not expressing an individual opinion.  It may seem like you can't win, but you
have to try.   And - until some IETF 'king' decides to stoop to literal censure
- your opinions will be heard in spite of the flames... :-)

--
Eric Gray

'Anonymous' wrote:

> Eric,
>
> I agree with you whole heartedly.  We must have the inputs from the carriers
> and not from the vendors alone.  Some vendors are pushing MPLS, GMPLS now,
> like this are the best ideas since sliced bread.  But others (Global
> Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the
> problems with MPLS.
>
> Issues that we have found relate to -
>
> 1.  MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's
> book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To
> many people, QoS is the driving factor behind MPLS.  This is actually
> something of a misconception......QoS is not a very strong reason to deploy
> MPLS..."
>
> 2.  To do VPN with MPLS with extensions is a bad idea also since BGP is a
> routing protocol that changes state quite often and to use it for VPN with
> MPLS tags is not really a very smart solution as a recent comm related
> magazine article points out (I don't have it here but I can provide it if you
> are interested),
>
> 2.  If not for QoS, then is it for TE?  As others have said on this MPLS
> thread, you can easily do TE with a host of network management tools
> available out there - if not real-time, for sure, near-real-time.
>
> 3.  Other issues pertaining to MPLS are - scalability: explicit path, RSVP,
> CSFP, all found not scalable from the dawn of these technologies (see Nortel
> site slides on MPLS for one confirmation), and finally
>
> 4. No one addresses the fact that tagging and variable packet sizing enroute
> for a packet is extremely high memory and processing hog (hardly acceptable
> for the hundreds and thousands of older routers out there) not to mention the
> issues of label explosion, TTL, and risk of MTU violation and subsequent
> fragmentation and retagging of packets.
>
> My colleagues and I wonder why no one speaks up.
>
> (Please feel free to use these items in the thread if you don't use my name.
> Thanks.)
>
> (Anonymous)
>
> Eric Gray wrote:
>
> > Randy,
> >

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 04 Jun 2001 07:47:39 -0700

Anonymous,

> something of a misconception......QoS is not a very strong reason to deploy

The above seems like quoting out of context. To put it in the proper
context here is the full sentence:

   Compared to other factors, such as traffic engineering and Virtual
   Private Network support, QoS is not a very strong reason to deploy
   MPLS.

So, what you seem to be missing is that it is *relative* to other
applications, such as TE and VPN, that "QoS is not a very strong reason
to deploy MPLS".

And while on the subject of QoS and MPLS, further in the first section 
of Chapter 6 (page 148):

  ..there are some novel QoS capabilities that can be supported across
  a provider network using MPLS that, while not being truly end-to-end,
  nevertheless may prove very useful. One of these, guaranteed bandwidth
  LSPs, is discussed in Section 7.5.2.
  
> magazine article points out (I don't have it here but I can provide it if 
> you are interested),

At best whether "to do VPN with MPLS with extensions" is "a bad idea"
is a matter of opinion. However, since at the beginning of you message
you suggested to get inputs from the carriers, you may look at the
list of authors of draft-rosen-rfc2547bis-03.txt, as this list may
give you a hint of what carriers think about this technology.
 
> available out there - if not real-time, for sure, near-real-time.

First of all, there is a difference between "said" and "done". So,
while other "have said.. you can easily do TE with a host of network
management tools", one could ask whether they actually done this.
And if yes, then the next question would be to compare results with
TE based on MPLS Constraint-based routing.
 
> site slides on MPLS for one confirmation), and finally

Since you quoted from "MPLS: Technology and Application" before,
I'd like to suggest to look at Section 7.6.2 of this book for the
discussion of alledged scalability problem with RSVP, when used in
conjunction with MPLS Constraint-based routing. 

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 04 Jun 2001 08:13:31 -0700

[minor typo...]

> I'd like to suggest to look at Section 7.6.2 of this book for the
                                         ^^^^^
                                         7.2.6

Yakov.