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

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 4 Dec 2008 10:04:48 -0500

Section 13.2.1. describes how to prune C-Source traffic from the shared
tree using a timer, and it says:
"The purpose of this timer is to ensure that C-S is not pruned off the
shared tree until all PEs have had time to receive the Source Active A-D
route for <C-S, C-G>."

Using this timer, how it can be assured that all PEs had received and
processed the Source Active A-D BGP update without generating
potentially excessive number of duplicates? 

Maria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Danny McPherson
> Sent: Friday, November 21, 2008 8:52 AM
> To: [email-masked]
> Subject: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> 
> 
> Please consider today the start of a 2-week last call
> for draft-ietf-l3vpn-2547bis-mcast-bgp, available here:
> 
> http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp-05
> 
> Input on this draft's suitability for publication as an
> Internet Standards Track document is solicited, feedback
> ends December 9, 2008.
> 
> Thanks in advance for your feedback!
> 
> Danny & Marshall

---

From: Thomas Morin <[email-masked]>
Date: Tue, 09 Dec 2008 13:36:52 +0100

Hello,

Current specs allow a behavior where a PE does not advertise an I-PMSI
tunnel, and will only use S-PMSIs for the traffic. In that case, the PE
can choose to only instantiate an S-PMSI and a tunnel after the
reception of a C-multicast route.  

But there is a slight inconvenience : the downstream PEs don't have any
way to tell that an upstream PEs will behave in that way. Nothing
breaks, but it makes it harder to have smooth feedback on the CLI and
troubleshooting.

Here is a proposal : let's decide that when a PE will use such a
"delayed/S-PMSI only" approach, it still MUST advertise an I-PMSI A-D
route, with a PMSI Tunnel Attribute of type "No tunnel information
present" and a new flag "only delayed S-PMSI" set to 1.  On reception of
such a route, the "protocol behavior" of a downstream PEs is not
changed, except that it can do a best job at reporting issues to the
operator: if a PE has multicast state for which the UMH is a PE which
not advertise an I-PMSI with a real tunnel, and doesn't has this flag
set, this can be identified by the downstream PE as an error case.

I would thus suggest the following addition to section 5 of -bgp:
* add a flag S to the Flags field, "Only delayed S-PMSI"
* add the following text to the paragraph related to the "no tunnel
information present" type:
  This type MUST be used when the local policy on a PE is to not
  instantiate any I-PMSI tunnel for a VRF, and only use S-PMSI for which
  the instantiation may possibly be delayed until a C-multicast route is
  imported in that VRF. In that case, the "Only delayed S-PMSI" flag
  (S) MUST be set. 

(maybe the text above would be better placed ni 9.1.1 of -bgp)

Moreover, when preparing the above text, it occurred to me that section
9.1.1 of -bgp and section 6.1.1 or arch says imply that the PMSI tunnel
attribute can possibly be omitted : I think we should exclude that case
where an impose that the PMSI tunnel attribute is *always*present*, but
possibly set to a type of "no tunnel information".

Thank you,

-Thomas

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 12 Dec 2008 16:17:29 -0500

PIM-SM/RFC 4601 permits, quote, "a receiver to join a group and specify
that it only wants to receive traffic for a group if that traffic comes
from a particular source. If a receiver does this, and no other receiver
on the LAN requires all the traffic for the group, then the DR may omit
performing a (*,G) join to set up the shared tree, and instead issue a
source-specific (S,G) join only."

Such behavior of end systems in PIM-SM means that a PE can receive Join
(C-S, C-G) even for sources that are not active. 

Section 13.1 of draft-ietf-l3vpn-2547bis-mcast-bgp-05 requires that
"whenever a PE creates an <C-S,C-G> state as a result of receiving a
Source Tree Join C-multicast route for <C-S, C-G> from some other PE,
the PE that creates the state MUST originate a Source Active A-D route."

The procedure as described in section 13.1 might lead to useless S-PMSI
creation for C-sources operating in sparse groups which are not active.
This procedure should be enhanced to prevent triggering of S-PMSIs in
such cases.

Maria

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 13 Dec 2008 18:51:21 -0800

Maria,

> This procedure should be enhanced to prevent triggering of S-PMSIs in

Could you please provide an example of how "the procedures as described
in section 13.1 might lead to useless S-PMSI creation for C-sources
operating in sparse groups which are not active".

Yakov.

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 14 Dec 2008 08:32:32 -0500

Dear Maria;

