Subject: Concerns regarding the numerous layer violations in base MPLS drafts

From: Ben Black <[email-masked]>
Date: Sun, 17 Dec 2000 14:13:04 -0800

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

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 18 Dec 2000 03:17:26 +0200 (EET)

ben,

i pointed out a long time ago that the encap i-d is full of wrong
assupmtions and statements regarding what is carried in the mpls
packets, but i was asked to shut up in order to not to delay its
publication as an rfc.

-- juha

---

From: Ben Black <[email-masked]>
Date: Sun, 17 Dec 2000 18:23:54 -0800

I've noticed that response quite a few times.  I wonder if, in this
case, all the IP bits are in there to maintain a connection to the
mission of the IETF, since a truly protocol-independent spec would
fall outside of its domain.

Ben

---

From: Eric Rosen <[email-masked]>
Date: Mon, 18 Dec 2000 14:17:46 -0500

These issues were all discussed quite thoroughly several years ago.  

I don't see  that there are any layer violations.   The documents are pretty
careful  to avoid  requiring that  any given  LSR be  capable  of generating
IP-specific error messages.  However, they  do discuss the way in which LSRs
that are so  capable should do so.  This simply reflects  the fact that most
LSRs understand IP and that most labeled packets carry IP. 

I  have  some  sympathy  with  the notion  that  rather  than  accommodating
traceroute,  one should  design  a  better traceroute  that  really gets  it
right.  When such a replacement  traceroute is ubiquitously deployed, we may
want to reconsider some of the issues. ;-)

Note, however,  that it is impossible  to get the same  functionality from a
control-plane-based traceroute as  from the data-plane-based traceroute that
we are familiar with.  

Some  of the  feeling that  there are  layering violations  may stem  from a
belief that MPLS  is a "layer 2" mechanism.  I've always  thought of MPLS as
an extension  of the network layer.  Thinking  of it this way  makes it very
natural to define it with  a combination of network-layer-specific rules and
network-layer-independent rules.  If  the only set of network-layer-specific
rules are those that apply to IP,  that simply reflects the fact that no one
cares about the other network layers.

With respect to  fragmentation, the encaps tries to  suggest the benefits of
doing it at  the LSP endpoints, but this is not  required.  I'd have thought
that  PMTU discovery  would make  this a  virtual non-issue,  but apparently
ICMP-discarding firewalls are so common that PMTU doesn't actually work very
well in practice. 

Ben> I wonder if, in  this case, all the IP bits are  in there to maintain a
Ben> connection  to  the  mission  of  the IETF,  since  a  truly  protocol-
Ben> independent spec would fall outside of its domain. 

Obviously you are not acquainted with the authors!  

The goal was just to make the  stuff useful, not to achieve a political goal
or  to  maintain a  level  of architectural  purity.   It  was assumed,  for
example, that  it would be  more useful to  keep traceroute working  than to
offer up learned arguments explaining why traceroute ought not to work.