RE: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

["NAPIERALA, MARIA H, ATTLABS" <[e-mail]>]

Yakov,

> To avoid useless S-PMSI tunnels one could require that S-PMSIs be
> created only when there is traffic to be carried over these S-PMSIs.

This is at the cost of requiring additional signaling to bind the
C-flows to P-tunnels instead of advertising a S-PMSI together with the
source active message. 

> > According to BGP spec, each (C-S,C-G) PIM route might have tree
> > different BGP versions:, Source Active A-D
> route,
> > and possibly S-PMSI A-D route ...
> 
> That is incorrect - each (C-S, C-G) PIM route have just *one* version,
> namely Source Tree Join C-multicast route.

I used the word "version" as a figure of speech... I meant that every
(C-S,C-G) PIM-SM Join triggers additional BGP routes.
Specifically, as described in section 13 of BGP spec, every PIM-SM
Source Tree Join C-multicast route triggers a Source Active A-D route
that has to be maintained on every MVPN PE. In addition, if S-PMSIs are
used for carrying C-S traffic then for every PIM-SM Source Tree Join
C-multicast route there is a S-PMSI A-D route also maintained on every
MVPN PE. And those updates could be quite dynamic.
For example, if there 1000 (C-S,C-G) mroutes in a MVPN, the procedures
in section 13 will generate, besides 1000 Source Tree Join C-multicast
routes, 1000 Source Active A-D routes, and 1000 S-PMSI A-D routes. And
latter two type of updates have to be stored on every PE with the given
MVPN. This is a lot of overhead. Even if those "C-S" flows are not
active (and this could be due misconfiguration or it could be malicious)
the procedures in section 13 will still generate Source Active A-D
routes. As I pointed out before, those updates (and there can be 1000's
of them, especially if it is the malicious) are useless yet they will
use common BGP RR resources. I am surprised that it wouldn't be a
concern to service provider with any meaningful MVPN deployment.  

Maria