> This procedure should be enhanced to prevent triggering of S-PMSIs in

Might there be situations where receivers want to set up a multicast  
route for
source regardless of whether the source is currently active, to reduce
the time for source data to propagate ? So in that case this would be  
legitimate.

Otherwise, joins to sources that are not active will generally stop.  
Or are you worried about
DOS attacks ?

Regards
Marshall

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Sun, 14 Dec 2008 20:59:18 -0500

Hi Marshall,

> Otherwise, joins to sources that are not active will generally stop.

Yes, I think that triggering Source Active A-D routes when receiving
(S,G) Joins without the knowledge that S is actually "active" creates a
security issue.  A single end-user PC can generate a lot of spurious
IGMP (S,G) joins that could trigger lots of BGP updates and potentially
useless S-PMSIs in VPN core.

Maria

> From: Marshall Eubanks [mailto:[email-masked]]
> Sent: Sunday, December 14, 2008 8:33 AM
> To: NAPIERALA, MARIA H, ATTLABS
> Cc: Danny McPherson; [email-masked]
> Subject: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> 
> Dear Maria;
>

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Sun, 14 Dec 2008 21:00:06 -0500

Yakov,

> operating in sparse groups which are not active".

Section 13.1 states: "Whenever a PE creates an <C-S,C-G> state as a
result of receiving a Source Tree Join C-multicast route for <C-S, C-G>
from some other PE, the PE that creates the state MUST originate a
Source Active A-D route."

And section 13.2 states: " When [...] a PE creates in one of its
MVPN-TIBs a (new) <C-*, C-G> entry with a non-empty outgoing interface
list that contains one or more PE-CE interfaces, the PE [...] sets up
its forwarding path to receive (C-S, C-G) traffic from the tunnel the
originator of the selected Source Active A-D route uses for sending
(C-S, C-G)."

The tunnels for (C-S, C-G) traffic could be, for example,
algorithmically derived or pre-provisioned. 
In general, I don't think it is a good idea to trigger Source Active A-D
routes without the knowledge that S is "active".

Maria

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Saturday, December 13, 2008 9:51 PM

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Sun, 14 Dec 2008 21:08:25 -0500

Comments on section 14:

- section 14.1 states "When a PE that previously advertised a Source
Active A-D route for a given (multicast) source learns that the source
is no longer active (the PE learns this by using the same mechanism by
which the PE learned that the source was active), the PE SHOULD withdraw
the previously advertised Source Active route."

How exactly a PE which is a C-RP, for example, decides that that a
source is not longer active, so that it can withdraw the previously
advertised Source Active route?  I think this should be specified since
PE being a C-RP differs from plain IP multicast context.

-  section 14.2 states "A PE MUST withdraw a Source Tree Join
C-multicast route for (C-S, C-G) if, as a result of having received PIM
messages from one of its CEs, the PE creates a Prune <C-S, C-G, RPT-bit>
upstream state in one of its MVPN-TIBs, but has no <C-S, C-G> Joined
state in that MVPN-TIB, and had previously advertised the said route."

The PE should also prune itself or be pruned from the tunnel it joined
to receive <C-S, C-G> traffic (if this tunnel is not bound to any other
traffic). This is also applicable to section 13.

- I think that a description should be added to section 14 on how a PE
handles <C-*, C-G> Prune messages received from locally attached CEs.

Maria

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 14 Dec 2008 18:21:49 -0800

Maria,

> originator of the selected Source Active A-D route uses for sending

What all of this has to do with S-PMSI creation ? In other words,
how does all of this support your claim that "the procedures
as described in section 13.1 might lead to useless S-PMSI creation
for C-sources operating in sparse groups which are not active" ?

> algorithmically derived or pre-provisioned. 

Could you please point me to the place in the spec that talks about
"algorithmically derived" tunnels.

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Sun, 14 Dec 2008 21:36:03 -0500

Yakov,

> "algorithmically derived" tunnels.

There is no place in the spec that would prevent it either. This could
be a desirable capability. 

Maria

> > > > that it only wants to receive traffic for a group if that
traffic
> > > comes
> > > > on the LAN requires all the traffic for the group, then the DR
> may
> > > omit
> > > > performing a (*,G) join to set up the shared tree, and instead
> issue
> > > a
> > > > Such behavior of end systems in PIM-SM means that a PE can
> receive
> > > Join
> > > > Source Tree Join C-multicast route for <C-S, C-G> from some
other
> > PE,
> > > > The procedure as described in section 13.1 might lead to useless
> S-
> > > PMSI
> > > > This procedure should be enhanced to prevent triggering of S-
> PMSIs
> > in
> > > > such cases.
> > >

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 14 Dec 2008 18:35:51 -0800

