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