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:49 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 848D51AE248; Wed, 15 Jan 2014 12:49:07 -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 reuQK5rr6cLn; Wed, 15 Jan 2014 12:49:05 -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 3B9DA1AE0D5; Wed, 15 Jan 2014 12:49:04 -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 s0FKmlsn022848; Wed, 15 Jan 2014 15:48:48 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401152048.s0FKmlsn022848@maildrop2.v6ds.occnc.com>
To: gorry@erg.abdn.ac.uk
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Wed, 15 Jan 2014 20:18:11 +0000." <b09d482e8df3c33f97fa0c26a40393b8.squirrel@www.erg.abdn.ac.uk>
Date: Wed, 15 Jan 2014 15:48:47 -0500
Cc: 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:49:07 -0000

In message <b09d482e8df3c33f97fa0c26a40393b8.squirrel@www.erg.abdn.ac.uk>
gorry@erg.abdn.ac.uk writes:
> 
> You may care to reference this to Section 2.2 of RFC 6936, which provides
> some background to where UDP-Lite may help, and some of the potential
> pitfalls.
>  
> Gorry


The right tool for the job but ...

Expect some pushback because older hardware looks at TCP and UDP in
the protocol field and then checks port numbers for ECMP load
balance.  That older hardware will not do this for UDP-Lite.

With MPLS over UDP, only the dest port number matters and the src port
number can be used like the MPLS Entropy Label.  That is about the
only thing that would not work in some networks with UDP-Lite.

IMHO it would be advantageous to provide the option to use UDP-Lite
rather than UDP with no checksum at all.  The section in RFC 6936
could be cited.  The limitation I mentioned could also be cited.

Curtis


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