The MPLS WG Archive

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

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