Subject: [Softwires] map-00: review on the mode 1:1

From: Maoke <[email-masked]>
Date: Wed, 27 Jun 2012 03:28:52 +0000

hi dear authors,

as the map-00 draft contains the normative 1:1 mode statement that is new
in comparison to the previous versions, i'd like to ask some technical
questions in order to clarify the understanding.

Section 4. page 9:

MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain per subscriber, and the CE is configured in hub and spoke
mode, with only a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of
IPv4 address or prefix and port sets is independent of the End-User
IPv6 prefix.

Question #1: who is a "subscriber"? the definition is missing. and
relatedly, what is the protocol for the subscription? the specification on
the protocol is missing too.

Question #2: what is the relationship between 1:1 mode, encapsulation mode,
translation mode, hub&spoke mode, mesh mode? are they independent to each
other, exclusively or not, somehow orthogonal or not? the specification on
the "mode" is missing.

Question #3: what is the resource for deployment of a "MAP domain"? the MAP
spec never define that. however, we kept understanding that the resource
for a "MAP domain" includes:
             - an IPv4 prefix (with prefix length 32 or less) shared by CEs
in this domain
             - an IPv6 prefix (with prefix length 64 or less) delegated to
the CEs in this domain with a /64 (or shorter) per CE (as the basic model
of prefix d
             the newly introduced "1:1 mode" obviously abandons this
understanding, then an explicit definition on the resource of a "MAP
domain" is requested. this is the origin and essential starting point of
the MAP deployment.

Section 5. page 10:

  * Forwarding mode

Question #4: this appears twice at the definition of BMR and DMR,
respectively. though Wojieich and Remi has discussed that in another
thread, i would like to confirm: is this mode a domain configuration
parameter or a rule parameter?

Question #5: does this "forwarding mode" is a enumerate type of {MAP-T,
MAP-E, 1:1, hub&spoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x
{hub&spoke, mesh}, where the "x" is the operator for de Cartesian product
of sets? (related to #2)

Section 7.1 page 19:

In 1:1 mode, the MAP CE is provisioned with only a Default Mapping
Rule, and the full IPv4 address/prefix and port range is provisioned
using the DHCP option.

Question #6: is the CE or the subscriber the receiver of the "full IPv4
address/prefix and port range" (correction: port set) to be provisioned? or
does it mean a CE is a subscriber itself in the 1:1 mode?

Section 7.3 page 19:

A MAP-E CE provisioned with only a Default Mapping Rule, as in the
1:1 case, and with no IPv4 address and port range configured by other
means, MUST disable its NAT44 functionality.

Question #7: this text is contradictory with Section 7.1. is the DHCP
option a sort of "other means" or not, or there's something out of scope of
this draft?

Question #8: what is the consequence of disabling the NAT44 functionality
on CE when a subscriber having a PSID of a share IPv4 address is running
behind that CE as a 1:1 mode domain?

before all of the above questions and further questions possibly to be
generated during the discussion are fully clarified, i cannot help but
gently show my disagreement on putting the current draft as working group
result. i also hope the MAP spec authors kindly understand with so many
uncertainty modifying MAP deployment draft to fit the MAP spec is a
mission-impossible for the time being.

thanks and regards,
maoke

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jun 2012 10:43:27 +0200

Hi Maoke,

inline...

> the protocol is missing too.

Answer 1: Subscriber = MAP CE. We will clarify the term.

>
> Question #2: what is the relationship between 1:1 mode, encapsulation
> mode, translation mode, hub&spoke mode, mesh mode? are they independent to
> each other, exclusively or not, somehow orthogonal or not? the
> specification on the "mode" is missing.
>

Answer 2: mode = forwarding mode, also known as transport mode. There are
two of these, translation and encapsulation. No relation between the rest
of the things you mention.

>
> Question #3: what is the resource for deployment of a "MAP domain"? the
> MAP spec never define that. however, we kept understanding that the
> resource for a "MAP domain" includes:
>              - an IPv4 prefix (with prefix length 32 or less) shared by
> CEs in this domain

Answer 3: What do you mean by resource for deployment?? It has, and always
has been an IPv6 prefix and an IPv4 address. This is the same in *all* of
this solution space. The split in terms of how one arrives at the IPv4
address and port-range has always been variable in MAP.
Additional point: There is no newly introduced 1:1 mode, as the spec hasn't
changed. Folks who implemented according to the previous spec, whihc you
seem to indicate had no 1:1 mode see no difference. Disabling the 1:1 mode
would actually require a spec change.

> parameter or a rule parameter?

Answer 4: Confirmed, intent is for it to be per domain.

> {hub&spoke, mesh}, where the "x" is the operator for de Cartesian product

Answer 5: No need to enumerate, because there is no relation between these
(answered above)

> does it mean a CE is a subscriber itself in the 1:1 mode?

Woj>  MAP CE.

> option a sort of "other means" or not, or there's something out of scope of

Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing in
the architecture prevents any other provisioning mechanisms to be used incl
dhcpv4, snmp, etc.

> behind that CE as a 1:1 mode domain?

Woj>  That is not possible.  We can be clearer in saying that if the CPE
has no IPv4 address configured then NAT44 is to be disabled (kind of
obvious)

> mission-impossible for the time being.

Woj> What is the basis of your gentle disagreement, and its timing now? The
merged of the drafts was discussed previously, and circulated on the design
team of which you are a apart of. It appears your comments relate to the
supposed controversial 1:1 non-normative text.

Regards,
Woj.

>
> thanks and regards,
> maoke
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 27 Jun 2012 17:57:15 +0900

Hi Maoke, Woj,

Two points.

On 2012/06/27, at 17:43, Wojciech Dec wrote:

> Question #7: this text is contradictory with Section 7.1. is the DHCP option a sort of "other means" or not, or there's something out of scope of this draft? 
> 
> Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing in the architecture prevents any other provisioning mechanisms to be used incl dhcpv4, snmp, etc.

In addition, any provisioning protocol could be used in MAP. But using these protocol in LW46 basis, DHCPv4-over-IPv6 and PCP in particular, absolutely out of scope for MAP.

> 
> Question #8: what is the consequence of disabling the NAT44 functionality on CE when a subscriber having a PSID of a share IPv4 address is running behind that CE as a 1:1 mode domain? 
> 
> Woj>  That is not possible.  We can be clearer in saying that if the CPE has no IPv4 address configured then NAT44 is to be disabled (kind of obvious)

Described text for '1:1 mode' in current version would make some people confused. We need to make clear for that.

cheers,
--satoru

---

From: Leaf yeh <[email-masked]>
Date: Wed, 27 Jun 2012 09:31:09 +0000

Satoru - Described text for '1:1 mode' in current version would make some people confused. We need to make clear for that.

I am also not in favor of the concept of '1:1 mode'. A special mode is called here.

I guess it doesn't mean length (EA bits in End-User IPv6 prefix) = 0.

1:1 might just mean length (Rule IPv4 prefix of BMR) = 32, 

that is a full public IPv4 address is associated with a Rule IPv6 prefix, but this public IPv4 address is definitely for sharing with different PSID. Right?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Wednesday, June 27, 2012 4:57 PM
To: Wojciech Dec
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1

Hi Maoke, Woj,

Two points.

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Wed, 27 Jun 2012 10:55:33 +0000

hi Woj,

thanks a lot for the clarification.

2012/6/27 Wojciech Dec <[email-masked]>

> Answer 1: Subscriber = MAP CE. We will clarify the term.

got it.

> of the things you mention
>

okay. then please clearly revise the wording to avoid confusing the
readers. only after the terms/wordings are revised, the MAP deployment is
able to follow these well-defined words and terms.

>>              - an IPv6 prefix (with prefix length 64 or less) delegated
>> to the CEs in this domain with a /64 (or shorter) per CE (as the basic
>> model of prefix d
> Additional point: There is no newly introduced 1:1 mode, as the spec
> hasn't changed. Folks who implemented according to the previous spec, whihc
> you seem to indicate had no 1:1 mode see no difference.
>

as you clarified CE = subscriber, it is ok. but a new question:

question #3.1: in the 1:1 mode, how long the PSID is? how long the EA-bits?
i understand the bit relationship described in the Figure 7 is the native
property of the MAP algorithm. but it looks to me that 1:1 mode has nothing
related to this figure. it breaks the relation o = p + q. it is hard to
accept that the 1:1 mode is not newly introduced alien. even an alien were
welcome, i would like to suggest the authors prepare a text at Figure 7
stating "this is nosense to the 1:1 mode".

question #3.2: then about the rule, for ONE rule, i see only, in Section 5:
* Rule IPv6 prefix (including prefix length)

* Rule IPv4 prefix (including prefix length)

* Rule EA-bits length (in bits)

* Rule Port Parameters (optional)

(as the 5th "forwarding mode" has been confirmed as a domain configuration)

i don't see there is a PSID value in this tuple, nor i see it in the
example in Sec 5.2, 5.3 for the Given rules.

if Section 5 is not applied to the 1:1 mode, an explicit text "This section
is nonsense to the 1:1 mode" is required. if a PSID value is to be added
into the rule, i understand it is hard to call "not newly introduced"
stuff.

>  Disabling the 1:1 mode would actually require a spec change.
>

> Answer 5: No need to enumerate, because there is no relation between these

question #5.1: do you mean, for example, when i decided the domain forward
mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A while N:1 for CE.B,
right? please confirm this.

> the architecture prevents any other provisioning mechanisms to be used incl

still confusing.
Question #7.1: is what the MAP *can* use a part of MAP spec suite, e.g.,
MAP-DHCP? please clarify explicitly: in the condition of Section 7.1, NAT44
must be disable or not?

> has no IPv4 address configured then NAT44 is to be disabled (kind of

much more confusing.
Question #8.1: please clarify if this CPE has no IPv4 stack enabled or has
only no IPv4 address configured (statically or dynamically). how it works?

> Woj> What is the basis of your gentle disagreement, and its timing now?
> The merged of the drafts was discussed previously, and circulated on the
> design team of which you are a apart of. It appears your comments relate to
> the supposed controversial 1:1 non-normative text.
>

i only talk about the aspect of technical maturity. it is not unreasonable
that i disagree the status of being WG doc even if there might be only me
who hasn't understood.

however, as you raised this question on the procedural justice, i have to
point out the following fact:

 the mdt-named MAP spec was circulated, according to my mailbox record
(maybe i missed some), until March 30, with the last message sent out by
Leaf. however, the 1:1 mode is added on May 31st 10:47:11  timezone +0200
according to the git log and git diff and the next day, June 1st, it
becomes the published version, which appears to IETF draft repos on June
8th. after May 30th, nobody among the authors called for review.

i may imagine that, maybe, the authors were not aware that the 1:1 mode
text IS a sort of change that need to review. but what do you suggest the
"right timing" if it is not NOW?!

i hope i need to point out the above fact only once and never talk on it
again. i also hope it were the case that the authors called for review but
i missed. it is not my purpose to debate on such kind of trivials --
wasting life of you, of me and of all of ours, nor i care what is the
normative text what is not. i only focus on the technical issue. whatever
the timing is, i am against any confusion and misleading.

- maoke

---

From: Maoke <[email-masked]>
Date: Wed, 27 Jun 2012 11:12:21 +0000

hi Satoru-san,

2012/6/27 Satoru Matsushima <[email-masked]>

> > Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing
> in the architecture prevents any other provisioning mechanisms to be used
> incl dhcpv4, snmp, etc.
>
> In addition, any provisioning protocol could be used in MAP. But using
> these protocol in LW46 basis, DHCPv4-over-IPv6 and PCP in particular,
> absolutely out of scope for MAP.
>
>
> >
> > Question #8: what is the consequence of disabling the NAT44
> functionality on CE when a subscriber having a PSID of a share IPv4 address
> is running behind that CE as a 1:1 mode domain?
> >
> Described text for '1:1 mode' in current version would make some people
> confused. We need to make clear for that.
>

i fully agree with you as zero-lengthed EA-bits is a naturally possible
case of MAP. however, to my understanding, even in this case the Figure 7
of MAP addressing architecture is still appliable and therefore it implies
PSID length also equals to zero. this is the real meaning of 1:1 that is a
natural case possibly occurs rather than a "mode" - mode is a sort of
preset configuration. and further, it is not necessary to disable NAT44 in
such EA-null/PSID-null cases at CE.

this definitely makes the MAP spec clear. if necessary, including this
special case in the MAP draft or in the MAP deployment draft, mentioning
its usage, is what i support unless we discover any other flaws regarding
this.

cheers,
maoke

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jun 2012 19:37:01 +0200

Hello Maoke,

inline...

On 27 June 2012 12:55, Maoke <[email-masked]> wrote:

>>> as the map-00 draft contains the normative 1:1 mode statement that is
>>> new in comparison to the previous versions, i'd like to ask some technical
>> Answer 3: What do you mean by resource for deployment?? It has, and
>> always has been an IPv6 prefix and an IPv4 address. This is the same in
>> *all* of this solution space. The split in terms of how one arrives at the
>> IPv4 address and port-range has always been variable in MAP.
> question #3.1: in the 1:1 mode, how long the PSID is? how long the
> EA-bits? i understand the bit relationship described in the Figure 7 is the
> native property of the MAP algorithm. but it looks to me that 1:1 mode has
> nothing related to this figure. it breaks the relation o = p + q. it is
> hard to accept that the 1:1 mode is not newly introduced alien. even an
> alien were welcome, i would like to suggest the authors prepare a text at
> Figure 7 stating "this is nosense to the 1:1 mode".
>

The relation of o = p + q holds, for all values of p and q giving 0 <= o
<=48. Given that we have resticted MAP to positive values of p and q,
although negative were suggested, that provides you the range of p and q.

> example in Sec 5.2, 5.3 for the Given rules.

Well, if you look at the info list passed in an FMR you will see that
everything is there allowing the derivation of a PSID for a given
destination if/when needed and/or the port range from a given FMR. In the
case of EA=0, the prefix is enough for forwarding.

>
> if Section 5 is not applied to the 1:1 mode, an explicit text "This
> section is nonsense to the 1:1 mode" is required. if a PSID value is to be
> added into the rule, i understand it is hard to call "not newly introduced"
> stuff.
>

As explained, it is not :-) And again, I bring your attention to what
several implementers said about this, all of whom used previous drafts as
their spec.

>> Answer 5: No need to enumerate, because there is no relation between
>> these (answered above)
>>
>

Each CE is configured independently. In case you mean to ask about two CPEs
in the same domain having different domain configurations (eg BMR), I would
like to point out that this makes them be in separate domains...

> MAP-DHCP? please clarify explicitly: in the condition of Section 7.1, NAT44

MAP is not defined or restricted to use of dhcpv6. As I state above, if one
wishes to use any other provisioning mechanism, then that is fine.

> only no IPv4 address configured (statically or dynamically). how it works?

Sorry, but your question doesn't appear to be quite logical. You asked,
"what is the consequence of disabling NAT44 functionality" in the context
of draft text which effectively says (which could be clearer) "disable
NAT44 if there is no IPv4 address". Perhaps you could clarify what you see
as running NAT44 without an IPv4 address, and then we can talk about its
consequences (it does not appear to be MAP issue however).

Regards,
Woj.

---

From: Maoke <[email-masked]>
Date: Thu, 28 Jun 2012 01:53:35 +0000

hi Woj,

thanks but it looks you didn't answer my questions somewhere maybe because
my questions were not clearly expressed. ;-) inline..

>>> Answer 2: mode = forwarding mode, also known as transport mode. There
>>> are two of these, translation and encapsulation. No relation between the
>>> rest of the things you mention
>>>
>>

then there are two possible understanding to the "1:1" case:

A. EA-bit becomes zero (it is surely not excluded by the MAP architecture),
o = 0 => p = q = 0.
   p = 0 means the whole IPv4 address (/32) is applied in the mapping
algorithm, with no any bits remained in the generated IPv6 address.
   q = 0 means the PSID length is zero, and therefore the CE working with
such an mapping rule has a (full) IPv4 address without sharing to any
others.

B. CE works with a shared or not shared IPv4 address while it is considered
that the CE is set to work in 1:1 mode.
   if shared, there IS a PSID assigned to the CE but (artificially) not
inserted into the MAP IPv6 address for the CE.

if your "1:1 mode" means A, it is fine and i totally agree that it is a
naturally established case of the MAP;
if your "1:1 mode" means B, i must say the MAP addressing algorithm is
abandoned for this special mode de facto.

i understand current MAP is talking B. please confirm!

up to now, my understanding is: containing the explanation on A and
clarifying its use case would make MAP spec comprehensive, while containing
the text meaning B makes MAP spec a low-quality and confusing doc.

> destination if/when needed and/or the port range from a given FMR.
>

let's make an example similar to Section 5.2 page 16, but in the EA-length
= 0:

CE X:
Forwarding Mapping Rule: {
    2001:db8:0:2:3:4:5:6/128 (Rule IPv6 prefix, call it /64 is no problem),
    192.0.2.18/32 (Rule IPv4 prefix),
    0 (Rule EA-bits length)
  }
PSID offset: 4 (default value as per section 5.1.3)

this FMR stored in BR, to my understanding, is a valid and native MAP rule.
it corresponds to the above 1:1 case A. when a packet
(**)
   IPv4 destination address: 192.0.2.18
   IPv4 destination port: 9030

comes, it is no doubt that the packet can be correctly forwarded to the
above CE X.

however, if there is a PSID for CE X and CE Y, sharing the same IPv4
address, but the PSID is not appear in the Rule IPv6 Prefix (as EA bits are
null):

CE X: same as (*)

CE Y:
Forwarding Mapping Rule: {
    2001:db8:1:2:4:5:6:7/128 (Rule IPv6 prefix),
    192.0.2.18/32 (Rule IPv4 prefix),
    0 (Rule EA-bits length)
  }
PSID offset: 4 (default value as per section 5.1.3)

when the packet (**) arrives at the BR, please tell me: which CE's IPv6
address will be selected for the MAP-E or MAP-T?

> In the case of EA=0, the prefix is enough for forwarding.
>
>>

NOTE: if you try to add a explicit PSID into the FMR, i don't think "what
several implementers said about this, all of whom used previous drafts as
their spec" can prove anything.

if you don't mean to add anything new in the FMR, admitting that the 1:1
case is actually the case A that i mentioned above, we can finish this
thread soon with a consensus to modify the text on 1:1 clarifying this
understanding.

>> question #5.1: do you mean, for example, when i decided the domain
>> forward mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A while N:1
>> for CE.B, right? please confirm this.
>>
>
> Each CE is configured independently. In case you mean to ask about two
> CPEs in the same domain having different domain configurations (eg BMR), I
> would like to point out that this makes them be in separate domains...
>
>>
>>
>>>
>>>> Section 7.1 page 19:
>>>>
> MAP is not defined or restricted to use of dhcpv6. As I state above, if
> one wishes to use any other provisioning mechanism, then that is fine.
>

please answer my question straightforwardly.
Question #7.2: is MAP-DHCP a native MAP component? Yes or No.
Question #7.3: when MAP-DHCP is used, NAT44 for a 1:1 mode CE MUST be
disabled or not? Yes or No.

>> Question #8.1: please clarify if this CPE has no IPv4 stack enabled or
>> has only no IPv4 address configured (statically or dynamically). how it
>> works?
>>
>

here my question is trying to understand what do you mean with the term
"the CPE has no IPv4 address configured". let me change a way of asking:
Question #8.2: does "the CPE has no IPv4 address configured" work in
IPv4/IPv6 dual-stack or IPv6 only?

Question #8.3: if "the CPE has no IPv4 address configured" works in
IPv4/IPv6 dual-stack, why it "has no IPv4 address configured"? how its IPv4
stack works? if it works with IPv6 only, it sounds a case of single
translation, out of the scope of MAP, right?

Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we need
to *disable* the NAT44? i agree with you that "NAT44 is disabled" here is
obvious but i see it is too obvious to cost a "MUST" in the specification.
"MUST disable" means WE, the HUMAN, MUST make an action according to the
specification. question clarified? please confirm that the editor/author of
this text refers the same thing as you interpreted.

thanks and regards,
maoke

>> i only talk about the aspect of technical maturity. it is not
>> unreasonable that i disagree the status of being WG doc even if there might
>> be only me who hasn't understood.
>>

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 28 Jun 2012 14:02:25 +0900

Hi Maoke-san,

On 2012/06/27, at 20:12, Maoke wrote:

> i fully agree with you as zero-lengthed EA-bits is a naturally possible case of MAP. however, to my understanding, even in this case the Figure 7 of MAP addressing architecture is still appliable and therefore it implies PSID length also equals to zero. this is the real meaning of 1:1 that is a natural case possibly occurs rather than a "mode" - mode is a sort of preset configuration. and further, it is not necessary to disable NAT44 in such EA-null/PSID-null cases at CE.
> 

Right, it isn't a 'mode' which changes any MAP nature.

> this definitely makes the MAP spec clear. if necessary, including this special case in the MAP draft or in the MAP deployment draft, mentioning its usage, is what i support unless we discover any other flaws regarding this. 

Thanks for clarification.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 28 Jun 2012 15:32:14 +0900

Remark,

Confusion of current 'draft-ietf-softwire-map-00' version of MAP about 1:1 is that independence between the ipv6 and ipv4 addressing could be represented as bellow:

1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning
2). only DMR provisioning for MAP-CE

So in the 1), it doesn't mean NAT44 disabled on MAP CE. 
In the 2), it does require MAP CE to disable NAT44 for compatibility of MAP-CE(-E) be as DS-Lite B4, and MAP-CE(-T) to be compatible with stateless NAT64.