Maria,

> PE being a C-RP differs from plain IP multicast context.

The text from 14.1 you quoted above clearly states that a PE
learns that the source is no longer active "by using the same
mechanism by which the PE learned that the source was active".

And the first paragraph in 14.1 describes possible mechanisms
by which a PE can learn that a source is active:

   A PE can obtain information about active multicast sources within a
   given MVPN in a variety of ways. One way is for the PE to act as a
   fully functional customer RP (C-RP) for that MVPN. Another way is to
   use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information
   about active multicast sources from one or more of the MVPN C-RPs to
   the PE. Yet another way is to use MSDP [MSDP] to convey information
   about active multicast sources from the MVPN C-RPs to the PE.

So, the current text is sufficient.

> traffic). This is also applicable to section 13.

We will add some text to cover this.
> handles <C-*, C-G> Prune messages received from locally attached CEs.

We will add some text to cover this.

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Sun, 14 Dec 2008 23:46:59 -0500

Yakov,

Regarding

> mechanism by which the PE learned that the source was active".

I understand it. What you mean I assume is that if C-RP-PE, for example,
learned about the source via receiving Register message, it will know
that the source is no more active by not receiving Register messages.
However, the point I was trying to make when comparing C-RP-PE to plain
ASM RP was a little different and it might not have been clear:
Assume that some sources (C-S, C-G) are constantly active but they have
no receivers in MVPN (these could be some illegitimate or misconfigured
sources/end-user PCs that can be active for long periods of time, and
there could many of them). In plain ASM multicast in such cases, the RP
would keep sending Stop-Registers, the first-hop router would keep
sending Registers, and nothing else happens. In MVPN case according to
section 14, the C-RP-PE would also keep sending Stop-Registers. However,
in addition to this, the C-RP-PE will initiate for each such source a
Source Active A-D route in the MVPN. These Source Active A-D routes
might not get withdrawn for very long periods of time. So, it would be
very desirable for the C-RP-PE to announce only those C-flows that have
interested receivers.

Maria

---

From: Thomas Morin <[email-masked]>
Date: Mon, 15 Dec 2008 11:51:24 +0100

Hi Maria,

NAPIERALA, MARIA H, ATTLABS :
> security issue. 

I don't agree with your formulation. Let's suppose that there is a
security issue due to spurious state being created because of an
inactive source "mistaken" as active.  Let's suppose we try to solve the
issue by avoiding inactive sources to create these states.  The
"attacker" on the customer side can still create the same states by
making the right number of source active.

> A single end-user PC can generate a lot of spurious

Well, I'm lost here : since when do IGMP S,G joins create S-PMSI
routes ?  

It is true that IGMP activity (and PIM) on the customer side will create
state on the PEs, and that this has to be controlled in some kind of
way, but this is not specific to BGP, nor related to S-A A-D routes or
S-PMSI routes...

Now, if we take a broader perspective, I agree that we must ensure that
there are safeguards to avoid that customers could creates an unbounded
amount of states in the PEs (and RRs) :
- it applies to state in the PEs that is created directly based on state
on the PE-CE interfaces : (S,G) and (*,G) joins
  * we need safeguards to avoid too much states created on PEs based on
customer PIM activity 
  * it implies having the operator configure upper bounds on the amount
of multicast states in the VRFs
  * this is true independently of the protocol used for C-multicast
routing
- it also applies to states created "indirecly" based on customer
activit: Source-Active and S-PMSI A-D routes
  * we need safeguards to cover these
  * S-PMSI routes are created based on (a) customer activity and (b) PE
policy defined by the operator   --> there is a need to bound the
amount, and frequency of changes, of S-PMSI state   (this critical to
protect P routers, and is true independently of the protocol used to
signal S-PMSIs)
  * S-A A-D routes are also created based on customer activity:
      -> in the context of section 13, they are only created based on
Source Tree Join routes, so if these are properly bounded, it should be
fine  
      -> in the context of section 14, they are created based on RP
activity, or PIM registers, or MSDP : bounds would typically also setup
here
      -> if we want more solive boundaries, it seems to me that it makes
sense to suggest that implementation should provide a way to set an
upper bound to the number of S-A A-D routes that can be advertised from
a VRF

