l3vpn@ietf.org
[Top] [All Lists]

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

Subject: Fwd: FW: Review of draft-ietf-l3vpn-2547-mcast-05
From: Rick Wilder
Date: Tue, 12 Feb 2008 09:38:06 -0800 PST
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.
> > 
> > 
> > 
> > 
> 
> 

<Prev in Thread] Current Thread [Next in Thread>
  • Fwd: FW: Review of draft-ietf-l3vpn-2547-mcast-05, Rick Wilder <=