Hi, I see some issues when using non-topological address hierarchies:
1. For example, if you use addresses <ISP><location><user class><user#><subnet> then you can have one route entry to route all traffic to a location, i.e. <ISP><location> But, it is harder to send traffic of one <user class> over different links than other classes -- you can't have 1 route table entry for: <ISP><*><user class1> --> <ISP><*><user class1> You need L routes if you have L locations. [ Does your router support non-contiguous masks in ACLs, route-maps etc ?? See e.g. Cisco IOS IPv6 Command Reference http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_10.html#wp2653677 IPv6 ACLs only allow e.g. *source-ipv6-prefix*/*prefix-length* which only specifies a left-most contiguous set of bits. It doesn't allow for non-contiguous wildcard-masks like IPv4 did. ] 2. Conversely, if you use addresses <ISP><user class><location><user#><subnet> then it is easier to route via <user class> and <user class> ACLs are very easy. But you aren't aggregating by location any more. 3. Or, if you use addresses <ISP><location><user#><user class><subnet> then you get route aggregation per location, and aggregation per user. But you have lost all route aggregation by <user class> and if you can't do non-contiguous ACLs, then filtering by <user class> will be very hard. === And if you have more semantic fields, then the routing and ACL complexity compounds. === At Monash University, the IPv6 address plan is basically <ISP><user class><faculty><location> ACLs by <user class> or <user class><faculty> are easy. We aren't summarising routes in our IGP, so not being able to summarise by location isn't a big issue for us. John On 4 June 2013 11:13, Sheng Jiang <shengji...@gmail.com> wrote: > 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 蒋胜 > > _______________________________________________ > 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 --------------------------------------------------------------------