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

From: Robert Raszuk <[email-masked]>
Date: Sun, 01 Apr 2001 00:02:15 -0800

Giles,

> > For the user-plane, the failure modes which must be considered/defined are:
> > -       simple below MPLS fabric server layer connectivity breaks;
> > -       simple within MPLS fabric connectivity breaks (at or below the LSP
> > level considered);
> 
> Both of these will be detected by the RSVP signalling, won't they?

Sure but the question is when ? 

Do you think that RSVP Error/Tear msgs will travel immediately - case of
link failure or are you proposing to run RSVP refresh in the interval
less then 1 sec - to detect the case of node failure ? The point is that
this draft is not about detection, but about backup LSP setup and label
allocation under the __local__ protection scheme. So let's talk on the
subject here. 

If one questions the use of local protection all together please specify
how else you will achive the same results of even less then 1 sec end to
end traffic disruption with end to end protection under both link & node
failures for the TE- LSP ? 

Bora,

Which CCAMP IDs address the setup & label allocation of backup tunnels
for local protection ?

R.

---

From: Giles Heron <[email-masked]>
Date: Mon, 02 Apr 2001 06:25:24 +0100

> allocation under the __local__ protection scheme. So let's talk on the

Sorry if I drifted off (or was led off) topic there.

In any case yes I would expect link failures to be detected
immediately.  Node failures presumably require some form of polling to
detect - so the questions are:

at what level should this occur (link layer, RSVP, "MPLS OAM"?)
how low is it reasonable to set the timers?
 
> failures for the TE- LSP ?

I'm all for local protection - precisely because it would be so hard to
get end to end protection to meet the <1 sec goal.

Giles

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 01 Apr 2001 22:13:26 -0700

Giles,

> immediately.  

Detection does not equal headend notification, but anyway as you agree
that local protection is a good thing I don't see a reason to hold this
draft and not to proceed to last call - we needed it for customers using
FRR today and want to interoperate with multiple vendors. 

Unless there is any other piece of work addressing this very specific
issue of label allocation on bypass tunnels (not reroute in general) in
mpls or ccamp I would agree with George's last call.

R.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Apr 2001 15:24:54 -0400

In message <[email-masked]>, nei
[email-masked] writes:
> Some comments:
> 
> 1	Where did the requirements in section 1 come (and is there a
> reference?):
> "In order to meet the needs of realtime applications such as Voice
>    over IP, it is highly desirable to be able to repair LSP tunnels in
>    10s of milliseconds. "?
> 
> I would suggest voice would be one application where 1-2s of outage was
> tolerable, cf  someone not answering a question immediately, but instead
> thinking for a short period of time before answering.  In general I do not
> believe customers would close down a voice call for an outage of the order
> of 10ms, but they might on the order >3s.

You telco guys can never make up you minds how touchy this SONET stuff
actually is.  :-)

What I've heard indirectly is that the per NE budget in sonet is 50
msec and that some sonet gear is fairly hard coded to drop connections
if more than on the order of 100 msec of signal loss is observed.

Maybe that's just a nasty rumor going around.  :-)

> 2	At the top of page 5 in section 2 it says:
> " When a failure occurs and the backup comes into use,......"
> 
> All user-plane (and indeed control-plane) failure modes must be identified
> and specified in terms of entry/exit criteria and consequent actions before
> we can meaningfully proceed with this draft. 

I see no reason to expand the scope of this document.

> -	swapped LSPs, ie instead of A1->A2 and B1->B2 a defect creates
> A1->B2 and B1->A2;
> -	mismerged LSPs, eg instead of A1->A2 and B1->B2 a defect creates
> A1->A2 and A1+B1->B2 say (though there are potentially several variations on
> this).

Link defects are covered.  IE: the link is POS over linear SONET and
SONET framing has detected that the link is no longer useable.

If a label table was incorrect on this router and it was detectable,
the solution would not be to reroute it would be to fix the table
entry.

> For the latter 2 defects it will be vital to suppress the traffic due to
> potential security/censorship/misbilling implications for carriers and
> customers.  Speaking as a carrier these issues are requirements that must be
> addressed.  This is not optional, and rigorous definitions must be provided
> (or referenced). 
> 
> Neil Harrison
> BT/Ignite/CTO/Network Architecture
> Tel +44 1 604 820 724
> mail [email-masked]

It would almost appear to me that you are simply interested in
expanding the scope of this document to require your OAM document so
that it could detect failures that it currently isn't intended to
address.  Nice try.

Curtis