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

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Wed, 8 Apr 2009 13:23:52 -0400

Yakov,

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

Well, you opposed this draft, so are you now supporting it?

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

RFC 4601, section 4.6.1. "(S,G) Assert Message State Machine":

AssertTrackingDesired(S,G,I) =
        (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
                (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
                (-) lost_assert(*,G)
                (+) joins(S,G) ) )
        OR (local_receiver_include(S,G,I) == TRUE
            AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me)))
        OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE))
        OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE)
            AND (SPTbit(S,G) == FALSE))

...

   Transitions from NoInfo State
...
     Receive Acceptable Assert with RPT bit clear AND
          AssertTrackingDesired(S,G,I)==TRUE
          We're interested in (S,G) Asserts, either because I is a
          downstream interface for which we have (S,G) or (*,G)
          forwarding state, or because I is the upstream interface for S
          and we have (S,G) forwarding state.  The received assert has a
          better metric than our own, so we do not win the Assert.  We
          transition to "I am Assert Loser" and perform Actions A6
          (below).
...

   (S,G) Assert State machine Actions

...
    A6:  Store new assert winner as AssertWinner(S,G,I) and assert
          winner metric as AssertWinnerMetric(S,G,I).
          Set Assert Timer to Assert_Time.
          If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true)
          set SPTbit(S,G) to TRUE.

> 
> > 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.
> 
> Your last claim above is incorrect.

Why?

> 
> > > >> There are other side effects of single forwarder election and
> > > >> 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
> 
> 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.

If "Installed UMH Route" procedure is chosen and MI-PMSI is used it
would generate duplicates if say PE1 choose PE2 as UMH and PE3 chooses
PE4 as UMH.  This would not be the case in PIM since the Assert would
choose either PE3 or PE4 as a single forwarder.  
 
> > 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.
> 
> 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".

My example meant to illustrate something different, namely, that with
Assert, when all PEs/VRFs have the same routing policy, the correct
upstream PE will be chosen. This is not the case with single forwarder
election and BGP-signaling. 

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

The first condition "Whenever the PE deletes the (C-S, C-G) state [...]"
implies the creation of such a state (i.e., existence of (S,G) join
route but no (S,G) PIM state) on upstream PE.

Maria