The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Mar> msg00137



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

I-D ACTION:draft-ietf-mpls-soft-preemption-02.txt

  • From: "Matthew R. Meyer" <mmeyer@gblx.net>
  • Date: Wed, 31 Mar 2004 20:25:51 -0700
  • Cc: Matthew Meyer <mrm@gblx.net>, "'mpls@uu.net'" <mpls@UU.NET>
  • User-Agent: Mutt/1.4.2i


Adrian,

Comments inline

Thus spake Adrian Farrel (adrian@olddog.co.uk):

 |Thanks Matthew, good to have a clear statement.
 |

Yes that was a tad brief, :-) Here is a bit more information 
now that I have verified what can be repeated:

Current status:

o Juniper has delivered [ERO Style] soft preemption.
o Avici reports an [ERO Style] implementation in progress.
o Cisco, Juniper, Avici all report multiple customer requests for [ERO Style] SP.
o GX, UUNET/MCI and other service providers are interested (please pipe up)
o GX has done some basic lab testing, plans on more testing and
     eventual deployment.

So, one vendor is shipping, 2 additional (that I know of) have committed
to it and a number of service providers have been pushing asking for it.
Take those 3 vendors and you've got something approaching 100% of the 
core router market.

 |Is the continued purpose of the draft to achieve "soft pre-emption", to "allowing
 |gathering of information on pre-empted resources through the RRO", or both?
 |
 |Perhaps other members of the WG would care to comment on their preferences.
 |
 |Thanks,
 |Adrian

Yes, the plan is to continue to support the RRO method. As was
discussed by others on-list a year ago the path/resv error method
was discarded in favor of the RRO method.  The RRO method was
considered to have superior aspects that, if implemented smartly,
could substantially reduce the number of essentially redundant
messages transiting the network and arriving at the ingress &
(optionally) egress LSRs.

WRT supporting both Path Error and ERO style, I guess the topic
has not been breached yet.  It would seem a waste to do both
because one would probably have to run both at the same time
in a multi-vendor network.  I think I'll let my co-authors duke
that one out. I do wonder though, why GMPLS needs a solution for 
what seems to me an MPLS-only problem?  One isn't going to 
allow multiple identical lambdas/channel briefly 'oversubscribe'
a single wave/timeslot so I am probably missing something there.

Matthew