Subject: RE: Vpns vs explicit null label

From: "David Allan" <[email-masked]>
Date: Wed, 29 Jan 2003 12:45:42 -0500

I get the feeling the genie is out of the bottle, and this sort of half-PHP
is really the provence of the LSR that originated the label. Only
consequence of such a spec change is the upstream LSR should not squawk or
place limitations on such a label if received.

One potential issue is figuring out who initiated the label in a PHP
scenario. The ingress may stack it unsignalled as a PID, the egress may
offer it upstream as a half-PHP. If there is PHP-LSP stacked on top of it,
technically the PH LSR is clueless as to where the label originated. So long
as you are not doing things like PHP of service labels at the egress PE, and
muxing test tools on the service label using explicit null at the ingress
PE, you should be OK ;-)

cheers
Dave

> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, January 29, 2003 10:51 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Vpns vs explicit null label 
> 
> 
> 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
> 
> At 10:09 AM 1/29/2003 -0500, Eric Rosen wrote:
> 
> >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 14:01:10 -0500

David> this  sort  of  half-PHP is  really  the  provence  of the  LSR  that
David> originated the label.  Only consequence of such a  spec change is the
David> upstream LSR should  not squawk or place limitations  on such a label
David> if received. 

When  the egress node  E sends  an LDP  message binding  explicit null  to a
particular FEC,  it is  telling the penultimate  node P that,  under certain
circumstances, when P receives an MPLS packet from some third node, P should
swap the top label  of that packet with explicit null.  P  will do this when
the FEC corresponding to the incoming label of the packet is the same FEC to
which E has bound explicit null. 

Strictly speaking E should only bind explicit null to a particular FEC if it
somehow knows that any packets which P sees that correspond to that FEC will
be carrying label stacks of no more than one label.  In practice, though, it
is difficult to make E obey this restriction. 

I think what you're saying is that  if E gets a packet with explicit null at
the top of the stack, it has  gotten what it asked for, and should handle it
in the obvious  way.  I agree with  this, and I'd assumed that  this is what
would generally be done.  But the spec never made this clear.  So we've seen
cases where  E throws the packet away  as malformed, and I  think we've also
seen cases where P throws the  packet away rather than sending a "malformed"
packet.  These  lead to lack of  interoperability.  I think  we've also seen
cases where P, when processing a packet with more than one label, will treat
explicit  null  as  if  it  had   been  implicit  null;  this  at  least  is
interoperable.

So perhaps what should really be required is: 

- When  the egress  LSR pops  off  explicit null,  it should  attend to  the
  IPv4/v6  type.   Other nodes  treat  the two  kinds  of  explicit null  as
  equivalent. 

- When asked  to put explicit null on  the top of a label stack,  one MAY do
  so, but one SHOULD treat explicit  null as if it were implicit null.  (Not
  sure about that "should".)

- When  creating a label stack  with explicit null somewhere  in the middle,
  one MAY put it there, but one SHOULD simply remove it.