The MPLS WG Archive

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

I think that this draft has technical merit in that an IGMP Multicast
protocol is not required.  Also, protocols other than IP can be supported
since there is no dependence on an IP multicast address as the destination.

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.

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.

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.

4. In figure 14, at the bottom, why is a PATH message being sent from node A
to node B? Is this 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?

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.

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.

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


Alan