>While it is true that any operator can do whatever they want, this >proposal is architecturally a bad way to achieve the kind of goals you >outline.
Will improve the expression to remove the mislead that we are 'selling' it. >So I would oppose publishing even an informational RFC on how one might >do this. > >As an example of the problems with this, you suggested that allocations >to enterprise would not change with this approach. That the enterprise >would receive a certain semantic, and would be allocated a certain /48 >to match that. While this sounds attractive and harmless: >1) It is extremely unlike that a customer will fall into a single >"semantic" with any useful definition of semantic Agree. Typically, there should be more than one semantic embedded. Actually, it is the problem of DSCP, which abstract all the semantics into service classes, which is one single dimension. This abstract processing has lost a lot of information, which providers want to inspect for every packet, then process the packet accordingly. The explicitly expressed semantics in prefix provides much more information. >2) You have argued that you can not use DSCP because they are not fine >enough grained. This means that you want to increase the routing >complexity by more than a factor of 64, which seems to be a VERY bad >idea for any operator infrastructure. Not exactly more than 64. It is more than one dimension. Say, we may have three semantics (2, 3, 4 types for each semantics) it is only 24 possibilities. Furthermore, in this way, it is not necessary that one single router to understand all semantics and differentiate the packet processing. Different semantics may trigger different on different routers. For example, express router may only care about one single semantic - whether the packet should be allowed to leave the domain, while some filter may care about another semantics. Cheers, Sheng >So even from a simple analysis, this seems somewhere between useless and >extremely dangerous. > >Yours, >Joel M. Halpern > >On 5/30/2013 3:00 AM, Sheng Jiang wrote: >... >> Hi, Tim, >> >> It is exactly what the draft document. These semantics is only meaningful >locally within the assigning provider network. It may only be interpretation >between agreeing providers. >> >> Any efforts to add global or generic semantics to IP address is overload the >IP architecture and it bad direction, I agree. >> >>> I think people will do this type of thing, so an Informational document >>> discussing the pros and cons, and how semantics can be used, is probably a >>> good thing. Perhaps a "Potential Pitfalls" type section after the >"Potential >>> Benefits" section would balance the document a little better? >> >> Yes. We will do so in the future version. >> >> Cheers, >> >> Sheng >... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
