Subject: RE: your mail

From: [email-masked]
Date: Tue, 2 Jul 2002 10:51:52 +0100

Eric,  please see below....I think this is the answer you seek (though I
suspect you may not like it).

regards, Neil

> -----Original Message-----
> From: Eric Osborne [mailto:[email-masked]]
> Sent: 02 July 2002 03:32
> To: Shahram Davari
> Cc: [email-masked]'; Eric Osborne; George Sheng; 
> [email-masked];
> [email-masked]
> 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).

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

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

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.

Hope that helps.

regards, Neil

---

From: Eric Osborne <[email-masked]>
Date: Tue, 2 Jul 2002 09:11:43 -0400

> suspect you may not like it).

yeah, probably...:) see inline

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

> (MPLS), VPI/VCI (ATM) or DLCI (FR)) then only p2p trail entities

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?

> fault/performance management of such is the critical piece. 

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

> where they are).

But not necessarily for IPinIP.  

>  Further, because of the SPF mode we have to introduce

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.

> 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