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

From: "Lazer, Monica A, NNAD" <[email-masked]>
Date: Fri, 6 Apr 2001 08:01:35 -0400

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 02, 2001 5:19 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels

Robert Raszuk [mailto:[email-masked]] 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

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 08 Apr 2001 22:36:33 -0400

In message <[email-masked]>, "L
> Advanced Transport Technology and Architecture Planning

Monica,

We're off topic, so I changed the subject.

Thanks for providing the 2.5 second figure.

I've heard carrier transport people grumble about SONET equipment
they'd be please to get rid of that will shut down even when used as
linear SONET with no protect path and as a result would require
<100msec restoration.  Since there is enough of this SONET gear, the
carriers can't really get rid of it although it will probably
disappear over time and so they will make fast restoration a
requirement of people they buy from.  To be safe, the request for
<50msec has been made.

If you are not blessed with such equipment or you are able to work
around it when doing VoIP, then you are among the fortunate.

Then again, this is second hand, so I could be completely wrong.  This
is not a measurement I've made myself and the SONET equipment is not
something I'm familiar with such that I could say with confidence that
it could not be configured to hold on longer or to not shut down at
all if there was no protect.

OTOH there are those who (claim to) want to configure SONET on some
links but not on others and don't want a fast restoration.  They want
to be assured that restoration will occur only after it is safe to
assume that SONET restoration is not available.

Curtis