Dear Tom, Sorry for late reply due to the instability of my mail account recently. Thanks a lot for your detailed comments! We will modify it accordingly.
My comments for section 4 is inline below. Maoke will give his comments on section 5 in a separated mail. On Thu, May 16, 2013 at 2:11 AM, Tom Taylor <[email protected]>wrote: > I have a number of trivial editorial comments, which I will share > privately with the authors. However, I also have a few points for broader > review. > > Section 4.1, Figure 3 > ===================== > > The introductory text to this figure reads: > > "Figure 3 illustrate a typical case, > where the home network have multiple connections to multiple > providers or multiple logical connections to the same provider." > > It seems to me that Figure 2 illustrates this case but Figure 3 does not. > Was this a mistake in labelling? Is Figure 3 even necessary given that the > point is made with Figure 2? > [Qiong] It is true that Figure 2 can also illustrate network model C. We will modify it accordingly. > > Section 4.2 first paragraph > =========================== > > In the middle of the paragraph there is the statement: > > "All CEs in the MAP domain are provisioned with the same set of MAP > rules by MAP DHCPv6 server [I-D.ietf-softwire-map-dhcp]." > > Wouldn't that be true only in mesh mode? In Hub-and-spoke mode, each CE > needs just its own BMR and the address of the BR. > [Qiong] Right. My intention is for both hub&spoke and mesh, since the differences between hub&spoke and mesh is only listed in the end of this paragraph. > > It seems to me there should be a statement somewhere (probably in the MAP > document, but also here) that the only difference between a BMR and an FMR > is the point of view. Every FMR is also a BMR for the destination CE. Then > the difference between hub-and-spoke and mesh is a matter of whether CEs > outside of a given sub-domain get provisioned with the BMR shared by the > members of that sub-domain. > [Qiong] Good suggestion, will do. > > Section 4.2.2 last sentence > =========================== > > The sentence reads: > > "But all CEs within the same MAP sub- > domain would have the same Rule IPv4 prefix, Rule IPv6 prefix and > PSID parameters." > > The PSID value will be unique to a specific CE within a given sub-domain. > Using the phrase: "PSID parameters" suggests it will not. Perhaps you > should replace PSID parameters by "number of Embedded Address (EA) bits". > [Qiong] Agree. Thanks! > > Section 4.2.3.3 last paragraph > ============================== > > The paragraph in question reads: > > "There is also a suggestion that an implementation may allow the CE > sends packet with destination address and port pointing to itself. > The hairpinning supported by the BR for the Hub/Spokes mode delivers > the packet back to the sender CE itself. Through this the probe on > the connection between CE and BR is enabled." > > This paragraph is talking about CE and BR capabilities rather than > operator planning. I think it belongs in the MAP document rather than here. > I note that the topic comes back in point 4 of Section 4.3. > [Qiong] Agree. We will remove it. > > Section 4.2.4 > ============= > > Again the first sentence says that all the CEs in the same MAP domain get > the same set of MAP rules. Please see the comments for Section 4.2. > > Further along in the first paragraph there is a reference to rule port > parameters. These are no longer mentioned in the MAP document. However, > Section 5.1 of that document has the following: > > "a-bits The number of offset bits. The default Offset bits (a) are 6, > this excludes the system ports (0-1023)." > > The use of the term "default" suggests that the value of 'a' is > provisionable. I recently generated results showing that, depending on the > intended number of ports per user, it is possible that a lower value of 'a' > would give a higher sharing ratio even though more than 1024 ports are > excluded as a result. This is due to the effects of rounding. Bottom line: > it may be that the value of 'a' should be made explicitly provisionable, > and it may be that my results would be useful in the deployment document. I > can send them along if the authors are interested. > [Qiong] We will update this part according to your latest results. That will be quite helpful for deployment. > > Section 4.2.5 > ============= > > The offset is discussed here, so my remarks on the value of 'a' in the > previous section also apply. Note that this section currently says the > default is 4 rather than 6. > > The statement that PSID cannot be zero is incorrect unless 'a' is set to > zero (port set consists of a single contiguous range). The correct > statement is that the initial part of the port number (the a-bits) cannot > be zero. There should be a reference to Appendix B of the MAP document when > discussing this. > [Qiong] Thanks. We will correct it in the next version. Best wishes Qiong > > Section 5.1 step B1 > =================== > > The example uses working addresses. It should use addresses from the > documentation ranges in the IANA IPv4 Special Purpose Address Registry: > 192.0.2.0/24, 198.51.100.0/24, and/or 203.0.113.0/24. > > Section 5.1 step B2 > =================== > > Do I misunderstand, or was the 3-bit PSID length chosen arbitrarily as > part of the example? Actually, I would expect the sharing ratio (or more > likely the number of ports per subscriber) to be the starting point, so you > might say instead (following the first sentence): > > "Suppose the intended sharing ratio is 8 subscribers per address, > resulting in (65536 - 1024)/8 = 8064 ports per subscriber assuming that the > well-known ports are excluded. Then the PSID length to achieve this will be > log2(8) = 3 bits. Bearing in mind the IPv4 16 bit prefix length for each of > our two prefixes, the EA-bit length is (32 - 16) + 3 = 19 bits." > > Section 5.1 step B3 > =================== > > I found this step rather mysterious until I got to step C3. Presumably the > purpose is to generate a unique IPv6 prefix per MAP rule. I suggest you > start by stating that as a requirement. Instead of the term "index", which > to me suggests consecutive values, how about "prefix extension"? > > A couple of minor points: > -- in the second paragraph, > s/contiguous block/contiguous address block/ > I have ports on the brain from recent work. Others > may also be confused. > > -- Is there a more usual notation for a binary value x, instead of > bin(x)? > > I'll read the rest of the document, so there may be more comments, but > this is a start. > > Tom Taylor > ______________________________**_________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires> > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
