iMPLS benefit

Mark,

Please see inline.

in-line...

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

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

No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt.
Redback's implementation that does not require manual provisioning of
point-to-point GRE tunnels between MPLS networks and to each and every
IP-only reachable PE is *purely* an implementation matter, and does *not*
require any new communities and/or attributes.

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.

Both draft-nalawade-kapoor-tunnel-safi-01.txt and
draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt use BGP to advertise capabilities
for carrying MPLS-labeled packets over various encapsulation types. Proof of

And *neither* of these are requires in order to avoid manual provisioning
of point-to-point GRE tunnels.

Yakov.

Yakov Rekhter wrote:

No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt.
Redback's implementation that does not require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE is *purely* an implementation matter, and does *not*
require any new communities and/or attributes.

OK, you made me go out to www.redback.com and read about their implementation.

A quote:

"This means that the ingress router can learn these next-hop addresses through MP-BGP, and then dynamically append the GRE encapsulation and outer IP header to a VPN packet destined for an egress router. In essence, these GRE tunnels can be considered as �soft� or dynamic because they do not need to be configured. "

Whether it is implicit from the next-hop address in BGP, or explicit in the next-hop update via draft-nalawade-kapoor-tunnel-safi-01.txt or draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt, we are still talking about MP-BGP as the vehicle for advertising how to reach a PE by GRE. We now have identified three variants for MPLS over GRE in this thread, (outside of manually configured "hard" GRE tunnels) -- back to my original point that "MPLS over GRE" can mean a lot of things.

IMHO, a PE explicitly identifying that it can receive MPLS over GRE (or MPLS over foo) traffic is a bit safer and more deterministic than implicitly assuming it can from a learned next-hop address. I don't want to speak for another company, but perhaps Redback did too which is why they helped sponser draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt in the first place. Go knock on Rahul's cube now that the two of you work at the same company and ask him :wink:

- Mark