hi Woj,
thanks but it looks you didn't answer my questions somewhere maybe because
my questions were not clearly expressed. ;-) inline..
2012/6/27 Wojciech Dec <wdec.i...@gmail.com>
> Hello Maoke,
>
> inline...
>
> On 27 June 2012 12:55, Maoke <fib...@gmail.com> wrote:
>
>> hi Woj,
>>
>> thanks a lot for the clarification.
>>
>> 2012/6/27 Wojciech Dec <wdec.i...@gmail.com>
>>
>>> Hi Maoke,
>>>
>>> inline...
>>>
>>> On 27 June 2012 05:28, Maoke <fib...@gmail.com> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Answer 1: Subscriber = MAP CE. We will clarify the term.
>>>
>>
>> got it.
>>
>>
>>>
>>>> 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
>>>
>>
>> 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.
>>
>>
>>>
>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>
>> 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".
>>
>
> 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.
>
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.
>
>
>>
>> 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.
>>
>
> 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.
>
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.
>
>>
>> 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.
>
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.
>
>
>
>>
>>> Disabling the 1:1 mode would actually require a spec change.
>>>
>>
>>>> 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?
>>>>
>>>
>>> Answer 4: Confirmed, intent is for it to be per domain.
>>>
>>>>
>>>> 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)
>>>>
>>>
>>> Answer 5: No need to enumerate, because there is no relation between
>>> these (answered above)
>>>
>>
>> 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:
>>>>
>>>> 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?
>>>>
>>>
>>> Woj> MAP CE.
>>>
>>>>
>>>> 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?
>>>>
>>>
>>> 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.
>>>
>>
>> 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?
>>
>
> 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: 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)
>>>
>>
>> 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?
>>
>
> 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).
>
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
>
> Regards,
> Woj.
>
>>
>>
>>>
>>>> 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.
>>>>
>>>
>>> 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
>>
>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
