Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

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

Dropping double-post to [e-mail]. Please see inline.

Yakov Rekhter wrote:

> Mark,
> 
> 
>>>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 usin
> 
> g 
> 
>>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).
> 
> 
> 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 ?

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.

> 
> 
>>>>>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, bu
> 
> t 
> 
>>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.
> 
> 
>>>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?
> 
> 
> Because from the l2tp point of view the procedures are exactly
> the same, whether it is 2547 or MPLS-based VR.

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

> 
> Yakov.
>