|
|
Sorry, folks. This is the second try to forward this to the list. Not
sure what happened the first time.
Rick
--- Rick Wilder <rick@xxxxxxxxxxxx> 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 <rick@xxxxxxxxxxxx>
> Subject: Fwd: FW: Review of draft-ietf-l3vpn-2547-mcast-05
> To: l3vpn@xxxxxxxx
> 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 <bdavie@xxxxxxxxx>
> > Date: January 3, 2008 1:56:36 PM EST
> > To: l3vpn@xxxxxxxx, Eric Rosen <erosen@xxxxxxxxx>, Rahul@xxxxxxxxxxx
> > 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.
> >
> >
> >
> >
>
>
|
|