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

From: John Drake <[email-masked]>
Date: Mon, 3 Mar 2003 15:50:44 -0800

Zhi,
 
Just to be clear, I consider call/connection separation to be a solution,
not a requirement.  The requirements that I've heard that call/connection
separation is claimed to address are the following:
 
Keeping a connection alive while attempting to reroute it after outage.
(This is basic RSVP and  MBB allows you to reuse links on the failed path.) 
 
Establishing a new path for an existing connection so that links along its
current path may be taken out of service for maintenance.  (This sounds like
a definition of MBB.)
 
Keeping track of the circuits in a virtual concatenation group.  (I think
this is covered with the SDH/SONET signalling draft.)
 
The other requirement I've heard is a need to have the ingress and egress
nodes perform a capabilities exchange prior to establishing a connection,
and that sounds like something Notify should be used for.
 
Thanks,
 
John
 
-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Sunday, March 02, 2003 11:21 AM
To: [email-masked]
Cc: John Drake
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

Hi John, 

I was wondering about the statements you've made below, especially the one
about "all of them can be handled with the existing Make Before Break
component of RSVP-TE". I'm a little slow, so could you elaborate a little
more as to how this is related to the call/connection concept, and how the
make-before-break actually handles the call service concept? 

Thanks
Zhi 

 From: John Drake [mailto:[email-masked]]
Sent: Friday, February 28, 2003 4:15 PM
To: [email-masked]'; Varma, Eve L (Eve)
Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
Andersson; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

I agree with Eric.

As an example, we have call/connection separation, which has been kicking
around since the early days of ISDN. In discussions as to why it is needed,
the first reason is always "because". Once past that, I have consistently
heard four or five examples cited. What is interesting is that all of them
can be handled with the existing Make Before Break component of RSVP-TE. 

Thanks,

John

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
> Andersson; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> 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. 
> 
> 
> 

  _____  

Do you Yahoo!?
Yahoo!  <http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/>
Tax Center - forms, calculators, tips, and more

---

From: Zhi-Wei Lin <[email-masked]>
Date: Mon, 03 Mar 2003 19:27:48 -0500

Hi John,

Thanks for the clarification. Some more comments below...

Keeping a connection alive while attempting to reroute it after outage.
(This is basic RSVP and  MBB allows you to reuse links on the failed path.)
[Zhi-Wei Lin]  I don't think the intent of the call is simply to allow to
keep connections alive. A call is much more related to the concept of
providing service to the end-user. One of the services is the ability to
keep a connection alive for, e.g., billing purposes, and having a single
call ID for a call makes tracking of the service much easier as well.

  Establishing a new path for an existing connection so that links along its
current path may be taken out of service for maintenance.  (This sounds like
a definition of MBB.)
  [Zhi-Wei Lin]  Same comment as above.

  Keeping track of the circuits in a virtual concatenation group.  (I think
this is covered with the SDH/SONET signalling draft.)
  [Zhi-Wei Lin] This is really not covered in full in the SONET/SDH
signaling draft. The current signaling draft puts a limitation on the
virtual concatenation by requiring that all component members of the virtual
concatenated signal travel along the same path. The general virtual
concatenation mechanism allows for each component of the virtual
concatenation group to travel along different paths. This is really where
the call concept comes in handy. Again note that call is not designed
specifially for the virtual concatenation, but it provides a nice way of
supporting the multiple routings for each component virtual concatenated
signal.

  The other requirement I've heard is a need to have the ingress and egress
nodes perform a capabilities exchange prior to establishing a connection,
and that sounds like something Notify should be used for.
  [Zhi-Wei Lin] Right, but this also means extending the Notify message. So
it's a matter of choosing one method for support versus another. Also using
the Notify to support this is just solving one part of the puzzle. It could
be done, but the call mechanism gives you all the above, plus the "service"
concept (whatever that is... ;-) For folks who wants to understand call, you
can read G.8080 (that ITU-T G. stuff again! ) or (*gasp!*) some of the ATM
documents on call (Q.2981 I think). Of course those of you who still uses
your telephone or even your cellphone are everyday making a "call" (but only
always one connection within the call -- very limited, huh??)

  Thanks,

  John

  -----Original Message-----
  From: Zhi-Wei Lin [mailto:[email-masked]]
  Sent: Sunday, March 02, 2003 11:21 AM
  To: [email-masked]
  Cc: John Drake
  Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

    Hi John,

    I was wondering about the statements you've made below, especially the
