The MPLS WG Archive

["Kullberg, Alan" <akullber@netplane.com>]

Hi Seisho,

See comments below.

Alan

> Our prune process also can solve this race condition
> In our design, Graft/Prune/Join/Leave message take precedence 
> over Path
> refresh message.
> This means that the Prune node does not send Path messages to 
> the pruned
> sub-tree in case the contents of TERO in the Path refresh 
> message specifies
> this sub-tree.
> Note that we must send Graft message if we want to re-establish pruned
> sub-tree.
> Therefore, our proposed mechanism can prevent racing problem.
> 
> And because those messages are not process at unrelated 
> intermediate nodes,
> our process can attain quick Graft/Prune operation in a 
> scalable manner.

Okay, but then does the Prune node "remember" that a prune
operation has been performed, and if so, for how long?
If not, then there is a race condition whereby the next
PATH refresh from the upstream node (containing the old
TERO with the pruned sub-tree) could cause the sub-tree
to be re-established.

> >5. Instead of sending an ADD message for MP-to-MP, why not 
> send a PATH
> >message that has the 2 new objects in the ADD message?
> 
> Add message has different function from Path message.
> So we define new Add message.
> Do you think Path message with 2 new object is better than 
> Add message ?

I think that adding objects to the PATH message would be easier
for an existing implementation.