The MPLS WG Archive

[Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>]

Hi Alan

Thank you for your comments on our draft.

>Here are some specific comments on the draft:
>
>1.  What is the expected behavior at the branch point when trying to setup
>more than one LSP (multiple PATH messages are sent). How long should the
>branch node wait for all of the returning RESVs to be received and what is
>the recovery mechanism if the node does not receive an RESV for all PATH
>messages.

We consider the branch node to wait for all the reply messages coming from 
downstream
leaf nodes to which the branch node send path messages to establish a sub-tree.

When the branch node succeeds in total establishment of sub-tree, it is 
expected that
the branch node receives the all of Resv messages corresponds to Path 
messages before long
from the all of downstream leaf nodes.

When the branch node succeeds in partial establishment of sub-tree, it is 
expected that
the branch node receives the Resv messages and PathErr messages before long
from the all of downstream leaf nodes.

But we must assume abnormal case such as link failure between the branch 
node and
downstream leaf nodes.

In this case, the branch node not always receives the all the reply 
messages from the downstream
leaf nodes.

We think implementing timer is useful for those recovery mechanism.

>2. For each type of the Notify message, when it reaches the sender node, the
>sender must update the TERO in the outgoing PATH message to reflect the
>changes in the multicast tree.  This must be stated in the draft.

In our design, topological change must be notified to LSP setup initiator 
at first.
And this information must be propagated to all of the nodes within the LSP by
updated TERO in the refresh Path message.
We will describe this mechanism in our revised draft.


>3. See figure 9 on page 27.
>The PATH message from node B to node E includes the sub-tree from node E
>downwards.  When the PRUNE message arrives at E, E sends a PATH_TEAR
>downstream and a PRUNE_NOTIFY to the sender node A.  If node B sends a PATH
>refresh message (with the old TERO), then E will setup the sub-tree again.
>But if the PRUNE_NOTIFY to node A causes A to remove the sub-tree from the
>TERO and send the modified PATH, and the PATH is received at B before B
>sends a PATH refresh to E, then no problem occurs.
>This is a race condition that is very likely to happen.  This race condition
>exists for both the prune and the leave mechanisms.  A similar problem could
>also exist for the JOIN and GRAFT mechanisms, depending upon what a node
>should do when a PATH with TERO is received that does not specify an already
>signaled sub-tree below this node.
>A possible solution to the prune and leave problems is to implement a D
>(delete) bit in the TERO sub-objects similar to that in
>draft-cheng-mpls-rsvp-multicast-er-00.txt, except that when the prune or
>leave is done, the branch point node sends some kind of NOTIFY message to
>the sender so that the sub-tree may be removed from the TERO. This requires
>a leaf node to send the LEAVE request all the way to the sender.
>A possible solution for the join and graft problems is to signal the join or
>graft by sending a modified TERO from the sender node and then having the
>branch point send some kind of NOTIFY message to the sender upon successful
>signaling of the join or graft.  This requires a leaf node to send the JOIN
>request all the way to the sender.

We think your proposed solution is one of the solutions for race condition.
But we think your proposed solution is not suitable in terms of scalability
and processing speed.
In your proposed design, all of the node must process a new Path message
to prune the partial sub-tree.
This means that  the information of sub-tree must be processed
at every intermediate node which have no relation to this partial sub-tree.
And we cannot expect quick prune operation of partial sub-tree in this design.
#Quick prune operation is important for first path recovery application.

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.

I
>4. In figure 14, at the bottom, why is a PATH message being sent from node A
>to node B? Is this a typo?

Yes, this is a typo.

>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 ?

>6. On page 36, last paragraph, the TERO is included in the PATH_TEAR
>message, but the contents of the PATH_TEAR message was not shown to contain
>the TERO.

Though Path_Tear has the TERO, massage format of Path_Tear in page 22 is lack
of TERO.
This is typo.
We will modify Path_Tear message format in next version.


>7. In figure 7, on GRAFT mechanism, does GRAFT mechanism require that node E
>was already a branch point?  I think yes, otherwise data won't be sent from
>node B to the node E sub-tree until sender node A updates the TERO and B
>sends a PATH to E and E sends a RESV to B.

No, any nodes within the multicast LSP can become graft node in our proposal.
Please note that multicast LSP is already established between nodeA, B, D, E, C
before node A send a Graft message to node E in figure 7.


>8. Can a node be both a leaf and a branch?  If yes, how does a node know
>that it is both?
>

We think it is better for a node to be both a leaf and a branch.
We think some dicussions are already made in draft-ietf-mpls-multicast-08.txt.

We can realize this by adding identification bits in TERO.
This identification bits indicate placement (1. Leaf 2. branch 3. Both) of 
the node.

By using this TERO in Path message, we can setup a node to be both a leaf 
and a branch.
We think some another discussion is necessary to realize this mechanism.

Seisho