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

[[e-mail]]

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

>
> 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
> <[e-mail]>
> [e-mail] writes:
>
>> you've got the perfect application to encourage UDP lite adoption and
>> deployment here.
>>
>> Lloyd Wood
>> http://about.me/lloydwood
>> ________________________________________
>> From: Stewart Bryant [[e-mail]]
>> Sent: 15 January 2014 11:31
>> To: Randy Bush
>> Cc: Wood L  Dr (Electronic Eng); [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]; [e-mail]
>> 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
>