[GROW] fwd: draft-ietf-grow-va-00 and multicast

[Xu Xiaohu <xuxh at huawei.com>]

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:xuxh at huawei.com]
> 发送时间: 2009年8月12日 11:56
> 收件人: 'Xu Xiaohu'
> 主题: 转发: [GROW] draft-ietf-grow-va-00 and multicast
> 
> 
> 
> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:xuxh at huawei.com]
> 发送时间: 2009年8月11日 16:43
> 收件人: 'John G. Scudder'; 'Paul Francis'; 'hitesh at cs.cornell.edu';
> 'jenster at cs.ucla.edu'; 'robert at raszuk.net 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:jgs at juniper.net]
> > 发送时间: 2009年8月11日 7:38
> > 收件人: Paul Francis; xuxh at huawei.com; hitesh at cs.cornell.edu;
> > jenster at cs.ucla.edu; robert at raszuk.net Raszuk; Lixia Zhang
> > 主题: Fwd: [GROW] draft-ietf-grow-va-00 and multicast
> >
> > Authors,
> >
> > Looks like the draft at 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 <jgs at juniper.net>
> > > Date: August 10, 2009 2:49:51 PM GMT-04:00
> > > To: "draft-ietf-grow-va-00 at tools.ietf.org"
> > <draft-ietf-grow-va-00 at tools.ietf.org
> > > >
> > > Cc: "grow at ietf.org" <grow at ietf.org>
> > > 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