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]> <[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] > 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. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: a) Fairness (no CPE gets well-known ports 0-1023) b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes d) UPnP friendliness (interleaved port sets) 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. > *) > o Multiple Port Ranges: Capability to assign multiple contiguous > port ranges to a single PRD > > Jacni>: I guess this only applies to "portrange" which offers contiguous > port-set. So, I would suggest removing this property. > [Med] Ok. > > *) For "despres-4rd", > Differentiated Port Sets Supported, through different piece of rules, > delegated CPE prefixes of different length. > [Med] the concern is more on the border router side, can you please check if > the operations are still stateless at the border side? Yes, still stateless. The BR doesn't need to know the length of a CPE prefix to build an address that starts with the CPE prefix. It may have bits beyond the CPE prefix, but the CPE ignores them. Kind regards, RD > BTW, I'm envisaging having two properties here: > > (1) Differentiated Port Sets (network level) > (2) Differentiated Port Sets (bound to the same shared address) > > IPv4 traffic Isolation supported > [Med] Ok. This is supported by assigning two prefixes. IPv4 traffic is recognized by the fact that Interface ID is a 4rd IID (sec 5.3) > > Prefix Aggregation supported, since the IPv6 address planning is not > affected. > [Med] Ok. > > I'll come back to you later if I get more. > > > Cheers, > Jacni > > On Tuesday, September 06, 2011 12:44:48 AM, > [email protected] wrote: >> >> Dear all, >> >> We have just submitted an I-D analysing the port set algorithms we have on >> the table. A set of properties are used to characterize the port set >> algorithms. >> >> This is a call for review. In particular, we invite authors of the following >> proposals to review their section: >> >> o [I-D.boucadair-behave-ipv6-portrange] >> o [I-D.xli-behave-divi] >> o [I-D.murakami-softwire-4v6-translation] >> o [I-D.murakami-softwire-4rd] >> o [I-D.despres-softwire-4rd-addmapping] >> >> Questions, suggestions, corrections and contributions are more than welcome. >> >> Thank you. >> Cheers, >> Med >> >> >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] De >> la part de [email protected] >> Envoyé : lundi 5 septembre 2011 18:33 >> À : [email protected] >> Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Analysis of Port Indexing Algorithms >> Author(s) : Mohamed Boucadair >> Nejc Skoberne >> Wojciech Dec >> Filename : draft-bsd-softwire-stateless-port-index-analysis-00.txt >> Pages : 25 >> Date : 2011-09-05 >> >> This document analyzes various algorithm proposals for building port >> sets. These algorithms are used to encode the range of ports in an >> IPv6 address and prefix in the context of stateless solutions. The >> ultimate goal of this analysis is to converge on one or a set of >> algorithms to be used by all stateless solutions. >> >> This is a companion document to >> [I-D.boucadair-softwire-stateless-rfc6052-update]. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt >> _______________________________________________ >> I-D-Announce mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
