Subject: Regarding draft-wijnands-mpls-mldp-csc

From: Eric Rosen <[email-masked]>
Date: Wed, 13 Jan 2010 11:03:09 -0500

Back in November/December a conversation took place on the MPLS mailing list
discussing the VPN-related features of draft-wijnands-mpls-mldp-csc.  That
conversation should really have taken place on the L3VPN list, so I am
forwarding it here for this WG's review.  Five messages are attached.  

Subject: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt
From: "John G. Scudder" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 9 Nov 2009 18:10:27 +0900
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>

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
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt
From: Eric Rosen <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [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.

Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 23 Nov 2009 13:21:50 -0800

Eric,

> 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.

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

> - - 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).

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

> 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.
 
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.

Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt
From: Eric Rosen <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 02 Dec 2009 10:18:00 -0500

> 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"

There is no reason why the WG should not consider simplifications that
optimize for particular deployment scenarios, particularly if those
scenarios are common.

> 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.

I don't think that anything in the requirements doc prevents the WG from
considering design goals that or simplifications that are not explicitly
mentioned there.  If SPs are interested in such simplifications, then there
should be public, interoperable standard for them.

Also, it's made quite clear in the drafts that the WG has already approved
that BGP C-multicast routing is optional to deploy.  I don't know if anyone
will ever deploy it or not, but I'm pretty sure that an SP that does not
deploy it for signaling customer multicast routes is not going to deploy it
just to provide unaggregated CsC mLDP-in-mLDP service!  Not when there's a
much simpler solution available.

> 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.

There's no reason why every individual option should meet each requirement.
And there's no reason for a service provider to deploy something that is
more complex than needed in that provider's environment.  

If we were required to design a set of eating utensils that supported the
eating of both liquid and solid foods, I think it would be okay to design a
spoon and a fork; we would not have to design a swiss army knife.  And I
don't think anyone would object to the inclusion of the "fork option" on the
grounds that you can't eat soup with a fork.

Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-02.txt
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 8 Dec 2009 11:03:06 -0800

Eric,

> > 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"
> 
> There is no reason why the WG should not consider simplifications that
> optimize for particular deployment scenarios, particularly if those
> scenarios are common.

Then please bring this up in L3VPN WG mailing list, as the topic
of the discussion is MVPN (and as such it is outside the scope
of MPLS WG).

Yakov.