The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Feb> msg00044



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS over L2TPv3 encap for RFC 2547 VPNs

  • From: Rahul Aggarwal <rahul@juniper.net>
  • Date: Mon, 9 Feb 2004 02:53:25 -0800 (PST)
  • cc: yakov@juniper.net, "" <mpls@UU.NET>, "" <l3vpn@ietf.org>


Hi Chris,

On Fri, 6 Feb 2004, Chris Lewis wrote:

> Hello Yakov,
>
> I saw your exchange with Mark below and want to offer an opinion.
>
> I agree that your question as to why BGP is better than L2TP signaling in
> this case is one worth asking.
>
> I believe that the answer is quite simple, however I would appreciate any
> further input on where this logic falls down.
>
> In this draft, Mark is not signaling pseudowire state. Rather a single
> piece of information that tells any other PE wanting to communicate with a
> given PE, what it's capabilities are, needs to be communicated throughout
> the domain. In this instance the same set of information needs to go to

Not just capabilities. This information includes L2TPv3 signaling
information: session-id and cookie.

> many peers and there is no exchange of pseudowire state involved.
> Essentially a point to multipoint conversation.
>

Hence, shouldn't it be fine to generalize this draft to cover any
point-to-multipoint application of MPLS over L2TPv3 ?

rahul

> To me it seems logical that using the BGP default behavior of broadcast is
> more efficient than using the behavior of L2TP, which is point to point in
> nature and forcing a replication of many L2TP point to point sessions, when
> a single BGP entry would do.
>



> Does this make sense, or am I missing something?
>
> Cheers
>
> Chris
>
> To: "W. Mark Townsley" <townsley@cisco.com>
> cc: mpls@UU.NET, l3vpn@ietf.org
> Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs
> Date: Wed, 04 Feb 2004 11:55:08 -0800
> From: Yakov Rekhter <yakov@juniper.net>
> Mark,
>  > Yakov Rekhter wrote:
>  >
>  > > Please document in your draft what is exactly "prudent" about BGP.
>  >
>  > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide:
>  >
>  > "RFC2547 already provides an egress-to-ingress signaling capability via
> BGP,
>  > and we specify below how to extend this to the signalling of security
> policy."
>  >
>  > I will add this text to the l3vpn-l2tpv3 document:
>  >
>  > "RFC2547 already provides an egress-to-ingress signaling capability via
> BGP,
>  > [NALAWADE] or [RAGGARWA] specifies how to extend this to the signaling of
>  > L2TPv3 reachability information for a PE."
> Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does
> not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does
> *not* replace IPSec signaling with BGP. All it does is specifying
> how to use BGP to indicate whether a particular VPN on a PE should
> use IPSec to get traffic to that PE.
> In contrast your draft uses BGP not just to specify whether a
> particular VPN on a PE should use l2tp to get traffic to that PE,
> but also uses BGP to carry the l2tp session and cookie (l2tp signaling
> information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt
> your draft does replace the l2tp signaling protocol with BGP, thus
> eliminating the need for l2tp signaling with the l2tp signaling
> protocol.
> Just tell us why BGP signaling is any better than l2tp signaling.
>
>