i don't believe that I said support. but when you select cases as representative, you are biasing the result.
people place all sorts of semantic clues in the methods of addressing… more so when the addresses themselves are too large to be memnonic. I happen to believe that the idea of documenting semantic constructs is less interesting as IETF protocol work and more interesting as operational practice. And as operational practice, describing characteristics of semantic drivers and implementations might be worthwhile. The caveat is that you still want to restrict your analysis to "typical" methods… which is disingenuous if you are truly doing an analysis of the methods of embedding semantic constructs in addressing. Your Bias is showing. /bill On 4June2013Tuesday, at 16:44, Sheng Jiang wrote: > We do NOT "support" anything. This would be an analysis document. The > motivation is to document existing typical semantic IP address mechanisms and > analyze them, both good and bad side. I will make this very clear in the new > version. > > Sheng > > > On 4 June 2013 22:44, manning bill <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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 <[email protected]> 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 > > > >> <[email protected] <mailto:[email protected]>> > > > >> 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 > > > >> [email protected] <mailto:[email protected]> > > > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > >> -------------------------------------------------------------------- > > > >> > > > >> > > > >> > > > >> > > > >> -------------------------------------------------------------------- > > > >> IETF IPv6 working group mailing list > > > >> [email protected] > > > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > >> -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > > > v6ops mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > > > > > > -- > > > Sheng Jiang 蒋胜 > > > > > > > > > > -- > > Sheng Jiang 蒋胜 > > > > > -- > Sheng Jiang 蒋胜 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
