Subject: MPLS over L2TPv3 encap for RFC 2547 VPNs

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 02 Feb 2004 21:26:15 +0100

Based on comments received from the previous IETF meeting, I have split the MPLS 
over L2TPv3 draft into two documents.

draft-townsley-l2tpv3-mpls-01.txt targets mpls, and presents only the MPLS over 
L2TPv3 encapsulation.

draft-townsley-l3vpn-l2tpv3-00.txt targets l3vpn, and discusses the use of MPLS 
over L2TPv3 within the context of RFC2547-Style VPNs.

Yakov also had three specific points raised during both meetings that I promised 
to bring to the list. These follow:

> 1. Why extending BGP for multipoint-to-point L2TP signaling
> is preferred to the existing L2TP signaling (or extending L2TP
> to provide multipoint-to-point signaling) ?

Any sort of point to multipoint manual configuration or signaling may in fact be 
used. However, BGP does seem prudent for what is effectively an extension to 
RFC2547.

> 2. The applicability scope is by no means limited to 2547 - it is
> applicable to any multipoint-to-point application.

Yes, though the scope does not extend beyond reachability information to a given 
PE. The MPLS labels for the VPN routes themselves continue to be distributed by 
the existing mechanisms of RFC2547.

> 3. The security claims have to be reviewed by the Security ADs.

Yes, as with any potential RFC.

Thanks,

- Mark

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 03 Feb 2004 17:41:45 -0800

Mark,

> draft-townsley-l2tpv3-mpls-01.txt targets mpls, and presents only the 
> MPLS over L2TPv3 encapsulation.
> 
> Yakov also had three specific points raised during both meetings that 
> I promised to bring to the list. These follow:
> 
> Any sort of point to multipoint manual configuration or signaling may 
> in fact be used. 

My question was not whether BGP *may* be used, but *why* extend BGP
to support l2tp signaling when l2tp already has its own signaling
protocol. 

> However, BGP does seem prudent for what is effectively 
> an extension to RFC2547.

Please document in your draft what is exactly "prudent" about BGP.

> Yes, though the scope does not extend beyond reachability information to 
> a given PE. The MPLS labels for the VPN routes themselves continue to 
> be distributed by the existing mechanisms of RFC2547.

I am glad you agree that that the distribution of l2tp signaling
information described in your draft  is completely orthogonal to
2547. Which is precisely the point I made.  That is, there is nothing
in your draft that is specific to just 2547. E.g., it is equally
applicable to VR based L3VPNs. Therefore, the draft has to be generalized
to cover any multipoint-to-point application of MPLS over l2tp.

> Yes, as with any potential RFC.

Since security considerations (and to be more precise, the part
about implications on packet spoofing) are presented in your draft
as one of the major justifications for using l2tp, in making a
decision on whether to accept your drafts as a WG document the WG
needs to know whether this justification is really accurate. That
is precisely why I asked the section on implications on packet
spoofing to be reviewed and evaluated for correctness and accuracy
by the Security ADs.

Yakov.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 04 Feb 2004 09:44:58 +0100

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

> That is, there is nothing in your draft that is specific to just 
 > 2547. E.g., it is equally applicable to VR based L3VPNs. Therefore,
 > the draft has to be generalized to cover any multipoint-to-point
 > application of MPLS over l2tp.

No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label for a VPN-IPv4 
address distributed via RFC2547 extensions to BGP between PEs. I should not 
extend this draft to cover other L3VPN models any more than 
draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt 
should. Shall I rename it to something with "2547" in the title to be more clear?

>>>3. The security claims have to be reviewed by the Security ADs.

I am more than happy to have discussions with Security ADs on this topic.

- Mark

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 04 Feb 2004 11:55:08 -0800

Mark,

