The MPLS WG Archive

[Mark Duffy <mduffy@quarrytech.com>]

Hi Chris,

If I understand you correctly, you are talking about providing IP
connectivity (only) to a reseller who places their own PE boxes outside
your network and then sells 2547-type VPN services to their customers.  Is
that right?  If so I don't see why it should matter if they use mpls-in-ip
or mpls-in-gre.  Either way achieves the ability to run over a non-mpls IP
backbone.

--Mark


At 12:51 PM 8/28/02 -0400, Chris Chase wrote:
>Oops.  Sent before I was done.
>
>In the approach described in
>
>http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip-2547-01.txt
>
>the tunnels between PE pairs are dynamic.  No tunnel configuration 
>required.  In fact an implementation might chose to not even need to 
>create a "tunnel" inteface if the tunnel header is viewed as an outbound 
>encapsulation for a given BGP next hop.  Much like there is no 
>"interface" created for downstream label switching when using MPLS as 
>the tunneling method between PEs.
>
>One descrepancy I see between the the dynamic approach of the above 
>draft and
>draft-rosen-mpls-in-ip-or-gre-00.txt is the latter requires MTU path 
>discovery for each "tunnel" destination.  A static configured MTU or min 
>MTU learned over the history of dynamic tunnels used would be prefered.
>
>In the customer's case mentioned below, by using the GRE tunnels made 
>the customers creation of hierarchical VPNs (carrier's carrier) 
>completely transparent to our service offer.  They could use the 
>existing service as defined without ordering or configuring anything 
>special in our service network.  Specifically, we did not have to 
>certify, deploy, provision and support MPLS CE-to-PE.  Instead it looks 
>just like our standard IP service interface definition.
>
>
>
>Another application, perhaps less important, in the VPLS context when 
>using BGP discovery and MAC address learning is that you do not need a 
>label that is upstream PE specific (the label block method).  You know 
>which upstream PE sent the packet from the source address of the tunnel.
>
>Chris
>
>
>Chris Chase wrote:
>
>> This is the usage I find the most attractive. 
>> Actually, we had a customer who wanted to do carrier's carrier to 
>> create their own VPNs for their tenants.  The approach taken was to 
>> use GRE tunnels.  The customer did not like having to create numerous 
>> tunnel interfaces.
>>
>>
>> Mark Duffy wrote:
>>
>>> Hi Art, are you suggesting that there is something about the MPLS VPN 
>>> case
>>> in particular that favors mpls-in-gre over mpls-in-ip?  If so would you
>>> explain that?
>>>
>>> Thanks, Mark
>>>
>>>
>>> At 01:32 PM 8/15/02 -0700, Art King wrote:
>>>  
>>>
>>>> Connecting MPLS VPN PE's over non-MPLS core in a Carrier is a
>>>> good example case for GRE usage.
>>>>
>>>> ----- Original Message -----
>>>> From: "Eric Rosen" <erosen@cisco.com>
>>>> To: "Shahram Davari" <Shahram_Davari@pmc-sierra.com>
>>>> Cc: <mpls@UU.NET>; "Loa Andersson" <loa.andersson@utfors.se>; "George
>>>> Swallow" <swallow@cisco.com>
>>>> Sent: Wednesday, August 14, 2002 11:27 AM
>>>> Subject: Re: Encapsulating MPLS in IP or GRE
>>>>
>>>>
>>>>   
>>>>
>>>>> In some  cases you  might already have  a GRE  tunnel through 
>>>>> which  you
>>>>>     
>>>>
>>>> are
>>>>   
>>>>
>>>>> supporting a routing adjacency.  It should be possible to send MPLS
>>>>>     
>>>>
>>>> packets,
>>>>   
>>>>
>>>>> as  well  as  IP  packets,  through  such  tunnels,  and  this  
>>>>> requires
>>>>>     
>>>>
>>>> an
>>>>   
>>>>
>>>>> MPLS-in-GRE encapsulation.
>>>>>
>>>>> There are also  other cases in which GRE tunnels (as  opposed to IP
>>>>>     
>>>>
>>>> tunnels)
>>>>   
>>>>
>>>>> are  commonly used,  and you  should be  able to  send MPLS  packets
>>>>>     
>>>>
>>>> through
>>>>   
>>>>
>>>>> them.
>>>>>
>>>>>     
>>>>
>>
>