The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

On Tue, Jul 02, 2002 at 10:51:52AM +0100, neil.2.harrison@bt.com wrote:
> Eric,  please see below....I think this is the answer you seek (though I
> suspect you may not like it).
> 

yeah, probably...:) see inline

> regards, Neil
> 
> > -----Original Message-----
> > From: Eric Osborne [mailto:eosborne@cisco.com]
> > Sent: 02 July 2002 03:32
> > To: Shahram Davari
> > Cc: 'erosen@cisco.com'; Eric Osborne; George Sheng; 
> > scullptor@yahoo.com;
> > mpls@UU.NET
> > Subject: Re: your mail
> (snipped>
> > Maybe you and I are just on different planes.  In simple words, so
> > folks like me who actually deploy the stuff can understand, what is
> > the fundamental problem with LDP's load-sharing that doesn't also
> > exist in IP, and how is this fundamental problem different from
> > whatever it is that MPLS-TE (CR-LDP or RSVP) does?
> 
> NH=> The key issue at question is this:
> 
> IP (inc IPinIP) maintains the cnls paradigm for any-any connectivity.  This
> is fine as *each/every* pkt contains absolute addressing information.  Let
> me put this another way....each/every pkt contains a *connectivity
> verification function*.  Here, the fundamental networking concept is a
> *routing domain*, and the key requirement is to ensure correct connectivity
> therein (as provided by absolute per pkt addressing).

This is where I start to turn my head sideways as I look at my
screen.  I hope maybe it's just a terminology thing, so let me parse
out your sentence and we'll see where I've gone wrong.

"absolute addressing information", to me, sounds like "enough
addressing information to get the packet to its final destination,
i.e. an end station".  Right?  If so, wouldn't that be true for cases
like IPinIP when the IP core doesn't know about addresses at the IP
edge (a la gre tunnels)?  Or do you mean something else?

I also don't see how this turns into a "connectivity verification
function".  What about an IP packet (or IPinIP) inherently has more
verification than IPinMPLS?  And isn't this turning into an OAM
discussion again, rather than talking about loadsharing?

> 
> If you want a co paradigm......because you want stronger QoS/survivability
> assurances (that can be fault managed and measured, and even partitioned on
> a *per customer* basis when required, eg VPNs)......which uses a relative
> addressing mode (ie link-connection unique-only addressing like labels
> (MPLS), VPI/VCI (ATM) or DLCI (FR)) then only p2p trail entities
> make sense.

I'm not sure I buy into the argument that the co paradigm is the only
way to do stuff like qos/survivability/etc.  Granted, you are far more
a co-paradigm guy than I am, so you know this area better, but I
suspect that means you're walking around with a co-paradigm-shaped
hammer, looking for a nail.  Of course, the same thing could be said
about my connectionless bias, so really there's no easy way out, here.

I'm also not sure what you mean by "link-connection unique-only".  You
mean a switching identifier on a packet that's relevant to a
particular link?  Not true for packet-mode MPLS, as a global label
space has its advantages, but I don't see how that has any bearing on
traffic management.

But whatever the argument, isn't the same is true for IPinIP where the
outer IP address is your PE (or whatever your term is) and the inner
IP is relevant to your customer, right?

> Here, we need to introduce a signalling or NMS set-up/tear-down capability,
> and the fundamantal networking concept is the *connection* itself, and the
> fault/performance management of such is the critical piece. 

ah....OAM again...me and my ten-foot pole are going somewhere else
now...

> 
> General LDP with mp2p merging network entities is neither one of these
> models nor the other.  It uses the relative addressing transfer mode of the
> co paradigm with the aim of satisfying the goal of the routing domain cnls
> paradigm.  But now LDP introduces new failure mode weaknesses that were not
> present in the true IP cnls model due to the relative addressing per
> link-connection which are not network-wide unique (unlike the case for IP
> where they are).

But not necessarily for IPinIP.  

>  Further, because of the SPF mode we have to introduce
> load-balancing.....so we 'break' the simple co label-forwarding idea of MPLS
> (because of LDP limitations);  though this is not the real problem it's
> merely one symptom.....just like the fact we can't have QoS/survivabily
> isolation between VPNs with like-DS-class merging across VPNs using
> LDP....the real problem is what I mentioned previously.

I guess I don't see how load-balancing breaks any sort of CO model,
other than the fact that the CO protocols don't have loadsharing.  So
I see how it's different, I don't see how that makes it broken.

> 
> So in conclusion, only 2 network models make sense:  true cnls for any-any
> behaviour and true p2p co where harder QoS/survivability behaviour
> assurances are required (though to be fair, one can still have some
> reasonable management capabilities with p2mp entities).  LDP mp2p however is
> a hybrid that offers no compelling advantages (over either using IPinIP or
> p2p LSPs as required) and only creates problems/weaknesses from my analysis
> of it.  I have talked to enough people now to know I/Shahram are far from
> alone in this view.....however, I do realise not everyone has reached this
> point of understanding yet.

I guess the fundamental piece I'm still missing is that I don't see
how LDP is any different from IP at the forwarding level.  At least in
one implementation, given the same topology and the same set of data,
the traffic pattern across the network will look the same whether the
traffic the network carries is IP or IPinLDP.  Given that the traffic
pattern is the same whether or not LDP is used, how does that make LDP
*bad*?  I will agree that LDP hasn't made anything _better_ in this
picture, but we already had the "why use LDP at all" discussion a few
weeks ago.  I'm just trying to understand the basic objection to LDP,
when the forwarding looks the same as IP.  And I don't mean the OAM
side, but the loadsharing side; loadsharing is how we started this
topic (I think), so I'd like to keep it there.

thanks...



eric

> 
> Hope that helps.
> 
> regards, Neil