Subject: RE: mpls encapsulations

From: Shahram Davari <[email-masked]>
Date: Wed, 19 Sep 2001 06:54:37 -0700

Hi,

> -----Original Message-----
> From: Hemant P. Kelkar [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2001 6:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: mpls encapsulations
> 
> 
> Hi Everybody !
> 
> I have some doubt regarding the MPLS encapsulation inside IP and other
> protocols.
> What is the aim behind the following encapsulations:
> #1. MPLS in IP (reasons other than tunneling MPLS via IP networks)

I don't think there is any other reason. 

> #2. MPLS in ATM and FR (reasons other than heterogeneous n/w 
> interface)

To reduce the number of control planes to one (i.e., MPLS).

> #3. MPLS in IP in Ethernet (MPLS/IP/Ethernet)

This is not a good architecture. There is no reason to have IP, you could easily do MPLS/Ethernet.

Yours,
-Shahram

> Regards,
> Hemant

---

From: Aris Kyriakopoulos <[email-masked]>
Date: Wed, 19 Sep 2001 19:40:05 -0400 (Eastern Daylight Time)

> I don't think there is any other reason.

I haven't seen this subject brought up on this list (seems to be more a
PWE3 activity).  But I always had a doubt about this.  What do you gain
from encapsulating MPLS in IP to tunnel through a non-MPLS-aware network?

Looking at the more common L2 encapsulations:

ATM - can use VCID notification between the label distribution peers
FR - to my knowledge, nothing yet
POS - SONET mux or other L1 switching equipment

So the goal is to be able to connect non-adjacent MPLS peers.  2 of the 3
L2 protocols above already have mechanisms to do this without going back
up the stack to L3.  In this situation, the extra IP encapsulation does
nothing more than add more overhead (plus, consider that it is most likely
that the original MPLS payload will be IP itself!  Wow, I love recursion
;-) )

As for Frame Relay, if there is a method similar to ATM VCID notification
I would appreciate being corrected.  If not, I would think that leaves two
choices to achieve the Holy Grail (2 non-adjacent LSRs communicating over
a FR interface): MPLS-in-IP, or a VCID-like notification method.  Which is
more palatable?  I would think the latter.

Plus, another alternative would be for a service provider to connect a FR
LSR at the edge to an ATM LSR in the core.

> To reduce the number of control planes to one (i.e., MPLS).

I think the WG charter should answer this question!

> could easily do MPLS/Ethernet.

As another poster commented, this goes back to the situation in Problem
#1.  I'm sure that there are scenarios where you would run into a LSR --
Ethernet switch -- LSR combination.  Since I can't think of any, I will
defer this question to someone else!

Cheers,
Aris