cheers,
--satoru

On 2012/06/28, at 10:53, Maoke wrote:

> Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we need to *disable* the NAT44? i agree with you that "NAT44 is disabled" here is obvious but i see it is too obvious to cost a "MUST" in the specification. "MUST disable" means WE, the HUMAN, MUST make an action according to the specification. question clarified? please confirm that the editor/author of this text refers the same thing as you interpreted. 
>

---

From: Leaf yeh <[email-masked]>
Date: Thu, 28 Jun 2012 06:37:11 +0000

Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally possible case of MAP. however, to my understanding, even in this case the Figure 7 of MAP addressing architecture is still appliable and therefore it implies PSID length also equals to zero. this is the real meaning of 1:1...

Satoru - Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 options.
BMR:
 o Rule-ipv6-prefix  : {exact matched with CE's delegated prefix}  o Rule-ipv4-prefix  : x.x.x.x/32
 o EA-length         : 0
 o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
(http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html )

I don't think 'it implies PSID length also equals to zero' can be derived from 'zero-lengthed EA-bits' as per the example from Satoru.

On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned in the draft, I'd like to know what the 1st '1' & the 2nd '1' stand for respectively.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Thursday, June 28, 2012 1:02 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1

Hi Maoke-san,

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Thu, 28 Jun 2012 07:31:07 +0000

2012/6/28 Leaf yeh <[email-masked]>

> Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally
> possible case of MAP. however, to my understanding, even in this case the
> Figure 7 of MAP addressing architecture is still appliable and therefore it
> implies PSID length also equals to zero. this is the real meaning of 1:1...
>
> I don't think 'it implies PSID length also equals to zero' can be derived
> from 'zero-lengthed EA-bits' as per the example from Satoru.
>

according to MAP architecture of addressing, EA-length MUST not less than
the length of PSID, no matter it is in DHCP configuration or in FMR
installed in BR. see my analysis in the discussion thread with Dec. having
a PSID for CE but no the PSID embedded in the address makes ambiguity when
mapping entry is selected for a specific IPv4 flow.

>
> On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned
> in the draft, I'd like to know what the 1st '1' & the 2nd '1' stand for
> respectively.
>

fully agree with you that any "1:1" is confusing. my understanding is
1-IPv6 address : 1-IPv4 address. but the term "1:1" is not necessary to
appear in specification.

- maoke

---

From: Leaf yeh <[email-masked]>
Date: Thu, 28 Jun 2012 06:58:14 +0000

Maoke - Section 7.3 page 19:

Supposed the draft is talking about the backward compatibility with DS-lite. When CE provisioned with only a Default Mapping Rule and the CE disable its NAT44 functionality, the CE turns to be B4 of DS-lite, the BR will turns to be stateful AFTR of DS-lite.

But the question on the text of "as in the 1:1 case" seems still be there, because '1:1' continuous to puzzles us before it is defined. 

I don't think the "as in the 1:1 case" is necessary here in the context of this paragraph.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Thursday, June 28, 2012 2:32 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1

Remark,

cheers,
--satoru

---

From: Leaf yeh <[email-masked]>
Date: Thu, 28 Jun 2012 08:37:00 +0000

maoke - see my analysis in the discussion thread with Dec.

That sound the homework of Woj. :-)

