Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

[Yakov Rekhter <[e-mail]>]

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 ?

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

Yakov.