The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Feb> msg00040



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS over L2TPv3 encap for RFC 2547 VPNs

  • From: Gargi <gargi@cisco.com>
  • Date: Fri, 06 Feb 2004 14:24:26 -0800
  • CC: "W. Mark Townsley" <townsley@cisco.com>, mpls@UU.NET, l3vpn@ietf.org
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
  • X-PMX-Version: 4.1.1.86173

Hi Yakov,

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


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

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.


> Based on the feedback received so far on the mailing list, I do
> 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