maoke - having a PSID for CE but no the PSID embedded in the address makes ambiguity when mapping entry is selected for a specific IPv4 flow. 
Satoru - Confusion of current 'draft-ietf-softwire-map-00' version of MAP about 1:1 is that independence between the ipv6 and ipv4 addressing could be represented as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning 2). only DMR provisioning for MAP-CE

1)  Length (EA bits) = 0 sounds no mapping at CE, the provision of IPv4 address and PSID are independent. The mapping (Fig.7) is expected to be invalid.
2)  Only DMR of MRs is provisioned to CE, sounds that no BMR/FMR defined in the draft-spec is really provisioned to CE.

maoke - my understanding is 1-IPv6 address : 1-IPv4 address.

The alternative of 1:1 might be 1x IPv6 prefix of CE  <->  1x {IPv4 address + PSID} of CE, which sound the same as before as the design target, but the MAP domain is expected only for one CE if length(EA bits) = 0. I supposed there might be some reason that PSID is not embedded, I guess the expectation might be that PSID could be totally independent from the mapping.

Best Regards,
Leaf

From: Maoke [mailto:[email-masked]] 
Sent: Thursday, June 28, 2012 3:31 PM
To: Leaf yeh
Cc: Satoru Matsushima; Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1

according to MAP architecture of addressing, EA-length MUST not less than the length of PSID, no matter it is in DHCP configuration or in FMR installed in BR. see my analysis in the discussion thread with Dec. having a PSID for CE but no the PSID embedded in the address makes ambiguity when mapping entry is selected for a specific IPv4 flow. 

