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

From: Yakov Rekhter <[email-masked]>
Date: Wed, 1 Apr 2009 07:58:26 -0700

Maria,
 
>>> It seems to me that trying to avoid duplicates with single forwarder
>>> election (when BGP-signaling is used) is becoming complex and has  
>>> side, 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.
>>
>> 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).
 
Your claim is incorrect wrt steady state, as in a steady state
single forwarder election with BGP as a signaling protocol does
eliminate/resolve duplicates by itself. 

Without the ability to discard packets from the unexpected UMH,
(without what you call "the strong RPF check") duplicates may exist
during transients (e.g., RPT to SPT switchover), but such duplicates
may exist with PIM as a signaling protocol as well. And as mentioned
above, with this ability (with "the strong RPF check") such duplicates 
will be suppressed with BGP as the C-multicast signaling protocol.
 
>> 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.
 
Your claim is incorrect, and here is why. Let's look at the whole 
section 9.1.2 of [MVPN] (not just the paragraph you quoted above):
 
 9.1.2. Single Forwarder Selection
 
  Section 5.1 specifies a procedure for choosing a "default upstream PE
  selection", such that (except during routing transients) all PEs will
  choose the same default upstream PE.  To ensure that duplicate
  packets are not sent through the backbone (except during routing
  transients), an ingress PE does not forward to the backbone any
  (C-S,C-G) multicast data packet it receives from a CE, unless the PE
  is the default upstream PE selection.
 
  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.
 
>From the text above it should be (abundantly) clear that section
9.1.2 talks about a steady state, *not* about transients, and in a
steady state single forwarder election with BGP as a signaling
protocol does eliminate duplicates by itself.
 
>>> <RA> Please see Yakov's email on the clarifying changes to the text
>>> in section 13.1.
>>
>> 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.
 
How about the following modified text:
 
   "Whenever the PE deletes the (C-S, C-G) state, or whenever the
    PE, as a result of receiving a withdrawal of the previousely
    advertise Source Tree Join C-multicast route for (C-S, C-G),
    is going to remove the S-PMSI/I-PMSI from the outgoing interface
    list of the (C-S, C-G) state, the PE MUST also withdraw the
    Source Active A-D route for (C-S, C-G), if such a route has
    been advertised by the PE."

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 2 Apr 2009 11:45:20 -0400

Yakov,

> will be suppressed with BGP as the C-multicast signaling protocol.

In a *transient* state only few duplicates are generated, which is
generally acceptable to multicast applications. 
The multicast scenario and how it is handled by BGP-multicast, which I
described, is not a case of a *transient* state. Let me explain:
The BGP implementation of the scenario forces SPT-to-RPT switchover
which is quite different from the familiar RPT-to-SPT switchover. I
believe that such a switchover should be avoided in the first place. In
fact, such SPT-to-RPT switchover does not happen in PIM because (as
defined in RFC4601) all receivers will stay on SPT as long as the source
is active. 
As Rahul described in his e-mail (and I agree with it), the only
solution to avoid packet loss is to delay sending (S,G) Prune towards
the source "S". The delay of this Prune will have to be long enough to
give time for the (*,G) Join to be delivered to C-RP:
-First, this delay has to be long enough for Source-Active A-D route to
be withdrawn and for egress PEs to change their forwarding to receive
"S" traffic on RPT. This might take seconds, especially if multiple RRs
are in the path, which itself poses a question whether the amount of
duplicates will be acceptable. 
-But more importantly this delay cannot be just in seconds but should
last several minutes. PIM allows for, at least, 210 sec (3.5 min) for an
interface to time out, taking into account that some Join(s) might not
be delivered. The switchback to RPT should allow similar amount of time
before pruning (S,G) since the (*,G) Join that performs the switchback
to RPT is being send to customer's network over which SP has no control,
and there is no guarantee that the 1st (*,G) Join will be delivered.
Since the source "S" can be active and there are active listeners, its
flow cannot be interrupted. The reliance on discarding duplicates in
this case is necessary (as Rahul correctly stated). 
Hence, it is quite clear that multicast forwarding with BGP-signaling
requires "strong" or "UMH-based" RPF check.

> >> BGP-signaling (I will send an example in a separate e-mail).

The other side effect of single forwarder election and BGP-signaling is
that it might trigger different trees than VPN customer expects. Here is
one example:
                                 
                 		                 RP---R3
                                         |
                                         |
                       R1---PE1-- ... --PE2---\
                                  ...          S
                       R2---PE4-- ... --PE3---/

Source "S" is dually connected to PE2 and PE3. 
Assume that PE2's, PE1's, and PE4's best path to "S" is via PE2.

