Subject: Re: A question.

From: [email-masked]
Date: Thu, 19 Apr 2001 10:20:57 +0530

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 <[email-masked]> 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.

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.

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.

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"?
********************
    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.
****************
--
Eric

You wrote:

> hi eric!
>      another solution here might be that, if we recieve a packet (at LER
> ingress) for which there is no existing binding available to a FEC. It should
be
> considered as a control packet and a request (downstream on demand) should be
> generated to the next hop(determined using L3 information) to give a binding
and
> the received packet(s) should be forwarded as normal IP forwarding till the
> point the complete LSP is set up. am I missing something?
>
> regards
> sumit
>
> Eric Gray <[email-masked]> on 04/16/2001 05:42:18 PM
>
> To:   "Bakshi, Sanjay" <[email-masked]>
> cc:   [email-masked] (bcc: Sumit Chauhan/HSS)
>
> Subject:  Re: A question.
>
> Sanjay,
>
>     Your assumption is slightly faulty.  :-)
>
>     The term LER (label edge router) is somewhat misleading,
> because it seems to define a box (router) as opposed to a
> function (label edge routing) which a box may or may not
> support.  People tend to think of an LER as a box that supports
> the edge routing functions of MPLS ingress and egress.  That
> does not mean that it absolutely must find an LSP for every
> packet it receives - or that it absolutely must pop the last
> label off of every packet that it sends.  It's behavior WRT any
> packet it receives or sends depends largely on the capabilities
> of the interfaces on which it was received or will be sent and
> the apriori existence of an FTN (or ILM) entry.
>
>     There is no 'data-driven label binding operation' as you imply
> in your question.  If an LER does not have a 'FEC entry' in its
> FTN (FEC to NHLFE) table, it either forwards the packet using
> IP routing (if it is able to do so) or it drops the packet (possibly
> returning a 'destination unreachable' error to the sender - again
> if it is able to do so).
>
> --
> Eric Gray
>
> You wrote:
>
> > Hello,
> > I have a simple question for which I think I know the answer but cannot find
> > the reference in the RFCs to de certain. What happens when a unlabeled
> > packet is received by a LER and there is no FEC entry corresponding to the
> > packet?
> > I know this falls under the data-driven label binding operation, in which
> > LDP is trigerred by the arriving packet. But I have not found a reference to
> > it in any RFC to back my assumption up.
> > Any pointers?
> > thanks
> > sanjay

---

From: Eric Gray <[email-masked]>
Date: Thu, 19 Apr 2001 09:05:46 -0400

Sumit,

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

    Please see comments below.

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

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

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

> we dont have an FEC?" so is there a concept of "default FEC as well". Maybe one

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.

Check out drafts available at:

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