one about "all of them can be handled with the existing Make Before Break
component of RSVP-TE". I'm a little slow, so could you elaborate a little
more as to how this is related to the call/connection concept, and how the
make-before-break actually handles the call service concept?

    Thanks
    Zhi

    I agree with Eric.

    As an example, we have call/connection separation, which has been
kicking
    around since the early days of ISDN. In discussions as to why it is
needed,
    the first reason is always "because". Once past that, I have
consistently
    heard four or five examples cited. What is interesting is that all of
them
    can be handled with the existing Make Before Break component of RSVP-TE.

    Thanks,

    John

    > works in the PWE3 group can testify that such "requirements"

----------------------------------------------------------------------------
    Do you Yahoo!?
    Yahoo! Tax Center - forms, calculators, tips, and more

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 03 Mar 2003 21:13:43 -0500

In message <[email-masked]>, Zhi-Wei Lin writes

Zhi,

MPLS is used for traffic engineering and is applied mostly to OC48c
and OC192c cores, though maybe extending out to OC12c and OC3c fringes
of a provider's network.  These MPLS LSP are not "calls".  They are
not customer "connections" of any kind.  GMPLS applies to even larger
aggregations of bandwidth when applied to optical (its orgiginal
purpose).

> keep a connection alive for, e.g., billing purposes, and having a single

This is the heart of the call/connection argument.  It didn't fly in
the early 1990s.  The Internet didn't implode because there was no way
to do per connection billing.  In fact it is the call/connection
telcos that are having the severe financial woes.  Those that own IP
operations (and virtually all do) generally have profitable IP
divisions.  Leased and switched services are declining while end
system encrypted VPN and provider VPN are growing.  Voice is becoming
flat rate.  Email and IM are clearly not call/connection oriented
unless you consider TCP to be call/connection.  Add voice to IM and
break through the last mile bandwidth monopoly and we wouldn't even
need the PSTN and its call/connection model, the last remnants of a
legacy technology whose demise began in 1984.

FR, SMDS, and ATM provided customer connections.  FR is still used for
low speed customer circuits, VPNs, etc.  SMDS is dead.  ATM SVC
services had virtually ZERO penetration at its peak and what little it
had was at low bandwidths.

ATM had some brief success as a core technology but 100% of that was
PVC or SPVC.  The reason we have MPLS is there were some things about
ATM that the IETF regarded as very broken.  The people that regarded
it as very broken were the very poeple running among the highest
capacity ATM deploymennts in the world, all running IP over ATM SPVCs.

What you are trying to do is bring some of the call/connection
brokenness that was rejected in the mid to late 1990s back into MPLS
after ATM failed in the market.

If you want to reminisce about the Q.2931 connection model go to the
ATM Forum and reminisce.  The Q.2931 model is dead in the IETF, always
has been, always will be.  The ATM Forum loves Q.2931 and they'd love
G.8080 since it is of the same mindset.  Please go away and use PNNI.

Curtis

---

From: Zhi-Wei Lin <[email-masked]>
Date: Mon, 03 Mar 2003 21:57:25 -0500

Hi Curtis,

Wow! What a position. Anyway, getting to some of your technical comments,
the ASON and just like the GMPLS is probably most useful at lower granular
signals where there are more churn and requests and therefore an automated
systems more useful. The original intent may be for optical OC-48 and above,
but (G)MPLS is supposed to be applied to everything under the sun, including
VT1.5/VC-11 signals.

Now getting to your other comments that would incite a lot of religious
discussions (and polarize folks)...your statement "In fact it is the
call/connection telcos that are having the severe financial woes" I thought
was interesting. Talking to some folks who works in the operating companies
lead me to believe that the root of the current crisis in the telecom
industry is that the operators have no way to build a profitable business
model. This is because they cannot charge for IP "services", but can only
bill on a flat rate for IP. And it's because of the broken IP business model
that they are in financial meltdown mode. Yes, the antiquated PSTN service
is suffering because of this, and people can say this is because the PSTN
business model is broken, but I prefer to think that the PSTN is a colateral
damage to the broken IP business model...

