Lorenzo, On Feb 7, 2014, at 11:35 AM, Lorenzo Colitti wrote:
> Mark, > > It is a controlled domain. > ISPs do filter packets from their users, because of BCP 38. > DSCP is no harder than source address filtering. It's not about whether treating the packet is hard technically on the forwarding engine, it's about whether you can trust whether the bits are set correctly and persevered where the operator expects them to. For DSCP, we even have difficulties with that across vendors in enterprise deployments. As trust is something that is built up over time, and DSCP has indeed been around quite a while, there's a lot of baggage to get past here. Operationally, I don't think BCP38 filtering and QoS treatment based on DSCP is a fair comparison at all. If your NAT sets the wrong source IP address bits and your packets get dropped by your ISP, you lose service entirely. Bad DSCP bits, unless being monitored closely by someone or some tool, likely results in intermittent service issues based on what mix of traffic is present at any given time. Rather than the problem getting resolved, the user just hangs up and calls on his mobile phone (or whatever), and then the problem just "goes away" later, until it comes back again.. Rinse. Repeat. > Please let's stop bringing to the table technical arguments that don't hold > water, ok? I'd much rather hear "we want this to be > standardized because DT has implemented it" - at least that's the truth. :-) I tried to stay out of the "semantic" discussion, but you're going to put me in it anyway. Here's my thought on that. We most often think about reducing the NAPT complexity above IPv4 by moving to IPv6, but there is a plethora of complexity below that IPv6 has the chance to collapse. In a greenfield IPv6 design, once you wipe away all the VLANs, overlays, etc... the inertia from that exercise alone can lead to looking at addresses for more than numbering exposed physical network interfaces alone. I've seen this again and again, and it is just this point where one person's convenient use of IP addressing becomes another's evil semantic horror. That makes sense, because once you pass the least common denominator of a physical network interface, you are necessarily more and more domain-specific, which is where most misunderstandings and arguments tend to occur. This seems like a "Tussle", quoting [Clark], et. al... "Design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive." You asked for Truth. Truth is that homes need multiple prefixes for multihoming to different ISPs. Reality is, if DT wants to use that to expose 3 VLANs or 3 networks making it look like 3 ISPs to the homenet, so be it. In fact, it's a good test case to ensure the multiprefix design is implemented and flexible enough to handle cases we don't immediately envision. - Mark [Clark] http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf > > Cheers, > Lorenzo > > > On Fri, Feb 7, 2014 at 7:26 PM, Mark Townsley <[email protected]> wrote: > > Brian, > > As you point out, DSCP does of course work between endpoints within an > enterprise network just as it was designed to do. It's reasonable to think > that the same technology could be used in other environments, but the track > record of it doing so outside of a tightly controlled domain is rather poor. > Reclassifying at boundaries is expensive, often inaccurate, and ultimately > doomed as we encrypt more and more end to end. It would be great if diffserv > worked across the Internet, multicast would be nice as well. But, heck, we > can't even get PMTUD working well enough to truly depend on. > > - Mark > > > > On Feb 5, 2014, at 8:15 PM, Brian E Carpenter wrote: > > > On 06/02/2014 01:13, Alexandru Petrescu wrote: > >> Le 05/02/2014 09:06, Mikael Abrahamsson a écrit : > >>> On Wed, 5 Feb 2014, Brian E Carpenter wrote: > >>> > >>>> On 05/02/2014 12:13, Michael Richardson wrote: > >>>>> Pierre Pfister <[email protected]> wrote: > >>>> ... > >>>>>> For instance, if a prefix is for general purpose, and another is for > >>>>>> voice > >>>>>> applications, then hosts may only get addresses for voice > >>>>>> application, and > >>>>>> would therefore not being able to access the internet. > >>>> > >>>> Yes, that's one of many reasons why using prefixes to distinguish > >>>> types of traffic is a really bad idea. > >>> > >>> The idea is that "non color-aware" devices will only use the "Internet" > >>> prefix, by means of the colored prefixes will use a different ND PIO > >>> type for prefix announcement (thus invisible to these non color-aware > >>> hosts), plus DHCPv6 server would only hand out prefixes/addresses to > >>> hosts that request them. > >> > >> A color could also be a particular value for the flow label field. > > > > No, a DSCP. The flow label value is supposed to be opaque with > > no semantics. > > > > We designed diffserv for this purpose and it works well and is quite > > widely used in corporate networks. Wasting prefixes to distinguish > > traffic types is an incredibly bad idea. > > > > brian > > > > _______________________________________________ > > homenet mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
