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 --------------------------------------------------------------------