The MPLS WG Archive

["Matthew R. Meyer" <mmeyer@gblx.net>]

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

Thanks Adrien,

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

True, customers are typically less concerned with mechanisms. You 
will have to admit though that NSP/Carrier customers are a tad more
fingers-in-the-pie about things.  When we get to a carrier sized 
network, the feature/benefit is, to a large degree, how the protocol
scales.

 |If the ERO style soft pre-emption is presented as the only option for soft pre-emption,
 |what else will be requested?

Perhaps the vendors would be in a better position to convey
what the customers were asking for, whether vague or specific, 
that comment was obviously assimilation of second-hand information.
As much as I would have liked to be there I wasn't :).

There was some on-list discussion about the two approaches a while 
back I thought so it is not impossible there were informed requests.

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

Well I think I understand GX's interest and Amir from MCI is 
on board as well.

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

As far as I know everyone on the draft is in some phase of 
work regarding ERO style SP.  I don't suppose a vote for
one necessarily means a vote against the other, but remember 
my note was in response to the implication that this draft 
was somehow destined for experimental and that nobody was
doing anything with it. An update was clearly overdue, and
for that I apologize.

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

This seems logical to me.

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

I would hope more than one vendor would look for efficiencies 
that could be gained from a design.  I am just saying there are 
some natural opportunities that lend themselves to the ERO model 
BECAUSE an ERO is being used.  How that is actually achieved is 
up to the vendor (I almost sound like you there :-P).

 |> because one would probably have to run both at the same time
 |> has not been breached yet.  It would seem a waste to do both
 |> in a multi-vendor network.  I think I'll let my co-authors duke
 |> that one out.
 |
 |This is my question, too.

Hmm, we'll see what they say on the subject.

 |> 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 :-)

Well, more specifically we are interested in something just short of 
preemption :-). MPLS Preemption as it currently stands causes unneeded
lost packets.

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

Indeed but there is little else that can be done for the desired 
outcome.  Someone will always oversimplify things and say "well 
its a capacity issue".  Well I really wish it was because it would
be easier to solve.  Unfortunately it is not: it is the fact that 
in the live network, failure elements with shared risk don't always
fail and recover in serial, they overlap and compound with similar
outages or maintenance work from time to time.  However rare this 
is, it is not something that can be 100% planned for capacity-wise,
Even with simulation a line must be drawn at how many orders of 
failure are reasonable.

This drives some to build the network to dynamically and accurately 
self heal (even in the worst conditions). Using MPLS-TE and preemption
is one approach.  Is this a 99% effort to fix the last 1% of the 
problem?  Sure, but it is that last 1% when the customer would 
have actually noticed the failure and the the SLA violation or 
Carrier grade VOIP transit would have been impacted. A testament 
to Neil's observed complexity explosion in the network is the 
universal support for some form of MPLS soft preemption in an 
attempt to cheat network size and scale issues.
 
 |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

Thanks for your comments, I'll get back to you. I would like to talk with
the other draft members.

Matthew