Cheers,

-Thomas

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 15 Dec 2008 08:54:31 -0500

Comments on section 13.2:

  "When as a result of receiving a new Source Active A-D route a PE
   updates its VRF with the route, the PE MUST check if the newly
   received route matches any <C-*, C-G> entries. If (a) there is a
   matching entry, (b) the PE does not have (C-S, C-G) state in its
   MVPN-TIB for (C-S, C-G) carried in the route, and (c) the received
   route is selected as the best(using the BGP route selection
   procedures), then the PE sets up its forwarding path to receive (C-S,
   C-G) traffic from the tunnel the originator of the selected Source
   Active A-D route uses for sending (C-S, C-G)."

The condition (b) above excludes the following case: a PE that received
a Source Active A-D route for (C-S,C-G) has both (C-*, C-G) and (C-S,
C-G) states in its MVPN-TIB (because its locally attached site switched
to SPT for C-S). If this PE does not join the tunnel used for C-S
traffic, this PE will not receive the C-S traffic.

Also, the section 13.2 has no procedure for the case when a PE that
received a Source Active A-D route for (C-S,C-G) has the (C-S,C-G) state
but not the (C-*, C-G) state in its MVPN-FIB. This could be the case,
for example, when the PE is attached to (a site with) C-RP but it is not
directly attached to any (C-*, C-G) receiver sites, except those behind
the C-RP. This PE will also have to join the tunnel used for C-S traffic
to deliver traffic to those receivers.

Maria

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 15 Dec 2008 10:02:58 -0500

> useless S-PMSIs in VPN core.

This is of course true for normal (non L3VPN) multicasts, and has  
largely been dealt with
by a combination of filtering and rate limiting - see, e.g.,

http://www.juniper.net/solutions/literature/app_note/350051.pdf