> and we specify below how to extend this to the signalling of security policy."
> 
> [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.

> should. Shall I rename it to something with "2547" in the title to be 

First of all I'd like to thank you for pointing that both
draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt
took a fairly narrow point of view. This is a bug, not a feature,
and therefore it should be fixed.

Second, the restriction on the applicability of your draft to 2547 is
quite arbitrary. That is, there are *no* technical justifications
for this restriction. And the fact that some other drafts took a fairly 
narrow view of the problem is no justification for continuing this.

> I am more than happy to have discussions with Security ADs on this topic.

Thanks. Please post the outcome of this discussion to the list.
 
Yakov.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 06 Feb 2004 17:09:35 +0100

> use IPSec to get traffic to that PE.

Read again. The ipsec-2547 draft refers to encoding more than just whether or 
not to reach a PE via IPsec vs. MPLS (as if this is somehow OK, when advertising 
other bits of reachability information for the PE isn't).

Specifically, the draft refers to encoding of the BGP "IPsec Extended Community" 
or "Tunnel Type Extended Community" to:

- accept, deny, or direct traffic with different IPsec policies (e.g., how to 
process a packet based on the SPI received within the IPsec header).

- determine if a PE may be reached via GRE or IP (e.g., which IP protocol type 
and header format to use).

The l3vpn-l2tpv3 draft is encoding somewhat similar information. e.g., Accept an 
MPLS-labeled payload on the IP Protocol Type for L2TPv3, and process or drop it 
based on the Session/Cookie received in the L2TPv3 header.

Bottom line, if you throw out one, you are really going to have to throw out the 
other. Niether of which I think is a good idea.

> Just tell us why BGP signaling is any better than l2tp signaling.

I will say it again. (1) This is an application of 2547 which is already using 
BGP, and (2) L2TP needs to distribute a *single* PE Session/Cookie to be used by 
every participating 2547-PE for VPN traffic destined to that PE (much like a 
single IP address is distributed to every participating PE for VPN traffic 
destined to that PE).

> and therefore it should be fixed.

I have no problem with someone documenting how a VR-based VPN should work, but 
why do this in the same draft? Would you consider adding VR VPNs to 2547bis?

> quite arbitrary. 

Hardly arbitrary.

> That is, there are *no* technical justifications for this restriction.

VRs and 2547 are different technical approaches, what technical justification is 
there for putting them in the *same* document?

 > And the fact that some other drafts took a fairly

And adding my document to the mix is justification for taking the other 
documents off course?

Write some VR text. I have absolutely no problem with that. But procedurally or 
technically I don't see why 2547 and VR must be a part of the same document.

- Mark

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 06 Feb 2004 11:46:03 -0800

Mark,

> single IP address is distributed to every participating PE for VPN traffic 

Are you saying that just because an application uses BGP, the application
should use BGP, instead of l2tp for l2tp signaling ?

Or you saying that only when both (1) *and* (2) hold, then the application
should use BGP, instead of l2tp for l2tp signaling ?

> why do this in the same draft? Would you consider adding VR VPNs to 2547bis?

Based on the feedback received so far on the mailing list, I do
plan to generalize draft-ietf-l3vpn-gre-ip-2547-00.txt.

> VRs and 2547 are different technical approaches, what technical justification
> is there for putting them in the *same* document?

Because from the l2tp point of view the procedures are exactly
the same, whether it is 2547 or MPLS-based VR.

Yakov.

---

From: Gargi <[email-masked]>
Date: Fri, 06 Feb 2004 14:24:26 -0800

Hi Yakov,

> should use BGP, instead of l2tp for l2tp signaling ?

The l3vpn-l2tpv3 draft is no different from ppvpn-mpls-ip-gre-sig-00.txt
Both describe how the same information about L2TPv3/GRE tunnel endpoints
can be exchanged via BGP as one of the mechanisms. Neither draft
mandates the use of BGP. One could use static configuration, LDP/l2tp
signalling or BGP for the relevant tunnel endpoints to know this
information. The use of the mechanism is upto the respective operator
who chooses the machanism that suits their particular network.

Also, the information carried in BGP (when BGP is chosen as the
mechanism) is no different than the inner label that is exchanged
via BGP. The inner label may be per-prefix, per VRF or whatever
granularity depending on the implementation's choice and it is
exchanged via BGP. It identifies to the rcvg router of the data
packet how the packet is to be switched. In case of the tunnel
endpoints for l2tp or gre tunnels, the tunnel information sent
through BGP, also identifies to the receiver of the BGP update
(and sender of the data packet) how the packet is to be switched.
For the IP-VPN application, if there is no label-switching enabled
in the core, and the tunnel endpoint becomes unreachable from
the sender (of the data pkt) PE, the prefix loses reachability.
In that sense, this is reachability information.

Yes, the tunnel endpoint information - in case of generic l2tp &
gre tunnels, could be exchanged through different signalling
protocols. The application that justifies carrying the endpoint
information in BGP is that in case of some applications such as
IP-VPNs, this is indeed reachability information. And it is very
analogous to the IGP reachability which sometimes gets injected
into BGP.

>>>>should. Shall I rename it to something with "2547" in the title to be 

If it is ok to carry either of the above information in BGP, the
l3vpn-l2tp draft just specifies on emore such class of information
that could be exchanged via BGP. I see no difference.

> plan to generalize draft-ietf-l3vpn-gre-ip-2547-00.txt.

Excellent! I would vote for generalizing it such that doesnt matter
whether  the information is gre, l2tp or ipsec related - it could use
the same BGP mechanism whenever BGP is the protocol to exchange any
part of the information.

Thanks,
Gargi

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 07 Feb 2004 10:54:55 +0100

Dropping double-post to [email-masked]. Please see inline.

Yakov Rekhter wrote:

>>I will say it again. (1) This is an application of 2547 which is already usin
> 
> g 
> 
>>BGP, and (2) L2TP needs to distribute a *single* PE Session/Cookie to be used
> 
>  by 
> 

The two reasons I gave above were motivations for the design of 2547 VPNs with 
an L2TPv3 encapsulation, no more. I have no desire to extend this to a 
generalized theorem (or continued rathole discussion) for when to use BGP or 
L2TP signaling for all other possible applications, as I must say you seem to be 
intent on doing with this thread.

>>I have no problem with someone documenting how a VR-based VPN should work, bu
> 
> t 
> 

I am happy to work with you or anyone else interested in discussing the 
technical details of this to determine whether it is indeed a good fit for the 
same draft, or could exist separately without undue repetition.

- Mark