Subject: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt

From: "Kullberg, Alan" <[email-masked]>
Date: Mon, 1 Jul 2002 16:15:32 -0400

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

---

From: Hummel Heinrich <[email-masked]>
Date: Thu, 4 Jul 2002 18:07:18 +0200

Two comments:
1) Three years ago me and Swee Loke (formerly Nortel) provided perfect algorithms for computing and processing explicit tree route information (each transit LSR could recognize whether or not it was a leaf node itself, which are its proper child links and which part of the received tree route info has to be forwarded via which child link. However that 
draft-hummel-mpls-explicit-tree-01.txt was grounded by the chairs.

2) Can a node be both a leaf and a branch? For sure, this needs  to be enabled.  
If yes, how does a node know that it is both? 
We provided a perfect indication in the TREE ROUTE TLV. W.r.t. the data flow,
I have nowhere seen some description like: the incoming label may be mapped to
more than one outgoing labels by means of a set of NHLFEs bound to the particular
incoming label. If one these NHLFEs contains the IPv4_NULL_LABEL then this node is also leaf node.

Heinrich Hummel
Siemens

-----Ursprüngliche Nachricht-----
Von: Kullberg, Alan [mailto:[email-masked]]
Gesendet: Montag, 1. Juli 2002 22:16
An: MPLS_WG (E-mail)
Betreff: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt

Alan

---

From: Seisho Yasukawa <[email-masked]>
Date: Fri, 05 Jul 2002 02:41:21 +0900

Hi Alan

Thank you for your comments on our draft.

>the recovery mechanism if the node does not receive an RESV for all PATH

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.

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

>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
>to node B? Is this a typo?

Yes, this is a typo.

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

>message, but the contents of the PATH_TEAR message was not shown to contain

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.

>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

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

---

From: "Kullberg, Alan" <[email-masked]>
Date: Tue, 9 Jul 2002 19:47:46 -0400

Hi Seisho,

See comments below.

Alan

> our process can attain quick Graft/Prune operation in a 

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.

> Do you think Path message with 2 new object is better than 

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