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

From: Tom Taylor <[email-masked]>
Date: Thu, 24 Jan 2013 19:25:32 -0500

Section 4
---------

It might be best to describe operations with respect to shared addresses 
first, then describe the exceptions for full IPv4 addresses or IPv4 
prefixes at the end. As it is, you switch back and forth from these to 
shared addresses and it is not totally clear what applies to one versus 
the other. The main question that arises in my mind as a result of the 
current arrangement of text is whether a NAPT is required if a full 
address or prefix is provisioned. If so, what does it do? Beyond that, I 
would even question whether a MAP module is needed for a full address or 
an address derived from a prefix, and not simply an RFC6052-compliant 
encapsulator.

Paragraph 4 talks about MAP provisioning a full address or prefix. I 
don't think MAP is a provisioning process -- just talk about whether a 
full address or a prefix was provisioned.

Typo in the first line of the section: s/e.g. For/e.g., for/.

Section 5
---------

Where is the definition of the optional port parameters?

Section 5.2
-----------

The first sentence of paragraph 3 relates to the naive algorithm 
specified in paragraph 2 and should be part of that paragraph. I was 
confused the first time I read this part.

Section 5 has now abstracted the port mapping algorithm, leaving it 
unspecified. But the GMA is still there implicitly. I believe it 
wouldn't hurt to say that the underlying algorithm allocates ports to a 
given CE as a series of contiguous ranges, occupying the same relative 
position in each in a series of fixed-sized blocks.

More later ...

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Jan 2013 10:47:00 +0100

Tom,

thanks again for thorough comments, very much appreciated!

> Section 4
> ---------
> 
> It might be best to describe operations with respect to shared addresses first, then describe the exceptions for full IPv4 addresses or IPv4 prefixes at the end. As it is, you switch back and forth from these to shared addresses and it is not totally clear what applies to one versus the other. The main question that arises in my mind as a result of the current arrangement of text is whether a NAPT is required if a full address or prefix is provisioned. If so, what does it do? Beyond that, I would even question whether a MAP module is needed for a full address or an address derived from a prefix, and not simply an RFC6052-compliant encapsulator.

I tend to agree  with your concerns with regards to the shared address, full address, prefix split.
would you be able to create a proposal for how the document would be organised, e.g. with section titles,
if we refactor it this way?

at NA(P)T is optional in the full IPv4 address or IPv4 prefix case.
it would in that case work exactly like IPv4 NAT does on CPEs today.

RFC2473 compliant encapsulator?
RFC2473 only specifies a point to point tunnel. the MAP modules gives provisioning and it gives mesh mode.

> Paragraph 4 talks about MAP provisioning a full address or prefix. I don't think MAP is a provisioning process -- just talk about whether a full address or a prefix was provisioned.

what would be a better wording?
MAP "calculates" an IPv4 address based on some information from a DHCP option and some (or none) information from the IPv6 prefix.
what's the verb describing that? "the MAP CE _implies_ its IPv4 addressing information". deduces, calculates, configures? 

> Typo in the first line of the section: s/e.g. For/e.g., for/.

fixed.

> Where is the definition of the optional port parameters?

it is currently described under "a-bits" section 5.1.
the optional port parameters only include the offset.
although -02 alluded to also a "well known ports" flag.

flexibility versus simplicity. in my opinion we should drop the port parameters
from the base MAP spec, and fix the offset to 4.

> Section 5.2
> -----------
> 
> The first sentence of paragraph 3 relates to the naive algorithm specified in paragraph 2 and should be part of that paragraph. I was confused the first time I read this part.

could you point out the exact paragraphs, I'm not quite sure which ones you mean?

> Section 5 has now abstracted the port mapping algorithm, leaving it unspecified. But the GMA is still there implicitly. I believe it wouldn't hurt to say that the underlying algorithm allocates ports to a given CE as a series of contiguous ranges, occupying the same relative position in each in a series of fixed-sized blocks.

thanks, I've added that more or less verbatim.

Best regards,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 25 Jan 2013 11:42:26 -0600

May I suggest that Tom to become the editor of MAP-E draft?

Behcet

On Fri, Jan 25, 2013 at 3:47 AM, Ole Troan <[email-masked]> wrote:

> shared addresses and it is not totally clear what applies to one versus the
> other. The main question that arises in my mind as a result of the current
> arrangement of text is whether a NAPT is required if a full address or
> prefix is provisioned. If so, what does it do? Beyond that, I would even
> question whether a MAP module is needed for a full address or an address
> derived from a prefix, and not simply an RFC6052-compliant encapsulator.
>
> don't think MAP is a provisioning process -- just talk about whether a full
> address or a prefix was provisioned.
>
> MAP "calculates" an IPv4 address based on some information from a DHCP
> option and some (or none) information from the IPv6 prefix.
> what's the verb describing that? "the MAP CE _implies_ its IPv4 addressing
> information". deduces, calculates, configures?
>
> unspecified. But the GMA is still there implicitly. I believe it wouldn't
> hurt to say that the underlying algorithm allocates ports to a given CE as
> a series of contiguous ranges, occupying the same relative position in each
> in a series of fixed-sized blocks.
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>