Subject: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt

From: "John G. Scudder" <[email-masked]>
Date: Mon, 9 Nov 2009 18:10:27 +0900

My question from the mic:

Please also consider how the draft responds to the requirements in  
RFC4834 (and contrast to the existing CsC solutions if possible).

Specific requirements to consider include

 From RFC4834, Section 5.2.2 (Scalability):
                                                   ....  proposed
    solutions SHOULD offer the possibility of sharing such resources
    between different multicast streams (between different VPNs, between
    different multicast streams of the same or of different VPNs).

and

 From RFC4834, Section 5.2.4.1 (Tunneling Technologies)

    Following the principle of separation between the control plane and
    the forwarding plane, a multicast VPN solution SHOULD be designed so
    that control and forwarding planes are not interdependent: the
    control plane SHALL NOT depend on which forwarding plane is used  
(and
    vice versa), and the choice of forwarding plane SHOULD NOT be  
limited
    by the design of the solution.  Also, the solution SHOULD NOT be  
tied
    to a specific tunneling technology.

Thanks,

--John

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Nov 2009 09:54:30 -0500

John> contrast to the existing CsC solutions if possible

That's a fair request.

The solution described in sections 15, 11.1.2 and 11.3.2 of
draft-ietf-l3vpn-2547bis-mcast-bgp presupposes the use of mLDP on the
interface between the "outer carrier" and the "inner carrier".  It uses BGP
C-multicast routing to convey the outer carrier's mLDP signaling
information, and uses BGP S-PMSI A-D routes to assign the outer carrier's
mLDP-based P2MP LSPs to P-tunnels of the inner carrier.  If a particular
deployment supports upstream-assigned MPLS labels, this can be used to allow
aggregation of multiple P2MP LSPs from the outer carrier into a single
P-tunnel of the inner carrier.

Now consider a deployment scenario with the following properties:

- The inner carrier has not deployed and/or does not want to deploy BGP
  C-multicast routing.

- The inner carrier and the outer carrier both use mLDP for their P-tunnels.

- The inner carrier is not concerned about aggregation (either because
  upstream-assigned labels are not available, or because it doesn't want the
  sub-optimal routing that comes with aggregation).

In this scenario, the simple "in-band" signaling of draft-wijnands-mpls-
mldp-csc provides a much simpler solution.  We think this will be a quite
common deployment scenario.  

Of course, if a carrier's carrier does want to do aggregation and does want
to deploy BGP C-multicast routing, those options are certainly available in
the overall solution set.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 Nov 2009 13:21:50 -0800

Eric,

> - - The inner carrier has not deployed and/or does not want to deploy BGP
>   C-multicast routing.
>
> - - The inner carrier and the outer carrier both use mLDP for their P-tunnels.

This is supported by the solution specified in 
draft-ietf-l3vpn-2547bis-mcast-bgp.

> - - The inner carrier is not concerned about aggregation (either because

The inner carrier doesn't have to use aggregation with the solution
specified in draft-ietf-l3vpn-2547bis-mcast-bgp 

> the overall solution set.
 
The MVPN solution that L3VPN WG has to produce is based on the
requirements developed in L3VPN WG, as specified in rfc4834, and
*not* on what you think "will be a quite common deployment
scenario". With this in mind, supporting carrier that "does not want
to deploy BGP C-multicast routing", which you use as a justification
for the approach specified in draft-wijnands-mpls-mldp-csc, is *not*
one of the requirements listed in that rfc. On the other hand, as
John pointed out in his e-mail, the approach specified in
draft-wijnands-mpls-mldp-csc does *not* meet two of the "SHOULD"
requirements specified in rfc4834.

Yakov.