Subject: [Softwires] Comments on draft-ietf-softwire-map-deployment-01

From: Tom Taylor <[email-masked]>
Date: Wed, 15 May 2013 14:11:07 -0400

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

---

From: Qiong <[email-masked]>
Date: Mon, 20 May 2013 13:37:53 +0800

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-masked]>wrote:

> privately with the authors. However, I also have a few points for broader
> review.
>
> Section 4.1, Figure 3
> =====================
>
> 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
[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.

> 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!

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

> 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

> likely the number of ports per subscriber) to be the starting point, so you
> might say instead (following the first sentence):
>
> 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"?
>
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> 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/ *
===============================================

---

From: Tom Taylor <[email-masked]>
Date: Mon, 20 May 2013 14:59:35 -0400

The results on the relationship of offset 'a' to sharing ratio are shown 
in the latest version of 
draft-tsou-softwire-port-set-algorithms-analysis beginning with the 
notes to Table 3 in Section 3.2.4 and continuing in Section 4. (BTW, the 
title of Table 3 is wrong due to a cut-and-paste error.)

Tom

On 20/05/2013 1:37 AM, Qiong wrote:
...

> will be quite helpful for deployment.
...

---

From: Maoke <[email-masked]>
Date: Tue, 21 May 2013 19:17:29 +0900

dear Tom,

thanks a lot for the comments. sorry for the delay though.
now maoke is replying in line regarding the section 5.

2013/5/16 Tom Taylor <[email-masked]>

> privately with the authors. However, I also have a few points for broader

yes. only a little difficult that originally we took /16 examples but there
is no /16 documentary ranges. :P i am handling with the text by using the
/24 above for the example. however, as the IPv4 space is now limited, the
supported number of CEs with reasonable sharing ratio must be smaller than
the original 2^20. i would like to change it to 2^10.

> Section 5.1 step B2

thanks a lot for suggesting the text. it is true that we firstly have the
sharing ratio as the part of service specification, then we may have the
length of PSID. however, the logic is not only about the sharing ratio. for
example, we have 2^10 CEs, and now we have the service specification that
share per IPv4 address among each 8 CEs, then at least 2^7 IPv4 addresses
are needed. if our held space is less than /25, we cannot play the game
unless we relax the sharing ratio to 16 CEs per address resulting in less
usable ports for each subscriber (CE). i'd like to take your suggest text
as the base and refine the paragraph taking this understanding into
account.

> Section 5.1 step B3

yes. there needs a statement on the requirement too. prefix extension is an
accurate term. thanks a lot for suggesting that.

>      I have ports on the brain from recent work. Others

thanks.

>   -- Is there a more usual notation for a binary value x, instead of

i have the same question but no answer. :P anyone has any suggestion?

> I'll read the rest of the document, so there may be more comments, but

thanks in advance.

best regards,
maoke

>
>
> Tom Taylor
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>