Subject: bug in draft-ietf-mpls-label-encaps-08

From: Puneet Agarwal <[email-masked]>
Date: Fri, 13 Oct 2000 18:43:45 -0700

Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with
hierarchical tunnels.

On pg 5 it states:
              i. A value of 0 represents the "IPv4 Explicit NULL Label".
                 This label value is only legal at the bottom of the
                 label stack.  It indicates that the label stack must be
                 popped, and the forwarding of the packet must then be
                 based on the IPv4 header.

 My understanding was that when a LSR got a label 3 from the egress LSR
during signaling, if the LSR was able to do a pop then it would perform a
penultimate hop pop otherwise it would just swap the incoming label with
label 0 and then the egress LSR would do the actual pop.

However, the draft states that the label 0 is only valid at the bottom of
the stack. This implies that to support hierarchical tunnels one of 2
conditions have to be true:

(a) All LSRs supporting hierarchical tunnels, need to support PHP (so they
never swap label 0 on the stack)

OR

(b) The "label value is only legal at the bottom of the label stack"
constraint should be removed from the draft for label 0.

Since support for PHP is not a requirement for LSRs, the draft should be
updated to remove the constraint for label 0, to support hierarchical
tunnels.

-Puneet

---

From: Eric Rosen <[email-masked]>
Date: Mon, 16 Oct 2000 13:07:54 -0400

Puneet> My understanding was  that when a LSR got a label  3 from the egress
Puneet> LSR during signaling, if the LSR was  able to do a pop then it would
Puneet> perform  a penultimate  hop pop  otherwise  it would  just swap  the
Puneet> incoming label  with label 0  and then the  egress LSR would  do the
Puneet> actual pop.  

I don't think  this understanding accords with section  4.1.5 of draft-ietf-
mpls-arch-07.txt:

        "... a  binding of Implicit NULL may  be distributed only
        to LSRs which can support that function."

---

From: Bora Akyol <[email-masked]>
Date: Mon, 16 Oct 2000 10:23:20 -0700

Eric

Unfortunately, this is the way we observe Implicit Null being used in the field.
Also, I have not seen a negotiation mechanism for RSVP-TE for PHP support.

I also think that the arch spec may contradict the label encaps spec.

Bora

---

From: Eric Rosen <[email-masked]>
Date: Mon, 16 Oct 2000 15:04:00 -0400

Bora> I also think that the arch spec may contradict the label encaps spec. 

Gee, maybe the primary author of  the arch spec should meet with the primary
author of the encaps spec and talk this out ;-)

Actually, I  don't believe  the encaps spec  says anything  whatsoever about
when you are supposed (or not supposed to) bind Implicit Null to a FEC.  Nor
does the  arch spec say anything about  Explicit Null.  So I  don't see what
the contradiction would be. 

Bora> I have not seen a negotiation mechanism for RSVP-TE for PHP support. 

Whether the  various label distribution protocols contain  all the necessary
mechanisms is an orthogonal issue.  

Eric> I  don't  think  this  understanding  accords with  section  4.1.5  of
Eric> draft-ietf-mpls-arch-07.txt 

Bora> this is the way we observe Implicit Null being used in the field. 

I've heard  of various  strange modes  of operation having  to do  with php,
implicit null, and explicit null, but  I hadn't heard of this one.  However,
the procedure should work, as long as the label in question is at the bottom
of the stack, and  is likely to work in other cases  as well.  If you happen
to  have a  system which  can't do  php connected  to a  system  which can't
refrain  from using Implicit  Null, this  makes for  a good  workaround.  At
least, until you run into a system which can't handle Explicit Null. 

The fact that a prohibited  procedure works could be considered a deficiency
in the specs, or it could be considered  to be a case of "be liberal in what
you accept, conservative in what you send".

Bora> The fact is that people are using Implicit and Explicit NULL labels in
Bora> the manner  originally described and  it would be nice  to acknowledge
Bora> that.

At some  point, we should  do a survey  of the implementations and  see what
they do.   If there  are a number  of mutually  interworking implementations
which do not  follow the spec, then  of course it makes sense  to modify the
spec to bring those implementations into compliance.