Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: [email-masked]
Date: Sat, 1 Mar 2003 13:16:41 -0000

Although the BT view is to ignore this stuff I feel some operator
observations are in order at this point.  So please see below.  regards,
Neil

Eric Rosen wrote 28 February 2003 20:54
> 
> Eve> For individual contributor drafts  coming in, it's quite 
> appropriate to
> Eve> evaluate  requirements and determine  if they  are 
> legitimate.   It's a
> Eve> different case when another  SDO, responsible for a 
> non-IP applications
> Eve> domain, has established a set of requirements related to 
> that domain.
> 
> I'd certainly  disagree with  that.  Many of  the 
> "requirements" I  see from
> other  organizations  are  not   requirements  at  all,  but  
> just  dogmatic
> statements  of connection-oriented  religion.  If  the IETF  
> were  to accept
> requirements from  other organizations, it  would quickly be  
> inundated with
> "requirements"  to make IP  behave exactly  like ATM.   In 
> fact,  anyone who
> works in the PWE3 group can testify that such "requirements" 
> come in all the
> time. 

'Connection-oriented religion'?  I fail to understand how anyone could make
such a remark when IETF are working on SDH and OTNs....which are about as
connection-oriented as you can get!  MPLS also uses connection-oriented
*fowarding mode*.....this is obvious from using link-connection identifiers
which are only link-unique.  I know many pretend its not like this.....but
really, do you think we operators are all so very stupid?

Here are a few of our requirements for networks....you can take take them or
leave them:

1	Operators need all 3 networks modes, viz:  cnls, co pkt-sw and co
cct-sw.  If anyone honestly thinks we can provide all the services we need,
and run our networks efficiently, without all these modes then they do not
understand the operator business at all.  

2	The technical and commercial drivers/constraints for each of these
modes means that you cannot functionally converge them.......as was the
original intent of the so-called GMPLS 'peer-model'.  This has been our
consistent position from day-1, and it seems this is slowly being understood
by the wider community.  However, whilst I clearly cannot speak for other
operators I can tell you that we have analysed this one to death, and we are
very sure of our requirements here.

3	The principle functions that networks must have to work/scale are:
addressing, routing (however executed), signalling (if co mode), OAM,
performance metrics/objectives, traffic descriptors.  As noted above, there
are compelling (to us at least) technical and commercial reason why
crunching all these functions across all the network modes, and maybe into
some 'god-box' say, is a non-starter.  What we do want however, is
functional convergence of all the technologies *within* each networking
mode.  The reason for this is to avoid stovepipes (ie 'technology=>service')
and/or complex/costly functional gateways, eg to interwork different
signalling types.  And as noted above, we also want a properly specified
common core co pkt-sw mode.  

4	We also want the ability to *choose* best-of-breed functional
components for each networking mode.  This is largely not allowed in G/MPLS
(ie all functions come as a job-lot), and this is not acceptable to us
either.

But all of the above are not a problem providing we have the choice to go
elsewhere for our stds when the solutions provided by IETF don't (or can't,
for whatever reason) match these.

regards, Neil

---

From: Loa Andersson <[email-masked]>
Date: Sat, 01 Mar 2003 21:49:52 +0100

All,

this begs a couple of interersting questions - like if pwe3 are make
IP behaving like ATM - but this is not what we are discussing here, if
you need to "preach" please do so under a separate subject line

/Loa