Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE

From: Kireeti Kompella <[email-masked]>
Date: Tue, 13 Jun 2000 17:09:20 -0700 (PDT)

> Observation/plea:
> 
> I am getting increasingly concerned that we have an MPLS trail object, ie an
> LSP, but that the trail termination points (either source or sink) seem to
> be a movable feast depending on (i) different people's interpetation of the
> IDs produced to date, and/or (ii) the functional behaviour that is being
> considered.  Can I therefore make the plea that if a further informational
> ID is produced to clarify these matters (which Bora orginally suggested)
> that we make sure that there is architectural consistency across all
> functional behaviour wrt to where the trail termination points are.

I don't think that the LSP termination point is a movable feast.
However, there *are* three types of terminations: PHP, label 0 (for
IPv4), and a regular (i.e., non-reserved) label.  Implementations
seem to be converging on the first (PHP), but that might just be
tunnel vision on my part.  Using a real label requires something
along the lines of "pop, send packet back to self, do another lookup"
which may or may not be acceptable as a normal mode of operation.

Note that in either the PHP or label 0 cases, almost all useful info
about the LSP carrying the packet is lost (we just had a thread of
discussion on this).  LSP stats at the egress (for example) are a
victim of PHP/label 0.

However, if the reason for wanting to know which LSP the packet came
in on is OAM, then there are other solutions (e.g., having the OAM
packet carry this info), in which case PHP or label 0 works fine
for data packets.

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jun 2000 11:47:29 -0400

> which may or may not be acceptable as a normal mode of operation.

You do seem to have tunnel vision.  Others support using a real label.
PHP offers some drawbacks and no benefits for architectures that can
handle a real label with no performance hit.  The egress can decide to
request PHP on an inner label if the depth of the label POP would be
enough to cause a performance hit (the VPN is inside a TE tunnel
inside a PSC-1, inside a PSC-2, etc, all terminating at the same
egress).  For some routers the lookup is fast enough to POP a few
labels before slowing down a 40 byte IP packet with shims on it.

> packet carry this info), in which case PHP or label 0 works fine

With PHP you can only count OAM packets, not packets received.  If the
purpose is to accurately measure loss through an LSP (for example, one
carrying an AF class), then PHP requires you to send enough OAM
traffic to make a significant sampling, which could be a lot.  If OAM
is for continuity testing only, then PHP is not a problem for OAM.

Curtis