Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

jnc@mercury.lcs.mit.edu (Noel Chiappa) Thu, 23 January 2014 14:49 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BFA1A00FC; Thu, 23 Jan 2014 06:49:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level:
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qsawzw_UJ7lF; Thu, 23 Jan 2014 06:49:18 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E316E1A00E2; Thu, 23 Jan 2014 06:49:17 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AF62D18C151; Thu, 23 Jan 2014 09:49:16 -0500 (EST)
To: ietf@ietf.org, mpls@ietf.org
Message-Id: <20140123144916.AF62D18C151@mercury.lcs.mit.edu>
Date: Thu, 23 Jan 2014 09:49:16 -0500
From: jnc@mercury.lcs.mit.edu
X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 14:49:20 -0000

    > From: "Eggert, Lars" <lars@netapp.com>

    >>> Depends on the reach of that encapsulation. .. If it traversed such
    >>> middleboxes by default, as UDP does, it has the same issues.

    >> Exactly. The problem is not specific to UDP.

    > you conveniently cut the part of my original message where I tried to
    > explain that the difference is in *reach* of the traffic.

Say what? Does not "Depends on the reach of that encapsulation. .. If it
traversed such middleboxes by default" (which I did include) make exactly
that point?

But that's not important. Moving on...


    > encapsulators are not forwarding nodes from the viewpoint of the
    > network they tunnel over. They are traffic sources.

You might just as well say that 'from the viewpoint of the rest of the
Internet, a NAT box is a traffic source'. I mean, as far as the rest of the
Internet can tell, it just sits there, and emits packets, right?

After all, i) the packets it emits are quite different from the packets it
receives, and ii) (to make your pet point) the original packets (which
usually have RFC-1918 source addresses) would not make it far through the
Internet without the header changes the NAT box makes. 

But I don't hear you clamouring to have NAT boxes detect, and respond to,
down-stream congestion.


Look at it from the point of view of the box. Something(s) is sending it
packets, which it is supposed to forward. Basically, it can do one of three
(really, two) things with the packet:

- Forward it
- Drop it
- Queue it (but this eventually has to turn into 1 or 2, above)

How is that any different between i) a plain old router, and ii) one of these
boxes that you insist is a "traffic *source[]*, not [a] *forwarder[]*"?


You want to separate out a very specific class of intermediate forwarding
nodes, selected on a fairly arbitrary basis (the particular kind of header
they emit), and impose requirements on them that are not imposed on any other
intermediate forwarding nodes - and change the Internet's basic schemea of
congestion control in the process.

Why restrict that change to this particular kind of intermediate forwarding
device?

	Noel