Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp section 13

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Wed, 11 Mar 2009 19:53:04 -0400

Hi Rahul,

thanks for the response.
See my comments in-line.

Maria

> 1. It is to be noted that the above scenario arises only when the
> receiver behind PE3 does not switch to SPT while the receiver behind
> PE2
> does. That is, the SPT threshold for the DR connected to the receiver
> behind PE2 is different from the SPT threshold for the DR connected to
> the receiver behind PE3. How realistic is this scenario?

This can easily happen when "Anycast RP with MSDP" is used in 
a VPN such that the (S,G) join is triggered not from the
last hop DR but from one of the Anycast RPs.

You don't want have a solution that does not work for valid C-PIM
scenarios.
So, I wanted to point this to you as, I thought, a valid input.

> 
> 2. Irrespective of how realistic this scenario, to address the above
> we will add to the spec the ability for PE4 to delay pruning itself
> off the C-S tree, once PE4 receives the withdraw of the C-Multicast
> source tree route for (C-S, C-G) that has been previousely advertised
> by PE2 (i.e. when the last source tree C-Multicast route goes away).
> The delay is controlled by a timer. The value of the timer must be
> configurable.

(btw, if the upstream PE (PE4) has locally connected CE(s) with
receiver(s) of (S,G), 
PE4 will only remove the P-tunnel interface from (S,G) state).

Dealing/setting such a timer in a large SP network is not going to be
trivial. This 
timer cannot be arbitrarily long because too many duplicates would be
generated and
some applications might not be able to handle it.
In addition, all (S,G) Prunes would have to be delayed from all upstream
PEs because 
the upstream PE cannot distinguish this scenario from others (e.g., when
all receivers 
have, in fact, pruned). This would cause unwanted traffic flowing in the
backbone 
for a longer time.

> The purpose of this timer is to ensure that PE1 does not prune (C-S,
> C-G) off the source tree (and therefore does not stop forwarding
> (C-S, C-G) onto the PMSI) until all PEs have had time to receive the
> withdraw of the Source Active A-D route for (C-S, C-G), and PE1
> starts forwarding of (C-S, C-G) on the RPT.

What would be the condition for Source Active route withdrawal? As this
condition
is currently stated in the draft, it will not work with this proposal.

It would be helpful if you could describe all the steps of this solution
from the 
moment the upstream PE receives (S,G) Join route withdrawal.

> 
> Note that before PE4 prunes C-S, there is a possibility to have
> (C-S, C-G) packets being sent at the same time on the PMSI by both
> PE1 and PE4. This would result in a transient unnecessary traffic
> on the provider backbone.  However, no duplicates will reach customer
> hosts subscribed to C-G as long as the downstream PEs apply procedures
> described in section 9.1 of [MVPN].

It seems to me that trying to avoid duplicates with single forwarder
election
(when BGP-signaling is used) is becoming complex and has side effects, 
and may not be worth solving ...

> 3. Can you please explain how this traffic loss which "will not be
> negligible" can be avoided when one uses the full per-MVPN PIM peering
> across a MI-PMSI procedures (ala draft-rosen).
> 
Are you saying that your implementation of draft-rosen has this problem
also?

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 12 Mar 2009 12:06:16 -0700

Hi Maria,

Please see inline:

<snipped>

(btw, if the upstream PE (PE4) has locally connected CE(s) with
receiver(s) of (S,G), PE4 will only remove the P-tunnel interface from
(S,G) state).

<RA> That is correct. Please see below for text that covers this.

Dealing/setting such a timer in a large SP network is not going to be
trivial. This timer cannot be arbitrarily long because too many duplicates
would be generated and some applications might not be able to handle it.

<RA> As mentioned below the CEs *do not* get the duplicates if the
downstream PEs apply procedures described in section 9.1 of [MVPN]. These
procedures enable egress PEs to discard packets from an unexpected UMH and
do not require single forwarder election. Hence the timer can indeed be
over-estimated.

In addition, all (S,G) Prunes would have to be delayed from all upstream
PEs because the upstream PE cannot distinguish this scenario from others
(e.g., when all receivers have, in fact, pruned).  This would cause unwanted
traffic flowing in the backbone for a longer time.

<RA> Can you please explain the above with an example?

<RA> Please see Yakov's email on the clarifying changes to the text
in section 13.1.

