Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE

From: Kireeti Kompella <[email-masked]>
Date: Wed, 14 Jun 2000 10:59:58 -0700 (PDT)

Curtis,

> You do seem to have tunnel vision.  Others support using a real label.

That's good to know.  Can you enumerate some of the 'others'?
What was the primary motivation?

Fortunately, an egress is in charge of its destiny, at least as far
as the last label is concerned.  As you point out, an egress can
(with some forethought) request PHP if the label stack gets too deep.

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

Agreed.

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 Jun 2000 14:26:30 -0400

> What was the primary motivation?

Avici is one.  We always send a real label unless you have an older
card that we no longer ship in which case PHP is needed.  I'll let
others speak for themselves.

> (with some forethought) request PHP if the label stack gets too deep.

Right.  Toss a packet as malformed if that number of POPs is exceeded
so as not to blow wire rate lookup.  Since an LSR controls its own
destiny in this regard, any packet with too many POPs is malformed.
Allow the user to configure a higher limit on the POP depth if average
payload size is significantly greater than 40 on their network.  With
this scheme the inner LSP (labels closer to the bottom of the stack
and the LSP that are last to be set up) will have PHP after the POP
limit is exceeded.  At the egress counters will be available for the
outer LSP only (the ones that don't use PHP).

> > is for continuity testing only, then PHP is not a problem for OAM.

Thanks,

Curtis