Of course the other heart of the current problem is the sudden dramatic
expansion of the capacity and services from many many many CLECs that
saturated the market with the same type of service offerings causing this
current meltdown in price and thus profitable revenue. None of this has to
do with a broken call/connection model. In fact my believe is that once a
service model is instituted on the IP world, operators will start to gain
traction in the business model front as well...of course we would never
stand for such draconian measure (after all, why should the RBOCs and PTTs
make any money?? they're dinosaurs who deserve to go extinct!! ;-)

As always, flames are very unwelcome, but I'm sure I'll get some with what I
said above... :-(

Looking forward to your reply!
Zhi

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 9:14 PM
> To: Zhi-Wei Lin
> Cc: 'John Drake'; 'Zhi-Wei Lin'; [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 03 Mar 2003 22:55:16 -0500

In message <[email-masked]>, Zhi-Wei Lin writes
> but (G)MPLS is supposed to be applied to everything under the sun, including

MPLS so far has been applied to TE at mostly OC48c and OC192c.  I'm
sure there is an interney-draft somewhere to apply MPLS to the
microprocessor in my coffee maker but I don't see it happenning.

> damage to the broken IP business model...

The IP business is profitable for many.  The PSTN is suffering because
of the competition from IP and competition from elsewhere.

Back in the mid to late 1990s the largest and most profitable IP
providers were bought by carrier that were loaded with cash from their
near-monopoly business.  They couldn't trash the IP businesses they
bought because others remained to compete against them so they ended
up undercutting themselves.  They still had the eroding voice business
to weight them down.

There is nothing wrong with voice as a service.  It is just that if
there is a competative market, you can only milk a tenth of the profit
out of the voice business that the big telcos made in the late 80s and
early 90s and remain competative.  For example, the new Worldcom will
very likely emerge smaller and it looks like with a flat rate voice
model.  Not much seems to be changing in the IP side of the house
which was still healthy and growing at an impressive rate until the
rest of the company dragged it along into the bankrupcy court.

> make any money?? they're dinosaurs who deserve to go extinct!! ;-)

The saturation that you are speaking of was at the transport level.
Many IP providers have been unable to make capital expenditures due to
the parent company problems and have capacity concerns either eminent
of on the near term horizon.

The fast provisioning promise of optical switching produced near
nothing over plain ol' WDM in terms of revenue or operational savings.
Switched services is declining and growth of leased line is slow and
may be driven largely by IP tail circuits.

According to some people the logical next step to rebuild the
transport business based on a model that just failed.  :-)
IP is still making money and the business is growning.

btw- If we didn't have a monopoly bottleneck at the last mile in the
US more of that overbuilt transport would be in use but that is a
political issue that is out of scope for IETF or SDOs in general.

> Looking forward to your reply!

Why.  Do you think you have some sort of compelling argument?

Quite frankly at this point I think we are wasting everyones time
including our own so lets just agree to disagree and follow Scott
Bradner's lead and leave liason completely out of Loa's draft and
address it separately, elsewhere.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 3 Mar 2003 22:01:46 -0800 (PST)

Hi Zhi,

On Mon, 3 Mar 2003, Zhi-Wei Lin wrote:

> bill on a flat rate for IP.

I agree with you that this is interesting -- even if completely unrelated
to CCAMP.

I pay flat rate for my local service.  I see a tentative move towards
flat rate for long distance; my cell phone bill is essentially flat
rate (I pay for more minutes than I would ever use per month.)  Of
course, I pay flat rate for my DSL (thanks to which you get this
message :-))

1) Assume the world is moving towards flat rate billing (big IF), would
   call and connection separation still be a requirement?

2) While GMPLS could be used down to the T1 and DS0 level, suppose
   for a minute that its use was restricted to OC12 and above.
   Would call and connection separation still be a requirement?

Thanks for your insights,
Kireeti.

---

From: [email-masked]
Date: Tue, 04 Mar 2003 11:59:19 +0100

zhi,

see comments in-line [DP]

---

Hi John,

Keeping a connection alive while attempting to reroute it after outage. 
(This is basic RSVP and  MBB allows you to reuse links on the failed
path.) 
[Zhi-Wei Lin]  I don't think the intent of the call is simply to allow
to keep connections alive. A call is much more related to the concept of
providing
service to the end-user. One of the services is the ability to keep a
connection alive for, e.g., billing purposes, and having a single call
ID for a call
makes tracking of the service much easier as well. 

[DP] if it was to name sessions why not simply use the session
name of the session attribute object ?

