The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

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.  

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.  

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.