IETF Logo Mail Archive

Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))

Curtis Villamizar <curtis@ipv6.occnc.com> Wed, 15 January 2014 20:05 UTC

Return-Path: <curtis@ipv6.occnc.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 CBC2C1AE389; Wed, 15 Jan 2014 12:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 AVnar5yR1lmb; Wed, 15 Jan 2014 12:05:52 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50A1AE373; Wed, 15 Jan 2014 12:05:52 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0FK5VIU022303; Wed, 15 Jan 2014 15:05:31 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401152005.s0FK5VIU022303@maildrop2.v6ds.occnc.com>
To: l.wood@surrey.ac.uk
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Wed, 15 Jan 2014 11:57:18 +0000." <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk>
Date: Wed, 15 Jan 2014 15:05:31 -0500
Cc: gorry@erg.abdn.ac.uk, mpls@ietf.org, lisp@ietf.org, ietf@ietf.org, wes@mti-systems.com, randy@psg.com, tsvwg@ietf.org, jnc@mit.edu
Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
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: Wed, 15 Jan 2014 20:05:54 -0000

Or perhaps UDP heavy with a FCS at the end and no checksum at all.

You do make a good point that perhaps UDP lite should be mentioned in
MPLS over UDP as an option.

Curtis


In message <290E20B455C66743BE178C5C84F1240847E63346CB@EXMB01CMS.surrey.ac.uk>
l.wood@surrey.ac.uk writes:
 
> you've got the perfect application to encourage UDP lite adoption and
> deployment here.
>  
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Stewart Bryant [stbryant@cisco.com]
> Sent: 15 January 2014 11:31
> To: Randy Bush
> Cc: Wood L  Dr (Electronic Eng); wes@mti-systems.com; curtis@ipv6.occnc.com; gorry@erg.abdn.ac.uk; mpls@ietf.org; ietf@ietf.org; tsvwg@ietf.org; jnc@mit.edu; lisp@ietf.org
> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
>  
> On 15/01/2014 11:08, Randy Bush wrote:
> > [ you insist on cc:ing me, so you get to endure my opinions ]
> >
> >> it seems that there are no valid statistics for the current Internet
> >> to sustain your case.
> > as we discussed privately, there seem to be no real measurements to
> > sustain any case.  this is all conjecturbation.
> >
> > what i do not understand is why, given the lack of solid evidence that
> > we are in a safe space, you and others are not willing to spend a few
> > euro cents to have a reasonable level of assurance at this layer.
> >
> > randy
> Randy,
>  
> It is not a few cents, it is likely the re-engineering of a lot
> of silicon.
>  
> The reason that UDP is of interest is that the on path silicon
> knows how to process it, for example it knows how to to ECMP it.
>  
> The reason that the UDP c/s is a problem for a tunneler is that
> it needs to have access to the whole pkt to calculate the
> c/s, but as you know the silicon optimised that access away
> a long time ago.
>  
> The alternative would be UDP-lite, but the ability of on path
> silicon to process that as competently and as completely as it
> processes UDP is by no means clear.
>  
> - Stewart

v2.23.0 | Report a Bug | By Email