Subject: Comment on draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 13.1

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 9 Mar 2009 11:15:56 -0400

Section 13.1. "Source Within a Site - Source Active Advertisement" says:

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

This condition is not sufficient to prevent packet duplication. 

Here is the scenario that illustrates the issue:

                         RP------------------|
                          |                  |
                         PE3----PE1---PE2----S
                                 |     |
                                 |     |
                                R1     R2

RP joins "S" via a backdoor.
R2 sends (*,G) Join.
R2 switches to SPT which creates (S,G) state on PE2. PE2 accepts "S" on
SPT and drops "S" traffic received on RPT.
R1 sends (*,G) Join.
R1 switches to SPT and PE1 sends (S,G) Join route to PE2. PE2 adds
MI-PMSI to oil of (S,G) state. According to section 13.1 PE2 does not
originate Source Active A-D route for (S,G) because it did not create
(S,G) when it received (S,G) Join route. 
Since Source Active route was not sent, PE3 does not prune "S" from RPT
(i.e., does not originate (S,G,rpt) Prune).
R1 receives duplicate "S" traffic on MI-PMSI, on RPT and SPT.

Maria

---

From: Thomas Morin <[email-masked]>
Date: Mon, 09 Mar 2009 16:35:03 +0100

Hi Maria,

It seems to me that it is wording issue.

The paragraph you quote says:  "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 case you point out kind of slips through a little hole left in the
sentence...  I think that the intent was to produce a sentence including
the case where the state could first have possibly been created by some
other join from a CE, something like:

  "Whenever a PE creates, _or_keeps_, 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."

(or alternatively, which I think would be equivalent: "Whenever a PE has
a C-multicast Source Tree Join (S,G) route and RPF(S) is a VRF
interface")

-Thomas

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 9 Mar 2009 11:43:19 -0400

Thomas,
I am not sure what "_or_keeps_" means... I think the wording would have
to be made more clear.

What will be the condition of SA route withdrawal?

Maria

> -----Original Message-----
> From: Thomas Morin [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 11:35 AM
> To: NAPIERALA, MARIA H, ATTLABS
> Cc: L3VPN
> Subject: Re: Comment on draft-ietf-l3vpn-2547bis-mcast-bgp-06 section
> 13.1
> 
> Hi Maria,
> 
> >    "Whenever a PE creates an (C-S,C-G) state as a result of
receiving
> a

---

From: Thomas Morin <[email-masked]>
Date: Mon, 09 Mar 2009 16:59:54 +0100

NAPIERALA, MARIA H, ATTLABS :
> >
> > The case you point out kind of slips through a little hole left in 
> > the sentence...  I think that the intent was to produce a sentence
> > including the case where the state could first have possibly been
> > created by some other join from a CE, something like:
> > 
> > (or alternatively, which I think would be equivalent: "Whenever a PE
> > has a C-multicast Source Tree Join (S,G) route and RPF(S) is a VRF
> > interface")
>

Yes, a better wording could be found...

The idea, if I'm correct, is that the condition holds if the PE receives
a C-multicast Source Tree Join from some other PE and actually process
it as a join for himself (ie. just seeing the BGP route is not enough),
whether to create (S,G) state if it is not already there, or to
contribute to keeping it (ie. when/if there is no VRF interface joined
to (S,G), the (S,G) would be kept).

> What will be the condition of SA route withdrawal?

It needs to be symmetrical, I think: that withdrawal of the SA A-D route
is conditioned to not having anymore the a C-multicast route matching
the above condition.

-Thomas

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 12 Mar 2009 07:43:23 -0700

Thomas,

> Yes, a better wording could be found...

Yes, indeed. Attached is the replacement text.

> is conditioned to not having anymore the a C-multicast route matching

In 13.1 make the following changes:

OLD:

   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 route carries a single MCAST-VPN NLRI constructed as
   follows:

NEW:

   Whenever as a result of receiving a Source Tree Join C-multicast
   route for (C-S, C-G) from some other PE the local PE adds either
   the S-PMSI or I-PMSI to the outgoing interface list of the (C-S,
   C-G) state (see Section 11.3.1.1 "Receiving Source Tree Join
   C-multicast route"), the local PE MUST originate a Source Active
   A-D route if the PE has not originated such route already. The
   route carries a single MCAST-VPN NLRI constructed as follows:

OLD:

   Whenever the PE deletes the (C-S, C-G) state that was previously
   created as a result of receiving a Source Tree Join C-multicast route
   for (C-S, C-G) from some other PE, the PE that deletes the state MUST
   also withdraw the Source Active A-D route, if such a route was
   advertised when the state was created.

NEW:

   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.

Yakov.