The MPLS WG Archive

[Ben Black <ben@layer8.net>]

I am greatly concerned by the numerous layer violations in the current
base MPLS drafts (MPLS Architecture and MPLS Label Stack Encoding, in
particular).  Why are these layer violations in these drafts when they
clearly work against the multiprotocol intent of MPLS?

Specific layer violation examples:

<draft-ietf-mpls-arch-07.txt>
Section 3.23
..
   This provides some level of protection against forwarding loops that
   may exist due to misconfigurations, or due to failure or slow
   convergence of the routing algorithm. TTL is sometimes used for other
   functions as well, such as multicast scoping, and supporting the
   "traceroute" command. This implies that there are two TTL-related
   issues that MPLS needs to deal with: (i) TTL as a way to suppress
   loops; (ii) TTL as a way to accomplish other functions, such as
   limiting the scope of a packet.

   When a packet travels along an LSP, it SHOULD emerge with the same
   TTL value that it would have had if it had traversed the same
   sequence of routers without having been label switched.  If the
   packet travels along a hierarchy of LSPs, the total number of LSR-
   hops traversed SHOULD be reflected in its TTL value when it emerges
   from the hierarchy of LSPs.
..

The first paragraph offers traceroute as an example of an application
which requires layer 3 TTL manipulation.  While this is certainly the
case, traceroute is actually just a hack to get information out of the
network without specific protocol support.  Rather than suggest that LSRs
process or otherwise support processing of layer 3 packets in the data
plane, support for this functionality should be present in the control
plane protocols (for example, through the use of LDP Path Vector TLVs).

The second paragraph drives this violation further home.  The implicit
assumption is that any packets carried across an LSP will have some sort
of TTL mechanism (if not, why bother suggesting LSRs manipulate it?).
This is certainly true for IP, but what about circuit emulation services?
What about LSRs that have no visibility into the data (existing ATM
switches, for example)?


<draft-ietf-mpls-label-encaps-08.txt>
Section 2.2
..
   conditions under which it is desirable.  For instance, if an
   intermediate LSR determines that a labeled packet is undeliverable,
   it may be desirable for that LSR to generate error messages which are
   specific to the packet's network layer.  The only means the
   intermediate LSR has for identifying the network layer is inspection
   of the top label and the network layer header.  So if intermediate
   nodes are to be able to generate protocol-specific error messages for
   labeled packets, all labels in the stack must meet the criteria
   specified above for labels which appear at the bottom of the stack.
..

I am simply at a loss to understand why an LSR should, under ANY
circumstance, generate protocol-specific messages based on error
states unrelated to the MPLS domain edge.  Intermediate LSRs MUST
NOT be concerned with the payload of an LSP.  To do otherwise would
be a layer violation leading to all manner of specification and
implementation complexity.

Sections 3.4 and 3.5 SHOULD be changed to say that any labeled packet
which is "too big" should be silently discarded.  Again, I have no
idea why all this IP-specific information is in what is, allegedly,
intended to be a protocol independent transport mechanism.  Asking
that intermediate LSRs be capable of full IP router functionality in
the _data plane_ makes no sense in light of the intent of MPLS.


I look forward to reading perspectives on why these layer violating,
protocol-specific components of the base specifications exist.


Ben