RE: Advancing the Protocol and Morin Drafts

[Thomas Morin <[e-mail]>]

Hello,

RAMACHANDRAN, PRASANNA, ATTOPS :
> 
> Being in AT&T Advanced Tier support group and having supported the MVPN
> core for the last 2 years, I can clearly say that we need a solution
> such as PIM-BiDir that can reduce the number of multicast states in
> the PEs to be able to scale the Groups X Sources x OILs explosion for
> our very large Enterprise customers.   

Let me split your comment into the "requirement" and the suggested
"solution".

Your requirement: "[...] reduce the number of multicast states in the
PEs to be able to scale the Groups X Sources x OILs explosion for our
very large Enterprise customers"

  --> PE scalability is certainly a requirement common to all operators
      interested in mVPN. It isn't new, and is already explicitly
      expressed in RFC4834. Your statement, based on a large deployment,
      confirms that current solutions based on draft-rosen are not
      satisfying. This is 100% in line with the analysis in
      draft-morin-l3vpn-mvpn-considerations which concludes that mVPN
      routing with the PIM LAN procedures is not the most efficient 
      architecture for PE scalability.

The solution you suggest: "a solution such as PIM-BiDir [...]"

  -> this statement is technically quite vague, but the helpful
  interpretation provided by Ice indicates that you favor the 
  MS-PMSI approach 

  Let me insist on a few points:
  - that solution breaks an important requirement of RFC4834, section
    5.2.4.1  (a multicast vpn requirement document, that had a long time
    to mature, and on which AT&T participated)
  - if you look closely that solution does not provide any PE
    scalability benefit over mvpn routing done with BGP, and provides
    roughly the same P scalability benefit (though it can, in some
    scenarios, provide an improvement over PIM LAN procedures like in
    draft-rosen) -- I don't think it can be a solution to the
    requirement you exposed
  - that solution is not in the scope of items being worked on by the
    working group ; we can see multiple reasons explaining this: among
    others, this proposal comes late compared to other proposals, and
    didn't receive much support among vendors or operators (not
    unrelated to the reasons mentioned above)

  By any means, the fact that you happen to prefer the MS-PMSI approach,
  looks to me as quite unrelated to the adoption of
  draft-morin-l3vpn-mvpn-considerations, which is focused on current
  work items of the working group and does not state anything related to
  any future new work (that may or may not happen to provide a benefit)

> We definitely do not want to tweak a crucial protocol like BGP of
> which our scale is 2 Million VPNV4 routes in the US alone.

How is this related to opposing adoption of
draft-morin-l3vpn-mvpn-considerations ?

Let me remind that draft-morin-l3vpn-mvpn-considerations does *not*
preclude the use of PIM for multicast VPN routing.  It merely
identifies, as you do based on operational experience, the limitations
of this approach compared to BGP-based mvpn routing.

Thank you,

-Thomas Morin



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Marshall Eubanks
> Sent: Wednesday, October 01, 2008 10:04 AM
> To: [e-mail]
> Cc: Ross Callon
> Subject: Advancing the Protocol and Morin Drafts 
> 
> This email starts a 3 week call for input, to expire October 23, 2008,  
> for the following steps:
> 
> 1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working
> group document;  and
> 
> 2.) To turn this document into a requirements draft, with mandatory to
> implement features for an interoperable implementation. The authors
> have indicated that they are willing to do this.
> 
> Our intention is, if this approach is accepted, to then begin WG last
> call to submit to the IESG for publication:
> 
> draft-ietf-l3vpn-2547bis-mcast
> draft-ietf-l3vpn-2547bis-mcast-bgp
> 
> We expect that these two documents will be submitted more or less as is
> (i.e., certainly with any new bug fixes or other necessary corrections  
> and
> improvements, but without specific mandatory to implement feature
> description in those drafts).
> 
> Please respond to the list with your recommendations for these two
> courses of action.
> 
> Regards
> Marshall & Danny
>