The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Sumit,

    Oh well, I tried to keep this discussion off of the list... :-)

    Please see comments below.

You wrote:

> hi eric!
>      Thanx a lot for the clarification. You made perfect sense here but I still
> have a few points that are embedded below as
> *****sumit****
>
> regards
> sumit
>
> Eric Gray <eric.gray@sandburst.com> on 04/18/2001 08:13:45 PM
>
> To:   Sumit Chauhan/HSS@HSS
> cc:
>
> Subject:  Re: A question.
>
> Sumit,
>
>     There are plenty of examples of ways in which you can
> establish LSPs (and therefore FECs) based on packets
> you receive.  As you point out, the mechanisms exist to
> support creation of an LSP on pretty much any basis you
> care to imagine.
>
>     But there are implications of doing what you suggest.
> A very similar suggestion was made about a year ago and
> it got mostly the silent treatment.  Bad history and other
> things worked against it then and will undoubtedly work
> against it again.
>
>     The fundamtental issue is that - at least for normal IP
> packets - you either use topology driven or flow driven
> path setup.  There is no reason to have both.
>
>     Look at it this way: if you are using topology based
> LSP setup and don't have a FEC for a packet, then you
> don't have a route for it either.  Who are you going to
> ask for a label from?  Are you going to ask for a label
> for a host address or 32 bit address prefix, or are you
> going to try to guess what an appropriate prefix length
> would be?  If you did have a route, then you are waiting
> for a label from the next hop (either because you asked
> for it already, or because the next hop is supposed to
> send one without you asking) or you already know you
> are not going to get one - therefore, why would you ask
> for one just because you have a packet?  What happens
> when you get another packet - do you send yet another
> request?
> ******sumit********
> few points here are
> 1. this means that the actual setup of the LSP shall happen once the network(its
> routers ) come up and exchange the initial routes (using some IGP) and then
> reach their stable state. Till the point they have first echanged the routes and
> exchanged lables(set up the LSPs) there can be no MPLS based forwarding
> possible. That is perfectly all right.

Using the optimal label distribution solution for a given
network deployment, and assuming that IP forwarding is
possible without labels, MPLS based forwarding lags
IP based forwarding by a little bit.  This 'little bit' can be
as little as zero in the case where labels are distributed
(piggyback) with route advertisements.  Whatever this
little bit is, it is unavoidable - therefore, it is good that
it is also acceptable. ;-)

>
>
> 2. From this it seems that "unsolicited downstream" seems to be the most logical
> solution as it is simpler for each LSR to generate lables to its
> directly-connected routes as I do not see any real value add in a upstream LSR
> asking for a label in this scenario.

The choice of whether downstream unsolicited (DU) or
downstream on demand (DoD) is used is more often a
result of the label retention mode that makes sense for
the technology that connects a pair of LSRs.

What might be argued on the basis of the lag between
IP forwarding and MPLS forwarding is whether or not
to use ordered or independent control.  However, this
choice should also depend on the capability of an LSR
that will eventually end up being an intermediate LSR,
in any given LSP, to forward IP packets to the correct
next hop if it:

    receives labeled packets from an LSR peer to which
    it has independently distributed labels and

    has not yet received a corresponding label from the
    correct next hop.

In this case, there is some cost to the system if the
LSR distributes labels independently but is required
to drop labeled packets until it receives a useful label
from the next hop for the LSP.

So, the decision as to what control mode an individual
LSR will use and whether to use DU or DoD label
distribution involves more than the concern over the
lag between IP and MPLS forwarding capability.

>
>
> 3. The other point is that it is a pretty simple solution once we are
> considering the topology based forwarding but in case we have to do flow based
> forwarding and along with that we want to have resource reservation. In that
> scenario I always beleived it should be something like "label on demand only and
> when needed only" because else we may land up reserving resources we may no use
> later. But I am sure I might be missing something here. Please clarify.

The currently defined signaling methods for setup
of non-best-effort label switched paths have at
least three things in common:

1    use of ordered control

2    use of downstream on demand

3    availability of path directing capability

I don't necessarily agree that any of these things
will always be necessary in setting up LSPs with
contractual resource requirements.

>
>
> 4. The other problem that strikes me here is that almost all routers also
> maintain "default routes". As you suggested that "whom do we ask for a lable if
> we dont have an FEC?" so is there a concept of "default FEC as well". Maybe one
> with prefix "0"?

I could be wrong, but I do not believe that it is the
normal case for routers to have default routes for
the context in which they are routers.  I think it is
common for hosts to have a default route to get
them to a router.  I believe it is also common for
an interior router to have a default route to an
exterior gateway router in certain deployments.
But I believe that - for example - interior routers
having default routes to other interior routers is a
good way to turn IP packet forwarding into a form
of finger pointing exercise.

>
> ********************
>     Suppose you do know both the next hop and (AIBM)
> the correct prefix length (AIBM) and you send a request
> for a label.  You've simply passed the problem on to the
> next hop.
>
>     So, you might ask, what if I have a route entry and I
> know the next hop and the right FEC to ask for?  Why
> can't I wait until I actually have a packet to request a
> label?  The answer is real simple: there's absolutely
> no reason to do so and every reason not to do so.
>
>     The topology based setup defined in MPLS is every
> bit as scalable as the routing it is based on - so you
> don't gain any advantage from not having to setup an
> LSP that you'll never use.  Nor is it very likely, in most
> real network deployments, that there will be instances
> of such LSPs in the first place.
>
>     Delaying LSP setup until a packet is received is one
> great way to place a strain on routing implementations
> and drop a lot of packets.  However many packets may
> be dropped (for a particular stream) while I wait for the
> topology based setup to complete (for that stream) will
> be increased by the amount of time it takes me to get
> the first packet for that stream.  And topology based
> setup can be even faster if using independent control.
> With topology based LSP setup, most streams will not
> see a single packet drop as a result of not having an LSP
> setup already. With flow based LSP setup, at least one
> stream for each FEC will see at least one packet drop.
> ******sumit*****
> Point well taken here. But again I think things should seem diffrently if we
> look at an FEC that has not just destiation address and prefix but things for
> QoS and CoS incl. resourse reservation.

Check out drafts available at:

    http://www.ietf.org/ids.by.wg/mpls.html

>
> ****************
> --
> Eric
>