Subject: What to do when label has error?

From: "Sherry Wei" <[email-masked]>
Date: Wed, 23 May 2001 10:08:27

Hello,

I have a doubt about the real operation in the case that the LSR can't find 
the according ILM or NHLFE. What will it do then? Drop the packet and send 
the ICMP message to the source, or strip off the label stack and deal with 
the packet with IP forwarding meanwhile send the ICMP message?

Sherry
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: "Akshat Kapoor" <[email-masked]>
Date: Wed, 23 May 2001 16:17:05 +0530

Sherry,
    Refer to rfc 3031 section 3.18 and 3.22. If the LSR can determine
through some external means that forwarding the packet is not going to
result in a loop (or any other harm) than it can forward the packet.
Otherwise it MUST drop the packet.  The rfc is silent about generating ICMP
messages in such a situation. If the LSR prefers to generate an ICMP message
than it should be able to route the ICMP Message to the source. (The LSR
might not have the routing information to the source. Also, if you are using
a shim header than you might not be able to identify the network layer
encapsulation correctly (in case of an invalid label)).
    In the second case, i.e. if the LSR can identify somehow that forwarding
the packet unlabeled is not going to cause any harm and resorts to IP
Forwarding after stripping the label stack than it should not(IMHO) send an
ICMP error message to the source.

Akshat

---

From: "Mohan Kumar S" <[email-masked]>
Date: Wed, 23 May 2001 16:44:50 +0530

Akshat and Sherry,
Refer RFC 3032 Section : 2.3. on "Generating ICMP Messages for
Labeled IP Packets"

regards,
Mohan Kumar.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Akshat
Kapoor
Sent: Wednesday, May 23, 2001 4:17 PM
To: Sherry Wei; [email-masked]
Subject: Re: What to do when label has error?

Sherry,

Akshat

---

From: David Charlap <[email-masked]>
Date: Wed, 23 May 2001 10:33:07 -0400

Akshat Kapoor wrote:
> 
>     Refer to rfc 3031 section 3.18 and 3.22. If the LSR can
> determine through some external means that forwarding the packet is
> not going to result in a loop (or any other harm) than it can
> forward the packet.

