Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels

From: "Dave Danenberg" <[email-masked]>
Date: Mon, 2 Apr 2001 09:27:49 -0400

Neil/Giles,

I've been watching your exchange with interest. Especially when
discussing
whether MPLS signaling can be used reliably for data-plane failure
detection.
So let me just throw this into the discussion... Won't most MPLS
deployments
support statically configured MPLS connections? If so, then signaling
would
not be there - even if it could reliably detect data-plane failures.
Seems
like a good argument for MPLS OAM. Also, (being in the chips and systems
business) I agree with Neil and Shahram that MPLS OAM implementation is
not
complex.

--Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, April 02, 2001 5:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels

Giles Heron [mailto:[email-masked]] wrote 02 April 2001 06:15
> Can you please give us some examples of situations where the control
> plane will not detect the user plane defect? (other than the buggy
> software case below of course.)
NH=> Any situation where the user and control-plane do not go through
*exactly* the same routing/processing.  In GMPLS-type situation this is
a
given, in MPLS this is less obvious I agree (except for those hopefully
rare
SW/HW failures modes).....especially for base LDP.  However, as a
general
principle one should aim to make user and control-plane defect handing
independent so as to allow flexibility of user and control-plane network
topology design (they are quite distinct in principle, and the
control-plane
topology has to takes its design cues from the duct for rigorous
resilience
design).
> 
> 
> And yes, of course I have a requirement to offer SLAs to customers. 
> Originally I had thought that some sort of MPLS OAM might be 
> useful for
> this.  Having read your draft, having seen the complexity involved,
> having figured out that all it seems to detect that cannot be detected
> by other means is mismerged/swapped LSPs, and having 
> discovered that it
> doesn't support merging LSPs
NH=> Lots of things don't support merging....nor is merging always such
a
wonderful thing.
, I have come to the conclusion 
> (rightly or
> wrongly) that I'm better off without.
NH=> I can understand your view .....especially if all you ever want to
use
MPLS for is in a LDP-type of deployment.  But I am still left with these
unanswered questions for a path-oriented view/use of LSPs:
-	where are the definitions of defects specified?
Note - I know some defects should be rare.......but we should aim to be
rigorous in specification at the outset and we need to weight the 'prob
of
event' by its 'potential impact' to properly assess the real risk....it
is
not sufficinet to appeal to the rare prob alone (cf the aircraft or
nuclear-power industries....OK networks don't kill people (usually at
least!), but I hope you get my point).  I am sure the vendors must have
some
specification, albeit currently proprietary....but these need
standardising.
-	where are the 'consequent actions' on failure specified?
-	where is the definition of availability specified?
-	and how can we move on to define QoS metrics/objectives if we
can't
define availablity? 
As an operator we are coming under increasing pressure to be able to
define
these (esp for VPN customers), and in any case these are issues that
should
be thought about up-front and not later (when it might be too difficult
to
make changes).  It seems clear that you don't have any answers to these
questions, but you also don't have any alternative proposals either.
BTW - I am surprised you thought the proposals complex.  This is about
as
simple as we could make them, and Shahram (who works for a chip
supplier)
did not think these complex.

regards, neil

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Apr 2001 16:58:14 -0400

In message <[email-masked]
>, "Dave Danenberg" writes:
> Neil/Giles,
> 
> support statically configured MPLS connections?

No.  In fact, none so far AFAIK.

Curtis

---

From: "Dave Cooper" <[email-masked]>
Date: Tue, 3 Apr 2001 15:19:10 -0700

> not be there - even if it could reliably detect data-plane failures.

Nope.  In fact, the wide scale use of statically defined MPLS connections
sends shivers down my spine.   But on the topic of MPLS OAM, it has its
merits -- especially when software failures (whereby the control plane
does not detect failures in the data plane) seem to continue to be the 
bane of most MPLS implementations.  I've been preaching this directly
to vendors for quite some time and despite what tweaks we put into the
control plane for dealing with failure (whether its fast reroute, normal
reroute, whatever), its still doesnt fix this constant problem.  Customers
are tired of hearing the vendor bug excuse.

dave

---

From: Ping Pan <[email-masked]>
Date: Tue, 03 Apr 2001 18:33:11 -0700

Dave Cooper wrote:
> 
> But on the topic of MPLS OAM, it has its

Dave,

Agree! Also it's hard to find much overlap between MPLS fast-reroute and
physical link failure detection (such as SONET APS). Although both try
to minimize packet loss, these are fundamentally different technologies.
One does not replace the other, and one does not preclude the use of
other. 

In particular, one big difference between the two is timing:
fast-reroute time is probably lower than typical ISIS/OSPF convergence
time in today's backbone. But fast-reroute time may still be higher than
SONET APS. In particular, I don't think that fast-reroute can offer
guarantees on the upper bound of fail-over time. There are simply too
many uncontrollable variables affecting the fail-over speed, no matter
what type of fast-reroute mechanism you choose.

Regards,

- Ping

---

From: Robin Park <[email-masked]>
Date: Wed, 04 Apr 2001 11:28:47 -0400

Dave,

Alcatel's implementation of MPLS does support statically configured LSPs.  I would
guess other vendors support statically configured LSPs.

Whether service providers widely use statically configured LSPs is another
question, but a blanket assumption that all LSPs are configured via signaling may
not be true.

In these cases, the control-plane would not detect data-plane failures.

Regards,

Robin.

---

From: Giles Heron <[email-masked]>
Date: Wed, 04 Apr 2001 21:09:15 +0100

> guess other vendors support statically configured LSPs.

Juniper certainly does.

> question, but a blanket assumption that all LSPs are configured via signaling may

I've yet to see a live deployment with static LSPs, but then I've only
got involved with 3 or 4 live MPLS networks.  Once or twice I have
considered using static LSPs for something - for about five seconds in
each case!

> In these cases, the control-plane would not detect data-plane failures.

True.  But in general if you choose to use statically configured LSPs
then I suspect a pretty hefty dose of caveat emptor should apply -
regardless of whether you have any OAM signalling...

Giles

-- 
============================================================
Giles Heron      Principal Network Architect      Gone2 Inc.
ph: +44 7880 506185         "if you build it they will yawn"
============================================================

---

From: Eric Osborne <[email-masked]>
Date: Wed, 4 Apr 2001 17:31:44 -0400

> > guess other vendors support statically configured LSPs.

There's a few ways this can be defined.  Do you mean "LSPs which are
not signalled via RSVP, but have crossconnect label values manually
configured at each hop", or "LSPs which have a per-hop path statically 
defined on the headend, which can be configured as to never ever
change, but which the headend signals via RSVP"?

eric

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Apr 2001 19:49:36 -0400

In message <[email-masked]>, Robin Park writes:
> This is a multi-part message in MIME format.
> --------------77D7BFECF73FA26A09450C19
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Dave,
> 

Ours supports this feature as well.  So does Cisco and Juniper.

> question, but a blanket assumption that all LSPs are configured via signaling

My only point was that I know of no one that is building a network
using statically configured LSPs.  The assumption was made by Dave
that the opposite was true.  I was just commenting on the validity of
that assumption.

> In these cases, the control-plane would not detect data-plane failures.

Providing measurement capabilities to better deal with rare errors
that may be undetectable when using an unused feature sounds like a
weak argument.  I suppose it would be up to the TE-WG whether that
constitutes a requirement.  In the ITU maybe.  :-)

> Robin.

The subject says "Last Call on RSVP Label Allocation for Backup
Tunnels" and we have strayed off this topic.

Curtis