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

From: Kireeti Kompella <[email-masked]>
Date: Tue, 19 Dec 2000 20:33:35 -0800 (PST)

Hi Curtis,

> I am surprised to see you take such a hard stance on this.
> 
> (1) There should be no requirement that the midpoints of an LSR do special
> processing for a particular L3PID.  (2) There should also be no
> requirement that an LSR be completely ignorant of the L3PID.

I can live with (2) if you grant me (1).  Note that the L3PID is
only valid (to my thinking) when the stack depth is 1.

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

We're on the same page so far.

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

Note that many SPs want tunnels not to show up in traceroute.

> (3) 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.

Cool, agreed to (3).  The rest is actually a bit tricky.

> The text is therefore fine as is.  Perhaps some minor clarification
> can be made, but it does not make sense to remove this.

Stating (1), (2) and (3) above, and stating that the L3PID is only valid
when the stack depth is 1 would do it for me.

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

True.  Different topic, however.  Take a look at the tunnel trace
work (so far, only requirements) -- should be out shortly
(draft-bonica-tunneltrace-00.txt).

Note too for IP VPNs and for BGP-free cores, traceroute will not work
(easily) -- intermediate LSRs don't know whom to send the ICMP error
to.  Yes, one may be able to hack around this, but it ain't pretty.

Kireeti.

---

From: Dan Tappan <[email-masked]>
Date: Wed, 20 Dec 2000 09:31:06 -0500

>when the stack depth is 1 would do it for me.

What people keep forgetting in these discussions is that there is no one 
"MPLS", there are at least 3:

1. MPLS as a way of adding additional capability to IP. This is the 
original, and includes TE, LDP, and VPN

2. MPLS as a media independent replacement for ATM (Layer 2 VC) signaling

3. GMPLS TE mechanisms as a mechanism implementing a control plane for 
non-packet capable devices

Folks who remember [1] think that having special procedures for IPv4 LSPs 
is perfectly reasonable.

Folks who focus on [2] worry about "layer violations"

Folks who focus on [3] don't even worry about the issue, since "non-packet 
capable devices" never see packets.

Right now Kireeti is feeling gored because he wants to transfer L2 packets 
over IPv4 LSPs, and doesn't want to worry about IPv4 procedures.

However, if he gets his way on the above then I predict that he, or someone 
else in his company, will feel equally gored the first time a customer 
deploys VPN, or LDP over TE, or Aggregated TE, or ..., and needs to debug a 
problem using traceroute, or wants to apply some other IPv4 procedure.

Regarding the organization of documents. I think it would be reasonable to 
have "MPLS Procedures for IPv4 LSPs" as a separate RFC (or BCP, since many 
of these are local decisions). Similarly for IPv6 or any other protocol 
dependent procedures. However, I don't think it's important enough to hold 
up publication of the current RFCs - the discussed procedures obviously 
apply only to IPv4 LSPs.

---

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

In message <[email-masked]>, Dan Tappan wr
> over IPv4 LSPs, and doesn't want to worry about IPv4 procedures.

If (big "if") that were the case, then Kireeti should either 1) use a
different L3PID, not IPv4, so the midpoints and the egress get it
right, or 2) put an IP header on the encapsulated packets, then it is
IPv4 and all is fine.

Personally I prefer 2) because it would allow non-MPLS hops near the
edges of the provider.  It would also make the IESG happier if that's
a consideration.

Curtis

btw- I don't think you've accurately guessed Kireeti's motives on this.

---

From: Dan Tappan <[email-masked]>
Date: Wed, 20 Dec 2000 07:42:17 -0500

>Note that many SPs want tunnels not to show up in traceroute.

and many want them to show up. And/or want to be able to choose.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 20 Dec 2000 09:59:15 -0500

> only valid (to my thinking) when the stack depth is 1.

That would only be the case if the L3PID on the outer tunnel (top) was
set up as MPLS.  If the L3PID was set up as IPv4, then only tunnels
containing IPv4 in the payload (other tunnels with a L3PID of IPv4)
should be placed inside.

I think this has been quite clear, but if not, we should make it
clear.  The right place might be the hierarchical draft.  See below.

> Note that many SPs want tunnels not to show up in traceroute.

So either don't decrement TTL, or put an access list prior to sending
a packet into the ICMP generation thingie.

> Cool, agreed to (3).  The rest is actually a bit tricky.

This is some detail on the text above where I said "see below".  The
L3PID is significant for an LSP regardless of stack depth.  The L3PID
of the top label should not conflict with the lower L3PID, and if so,
the setup should be rejected.  The L3PID must exactly match the one
immediately below it unless the outer L3PID is MPLS, in which case any
inner L3PID is allowed, but the outer label no longer provides the
payload type.  The midpoint LSR usually do not know anything about the
lower labels so all L3PID specific tricks are disabled.

> when the stack depth is 1 would do it for me.

I entirely disagree.  The L3PID of every LSP MUST be accurate.  If
the top L3PID is MPLS, then it accurately says "I don't know".

> (draft-bonica-tunneltrace-00.txt).

Another thread.

> to.  Yes, one may be able to hack around this, but it ain't pretty.

This is solved by sending the ICMP forward through the LSP.  The
egress should be able to look up the destination in the ICMP packet in
the correct VPN forwarding table if private address is used.

Curtis

---

From: Eric Gray <[email-masked]>
Date: Wed, 20 Dec 2000 12:56:39 -0500

