|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: iMPLS benefit
Hi, Mark: > Message-ID: <[email protected]> > Date: Mon, 22 Mar 2004 16:27:21 +0100 > From: "W. Mark Townsley" <[email protected]> > To: Enke Chen <[email protected]> > Cc: David Meyer <[email protected]>, Yakov Rekhter <[email protected]>, > sonet twister <[email protected]>, [email protected] > Subject: Re: iMPLS benefit > References: <[email protected]> > > > Enke Chen wrote: > > > Hi, Mark: > > I was no vacation and just became aware of this thread. > > Lucky you! > > > I have some clarifications here: > > > > (1) The relevant implementation is "Encapsulating MPLS in IP or Generic > > Routing Encapsulation (GRE)" for L3VPN (draft-ietf-mpls-in-ip-or-gre-xx.txt) > > This draft describes encapsulation and decapsulation of MPLS over IP, MPLS over > GRE (with and without optional GRE fields), and (in more recent versions) > touches on all of these encapsulation modes in the presence of IPsec. There is > no detail on dynamic establishment of GRE tunnels here. I should have mentioned the draft "Use of PE-PE GRE or IP in RFC2547 VPNs" (draft-ietf-l3vpn-gre-ip-2547-xx.txt), in which the notion of dynamic GRE tunnel is defined: ----------------------------------------------------------------------- 6.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE [...] The effect is to dynamically create an IP (or GRE) tunnel between the ingress and egress PE routers. No apriori configuration of the remote tunnel endpoints is needed. Note that these tunnels are NOT IGP- visible links, and routing adjacencies are not supported across these tunnel. Note also that the set of remote tunnel endpoints is NOT known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. ------------------------------------------------------------------------ Regards, -- Enke > > > > (2) Redback's implementation does not require manual configuration of > > and GRE tunnels in this case. We have tested the interoprability > > with another implementation that does require manual configuration. > > I don't doubt that this can be made to work. However, there are out-of-band > assumptions here beyond simple support for "MPLS over GRE" which was my initial > point. e.g., in order to interoperate, a "soft" GRE tunnel node must make > assumptions that every node it is sending a GRE encapsulated MPLS packet to is > either (1) manually configured to accept MPLS over GRE from that endpoint, or > (2) is a PE which is participating in the same "soft" GRE system, learning > endpoints from BGP updates or some other method. This is, of course, made easier > when nodes are simply configured to allow MPLS over GRE/IP from any source IP > address, but this also substantially increases the spoofing concerns for MPLS > over GRE/IP at that node. > > IMHO, if an implementation is going to be made to dynamically learn the > destination address for an MPLS over IP enabled endpoint from BGP, including an > attribute to explicitly identify the ability to receive said MPLS over IP > packets goes a long way to overcome blackhole situations where one could end up > sending tunneled packets to a PE which isn't able to receive and process them > correctly. > > Thanks, > > - Mark > > > > > Regards, > > > > -- Enke > > > > * From: W. Mark Townsley > > * Date: Mon Mar 15 13:19:37 2004 > > > > Please see inline. > > > > > >>Yakov Rekhter wrote: > > > > > > ------------------------------------------------------- > > > >>>Mark, > >>> > >>>i heard there is a way to run MPLS for layer3 VPN(2547) > >>>service without needing to run label switching in the > >>>core(LDP/TDP/RSVP) but straight IP (aka iMPLS). > >>> > >>> ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt > >>> > >>> See also Mark's talk from the last NANOG > >>> > >>> http://nanog.org/mtg-0402/townsley.html > >>> > >>>That requires to run L2TP. An alternative is to run GRE (or even plain > >>>IP). The latter (GRE) is implemented by quite a few vendors (and is > >>>known to be interoperable among multiple vendors). > >>> > >>>The only multi-vendor interoperable mode of GRE that I am aware of requires > >>>manual provisioning of point-to-point GRE tunnels between MPLS networks > >>>and to each and every IP-only reachable PE. > > > > > >>I guess you are *not* aware of the Redback implementation of 2547 > >>over GRE, as this implementation is (a) available today, (b) > >>interoperable with other implementations of 2547 over GRE, and (c) > >>does *not* require manual provisioning of point-to-point GRE tunnels > >>between MPLS networks and to each and every IP-only reachable PE. > >> > >>And, just for the record, (stating the obvious) I don't work for Redback. > > > > ------------------------------------------------------------------------ > > > > Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? > > (Just guessing as the principal author used to work for Redback). > > Thanks for the update, I was in fact not aware that companies other > > than Redback had implemented it. You didn't name those companies, but > > I will happily stand corrected here. > > > > In any case, the point I was trying to make was that there is more than > > one way to do "MPLS over GRE" and that they are not all necessarily > > interoperable as you seemed to imply in your message. You have helped > > to make that quite clear. > > > > The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN > > support without requiring any manually provisioned tunnels (and works for > > "mGRE" or L2TPv3). > > > > http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt > > > > The question to ask is whether the extension you mentioned above is > > truly necessary for supporting 2547 over GRE. The Redback implementation > > I mentioned above is an existence proof that the extension is *not* > > necessary for 2547 over GRE that does *not* involve manually provisioned > > GRE tunnels. > > > > [clip] > > > > - Mark > > > > >
|