Subject: RE: Any disadvantage about MPLS?

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 5 Jun 2001 18:12:53 -0400

Another minor but worth mentioning disadvantage(s) are:
 
(1) There is no protection for shim header:
    Both L2 and L3 have their own checksum/CRC
    for respective headers/PDUs. But won't cover shim 
    header specifically. For example some L2s like ATM
    has checksum only for header (first label) not for 
    their payload.
   (shim header + IP header + data are in ATM payloads)

    It is difficult to rely on L1/L2 CRCs,
    even a single bit corruption in shim header
    may lead the LSP to different destinations
    not destined to!?!

(2) When many "bits" are available in hand (IPv4 IPv6 headers)
    to control the flow we can provide many features 
    (ranging from diff-serv, TOS, encryption, precedence, 
    fragmentation, control & many more options etc.)
    but expecting the same functionality with small number
    of bits in hand (shim header) is always difficult
    and disadvantages follow.
    
(3) Remember there are always some pros-and-cons for
    hope-by-hope forwarding and switching (in theory)
    (mean to say connection-less vs connection-oriented also)
    We have to weigh them both for our needs, in what expense?

 I am not going against MPLS, just to mention a few.
 If we start mentioning advantages, we can write a book 
 challenging Yakov ;-)

--Venkata Naidu

-> Hi ewliu!
-> 
-> one disadvantage of mpls is that a four byte shim header is 
-> inserted to every
-> network layer packet before being forwarded to data link layer, which
-> effectively increases the payload for data link layer.
-> 
-> Regards
-> Mohit
-> 
-> 
-> 
-> 
-> [email-masked] on 06/05/2001 02:56:17 AM
-> 
-> To:   [email-masked]
-> cc:   [email-masked] (bcc: Mohit Goel/HSS)
-> 
-> Subject:  Any disadvantage about MPLS?
-> 
-> 
-> 
-> 
-> It seems that MPLS is good for almost everything,from QoS to 
-> traffic engineering
-> and VPN.
-> 
-> I want to get some information about its disadvantages,any 
-> information will be
-> appreciated.
-> 
-> _____________________________________________
-> ??????????????????   http://shopping.263.net/hotsale/summer/
-> [???????? ????????] ????????????95963????????/??????263
-> 
-> 
-> 
-> 
->

---

From: Eric Gray <[email-masked]>
Date: Tue, 05 Jun 2001 18:58:25 -0400

Venkata,

    Sigh.  Why do we let ourselves be dragged down this path?

>     may lead the LSP to different destinations

Most people tend to feel that L1/L2 error detection is sufficient.

>     and disadvantages follow.

We cannot do much with 5 or more words worth of binary options
that we cannot also do with the one-word label stack entry.  Do
we truly need to differentiate more than 8 million (or so) flows in
every network box, and at every network interface?

>     We have to weigh them both for our needs, in what expense?

I like your (Freudian?) description of routing as hope-by-hope
forwarding and switching.  Cute.  :-)

>  If we start mentioning advantages, we can write a book

That might be a good idea.

---

From: Eric Gray <[email-masked]>
Date: Tue, 05 Jun 2001 20:12:29 -0400

Earlier, I wrote (snipped), in response to Venkata:

> > ...

Just to be clear, comparing apples to apples, you have to include
the 8 bit TTL and the 3 bit EXP field, along with the MPLS label
when comparing it to IPv4/v6 headers for informational content.
The one bit bottom of stack bit has nothing to do with forwarding
but there are similarly non-contributing bits in IPv4/v6 headers.

Part of the point is that the MPLS label stack gives a more efficient
means to aggregate flows (using MPLS tunnels) than - for instance
- IP-in-IP tunnels.  With improved efficency in aggregating flows,
20 bit labels, possibly with 3 bit EXP values, should be enough info
for network boxes/interfaces to process per-packet.

Of course, if a network entity wants to support fewer labels, they
are free to do so.

> > ...