Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

["W. Mark Townsley" <[e-mail]>]

Yakov Rekhter wrote:

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

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.

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

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

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

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?

> 
> Second, the restriction on the applicability of your draft to 2547 is
> 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
> narrow view of the problem is no justification for continuing this.

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

> 
> 
>>>>>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.
> 
> 
> Thanks. Please post the outcome of this discussion to the list.
>  
> Yakov. 
>