Subject: RE: A question.

From: "Bakshi, Sanjay" <[email-masked]>
Date: Wed, 18 Apr 2001 13:33:25 -0700

Hi Eric,
Thanks for the clarification.
So, this implies that LSP setup (via LDP etc) is triggered either by 
routing changes or by management e.g. in case of ERLSP and packets 
for which 'FEC entry' is missing in FTN are handled as you suggested.
Is that fair to say?
thanks
--sanjay

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Monday, April 16, 2001 5:12 AM
To: Bakshi, Sanjay
Cc: [email-masked]
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