Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

[Chris Lewis <[e-mail]>]

Hi Rahul,

At 04:53 AM 2/9/2004, Rahul Aggarwal wrote:

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

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.


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

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

Chris


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