Hello Maoke, inline...
On 27 June 2012 12:55, Maoke <[email protected]> wrote: > 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". > 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. > > 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. 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. > >> 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. > > >> >>> 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). 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
