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

From: [email-masked]
Date: Mon, 2 Apr 2001 10:19:08 +0100

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: Giles Heron <[email-masked]>
Date: Wed, 04 Apr 2001 12:57:58 +0100

> topology has to takes its design cues from the duct for rigorous resilience

I'll take that as a "no" then ;-)

Seriously I think it is the case that for MPLS the control and user
plane will almost always go through the same path (since in the LDP case
both the control and user planes follow the IGP, whilst in the RSVP case
the user plane follows the path of the RSVP RESV message.)  The
exception could be when BGP is used for label distribution (because of
route reflection etc.)  However for the BGP VPN case there is a layer of
(typically LDP derived) labels over which the VPN labels operate (and so
these will detect any network failure), whilst in the eBGP case you'd
hope that the MP-eBGP session runs directly over the link for which
labels are being assigned?

> NH=> Lots of things don't support merging....nor is merging always such a

No, it isn't always a wonderful thing.  But it is a useful tool to have.

> specification, albeit currently proprietary....but these need standardising.

I think a fair assumption is to say that if the LSP fails from the
control plane point of view then it is considered to be down.  I know
this doesn't catch the "rare" cases, but I think it is workable for all
intents and purposes (especially since the OAM code to catch the "rare"
cases would have failure modes itself!)

> -       where are the 'consequent actions' on failure specified?

Presumably in the case of George's draft the "consequent action" should
be to reroute over a backup tunnel?

> -       where is the definition of availability specified?

I'd specify it as the % of time for which the LSP is up from the control
plane point of view?

> -       and how can we move on to define QoS metrics/objectives if we can't

Agreed - so let's take a simple definition as above.

> questions, but you also don't have any alternative proposals either.

I'd say I just made a perfectly workable proposal - from the point of
view of a pragmatist who has to build and run a production network.  I
suspect your viewpoint is somewhat different.

> did not think these complex.

I'd say 29 pages for a first revision of a draft is pretty meaty. 
Especially when the P flow and support for merging LSPs are FFS, and the
figures are all missing?

Giles

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