I agree with Dan on all of his points.  Note that a proposal
to re-organize documents for what are essentially esthetic
reasons are completely inappropriate at this late date.

--
Eric

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 20 Dec 2000 13:12:55 -0500

I totally agree with Dan on this. There is
no practical reason to reorganize the drafts at this
late stage of the game.

         --Tom

>However, if he gets his way on the above then I predict that he, or 
>someone else in his company, will feel equally gored the first time a 
>customer deploys VPN, or LDP over TE, or Aggregated TE, or ..., and needs 
>to debug a problem using traceroute, or wants to apply some other IPv4 
>procedure.
>

---

From: Ben Black <[email-masked]>
Date: Wed, 20 Dec 2000 10:04:38 -0800

I was under the impression that the purpose of the IETF was to
engineer, not simply to generate documentation.  The date is
irrelevant if there is a problem with a specification.  What
you consider merely aesthetic, others consider fundamental to
good protocol design.

Ben

---

From: Eric Gray <[email-masked]>
Date: Wed, 20 Dec 2000 14:01:08 -0500

Ben,

    Please read embedded comments.

You wrote:

> engineer, not simply to generate documentation.

Whether you meant it this way or not, this is essentially a
two-pronged attack which falls apart fairly easily.  You seem
to be arguing that my desire to leave the document as is will
somehow "generate documentation".  On the other hand, your
argument to re-organize several MPLS base drafts for the
purpose of  moving IPv4 specifics (presumably without any
substantive changes to the contents) is somehow exclusively
a good engineering exercise.

I disagree on both points for what, IMHO, are obvious
reasons.

> The date is irrelevant if there is a problem with a specification.

No, the date is not irrelevant.

Progress is accomplished by achieving results, however imperfect
they might be, and moving on to the next problem.  Progress is
not attained as a result of an endless search for the perfect goal.

If you see a problem with a specification, I suggest that you write
a separate specification to address it.  This is under the heading
of "moving on to the next problem".  IF, in attempting to write a
new specification, you uncover reasons why the existing one will
not be useful to anyone, THEN it is likely that the existing one
will be discarded in favor of a new, improved version.

I do not think the reasons stated so far are sufficient to justify
such a course of action.  I believe there is abundant evidence that
the existing specifications are useful to someone.

>
> What you consider merely aesthetic, others consider fundamental
> to good protocol design.

:-)

If you uncover a useful book on protocol design principles,
one of them will be something along the lines of "strive always
for completion, rather than perfection".  Unfinished but nearly
perfect protocols are less useful than imperfect, but working,
protocols.

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 20 Dec 2000 21:58:42 +0200 (EET)

eric,

the issues that i pointed out didn't deal with reorganization of the
i-d, but simply words that don't correspond with how mpls is used. for
example, already the appendix speaks only about "network layer packets"

   "Multi-Protocol Label Switching (MPLS)" [1] requires a set of
   procedures for augmenting network layer packets ..."

and things just get worse in the rest of the document.  the use of mpls
as a new connection oriented layer 2 protocol for carrying anything is
nothing new and could have been taken into account when the i-d was
written.

-- juha

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Dec 2000 14:45:16 -0800

> reasons are completely inappropriate at this late date.

s/esthetic/architectural/ and you may get a hint of why people
want to do this.

randy

---

From: Pankaj K Jha <[email-masked]>
Date: Thu, 21 Dec 2000 08:50:58 -0800

Eric Gray wrote:

> of "moving on to the next problem".

> IF, in attempting to write a

Eric:

I clearly sense a document-generating attitude in "Progress is
accomplished by achieving results, however imperfect they might be",
"moving on to the next problem" and "however imperfect they might be",
and "the existing one will be discarded in favor of a new, improved
version". Unless MPLS has a short life cycle, I think it is still early
enough to be able to initiate a change.

By the way, who is urging us to "move on to the next problem" after
giving a half-baked solution to the current problem? It is always the
person wanting to move on to the next problem. No one else is asking him
to do that. Industry never says - I depend on you to keep generating
document, don't worry how bad they are - for the coming generation will
inherit them and fix them if they want to do it - you just keep typing
away :-)

Your arguments aren't technical at all. And by the way, I do not think
ANY implementer will get confused when he finds IP-specific
implementation details in a separate draft. Neither will his software
implementation change due to one draft now becoming two drafts. So where
is the adverse impact? Let's fix it now, or it will never get fixed
properly.

If we are that determined upon making MPLS to be IP-specific only (and
telling other protocols to go figure how they are going to fit in the
paradigm) then let us just call it IPLS, or some such thing. No use
calling it MPLS.

I do not think removing IP-specific stuff will take such a long time.
I'm sure we'll get plenty of volunteers to do such a job, and it should
take only a few days.

Regards,
Pankaj

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 21 Dec 2000 23:30:14 -0500

> inherit them and fix them if they want to do it - you just keep typing

None of us get paid by the pounds of documents generated and claiming
that a wording nit in a non-normative architecture document makes
something a half baked solution is ridiculous.

If someone proposes an editorial change to provide better clarity,
that's fine.  Editorial changes can be made.

If someone wants to reorganize documents with no technical basis
because if violates their sense of architectural purity, then
entertaining such a request just wastes the valuable time of WG
contributors.

Curtis

ps - We are wasting the valuable time of WG contributors by continuing
this thread.  Nothing of substance has come out of it.  If someone
wants to propose editorial changes that clarify the existing optional
use of the IPv4 L3PID please do so.