MVPN Profiles

1
MVPN Profiles

• Why do we need profiles?
• By design, architecture provides many choices
• PE-PE C-multicast routing info distribution PIM
  or BGP
• Multicast data distribution infrastructure
• GRE encaps with PIM trees,
• MPLS encaps with
• RSVP-TE P2MP LSPs
• mLDP P2MP LSPs
• mLDP MP2MP LSPs
• Ingress replication with IP-based encaps
• No consensus (and not desirable) to eliminate all
  but one choice
• No vendor wants to implement all possible
  combinations of options

2
Whats Good About Specifying Profiles?

• Profile A set of options which are
• useful together, and
• wanted by a customer
• Customer can ask for the profile it wants
• conformance to a profile is well-defined
• i.e., multi-vendor interoperability is possible.?
• Decisions can be based on customer demand, rather
  than IETF debate.

3
FUD About Profiles

• Wouldnt it be better to have fewer options, or
  even no options?
• Only if you believe that one size fits all
• Only if theres enough real world experience to
  show that only one set of options is needed
• Only if theres real consensus behind a single
  profile
• Unless one profile is mandatory, theres no
  guaranteed interoperability
• In fact, it doesnt matter if one profile is
  mandatory, unless thats the one that everyone
  wants!

4
Profiles Using PIM Control Plane

• PIM? Oh, thats so passe! ?
• Some facts
• All existing deployments use PIM
• Not going away tomorrow
• One big advantage known to work, many years
  experience behind it
• Scalability issues do exist, but not even close
  to approaching them in practice

5
Isnt BGP the new generation?

• WG docs do not favor either PIM or BGP over the
  other
• BGP for multicast new, experimental, with
  certain risks
• Increased J/P latency
• Impact on other uses of BGP
• Sparse Mode we think BGP handles sparse mode
  okay, but there are some differences from PIM,
  impact remains to be seen
• Some customer deployments use PIM in odd ways
  (e.g., use more control than data) that may not
  fit well with BGP
• BGP great at disseminating state, less great at
  handling transactions
• many PIM operations are transactional
• this caused the BGP solution to become more
  complicated than originally envisaged, at least
  by me

6
Profiles with PIM

• Primary Focus is one two profiles
• PIMGRE
• Existing deployments
• Really two sub-profiles
• Legacy sub-profile that corresponds exactly to
  existing deployments
• Fully standard sub-profile that provides PIMGRE
  in a way which is fully compatible with WG docs
• PIMMPLS
• We think MPLS data transport can provide a number
  of advantages that make it useful with a PIM
  control plane.

7
PIMGRE Profile

• Legacy sub-profile contains non-standard items,
  specified in draft
• MDT/SAFI, connector
• Replaced by Intra-AS AD Route and VRF Route
  Import Extended Community in standards
• PIM RDvector Join Attribute, for unsegmented
  inter-AS trees in vanilla option B nets
• IMHO should be added to WG standard, but has
  gotten tangled up in the loose threads
• Draft also specified fully standard PIMGRE
  sub-profile

8
PIMMP2MP-LSP Profile

• PIM control plane is used
• MP2MP LSPs used for data and control packet
  distribution
• MI-PMSI required for PIM, but
• the P-tunnels instantiating the MI-PMSI are
  created only as needed,
• a PE joins a particular P-tunnel only as needed.
• No full mesh of P-tunnels
• unless needed anyway for data

9
MP2MP LSPs as P-Tunnels

• Each P-tunnel is MP2MP LSP rooted at a given PE
• To send a JP to a PE, join its MP2MP LSP and send
  the JP on that LSP
• Bidir joining based on RPA discovery, choose DF
  based on upstream multicast hop selection for RPA
• To send data to the other PEs
• Non-bidir send on the MP2MP LSP that you are the
  root of
• Bidir send on the MP2MP LSP rooted at the
  selected DF?
• N.B. If no one wants data from a particular PE,
  the P-tunnel rooted at that PE is never created

10
Interesting Properties

• Number of P-tunnels determined by number of PEs
  that have data to send
• generally much smaller than total number of PEs
• therefore addresses PIM/MI-PMSI scalability
  issues
• When receiving data on MI-PMSI, can always
  tell which PE transmitted it
• inferred from LSP label, since only root
  transmits data on LSP
• data arriving from wrong upstream PE easily
  discarded
• makes efficient support of C-bidir possible
• eliminates need for single forwarder selection
• asserts never occur
• Does not require a second (upstream-assigned)
  MPLS label
• Still allows use of S-PMSIs as necessary

11
Future of This Draft

• Offered now as individual/informational
• Hopefully would progress to RFC after WG docs
• One might infer the interest of certain vendors
  and customers in these profiles ?
• WG might or might not decide to bless the notion
  of profiles and standardize a few
• In that case, we might want to reconsider the
  role of this doc