Subject: RE: GMPLS Last Calls

From: [email-masked]
Date: Fri, 1 Jun 2001 12:22:55 -0500

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

In the interest of saving bandwidth, individual expertise has been 
bundled/aggregated/grouped to have one email instead of several. can't 
help it if this doesn't appeal to you

---

From: [email-masked]
Date: Fri, 1 Jun 2001 12:53:34 -0500

Ananth and all,
I will be gone for all of next week in Turin, Italy.  I will try to 
read my mail but don't know how much luck I will have in getting 
access.  I am leaving tomorrow.

I am hoping that for these detailed messages that are GMPLS specific, 
you and Wesam can take the brunt of it.  I want to focus more on the 
functional level and management specific issues as much as possible and 
leave detailed GMPLS items to the two of you.

I see that this individual from Alcatel is pushing hard for GMPLS. I 
will let you all know what happens in Turin.  I think maybe just thank 
those that sent the e-mails and say you will look over what they sent 
if you don't have any further opion on what they sent.
Tammy

-----Original Message-----
From: Nagarajan, Ananth 
Sent: Friday, June 01, 2001 12:23
To: randy
Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir,
Lynn
Subject: RE: GMPLS Last Calls

---

From: [email-masked]
Date: Fri, 1 Jun 2001 15:30:34 -0500

Eric, Lloyd and other "individuals",
Thanks for being so understanding :-)  I am sorry this thread is going 
on in a direction it was not intended to.  I apologize for offending 
"IETF culture".  As a group of individuals interested in getting 
technical responses to our technical concerns, can we re-focus on the 
technical issues raised collectively by individuals that I work with (I 
hope this description is acceptable)?  Let us get a technical 
discussion going, please!

Ananth

-----Original Message-----
From: eric.gray [mailto:[email-masked]]
Sent: Friday, June 01, 2001 3:19 PM
To: randy
Cc: eric.gray; Nagarajan, Ananth; ccamp; mpls; Alanqar, Wesam; Ferris,
Tammy; Jones, Mark L.; Neir, Lynn
Subject: Re: GMPLS Last Calls

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

You wrote:

> > Is this one of your usual insightful comments?
>
> nope.  a statement of ietf culture and policy.
>
> randy

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 1 Jun 2001 17:25:32 -0400

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: [email-masked] 

> -----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: [email-masked]

---

From: Atsushi Iwata <[email-masked]>
Date: Sat, 02 Jun 2001 09:28:33 +0900

Ananth,

As Bala suggested, I wrote the following I-D proposing the crankback 
routing capability for CR-LDP and RSVP-TE signaling. 

http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-00.txt

Please look at it and if you find any missing pieces for GMPLS signaling, 
please let me know. I would appreciate any constructive comments.

Thank you.

>that you please consider writing some drafts if there is something
----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Assistant Manager
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     [email-masked]
NEC-internal E-mail: [email-masked]

*** Organization has been a bit changed since Apr.2001 ***

---

From: [email-masked]
Date: Mon, 4 Jun 2001 10:33:10 +0100

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

> From:	Bala Rajagopalan [SMTP:[email-masked]]
> Sent:	01 June 2001 22:26
> To:	[email-masked]'
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: Re: GMPLS Last Calls
> 
> Ananth:
>

---

From: [email-masked]
Date: Mon, 4 Jun 2001 09:45:11 -0500

This is to the same individual who sent me a private e-mail with 
similar content as was sent to Eric Gray:

Please don't misinterpret my GMPLS concerns as concerns about MPLS as a 
whole.  Please note that I am very supportive of MPLS, and in fact, I 
like the very aspects of MPLS that you point out as bad things (MPLS 
for TE, BGP-MPLS and Virtual Router-based VPNs etc.)  I also have no 
problem with GMPLS as the protocol of choice for the optical control 
plane (In fact i think it is a very logical idea).  My e-mail was to 
point out, what carriers may think as deficiencies with GMPLS for the 
optical control plane.  I welcome comments, like Bala's and others' 
clarifying the different features that address our concerns.  After 
all, voicing concerns and getting clarifications on a protocol is 
supposed to be an educational process as well.  (Doesn't mean that all 
the concerns that had been expressed in my e-mail have been resolved, 
but those will be addressed via a separate e-mail).

Cheers,
Ananth

-----Original Message-----
From: eric.gray [mailto:[email-masked]]
Sent: Monday, June 04, 2001 9:06 AM
To: mpls; ccamp
Subject: Re: GMPLS Last Calls

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,
> >
> >     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
> >
> > You wrote:
> >
> > > > These are the collective opinions of me and my colleagues
> > >

---

From: [email-masked]
Date: Mon, 4 Jun 2001 16:56:49 +0100

Yakov Rekhter wrote 04 June 2001 15:48
<snipped>
> > 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
> > something of a misconception......QoS is not a very strong 
> reason to deploy
> > MPLS..."
> 
> 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.

