Subject: RE: your mail

From: [email-masked]
Date: Tue, 2 Jul 2002 19:15:08 +0100

Thanks Eric.....please see my further observations and attempted answers to
your questions.

regards, Neil

> -----Original Message-----
> From: Eric Osborne [mailto:[email-masked]]
> Sent: 02 July 2002 14:12
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: your mail
> 
> 
> On Tue, Jul 02, 2002 at 10:51:52AM +0100, 
> [email-masked] 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:[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>
> "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?
NH=> No, this is precisely what I mean.  Within the constraint of a given
routing domain, cnls forwarding must use unique addressing.  When I say
'absolute' addressing I mean its unique wrt to the whole routing domain and
not a single hop within it.....when I say 'relative' addressing its only
unique to an interface (like case of labels, VPI/VCI or DLCIs) which is the
normal mode of stringing together a set of hops (=link-connections) to
create a co trail (though the trail termination points must have absolute
addressing).  Further, and although it might not be immediately obvious why
its relevent here, when one creates trails via concatenated relatively
addressed link-connections the pkts alone cannot convey all the required
QoS/survivability attributes (as they have to in a cnls mode)......you have
to take pkts_+_parent_trail into account, and its the trail entity that is
the key/primary focus for proper fault-management.  Hope that helps clear up
what I mean. 
> 
> 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?
NH=> They are fundamentally different.  An IP address means something to the
whole of its routing domain.  A label only means something to an interface
(or at largest a node....though a few labels have been globally reserved for
specific/network-wide functions, eg null labels).  So if an IP pkt ends up
in the wrong place it will (usually) get re-directed back on
course....however, if a labelled pkt ends up in the wrong place it may be
showing a valid label for its next hop and get misdirected (or if not it
will get immediately black-holed....and it will usually get black-holed at
some higher levels when labels fail to match anymore or, if it makes to the
the client level, than at this highest LSP->clinet adaptation point).  So we
can get (and have seen) misrouting defects because the same labels are used
on different/disjoint hops.

>  And isn't this turning into an OAM
> discussion again, rather than talking about loadsharing?
NH=> Well, fault-management is fundamentally important to us
operators....and if you fail to get this key-stone right then whatever
follows will not have a good foundation.  Loadsharing is one by-product of
using LDP because there is no felxibility in routing choice.....but its not
the only by-product of LDP.
<snipped> 
> 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.
NH=> Not at all....if that is your impression of what I said you have
completely misunderstood me.  The main message I gave was this:
-	true cnls = good for certain applications
-	true p2p co = good for certain applications
They both have important roles and neither should be regarded as supplanting
the other.  I believe we can do the vast majority of networks services with
both these modes.  What I don't see however is a compelling reason for mp2p
LDP over the other modes.
<snipped>
> 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?
NH=>No....in both the operator and the customer routing domains the IP
addresses relevant to each are unique to the whole of each (disjoint)
routing domain.  This is not true for labels, VPI/VCI, DLCI when these are
link-connection only unique.
> 
> > 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...
NH=> Where might that be LSP-PING perhaps?......same problem, just far more
complex attempt at solution.  Seriously though, fault-management of networks
is really important to operators.
<snipped>
> 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.
NH=> IP uses memoryless best-match look-up and LDP uses pre-calculated paths
that have locally significant 'tags' applied to them (this is a co trait).
By definition these are subject to different failures modes....and I know
its the OAM stuff you don't like again but LDP data-plane forwarding has new
failure modes that don't exist in IP.  Why else do you think some of your
colleagues are working on LSP-PING?    Further, MPLS can carry protocols
other than IP....so this raises other aspects that need consideration (and
where fault-management solutions really need to client (and server)
agnostic).

> I'm just trying to understand the basic objection to LDP,
> when the forwarding looks the same as IP.
NH=> And that is the crux of the point....it may *look* the same when its
working but it does not fail the same.
>  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.
NH=> Load-sharing is only 1 aspect of MPLS/LDP they don't tell you about too
loudly about at sale time when explaining the 'simple' label-swapping
paradigm ;-)......and just focussing on this topic misses the bigger picture
anyway.  You need to look at the whole space to draw meaningful conclusions.

thanks and regards, Neil

---

From: Eric Osborne <[email-masked]>
Date: Tue, 2 Jul 2002 16:27:44 -0400

> the key/primary focus for proper fault-management.  Hope that helps clear up

So a few things have happened in this thread.

It started off, if I recall, with a statement about "LDP's inability
to TE".  It then went into hashing and other such stuff.  And it
appears like it's also touching on OAM.

I am familiar with the OAM discussion; it's happened a few times
already, as you know.  So rather than going down that path again, let
me ask a question (particularly to you and Sharam) - is there anything
wrong with hashing for loadsharing purposes *other* than the fact that
it makes doing OAM the way you've proposed difficult, if not
impossible?    

eric