Establishing a new path for an existing connection so that links along
its current path may be taken out of service for maintenance.  (This
sounds like a definition of MBB.)
[Zhi-Wei Lin]  Same comment as above.
        
[DP] let's be a bit more inventive here, admin status object
with its flags has been defined for that purpose was it really
impossible to use it here ?

Keeping track of the circuits in a virtual concatenation group.  (I
think this is covered with the SDH/SONET signalling draft.)
[Zhi-Wei Lin] This is really not covered in full in the SONET/SDH
signaling draft. The current signaling draft puts a limitation on the
virtual concatenation by requiring that all component members of the
virtual concatenated signal travel along the same path. The general
virtual concatenation mechanism allows for each component of the virtual
concatenation group to travel along different paths. This is really
where the call concept comes in handy. Again note that call is not
designed specifially for the virtual concatenation, but it provides a
nice way of supporting the multiple routings for each component virtual
concatenated signal.
       
[DP] this problem was known w/i the ccamp community since begin'01
this is also the reason why "lbm stuff" has been proposed to fully
cover virtual concatenation
 
The other requirement I've heard is a need to have the ingress and
egress nodes perform a capabilities exchange prior to establishing a
connection, and that sounds like something Notify should be used for.
[Zhi-Wei Lin] Right, but this also means extending the Notify message.
So it's a matter of choosing one method for support versus another. Also
using the Notify to support this is just solving one part of the puzzle.
It could be done, but the call mechanism gives you all the above, plus
the "service" concept (whatever that is... ;-) 

[DP] i have a problem here, it seems that proposed extensions 
have been proposed to cover a concept rather than really 
translating an implementation need, would be more than useful
for the ccamp community that you clearly mean by service here

For folks who wants to understand call, you can read G.8080 (that ITU-T
G. stuff again! ) or (*gasp!*) some of the ATM documents on call (Q.2981
I think). Of course those of you who still uses your telephone or even
your cellphone are everyday making a "call" (but only always one
connection within the call -- very limited,
 huh??)

[DP] Q.2982, but it is clear that the higher the granularity
less this call concept will be interesting, and the smaller
the network less this concept will be interesting in addition 
for atm networks this concept hasn't been widely used, the 
question is that there are no clear evidence that it won't
be the case with sdh networks as well ... dimitri.
        
       Thanks,
        
       John
      
-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 04 Mar 2003 08:13:52 -0500

Kireeti,

Yea, you are right. You pay flat rate for a DSL. I guess you have to double your
pay if you get TWO DSLs. :-) More important, you are talking about "consumer"
service, where flat rate may be popular for the time being. Carrier chooses flat
rate for many business reasons, e.g. ... (totally out of CCAMP scope, so skip).
Yet, it may be a different picture in the business customer service area.

Furthermore, you are talking about billing. Indeed, one of the reasons opertors
choose flat rate is to simplify billing because the control/management plane
can't generate accurate information. 

The bottom line is that as the building block of the overall management
functions, control plane should provide adequate function to support high level
services. Otherwise, everything becomes commodity.

Regards,

Yangguang

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 04 Mar 2003 11:10:06 -0500

In message <[email-masked]>, Yangguang Xu writes:
> 
> 
> Kireeti,
> 
> Yea, you are right. You pay flat rate for a DSL.  [...]

Lets look up and down the food chain.  

  At consumer level, service is tiered flat rate.  DSL, cable IP, cell
  phone, now POTS.

  IP service at T1 or higher has always been flat rate or burstable
  tiered flat rate.

  Switched services such as FR and ATM have been flat rate PVC or
  SPVC.  SVC service is generally not available and where it is has
  almost negligible penetration.

  At the high end, leased lines, leased lambdas, and leased dark fiber
  is definitely not signaled dynamicly by the customer so there is not
  "call" or customer connection.

What has had a call model:

  X.25

  ISDN

Even ISDN, where it has been at all successful, is flat rate.  Where
it is metered, market penetration is zip.  (btw - Its still metered
where I live afaik and might as well not be offered).

> services. Otherwise, everything becomes commodity.

So what does this billing and control/management plane nonsense mean
in a world with flat rate or tiered service with no customer initiated
connections to bill for?  It has absolutely no purpose except to try
to perpetuate a mindset and perpetuate a hope that services with the
X.25 and ISDN metered billing model will somehow gain penetration and
the SP will be able to milk huge profits from it.  Unfortunately the
customer isn't stupid enough, so short of a return to monopoly rule or
other exclusion of competition, it won't happen.

Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 04 Mar 2003 12:12:51 -0500

