RE: MPLS over L2TPv3 encap for RFC 2547 VPNs

[[e-mail]]

Yakov/Mark,

This discussion seems to have 2 major themes:
-	the appropriate functional use (or misuse) of protocols
-	security implications of functional protocol use (or misuse).

I would much prefer we split the VPN problem into its 3 major components (see below) and folks can use whichever protocol is considered the most appropriate to that component.  Further, and speaking as an operator, I'd like to see as much *appropriate* re-use of components across the 3 networking modes of co-cs, co-ps and cl-p as possible when creating VPNs so that I can get my capex/opex costs down....and this has impact through to the NMS/OSS supporting these.

Now when I look at the VPN problem I see 3 major component areas:

1	Discovery/authentication:  One needs a method of knowing which addressable access points of a given server layer technology belong to a given VPN.  A query/response behaviour seems most appropriate here, not a broadcast approach that one gets with BGP4.  So an approach based on Radius say seems a good solution here.

2	Server layer topology creation:  One needs a method of creating forwarding paths between the identified (from above) addressable access points of the server layer technology belonging to the VPN.  This needs a proper signalling protocol IMO and not a broadcast behaviour like BGP4.  Several signalling protocols could be used, and the selection is dependent upon which networking mode is being used for the server layer technology.  For example, if the server layer is IP (cl-ps mode) one can use L2TP (but I could also 'signal' the set-up of GRE tunnels say).  If the server layer is MPLS (co-ps mode) one can use RSVP-TE.....and in theory I could also use PNNI.  If the server layer is SDH (co-cs mode) one can again use RSVP-TE....or I could also use PNNI.

There are three important observations at this point:
-	within a given mode there can be more than 1 choice of signalling protocol....some signalling protocols have better functional specification/behaviour than others;
-	the use of an out-of-band (OOB), logical and/or physical, date-plane network for the important *internal* control/management traffic should be very high on any operator's requirements list for obvious security reasons.  So where this is possible this should be done (this should be a no-brainer requirement IMO for both the co-ps and co-cs modes);
-	if we stop the VPN creation process at steps 1 and 2 above we have the essence of automating the creation of a simple managed BW VPN is some technology.....some folk call these 'L2 VPNs', not a good term IMO but it is in general usage.

3	Client layer reachability information:  This is a component that can be added to the above 'L2 VPN' base-case to create a so-called 'L3 VPN'.  The type of client should not be prescriptive....and this is why it is architecturally wrong to assume 'L3 VPN'=> IP VPN, and why I think the term 'L3 VPN' is misleading.  Indeed, I recall seeing a draft from Chris Metz (draft-metz-switched-atm-l2vpn-00.txt) a while ago that was using a rfc2547 approach with BGP4 distributing ATM NSAP address reachability over MPLS as the server layer technology, ie ATM was the client in this 'L3 VPN'

Now here a limited broadcast functional behaviour is what is required to distribute information regarding which *client* layer access point addresses lie above/behind which *server* layer access point addresses....noting these are 2 disjoint layer networks.


It is my opinion that if folks started to regard VPNs in the above terms then much of the squabbling (eg 'my protocol is better than yours') could be avoided.  And we may also be able to provide operator's with better solutions in the future (esp noting my points on functional re-use to get capex/opex down and the use of an OOB control/management plane where this is appropriate to improve security).

regards, Neil 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Yakov Rekhter
> Sent: 04 February 2004 01:42
> To: W. Mark Townsley
> Cc: [e-mail]; [e-mail]
> Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs 
> 
> 
> Mark,
> 
> > 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. 
> 
> 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.
> 
> > > 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.
> 
> 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.
> 
> > > 3. The security claims have to be reviewed by the Security ADs.
> > 
> > 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.
> 
>