Hi Ted and all, On 2013-5-31, at 19:37, Ted Lemon <ted.le...@nominum.com> wrote:
> On May 31, 2013, at 5:46 AM, Ray Hunter <v6...@globis.net> wrote: >> I was suggesting looking at using a tag option within an existing header >> (the hop by hop header), which theoretically is already processed by all >> nodes along the path. So new options rather than a new header. > > Right, but the hop-by-hop header doesn't exist unless you add it, and it > can't be processed on the fast path. It's useful for networks where there > _is_ no fast path (e.g., llns), but not so useful for the applications we're > talking about here (e.g., VoIP). > >> But why are people coming up with these schemes for encoding semantics >> in the address prefixes in the first place? That's what I'd like to >> understand first and foremost: what lack of functionality is >> motivating/forcing these people to adopt such schemes? > > This is a good question to be asking. [Qiong] I'm trying to answer this question from operator's aspect. When we are trying to encode semantics e.g service type, subscriber type, etc., in some flag, it should have the following features: 1) It should exist and be encoded from the beginning. Otherwise, we still need to introduce dpi-related system to identify certain services, which I believe is not scalable. 2) It cannot be changed along the path. Otherwise, there will be trust issue and may be changed to a different value without notice. 3) It can be easily treated in existing routers. In the ideal way, it does not need to introduce new functionality so that all our existing routers can deal with it. This can greatly reduce our upgrading cost. These are major reasons that we embed semantics in prefixes. But I'm still open suggestions if there is a better choice. Best wishes Qiong > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
