The MPLS WG Archive

["Reddy, Vikram" <vikramr@netplane.com>]

Hello Yasukawa-san,

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.

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.

Thanks,
Vikram.





-----Original Message-----
From: Seisho Yasukawa [mailto:yasukawa.seisho@lab.ntt.co.jp]
Sent: Tuesday, September 03, 2002 4:09 PM
To: Reddy, Vikram
Cc: 'mpls@UU.NET'
Subject: Re: Questions/Comments regarding
draft-yasukawa-mpls-rsvp-multicast


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
>another muticast group.

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.

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

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


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

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.

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

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

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

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

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

We would like to modify both statements.

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

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

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

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

Thanks,

Seisho