<RA> Here is the text to be added to section 11.3.1.1:

  "When, for a said VRF, the last Source Tree Join C-multicast route
   for (C-S, C-G) is withdrawn, resulting in the situation where
   the VRF contains no Source Tree Join C-multicast route for (C-S,
   C-G) the PE MUST remove the I-PMSI/S-PMSI from the outgoing
   interface list of the (C-S, C-G) state. Depending on the (C-S,
   C-G) state of the PE-CE interfaces, this may result in the PE
   using PIM procedures to prune itself off the (C-S, C-G) tree.
   If C-G is not in the SSM range for the VRF, then removing the
   I-PMSI/S-PMSI from the outgoing interface list of the (C-S, C-G)
   state SHOULD be done after a delay that is controlled by a timer.
   The value of the timer MUST be configurable.

   The purpose of this timer is to ensure that the PE does not stop
   forwarding (C-S, C-G) onto a PMSI tunnel until all the PEs of
   the same MVPN have had time to receive the withdrawal of the
   Source Active A-D route for (C-S, C-G) (see Section 13.1 "Source
   Within a Site - Source Active Advertisement"), and the PE connected
   to C-RP starts forwarding (C-S, C-G) on the C-RPT.

   Note that before the PE stops forwarding (C-S, C-G), there is a
   possibility to have (C-S, C-G) packets being sent at the same
   time on the PMSI by both the local PE and the PE connected to
   the site that contains C-RP. This would result in a transient
   unnecessary traffic on the provider backbone. However, no
   duplicates will reach customer hosts subscribed to C-G as long
   as the downstream PEs apply procedures described in section 9.1
   of [MVPN]."

<RA> Here is the text to be added to section 11.3.1.2:

   "When, for a said VRF, the last Shared Tree Join C-multicast
   route for (C-*, C-G) is withdrawn, resulting in the situation
   where the VRF contains no Shared Tree Join C-multicast route for
   (C-*, C-G) the PE MUST remove the I-PMSI/S-PMSI from
   the outgoing interface list of the (C-*, C-G) state. Depending
   on the (C-*, C-G) state of the PE-CE interfaces, this may result
   in the PE using PIM procedures to prune itself off the (C-*,
   C-G) tree."

It seems to me that trying to avoid duplicates with single forwarder
election (when BGP-signaling is used) is becoming complex and has side effects,
and may not be worth solving ...

<RA> I am not referring to single forwarder election. Section 9.1 of
[MVPN] describes discarding packets from the unexpected UMH,
irrespective of whether single forwarder election is used or not and that
is what I am referring to.

<RA> The question was about protocol procedures and not about
implementation. Since you consider the packet loss in the scenario you
described to be an issue, I am simply asking you how
do vanilla PIM procedures as per RFC 4601, which are also used in full per-MVPN
PIM peering across MI-PMSI (ala draft-rosen) avoid this traffic loss? If
they do, please explain the procedures. If they don't it will be useful to
understand why do you think it is not considered an issue in that case,
while you consider it to be an issue when c-multicast routes are exchanged
using BGP?

rahul

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 17 Mar 2009 12:46:56 -0400

Hi Rahul,

> <RA> Can you please explain the above with an example?

What I meant is that in PIM-SM (S,G) Prunes will always have to be
delayed on the upstream PEs, even if this scenario does not apply.

> is what I am referring to.

That is exactly what I meant, namely, that single forwarder election
(with BGP as signaling protocol) cannot resolve duplicates by itself but
always requires the "strong" RPF check (i.e., identifying the PE that
transmitted the packet). There are other side effects of single
forwarder election and BGP-signaling (I will send an example in a
separate e-mail).

Hence, the statement in section 9.1.2 of [MVPN]: 

"One difference in effect between this procedure and the procedure of
section 9.1.1 is that this procedure sends only one copy of each packet
to each egress PE, rather than sending multiple copies and forcing the
egress PE to discard all but one" 

is not true when BGP-signaling is used.

> <RA> Please see Yakov's email on the clarifying changes to the text

The new proposal for SA withdrawal is as follows:

   "Whenever as a result of receiving a withdrawal of the previousely
   advertise Source Tree Join C-multicast route for (C-S, C-G), the
   PE is going to remove the S-PMSI/I-PMSI from the outgoing interface
   list of the (C-S, C-G) state, the local PE MUST also withdraw
   the Source Active A-D route for (C-S, C-G), if such a route has
   been advertised."

What happens if "S" stops sending and (S,G) state is deleted on the
upstream PE before it receives a withdrawal of (S,G) Join route?
According to the condition as stated above, the SA A-D route for (S,G)
will not be withdrawn.

> PIM peering across MI-PMSI (ala draft-rosen) avoid this traffic loss?

There are no such blackholes/traffic loss when using PIM. This is
described in RFC 4601 (specifically, in the section on (S,G) Assert).
 
> If
> they do, please explain the procedures. 

The procedure is described in section 4.6.1 "(S,G) Assert State Machine"
in RFC 4601. 

>If they don't it will be useful
> to

Well, it does not happen in PIM.