>can't generate accurate information.

         That it not entirely true. I know some providers that
due bill based on usage, and also verify based on these
same SLAs.

>services. Otherwise, everything becomes commodity.

         I wonder how you have arrived at your bottom line.
I personally think that the current offering of management is
largely sufficient to satisfy the requirements for monitoring
SLAs in many different levels of granularity. New drafts are
appearing all the time to fill in the holes.  There are other things
being working on in other  WGs such as IPFIX to standardize
additional accounting.  If you can identify specific deficiencies,
please let us all know.

         --Tom

---

From: Stephen Trowbridge <[email-masked]>
Date: Tue, 04 Mar 2003 11:04:18 -0700

Curtis,
Working for an equipment manufacturer, I have never felt that it was
my place to tell a SP how they should bill for their services. I don't
think we should preclude any particular billing model by our architecture.
It is the market that should decide what gets offered at a flat rate:
not the equipment, and certainly not the standards.
Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 04 Mar 2003 13:36:16 -0500

> not the equipment, and certainly not the standards.

Steve,

This is no different from the 1995 argument that IP should go away
becasue there is no good way to bill on a per connection basis.

What you are asking for is customer initiated connections which can be
metered for billing purposes.

I used to work at two major ISPs in the architecture group.  There was
no such requirement.  Since leaving and being on the vendor side I
have not heard any such requirement from customers.

Well actually if you count Enron as a customer, Enron's bandwidth
brokering required customer initiated connections with AAA and
possibly metering.  They hadn't decided on the latter before they gave
up and switched their business plan to a QoS enabled backbone for VOD
(remember the Enron/Blockbuster announcement).  We all know how far
both of those ideas went.

It appears that you are not arguing that any SP wishes to repeat
Enron's folly (the first of the two), just that we should extend the
protocols to accommodate it just in case.  That doesn't sound like a
strong case for a set of requirements.

Curtis

> > > Furthermore, you are talking about billing. Indeed, one of the reasons op
> erto
> > > rs
> > > functions, control plane should provide adequate function to support high
>  lev
> > > el

---

From: Stephen Trowbridge <[email-masked]>
Date: Tue, 04 Mar 2003 12:13:42 -0700

Curtis,
OK, so it is your place to tell SPs how to bill for their services rather
than mine.

No doubt that there are certain services at certain usage levels where it
is better for the SP and for the customer to bill at a flat rate. All I am
saying is that this is not necessarily the correct model in all cases.
Sure, I can pay a flat rate for ulimited long distance calling if I choose
to, but this flat rate is about 10x my normal long distance bill - so I
choose to pay per call instead. But if I follow your model, I can expect
what I pay for very few long distance calls to increase dramatically in
the near future, since nobody will be able to measure my usage for VoIP
and their only choice will be to charge me the amount that covers average
usage.

I pay a flat rate (~$45/mo with taxes) for my cable modem service. This is
a bargain since we have 4 computers (2 tech. industry professionals, 1 CS
major college student, one high school student) behind my router and we
make pretty heavy use of it. But would you blame a SP for wanting to provide a
metered service also to try to get more cable modem penetration among light
users?

Again, these are market related decisions to be made by the SPs. Not
technology related decisions to be made by the equipment designers.
Regards,
Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 04 Mar 2003 14:44:52 -0500

> OK, so it is your place to tell SPs how to bill for their services rather

No.  It is the SPs business to tell us.  

> and their only choice will be to charge me the amount that covers average

No SPs seem to be making credible requests for customer initiated MPLS
connections which are per bandwidth billable.

> metered service also to try to get more cable modem penetration among light

But they don't and they don't intend to.  AOL could also go back to
metered billing.  So could the cell phone providers.  Customers
disappear, so they don't meter.

> technology related decisions to be made by the equipment designers.

The discussion was about requirements and I am speaking on the basis
of my experience on the SP side and what requirements I have heard on
the vendor side and observations about very clear industry trends
(toward not away from flat rate billing).

Nice tactic though.  After you lose the argument, declare the argument
out of scope.  :-)

Curtis

> > > > > choose flat rate is to simplify billing because the control/managemen
> t pl
> > > ane