Hi, If somebody has the same doubt about how to run PIM and VA together as John mentioned, please see the following email.
Any comment is appreciated. Xiaohu > -----邮件原件----- > 发件人: Xu Xiaohu [mailto:[email protected]] > 发送时间: 2009年8月12日 11:56 > 收件人: 'Xu Xiaohu' > 主题: 转发: [GROW] draft-ietf-grow-va-00 and multicast > > > > -----邮件原件----- > 发件人: Xu Xiaohu [mailto:[email protected]] > 发送时间: 2009年8月11日 16:43 > 收件人: 'John G. Scudder'; 'Paul Francis'; '[email protected]'; > '[email protected]'; '[email protected] Raszuk'; 'Lixia Zhang' > 主题: 答复: [GROW] draft-ietf-grow-va-00 and multicast > > Hi John, > > Let me try to answer your question. First, your observation is correct. In > the current VA specification, it's hard to support multicast. > > In the initial design of VA, we only shrink the FIB size, while keeping the > routing table (on control plane) as normal. In this way, the RPF interface > and RPF neighbor can be determined according to the routing table. That's to > say, once the PIM module determines the RPF interface for a given (*,G) or > (S,G), the RPF interface information will be installed as a field into the > mFIB entry, so the RPF checking during multicast forwarding is only > dependent on the mFIB, rather than the unicast FIB. Once the upstream > neighbor is determined according to the routing table, the PIM control > messages will be forwarded to the correct upstream neighbor. In a word, PIM > can work as normal as if there is no VA deployed. > > However, this situation was changed in the latter version. See the following > statement quoted from Section 1.4.1.3. Revisions from 00 version, " ...FIB > suppression can be achieved by not loading entries into the Routing Table, > as suggested by Rajiv Asati in email...". > > Taking the multicast capability into account, I think we should restore the > FIB reduction mechanism to the original design. > > Any comment? > > Xiaohu > > > -----邮件原件----- > > 发件人: John G. Scudder [mailto:[email protected]] > > 发送时间: 2009年8月11日 7:38 > > 收件人: Paul Francis; [email protected]; [email protected]; > > [email protected]; [email protected] Raszuk; Lixia Zhang > > 主题: Fwd: [GROW] draft-ietf-grow-va-00 and multicast > > > > Authors, > > > > Looks like the dr...@tools alias didn't work right, so I'm re-sending > > to your individual addresses. I didn't re-cc the GROW mailing list > > but you may want to do so on replies. > > > > --John > > > > Begin forwarded message: > > > > > From: John Scudder <[email protected]> > > > Date: August 10, 2009 2:49:51 PM GMT-04:00 > > > To: "[email protected]" > > <[email protected] > > > > > > > Cc: "[email protected]" <[email protected]> > > > Subject: [GROW] draft-ietf-grow-va-00 and multicast > > > > > > Draft-ietf-grow-va authors, > > > > > > In looking over the draft, it's not clear how multicast would work. > > > For example, in the case discussed in 3.2.3, how would the border VA > > > router perform an RPF check on multicast traffic received from an > > > adjacent AS if the VA router doesn't have a route to the source of the > > > traffic (other than some flavor of default which is pointing down a > > > tunnel in the wrong direction)? > > > > > > Similarly, in the case where traffic from a border router goes to an > > > APR and then back to the same border router, how does PIM work? It > > > would appear that in this case the incoming and outgoing interfaces > > > used by PIM could be the same. More generally, have you thought > > > through how PIM works in the VA world, period? Seems like questions > > > to be looked at include how PIM messages flow (tunneled, native), how > > > multicast data traffic flows, and so on. Perhaps there are simple > > > answers to these but they weren't evident to me. > > > > > > Thanks, > > > > > > --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
