The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi Eric:

<snipped>
> 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, 

Could you elaborate on "under certain circumstances"? I would presume that
if that was the offered label binding, the upstream LSR was expected to use
it.

> 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. 

Yes.

> 
> 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.  

Consistent with 3032

> In practice, though, it is difficult to make E obey this restriction. 

Agreed, although as I note below, of you don't need the V4/V6 part, any
label will do and has no wierd semantics assocaited with it...
> 
> 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.  

yes, if it offered it, nothing further required. If it didn't offer it, (for
example offered implicit NULL and got explicit NULL as a top label, then I
would presume the ingress originated the explicit NULL as an IP PID
(although I do not know why it would do so). OR if E offered another label,
and when popping that label found an explicit NULL would similarly assume
that it originated with the ingress.

> 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, 

one where it offered explicit NULL? Different teams implementing different
features ;-)

> and I  think we've also seen cases where P throws the  packet away rather
than 
> sending a "malformed" packet.  

This is what I presume removing the restriction would address.

> These  lead to lack of  interoperability.  

agreed

> 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. 

I think it's a bit more subtle. If it is a top and a bottom label at E as a
result of any operation (P doing PHP, P not doing PHP and E popping a
previous top label etc.), then E attends to the V4/V6 type. 

If it is a top and not a bottom label at E, then it is just a label and if
not offered by E then it is a fault.

IMHO this is a bit bizzare and not what I would design from a clean sheet,
but seems to correspond to actual usage. Realistically if I did not want to
attend to V4/V6 type, ANY label would do to stunt double for the way
Explicit NULL is used, the implementation merely needed to pick any one
non-reserved value to use where it offered explicit null today and would
then be compliant with 3032 as written.


> 
> - 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".)

Not quite clear on the implications of that other than that the link has a
"default" label for LSPs terminating at E.

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

I think I just talked myself out of removing the restriction ;-) except if
we need to document existing practice.

cheers
Dave