And this is a big IF.  When LDP or CR-LDP are used to signal the LSP, a
transit router has no way of knowing for certain if the payload contains
IP packets or something else.  (RSVP-TE carries the L3 protocol ID in
the LABEL_REQUEST objects, so transit routers should know if the payload
is IP or not, assuming that the ingress node didn't lie about it.)

> Otherwise it MUST drop the packet.  The rfc is silent about
> generating ICMP messages in such a situation.

ICMP is only meaningful if the payload is IP.  If it's something else,
ICMP would be completely inappropriate.

-- David

---

From: David Charlap <[email-masked]>
Date: Wed, 23 May 2001 10:37:05 -0400

Sherry Wei wrote:
> 
> I have a doubt about the real operation in the case that the LSR
> can't find the according ILM or NHLFE.

If the ILM is not found, then the packet is dropped.  There is no
question about this.

If there is an ILM but no NHLFE, then the router will probably drop the
packet.  If the router is able to forward the payload without looping
(which implies that the router knows what the L3 protocol is), then it
may pop the label and forward the payload as an unlabeled packet.  If it
can not be certain what the payload is, or can not guarantee that it
won't loop, then it must drop the packet.

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 23 May 2001 13:08:09 -0400

David,

    LDP only supports IPv4 and IPv6 FECs, consequently it should
be fair to assume that packets transported using such an LSP are
either IPv4 packets, IPv6 packets, or (hierarchically) MPLS labeled
packets enroute to a known IP (v4 or v6) address.  This is the case,
because an LDP-based LSP will move around based on IPv4 (and,
someday, IPv6) routing therefore, the packets transported MUST
be destination addressed as expected if there is only one label.

    An implementation may elect to retain state relative to the FEC
used to establish it.  In fact, some implementations may not be able
to discard this state information.  An implementation can also easily
tell when a packet only has one label. Therefore, in the LDP case,
it is not the uncommon case that a packet can be forwarded.

    Under the same conditions, if an LSR decides to drop such packets,
the likelihood that it will be able to successfully route ICMP messages
back to the source of the message is the same (in the single label case)
as it would be if the packet had been routed using IP instead of MPLS.
Therefore, it should not be a problem to handle ICMP error processing
in the LDP, single label case.

    The multiple label case is different, however, I recently had a trace
pointed out to me where a two-level labeled MPLS packet was being
used to carry an ICMP echo message where the reply was being sent
using simple IPv4.  Therefore, empirically, it would appear that there
may be applications where - even in the multiple label scenario - a
user may decide to configure their network to deal with it...

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Wed, 23 May 2001 13:22:58 -0400

David,

    I agree with the 'spirit' of what you are saying, however, an ILM
and no NHLFE makes no sense.  An ILM maps an incoming label
to a set of NHLFEs and - while it is not explicitly stated - such a
set makes no sense if empty.

    I believe what you are getting at is that an LSR that gets a label
it knows nothing about will discard the packet.  This I agree with.
However, how an implementation deals with the case where it
knows of a label which it has given out and it currently has no usable
NHLFEs for that label, is a local matter for the implementation.  In
other words, how an implementations 'memory' of the labels it has
given out maps to an 'ILM' is an internal issue.

    For example, many implementations might use a 'default' NHLFE
which looks, acts and even quacks like a bit-bucket.  This would
allow them to have a useful ILM when there is no useable next hop
information at the time.  But such an implementation may also have
a set of NHLFEs that are more sophisticated.

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Wed, 23 May 2001 15:26:27 -0400

David,

    One more comment, in addition to what I have already said
in response to this post.  Please see below.

> is IP or not, assuming that the ingress node didn't lie about it.)

And this is a big assumption.  Even if it is true, however, the use of
the protocol ID is pretty much intended to be a secret shared between
end points since the intention is that the packets are routed along an
explicitly determined path - rather than as they might be routed using
any particular L3 protocol.  RFC 3031 does explicitly state that there
is a risk of looping packets if they are partially transported on an LSP
that is explicitly routed.

--
Eric

---

From: David Charlap <[email-masked]>
Date: Wed, 23 May 2001 17:43:46 -0400

> be destination addressed as expected if there is only one label.

Who is to say that LDP is the only protocol running on the switch?

You can't look at a label and know what protoco it should have come
from.  So you still can not determine that an unknown label is being
used to wrap IP traffic.

-- David

---

From: David Charlap <[email-masked]>
Date: Wed, 23 May 2001 17:53:50 -0400

Eric Gray wrote:
> 
>     I agree with the 'spirit' of what you are saying, however, an
> ILM and no NHLFE makes no sense.

I agree.  But Section 3.22 of RFC 3031 describes that exact situation. 
And this section tells implementors to drop such traffic unless the
switch can ensure that the data can be properly forwarded without
looping.

I am assuming that the situation described ("the ILM does not map the
packet's incoming label into an NHLFE") is different from "there is no
ILM for the label".

> a set of NHLFEs that are more sophisticated.

If a default NHLFE is created for every ILM, then the situation
described will never happen.  But I question the usefulness of having
default NHLFEs.  They are likely to create situations where packets will
loop, or the router may try to forward non-IP traffic as if it was IP.

(Yes, I am aware that LDP doesn't support non-IP traffic.  But RFC 3031
is not LDP.  And the concepts of ILM and NHLFE are forwarding, not
signaling concepts.)

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 23 May 2001 18:10:40 -0400

David,

    You're right in saying that context is important.  So why do you
comment on my remarks out of context?

    Earlier, you replied to Akshat Kapoor who said

> > > not going to result in a loop (or any other harm) than it can

- by saying -

> from.  So you still can not determine that an unknown label is being

You said "when LDP or CR-LDP are used to signal <an> LSP,
a transit router has no way of knowing for certain if the payload
contains IP packets or something else.

For labels signaled using LDP, this is plainly false.  There is no
context in which my statement to you can be interpreted to mean
that I believe that an LSR can interpret any unknown label to mean
anything at all.  In fact, I said pretty near exactly that on a separate
posting, in which I said (exactly):

"I believe what you are getting at is that an LSR that gets a label
it knows nothing about will discard the packet.  This I agree with."

Please do not attempt to put silly words in my mouth for me - I can
do that well enough on my own.  :-)

--
Eric Gray

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Wed, 23 May 2001 18:59:05 -0400

> switch can ensure that the data can be properly forwarded without

Personally, I think that the specific wording you refer to
somewhat over-steps the bounds of what an architecture
specification should do because it makes assumptions that
depend on a specific implementation.  It does it, I feel sure,
for a good reason - which is to try to keep the description
simple.

One way that same text could have been phrased is:

"When a labeled packet is traveling along an LSP, it may occasionally
happen that it reaches an LSR at which the incoming label does not map
to an NHLFE, even though the incoming label is itself valid.  This can
happen due to transient conditions, or due to an error at the LSR which
should be the packet's next hop."

The wording of the original specification implies that an ILM
will exist in an implementation when there is a valid label and
that ILM does not necessarily point to an NHLFE - and this
is not necessarily true for all implementations.   I did - at one
time - write an internet draft that pointed out that there were a
lot of implementation specific assumptions in the architecture
draft.  Others reported similar issues and at least some of them
were removed.  This one just doesn't seem that important...

> packet's incoming label into an NHLFE") is different from "there is no

Note that the text does say that the label is valid.  I suspect
that - like many people - you are equating

    <valid label> = <ILM exists>

Whether or not this is always the case is not an important point.
If this is the way you want to express your point, then I agree
with your point (if not your expression of it).

> loop, or the router may try to forward non-IP traffic as if it was IP.

Pardon me.  In the architectural model, an ILM maps to an NHLFE.
There is absolutely no requirement that there be a separate NHLFE
for each ILM.  A single 'default' NHLFE will do.  And apparently the
term 'bit-bucket' is dating me - it means the place you put dead bits
when you no longer need them.  If you are mapping all packets to the
bit-bucket by default, then you hardly need to concern yourself about
looping packets as a result.

You can argue that this is trivializing your distinction of an ILM that
does not map to an NHLFE.  I would disagree.  If you assume that an
ILM always maps to some NHLFE (including the 'default' NHLFE),
then how an implementation deals with a legitimate label becomes
clear in every case.  For example, if - as a result of signaling - I know
that I have a fall back mode that allows me to forward packets using
IP, then I can have a corresponding fall-back NHLFE.  Otherwise, my
fall-back NHLFE might be 'see a packet, drop a packet'.  I am simply
trying to increase the level of general understanding for the terms and
concepts.

> is not LDP.  And the concepts of ILM and NHLFE are forwarding, not

Actually, you may be thinking more of RFC 3032.  Much of RFC 3031
is devoted to signaling aspects of the MPLS architecture. The term
LDP was first coined in RFC 3031.

In at least some implementations, control of ILMs and NHLFEs
depends mostly on signaling.  These terms are needed as much to
understand signaling as they are needed to understand forwarding.
For example, an NHLFE does not just disappear: it is removed and
this is typically done in cooperation with (if not by) the process
that is also handling signaling.

--
Eric

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Thu, 24 May 2001 07:44:38 +0530 (IST)

David,
       One statement in ur reply is confusing. I am quoting it here :
>(RSVP-TE carries the L3 protocol ID in
>is IP or not)
But if the label itself is wrong, i.e the router does'nt recognize the
label then how can it  know the L3 protocol associated with that label.
The transit routers will associate L3 protocol with labels and store it in
the LIB, so that information can only be accessed if the label is
recognized ..
Is'nt it ???

tomar

---

From: David Charlap <[email-masked]>
Date: Thu, 24 May 2001 15:37:52 -0400

Nagendra Singh Tomar wrote:
> 
>        One statement in ur reply is confusing. I am quoting it here:
>
>> (RSVP-TE carries the L3 protocol ID in the LABEL_REQUEST objects,
>> so transit routers should know if the payload is IP or not)
>
> But if the label itself is wrong, i.e the router does'nt recognize
> the label then how can it  know the L3 protocol associated with that
> label.

Oops.  You are right.  Nothing carried by signaling will work to help a
router determine the L3 protocol of a label it knows nothing about.  My
mistake.  The L3PID in RSVP is really only useful to the egress router.

-- David