Re: LC comment on "considerations" inter-AS section

[Eric Rosen <erosen at cisco.com>]

> on whether or not you can avoid sending traffic uselessly [on S-PMSIs] in other 
> ASes : this is mentioned in section 9.2.3.6 of 
> draft-ietf-2547bis-mcast-bgp (the whole supersection is on I-PMSI route 
> processing, but the text in 9.2.3.6 would apply equally well to S-PMSIs, 
> possibly an improvement to bring there)

I thought the policy of the  "considerations" draft was to take account only
of  what is  written  in the  base  specs, not  of "possible  improvements".
Obviously this policy is not being applied in an even-handed manner.  

Even if  we grant that  9.2.3.6 could be  applied to S-PMSIs,  there doesn't
seem to be anything in the  existing specs that prevents an S-PMSI A-D route
from creating intra-AS segments connecting the ASBRs in all ASes of the VPN,
whether or not the multicast flow or flows bound to the PMSI are needed. 

The procedure of 9.2.3.6 allows an ASBR to dynamically create a set of <S,G>
filters for each P-tunnel, based  on the C-multicast routes that are passing
through  the  ASBR.  (This  seems  to  make  certain assumptions  about  the
deployment.)  Then these filters have to be applied to data packets arriving
on  that  P-tunnel.  Creating  LSP  tunnels  that  aren't needed,  and  then
applying IP-based filtering to the  MPLS packets traveling on those tunnels,
does not seem to me to be a particularly good scaling technique.  

But let me guess, S-PMSI scaling is out of scope, right? ;-)

> you brought up this point about P-tunnel aggregation and debate on the 
> associated scaling benefits, this is indeed an additional potential 
> argument for the segmented approach

Sure, just  explain how one does  it in practice,  and why it can't  also be
done with the non-segmented approach.

> some other questions you ask me are answered, or should be answered in 
> draft-ietf-2547bis-mcast and/or draft-ietf-2547bis-mcast-bgp

No doubt those issues are all out of scope ;-)