-RP sends (S,G) Join to PE2 and PE2 sends Join directly to "S" 
-R1, R2, R3 send (*,G) Joins towards RP 
-R1, R2, R3 switch to SPT and single forwarder election chooses PE3 as
the upstream PE

Hence, SPT will be as follows:

			  S
			/   \
      R3---RP---PE2--PE3---PE4---R2
			    |	
			   PE1
			    |
			    R1

while VPN customer expected SPT not to include S--PE3 path, as follows:
		
				S          
                        |                
             R3---RP---PE2---PE4---R2	 
			      |
                       PE1 
			      |
			      R1
			
This is an issue because VPN customers expect multicast to follow VRF
routing policy.
  
When PIM is used as a signaling protocol the SPT will be as expected
because there will be no (S,G) Joins send to PE3 and thus there will be
no Asserts.

> packet

As I explained above the switching from SPT to RPT using BGP-signaling
would not generate *merely* a transient state.

>     been advertised by the PE."

This means that an upstream PE may have (S,G) Join route(s) but no (S,G)
PIM state. Doesn't this imply an inconsistency between PIM and BGP since
the (S,G) Join route (quote from [BGP-MVPN]) "'correspond' to the PIM
(S,G) state"?

Maria

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 6 Apr 2009 13:57:51 -0700

Maria,

> defined in RFC4601) all receivers will stay on SPT as long as the source
 
First of all, you are contradicting your own requirements. This is
because on one hand you say above that SPT-to-RPT should be avoided
"as long as the source is active", which means that it should be
avoided irrespective of whether there are any receivers that switch
to SPT.  Yet on another hand you require MVPN "not trigger unexpected
(C-S, C-G) states in customer's network" (see Section 5 of your
draft draft-mnapierala-mvpn-part-reqt-02.txt).  If indeed SPT-to-RPT
switchover is to be avoided, even if there are no more receivers
that switch to SPT, then this may result in a situation where the
MVPN customer network will have an unexpected (C-S, C-G) state.

Second, please consider the following example:

     C-RP   C-S
      |      |
     CE1    CE2
      |      |
     PE1     PE2

     PE3     PE4
      |      |
     CE3    CE4
      |      |
     Rcv1   Rcv2

Assume that initially DRs connected to both Rcv1 and Rcv2 join RPT
(by sending Join(C-*, C-G) towards C-RP). When the DR connected to
Rcv1 receives the first (C-S, C-G) packet, the DR switches to SPT
(by sending Join(C-S, C-G) towards C-S). However, the DR connected
to Rcv2 stays on RPT (and does not switch to SPT). Later on, Rcv1
goes away.

Please point to the *specific* procedures in rfc4601 (section number
does not count as a "specific procedure") that would result in
preserving SPT (and specifically preserving (C-S, C-G) state on
PE2) after Rcv1 goes away.

> - -First, this delay has to be long enough for Source-Active A-D route to
> - -But more importantly this delay cannot be just in seconds but should

Your last claim above is incorrect.

> - -RP sends (S,G) Join to PE2 and PE2 sends Join directly to "S" 
> - -R1, R2, R3 send (*,G) Joins towards RP 
> - -R1, R2, R3 switch to SPT and single forwarder election chooses PE3 as
> the upstream PE

Let me remind you of the following text from Section 5.1.3 of 
draft-ietf-l3vpn-2547bis-mcast-08.txt

   Another procedure, which SHOULD be implemented, is to use the
   Installed UMH Route as the Selected UMH Route.  

in which case PE2 (and not PE3, as you claim above) will be chosen as 
the forwarder (as PE2's, PE1's, and PE4's best path to "S" is via PE2,
and not via PE3), and so the rest does not apply.

> because there will be no (S,G) Joins send to PE3 and thus there will be

As you know quite well, use of PIM for C-multicast signaling, as
specified in draft-ietf-l3vpn-2547bis-mcast-08.txt, can result
in a situation where multicast will *not* follow the VRF routing
policy, and the SPT may not be "as expected".

Using your example above, let's assume that that PE1's best path
to "S" is via PE2, but PE4's best path to "S" is via PE3. In this
case Asserts will result in either PE2 or PE3 being the forwarder,
which in turn will result in violation of the VRF routing policy
on either PE1 or PE4, and the SPT *not* being "as expected".

> the (S,G) Join route (quote from [BGP-MVPN]) "'correspond' to the PIM

What makes you think that the text I proposed mean "that an upstream PE 
may have (S,G) Join route(s) but no (S,G) PIM state" ?

Yakov.