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?
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.
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.
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".
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.
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.
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.
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
