The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <200012200433.UAA15414@kummer.juniper.net>, Kireeti Kompella writes:
> Hi Curtis,
> 
> > I am surprised to see you take such a hard stance on this.
> > 
> > (1) There should be no requirement that the midpoints of an LSR do special
> > processing for a particular L3PID.  (2) There should also be no
> > requirement that an LSR be completely ignorant of the L3PID.
> 
> I can live with (2) if you grant me (1).  Note that the L3PID is
> only valid (to my thinking) when the stack depth is 1.


That would only be the case if the L3PID on the outer tunnel (top) was
set up as MPLS.  If the L3PID was set up as IPv4, then only tunnels
containing IPv4 in the payload (other tunnels with a L3PID of IPv4)
should be placed inside.

I think this has been quite clear, but if not, we should make it
clear.  The right place might be the hierarchical draft.  See below.

> > If the MTU is passed back to the ingress of a TE tunnel, then the
> > ingress can fragment or generate the ICMP for packets with "don't
> > fragment" set.
> 
> We're on the same page so far.
> 
> > If the L3PID is IPv4, it is perfectly legitimate to send TTL expired
> > ICMP if TTL expires.  It is equally legitimate to ignore the L3PID and
> > not generate ICMP, or disable TTL decrement at all but the egress for
> > TE tunnels (where no loop is ever possible).  LSR that don't generate
> > ICMP are simply traceroute unfriendly and the path will pick up again
> > as soon as the TTL is large enough to reach the egress of the LSP.
> 
> Note that many SPs want tunnels not to show up in traceroute.

So either don't decrement TTL, or put an access list prior to sending
a packet into the ICMP generation thingie.

> > (3) If the L3PID is not IPv4 (for example MPLS) then an LSR should not try
> > to guess the type of payload.  Providers who want to retain
> > functionality that is only available if the L3PID is known will have
> > to set up TE hierarchical tunnels for IPv4 only and other hierarchical
> > tunnels to carry "anything else".  This would be true of hierarchical
> > tunnels for specific diff-serv CT values so this is no surprise.
> 
> Cool, agreed to (3).  The rest is actually a bit tricky.

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.

> > The text is therefore fine as is.  Perhaps some minor clarification
> > can be made, but it does not make sense to remove this.
> 
> Stating (1), (2) and (3) above, and stating that the L3PID is only valid
> when the stack depth is 1 would do it for me.

I entirely disagree.  The L3PID of every LSP MUST be accurate.  If
the top L3PID is MPLS, then it accurately says "I don't know".

> > I also think the MPLS ICMP work is fine as is as long as only the MPLS
> > stack is exposed.  For those wishing to hide topology, either ICMP can
> > be disabled entirely or access lists can be applied to the IP source
> > address field before TTL expired is considered for generation of ICMP,
> > yielding better control than most implementation of ICMP for IP TTL.
> 
> True.  Different topic, however.  Take a look at the tunnel trace
> work (so far, only requirements) -- should be out shortly
> (draft-bonica-tunneltrace-00.txt).

Another thread.

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

> Kireeti.

Curtis