Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

[Yakov Rekhter <[e-mail]>]

Maria,

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

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.

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

We will add some text to cover this.
> 
> - 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.

We will add some text to cover this.

Yakov.