IETF Logo Mail Archive

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

Scott Brim <scott.brim@gmail.com> Fri, 10 January 2014 21:32 UTC

Return-Path: <scott.brim@gmail.com>
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 1EC371AE1E1; Fri, 10 Jan 2014 13:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 vYyHLZzaosdI; Fri, 10 Jan 2014 13:32:34 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 30AFD1AE1D3; Fri, 10 Jan 2014 13:32:33 -0800 (PST)
Received: by mail-ob0-f177.google.com with SMTP id vb8so5301438obc.8 for <multiple recipients>; Fri, 10 Jan 2014 13:32:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FQc3/hCV61AVpz/i8uWVPiJiCv37btbVGsRN2qG2ZcM=; b=Ls7/51+a09ybWl1R3ILoQBG3lfy67av0R/vd/vT8kl67Eg2F/47+AllcbHs4QXF8xu xTuNb5ZUYDCjK8LPpWTBdOX4Lv+f17x8+hl5i9jVYWCKL9Xk3fweg0pZD+jISdMWxMf7 Nk9V6ZkobBk9mfhrfH/gzy1T04XIFbMvVQpa2KZb4RIYG/ONblZmVPAWrEiVZ7SPpxzd 1DuGF7+S8Zum6LzGQb6jS8/ClvV7wQVv49aFxPE06yoRwm/qZ4BYo5LDPOn10G4rSzWH 6Mc0cWuB9zojk3KsZLYjiQCl5TaaKeRGn23uz0pNAQwMGHiGptWyMC3uzkDjiwpPRTnq ZFNg==
X-Received: by 10.60.174.167 with SMTP id bt7mr8891124oec.54.1389389543027; Fri, 10 Jan 2014 13:32:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.48.9 with HTTP; Fri, 10 Jan 2014 13:32:02 -0800 (PST)
In-Reply-To: <52D05C75.3050505@joelhalpern.com>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <CAPv4CP-iwoHEiV=xtNAd7qT4r8OYvfE1ZjnKE=wWY5VVcQ3x8w@mail.gmail.com> <CACKN6JGNAm6KWLohzqaM58jy94wYqmtjJTh4Y8Cx2dcRRqJ_xQ@mail.gmail.com> <CAPv4CP_YiOnKNBgh5Qg2AaLwOGfm6j3FidNQD347+QQhv5MfkA@mail.gmail.com> <52D05C75.3050505@joelhalpern.com>
From: Scott Brim <scott.brim@gmail.com>
Date: Fri, 10 Jan 2014 16:32:02 -0500
Message-ID: <CAPv4CP_33OU-s+8xt9t5voAtiXMS3pw2+67w9=FxpS2cAOmDeg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "mpls@ietf.org" <mpls@ietf.org>, IETF <ietf@ietf.org>
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: Fri, 10 Jan 2014 21:32:36 -0000

On Fri, Jan 10, 2014 at 3:47 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> The problem with taht paragraph is that it assumes that the UDP encapsulator
> knows what the payload is.
> It seems to me that one could easily be applying the UDP in any one of a
> number of cases where the payload will not be known.
> So the requirement in the paragraph seems at best difficult to meet.
>
> And has been noted, this seems to place an expectation on UDP encapsulated
> MPLS that is not present for MPLS itself, when the traffic is not known to
> be IP.

OK good point - so we invoke the end-to-end argument on MPLS's behalf.

v2.23.0 | Report a Bug | By Email