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

From: [email-masked]
Date: Thu, 29 Mar 2001 09:45:07 +0100

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.

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. 

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

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]

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: 29 March 2001 00:04
> To: [email-masked]
> Subject: Last Call on RSVP Label Allocation for Backup Tunnels 
> 
> 
> This message commences a workgroup last call on "RSVP Label Allocation
> for Backup Tunnels" <draft-swallow-rsvp-bypass-label-01.txt>.  This
> draft is informational.  The last call closes April 11, 12 PM GMT.
> 
> ...George
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
>

---

From: Giles Heron <[email-masked]>
Date: Thu, 29 Mar 2001 22:27:28 +0100

> of 10ms, but they might on the order >3s.

Definitely.  I've never quite understood where the whole 10s of
milliseconds thing came from.  Sure, SONET/SDH can do this - but how
many applications need it?  We had a voice network long before SONET was
invented...

> -       simple within MPLS fabric connectivity breaks (at or below the LSP

Both of these will be detected by the RSVP signalling, won't they?

> A1->A2 and A1+B1->B2 say (though there are potentially several variations on

Both of these would only occur (as far as I can tell) if the router
software is buggy.  As I have stated before I don't really see the
benefit of adding code to fix buggy code.

> addressed.  This is not optional, and rigorous definitions must be provided

Speaking as another carrier I *don't* see these as requirements that
must be addressed.  If software is buggy things go wrong.  So let's fix
the software rather than adding another layer to "manage" the bugs.

Giles

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

---

From: David Charlap <[email-masked]>
Date: Thu, 29 Mar 2001 16:27:18 -0500

Giles Heron wrote:
> many applications need it?  We had a voice network long before SONET
> was invented...

In a circuit emulation environment, <10ms rerouting means you can
reroute around a failure before SONET APS kicks in.  This is why it is
used in the ATM world, anyway.

For applications other than circuit emulation, you're right.  There
shouldn't be a need for _that_ level of performance.

-- David

---

From: Peter Willis <[email-masked]>
Date: Fri, 30 Mar 2001 17:06:24 +0100

> benefit of adding code to fix buggy code.

If the LSR software was sufficiently simple that it could be proved to be correct,
I guess we're all aware of formal software validation and testing methods, then the
value of adding more software to monitor for "bugs" could be questioned. I guess,
and the vendors will no doubt shout if I'm wrong, that they have NOT formally validated their software.

Safety Critical Systems use the practice of "watchdog" code to check for abnormal conditions and limit the damage caused by the abnormal conditions. Safety
Critical Systems should also handle "rare" conditions.

I guess that no one is planing to use MPLS networks to support safety critical systems so we have no need to worry about having "watchdog" code to detect abnormal conditions and limit the hazard they may cause. 

By the way the car I drive has a low brake fluid detector but no bulb on the dashboard
to display when its detected low brake fluid. At least I don't have to worry about
checking the low brake fluid bulb is working (its a British sports car!) and I don't get stopped by false alerts from the low brake fluid detector, besides I know when the brake fluid is low when the brakes stop working.

Peter.