The MPLS WG Archive

[Ping Pan <pingpan@juniper.net>]

Apratim Mukherjee wrote:

> Hi ,
> 
> Doubt #1 :
> Lets take a set-up
> 		 |-----------------N6---------------------|
> 		 |    			        |
> 	------N1 ------ N2 ----- N3 -----N4 -----N5-----
> 
> 	N1 is sending summary refresh to N2 for a Path message destined to
> N5 currently going thru n2 , n3 , n4 
> 
> 	so , if  a route change occurs for only this path ( link betwn n4
> and n5 goes down) then should it not send a trigger refresh immediately to
> N6 and stop sending summary refresh to N2 ? 
> 	If , in a specific implementation , there is no route change
> notification , then should it check for each path refresh it sends out in
> form of msg id, whether route has changed so that the path message should
> now go thru another next hop ?
> 


Refresh reduction should be used right before transmitting the messages. 
If the messages are triggered ones, get an id... If they are refresh 
ones, send id's only (SummaryRefresh for example). It has nothing to do 
with route notification. Per RSVP RFC, there are two ways to deal with 
route changes: active (get an upcall from routing) and passive (check 
routing before sending). So don't get confused here.


> 	Doubt # 2 :
> From RFC2961 abt refresh reduction:
> "Srefresh NACKs are used to indicate that a received
> Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST, or
> MCAST_LIST object does not match any installed state.  This may occur
> for a number of reasons including, for example, a route change."
> 
> Could someone tell me how this would occur ?


Upstream route changes.


> If my previous assumptions are correct then the previous hop will not send a
> refresh summary message for a path message whose route has changed . i feel
> that only if a path tear or resv tear has happened after a route change then
> at node N1 if a resv refresh msgid is sent from N2 after route change has
> occured and then a state teardown , will this sort of a situation arise
> .Please correct me if i am wrong .
> 


Please read RSVP RFC more carefully.

- Ping


> Thanks 
> Apratim
>