The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS over L2TPv3 encap for RFC 2547 VPNs
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
|
|