RE: Last Call on RSVP Label Allocation for Backup Tunnels

["Lazer, Monica A, NNAD" <mlazer@att.com>]

Voice switches will drop the connections after 2.5 seconds. A large number
of dropped calls will cause FCC reportable events, which is something that
US carriers need to avoid. So restoration within this time frame is needed
for support of trunks carrying voice traffic.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
mlazer@att.com


-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Monday, April 02, 2001 5:19 AM
To: raszuk@cisco.com
Cc: mpls@UU.NET; ccamp@ops.ietf.org
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels

Robert Raszuk [mailto:raszuk@cisco.com] wrote 01 April 2001 09:02
> 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 ?
NH=> Fair point Robert.....but it still leaves me wondering:
1       Why do we need such fast action......voice surely does not need few
10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare
case of failure......unless, perhaps, one expects such failures to occur on
a very frequent basis)?
BTW- I suspect the biggest source of 'disruptions' will be planned-works by
operators at L1, ie pre-meditiated re-routing of traffic.....so some care
should be taken that such actions don't invoke unecessary actions in higher
layers.
2       Where are the failures referenced specified?  Have Cisco their own
specifications for this?  We would really like to see these specified in
some standard manner.

thanks/regards, neil