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

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

Hi All,
     I have couple of soubts and suggetions for  http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-16.txt.

Doubts:

“To guard against a situation where bandwidth under-provisioning will last forever, a local timer (named the "Soft preemption timer") MUST be started on the preemption node, upon soft preemption.  If this    timer expires, the preempting node SHOULD send an RSVP PathTear and    either a ResvTear message or a PathErr with the 'Path_State_Removed'    flag set “
 
In the process of soft preemption, till the time low priority LSP is turned down; will the traffic from both the LSP's (including the about to be prempted low priority LSP) flow through the same link?

“Under specific circumstances such as unacceptable link congestion, a   node MAY decide to hard preempt a TE LSP (by sending a fatal Path    Error message, a PathTear and either a ResvTear or a Path Error    message with the 'Path_State_Removed' flag set) even if its head-end    LSR explicitly requested 'soft preemption' ('Soft Preemption desired'    flag of the corresponding SESSION-ATTRIBUTE object set).  Note that    such decision MAY also be taken for TE LSPs under soft preemption    state.”
 
How can congestion be measured? Is it left to developer to get the information from the data plane?

Suggestions:
 
“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 to 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). As it would be 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 in case 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