Subject: signaling preemption in GMPLS RSVP

From: "Reeve, Andrew" <[email-masked]>
Date: Fri, 4 May 2001 16:57:37 +0100

Section 4 'Removing State with a PathErr message' in draft-ietf-mpls-generalized-rsvp-te-03.txt makes a welcome improvement to the signaling when LSPs are torn down by the network. I assume that it is intended that the benefits be obtained for any 'network clear'. However the draft mentions its use for 'certain error conditions' without explaining what these are. I suggest that the section be modified to state explicitly that the mechanism can be used anywhere a PathErr is used. In other words it should be possible to use the Path_State_Removed flag for any error and also to use it during preemption.

Regards,
Andy
> __________________________
> Andy Reeve,
> Senior Consultant,
> Internet Technology and Networks.
__________________________

> Roke Manor Research Ltd,
> A SIEMENS Company.
> 
> Roke Manor, 
> Romsey. SO51 OZN.
> 
> Tel: +44 1794 833580
> Fax: +44 1794 833616
> 
> mailto:[email-masked]
> 
> http://www.roke.co.uk
> http://www.roke-manor.com
> __________________________
The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission.  This communication is for information only and shall not create or change any contractual relationship.

---

From: "Hong Liao" <[email-masked]>
Date: Sun, 6 May 2001 18:32:38 -0400

Hi,

Look at this message, I would like to ask some question related to this in
RSVP-TE.

For my understanding of RSVP-TE , if there is a Path message send out from
the Ingress router,  and there is no Resv message back from the Egress
router, the Ingress router should send out PathTear to clear the
connect(path state) instead of sending out PahtErr to clear the connection.
I did not find this statement 'Removing State with a PathErr message' in
the latest version of RSVP-TE.

Sorry I know you are discussing about the GMPLS RSVP.

Can anyone point me out?

Thanks,

Julia

"Reeve, Andrew" <[email-masked]> on 05/04/2001 11:57:37 AM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Hong Liao/Telcordia)
Subject:  signaling preemption in GMPLS RSVP

Section 4 'Removing State with a PathErr message' in
draft-ietf-mpls-generalized-rsvp-te-03.txt makes a welcome improvement to
the signaling when LSPs are torn down by the network. I assume that it is
intended that the benefits be obtained for any 'network clear'. However the
draft mentions its use for 'certain error conditions' without explaining
what these are. I suggest that the section be modified to state explicitly
that the mechanism can be used anywhere a PathErr is used. In other words
it should be possible to use the Path_State_Removed flag for any error and
also to use it during preemption.

Regards,
Andy

> http://www.roke-manor.com
The information contained in this e-mail is confidential to Roke Manor and
must not be passed to any third party without permission.  This
communication is for information only and shall not create or change any
contractual relationship.