Fwd: FW: Review of draft-ietf-l3vpn-2547-mcast-05

[Rick Wilder <[e-mail]>]

Sorry, folks. This is the second try to forward this to the list. Not
sure what happened the first time.

Rick

--- Rick Wilder <[e-mail]> wrote:

> From Rick Wilder Tue Feb  5 07:26:22 2008
> Received: from [72.205.13.24] by web303.biz.mail.mud.yahoo.com via HTTP; Tue, 05 Feb 2008
> 07:26:22 PST
> Date: Tue, 5 Feb 2008 07:26:22 -0800 (PST)
> From: Rick Wilder <[e-mail]>
> Subject: Fwd: FW: Review of draft-ietf-l3vpn-2547-mcast-05
> To: [e-mail]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> Content-Length: 56334
> 
> 
>  Forwarded to the list on behalf of Bruce Davie:
>  
> > 
> > Begin forwarded message:
> > 
> > 
> > 	From: Bruce Davie <[e-mail]>
> > 	Date: January 3, 2008 1:56:36 PM EST
> > 	To: [e-mail], Eric Rosen <[e-mail]>, [e-mail]
> > 	Subject: Review of draft-ietf-l3vpn-2547-mcast-05
> > 
> > 	As requested at the last WG meeting in Vancouver, I have provided a detailed review of
> > draft-ietf-l3vpn-2547-mcast-05.
> > 
> > 	I think it's an excellent document. Given the complexity of the problem space, it is
> admirably
> > readable and comprehensible. The only major issues I could find are ones that the authors have
> > acknowledged (as in "this issue will be addressed in a future revision").
> > 
> > 	Most of my comments below are suggestions to improve the clarity or to help readers more
> easily
> > understand the document. I have not bothered to point out every typo (that's something the RFC
> > editor does) but I did point out a few to prove I was paying attention.
> > 
> > 	All my comments are prefaced by the section number and the piece of text on which I'm
> > commenting and then by BD>>. For those large chunks of the text on which I had no comments,
> I've
> > just cut the text and replaced it with [...]
> > 
> > 	Bruce Davie
> > 	===============
> > 	2.1. Optimality vs Scalability
> > 	[...]
> > 
> > 	   However, in order to provide optimal multicast routing for a
> > 	   particular multicast flow, the P routers through which that flow
> > 	   travels have to hold state which is specific to that flow.
> > 
> > 
> > 	BD>>> "Flow" is one of those words that means different things to
> > 	different people, so I think you should define it here or earlier in
> > 	the document, or at least reference a document that defines it
> > 	suitably for your purposes.
> > 
> > 	[...]
> > 
> > 	2.2.4. PE-PE Multicast Routing Information
> > 
> > 	   The BGP/MPLS IP VPN [RFC4364] specification requires a PE to maintain
> > 	   at most one BGP peering with every other PE in the network. This
> > 	   peering is used to exchange VPN routing information. The use of Route
> > 	   Reflectors further reduces the number of BGP adjacencies maintained
> > 	   by a PE to exchange VPN routing information with other PEs. This
> > 	   document describes various options for exchanging MVPN control
> > 	   information between PE routers based on the use of PIM or BGP. These
> > 	   options have different overheads with respect to the number of
> > 	   routing adjacencies that a PE router needs to maintain to exchange
> > 	   MVPN control information with other PE routers. Some of these options
> > 	   allow the retention of the unicast BGP/MPLS VPN model letting a PE
> > 	   maintain at most one routing adjacency with other PE routers to
> > 	   exchange MVPN control information.
> > 
> > 	   The solution in [RFC4364] uses BGP to exchange VPN routing
> > 	   information between PE routers. This document describes various
> > 	   solutions for exchanging MVPN control information. One option is the
> > 	   use of BGP, providing reliable transport. Another option is the use
> > 	   of the currently existing, "soft state" PIM standard [PIM-SM].
> > 
> > 	BD>> The second paragraph mostly just repeats statements from the
> > 	first, and seems to be an editing mistake. I suggest you delete the second
> > 	para, and optionally add the few extra words about reliable transport
> > 	and soft state into the middle of the first para.
> > 
> > 	[...]
> > 	3.1. PE-CE Multicast Routing
> > 	[...]
> > 
> > 	   If a PE attaches to n VPNs for which multicast support is provided
> > 	   (i.e., to n "MVPNs"), the PE will run n independent instances of a
> > 	   multicast routing protocol.  We will refer to these multicast routing
> > 	   instances as "VPN-specific multicast routing instances", or more
> > 	   briefly as "multicast C-instances".
> > 
> > 	BD>> Since you are using the "C-foo" terminology for the first time,
> > 	it might be good, either here or earlier in the doc, to explain what
> > 	C-foo and P-foo mean.
> > 
> > 	[...]
> > 	   In order to support the "Carrier's Carrier" model of [RFC4364], mLDP
> > 	   or BGP will also be supported on the PE-CE interface; however, this
> > 	   is not described in this revision.
> > 
> > 	BD>> If, as I expect, you're not going to cover it in a later
> > 	revision either, you might want to say something more like "this is
> > 	for further study".
> > 
> > 
> > 
> > 
> > 	3.2. P-Multicast Service Interfaces (PMSIs)
> > 
> > 	   Multicast data packets received by a PE over a PE-CE interface must
> > 	   be forwarded to one or more of the other PEs in the same MVPN for
> > 	   delivery to one or more other CEs.
> > 
> > 	   We define the notion of a "P-Multicast Service Interface" (PMSI).  If
> > 	   a particular MVPN is supported by a particular set of PE routers,
> > 	   then there will be a PMSI connecting those PE routers.  A PMSI is a
> > 	   conceptual "overlay" on the P network with the following property: a
> > 	   PE in a given MVPN can give a packet to the PMSI, and the packet will
> > 	   be delivered to some or all of the other PEs in the MVPN, such that
> > 	   any PE receiving such a packet will be able to tell which MVPN the
> > 	   packet belongs to.
> > 
> > 	   As we discuss below, a PMSI may be instantiated by a number of
> > 	   different transport mechanisms, depending on the particular
> > 	   requirements of the MVPN and of the SP.  We will refer to these
> > 	   transport mechanisms as "tunnels".
> > 	[...]
> > 
> > 	3.2.1. Inclusive and Selective PMSIs
> > 
> > 	   We will distinguish between three different kinds of PMSI:
> > 
> > 	     - "Multidirectional Inclusive" PMSI (MI-PMSI)
> > 
> > 	       A Multidirectional Inclusive PMSI is one which enables ANY PE
> > 	       attaching to a particular MVPN to transmit a message such that it
> > 	       will be received by EVERY other PE attaching to that MVPN.
> > 
> > 	       There is at most one MI-PMSI per MVPN.  (Though the tunnel which
> > 	       instantiates an MI-PMSI may actually carry the data of more than
> > 	       one PMSI.)
> > 
> > 	BD>> I think that should be "the tunnel or tunnels that instantiate..."
> > 
> > 	       An MI-PMSI can be thought of as an overlay broadcast network
> > 	       connecting the set of PEs supporting a particular MVPN.
> > 
> > 	       [The "Default MDTs" of rosen-08 provide the transport service of
> > 	       MI-PMSIs, in this terminology.]
> > 
> > 	     - "Unidirectional Inclusive" PMSI (UI-PMSI)
> > 
> > 	       A Unidirectional Inclusive PMSI is one which enables a particular
> > 	       PE, attached to a particular MVPN, to transmit a message such
> > 	       that it will be received by all the other PEs attaching to that
> > 	       MVPN.  There is at most one UI-PMSI per PE per MVPN, though the
> > 	       "tunnel" which instantiates a UI-PMSI may in fact carry the data
> > 	       of more than one PMSI.
> > 
> > 	BD>> Again, shouldn't that be "tunnel or tunnels"? And why did you put
> > 	it in quotes here?
> > 
> > 	     - "Selective" PMSI (S-PMSI).
> > 
> > 	       A Selective PMSI is one which provides a mechanism wherein a
> > 	       particular PE in an MVPN can multicast messages so that they will
> > 	       be received by a subset of the other PEs of that MVPN.  There may
> > 	       be an arbitrary number of S-PMSIs per PE per MVPN.  Again, the
> > 	       "tunnel" which instantiates a given S-PMSI may carry data from
> > 	       multiple S-PMSIs.
> > 
> > 	BD>> See previous comment.
> > 
> > 	       [The "Data MDTs" of earlier drafts provide the transport service
> > 	       of "Selective PMSIs" in the terminology of this draft.]
> > 
> > 	   We will see in later sections the role played by these different
> > 	   kinds of PMSI.  We will use the term "I-PMSI" when we are not
> > 	   distinguishing between "MI-PMSIs" and "UI-PMSIs".
> > 
> > 
> > 	BD>> I wonder if you plan to remove the parenthetical references to
> > 	"draft-rosen" and "earlier drafts"?
> > 
> > 	BD>> Whether or not those parenthetical comments are removed, it might
> > 	be good to give a quick example of what each of the 3 PMSI types is
> > 	good for, just to help the reader get a grasp of the terms.
> > 
> > 
> > 
> > 	3.2.2. Tunnels Instantiating PMSIs
> > 	[...]
> > 
> > 	       Selective PMSIs are most instantiated by source P-trees, and are
> > 	       most naturally created by PIM-SSM, since by definition only one
> > 	       PE is the source of the multicast data on a Selective PMSI.
> > 
> > 	BD>> most -> mostly?
> > 
> > 	       [The "Default MDTs" of [rosen-08] are MI-PMSIs instantiated as
> > 	       PIM trees.  The "data MDTs" of [rosen-08] are S-PMSIs
> > 	       instantiated as PIM trees.]
> > 
> > 	     - MLDP
> > 
> > 	BD>> I noticed there is no MLDP reference in this draft - I think you
> > 	want to make a reference to draft-ietf-mpls-ldp-p2mp-03.txt.
> > 
> > 	       A PMSI may be instantiated as one or more mLDP Point-to-
> > 	       Multipoint (P2MP) LSPs, or as an mLDP Multipoint-to-Point(MP2MP)
> > 	       LSP.
> > 
> > 	BD>> Should that be Multipoint-to-multipoint?
> > 
> > 	       A Selective PMSI or a Unidirectional Inclusive PMSI would
> > 	       be instantiated as a single mLDP P2MP LSP, whereas a
> > 	       Multidirectional Inclusive PMSI could be instantiated either as a
> > 	       set of such LSPs (one for each PE in the MVPN) or as a single
> > 	       M2PMP LSP.
> > 	BD>> That should be ... "MP2MP LSP."
> > 
> > 
> > 	       MLDP P2MP LSPs can be shared across multiple MVPNs.
> > 
> > 	BD>> That comment makes me wonder whether PIM tunnels could also be
> > 	shared across multiple MVPNs, since you didn't say whether they could
> > 	or not. You should probably make this point explicity (whichever way it turns
> > 	out). The sentence also leaves it unclear as to whether MP2MP LSPs can
> > 	be shared.
> > 
> > 	     - RSVP-TE
> > 
> > 	       A PMSI may be instantiated as one or more RSVP-TE Point-to-
> > 	       Multipoint (P2MP) LSPs.  A Selective PMSI or a Unidirectional
> > 	       Inclusive PMSI would be instantiated as a single RSVP-TE P2MP
> > 	       LSP, whereas a Multidirectional Inclusive PMSI would be
> > 
> > 	BD>> You seem to be inconsistent in choosing whether to use Selective
> > 	PMSI or S-PMSI. I think it would be more readable if you stuck to the
> > 	shorter form throughout.
> > 
> > 	[...]
> > 	   The choice of the tunnel technique belongs to the sender router and
> > 	   is a local policy decision of the router. The procedures defined
> > 	   throughout this document do not mandate that the same tunnel
> > 	   technique be used for all PMSI tunnels going through a same provider
> > 	   backbone.
> > 
> > 	BD>> "a same" -> "a given"
> > 
> > 	   It is however expected that any tunnel technique that can
> > 	   be subject to being used by a PE for a particular MVPN is also
> > 	   supported by other PE having VRFs for the MVPN.
> > 
> > 	BD>> How about deleting "subject to being"
> > 
> > 	   Moreover, the use of
> > 	   ingress replication by any PE for an MVPN, implies that all other PEs
> > 	   MUST use ingress replication for this MVPN.
> > 
> > 	BD>> I don't see why that is true. Can you add a line of explanation?
> > 
> > 	[...]
> > 	3.3.1. MVPNs with Default MI-PMSIs
> > 	[...]
> > 
> > 	   If a particular multicast stream from a particular source PE has
> > 	   certain characteristics, it can be desirable to migrate it from the
> > 	   MI-PMSI to an S-PMSI.
> > 
> > 	BD>> Can you give an example of what the "certain characterstics"
> > 	   might be?
> > 
> > 	[...]
> > 	3.3.3. MVPNs That Do Not Use MI-PMSIs
> > 
> > 	   If a particular MVPN does not use a default MI-PMSI, then its
> > 	   multicast data may be sent by default on a UI-PMSI.
> > 
> > 	   It is also possible to send all the multicast data on an S-PMSI,
> > 	   omitting any usage of I-PMSIs.
> > 
> > 	BD>> Shouldn't that be "a set of S-PMSIs" ?
> > 
> > 	[...]
> > 	3.4.1.3. Unicasting of PIM C-Join/Prune Messages
> > 
> > 	[...]
> > 
> > 	   Procedures for unicasting the PIM control messages are not further
> > 	   specified in this document.
> > 
> > 	BD>>It seems like you haven't provided enough information to enable
> > 	this method to be used; you've just sketched a "road not taken". Do
> > 	you think it would be better just to cut this section or move it to an
> > 	appendix?
> > 
> > 
> > 
> > 	3.4.2. Using BGP to Carry C-Multicast Routing
> > 
> > 	   It is possible to use BGP to carry C-multicast routing information
> > 	   from PE to PE, dispensing entirely with the transmission of C-
> > 	   Join/Prune messages from PE to PE. This is specified in section 5.3.
> > 	   Inter-AS procedures are described in section 8.
> > 
> > 	BD>> For the sake of clarity, this might be a good time to point out
> > 	   that using BGP to carrying C-routes and using BGP to perform
> > 	   autodiscovery are two completely separable tasks.
> > 
> > 	4. BGP-Based Autodiscovery of MVPN Membership
> > 	[...]
> > 	     - PMSI tunnel attribute.  This attribute is present if and only if
> > 	       a default MI-PMSI is to be used for the MVPN.  It contains the
> > 	       following information:
> > 	[...]
> > 	         * If the PE wishes to setup a default tunnel to instantiate the
> > 	           I-PMSI, a unique identifier for the tunnel used to
> > 	           instantiate the I-PMSI.
> > 
> > 	BD>> Can you give an example of such an identifier? Could it be, for
> > 	           example, the group address of PIM tree?
> > 
> > 	           All the PEs attaching to a given MVPN (within a given AS)
> > 	           must have been configured with the same PMSI tunnel attribute
> > 	           for that MVPN.  They are also expected to know the
> > 	           encapsulation to use.
> > 
> > 	           Note that a default tunnel can be identified at discovery
> > 	           time only if the tunnel already exists (e.g., it was
> > 	           constructed by means of configuration), or if it can be
> > 	           constructed without each PE knowing the the identities of all
> > 	           the others (e.g., it is constructed by a receiver-initiated
> > 	           join technique such as PIM or mLDP).
> > 
> > 	BD>> It would be helpful to explain why that proceeding statement is true.
> > 
> > 	           In other cases, a default tunnel cannot be identified until
> > 	           the PE has discovered one or more of the other PEs.  This
> > 	           will be the case, for example, if the tunnel is an RSVP-TE
> > 	           P2MP LSP, which must be set up from the head end.  In these
> > 	           cases, a PE will first send an A-D route without a tunnel
> > 	           identifier, and then will send another one with a tunnel
> > 	           identifier after discovering one or more of the other PEs.
> > 
> > 	           All the PEs attaching to a given MVPN must be configured with
> > 	           information specifying the encapsulation to use.
> > 
> > 	BD>> must -> MUST ?
> > 
> > 
> > 	         * Whether the tunnel used to instantiate the I-PMSI for this
> > 	           MVPN is aggregating I-PMSIs from multiple MVPNs.  This will
> > 	           affect the encapsulation used.  If aggregation is to be used,
> > 	           a demultiplexor value to be carried by packets for this
> > 	           particular MVPN must also be specified.  The demultiplexing
> > 	           mechanism and signaling procedures are described in section
> > 	           6.
> > 
> > 	       Further details of the use of this information are provided in
> > 	       subsequent sections.
> > 
> > 	       Sometimes it is necessary for one PE to advertise an upstream-
> > 	       assigned MPLS label that identifies another PE.  Under certain
> > 	       circumstances to be discussed later, a PE which is the root of a
> > 	       multicast P-tunnel will bind an MPLS label value to one or more
> > 	       of the PEs that belong to the P-tunnel, and will distribute these
> > 	       label bindings using A-D routes. The precise details of this
> > 	       label distribution will be included in the next revision of this
> > 	       document.  We will refer to these as "PE Labels".  A packet
> > 	       traveling on the P-tunnel may carry one of these labels as an
> > 	       indication that the PE corresponding to that label is special.
> > 	       See section 11.3 for more details.
> > 
> > 
> > 	5. PE-PE Transmission of C-Multicast Routing
> > 
> > 	   As a PE attached to a given MVPN receives C-Join/Prune messages from
> > 	   its CEs in that MVPN, it must convey the information contained in
> > 	   those messages to other PEs that are attached to the same MVPN.  This
> > 	   is known as the "PE-PE transmission of C-multicast routing
> > 	   information".
> > 
> > 	   This section specifies the procedures used for PE-PE transmission of
> > 	   C-multicast routing information.  Not every procedure mentioned in
> > 	   section 3.4 is specified here.  Rather, this section focuses on two
> > 	   particular procedures:
> > 
> > 
> > 
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 24]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	     - Full PIM Peering.
> > 
> > 	       This procedure is fully specified herein.
> > 
> > 	     - Use of BGP to distribute C-multicast routing
> > 
> > 	       This procedure is described herein, but the full specification
> > 	       appears in [MVPN-BGP].
> > 
> > 	   Those aspect of the procedures which apply to both of the above are
> > 	   also specified fully herein.
> > 
> > 	   Specification of other procedures is for future study.
> > 
> > 
> > 	5.1. Selecting the Upstream Multicast Hop (UMH)
> > 
> > 	   When a PE receives a C-Join/Prune message from a CE, the message
> > 	   identifies a particular multicast flow as belonging either to a
> > 	   source tree (S,G) or to a shared tree (*,G).  We use the term C-
> > 	   source to refer to S, in the case of a source tree, or to the
> > 	   Rendezvous Point (RP) for G, in the case of (*,G).  If the route to
> > 	   the C-source is across the VPN backbone, then the PE needs to find
> > 	   the "upstream multicast hop" (UMH) for the (S,G) or (*,G) flow. The
> > 	   "upstream multicast hop" is either the PE at which (S,G) or (*,G)
> > 	   data packets enter the VPN backbone, or else is the Autonomous System
> > 	   Border Router (ASBR) at which those data packets enter the local AS
> > 	   when traveling through the VPN backbone.  The process of finding the
> > 	   upstream multicast hop for a given C-source is known as "upstream
> > 	   multicast hop selection".
> > 
> > 
> > 	5.1.1. Eligible Routes for UMH Selection
> > 
> > 	   In the simplest case, the PE does the upstream hop selection by
> > 	   looking up the C-source in the unicast VRF associated with the PE-CE
> > 	   interface over which the C-Join/Prune was received.  The route that
> > 	   matches the C-source will contain the information needed to select
> > 	   the upstream multicast hop.
> > 
> > 	   However, in some cases, the CEs may be distributing to the PEs a
> > 	   special set of routes that are to be used exclusively for the purpose
> > 	   of upstream multicast hop selection, and not used for unicast routing
> > 	   at all.  For example, when BGP is the CE-PE unicast routing protocol,
> > 	   the CEs may be using SAFI 2 to distribute a special set of routes
> > 	   that are to be used for, and only for, upstream multicast hop
> > 	   selection.  When OSPF is the CE-PE routing protocol, the CE may use
> > 	   an MT-ID of 1 to distribute a special set of routes that are to be
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 25]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	   used for, and only for, upstream multicast hop selection .  When a CE
> > 	   uses one of these mechanisms to distribute to a PE a special set of
> > 	   routes to be used exclusively for upstream multicast hop selection,
> > 	   these routes are distributed among the PEs using SAFI 129, as
> > 	   described in [MVPN-BGP].
> > 
> > 	   Whether the routes used for upstream multicast hop selection are (a)
> > 	   the "ordinary" unicast routes or (b) a special set of routes that are
> > 	   used exclusively for upstream multicast hop selection, is a matter of
> > 	   policy.  How that policy is chosen, deployed, or implemented is
> > 	   outside the scope of this document.  In the following, we will simply
> > 	   refer to the set of routes that are used for upstream multicast hop
> > 	   selection, the "Eligible UMH routes", with no presumptions about the
> > 	   policy by which this set of routes was chosen.
> > 
> > 
> > 	5.1.2. Information Carried by Eligible UMH Routes
> > 
> > 	   Every route which is eligible for UMH selection MUST carry a VRF
> > 	   Route Import Extended Community [MVPN-BGP].  This attribute
> > 	   identifies the PE that originated the route.
> > 
> > 	   If BGP is used for carrying C-multicast routes, OR if "Segmented
> > 	   Inter-AS Tunnels" (see section 8.2) are used, then every UMH route
> > 	   MUST also carry a Source AS Extended Community [MVPN-BGP].
> > 
> > 	   These two attributes are used in the upstream multicast hop selection
> > 	   procedures described below.
> > 
> > 
> > 	5.1.3. Selecting the Upstream PE
> > 
> > 	   The first step in selecting the upstream multicast hop for a given C-
> > 	   source is to select the upstream PE router for that C-source.
> > 
> > 	   The PE that received the C-Join message from a CE looks in the VRF
> > 	   corresponding to the interfaces over which the C-Join was received.
> > 	   It finds the Eligible UMH route which is the best match for the C-
> > 	   source specified in that C-Join.  Call this the "Installed UMH
> > 	   Route".
> > 
> > 	   Note that the outgoing interface of the Installed UMH Route may be
> > 	   one of the interfaces associated with the VRF, in which case the
> > 	   upstream multicast hop is a CE and the route to the C-source is not
> > 	   across the VPN backbone.
> > 
> > 	   Consider the set of all VPN-IP routes that are: (a) eligible to be
> > 	   imported into the VRF (as determined by their Route Targets), (b) are
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 26]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	   eligible to be used for upstream multicast hop selection, and (c)
> > 	   have exactly the same IP prefix (not necessarily the same RD) as the
> > 	   installed UMH route.
> > 
> > 	   For each route in this set, determine the corresponding upstream PE
> > 	   and upstream RD.  If a route has a VRF Route Import Extended
> > 	   Community, the route's upstream PE is determined from it. If a route
> > 	   does not have a VRF Route Import Extended Community, the route's
> > 	   upstream PE is determined from the route's BGP next hop attribute.
> > 	   In either case, the upstream RD is taken from the route's NLRI.
> > 
> > 	   This results in a set of pairs of <route, upstream PE, upstream RD>.
> > 	   If the Installed UMH Route is not already in this set, it is added to
> > 	   the set.  Call this the "UMH Route Candidate Set."  Then the PE MUST
> > 	   select a single route from the set to be the "Selected UMH Route".
> > 	   The corresponding upstream PE is known as the "Selected Upstream PE",
> > 	   and the corresponding upstream RD is known as the "Selected Upstream
> > 	   RD".
> > 
> > 	   There are several possible procedures that can be used by a PE to
> > 	   select a single route from the candidate set.
> > 
> > 	   The default procedure, which MUST be implemented, is to select the
> > 	   route whose corresponding upstream PE address is numerically highest,
> > 	   where a 32-bit IP address is treated as a 32 bit unsigned integer.
> > 	   Call this the "default upstream PE selection".  For a given C-source,
> > 	   provided that the routing information used to create the candidate
> > 	   set is stable, all PEs will have the same default upstream PE
> > 	   selection.  (Though different default upstream PE selections may be
> > 	   chosen during a routing transient.)
> > 
> > 	   An alternative procedure which MUST be implemented, but which is
> > 	   disabled by default, is the following.  This procedure ensures that,
> > 	   except during a routing transient, each PE chooses the same upstream
> > 	   PE for a given combination of C-source and C-G.
> > 
> > 	      1. The PEs in the candidate set are numbered from lower to higher
> > 	         IP address, starting from 0.
> > 
> > 	      2. The following hash is performed:
> > 
> > 	           - A bytewise exclusive-or of all the bytes in the C-source
> > 	             address and the C-G address is performed.
> > 
> > 	           - The result is taken modulo n, where n is the number of PEs
> > 	             in the candidate set.  Call this result N.
> > 
> > 	   The selected upstream PE is then the one that appears in position N
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 27]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	   in the list of step 1.
> > 
> > 	   Other hashing algorithms are allowed as well, but not required.
> > 
> > 	   The alternative procedure allows a form of "equal cost load
> > 	   balancing".  Suppose, for example, that from egress PEs PE3 and PE4,
> > 	   source C-S can be reached, at equal cost, via ingress PE PE1 or
> > 	   ingress PE PE2.  The load balancing procedure makes it possible for
> > 	   PE1 to be the ingress PE for (C-S, C-G1) data traffic while PE2 is
> > 	   the ingress PE for (C-S, C-G2) data traffic.
> > 
> > 
> > 	5.1.4. Selecting the Upstream Multicast Hop
> > 
> > 	   In certain cases, the selected upstream multicast hop is the same as
> > 	   the selected upstream PE.  In other cases, the selected upstream
> > 	   multicast hop is the ASBR which is the "BGP next hop" of the Selected
> > 	   UMH Route.
> > 
> > 	   If the selected upstream PE is in the local AS, then the selected
> > 	   upstream PE is also the selected upstream multicast hop.  This is the
> > 	   case if any of the following conditions holds:
> > 
> > 	     - The selected UMH route has a Source AS Extended Community, and
> > 	       the Source AS is the same as the local AS,
> > 
> > 	     - The selected UMH route does not have a Source AS Extended
> > 	       Community, but the route's BGP next hop is the same as the
> > 	       upstream PE.
> > 
> > 	   Otherwise, the selected upstream multicast hop is an ASBR.  The
> > 	   method of determining just which ASBR it is depends on the particular
> > 	   inter-AS signaling method being used (PIM or BGP), and on whether
> > 	   segmented or non-segmented inter-AS tunnels are used.  These details
> > 	   are presented in later sections.
> > 
> > 
> > 	5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI
> > 
> > 	   In this section, we assume that inter-AS MVPNs will be supported by
> > 	   means of non-segmented inter-AS trees.  Support for segmented inter-
> > 	   AS trees with PIM peering is for further study.
> > 
> > 	   When an MVPN uses an MI-PMSI, the C-instances of that MVPN can treat
> > 	   the MI-PMSI as a LAN interface, and form either full PIM adjacencies
> > 	   with each other over that "LAN interface".
> > 
> > 	   To form a full PIM adjacency, the PEs execute the PIM LAN procedures,
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 28]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	   including the generation and processing of PIM Hello, Join/Prune,
> > 	   Assert, DF election and other PIM control packets.  These are
> > 	   executed independently for each C-instance.  PIM "join suppression"
> > 	   SHOULD be enabled.
> > 
> > 
> > 
> > 	5.2.1. PIM C-Instance Control Packets
> > 
> > 	   All PIM C-Instance control packets of a particular MVPN are addressed
> > 	   to the ALL-PIM-ROUTERS (224.0.0.13) IP destination address, and
> > 	   transmitted over the MI-PMSI of that MVPN.  While in transit in the
> > 	   P-network, the packets are encapsulated as required for the
> > 	   particular kind of tunnel that is being used to instantiate the MI-
> > 	   PMSI.  Thus the C-instance control packets are not processed by the P
> > 	   routers, and MVPN-specific PIM routes can be extended from site to
> > 	   site without appearing in the P routers.
> > 
> > 	   As specified in section 5.1.2, when a PE distributes VPN-IP routes
> > 	   which are eligible for use as UMH routes, the PE MUST include a VRF
> > 	   Route Import Extended Community with each route.  For a given MVPN, a
> > 	   single such IP address MUST be used, and that same IP address MUST be
> > 	   used as the source address in all PIM control packets for that MVPN.
> > 
> > 
> > 	5.2.2. PIM C-instance RPF Determination
> > 
> > 	   Although the MI-PMSI is treated by PIM as a LAN interface, unicast
> > 	   routing is NOT run over it, and there are no unicast routing
> > 	   adjacencies over it.  It is therefore necessary to specify special
> > 	   procedures for determining when the MI-PMSI is to be regarded as the
> > 	   "RPF Interface" for a particular C-address.
> > 
> > 	   The PE follows the procedures of section 5.1 to determine the
> > 	   selected UMH route.  If that route is NOT a VPN-IP route learned from
> > 	   BGP as described in [RFC4364], or if that route's outgoing interface
> > 	   is one of the interfaces associated with the VRF, then ordinary PIM
> > 	   procedures for determining the RPF interface apply.
> > 
> > 	   However, if the selected UMH route is a VPN-IP route whose outgoing
> > 	   interface is not one of the interfaces associated with the VRF, then
> > 	   PIM will consider the RPF interface to be the MI-PMSI associated with
> > 	   the VPN-specific PIM instance.
> > 
> > 	   Once PIM has determined that the RPF interface for a particular C-
> > 	   source is the MI-PMSI, it is necessary for PIM to determine the "RPF
> > 	   neighbor" for that C-source.  This will be one of the other PEs that
> > 	   is a PIM adjacency over the MI-PMSI.  In particular, it will be the
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 29]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	   "selected upstream PE" as defined in section 5.1.
> > 
> > 
> > 	5.2.3. Backwards Compatibility
> > 
> > 	   There are older implementations which do not use the VRF Route Import
> > 	   Extended Community or any explicit mechanism for carrying information
> > 	   to identify the originating PE of a selected UMH route.
> > 
> > 	   For backwards compatibility, when the selected UMH route does not
> > 	   have any such mechanism, the IP address from the "BGP Next Hop" field
> > 	   of the selected UMH route will be used as the selected UMH address,
> > 	   and will be treated as the address of the upstream PE.  There is no
> > 	   selected upstream RD in this case.  However, use of this backwards
> > 	   compatibility technique presupposes that:
> > 
> > 	     - The PE which originated the selected UMH route placed the same IP
> > 	       address in the BGP Next Hop field that it is using as the source
> > 	       address of the PE-PE PIM control packets for this MVPN.
> > 
> > 	     - The MVPN is not an Inter-AS MVPN that uses option b from section
> > 	       10 of [RFC4364].
> > 
> > 	   Should either of these conditions fail, interoperability with the
> > 	   older implementations will not be achieved.
> > 
> > 
> > 	5.3. Use of BGP for Carrying C-Multicast Routing
> > 
> > 	   It is possible to use BGP to carry C-multicast routing information
> > 	   from PE to PE, dispensing entirely with the transmission of C-
> > 	   Join/Prune messages from PE to PE. This section describes the
> > 	   procedures for carrying intra-AS multicast routing information.
> > 	   Inter-AS procedures are described in section 8.  The complete
> > 	   specification of both sets of procedures and of the encodings can be
> > 	   found in [MVPN-BGP].
> > 
> > 
> > 	5.3.1. Sending BGP Updates
> > 	[...]
> > 	   Whenever a C-multicast route is sent, it must also carry, in a Route
> > 	   Target Extended Community, the Selected Upstream Multicast Hop
> > 	   corresponding to the C-source address (determined by the procedures
> > 	   of section 5.1). The selected upstream multicast hop is identified in
> > 	   an Extended Community attribute to facilitate the optional use of
> > 	   filters which can prevent the distribution of the update to BGP
> > 	   speakers other than the upstream multicast hop.  See section 10.1.3
> > 	   of [MVPN-BGP] for the details.
> > 
> > 	BD>> This sounded weird to me when I read it, so I went and looked at
> > 	[MVPN-BGP]. I think it might be easier on the reader if you said
> > 	something like this:
> > 	   "Whenever a C-multicast route is sent, it must also carry the
> > 	   Selected Upstream Multicast Hop
> > 	   corresponding to the C-source address (determined by the procedures
> > 	   of section 5.1). The selected upstream multicast hop must be
> > 	   encoded as a Route Target Extended Community, to facilitate..."
> > 
> > 	[...]
> > 	6.3. Aggregation
> > 
> > 	   A P-multicast tree can be used to instantiate a PMSI service for only
> > 	   one MVPN or for more than one MVPN. When a P-multicast tree is shared
> > 	   across multiple MVPNs it is termed an Aggregate Tree [RAGGARWA-
> > 	   MCAST].
> > 	BD>> There doesn't seem to be much point in including that reference
> > 	   to an ID that will likely disappear.
> > 
> > 
> > 
> > 
> > 	6.3.1. Aggregate Tree Leaf Discovery
> > 
> > 	   BGP MVPN membership discovery allows a PE to determine the different
> > 	   Aggregate Trees that it should create and the MVPNs that should be
> > 	   mapped onto each such tree. The leaves of an Aggregate Tree are
> > 	   determined by the PEs, supporting aggregation, that belong to all the
> > 	   MVPNs that are mapped onto the tree.
> > 
> > 	   If an Aggregate Tree is used to instantiate one or more S-PMSIs, then
> > 	   it may be desirable for the PE at the root of the tree to know which
> > 	   PEs (in its MVPN) are receivers on that tree.  This enables the PE to
> > 	   decide when to aggregate two S-PMSIs, based on congruence (as
> > 	   discussed in the next section).  Thus explicit tracking may be
> > 	   required.  Since the procedures for disseminating C-multicast routes
> > 	   do not provide explicit tracking, a type of A-D route known as a
> > 	   "Leaf A-D Route" is used.  The PE which wants to assign a particular
> > 	   C-multicast flow to a particular Aggregate Tree can send an A-D route
> > 	   which elicits Leaf A-D routes from the PEs that need to receive that
> > 	   C-multicast flow.  This provides the explicit tracking information
> > 	   needed to support the aggregation methodology discussed in the next
> > 	   section.
> > 
> > 	BD>> For consistency, it would be good if this doc and its companion
> > 	draft-ietf-l3vpn-2547bis-mcast-bgp-04.txt used the same term for Leaf
> > 	A-D routes (which are called leaf auto-discovery routes throughout the
> > 	other doc). I also found it a bit odd that the specification of Leaf
> > 	A-D routes in the companion doc appears in the section on Inter-AS
> > 	operations, even though here they seem to be useful in intra-AS
> > 	operation. You might also want to make an explicit reference to the
> > 	companion doc here, as the leaf A-D routes seemed particularly opaque
> > 	to me without going to the other doc.
> > 
> > 	[...]
> > 	6.3.4. Demultiplexing C-multicast traffic
> > 
> > 	   When multiple MVPNs are aggregated onto one P-Multicast tree,
> > 	   determining the tree over which the packet is received is not
> > 	   sufficient to determine the MVPN to which the packet belongs.  The
> > 	   packet must also carry some demultiplexing information to allow the
> > 	   egress PEs to determine the MVPN to which the packet belongs.  Since
> > 	   the packet has been multicast through the P network, any given
> > 	   demultiplexing value must have the same meaning to all the egress
> > 	   PEs.  The demultiplexing value is a MPLS label that corresponds to
> > 	   the multicast VRF to which the packet belongs. This label is placed
> > 	   by the ingress PE immediately beneath the P-Multicast tree header.
> > 	   Each of the egress PEs must be able to associate this MPLS label with
> > 	   the same MVPN.  If downstream label assignment were used this would
> > 	   require all the egress PEs in the MVPN to agree on a common label for
> > 	   the MVPN. Instead the MPLS label is upstream assigned [MPLS-UPSTREAM-
> > 	   LABEL]. The label bindings are advertised via BGP updates originated
> > 	   the ingress PEs.
> > 
> > 	   This procedure requires each egress PE to support a separate label
> > 	   space for every other PE. The egress PEs create a forwarding entry
> > 	   for the upstream assigned MPLS label, allocated by the ingress PE, in
> > 	   this label space. Hence when the egress PE receives a packet over an
> > 	   Aggregate Tree, it first determines the tree that the packet was
> > 	   received over. The tree identifier determines the label space in
> > 	   which the upstream assigned MPLS label lookup has to be performed.
> > 	   The same label space may be used for all P-multicast trees rooted at
> > 	   the same ingress PE, or an implementation may decide to use a
> > 	   separate label space for every P-multicast tree.
> > 
> > 	BD>>
> > 	When I first read this section, I found myself wondering what would
> > 	happen if you have P-multicast trees that are not rooted at
> > 	a PE (e.g. a PIM shared tree). The above text seemed to
> > 	assume that ingress PE = root of P tree. Then, as I read on to section
> > 	6.6, I see that you do say that
> > 	aggregation support for BIDIR trees is for further study. Perhaps you
> > 	should say that here too. Also a forward reference to 6.6 to say that
> > 	the label allocation for shared trees is addressed there would help
> > 	the reader understand the above text more readily.
> > 
> > 	[...]
> > 
> > 
> > 
> > 
> > 
> > 	7.1. S-PMSI Instantiation Using Ingress Replication
> > 
> > 	   As described in section 6.1.1, ingress replication can be used to
> > 	   instantiate a UI-PMSI. However this can result in a PE receiving
> > 	   packets for a multicast group for which it doesn't have any
> > 	   receivers. This can be avoided if the ingress PE tracks the remote
> > 	   PEs which have receivers in a particular C-multicast group.  In order
> > 	   to do this it needs to receive C-Joins from each of the remote PEs.
> > 	   It then replicates the C-multicast data packet and sends it to only
> > 	   those egress PEs which are on the path to a receiver of that
> > 	   C-group.
> > 
> > 	BD>> This seems like a lot of extraneous text about UI-PMSIs in a
> > 	   section that is ostensibly about S-PMSIs.
> > 
> > 
> > 	7.2.1.2. Packet Formats and Constants
> > 
> > 	[...]
> > 
> > 	   Currently only one type of S-PMSI Join is defined.  A type 1 S-PMSI
> > 	   Join is used when the S-PMSI tunnel is a PIM tunnel which is used to
> > 	   carry a single multicast stream, where the packets of that stream
> > 	   have IPv4 source and destination IP addresses.
> > 
> > 	BD>> I'm sure you'll be adding a type for when the stream consists of
> > 	IPv6 packets in a future version,
> > 	right? And you'll also be specifying how to use something other than a
> > 	PIM tunnel for this purpose? OR when the PIM tunnel is identified by a
> > 	v6 address?
> > 	Also, when you get around to writing the IANA considerations, this Type
> > 	field will need to be given its own registry.
> > 
> > 
> > 
> > 
> > 	        0                   1                   2                   3
> > 	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > 	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 	       |     Type      |           Length            |    Reserved     |
> > 	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 	       |                           C-source                            |
> > 	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 	       |                           C-group                             |
> > 	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 	       |                           P-group                             |
> > 	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 	[...]
> > 
> > 
> > 
> > 	7.4. Instantiating the S-PMSI with a PIM Tree
> > 
> > 	   The procedures of section 7.3 tell a PE when it must start
> > 	   listening
> > 	>>BD I think you mean 7.2?
> > 
> > 	   and stop listening to a particular S-PMSI.  Those procedures also
> > 	   specify the method for instantiating the S-PMSI.  In this section, we
> > 	   provide the procedures to be used when the S-PMSI is instantiated as
> > 	   a PIM tree.  The PIM tree is created by the PIM P-instance.
> > 
> > 	   If a single PIM tree is being used to aggregate multiple S-PMSIs,
> > 	   then the PIM tree to which a given stream is bound may have already
> > 	   been joined by a given receiving PE.  If the tree does not already
> > 	   exist, then the appropriate PIM procedures to create it must be
> > 	   executed in the P-instance.
> > 
> > 	   If the S-PMSI for a particular multicast stream is instantiated as a
> > 	   PIM-SM or BIDIR-PIM tree, the S-PMSI identifier will specify the RP
> > 	   and the group P-address, and the PE routers which have receivers for
> > 	   that stream must build a shared tree toward the RP.
> > 
> > 	   If the S-PMSI is instantiated as a PIM-SSM tree, the PE routers build
> > 	   a source tree toward the PE router that is advertising the S-PMSI
> > 	   Join.  The IP address root of the tree is the same as the source IP
> > 	   address which appears in the S-PMSI Join.  In this case, the tunnel
> > 	   identifier in the S-PMSI Join will only need to specify a group P-
> > 	   address.
> > 
> > 	   The above procedures assume that each PE router has a set of group P-
> > 	   addresses that it can use for setting up the PIM-trees.  Each PE must
> > 	   be configured with this set of P-addresses.  If PIM-SSM is used to
> > 	   set up the tunnels, then the PEs may be with overlapping sets of
> > 	   group P-addresses.
> > 	BD>> Missing word after "may be"... configured?
> > 
> > 	 If PIM-SSM is not used, then each PE must be
> > 	   configured with a unique set of group P-addresses (i.e., having no
> > 	   overlap with the set configured at any other PE router).  The
> > 	   management of this set of addresses is thus greatly simplified when
> > 	   PIM-SSM is used, so the use of PIM-SSM is strongly recommended
> > 	   whenever PIM trees are used to instantiate S-PMSIs.
> > 
> > 	   If it is known that all the PEs which need to receive data traffic on
> > 	   a given S-PMSI can support aggregation of multiple S-PMSIs on a
> > 	   single PIM tree, then the transmitting PE, may, at its discretion,
> > 	   decide to bind the S-PMSI to a PIM tree which is already bound to one
> > 	   or more other S-PMSIs, from the same or from different MVPNs.  In
> > 	   this case, appropriate demultiplexing information must be signaled.
> > 
> > 	BD>> Suggest a cross-ref to the section where demuxing is described (6.3.4)
> > 	[...]
> > 
> > 	8. Inter-AS Procedures
> > 
> > 	   If an MVPN has sites in more than one AS, it requires one or more
> > 	   PMSIs to be instantiated by inter-AS tunnels.  This document
> > 	   describes two different types of inter-AS tunnel:
> > 
> > 	      1. "Segmented Inter-AS tunnels"
> > 
> > 	         A segmented inter-AS tunnel consists of a number of independent
> > 	         segments which are stitched together at the ASBRs.  There are
> > 	         two types of segment, inter-AS segments and intra-AS segments.
> > 	         The segmented inter-AS tunnel consists of alternating intra-AS
> > 	         and inter-AS segments.
> > 
> > 	         Inter-AS segments connect adjacent ASBRs of different ASes;
> > 	         these "one-hop" segments are instantiated as unicast tunnels.
> > 
> > 	         Intra-AS segments connect ASBRs and PEs which are in the same
> > 	         AS.  An intra-AS segment may be of whatever technology is
> > 	         desired by the SP that administers the that AS.  Different
> > 	         intra-AS segments may be of different technologies.
> > 
> > 	         Note that an intra-AS segment of an inter-AS tunnel is distinct
> > 	         from any intra-AS tunnel in the AS.
> > 
> > 	BD>> I found that statement a bit confusing. I notice that you rely on
> > 	this distinction in Section 9, so maybe it would be helpful to say
> > 	something like this:
> > 
> > 	"Note that the intra-AS segments of inter-AS tunnels
> > 	form a category of tunnels that is distinct from simple intra-AS
> > 	tunnels; we will rely on this distinction later (see Section 9). "
> > 
> > 	8.1.3. Inter-AS P-Tunnels
> > 
> > 	   The procedures described earlier in this document can be used to
> > 	   instantiate either an I-PMSI or an S-PMSI with inter-AS P-tunnels.
> > 	   Specific tunneling techniques require some explanation.
> > 
> > 	   If ingress replication is used, the inter-AS PE-PE tunnels will use
> > 	   the inter-AS tunneling procedures for the tunneling technology used.
> > 
> > 	   Procedures in [RSVP-P2MP] are used for inter-AS RSVP-TE P2MP P-
> > 	   Tunnels.
> > 
> > 	   Procedures for using PIM  to set up the P-tunnels are discussed in
> > 	   the next section.
> > 
> > 	8.1.4. PIM-Based Inter-AS P-Multicast Trees
> > 
> > 	BD>> It seems to me this should be 8.1.3.1, as it is a specific case
> > 	   of inter-AS P-tunnels.
> > 
> > 	[...]
> > 
> > 	8.2. Segmented Inter-AS Tunnels
> > 
> > 	8.2.1. Inter-AS MVPN Auto-Discovery Routes
> > 	[...]
> > 	   This section defines an inter-AS auto-discovery route as a route that
> > 	   carries information about an AS that has one or more PEs (directly)
> > 	   connected to the site(s) of that MVPN. Further it defines an inter-AS
> > 	   leaf auto-discovery route (leaf auto-discovery route) as a route used
> > 	   to inform the root of an intra-AS segment, of an inter-AS tunnel, of
> > 	   a leaf of that intra-AS segment.
> > 
> > 	BD>> It took me several attempts to parse that last sentence. Let me
> > 	make a suggestion for some alternate wording (feel free to try your
> > 	own):
> > 	    Further it defines an inter-AS leaf auto-discovery route in the
> > 	    following way:
> > 	     - Consider a node which is the root of an an intra-AS segment of
> > 	     an inter-AS tunnel. An inter-AS leaf autodiscovery route is used
> > 	     to inform such a node of a leaf of that intra-AS segment.
> > 
> > 	And even if the proposed wording is not correct, then you definitely need
> > 	to reword the original, because that was the only sense I could make
> > 	of it.
> > 
> > 
> > 
> > 	8.2.1.2. Propagating Inter-AS MVPN A-D Information
> > 
> > 	   As an inter-AS auto-discovery route originated by an ASBR within a
> > 	   given AS is propagated via BGP to other ASes, this results in
> > 	   creation of a data plane tunnel that spans multiple ASes. This tunnel
> > 	   is used to carry (multicast) traffic from the MVPN sites connected to
> > 	   the PEs of the AS to the MVPN sites connected to the PEs that are in
> > 	   the other ASes. Such tunnel consists of multiple intra-AS segments
> > 	   (one per AS) stitched at ASBRs' boundaries by single hop <ASBR-ASBR>
> > 	   LSP segments.
> > 
> > 	BD>> Should that be "LSP segments" or "tunnels"? Do the inter-AS
> > 	tunnels have to be MPLS encapsulated? If so, it would be good to clear
> > 	this up in the intro to section 8.
> > 
> > 	[...]
> > 
> > 	8.2.1.2.3. Inter-AS Auto-Discovery Route received via IBGP
> > 
> > 
> > 	[...]
> > 
> > 	   If the NLRI of the route does not carry a label, then this tree is an
> > 	   intra-AS LSP segment that is part of the inter-AS Tunnel for the MVPN
> > 	   advertised by the inter-AS auto-discovery route.
> > 	BD>> Again, shouldn't that be "intra-AS tunnel segment" rather than
> > 	   "LSP segment"?
> > 
> > 	 [...]
> > 
> > 	8.2.4. Inter-AS S-PMSI
> > 
> > 	   An inter-AS tunnel for an S-PMSI is constructed similar to an inter-
> > 	   AS tunnel for an I-PMSI. Namely, such a tunnel is constructed as a
> > 	   concatenation of tunnel segments. There are two types of tunnel
> > 	   segments: an intra-AS tunnel segment (a segment that spans ASBRs
> > 	   within the same AS), and inter-AS tunnel segment (a segment that
> > 	   spans adjacent ASBRs in adjacent ASes).
> > 
> > 	BD>> doesn't the intra-AS tunnel segment span both ASBRs and PEs?
> > 
> > 	   ASes that are spanned by a
> > 	   tunnel are not required to use the same tunneling mechanism to
> > 	   construct the tunnel - each AS may pick up a tunneling mechanism to
> > 	   construct the intra-AS tunnel segment of the tunnel on its
> > 
> > 	BD>> sentence fragment...
> > 
> > 	[...]
> > 
> > 
> > 	10.2. Using MSDP between a PE and a Local C-RP
> > 
> > 
> > 	   Suppose that PE1 transmits a multicast data packet on a PMSI, where
> > 	   that data packet is part of an (S,G) flow, and PE2 receives that
> > 	   packet form that PMSI.
> > 	BD>> from -> from
> > 	  According to section 9, PE1 is not the PE that PE2 expects to be
> > 	   transmitting (S,G) packets, then PE2 must
> > 	   discard the packet.
> > 	BD>> I think you mean to say "*if* PE1 is not the PE..."
> > 
> > 	 If an MSDP-encapsulated data packet is
> > 	   transmitted on a PMSI as specified above, this rule from section 9
> > 	   would likely result in the packet's getting discarded.  Therefore, if
> > 	   MSDP-encapsulated data packets being decapsulated and transmitted on
> > 	   a PMSI, we need to modify the rules of section 9 as follows:
> > 
> > 	      1. If the receiving PE, PE1, has already joined the (S,G) tree,
> > 	         and has chosen PE2 as the upstream PE for the (S,G) tree, but
> > 	         this packet does not come from PE2, PE1 must discard the
> > 	         packet.
> > 
> > 	      2. If the receiving PE, PE1, has not already joined the (S,G)
> > 	         tree, but is a PIM adjacency to a CE which is downstream on the
> > 	         (*,G) tree, the packet should be forwarded to the CE.
> > 	BD>> It appears that in the course of this paragraph you went from PE2
> > 	         receiving packets from PE1 to PE1 receiving packets from
> > 	         PE2. That seems needlessly confusing - suggest you pick one
> > 	         to be the receiving PE for the whole para.
> > 
> > 	11. Encapsulations
> > 	[...]
> > 	11.1.3. Encapsulation in MPLS
> > 
> > 	   If the PMSI is instantiated as a P2MP MPLS LSP,
> > 	BD>> or an MP2MP MPLS LSP?
> > 
> > 	   MPLS encapsulation is
> > 	   used. Penultimate-hop-popping must be disabled for the P2MP MPLS LSP.
> > 	   If the PMSI is instantiated as an RSVP-TE P2MP LSP, additional MPLS
> > 	   encapsulation procedures are used, as specified in [RSVP-P2MP].
> > 
> > 	   If other methods of assigning MPLS labels to multicast distribution
> > 	   trees are in use,
> > 	BD>> e.g. MLDP
> > 
> > 	 these multicast distribution trees may be used as
> > 	   appropriate to instantiate PMSIs, and any additional MPLS
> > 	BD>> "any" -> appropriate?
> > 	   encapsulation procedures may be used.
> > 
> > 
> > 
> > 
> > 	11.2. Encapsulations for Multiple PMSIs per Tunnel
> > 
> > 	   The encapsulations for transmitting multicast data messages when
> > 	   there are multiple PMSIs per tunnel are based on the encapsulation
> > 	   for a single PMSI per tunnel, but with an MPLS label used for
> > 	   demultiplexing.
> > 
> > 	   The label is upstream-assigned and distributed via BGP as specified
> > 	   in section 4.  The label must enable the receiver to select the
> > 	   proper VRF, and may enable the receiver to select a particular
> > 	   multicast routing entry within that VRF.
> > 
> > 	BD>> I suggest for completeness you add a sentence about the case
> > 	where the outer encapsulation is MPLS, then say that the non-MPLS
> > 	cases are covered below.
> > 
> > 	[...]
> > 
> > 
> > 	11.4. Encapsulations for Unicasting PIM Control Messages
> > 
> > 	   When PIM control messages are unicast, rather than being sent on an
> > 	   MI-PMSI, the the receiving PE needs to determine the particular
> > 	BD>> ..., then the
> > 
> > 
> > 
> > 	11.5. General Considerations for IP and GRE Encaps
> > 
> > 	   These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations.
> > 
> > 
> > 	11.5.1. MTU
> > 
> > 	   It is the responsibility of the originator of a C-packet to ensure
> > 	   that the packet small enough to reach all of its destinations, even
> > 	BD>> ... is small...
> > 
> > 
> > 
> > 
> > 
> > 	11.5.2. TTL
> > 
> > 	   The ingress PE should not copy the TTL field from the payload IP
> > 	   header received from a CE router to the delivery IP or MPLS header.
> > 	   The setting of the TTL of the delivery header is determined by the
> > 	   local policy of the ingress PE router.
> > 
> > 	BD>> Is there anything MVPN specific about that paragraph? Why don't
> > 	the normal rules of TTL setting for MPLS or IP/GRE tunnels apply?
> > 	Maybe you can cite RFC3443?
> > 
> > 	[...]
> > 
> > 	12. Support for PIM-BIDIR C-Groups
> > 
> > 	   In BIDIR-PIM, each multicast group is associated with an RPA
> > 	   (Rendezvous Point Address).  The Rendezvous Point Link (RPL) is the
> > 	   link that attaches to the RPA.  Usually it's a LAN where the RPA is
> > 	   in the IP subnet assigned to the LAN.  The root node of a BIDIR-PIM
> > 	   tree is a node which has an interface on the RPL.
> > 
> > 	   On any LAN (other than the RPL) which is a link in a PIM-bidir tree,
> > 	   there must be a single node that has been chosen to be the DF.
> > 
> > 	BD>> A definition of DF would be good.
> > 
> > 
> > 
> > 	   If BGP signaling is used among the PEs, an alternative to DF election
> > 	   is necessary.  One might think that use the "single forwarder
> > 
> > 	BD>> "use" should be deleted
> > 
> > 	   selection" procedures described in sections 5 and 9 coudl be used to
> > 	BD>> "could"
> > 
> > 	   choose a single PE "DF" for the backbone (for a given RPA in a given
> > 	   MVPN).
> > 
> > 	[...]
> > 
> > 
> > 	12.1.1. Control Plane
> > 
> > 	   Associated with each MVPN-RPL is an address prefix that is
> > 	   unambiguous within the context of the MVPN associated with the MVPN-
> > 	   RPL.
> > 
> > 	   For a given MVPN, each VRF connected to an MVPN-RPL of that MVPN is
> > 	   configured to advertise to all of its connected CEs the address
> > 	   prefix of the MVPN-RPL.
> > 
> > 	   Since in PIM Bidir there is no Designated Forwarder on an RPL, in the
> > 	   context of MVPN-RPL there is no need to perform the Designated
> > 	   Forwarder election among the PEs (note there is still necessary to
> > 	   perform the Designated Forwarder election between a PE and its
> > 	   directly attached CEs, but that is done using plain PIM Bidir
> > 	   procedures).
> > 
> > 	BD>> The start of this para repeats text from the start of
> > 	12.1. The main value of this para seems to be the paranthetical
> > 	comment, so maybe it shouldn't be paranthetical. How about:
> > 
> > 	   "As noted above, there is no need in this case to perform DF
> > 	   election among the PEs. Note however that it is still necessary to
> > 	   perform the DF election between a PE and its
> > 	   directly attached CEs; that is done using plain PIM Bidir
> > 	   procedures."
> > 
> > 	[...]
> > 
> > 
> > 
> > 
> > 	12.2. Partitioned Sets of PEs
> > 
> > 	   This method does not require the use of the MVPN-RPL, and does not
> > 	   require the customer to outsource the RPA/RPL functionality to the
> > 	   SP.
> > 
> > 
> > 	12.2.1. Partitions
> > 
> > 	   Consider a particular C-RPA, call it C-R, in a particular MVPN.
> > 	   Consider the set of PEs that attach to sites that have senders or
> > 	   receivers for a BIDIR-PIM group C-G, where C-R is the RPA for C-G.
> > 	   (As always we sue the "C-" prefix to indicate that we are referring
> > 
> > 	BD>> "sue" -> "use". But isn't it a bit late to be reminding the
> > 	reader what "C-" means anyway?
> > 
> > 	   to an address in the VPN's address space rather than in the
> > 	   provider's address space.)
> > 
> > 
> > 	   Following the procedures of section 5.1, each PE in the set
> > 	   independently chooses some other PE in the set to be its "upstream
> > 	   PE" for those BIDIR-PIM groups with RPA C-R.  Optionally, they can
> > 	   all choose the "default selection" (described in section 5.1), to
> > 	   ensure that each PE to choose the same upstream PE.  Note that if a
> > 
> > 	BD>> "to choose" -> "chooses"
> > 
> > 	   PE has a route to C-R via a VRF interface, then the PE may choose
> > 	   itself as the upstream PE.
> > 
> > 	[...]
> > 
> > 	   Consider packet P, and let PE1 be its ingress PE.  PE1 will send the
> > 
> > 
> > 
> > 	Rosen & Raggarwa                                               [Page 78]
> > 
> > 	Internet Draft    draft-ietf-l3vpn-2547bis-mcast-05.txt        July 2007
> > 
> > 
> > 	   packet on a PMSI so that it reaches the other PEs that need to
> > 	   receive it.  This is done by encapsulating the packet and sending it
> > 	   on a P-tunnel.  If the original packet is part of a PIM-BIDIR group
> > 	   (its ingress PE determines this from the packet's destination address
> > 	   C-G), and if the VPN backbone is not the RPL, then the encapsulation
> > 	   MUST carry information that can be used to identify the partition to
> > 	   which the ingress PE belongs.
> > 
> > 	   When PE2 receives a packet from the PMSI, PE2 must determine, by
> > 	   examining the encapsulation, whether the packet's ingress PE belongs
> > 	   to the same partition (relative to the C-RPA of the packet's C-G)
> > 	   that PE2 itself belongs to.
> > 
> > 	BD>> Might be helpful to point ahead to 12.2.2 to say that the
> > 	   encaps will be explained there.
> > 
> > 	  If not, PE2 discards the packet.
> > 	   Otherwise PE2 performs the normal BIDIR-PIM data packet processing.
> > 	   With this rule in place, harmful loops cannot be introduced by the
> > 	   PEs into the customer's bidirectional tree.
> > 
> > 
> > 
> > 
> 
>