hi Woj, thanks a lot for the clarification.
2012/6/27 Wojciech Dec <[email protected]> > Hi Maoke, > > inline... > > On 27 June 2012 05:28, Maoke <[email protected]> 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". 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. > >> 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. > >> 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? > >> 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? > >> 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
