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

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 4 Mar 2009 15:58:42 -0800

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.