NH=> MPLS has the potential to become very important and have a key role on
QoS issues (and it should not be confused with GMPLS see 'note' at
end).....but to get there we need to recognise these points:
-	LDP is to me an IP routing adjunct.....its main role as I see it is
to provde address partitioning (or a 'hierachy of routing' as I think you
described it in your book Yakov....which, if anyone has not read it, I can
strongly recommend);
-	LDP induced LSPs do not really create a layer network.....since they
allow merging, and this in itself causes some hard QoS problems....like how
does one define availability in a mpt-pt tree?  [Its the old issue of 'no
free lunch'...if you push down a problem in 1 dimension (eg scalability), it
creates a problem somewhere else (eg measuing availability in VPNs say)];
-	Explicitly routed LSPs on the other hand do form true layer
networks....since they need to be signalled they exist as true trail objects
in their own right.
And it was these apsects that our OAM paper tried to address for
MPLS....that is, to attack the QoS problem (wrt operational processes and
measurements) one needs to first define the defects (and MPLS does have the
potential to introduce new ones) and the consequent actions...and from this
we can define availability of the LSPs which in turn is a pre-requisite to
measuring QoS (since QoS is only relevant to the up-state of the LSP).

However.....we have had a 'hard time' from a few on this (maybe there is a
silent majority that support this work?)....and this relates to Eric Gray's
prior mail on why people don't speak up.....besides the fear of ridicule or
abuse, one can only try so many tmes before giving up and going elsewhere.
So maybe there is a deep-seated culture problem that needs addressing?

Note - MPLS introduces a new user-plane technology....the shim header.  By
definition, and as noted above, operators need to manage this in an
OAM/performance sense.  MPLS has the ability to be extended to end
systems....I know this is not currently on the agenda of many, but it has
that *potential* (ie so that applications could choose a priori the transfer
mode, co or cnls).  The arguments for a single control-plane across MPLS and
IP (or to be more precise the 'addressing facet' of the control-plane) is
important if ever MPLS was extended to end systems.....this was the real
problem with ATM and IP unification, ie disjoint addressing.
GMPLS on the other hand does not introduce a new user-plane.  It is about
re-using control-plane facets for different layer networks.  In principle
this is a laudable aim, but its actual embodiment has many technical and
commercial implications that are too deep to go into here and we (ie I and
colleagues in BT) are addressing these elsewhere.
So all I wanted to say here is that one should not compare MPLS and GMPLS
like they are same thing.
<snipped to end>

---

From: [email-masked]
Date: Mon, 4 Jun 2001 09:11:05 -0700

Eric,

You are right on the nose..
these communications forums depend on interactive dialogue and freedom to
have and courage to express an opinion.

When people cloak their identity to avoid direct confrontation or worst yet
to falsly influence....well that is one of the downsides to freedom of
speach.

All with valid reaons need to speak up...the listener has to alboe to
filter the wheat from the chaff.

Pat

---

From: "David Allan" <[email-masked]>
Date: Thu, 7 Jun 2001 11:36:43 -0400

Neil, you wrote

I'm not sure the existence of merging or QoS is necessarily a criteria for
excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for
the purposes of MPLS a layer can exist independently of which subset of
topological constructs in the architecture toolkit it subscribes to. ER-LSPs
overlaid on an LDP infrastructre using integrated routing to me would
constitute a useful definition of a "layer". It is only when I ruthlessly
exclude absolutely everything but the elemental  p2p undirectional trail
from the discussion that such a hard definition applies, unfortunatley much
of the value statements around MPLS disappear at roughly the same time.

cheers
Dave

---

From: [email-masked]
Date: Thu, 7 Jun 2001 17:34:44 +0100

Hi Dave.....I know exactly what you are saying and its something Andy Reid
and I have chewed over once or twice when considering a functional
architecture description of MPLS.

I was certainly not exhaustive nor precise in my description and
definitions....I was more interested in trying to emphasise the 'no free
lunch' point that making one aspect simpler usually makes some aspect more
complex (normal engineering trade-off).

I see 2 basic forms of MPLS LSPs:

1	One that is a close adjunct function of the IGP.....this is LDP
LSPs, and LDP is required since one cannot easily distribute labels
piggy-backed on a link-state routing protocol like OSPF (though you can with
BGP).

2	One that is not a close adjunct function of the IGP, and requires to
be signalled....this is RSVP-TE and CR-LDP LSPs.

The 'no free lunch' bit here means the former gives an operator more
headaches when considering fault-management and the definition of SLAs for
VPN services for example, whilst potentially getting some gains in
scalability......so that's the trade off I was inferring.

Its a bit like the polarised CO vs CNLS transfer mode view of the
world.....in reality technologies fall some-way between the 2 pure extremes,
and its knowing where the compromises should occur for a given (service)
case.....since neither alone can yield an optimum solution for all cases.
Indeed, one could say this is exactly why we have/need MPLS to augment IP.

Neil
-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: 07 June 2001 16:37
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: GMPLS Last Calls

Neil, you wrote 

in their own right.