Subject: [mpls] questions on draft http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-16.txt.

From: SANTOSH PALLAGATTI <[email-masked]>
Date: Mon, 23 Mar 2009 10:58:57 +0000 (GMT)

Hi All,
    I have couple of questions on  http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-16.txt.

As per the draft 
"The preempting node MUST immediately send a PathErr with error code    "Reroute" and a error value "Reroute request soft preemption" for each soft preempted TE LSP.  The node MAY use the occurrence of soft    preemption to trigger an immediate IGP update or influence the    scheduling of an IGP update" 

1. PATH ERR message will be destined to previous hop. Assume that for some LSP's which need to be preempted at previous hop of egress (almost tail end of LSP), in this case there would be a delay to notify head end. Why cant we unicast PATH ERR message directly to head end router? So that it will speed up the notification (acknowledgment can be considered in case of reliability). 

In this case the problem would be receiving the PATH ERR on different interface. In case of unicast there could be chance where head end node receives the PATH ERROR on the interface different from the interface through which it established LSP, with the help of session object it can still identify the LSP for which a notification was received. Here RSVP-TE router should be ready to accept the RSVP-TE message on interface where RSVP is not enabled.

2. Why not consider crankback as specified in RFC 4920? (This would ofcourse introduce delay only in case if it don't get the alternate path to destination, from intermediate routers  till head end from the point of failure)

Thanks and regards
Santosh P K

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 23 Mar 2009 15:38:56 -0000

Santosh,

Direct-to-repair-point error event signaling is provided by the RSVP-TE 
Notify message.

Cheers,
Adrian
----- Original Message ----- 
From: "SANTOSH PALLAGATTI" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 23, 2009 10:58 AM
Subject: [mpls] questions on draft 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-16.txt.

> Hi All,
>    I have couple of questions on 
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-16.txt.
>
> As per the draft
> "The preempting node MUST immediately send a PathErr with error code 
> "Reroute" and a error value "Reroute request soft preemption" for each 
> soft preempted TE LSP.  The node MAY use the occurrence of soft 
> preemption to trigger an immediate IGP update or influence the 
> scheduling of an IGP update"
>
> 1. PATH ERR message will be destined to previous hop. Assume that for some 
> LSP's which need to be preempted at previous hop of egress (almost tail 
> end of LSP), in this case there would be a delay to notify head end. Why 
> cant we unicast PATH ERR message directly to head end router? So that it 
> will speed up the notification (acknowledgment can be considered in case 
> of reliability).
>
> In this case the problem would be receiving the PATH ERR on different 
> interface. In case of unicast there could be chance where head end node 
> receives the PATH ERROR on the interface different from the interface 
> through which it established LSP, with the help of session object it can 
> still identify the LSP for which a notification was received. Here RSVP-TE 
> router should be ready to accept the RSVP-TE message on interface where 
> RSVP is not enabled.
>
> 2. Why not consider crankback as specified in RFC 4920? (This would 
> ofcourse introduce delay only in case if it don't get the alternate path 
> to destination, from intermediate routers  till head end from the point of 
> failure)
>
>
> Thanks and regards
> Santosh P K
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>