The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Thanks Matthew,

Useful information.
Replies in line with implicit incorporation of responses to some of Neil's points.

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

So, be very careful. In my experience, customers are less concerned about protocol
mechanisms and more about function and features.
If the ERO style soft pre-emption is presented as the only option for soft pre-emption,
what else will be requested?

> o GX, UUNET/MCI and other service providers are interested (please pipe up)

Again, what is the interest? Is it in protocol mechanisms or function and features?

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

In Seoul, I pushed for support of the (my :-) draft as a condition for continuing to work
on it.
In the very limited time that was available there were positive responses from people
working for several vendors (with some overlap with your list above).

So this isn't as clear cut as it seems.

But, if the WG is happy with the existing situation and drafts that is fine (although
someone should write a BCP to ease the interpretation of RFC3209).

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

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

I would say that a draft that "if implemented smartly" can benefit the network is not of
substantial use to the community since there is a distinction between an advantage to a
single node (smart implementation) and advantage to the network (good standardisation).

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

This is my question, too.

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

1. GMPLS supports packet switching so all MPLS requirements
    apply.
2. In a TDM, LCS or FCS network, soft pre-emption obviously
    cannot do oversubscription. However, the pre-emption of a
    resource on one span (and the subsequent break in service)
    does not require the teardown of the entire LSP allowing
    more speedy repair. This is the benefit of soft pre-emption in
    such a network.

Whether anyone want pre-emption in any type of network is clearly up for debate. it would
appear that GX is interested :-)
I think that of Neil's two categories of uses for pre-emption, most people are talking
about fairly selective use such as the "emergency" placement of a recovery path for a high
priority service, or the bumping of "extra traffic" from a 1:n protection path. As Neil
says, while the use of pre-emption to manage fine granularity disparate services is a
technical possibility, it grows dramatically in complexity with the size and scope of the
network.

Whether any form of pre-emption is desired in an optical/TDM network is also for debate
amongst another (different) set of SPs. Neil's points are well made and it may be that
some/many/all nodes within a specific network are not pre-emption-capable (by design or
desire). The protocols must, however, support (but not demand) this function where there
are networks that wish to make use of this function.

At the same time, Neil's point about holding times is important. Pre-emption is a risky
business in a flapping network since it may cause (far) more damage than the problem it is
trying to solve. Safeguards must be built into the protocols, the operational switches
*and* the error detection/reporting/correlation mechanisms.

With regard to the differences between MPLS and GMPLS...
The aim is to have similar or identical protocol objects to achieve similar conceptual
functions. The specific procedures may differ depending on the type of network and the
other facilities of the protocol (for example, the danger of misconnection is significant
in a network where a resource is equivalent to a label).

Cheers,
Adrian