Subject: Questions/Comments regarding draft-yasukawa-mpls-rsvp-multicast

From: "Reddy, Vikram" <[email-masked]>
Date: Mon, 2 Sep 2002 09:18:44 -0400

Hi all,

I have a few questions/comments regarding the RSVP multicast draft.

1) Can a mulicast address be a part of the TERO (as a Leaf node address).
    I have in mind a multicast LSP with a sub-tree containing the nodes of
another muticast group.

    If not I would like to know the reason for the following statement in
section 3.7.1.2

  "A loose explicit route allows an external routing algorithm to decide the
route between specified nodes.  
   Multicast routing algorithm such as PIM-SM[8] and MOSPF[9] are examples
of such algorithms. 
   These routes are selected at each link of the tree. "

The above statements seem to imply that if there is a loose hop (i.e
incomplete information at the source),
then there is a need at the intermediate nodes for the existence of
multicast routing capabilities to resolve
it even further. 
My question is, if we use only Unicast address as ER hops in the TERO, what
is the need for the exsitance of 
mulicast information at the intermediate nodes.

2) Typo in Section 4.5.1. Instead of 
   TERO is added to the Resv message. 
  it should be "TERO is added to the Path message. "
3) In section 5.1, regarding the statement.
"This grafting process is initiated not only by the sender node but also by
the NMS. "
What is meant by the above statement. I would think that the NMS cannot
directly signal a grafting
process. What probably is meant is, the NMS can signal the ingress to
initiate a grafting process.
In any case, it is always the ingress which signals a grafting process as
far as RSVP is considered.
NMS can never directly signal a grafting process.

4) In section 5.2 regarding the statement.
"This pruning process is initiated not only by the sender node but also by
the NMS. "
Same argument as above.
5) After a graft notify/join notify/ prune notify/leave notify are received
by the ingress, the ingress should
update the TERO. This is not specified. 

6) Since there are new messages introduced, it would be more helpful if
there is explicit mention of how each 
message is sent i.e with or withiout router alert etc.

Thanks,
Vikram.

---

From: Seisho Yasukawa <[email-masked]>
Date: Tue, 03 Sep 2002 19:38:59 +0900

Vikram

>1) Can a mulicast address be a part of the TERO (as a Leaf node address).

A multicast address can be a part of the TERO as a Leaf node address 
theoretically.
But we don't assume this case in the first version of our draft.

>     I have in mind a multicast LSP with a sub-tree containing the nodes of

We also think a multicast LSP with a sub-tree containing the nodes of another
multicast group is very attractive when considering backbone usage.
We can convey several multicast group's traffic that splits into several 
different
mulitcast LSP in the peripheral networks, in common within the backbone network.
But we think several new mechanism must be developed to realize this application.
Therefore, we are not targeting to discuss this new technology in our draft.

>multicast routing capabilities to resolve it even further.

This is typo.
Correct example of external routing algorithm is unicast routing algorithm
such as OSPF and IS-IS.

>mulicast information at the intermediate nodes.

We think using multicast address as ER hops in the TERO can provide another
attractive function.
We can setup multicast LSP automatically using L3 multicast routing information
that is constructed by multicast routing algorithm.
We will discuss this mechanism in our future draft.

>   it should be "TERO is added to the Path message. "

Thank you for your comments.
We would like to modify this error in the next draft.

>NMS can never directly signal a grafting process.

We also don't assume the NMS directly signal a grafting process.
As you mentioned above, the meaning of statement is "the NMS can signal
the ingress to initiate a grafting process".

>"This pruning process is initiated not only by the sender node but also by

We would like to modify both statements.

>update the TERO. This is not specified.

We would like to specify this mechanism in the next draft.

>message is sent i.e with or withiout router alert etc.

We would also like to specify above point in the next draft.

Thanks,

Seisho

---

From: Seisho Yasukawa <[email-masked]>
Date: Fri, 06 Sep 2002 00:45:20 +0900

Hello Vikram

>I have one more question regarding the draft. The following is from the
>draft.
>
>    Either the intermediate node or the leaf node may calculate the
>    multicast tree route in order to decentralize this calculation. So
>    all nodes belonging to the same multicast group need to have
>    information about the whole multicast tree topology in order to
>    prevent intersection of multicast tree.  Each node MUST NOT delete
>    the TERO subobjects that specify nodes on the explicitly routed path
>    in order to get the whole multicast tree topology information. Each
>    node MAY record the whole multicast tree topology from TERO. In this
>    way, all nodes can have the same information about the whole
>    multicast tree topology.
>
>The above states that all the nodes in the multicast tree have to have
>the full information about the multicast tree.
>I would like to know the technical reasons for this requirement.
>The obvious drawbacks with this requirement is the increase in the
>the message sizes with the increase in the number of nodes.

Technically, it is preferable to maintain the full information about the
multicast tree to avoid creating the multicast tree loop.
When considering leaf initiated Join process, the node receiving the
Join message become a leaf LSP setup initiator.
(We call this node as a Graft node)
Therefore the Graft node must be check whole multicast tree topology
when grafting leaf LSP to avoid the creation of multicast loop.

>In my opinion, if every node maintains the previous hop and the
>next hop(s) information, it should be enough, unless you see some
>specific technical reason for the above information. If it is
>only for the NMS show/information/display purpose, I feel it
>is better to do it at the source node itself and thus remove this
>requirement.

We also recognize the drawback of this architecture when considering
system implementation.
To maintain whole topology of multicast tree require huge memory
resource at each node.
This restricts network and system scalability.

Therefore, we want to modify this requirement mandatory to optional
in next version of our draft.

Thanks,

Seisho