The MPLS WG Archive

[Giles Heron <giles@goneto.net>]

neil.2.harrison@bt.com wrote:
> 
> 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.

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

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

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

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

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.

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

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

> 
> Neil Harrison
> BT/Ignite/CTO/Network Architecture
> Tel +44 1 604 820 724
> mail neil.2.harrison@bt.com
> 
> 
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: 29 March 2001 00:04
> > To: mpls@UU.NET
> > 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
> >
> >
> >

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