I would think that the VPN situation would be even easier to control  
(it should be easier to
determine what is and isn't authorized, for example).

Are you saying that you have seen these kinds of DOS attacks in  
practice, or are
you just worried about the principle ?

Wearing no hats of any kind;
Marshall

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 15 Dec 2008 14:25:29 -0500

Hi Marshall,

> by a combination of filtering and rate limiting 

In MVPN we are dealing with very large scale and very dynamic
environment, with multiple MVPNs provisioned on the same PE. We have to
be generous with multicast route volume (their number and frequency)
because such are customers' needs. We implemented all possible
protection knobs that were reasonable to customers and to us as a
Service Provider to be able to deal with large volume of MVPNs and their
size. 

My point about announcing Active Source BGP routes when source is not
active is that it makes MVPN vulnerable to misconfigured or malicious
end-users/PCs. Specifically, a multicast (C-S, C-G) BGP route is sent
only to a specific upstream PE while Active Source BGP routes are sent
to all PEs (in a given VPN) and for each (C-S, C-G) BGP route there is a
corresponding Active Source route. If there is an end-user/PC which is
misconfigured or even malicious, it can generate lots of invalid IGMP
(S,G) joins which will be translated to Active Source A-D routes and
replicated on every MVPN PE. All those Active Source routes would be
useless but will take up BGP resources. In addition, there is no
requirement (and it shouldn't be) in the spec that only MI-PMSIs are
used for C-S traffic but that also S-PMSIs can be used. The S-PMSIs
could be, e.g., pre-provisioned in mVRFs. For example, mVRF
configuration could specify per root PE and per C-G an S-PMSI used for
sending traffic from all C-S's of C-G attached to the root PE. All those
tunnels would be useless but will take up VPN core transport resources.

> determine what is and isn't authorized, for example).

There is really no way to control what multicast routes we receive in
MVPN context and even MVPN customers tell us that they can't fully
control it. What we see is that multicast routing in VPN is a completely
different than unicast routing, i.e., we have to deal with end-user
activity and not just with router activity. 
I believe that MVPN technology should, if anything, make MVPN "tighter"
that is less and not more exposed to such spurious multicast events. 
According to BGP spec, each (C-S,C-G) PIM route might have tree
different BGP versions: Source Tree Join route, Source Active A-D route,
and possibly S-PMSI A-D route ...

> practice

Yes. We saw large number of spurious sources. It was due to customer's
misconfiguration of a large MVPN.

Maria

S-

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Dec 2008 13:49:24 -0800

Maria,

> to deliver traffic to those receivers.

In the case where (C-S, C-G) is carried over an S-PMSI text in 12.3
already covers this:

                             the PE MUST set up its forwarding path
   to receive (C-S, C-G) traffic from the tunnel advertised  by the S-
   PMSI A-D route (the PE MUST switch to the S-PMSI).

In the case where (C-S, C-G) is carried over an I-PMSI, we'll
add the text to cover this.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Dec 2008 14:34:34 -0800

Maria,

> useless but will take up BGP resources. 

See the e-mail from Thomas Morin on this topic that he sent today
(I attached it).

>                                         In addition, there is no
> could be, e.g., pre-provisioned in mVRFs. 

Your claim that "S-PMSIs could be .. "pre-provisioned" is incorrect, as
*by definition* S-PMSIs are not pre-provisioned, but are established
dynamically. 

> tunnels would be useless but will take up VPN core transport resources.

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.
In fact 7.2 of draft-ietf-l3vpn-2547bis-mcast-07.txt is very explicit
about this:

                  If a particular stream has a significant amount of
   traffic, it may be beneficial to move it to an S-PMSI that includes
   only those PEs that are transmitters and/or receivers (or at least
   includes fewer PEs that are neither).

> 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.

> misconfiguration of a large MVPN.

See the e-mail from Thomas Morin on this topic that he sent today
(I attached it).

Yakov.
-------------------------------------------------------------
Date:    Mon, 15 Dec 2008 11:51:24 +0100
To:      "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
cc:      [email-masked], Danny McPherson <[email-masked]>
From:    Thomas Morin <[email-masked]>
Subject: RE: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

Hi Maria,

Cheers,

-Thomas

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Dec 2008 16:46:41 -0800

Maria,

[small correction to my previous reply...]

> to deliver traffic to those receivers.

The current spec allows (C-S, C-G) to be carried either on I-PMSI or S-PMSI. 

When (C-S, C-G) is carried on I-PMSI the PE joins the tunnel(s) used by
I-PMSI at provisioning time, and therefore does not need to join
any I-PMSI tunnel(s) when it receives a Source Active A-D route.

When (C-S, C-G) is carried over an S-PMSI text in 12.3 covers the issue
of joining the tunnel.

So, the current spec already addresses your comment wrt joining
the tunnel.

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 15 Dec 2008 22:50:46 -0500

Yakov,

what functionality does the following paragraph in section 13.2
introduces beyond what is already covered in section 12.3:

"When as a result of receiving a new Source Active A-D route a PE
updates its VRF with the route, the PE MUST check if the newly received
route matches any <C-*, C-G> entries. If (a) there is a matching entry,
(b) the PE does not have (C-S, C-G) state in its MVPN-TIB for (C-S, C-G)
carried in the route, and (c) the received route is selected as the
best(using the BGP route selection procedures), then the PE sets up its
forwarding path to receive (C-S,C-G) traffic from the tunnel the
originator of the selected Source Active A-D route uses for sending
(C-S, C-G)."

Maria

> Sent: Monday, December 15, 2008 7:47 PM
> The current spec allows (C-S, C-G) to be carried either on I-PMSI or
S-
> PMSI.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 16 Dec 2008 10:34:37 -0500

Yakov,

> 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. 

> > different BGP versions:, Source Active A-D
> 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

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 16 Dec 2008 07:56:32 -0800

Maria,

> C-flows to P-tunnels instead of advertising a S-PMSI together with the

It is perfectly valid to advertise both a Source Active A-D route
and an S-PMSI A-D in the same BGP message.
  
> concern to service provider with any meaningful MVPN deployment.  

To respond to your point about originating Source Active A-D route
for C-S flows that are not active please consider the following.

According to the procedures in section 13 Source Active A-D routes
are originated *only* in response to Source Tree Join C-multicast
routes, and withdrawn in response to withdraw of Source Tree Join
C-multicast routes.

A PE originates Source Tree Join C-multicast route for a given <C-S,
C-G> only after it receives PIM Join (C-S, C-G) from a CE, and
withdraws Source Tree Join C-multicast route when it receives PIM
Prune (C-S, C-G) from a CE.

With PIM-SM in ASM mode originating PIM Join (C-S, C-G) requires
(C-S,C-G) to be active.

Therefore, the procedures in section 13 result in origination of
Source Active A-D routes *only* for the sources that are active.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 16 Dec 2008 08:00:10 -0800

Maria,

> originator of the selected Source Active A-D route uses for sending

Titles of 12.3 and 13.2 provide an answer to your question.

Yakov.