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

From: Kireeti Kompella <[email-masked]>
Date: Sun, 17 Dec 2000 16:50:04 -0800 (PST)

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Dec 2000 16:06:36 -0500

> is popped, and the packet forwarded as an unlabeled layer 3 packet.

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

---

From: Ben Black <[email-masked]>
Date: Tue, 19 Dec 2000 13:30:40 -0800

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

> ingress can fragment or generate the ICMP for packets with "don't

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.

> 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

---

From: Eric Gray <[email-masked]>
Date: Tue, 19 Dec 2000 18:30:25 -0500

Ben,

    Please see embedded comments.

> handle IPv4 (and IPv6) packets.

It is often the case that a protocol specification for generic
support of multiple protocol includes one or two examples
of how the generic support works.  While it might be more
correct to do IPv4 (for example) in a separate draft, it
might also be more correct to arrange condiments on your
supper table in alphabetical order.  More correct does not
mean necessary.

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

One or two examples are fine, thanks...

--
Eric

---

From: Ben Black <[email-masked]>
Date: Tue, 19 Dec 2000 15:52:01 -0800

> supper table in alphabetical order.  More correct does not

Protocol-specific components do not belong in the body of the
base draft.  If you are so adamant that "one or two examples"
be included in the base draft, put them in an appendix.  Of
course, if they are cut out and put in an appendix, why not
just put the appendix in its own draft?

Ben

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 20 Dec 2000 10:19:03 -0500

Ben,

ATM, Frame Relay, Circuit Emulation are clearly second class citizens.
Besides the fact that this is the IETF, these are supported mostly to
transition legacy services (whose market is growing very slowly, flat,
or shrinking in most providers according to their quarterly
statements.  When it goes negative, switched services stop getting
reported separately).

The initial and major use of MPLS was assumed to be IPv4.  For quite a
long time it was the exclusive use of MPLS in practice.  That
assumption is still correct today.  Some consideration of IPv4 in the
base MPLS documents is perfectly fine as long as it does not impact
the ability to support other L3PIDs.

It is perfectly fine to specify optional treatment for other L3PIDs in
separate documents if it made sense to support some form of special
treatment.  The encapsulation documents would be a good place to do
this.  If you really wanted to specify a feature such as setting FECN
or some other L3PID specific action, you could do so and see if there
is enough demand for the feature that anyone implements it.

Curtis