I believe this is fraught with danger. It perhaps better to identify semantic constructs than to presuppose representative cases.
things like even/odd for in/out-bound links, lat/log encoding or other geo-location etc. as a survey of technique. /bill On 4June2013Tuesday, at 7:32, Sheng Jiang wrote: > For sure, we cannot document all variants, but we can document the most > representative ones. My current plan is three categeries: ISP's, enterprise's > and subscribe's. Each categery has one example (in appendexes), I guess. > > Cheers, > > Sheng > > > On 4 June 2013 21:51, manning bill <bmann...@isi.edu> wrote: > are you intending to document -all- variants of the semantics address holder > may use to address and organize their assigned numbers? > or are you intending to document a "preferred" version of address semantics? > > /bill > > > On 4June2013Tuesday, at 6:24, Sheng Jiang wrote: > > > 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 蒋胜 > > > > > -- > Sheng Jiang 蒋胜 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
