Subject: RE: Query on draft-ietf-mpls-label-encaps

From: Shahram Davari <[email-masked]>
Date: Mon, 16 Oct 2000 10:46:07 -0700

Hi Curtis,

The egress node of an LSP, knows that it is the egress of that LSP. So the
penultimate node could basically swap the top label with any label (not just
0, 2) and the egress LSR (knowing that it is egress point)could pop it. So
my questions are:

1) Why do we need explicit null labels?
2) Why do we have two explicit null labels 0 and 2?

Regards,
-Shahram

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, October 16, 2000 9:32 AM
> To: Shahram Davari
> Cc: [email-masked]'; Sudhanshu Jain; [email-masked]; 
> Yakov Rekhter;
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Query on draft-ietf-mpls-label-encaps 
> 
> 
> 
> In message 
> <9DC5E2ABE65BD54CA9088DA3194461D6010C99E6@BBY1EXM01>, Shahram Davari
>  writes:
> > Hi Curtis,
> > 
> > Although you are right in saying that L3PID could determine 
> the L3, but this
> > is limited only to REVP-TE. CR-LDP does not have such a 
> field in its label
> > request, and besides this is not required by label-encaps draft.
> 
> Does anyone use CRLDP?  :-)
> 
> > So I think that the current IPV4/IPV6 explicit null labels 
> are needed to
> > addresses the scenarios in which L3PID does not exist (such 
> as CR-LDP case).
> > 
> > Regards,
> > -Shahram
> 
> CRLDP needs to get fixed to carry an L3PID.
> 
> Generalized MPLS has a G-PID which is redundant for RSVP but fixes the
> CR-LDP problem.
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Oct 2000 13:59:49 -0400

In message <9DC5E2ABE65BD54CA9088DA3194461D6010C99F1@BBY1EXM01>, Shahram Davari
> 2) Why do we have two explicit null labels 0 and 2?

Whether "we" need these depends on who "we" is.  Some routers cannot
forward at full line rate if they have to do a lookup to determin that
they have to POP a label and then do a second lookup on the underlying
protocol.  These routers need to send label 0 or 3 for IPv4 and 2 or 3
for IPv6.  If they would rather special case 0 and 2 in hardware and
do the appropriate lookup, they can.

I don't see that these do any harm.  Just leaving label 3 in place as
a signaling convention and dropping 0 and 2 would be OK by me.  I
don't see a compelling reason to drop them since supporting them is
almost trivial.

Curtis