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

[Paul Francis <francis at mpi-sws.org>]

I just want to make sure that folks understand what Xiaohu said here.

The original VA draft suggested that FIB suppression take place between 
the routing table and the FIB.  (i.e., entries in the routing table would 
not be loaded into the FIB).

Rajiv Asati had suggested way back in Dublin that it would be simpler if 
suppression take place between the RIB and the routing table, so we 
modified the second draft to read this way.

John points out, however, that this messes up PIM, which is true.

So, we propose going back to the original draft.  In this way, the RIB 
goes unchanged from what it would be without VA, so PIM runs as normal. 

PF





From:
Xu Xiaohu <xuxh at huawei.com>
To:
grow at ietf.org
Date:
08/14/2009 10:10 AM
Subject:
[GROW] fwd:  draft-ietf-grow-va-00 and multicast
Sent by:
grow-bounces at ietf.org



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

_______________________________________________
GROW mailing list
GROW at ietf.org
https://www.ietf.org/mailman/listinfo/grow