The MPLS WG Archive

[neil.2.harrison@bt.com]

Curtis....some small observations:

<snipped>

> This is some detail on the text above where I said "see below".  The
> L3PID is significant for an LSP regardless of stack depth.  The L3PID
> of the top label should not conflict with the lower L3PID, and if so,
> the setup should be rejected.  The L3PID must exactly match the one
> immediately below it unless the outer L3PID is MPLS, in which case any
> inner L3PID is allowed, but the outer label no longer provides the
> payload type.  The midpoint LSR usually do not know anything about the
> lower labels so all L3PID specific tricks are disabled.
	NH=> This seems to work only for a 1:1 client/server LSP nesting
arrangement.  What happens when one wants a lower level server LSP to carry
several client LSPs each having a different L3PID?

	> (KP=>) Note too for IP VPNs and for BGP-free cores, traceroute
will not work
	> (easily) -- intermediate LSRs don't know whom to send the ICMP
error
	> to.  Yes, one may be able to hack around this, but it ain't
pretty.

	This is solved by sending the ICMP forward through the LSP.  The
	egress should be able to look up the destination in the ICMP packet
in
	the correct VPN forwarding table if private address is used.
	NH=> I agree with Kireeti on this.  Why should an IP layer OAM
function be invoked in response to a MPLS layer problem....noting that this
argument can be extended to other defects besides TTL expiry as you are
aware?  If I was a VPN customer using one or more transit MPLS/LSP providers
I would not want to see ICMP pkts for defects sourced in their networks when
they themselves are not being told there is a problem, ie lack of MPLS layer
OAM.  This also ignores the fact that (i) the ICMP pkt may not be routable
(or difficult to route) or (ii) that the LSP client is not IP.  Solutions to
defect handling in MPLS really ought to be specific to the MPLS fabric and
not rely on other layer's OAM functions....otherwise we can get future layer
evolution problems.  We do, however, need a method of conveying forward
derfect indications between layers at the server-> client adaptation point.
This is standard practice in most other technologies and indeed IP relies on
such mechanisms today for fast defect detection eg AIS from SDH->ATM->IP
say.