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 蒋胜 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
