RE: Last Call on RSVP Label Allocation for Backup Tunnels

[neil.2.harrison@bt.com]

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