Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE

From: [email-masked]
Date: Wed, 14 Jun 2000 00:34:24 +0100

Curtis is making an important observation towards the end of his comments
below.........which, if we remove the specific case that is being considered
here, boils down to the more generic question 'where is the LSP trail
termination point?'.  Further, I was just looking through
draft-ietf-mpls-diff-ext-05.txt and several issues struck me that are all
related to the discussion here.  For example (this is not exhaustive).

Since the LSP trail termination is a movable feast (thanks to the notion of
PHP) then this will impact:
-	defect processing...and indeed OAM functional arch [The point that
Curtis makes below]
-	restoration/prot-sw processing.....since this is dependent on above,
and of course knowing where the correct source/sink end points of the LSP
are
-	QoS processing....since this is dependent on above
-	TTL processing ....though this is an orthogonal issue
-	DS processing.......which is what draft-ietf-mpls-diff-ext-05.txt
discusses.

One final observation......in draft-ietf-mpls-diff-ext-05.txt it says that
the choice of the 'uniform' or 'pipe' model is done on a LSR basis.  I have
the concern that this may need to be done on a per LSP basis (and not on a
per LSR basis).  If true, this will get very messy on interworking and might
incur significant configuration problems.

Regards, Neil

> -----Original Message-----
> From:	Curtis Villamizar [SMTP:[email-masked]]
> Sent:	Tuesday, June 13, 2000 3:16 PM
> To:	Kireeti Kompella
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> In message <[email-masked]>, Kireeti Kompella
> writes:
> > > Two POPs are needed to terminate a VPN tunnel.
> > 
> > Not if you use PHP.  You start popping one hop earlier, e.g., if
> > X is the PE attached to the customer, and Y the penultimate hop,
> > Y pops the "outer label" and forwards the packet with the "inner
> > label" identifying the VPN to X.  X looks at the inner (only!)
> > label, pops it and knows which customer to forward the packet to.
> > 
> > Corner case: a one-hop LSP carrying VPN info: don't put any "outer
> > label" in this case.
> > 
> > > Three might be needed
> > > if the outer tunnel on the VPN took its last hop through a FA-PSC.
> > 
> > Picture time:
> > 
> >     A ---- B ==== C ==== D ==== E ~~~~ customer
> >             <-43-  <-28-  <--3-
> >     <--71-- <-------- 3 -------
> > 
> >     <-- 32 for VPN to customer --
> > 
> > There's an FA-LSP from B to E.  E sends D an implicit NULL label,
> > D sends C label 28, C sends B 43.
> > 
> > Now, there's another LSP that wants to tunnel through the above
> > FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
> > B sends A label 71.
> > 
> > A and E agree on label 32 for the VPN.
> > 
> > The label stack for a packet to the customer is as follows:
> > 
> >     A ---- B ==== C ==== D ==== E ~~~~ customer
> >               43     28
> >        71
> >        32     32     32     32
> > 
> > Note that 71 -> 43 is not really a swap as much as a pop (PHP),
> > followed by a push (equivalent, but you get there differently).
> > 
> > It is interesting to first work out the case where the tunneled
> > LSP terminates beyond the tail of the FA-LSP, as the above example
> > is another 'corner case'.
> > 
> > Kireeti.
> 
> 
> Kireeti,
> 
> PHP does remove POPs and make it easier to implement an egress LSR but
> it makes it very hard to collect statistics of packets and bytes
> received on an LSP at the egress.  Recall the discussion of OAM and
> loss measurements.  There is no way to count at the egress if the
> labels are lost.  Therefore in your example there is no way to
> determine loss over the FA-PSC tunnel or over the tunnel from A-E.
> 
> Curtis

---

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

> related to the discussion here.  For example (this is not exhaustive).

Since there may be some confusion about the reasons for doing or not
doing PHP, I'd like to provide a little more detail on some of these
tradeoffs.

> and of course knowing where the correct source/sink end points of the LSP

Restoration is not dependent on the above unless there is a disconnect
between signaling and forwarding as was discussed on the OAM thread.
If hardware and software are still working (ie: internal parity is
working, software hasn't gone insane), then defects in transmission
(ie: SONET layer detects fault) will be restored within 10s of msec if
local-protect is enabled and regardless of whether local protect is
used signaling will be sent to the ingress (path tear and IGP
flooding).  This is also why OAM has not been perceived as a need (not
until recently, and perhaps not with sufficient consensus).

> -	QoS processing....since this is dependent on above

This can be a problem.  If the same DSCP means something different
when it comes from two different ingress interfaces, then the
classification of traffic is lost when the PHP pop occurs.  This is
significant if that classification is needed by the egress LSR, since
it can no longer be recovered.

> -	TTL processing ....though this is an orthogonal issue

This seems to only affect the way TTL hiding is done (ie: decrementing
the IP TTL only once for the whole tunnel).

> incur significant configuration problems.

The draft does preclude setting uniform or pipe on a per LSP basis.
This would need to be signalled.  The ingress should be able to
request one or the other.  The egress can then reject a request for
the model requested if it cannot support it (if the router is
configured for the other and does not have per LSP capability or the
router only supports one model).  The ingress can then decide whether
to accept the alternate model or not bring up the LSP.

I'm not sure that this flexibility is needed.  It may be better if the
wording in draft-ietf-mpls-diff-ext-05.txt declared the signaling to
set uniform or pipe on a per LSP basis as out of scope rather than
precluding it so that a later document can define the signaling if
there is a need.

Curtis

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 16 Jun 2000 15:28:03 +0200

Curtis,

>precluding it so that a later document can define the signaling if

This is a fine approach. We'll take this as a Last Call comment on draft-ietf-mpls-diff-ext-05.txt.
thanks
Francois