The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Dec> msg00355



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Concerns regarding the numerous layer violations in base MPLS drafts

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Tue, 19 Dec 2000 16:06:36 -0500
  • cc: ben@layer8.net, mpls@UU.NET


In message <200012180050.QAA06944@kummer.juniper.net>, Kireeti Kompella writes:
> Hi,
> 
> > I am greatly concerned by the numerous layer violations in the current
> > base MPLS drafts (MPLS Architecture and MPLS Label Stack Encoding, in
> > particular).
> 
> So am I.  If the protocol requires that an LSR in the middle of a tunnel
> look beyond the label stack (into the MPLS payload), something is
> seriously broken.  Groping inside a packet that has no protocol
> discriminator hoping to find evidence of IP-ness ("oh, look, the first
> nibble is 0x4!") is a gross hack; and while gross hacks are hallmarks
> of great implementations and proudly exchanged at beer parties, I would
> rather not see them in the protocol specifications themselves.
> 
> The main reasons seem to be handling TTL expiry and the need for
> fragmentation.  In both cases, in my opinion, the guilty packet MUST be
> dropped with no further processing.
> 
> If TTL expiry is needed for traceroute, an important debugging tool,
> then the answer is "do traceroute right", and indeed such an effort
> is under way.
> 
> As for fragmentation, we've argued this several times.  In my opinion,
> the only place that this should be handled is at the head end of the
> LSP; and protocols/implementations that don't allow/do this are broken
> and need to be fixed.
> 
> Finally, the L3PID (or equivalent) should only be used by the tail end
> of an LSP (or the penultimate hop, if PHP is used) when the last label
> is popped, and the packet forwarded as an unlabeled layer 3 packet.
> Again, my opinion only.
> 
> Kireeti.


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.

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.

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.

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.

Curtis