The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Oct> msg00053



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

[mpls] mpls vs IPv6

  • From: Loa Andersson <loa@pi.se>
  • Date: Tue, 12 Oct 2004 15:30:36 +0200
  • Cc: mpls@ietf.org, Jung Janos <jj306@hszk.bme.hu>
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.7.2) Gecko/20040803

All,

here we go again ;)

It is one of the "popular" misconceptions that mpls ever
was intended to improve node capacity.

If you go back to the problem statement from IETF 38
(Memphis April -97) you will find that there were
four items in the problem state node performance
was not one of them. Network performance were, but
that had nothing to do with the throughput of the
routers (nodes) but with the ability to load more
traffic on to the network. A couple of meetings later
we extended the "performance" conceot and started to
call it "internet traffic engineering".

I remember people coming up to me in Memphis and
Munich (and later) trying to explain that routers did
forward at line speed and consequently mpls was not
needed. They were rather surprised when I agreed on
the line speed, but pointed out that mpls were not
intended to solve that non-problem.

/Loa

Peter Ashwood-Smith wrote:

> 
>   You are correct that many of the original motivations for MPLS are no 
> longer really valid.
> Forwarding speed as you point out is less relevant; Encapsulation can be 
> done other ways such that MPLS would only be required at the service level;
> 
>   The one thing that you cannot easily do without label substitution 
> forwarding is non shortest path forwarding. If you ever want a subset of 
> your traffic to diverge from the routes IP would give, you either have to:
> 
>    A) use source routing (stateless).
>    B) use label substitution (statefull).
>    C) Create multiple instances of another hop-by-hop protocol i.e 
> multiple forwarding tables and a way to figure out which one to use, 
> i.e. DHCP/flow etc. could key which table ..
> 
>   This is of course true regardless of the address size or how QOS is 
> implemented per hop. Right now B) seems the most practical option 
> although with bandwidth getting cheaper by the nanosecond it can't be 
> long before new forms of A) arrive.
> 
>   Peter
> 
> 
> -----Original Message-----
> From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org]
> Sent: Tuesday, October 12, 2004 4:26 AM
> To: Marc Binderberger; Jung Janos
> Cc: mpls@ietf.org
> Subject: Re: [mpls] mpls vs IPv6
> 
> 
> May I be bold enough to ask the reason MPLS was ever
> deployed?
> 
> some more queries inline.>
> 
> --- Marc Binderberger <marc@sniff.de> wrote:
> 
>  > Hello,
>  >
>  > > With MPLS I can create MPLS VPNs, QoS can
>  > (really?) be
>  > > granted to packet flows, and routing is more
>  > faster.
>  >
>  > Forget about the "faster". Today the forwarding
>  > happens either in
>  > hardware and is wire-speed for IPv4/IPv6 as well. Or
>  > it's the same
>  > underlying mechanism in software, e.g. the "CEF"
>  > table in Cisco
>  > routers.
>  >
> 
> And how many such end addresses are there? Do we need
> to throw out the existing gear to move to IPv6?
> 
>  > QoS for MPLS is in first place the same as for
>  > IPv4/IPv6. You have 3
>  > bits, like the (old) IPv4 Precedence. In theory more
>  > QoS information
>  > could be coded in the label, of course.
>  >
>  > > IPv6 has the "Flow label" field wich makes routing
>  > faster
>  >
>  > again, the "faster" doesn't matter with today's
>  > ASICs in place.
>  >
> 
> But then tomorrow's ASICs will be faster than today's
> so why not wait for tomorrow :)) till they are built
> ??
> 
> 
>  > > and has less header overhead than ipv4 (or
>  > mpls+ipv4)
>  >
>  > n*4+20 vs. 40 - less overhead?
>  >
>  > > And i think flow label could have the same use as
>  > > the mpls label value...
>  > >
>  > > How is MPLS to IPv6 related?
>  >
>  > as already answered: the same as MPLS to IPv4.
>  > Well, there is always a difference between theory
>  > and implementation.
>  > MPLS needs LDP (and RSVP depending on what you do),
>  > LDP uses IP UDP and
>  > TCP. Although informations within are "TLV" coded
>  > and thus expandable I
>  > haven't seen any IPv6-based LDP on my Cisco so far.
>  > Read: you may have
>  > IPv4 to run protocols like LDP to finally run MPLS
>  > carrying IPv6
>  > packets.
>  >
>  > > Are they technologies that have nothing to do with
>  > each other?
>  >
>  >  From a generic point of view: correct.
>  >
>  > > Or MPLS can bring new functionalities to IPv6
>  > networks (like to IPv4),
>  > > and
>  > > so mpls+ipv6 would have a sense?
>  >
>  > exactly. Hope I don't start a religious war now but
>  > look upon IPv6 as
>  > an IPv4 with larger addresses, a more structured
>  > approach to "ip
>  > options", avoiding fragmentation (on transit
>  > routers) and such. In
>  > short: more addresses ;-)
>  >
> 
>  > Same as for IPv4: TE capabilities, allows you to
>  > integrate ATM into
>  > your IP packet network, [...].
>  >
> But why woould I need ATM then?
> 
> 
>                
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                            loa@pi.se

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls