The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01,thank you!
Jin, > > Can you give an example of a multicast routing protocol that > populates > such a table? > > jin.lizhong:Different multicast routing protocols may generate > different trees > (the tree may be generated by DVMRP or PIM-DM protocol). Z can > determine the > upstream LSR by following the multicast routing protocol messages. Then > the P2MP or MP2MP LSP is identical to the L3 multicast tree. Which is > the best path for Z is hard to say, the path determined by unicast > routing > protocols or multicast routing protocols. The only multicast routing protocol that creates its own unicast path is DVMRP. It is very unrealistic that customers will use DVMRP to create a unicast table that LDP will use to build the P2MP or MP2MP LSP. > > > > > > The two ways are not compatiable, and the two P2MP LSPs or MP2MP > LSPs > > are defferent. Maybe this draft should describe the two ways, and > > specify one way or both the two ways. The best path selection > problem > > should be solved. > > Are you suggesting we should set priority to one table over the other? > > It looks to me that the table selection is a local policy and does > not > necessarily need to be the same on each LSR. You may want to use a > MuRIB between 2 LSRs just to make Multicast divert from Unicast for a > > specific link. How these two tables are used is up to the operator to > > define. It does not seems to be something the draft must spell out. > So > I think this is out side the scope of the document. > > jin.lizhong:Firstly, we should describe the "best path" in more detail. The best path is what unicast gives us if you do a lookup for the root address. > The two selection methods are not compatiable and P2MP or MP2MP LSP > will > not be setup sucessfully if different methods are used in Root Node, > Transit > Node, and Leaf Node. What's more, if Root Node does not support > multicast > routing protocols and Leaf Node only support multicast routing lookup > method. Then the Leaf Node will not find the Root Node, for the Root > Node > is out of the sight of Multicast domains. I don't see what the problem is you are trying to solve. Why would you want to run a multicast routing protocol in the MPLS network to provide path to the root? Do you really consider DVMRP here? That is going backwards in time, just like proposing to use RIP. Normal best path procedures apply to unicast routing tables, like admin distance and metric. If you have different unicast tables it is up to the administrator to set which table has preference. Thx, Ice. > Secondly, we should specify the concept of "best path". Then we can > set a > priority to one table over the other, or we can only select one > selection > method. > > Thx, > > Ice. > > > > > > > > > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this mail > > > is solely property of the sender's organization. This mail communicati > > > on is confidential. Recipients named above are obligated to maintain se > > > crecy and are not permitted to disclose the contents of this communicat > > ion to others. > > > This email and any files transmitted with it are confidential and inten > > > ded solely for the use of the individual or entity to whom they are add > > > ressed. If you have received this email in error please notify the orig > > > inator of the message. Any views expressed in this message are those of > > the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti- > > Spam system. > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of > this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the originator of the message. Any views expressed in this message are > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > is solely property of the sender's organization. This mail communicati > on is confidential. Recipients named above are obligated to maintain se > crecy and are not permitted to disclose the contents of this communicat > ion to others. > This email and any files transmitted with it are confidential and inten > ded solely for the use of the individual or entity to whom they are add > ressed. If you have received this email in error please notify the orig > inator of the message. Any views expressed in this message are those of > the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti- > Spam system. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|