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

Please see 6935,6936.

You've conveniently ignored most if not all of the arguments Curtis has
made in the past ~30 messages.  I won't repeat them again here.

If you really are so concerned about potential corruption scatter and
header integrity issues beyond FEC/FCS for v6 protocols, perhaps you should
propose a v6 checksum hop-by-hop extension header.  :)

On Tue, Jan 21, 2014 at 11:36 AM, <l.wood@surrey.ac.uk> wrote:

> Oh, 'experience' is never a good play; after all, all experience is
> ultimately anecdotal. But as an argument, it's being used by all sides. We
> haven't seen missent traffic errors, because we're not looking for them.
>
> The question is, what does the end-to-end argument support?
>
> And surely the burden of proof falls on those making the change (this
> draft); first, do no harm. The end-to-end principle and the precautionary
> principle are strong arguments.
>
> Stone's papers, though technologically dated, support the underlying
> principle and provide analysis - you want a modern setting, I'm quite happy
> with proof of principle. Weird stuff happens; an end-to-end check can catch
> it.
>
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Edward Crabbe [edc@google.com]
> Sent: 21 January 2014 19:19
> To: Wood L  Dr (Electronic Eng)
> Cc: stbryant@cisco.com; Eggert, Lars; joelja@bogus.com; mpls@ietf.org
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> (Encapsulating MPLS in UDP) to Proposed Standard
>
> I don't think the 'experience' card is such a good play here Lloyd.  Many
> people on this list, and certainly a few of the ones you've been directly
> arguing with, have no small amount experience running *extremely* large,
> geographically distributed networks.   I've spent a bit of time running
> some very large backbones and major content providers myself, and I have to
> say, I'm finding most of your arguments here to be unconvincing at best.
>
> I do find it a bit ironic that you're asking for (difficult to gather,
> vendor variable and generally poorly documented) data form Stewart, when
> your own argument has yet to be substantiated via any form of quantitative
> impact analysis, either empirically or theoretically in a modern setting.
>  I'd be interested in seeing empirical (back)scatter collection data
> (similar to what Morley or Savage have done) to get some idea of impact
> here.  I strongly suspect that corruption scatter will be trivial, and
> certainly completely overwhelmed in terms volume by typical, day to day
> DDoS backscatter.  Perhaps this may be an idea for your next research paper?
>
> With regard to the congestion-control-of-all-tunnel-protocols argument: I
> find the argument to be specious.  Curtis summed up the end-to-end version
> of this argument pretty succinctly in an earlier email, to wit:
>
> If congestion aware or using a congestion aware transport, the top
> level applications are still congestion aware.  If congestion
> ignorant, they are still congestion ignorant.  If hostile, they are
> still hostile.
>
>
> On Tue, Jan 21, 2014 at 9:56 AM, <l.wood@surrey.ac.uk<mailto:
> l.wood@surrey.ac.uk>> wrote:
> Stewart
>
> the IP header check is not the UDP pseudoheader check - and IPv6 has
> neither.
>
> If a NAT gets a corrupted header, won't it open up new state and attempt
> to translate for that header? Remember, this is UDP, not TCP - it's not on
> an existing connection that must have already been opened by SYN/ACK, where
> the NAT is more likely to reject it as unknown.
>
> 'NATs, which rewrite and can trash headers, demonstrate and validate the
> integrity of the Internet' is not a good argument imo.
>
> I'd like to see some evidence for '"obscure" IP protocol numbers will get
> dropped by default at NATs and firewalls.'. IP/GRE is relatively
> state-free, nothing much to translate at transport there - it's not SCTP.
> I've spent a couple of years running an ISP, and the 'oh, that protocol
> won't go through your NAT' has not come up.
>
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Stewart Bryant [stbryant@cisco.com<mailto:stbryant@cisco.com>]
> Sent: 21 January 2014 12:29
> To: Eggert, Lars
> Cc: Wood L  Dr (Electronic Eng); curtis@ipv6.occnc.com<mailto:
> curtis@ipv6.occnc.com>; Joel Jaeggli; mpls@ietf.org<mailto:mpls@ietf.org>
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> (Encapsulating MPLS in UDP) to Proposed Standard
>
> On 21/01/2014 12:07, Eggert, Lars wrote:
> > Hi,
> >
> > On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com<mailto:
> stbryant@cisco.com>> wrote:
> >> In terms of congestion and misdelivery it is interesting looking
> >> at the number of horses that are already bounding around
> >> in the paddock outside the stable:
> >>
> >> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> > there is a big difference between encapsulation in IP and encapsulation
> in UDP. Everything encapsulated with "obscure" IP protocol numbers will get
> dropped by default at NATs and firewalls, whereas UDO traffic happily
> traverses them. The reach of UDP traffic is much broader.
> >
> > Lars
> So we have established that it's not the load on the NATs and Firewalls
> we are worried about.
>
> Seemingly from the above congestion is off the table as well.
>
> Now surely those same NATs and firewalls will be looking for an SA, DA,
> Type, SP, DP match
> and that is a lot of things that have to be right for a header
> corruption misdelivery to get
> through.
>
> - Stewart
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org<mailto:mpls@ietf.org>
> https://www.ietf.org/mailman/listinfo/mpls
>
>