Hi, George, Yes, network operators have the freedom to plan the address in their prefer ways. There are many different ways to organize address schemas. Different network operators (including both ISPs and enterprises) has various considerations. Some consideration may be important for one network operator while makes much less sense for others. Why rule out others possibilities or mechanism by saying I have reasons to do things in my way? There are ISPs and enterprises who have chosen to embed their cared semantics into address and organize network or routing polices accordingly. We need to document this and give the analysis we could.
Cheers, Sheng On 4 June 2013 11:25, George Michaelson <g...@algebras.org> wrote: > Just to remind people, RIR policy is community driven. If the operations > people feel they need a policy for IPv6 allocations and assignments which > takes accounts of semantic bits, they can derive consensus driven policies > to do it. Its not done in the IETF. There might be an issue with how it > squares against IETF goals of conservation, but thats part of the > discussion in RIR policy space maybe. > > I think there is a touch of catch-22 here: there isn't a clear sense this > is an industry wide practice demanding that policy initiative (I do not > preclude it: I just observe, it hasn't happened yet) and there is an > absence of a well understood methodology of using it and applying it which > differs radically in outcome from ACL based methods. If there was an IETF > standard I am sure somebody could propose an allocations model which > reflected it, but who knows if that would get traction. > > I notice that there are large providers who feel semantic bit flagging > works for them. So, I do not say "nobody is doing it" as much as "nobody > has said they want an RIR allocations policy which reflects it, yet" > > The first time this came up, I think I said to mike that I could > understand ISPs wanting to say "this is a mechanism we use inside our locus > of control, to flag behaviours of packets" -ie that it was unlikely there > was a model for this to be meaningful between providers, but inside a > single autonomous region, sure: why not. (the formalism that you didn't get > the /32 under a model of consumption which assumed this kind of usage of > the bits is really not a big deal for me personally, although I am sure it > would upset some people) > > -G > > PS I am an RIR employee. I do not speak to policy in any formal sense. I > work in research. > > > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <ipepeln...@gmail.com>wrote: > >> Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list >> >> ===== >> Mistyped and autocorrected on a clunky virtual keyboard >> >> On 4. jun. 2013, at 01:08, joel jaeggli <joe...@bogus.com> wrote: >> >> > On 6/3/13 3:59 PM, Andrew McGregor wrote: >> >> That's completely true; many switch chips cannot route on longer than >> /64 prefixes, so attempting to do so starts to either heat up the software >> slow path, or consume ACL entries, or is simply not supported at all. While >> this is arguably a bug, it is also pretty much ubiquitous in the current >> generation of ethernet switches, which are the basis for the majority of >> routers. >> > please cite specifics. I have no devices in the field that have such a >> limitation. >> > >> > joel >> >> >> >> >> >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < >> brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote: >> >> >> >> On 04/06/2013 03:44, manning bill wrote: >> >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >> >> > >> >> >> On 03/06/2013 11:06, manning bill wrote: >> >> >>> /48's are a horrible policy - one should only advertise what >> >> one is actually using. >> >> >> Now *that* would cause a nice fragmented DFZ... >> >> >> Sander >> >> >> >> >> > >> >> > >> >> > I'm going to inject a route. One route. why do you care if its a >> >> /9, a /28, a /47, or a /121? >> >> >> >> I've heard tell that there are routers that are designed to handle >> >> prefixes up to /64 efficiently but have a much harder time with >> >> prefixes longer than that, as a reasonable engineering trade-off. >> >> Not being a router designer, I don't know how true this is. >> >> >> >> Brian >> >> >> >> Its -one- route. >> >> > That one route covers everything I'm going to use… and nothing >> >> I'm not. >> >> > >> >> > Is there a credible reason you want to be the vector of DDoS >> >> attacks, by announcing dark space (by proxy aggregation)? >> >> > Is that an operational liability you are willing to assume, just >> >> so you can have "unfragmented" DFZ space? >> >> > >> >> > >> >> > /bill >> >> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org <mailto:ipv6@ietf.org> >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6...@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6...@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- Sheng Jiang 蒋胜
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
