The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

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

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

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