Subject: Resolutions: draft-ietf-l3vpn-2547bis-mcast-bgp-06.txt

From: Danny McPherson <[email-masked]>
Date: Sun, 8 Mar 2009 12:13:56 -0600

Folks,
I would like to one-week Last Call only these comments
(or any issues that were brought up during the full
Last Call on this document that were not addressed below).

Last call ends March 17, 2009.

Thanks Rahul!

-danny

On Mar 4, 2009, at 4:58 PM, Rahul Aggarwal wrote:

>
> The revised version-06 of draft-ietf-l3vpn-2547bis-mcast-bgp, that
> addresses the LC comments, has been posted. Here is the list of
> comments and resolutions.
>
> --------------------------------------------------------------
>
> Comment 1: (substantial)
>
> Source: Subinoy Das <[email-masked]>:
>
> Section Point 5 in 7.4.1.1. Advertising C-flow Binding to P-Tunnel
> in draft-ietf-l3vpn-2547bis-mcast-07.txt, and section 12.1
> in draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt says:
>
>        "If at least some of the S-PMSIs aggregated onto the same
>        P-tunnel belong to different MVPNs, then all these routes MUST
>        carry an MPLS upstream assigned label [MPLS-UPSTREAM-LABEL,
>        section 6.3.4]. If all these aggregated S-PMSIs belong to the
>        same MVPN, then the routes MAY carry an MPLS upstream assigned
>        label [MPLS-UPSTREAM-LABEL]. The labels MUST be distinct on a
>        per MVPN basis, and MAY be distinct on a per route basis."
>
> I do not understand where 1 label per MVPN solves everything then
> what is the need to use 1 label per route. What is the need to keep
> multiple label for a single MVPN per PE router?
>
> Resolution:
>
> In the carrier's carrier case with mLDP between CE and PE, if one
> aggregates into the same P-tunnel of the inner carrier multiple
> p2mp LSPs of the outer carrier, the inner carrier would need to
> assign an upstream label to each of the outer carrier's p2mp LSPs.
> In other words, in this case assigning the upstream labels is a
> "MUST", not "MAY".
>
> To address this replace:
>
>   If all these aggregated S-PMSIs belong to the same MVPN, then the
>   routes MAY carry an MPLS upstream assigned label [MPLS-UPSTREAM].
>   The labels MUST be distinct on a per MVPN basis, and MAY be
>   distinct on a per route basis.
>
> With the following:
>
>   If all these aggregated S-PMSIs belong to the same MVPN, and
>   this MVPN uses PIM as its C-multicast routing protocol, then
>   the corresponding S-PMSI A-D routes MAY carry an MPLS upstream
>   assigned label [MPLS-UPSTREAM]. Moreover, in this case the
>   labels MUST be distinct on a per MVPN basis, and MAY be distinct
>   on a per route basis.
>
>   If all these aggregated S-PMSIs belong to the MVPN(s) that use
>   mLDP as its C-multicast routing protocol, then the corresponding
>   S-PMSI A-D routes MUST carry an MPLS upstream assigned label
>   [MPLS-UPSTREAM], and these labels MUST be distinct on a per
>   route (per mLDP FEC) basis, irrespective of whether the aggregated
>   S-PMSIs belong to the same or different MVPNs.
>
>
> -------------------------------------------------------------------
> Comment 2:
>
> Source: Yakov Rekhter (substantial)
>
> The current spec does not cover the case where one uses (non
> wild-card) S-PMSIs to carry (C-S, C-G) traffic that flows on the
> C-RPT tree.
>
> Resolution:
>
> In 12.1 ("Originating S-PMSI A-D routes") replace:
>
>   By default the set of Route Targets carried by the route MUST
>   be a set intersection between the set of Route Targets carried
>   in the intra-AS I-PMSI A-D route originated from the VRF, and
>   the set of Route Targets carried by the (unicast) VPN-IP route
>   to C-S originated from the VRF. The default could be modified
>   via configuration.
>
> with the following:
>
>    By default the set of Route Targets carried by the route MUST be
>    constructed as follow:
>
>      - If there is a (unicast) VPN-IP route to C-S originate
> 	 from the VRF, but no (unicast) VPN-IP route to C-RP
> 	 originated from the VRF, then the set of Route Targets is
> 	 set to a set intersection between the set of Route Targets
> 	 carried in the intra-AS I-PMSI A-D route originated from
> 	 the VRF, and the set of Route Targets carried by the
> 	 (unicast) VPN-IP route to C-S.
>
>      - If there is no (unicast) VPN-IP route to C-S originated
>        from the VRF, but there is a (unicast) VPN-IP route to C-RP
>        originated from the VRF, then the set of Route Targets is set  
> to
>        a set intersection between the set of Route Targets carried
>        in the intra-AS I-PMSI A-D route originated from the VRF,
>        and the set of Route Targets carried by the (unicast) VPN-IP
>        route to C-RP.
>
>      - If there is a (unicast) VPN-IP route to C-S originate
> 	 from the VRF, and a (unicast) VPN-IP route to C-RP originated
> 	 from the VRF, then the set of Route Targets is set to a
> 	 set intersection between the set of Route Targets carried
> 	 in the intra-AS I-PMSI A-D route originated from the VRF,
> 	 and the set union of Route Targets carried by the (unicast)
> 	 VPN-IP route to C-S and the (unicast) VPN-IP route to C-RP.
>
>    In all of the above cases an implementation MUST allow to modify
>    the default via configuration.
>
> In 12.3 ("Receiving S-PMSI A-D routes by PEs") replace:
>
>                                ... (b) a PE performs procedures
>  specified in that section only if in addition to the criteria
>  specified in that section all of the following is true:
>
>    + The PE has in its MVPN-TIB the state for either (C-*, C-G) or (C-
>      S, C-G), where C-S is the Multicast Source and C-G is the
>      Multicast Group carried in the S-PMSI A-D route, and the oif
>      (outgoing interfaces) for this state contains one or more
>      interfaces to the locally attached CEs.
>
>    + Either (a) the PE originates a Source Tree Join (C-S, C-G) C-
>      multicast route, and the upstream PE of that route is the PE that
>      originates the S-PMSI A-D route, or (b) the PE does not originate
>      a Source Tree Join (C-S, C-G) C-multicast route, and the best (as
>      determined by the BGP route selection procedures) Source Active
>      A-D route for (C-S, C-G) selected by the PE is originated by the
>      same PE as the one that originates the S-PMSI A-D route.
>
> with the following:
>
>                                ...  (b) a PE performs procedures
>    specified in that section only if in addition to the criteria
>    specified in that section one of the following is true:
>
> 	- the PE originates a Source Tree Join (C-S, C-G) C-multicast
> 	  route, and the upstream PE of that route is the PE that
> 	  originates the S-PMSI A-D route, or
>
> 	- the PE does not originate a Source Tree Join (C-S, C-G)
> 	  C-multicast route, but originates a Shared Tree Join (C-*,
> 	  C-G) C-multicast route, and the best (as determined by
> 	  the BGP route selection procedures) Source Active A-D
> 	  route for (C-S, C-G) selected by the PE is originated by
> 	  the same PE as the one that originates the S-PMSI A-D
> 	  route, or
>
> 	- the PE does not originate a Source Tree Join (C-S, C-G),
> 	  has not received any Source Active A-D routes for (C-S,
> 	  C-G), but does originate a Shared Tree Join (C-*, C-G)
> 	  route, and the upstream PE for that route is the PE that
> 	  originates the received S-PMSI A-D route.
>
> -------------------------------------------------------------------
> Comment 3:
>
> Source: Thomas Morin (substantial)
>
> Current specs allow a behavior where a PEs does not advertise an I- 
> PMSI
> tunnel, and will only use S-PMSIs for the traffic. In that case the PE
> can choose to only instantiate an S-PMSI and a tunnel after the
> reception of a C-multicast route.
>
> But there is a slight inconvenience: the downstream PEs don't have
> any way, other than by configuration, to tell that an upstream PE
> will behave in that way. Nothing breaks, but it makes it harder to
> have smooth feedback on the CLI and troubleshooting.
>
> Resolution:
>
> In Section 9.1.2 add after the first paragraph the following:
>
>  If the route does not carry the PMSI Tunnel Attribute and ingress
>  replication is not used, either a) the PE that originated the
>  route will be using only S-PMSIs to send traffic to remote PEs,
>  or b) as a matter of policy, the PE that originated the route,
>  cannot send multicast traffic from the MVPN sites connected to
>  it to other sites of that MVPN (in other words, the sites connected
>  to the PE are only in the Receiver Sites set).
>
>  When BGP is used to exchange C-multicast routes, to distinguish
>  between cases (a) and (b) we use the presence/absence of the VRF
>  Route Import extended community in the unicast VPN routes, as
>  follows. As specified in section "VRF Route Import Extended
>  Community", if it is know a priori that none of the addresses
>  carried in the NLRI of a given (unicast) VPN route could act as
>  multicast sources and/or C-RP, then such a route does not carry
>  the VRF Route Import extended community. Hence based on the UMH
>  selection algorithm specified in [MVPN], such a route will be
>  ineligible for the UMH selection. This implies that if a given
>  VPN route is selected by the UMH selection procedures, and the
>  PE that originates this VPN route also originates an Intra-AS
>  I-PMSI A-D route, but this route does not carry the PMSI Tunnel
>  attribute, then this PE will be using only S-PMSIs for sending
>  (multicast) data.
>
> -------------------------------------------------------------------
> Comment 4  (substantial)
>
> Source: Thomas Morin
>
> We must ensure that there are safeguards to avoid that customers
> could creates an unbounded amount of states in the PEs (and RRs) :
>
> - it applies to state in the PEs that is created directly based on  
> state
> on the PE-CE interfaces : (S,G) and (*,G) joins
> * we need safeguards to avoid too much states created on PEs based on
>   customer PIM activity
> * it implies having the operator configure upper bounds on the amount
>   of multicast states in the VRFs
> * this is true independently of the protocol used for C-multicast
>   routing
> - it also applies to states created "indirecly" based on customer
> activity: Source-Active and S-PMSI A-D routes
> * we need safeguards to cover these
> * S-PMSI routes are created based on (a) customer activity and (b) PE
>   policy defined by the operator   --> there is a need to bound the
>   amount, and frequency of changes, of S-PMSI state   (this critical  
> to
>   protect P routers, and is true independently of the protocol used to
>   signal S-PMSIs)
> * S-A A-D routes are also created based on customer activity:
>     -> in the context of section 13, they are only created based on
>        Source Tree Join routes, so if these are properly bounded,
>        it should be fine
>     -> in the context of section 14, they are created based on RP
>        activity, or PIM registers, or MSDP : bounds would typically
>        also setup here
>     -> if we want more solive boundaries, it seems to me that it makes
>        sense to suggest that implementation should provide a way to
>        set an upper bound to the number of S-A A-D routes that can
>        be advertised from a VRF
>
> Resolution: add the following text to the Security Considerations
> section of each of the documents:
>
> The following is for the framework/architecture document:
> ---------------------------------------------------------
>
> Many of the procedures in this document cause the SP network to
> create and maintain an amount of state which is proportional to
> customer multicast activity.  If the amount of customer multicast
> activity exceed expectations, this can potentially cause P and PE
> routers to maintain an unexpectedly large amount of state, which
> may cause control and/or data plane overload.  To protect
> against this situation an implementation should provide ways for
> the SP to bound the amount of state it devotes to the handling
> of customer multicast activity.
>
> In particular, an  implementation SHOULD provide mechanisms
> that allow a SP to place limitations on the following:
>
> - total number of (C-*, C-G) and/or (C-S, C-G) states per VRF
>
> - total number of P-tunnels per VRF used for S-PMSIs
>
> - total number of P-tunnels traversing a given P router
>
> A  PE implementation  MAY also provide  mechanisms that
> allow a SP  to limit the rate of change of various states on PEs,
> as well as the rate at which control  messages may be received
> by a PE from the CEs and/or sent from the PE to other PEs.
>
> Lack of the mechanisms that allow a SP to limit the rate of change
> of various states on PEs, as well as the rate at which control
> messages may be received by a PE from the CEs and/or sent from the
> PE to other PEs may result in the control plane overload on a PE,
> which in turn would adversely impact all the customers connected
> to that PE, as well as to other PEs.
>
>
> The following is for the -bgp spec:
> -----------------------------------
>
> When C-multicast routing information is exchanged among PEs using
> BGP, an implementation SHOULD provide the ability to rate limit BGP
> messages used for this exchange. This SHOULD be provided on a per
> PE, per MVPN granularity.
>
> An implementation SHOULD provide capabilities to impose an upper
> bound on the number of S-PMSI A-D routes, as well as on how frequently
> they may be originated. This SHOULD be provided on a per PE, per
> MVPN granularity.
>
> In conjunction with the procedures specified in Section "Supporting
> PIM-SM without Inter-Site Shared C-trees" an implementation SHOULD
> provide capabilities to impose an upper bound on the number of
> Source Active A-D routes, as well as on how frequently they may be
> originated. This SHOULD be provided on a per PE, per MVPN granularity.
>
> In conjunction with the procedures specified in Section "Switching
> from Shared C-tree to Source C-tree" limiting the amount of (C-S,C-G)
> state would limit the amount of Source Active A-D route, as in the
> context of this section Source Active A-D routes are created in
> response to Source Tree Join C-multicast routes, and Source Tree
> Join C-multicast routes are created as a result of creation of (C-S,
> C-G) state on PEs. However, to provide an extra level of robustness
> in the context of these procedures an implementation MAY provide
> capabilities to impose an upper bound on the number of Source Active
> A-D routes, as well as on how frequently they may be originated.
> This MAY be provided on a per PE, per MVPN granularity.
>
> Section "Dampening withdrawals of C-multicast routes" describes
> optional procedures for dampening withdrawals of C-multicast routes.
> It is RECOMMENDED that an implementation supports such procedures.
>
> Section "Dampening withdrawals of Leaf A-D routes" describes
> optional procedures for dampening withdrawals of Leaf A-D routes.
> It is RECOMMENDED that an implementation supports such procedures.
>
> -------------------------------------------------------------------
> Comment 5  (substantial)
>
> Source: Mark Fine
>
> Comments on draft-ietf-l3vpn-2547bis-mcast-bgp section 13 and
> draft-ietf-l3vpn-2547bis-mcast section 9.1:
>
> With C-RP behind PE1, PE2 having (C-*,C-G) state, C-S behind PE3, and
> C-S sending traffic to C-G...
>
> C-RP will upstream join (C-S,C-G) since inherited_olist(C-S,C-G) will
> contain joins(C-*,C-G) from PE2's (C-*,C-G) state.
>
> Per 13.1 and 9.1, PE3 creates (C-S,C-G) state as a result of receiving
> the Source Tree Join C-multicast route from PE1, and PE3 originates
> the Source Active route.
>
> Per 13.2 and 9.1, PE2 sets up its forwarding path to receive (C-S,C-G)
> from PE3's tunnel as a result of receiving the Source Active route
> from PE3.
>
> Per 13.2.1 and 9.1, PE1 creates (C-S,C-G,rpt) state as a result of
> receiving the Source Active route from PE3 and having (C-*,C-G) state
> with an iif containing a PE-CE interface.
>
> C-RP will upstream prune (C-S,C-G) since inherited_olist(C-S,C-G) will
> be NULL from PE1's (C-S,C-G,rpt) state.
>
> Per 13.1 and 9.1, PE3 deletes (C-S,C-G) state as a result of the
> withdrawn Source Tree Join C-multicast route from PE1, and PE3
> withdraws the Source Active route.
>
> Per 13.2.1 and 9.1, PE1 deletes (C-S,C-G,rpt) state as a result of the
> withdrawn Source Active route from PE3.
>
> C-RP will upstream join (C-S,C-G) since inherited_olist(C-S,C-G) will
> no longer be NULL from after deleting PE1's (C-S,C-G,rpt) state.
>
> ... per 13 and 9.1, the above suggests a continuous cycle of joining
> C-RP to SPT, pruning C-S off RPT, pruning C-RP from SPT, joining C-S
> to RPT, joining C-RP to SPT... only forwarding (C-S,C-G) traffic to
> PE2 in the intervals where C-RP is joined to SPT.
>
> Resolution:
>
> Replace Section 13.2.1 with the following:
>
>  In addition to the procedures in the previous section, a PE
>  applies the following procedure when importing a Source Active
>  A-D route for (C-S,C-G) into a VRF.
>
>  The PE finds an <C-*, C-G> entry in the MVPN-TIB whose C-G is
>  the same as C-G carried in the Multicast Group field of the
>  Source Active A-D route.
>
>  If the outgoing interface list (oif) for the found <C-*,C-G>
>  entry in the MVPN-TIB on the PE contains either I-PMSI or S-PMSI,
>  and the PE does not originate the Source Tree Join C-multicast
>  route for <C-S, C-G> (where C-S is address carried in the Multicast
>  Source field, and C-G is the address carried in the Multicast
>  Group field of the received Source Active A-D route), then the
>  PE MUST transition the (C-S, C-G, rpt) downstream state machine
>  on I-PMSI/S-PMSI to the Prune state. [Conceptually the C-PIM
>  state machine on the PE will act "as if" it had received Prune
>  (C-S, C-G,Rpt) on I-PMSI/S-PMSI, without actually having received
>  one.] Depending on the (C-S,C-G,rpt) state of the PE-CE interfaces,
>  this may result in the PE using PIM procedures to prune C-S
>  off the (C-*,C-G) tree.
>
>  Transitioning the state machine to the Prune 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 C-S is not pruned off the shared tree until all
>  PEs have had time to receive the Source Active A-D route for
>  <C-S, C-G>.
>
>  Note that before C-S is prune off the shared tree, there is a
>  possibility to have (C-S,C-G) packets be sent at the same time
>  on the PMSI by distinct PEs. 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].
>
>  The PE MUST keep the (C-S, C-G, rpt) downstream state machine
>  on I-PMSI/S-PMSI in the Prune state for as long as (a) the
>  outgoing interface list (oif) for the found <C-*,C-G> entry in
>  the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, and (b)
>  the PE has at least one Source Active A-D route for <C-S, C-G>,
>  and (c) the PE does not originate the Source Tree Join C-multicast
>  route for <C-S, C-G>.  Once either of these conditions become
>  no longer valid, the PE MUST transition the (C-S, C-G, rpt)
>  downstream state machine on I-PMSI/S-PMSI to the NoInfo state.
>
>  Note that changing the state on the downstream state machine
>  on I-PMSI/S-PMSI, as described above, does not imply exchanging
>  PIM messages over I-PMSI/S-PMSI.
>
>  Note also, that except for the scenario described in the third
>  paragraph of this section, in all other scenarios relying solely
>  on PIM procedures on the PE is sufficient to ensure the correct
>  behavior when pruning sources off the shared tree.
>
> -------------------------------------------------------------------
> Comment 6
>
> Source Thomas Morin:
>
>> From section 14.1:
>
>  When a PE using any of the above methods first learns of a new
>  (multicast) source within that MVPN, the PE constructs a Source
>  Active A-D route, and sends this route to all other PEs that have one
>  or more sites of that MVPN connected to them. The route carries a
>  single MCAST-VPN NLRI constructed as follows:
>
>    + The RD in this NLRI is set to the RD of the VRF of the MVPN on
>      the PE.
>
>    + The Multicast Source field MUST be set to the source IP address
>      of the multicast data packet carried in the PIM-Register message.
>      The Multicast Source Length field is set appropriately to reflect
>      this.
>
>    + The Multicast Group field MUST be set to the group address of the
>      multicast data packet carried in the PIM-Register message. The
>      Multicast Group Length field is set appropriately to reflect
>      this.
>
> In the above, the "of the multicast data packet carried in the
> PIM-Register message" does not take into account the case where the
> source was learned through MSDP.
>
> Resolution:
>
> Change the last two bullets in the above to the following:
>
>    + The Multicast Source field MUST be set to the source IP address
>      of the multicast data packet carried in the PIM-Register
>      message (RP/PIM register case) or of the MSDP Source-Active
>      message (MSDP case). The Multicast Source Length field is set
>      appropriately to reflect this.
>
>    + The Multicast Group field MUST be set to the group IP address
>      of the multicast data packet carried in the PIM-Register
>      message (RP/PIM register case) or of the MSDP Source-Active
>      message (MSDP case). The Multicast Group Length field is set
>      appropriately to reflect this.
>
> -------------------------------------------------------------------
> Comment 7
>
> Source: Thomas Morin
>
> When a PE is connected to both the RP and a source C-S, it could
> advertise an Source Active A-D route for (C-S,C-G) at some point, but
> it should not apply to (C-S,C-G) the procedures in 13.2.
>
> Resolution:
>
> Modify the first sentence in 13.2 by replacing
>
>   When a PE receives a new Source Active A-D route ...
>
> with
>
>   When a PE receives a new Source Active A-D route from some other  
> PE ...
> -------------------------------------------------------------------
> Comment 8
>
> Source: Thomas Morin
>
> In section 13 the spec should state that Source Active A-D routes
> are originated only based on the reception of Source Tree Join
> routes, and not on any other conditions (e.g., reception of PIM
> registers).
>
> Resolution:
>
> Add the following at the end of 13.1:
>
>  Note that if the PE is also acting as a C-RP, but inter-site
>  shared trees are being used, the reception of a PIM Register
>  message by the PE does not result in the origination of a Source
>  Active A-D route.
>
> -------------------------------------------------------------------
> Comment 9
>
> Source: Maria Napierala
>
> Description should be added to section 14 on how a PE handles <C-*,  
> C-G>
> Prune messages received from locally attached CEs.
>
> Resolution:
>
> Add the following paragraph to section 14 immediately before the  
> paragraph
> that begins with "Even though PIM is used as a C-multicast protocol,"
>
>  When a PE deletes the <C-*, C-G> state (e.g., due to to receiving
>  PIM Prune (C-*, C-G) from its CEs), the PE MUST withdraw all the
>  Source Tree Join C-multicast routes for C-G that have been
>  advertised by the PE, except for the routes for which the PE
>  still maintains the corresponding <C-S, C-G> state.
>
> -------------------------------------------------------------------
> Comment 10
>
> Source: Maria Napierala
>
> 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.
>
> Resolution:
>
> Add the following paragraph at the end of section 12.3:
>
>  If a PE that is a leaf node of a particular Selective tunnel
>  determines that it no longer needs to receive any of (C-S, C-G)s
>  carried over that tunnel, the PE SHOULD prune itself off that
>  tunnel.  Procedures for pruning are specific to a particular
>  tunneling technology.
>
> -------------------------------------------------------------------
> Comment 11
>
> Source: Venu Hemige, Mark Fine, Thomas Morin
>
> To clarify that in the context of section 13.2 BGP Source Active
> A-D routes do not replace MSDP or PIM-based Anycast RP peering among
> RPs add the following to 13.2:
>
>  Note that if the PE is also acting as a C-RP, and inter-site shared
>  trees are being used, the BGP Source Active A-D routes do not replace
>  the MSDP or PIM-based Anycast RP peerings among C-RPs that would be
>  needed to disseminate source discovery information among C-RPs.
>
> -------------------------------------------------------------------
> Comment 12
>
> Source: Rahul Aggarwal
>
> Clarify that adding I-PMSI/S-PMSI to the oif does not imply
> exchanging PIM messages over I-PMSI/S-PMSI
>
> Resolution:
>
> Add the following as the last paragraph to section 11.3.1:
>
>  Since C-multicast routing information is disseminated by BGP,
>  PIM messages are never sent from one PE to another.
>
> -------------------------------------------------------------------
> Comment 13
>
> Source: Thomas Morin
>
> Clarify procedures for handling Leaf A-D routes originated in
> response to S-PMSI A-D routes.
>
> Resolution:
>
> In Section 12.1 replace:
>
>    + If a PE originates S-PMSI A-D routes with the Leaf Information
>      Required flag in the PMSI Tunnel attribute set to 1, then the PE
>      MUST be (auto)configured with an import Route Target, which
>      controls acceptance of Leaf A-D routes by the PE.
>
> with the following:
>
>    + If a PE originates S-PMSI A-D routes with the Leaf Information
>      Required flag in the PMSI Tunnel attribute set to 1, then the PE
>      MUST be (auto)configured with an import Route Target, which
>      controls acceptance of Leaf A-D routes by the PE. (Procedures
>      for originating Leaf A-D routes by the PEs that receive the
>      S-PMSI A-D route are described in section "Receiving S-PMSI
>      A-D routes by PEs.)
>
> In Section 12.3 replace:
>
>  Note that if the received S-PMSI A-D route has a PMSI Tunnel
>  attribute with the Leaf Information bit set, then the above
>  procedures may cause the origination of a Leaf A-D route whose Route
>  Key is set to the NLRI of the S-PMSI A-D route.
>
> with the following:
>
>  If the received S-PMSI A-D route has a PMSI Tunnel attribute
>  with the Leaf Information Required flag set to 1, then the PE
>  originates a Leaf A-D route. The Route Key of the Leaf A-D route
>  is set to the MCAST-VPN NLRI of the S-PMSI A-D route. The rest
>  of the Leaf A-D route is constructed using the same procedures
>  as specified in section "Originating Leaf A-D route into IBGP",
>  except that instead of originating Leaf A-D routes in response
>  to receiving Inter-AS I-PMSI A-D routes the procedures apply to
>  originating Leaf A-D routes in response to receiving S-PMSI A-D
>  routes.
>
> -------------------------------------------------------------------
> Comment 14
>
> Source: Yakov Rekhter
>
> The first bullet in 9.2.3.4.1 seems to be missing PE.
>
> Resolution:
>
> Replace:
>
>    + The route carries a single MCAST-VPN NLRI with the Route Key
>      field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route
>      received from that neighbor, and the Originating Router's IP
>      address set to the IP address of the ASBR (this MUST be a
>      routable IP address).
>
> with the following:
>
>    + The route carries a single MCAST-VPN NLRI with the Route Key
>      field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route
>      received from that neighbor, and the Originating Router's IP
>      address set to the IP address of the PE/ASBR (this MUST be a
>      routable IP address).
>
> -------------------------------------------------------------------
> Comment 15
>
> Source: Thomas Morin
>
> We need to clarify the text that specifies conditions for using
> "No tunnel information present" flag in the PMSI Tunnel attribute.
>
> Resolution:
>
> In Section 5 replace:
>
>   When the type is set to "No tunnel information present", the PMSI
>   Tunnel attribute carries no tunnel information (no Tunnel
>   Identifier).  This may be used to enable explicit tracking for a
>   particular customer multicast flow (by setting the Leaf Information
>   Required flag to 1), but without binding this flow to a particular
>   provider tunnel (by omitting any tunnel information).
>
> with the following:
>
>  When the type is set to "No tunnel information present", the
>  PMSI Tunnel attribute carries no tunnel information (no Tunnel
>  Identifier). This type is to be used only in the following case:
>  to enable explicit tracking for a particular customer multicast
>  flow (by setting the Leaf Information Required flag to 1), but
>  without binding this flow to a particular provider tunnel (by
>  omitting any tunnel information).
>
> -------------------------------------------------------------------
> Comment 16
>
> Source: Yakov Rekhter
>
> The current text allows routes originated from sites that are only
> in the Receiver Sites set to be used for UMH selection.  This is
> incorrect, as such sites should not (as a matter of policy) contain
> multicast sources and/or C-RP.
>
> Resolution:
>
> In Section 7 replace:
>
>  To support MVPN, in addition to the import/export Route Target(s)
>  extended communities used by the unicast routing, each VRF on a PE
>  MUST have an import Route Target extended community.
>
> with the following:
>
>  To support MVPN in addition to the import/export Route Target(s)
>  extended communities used by the unicast routing, each VRF on a
>  PE MUST have an import Route Target extended community, except
>  if it is known a priori that none of the (local) MVPN sites
>  associated with the VRF contain multicast source(s) and/or C-RP,
>  in which case the VRF need not have this import Route Target.
>
> In Section 7 replace:
>
>           To accomplish this a PE that originates a (unicast) route
>  to VPN-IP addresses MUST include in the BGP Updates message that
>  carries this route the VRF Route Import extended community that has
>  the value of the C-multicast Import RT of the VRF associated with the
>  route, except if it is known a priori that none of these addresses
>  will act as multicast sources and/or RP, in which case the (unicast)
>  route need not carry the VRF Route Import extended community.
>
> with the following:
>
>           To accomplish this a PE that originates a (unicast) route
>    to VPN-IP addresses MUST include in the BGP Updates message
>    that carries this route the VRF Route Import extended community
>    that has the value of the C-multicast Import RT of the VRF
>    associated with the route, except if it is known a priori
>    (e.g., via provisioning) that none of these addresses could
>    act as multicast sources and/or RP, in which case the (unicast)
>    route MUST NOT carry the VRF Route Import extended community.
>
> -------------------------------------------------------------------
> Comment 17
>
> Source: Yakov Rekhter
>
> Making OPTIONAL origination of Intra-AS I-PMSI A-D routes
> just complicates the system, and does not promote interoperability.
>
> Resolution:
>
> In Section 9.1.1 replace:
>
>  When BGP is used to exchange C-multicast routes, originating an
>  Intra-AS I-PMSI A-D route for a given MVPN by a given PE is OPTIONAL
>  if (a) it is known a priori that none of the MVPN sites connected to
>  the PE have multicast sources, (b) the PE does not use ingress
>  replication for incoming multicast traffic of that MVPN, and (c) none
>  of the other PEs that have VRFs of that MVPN use RSVP-TE P2MP LSPs
>  for that MVPN.
>
>  When BGP is used to exchange C-multicast routes, originating an
>  Intra-AS I-PMSI A-D route for a given MVPN by a given PE is also
>  OPTIONAL if it is known a priori that none of the MVPN sites
>  connected to the PE have multicast receivers, and the PE uses ingress
>  replication for that MVPN.
>
> with the following:
>
>  When BGP is used to exchange C-multicast routes, if (a) it is
>  known a priori that as a matter of policy none of the MVPN sites
>  connected to a given PE are allowed to send multicast traffic
>  to other sites of that MVPN (in other words, all these
>  sites are only in the Receiver Sites set), (b) the PE does not
>  use ingress replication for the incoming traffic of that MVPN,
>  and (c) none of the other PEs that have VRFs of that MVPN use
>  RSVP-TE P2MP LSP for that MVPN, then the local PE SHOULD NOT
>  originate an Intra-AS I-PMSI A-D route.
>
>  When BGP is used to exchange C-multicast routes, if it is known
>  a priori that as a matter of policy none of the MVPN sites
>  connected to a given PE can receive multicast traffic from other
>  sites of that MVPN (in other words, all these sites are only in
>  the Sender Sites set), and the PE uses ingress replication for
>  that MVPN, then the PE SHOULD NOT originate an Intra-AS I-PMSI
>  A-D route for that MVPN.
>
> -------------------------------------------------------------------
> Comment 18
>
> Source: Thomas Morin
>
> Add the following to the Security section:
>
>  A PE router MUST NOT accept from CEs routes with MCAST-VPN SAFI.
>
> -------------------------------------------------------------------
> Comment 19
>
> Source: Eric Rosen
>
> Add the following to the Security section:
>
>  If BGP is used as a CE-PE routing protocol, then when PE receives
>  a route from CE, if this route carries the VRF Route Import
>  extended community, the PE MUST remove this community from the
>  route before turning it into a VPN-IP route. Routes that a PE
>  advertises to a CE MUST NOT carry the VRF Route Import
>  extended community.
> -------------------------------------------------------------------
> Comment 20
>
> Source: Eric Rosen
>
> The following from 11.3.1.1 states that if there is no S-PMSI at the  
> time
> C-(S,G)  state is created, then an I-PMSI must be  used. But in  
> general,
> the S-PMSI for C-(S,G) won't exist at the  moment the C-(S,G) state is
> first created. Therefore, the text may give an impression that
> it does not cover the case where one uses S-PMSIs only (no I-PMSIs),
> which is certainly not the case.
>
>                                            If there is no S-
>  PMSI for <C-S, C-G> then the PE adds an I-PMSI to the outgoing
>  interface list of the state if it is not already there. If there is
>  an S-PMSI for <C-S, C-G> then the PE add S-PMSI to the outgoing
>  interface list of the state if it is not already there.
>
> Resolution:
>
> Replace the above with the following:
>
>   If the local policy on the PE is to bind <C-S, C-G> to an S-PMSI,
>   then the PE adds the S-PMSI to the outgoing interface list of
>   the <C-S, C-G> state, if it is not already there. Otherwise,
>   the PE adds an I-PMSI to the outgoing interface list of the
>   <C-S, C-G> state, if it is not already there.
> ---------------------------------------------------------------------
>
> Comment 21
>
> Source: Yakov Rekhter
>
> In Section 13.2 we need to clarify the rules for creating (C-S,C-G)
> state in response to receiving SA A-D routes to make it clear that
> a PE creates such state not just when it has (C-*, C-G) state, but
> when this state also results in originating a Shared Tree Join (C-*,
> C-G) route (in other words, when C-RP is reachable through some
> other PE).
>
> Resolution:
>
> In Section 13.2 replace:
>
>  We say that a given (C-S, C-G) Source Active A-D route stored in a
>  given VRF matches a given <C-*, C-G> entry present in the MVPN-TIB
>  associated with the VRF if C-G carried by the route is the same as C-
>  G of the entry.
>
> with:
>
>  We say that a given (C-S, C-G) Source Active A-D route stored
>  in a given VRF on a PE matches a given <C-*, C-G> entry present
>  in the MVPN-TIB associated with the VRF if C-G carried by the
>  route is the same as C-G of the entry, and the PE originates a
>  Shared Tree Join C-multicast route for the same C-G as C-G of
>  the entry.
>
> ---------------------------------------------------------------------
>
> Comment 22
>
> Source: Yakov Rekhter
>
> Make it explicit that one may combine advertisement of a Source
> Active A-D route nad an S-PMSI A-D route into the same BGP Update
> message.
>
> Resolution:
>
> Add the following to 13.1:
>
>  Note that the advertisement of a Source Active A-D route for
>  a given (C-S, C-G) could be combined, if desired, with the
>  advertisement of an S-PMSI A-D route for the same (C-S, C-G)
>  This is accomplished by using the same BGP Update message to carry
>  both the NLRI of the S-PMSI A-D route and the NLRI of the Source
>  Active A-D route.
>
>  Note that even if the originating PE advertises both the Source
>  Active A-D route and the S-PMSI A-D route in the same BGP Update
>  message, an implementation can not assume that all other PEs
>  will receive both of these routes in the same Update message.
>
> ---------------------------------------------------------------------
>
> Comment 23
>
> Source: Eric Rosen
>
> Section  11.1.2,  correctly, specifies  that  if  mLDP  is the  C-M   
> routing
> protocol, the Multicast  Group field of the C-multicast route  is  
> set to the
> Opaque Value from mLDP's P2MP Label Map.
>
> There are three other  places where  it says that  the Multicast   
> Group field
> should be set  to the C-Generic LSP Identifier Value (at  least one  
> of these
> places actually refers to section 11.1.2).
>
> Resolution:
>
> Replace the  the term "C-Generic  LSP Identifier Value" throughout the
> document with the term "C-LDP  MP  Opaque  Value Element", as follows:
>
> Section 4.3:
>
> OLD
>
>  The Multicast Group field contains the C-G address or C-Generic LSP
>  Identifier Value (use of C-Generic LSP Identifier Value is
>  described in Section "Receiving routes:  mLDP as the C-Multicast
>  protocol").  If the Multicast Group field contains an IPv4 address
>  or a C-Generic LSP Identifier Value, then the value of the
>  Multicast Group Length field is 32. If the Multicast Group field
>  contains an IPv6 address, then the value of the Multicast Group
>  Length field is 128.
>
> NEW
>
>  The Multicast Group field contains the C-G address or C-LDP MP
>  Opaque Value Element (use of C-LDP MP Opaque Value Element is
>  described in Section "Receiving routes: mLDP as the C-Multicast
>  protocol").  If the Multicast Group field contains an IPv4 address,
>  then the value of the Multicast Group Length field is 32. If the
>  Multicast Group field contains an IPv6 address, then the value of
>  the Multicast Group Length field is 128.
>
> Section 4.6
>
> OLD
>
>  The Group Address field contains the C-G address or C-Generic LSP
>  Identifier Value. If the Multicast Group field contains an IPv4
>  address or C-Generic LSP Identifier Value, then the value of the
>  Multicast Group Length field is 32. If the Multicast Group field
>  contains an IPv6 address, then the value of the Multicast Group
>
> NEW
>
>  The Group Address field contains the C-G address or C-MP Opaque
>  Value Element.  If the Multicast Group field contains an IPv4
>  address, then the value of the Multicast Group Length field is 32.
>  If the Multicast Group field contains an IPv6 address, then the
>  value of the Multicast Group Length field is 128.
>
> Section 11.3.2
>
> OLD
>
>  When the PE receives a Source Tree Join C-multicast route, the PE
>  applies, in the scope of this VRF, the P2MP mLDP procedures for a
>  transit node using the value carried in the Multicast Source field
>  of the route as the C-Root Node Identifier, and the value carried
>  in the Multicast Group of the route as the C-Generic LSP Identifier
>  Value.
>
>  If there is no S-PMSI for <C-Root Node Identifier, C-Generic LSP
>  Identifier Value> then the PE creates and advertises an S-PMSI as
>  described in Section "Using S-PMSI A-D routes to Bind C-trees to P-
>  tunnels" using C-Root Node Identifier as the value for the
>  Multicast Source field of the S-PMSI A-D route and C-Generic LSP
>  Identifier Value as the value for the Multicast Group field of the
>  route.
>
>
> NEW
>
>  When the PE receives a Source Tree Join C-multicast route, the PE
>  applies, in the scope of this VRF, the P2MP mLDP procedures for a
>  transit node using the value carried in the Multicast Source field
>  of the route as the C-Root Node Identifier, and the value carried
>  in the Multicast Group of the route as the C-LDP MP Opaque Value
>  Element.
>
>  If there is no S-PMSI for <C-Root Node Identifier, C-LDP MP Opaque
>  Value Element> then the PE creates and advertises an S-PMSI as
>  described in Section "Using S-PMSI A-D routes to Bind C-trees to
>  P-tunnels" using C-Root Node Identifier as the value for the
>  Multicast Source field of the S-PMSI A-D route and C-LDP MP Opaque
>  Value Element as the value for the Multicast Group field of the
>  route.