The MPLS WG Archive

[Ben Black <ben@layer8.net>]

On Tue, Dec 19, 2000 at 04:06:36PM -0500, Curtis Villamizar wrote:
> Kireeti,
> 
> I am surprised to see you take such a hard stance on this.
> 
> There should be no requirement that the midpoints of an LSR do special
> processing for a particular L3PID.  There should also be no
> requirement that an LSR be completely ignorant of the L3PID.
> 

The issue I am raising is whether the processing of a particular L3PID
should be in the base specification.  I don't believe it should.  There
should be an IP-specific draft addressing how L3PID-aware LSRs should
handle IPv4 (and IPv6) packets. 

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

Absolutely.  However, if the MTU can be determined before any packets
flow across, why add _anything_ to the specification for processing
packets which need to be fragmented?  The combination of proper
signalling and silent discard within the MPLS domain provides all that
is required.

> 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.
> 
> 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.
> 
> The text is therefore fine as is.  Perhaps some minor clarification
> can be made, but it does not make sense to remove this.
> 

Then I propose we add text for ATM, Frame Relay, Circuit Emulation, ...


Ben