Hi, Roland, Thanks for your comments. Yes, the authors will restructure this draft - making it more an analysis draft rather than a proposal. The pitfalls will be an very important part for a neutral analysis.
Cheers, Sheng On 3 June 2013 22:09, Bless, Roland (TM) <roland.bl...@kit.edu> wrote: > Hi, > > On 31.05.2013 11:46, Ray Hunter wrote: > > > 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? > > I'm not sure. Some impressions from the draft I got when I browsed > over it: > - An address is something that the provider controls, therefore > it may have more trust in the address information, esp. if > source address filtering is done properly. The draft seems > to promote the idea in favor of others like DSCP marking > (which is untrusted up to the boundary node anyway). > > - Overloading semantics is IMHO a bad thing as it complicates > things as well, e.g., encoding application-level semantics into the > network layer is generally a bad idea (see end-to-end > argument - putting appl.-level knowledge into the network implies > inflexibility and increased complexity). Moreover, choosing the right > address/network prefix must not require network topology knowledge > in the application (remembering the site-locals discussion several > years ago). > > - one useful scenario, however, may be the use of different security > zones. We actually proposed this in an internal network > of a vehicle - the particular advantage is here that you can easily > perform security policy enforcement with firewalls and address > filtering rules. > However, you also may have a topological/logical subnet structure > in addition to the security zones, leading to a subnet matrix > structure. In addition to that you may have different QoS > requirements for traffic within a subnet, so DSCP marking is also > orthogonal to the "address" semantics - you should not encode them > into the prefix as well. > > - dividing a network into different subnets according to different > semantics is nothing unusual and is widely used today, mostly > motivated by either topological aspects, logical user/device groups, > and/or trust/security domains. However, semantics b., d. and e. > of > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03#section-4.3 > (applications, traffic identity types, quality requirements) > seem to be bad reasons for "encoding" them into prefixes, IMHO. > > Thus, if the document is adopted somehow, it should rather > point out the potential pitfalls. Currently, as other already said, > it reads as it would be a preferred operational method... > > Regards, > Roland > > _______________________________________________ > 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 --------------------------------------------------------------------
