[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call on RSVP Label Allocation for Backup Tunnels
Robert Raszuk [mailto:firstname.lastname@example.org] wrote 01 April 2001 09:02
> > > 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
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.