Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

So I wasn't naively asking those questions, I know what the answers were likely to be.
What I'd really like is for people to actually say what they want, which I think is an Internet with packets that look like
[IPv6 Fixed Hdr][TCP Hdr], total size <= 1280[IPv6 Fixed Hdr][UDP Hdr], total size <= 1280
and that is it.
The consequence would be to deprecate many existing protocols and making them work over fragment unnecessary TCP or UDP.
I'd think OSPF is probably the most important one to start with.

      From: joel jaeggli <joelja@bogus.com>
 To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>; Nick Hilliard <nick@foobar.org>; "v6ops@ietf.org" <v6ops@ietf.org> 
 Sent: Wednesday, 22 April 2015, 16:32
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

On 4/21/15 11:20 PM, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.

not a transit provider so I'm sitting in the edge that said I have some
exposure to this problem space.

hence

https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same place
> in the packet, so that hardware can look at them for the purposes of
> dropping them in hardware or as inputs into LB. Is that the case?
> 
> What I'm curious about then is how do you handle DDoSes that are using
> IP fragments, where there are no TCP or UDP headers ports to look at?

https://datatracker.ietf.org/doc/draft-taylor-v6ops-fragdrop/

> I'm also curious about how you LB packets (either at layer 2 or layer 3)
> that don't have TCP or UDP headers, or aren't IP. I've seen LB become
> completely ineffective at layer 2 because a customer was using MPLS
> between two routers, so no MAC address variation, and no IP addresses
> and no TCP or UDP ports to look at.

as someone who does stateless l3+l4 loadbalancing to servers, if I can't
find the l4 header in an asic based forwarding engine even if a server
can I have problem.

> In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to be considered
> by the bridge as normal bridge ports, so if you want to avoid loops
> across the links that are candidate members of the LAG, the IEEE expect
> you to be running STP of some form across them...), I'm a big fan of the
> quote on the last slide of this presentation:
> 
> "IEEE 802.3ad Link Aggregation (LAG) what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf
> 
> 
> "LAG is good, but it’s not as good as a fatter pipe."
> 
> 
> ------------------------------------------------------------------------
> *From:* Nick Hilliard <nick@foobar.org>
> *To:* v6ops@ietf.org
> *Sent:* Wednesday, 22 April 2015, 2:56
> *Subject:* Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world:
> clarification text
> 
> On 21/04/2015 16:51, Gert Doering wrote:
>> I'm fully at a loss to express my amazement in polite words, so I'm just
>> *out* of this discussion now.
> 
> Fully agreed on this + that this thread needs to end.  The lack of
> operational reality being displayed is pretty severe.
> 
> Nick
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops

> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 