Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE

From: Eric Gray <[email-masked]>
Date: Tue, 13 Jun 2000 11:23:17 -0700

Eric,

	I am not sure it should be removed.  Perhaps
its should either be extended, or reduced.  If the
restriction is eliminated entirely, then so should
the concept of Explicit NULL labels be removed. It
might be more work to take out this restriction
then it would be to remove Explicit NULL labels.

	It is possible that an implementation may
rely on this usage when its upstream neighbor is
not able to perform PHP.  Having separate labels
for IPv4 and IPv6 Explicit NULL makes sense for
an implementation that wants to be certain which
encapsulation follows the label to be popped.

	We can argue that it is up to the local
implementation to use labels that allow it to 
distinguish the underlying encapsulation in the
"pop and look again" mode.  In that case, because
labels are downstream allocated, it was NEVER
necessary to define well known values for IPv4
and IPv6 Explicit NULL labels.  An implementation
is free to use ANY label - or set of labels - to 
accomplish this function.

	However, because we have 2 forms of Explicit
NULL labels - one for IPv4 and another for IPv6 -
there are problems with allowing either Explicit
NULL label to be followed by additional labels in
a label stack:

o	What does it mean to have an IPv4 Explicit
	NULL label as opposed to an IPv6 Explicit
	NULL label when either one could be followed
	by an MPLS label stack?
	o	Does it mean that - should you want to
		look beyond the stack, you will find
		an IPv4 L3 header?
	o	What happens if more than one Explicit
		NULL label appears in the same stack
		and one is for IPv4 and the other for 
		IPv6?
o	Why not define another well known Explicit 
	NULL label for the "followed by more labels"
	case?
o	Is it ever legal for an ingress to mix and 
	match - for example - IPv4 and labeled data
	packets on the same LSP?
	o	this will work at the egress - for the
		same reason it works at the penultimate
		hop - because the Explicit NULL label
		either will or will not have the bottom
		of stack bit set;
	o	will every implementation look at the
		bottom of stack bit when they receive
		an IPv4 Explicit NULL label?

	Because it is likely that some implementations
may have built this restriction in (by ignoring the
bottom of stack bit for Explicit NULL labels), it will
be necessary to include a means to allow the egress to
force the ingress to use distinct LSPs for labeled and
unlabeled packets.  

	How would this be done using current signaling 
protocols?

	Finally, why did we define well known Explicit
NULL labels for IPv4 and IPv6 in the first place?
Since the labels are allocated by the implementation
that has to interpret them, that implementation could
choose to use any labels (or sets of labels) it wants
to.  There must have been some reason for deciding to
use well-known values.  What was it?

--
Eric Gray

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, June 13, 2000 10:24 AM
> To: Shahram Davari
> Cc: 'Tony Li'; [email-masked]; Bora Akyol; [email-masked]'
> Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> 
> Shahram> The Encaps-draft says that the IPV4/6 Explicit Null 
> Labels are only
> Shahram> legal if they are the sole label stack entry.
> 
> It does say that, but I think that is just a mistake.  This 
> restriction will
> be removed in the next draft. 
>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 13 Jun 2000 14:26:48 -0400

My proposal is to replace the requirement that explicit nulls only appear as
the sole  label on the stack with  the requirement that they  only appear at
the bottom of the stack. 

This doesn't change the fact that the S bit needs to be on when these labels
appear. 

We used well-known values so that an implementation wouldn't have to look up
the label in  its database of allocated label entries, only  to find that it
then needs  to look up  an IP destination  address.  Checking a  label value
against a  couple of well  known values is  much simpler than doing  a table
lookup.