Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

From: Chris Lewis <[email-masked]>
Date: Fri, 06 Feb 2004 21:23:21 -0600

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 
many peers and there is no exchange of pseudowire state involved. 
Essentially a point to multipoint conversation.

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" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs
Date: Wed, 04 Feb 2004 11:55:08 -0800
From: Yakov Rekhter <[email-masked]>
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.

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 9 Feb 2004 02:53:25 -0800 (PST)

Hi Chris,

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

> 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

---

From: Chris Lewis <[email-masked]>
Date: Mon, 09 Feb 2004 09:10:55 -0600

Hi Rahul,

>information: session-id and cookie.

If it's the same value that has to go to multiple peers, it seems to me 
that to broadcast it by BGP is a more efficient option.

>point-to-multipoint application of MPLS over L2TPv3 ?

If you're referring to virtual routers in this definition of 
generalization, I don't have an opinion.

Chris