The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Aug> msg00130



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

Encapsulating MPLS in IP or GRE

  • From: Chris Chase <chase@research.att.com>
  • Date: Wed, 28 Aug 2002 12:51:36 -0400
  • Cc: Mark Duffy <mduffy@quarrytech.com>, Art King <art@frost-king.com>, mpls@UU.NET
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

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