Hi Rémi, Please see inline.
Cheers, Med ________________________________ De : Rémi Després [mailto:[email protected]] Envoyé : mercredi 7 septembre 2011 14:06 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Jacni Qin; Softwires-wg; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Oops, e) to be deleted from the list below (same feature as c)) Le 7 sept. 2011 à 11:02, Rémi Després a écrit : Hi Med, Thank you for the detailed analysis of our draft. Please see some first comments in line. Le 7 sept. 2011 à 07:22, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> a écrit : Hi Jacni, Please see inline. Cheers, Med ________________________________ De : Jacni Qin [mailto:[email protected]] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; [email protected]<mailto:[email protected]> Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. IMHO, separating port-set indexing and IPv6 address format would be a clarification. [Med] OK, I will do. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: [Med] In fact we are not evaluating the algorithm at this stage but only characterizing them with a set of properties. a) Fairness (no CPE gets well-known ports 0-1023) [Med] We indicate whether this range is excluded or not in the properties table. But, this can be seen also as a loss of port utilization efficiency. b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes [Med] As I mentioned in another e-mail, I added two properties in the table: o Differentiated Port Sets (Network Level): Capability to assign port sets of different sizes to customers attached to the same network. o Differentiated Port Sets (same IP address): Capability to assign port sets of different sizes to customers assigned with the same IPv4 address. d) UPnP friendliness (interleaved port sets) [Med] I guess you are referring to IGD:1. Difficult to assess for at least two reasons: (1) IGD:1 is broken and (2) implementations adopt several behaviour (incremental or random). e) Support of differentiated sharing ratios without per-CPE states in BRs Major criteria to evaluate IPv6 address formats of CPEs: i) Compatibility with IPv4 routes between CPEs as direct as IPv6 routes. (This implies A+P->IPv6 derivation without per-CPE state) j) No impact on the assignment plan of IPv6 prefixes to CPE's. (This excludes in particular full IPv4 addresses in CPE IPv6 prefixes.) k) Optional support of CPE cascades (the suffix field of the 4rd mapping proposals, explained in the 4rd-addmapping draft) OTOH, complexity comparisons, although worth keeping in mind at this stage, are premature (largely subjective before optimized codes have been worked on for stabilized methods). So far, making sure all methods have AFAIK O(1) complexity should IMHO be be sufficient. When clear about other criteria, thin optimization can become relevant.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