fully agree with you that any "1:1" is confusing. my understanding is 1-IPv6 address : 1-IPv4 address. but the term "1:1" is not necessary to appear in specification. 

- maoke

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Thursday, June 28, 2012 1:02 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1
Hi Maoke-san,

cheers,
--satoru

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 28 Jun 2012 12:17:07 +0000

Hi Woj and Satoru,

Thanks for spending time to explain MAP to the ML. It really helps to
understand it better. Thanks

I concur with Maoke's analysis. If the 1:1 mode means giving the CE a
complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e.
EA-bit=0 and r <= 32) , this is what MAP allows. If 1:1 means explicitly
provisioning PSID in the BR for shared an IPv4 address and PSID isn't
contained in the CE MAP address, AFAIK this is not MAP originally designed
for. 

In the current version of the draft, I found two references:

   MAP can also be provisioned in 1:1 mode.  In 1:1 mode the BR has a
   MAP domain per subscriber, and the CE is configured in hub and spoke
   mode, with only a DMR and no other mapping rules.  This allows for a
   mode where the BR has one rule per subscriber and the provisioning of
   IPv4 address or prefix and port sets is independent of the End-User
   IPv6 prefix.
   In 1:1 mode, the MAP CE is provisioned with only a Default Mapping
   Rule, and the full IPv4 address/prefix and port range is provisioned
   using the DHCP option.
When I read them, my interpretation is when EA-bit=0, port-set could be
provisioned to CE. BR will also install the BMR+Port-set per CE. It seems to
me the 1:1 is the second case rather than first case. Am I reading the draft
wrong?

I also have a question about routing the packet to CE. If EA-bit=0, does
this require each CE will have a different Rule IPv6 prefix (i.e. Each sub
is in its domain)? If not, how does routing work in BR?

Thanks,
Yiu

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 28 Jun 2012 15:28:31 +0200

On 28.06.2012 14:17, Lee, Yiu wrote:
> contained in the CE MAP address, AFAIK this is not MAP originally
> designed for. 
> 
Sorry for interrupting, but which current version do you referring to?
There is softwire-map-01 published earlier today with the 1:1 mode removed.

Cheers,
Tomek

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 28 Jun 2012 13:30:11 +0000

I didn't check there was a newer version. My bad.