Subject: Vpns vs explicit null label

From: [email-masked]
Date: Wed, 29 Jan 2003 13:06:41 +0100

Hello,

I have a question on the explicit null label.

Issue
=====
Consider a 2-step approach:
1) Step-1: Setup of an LSP between 2 PE routers (say PE-1 and PE-2).
==> During LSP setup PE-2 indicates the use of the explicit null label.
2) Step-2: Send VPN packets through the LSP from PE-1 to PE-2.

In this configuration the VPN packets arrive at PE-2 with the VPN label 
beneath the explicit null label. PE-2 drops the VPN packets since RFC 3032 
indicates that the explicit null label can only occur at the bottom of a 
label stack.

Question
========
Then the question is:
* How can during the LSP setup between PE-1 and PE-2 be made known to PE-2 
that it should not use the explicit null label?
OR
Should the statement that <the explicit null label only occurs at the 
bottom of the stack> be relaxed?

Thanks for any help you can provide.

        Francis.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Jan 2003 10:09:35 -0500

Francis> Should the statement  that <the explicit null label  only occurs at
Francis> the bottom of the stack> be relaxed? 

This statement causes a lot of problems, and no one can seem to remember why
it is there.  Further, there are a number of cases in which it is awkward to
prevent explicit  null from appearing in  mid-stack. Not only  that, but the
specs  don't really say  what you  are supposed  to do  if you  do encounter
explicit null above another label, or if you are instructed (via LDP) to put
explicit null on a packet which already has a label stack.

So I would favor removing the  requirement that explicit null only appear at
the bottom of the stack.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Jan 2003 10:51:07 -0500

Probably an explicit null which is not at the bottom of the stack should not
be interpreted as indicating the protocol type of the payload. 

> others may have  hard-coded the condition in which  an explicit NULL label
> is not bottom of stack as an error

Yes, but that would be an example  of why "be liberal in what you accept" is
a good principle.

---

From: Eric Gray <[email-masked]>
Date: Wed, 29 Jan 2003 10:42:48 -0500

Eric,

    There remains the question of whether a specific "explicit NULL"
label might occur or in this case or either IPv4 or IPv6 explicit NULL
is acceptable.  Realistically, it is going to be an IPv4 explicit NULL
label now and for much of the forseeable future, but this is a hole we
might also want to address.

    One reason for bringing this up is that it is conceivable that some
implementations might not check the bottom of stack bit when dealing
with either explicit NULL label type while others may have hard-coded
the condition in which an explicit NULL label is not bottom of stack as
an error.  If we are going to potentially require people to "fix" these
implementations, we should make sure we are not setting them up for
more "fixes" down the road.  Or at least as sure as possible...

--
Eric Gray

---

From: Alia Atlas <[email-masked]>
Date: Wed, 29 Jan 2003 10:51:22 -0500

I agree that removing the restriction that an explicit null only occur at 
the bottom of the stack would be a good idea.

It does raise some questions, because there is an IPv4 explicit null and an 
IPv6 explicit null.  What we really want is just an explicit null, which 
means "pop off this label and then forward based on whatever's underneath".

Alia

---

From: Mark Duffy <[email-masked]>
Date: Wed, 29 Jan 2003 13:27:12 -0500

Under what circumstances would an LSR expect to receive a packet with one 
of the explicit null labels?

Usually, LSRs only receive packets with labels that the LSR has itself 
distributed.  Is that true for these labels?  Presumably not or there would 
have been no need to reserve specific values for them.

So, I presume the idea is that an upstream LSR may apply these labels even 
though they weren't distributed by the downstream.  But under what 
circumstances would this be done?  Is there any reason to apply these 
labels today?  Does anyone have a product that is doing so?  Or were these 
just reserved because they sounded useful at the time and might be used by 
some future application of MPLS.

-- Mark

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Jan 2003 13:34:30 -0500

Alia> What we  really want is  just an explicit  null, which means  "pop off
Alia> this label and then forward based on whatever's underneath". 

If  what's underneath  is  not MPLS,  then  the label  you  just popped  off
provides the only clue to what is underneath.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Jan 2003 14:07:36 -0500

Mark> Usually, LSRs only receive packets with labels that the LSR has itself
Mark> distributed.  Is that true for  these labels?  Presumably not or there
Mark> would have been no need to reserve specific values for them. 

Reserved  values were  used because  they  are easy  to look  up; it's  much
quicker to determine that the label is  one of a small set of constants than
it is to  look up a label in  your 20-bit lookup table.  When  a packet with
explicit null is received, the explicit  null needs to be detected, and then
the packet's IP  address needs to be looked up.  By  using a reserved value,
the time  to look  up the  label plus the  IP address  becomes approximately
equal to the time  to look up the IP address.  Without  a reserved value, it
would be approximately double that.

Of course,  once a reserved value is  used, it does become  possible for the
penultimate node  to put  on explicit  null even when  it hasn't  been asked
for.  By "be liberal in what you accept", this should be handled properly at
the egress.

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 29 Jan 2003 12:03:20 -0800 (PST)

Hi Eric,

A couple of points on my interpretation of explicit null that has been
implemented:

1. A penultimate hop router doesn't put on an explicit null on a packet if
the outgoing label stack is not empty. Hence it has the intelligence to
insert an explicit null only if the outgoing label stack is empty. This
takes care of the VPN case, the question on which started this thread. I
think this is the right thing as explicit null is needed for payload
determination or for MPLS QoS. If there is already a label in the outgoing
label stack that should take care of it..
                                           
2. As you said the destination PE does a "fast" lookup using the fact that
an explicit null is a reserved value.

3. Destination PE rejects an explicit null if its not at the bottom of
stack. I am yet to be convinced that this is not the right thing to do as
an explicit null shouldn't show up other than at the bottom of the stack
(Point # 1). I am not sure if being liberal on what you accept applies
that well to the forwarding path. 
That said if there is a reason why this can happen, I think its not hard
to remove this restriction, unless there is hardware out there that cannot
do this.

thanks,
rahul