Hi Maoke, On 20 July 2012 03:17, Maoke <fib...@gmail.com> wrote:
> hi Woj, > > let me truncate the old text that makes this message too long. focusing on > the recent replies. > > 2012/7/19 Wojciech Dec <wdec.i...@gmail.com> > >> Hello Maoke, >> >> okay, if your "MAP algorithm" refers to the GMA, it is fine to state GMA >>> is usable to address/port-set assignment and/or stateless IPv4-mapped IPv6 >>> address generation. however, only the GMA doesn't make MAP as a "mapping of >>> address and port". the purpose of mapping is making a stateless packet >>> transform at the IPv4/IPv6 boundary and vise versa. >>> >> >> The mapping still happens, in the lower 64 bits. >> > > clarified. thanks. > > >> >> >>> if you argue GMA is generic for universal cases of A+P ( i actually >>> agree that ), i suggest to submit GMA separately as a standard or as an >>> update of A+P, so that stateful/stateless solutions are able to cite it >>> easily. >>> >> >> That's what it was, but it was said to be "too many drafts". >> >>> >>> >>>> In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus >>>> there is no "algorithm is abandoned" case, as you put it. >>>> >>> >>> this a little differs from my early reading on the MAP draft stating >>> 1:1. you clarify here that in any cases IPv4+PSID is embedded in the mapped >>> IPv6 address. >>> >>> >>>> The PSID is intended to be passed as part of the Optional Port >>>> Parameters, which the draft already has as part of the FMRs, and what has >>>> also been discussed in the DT. >>>> >>> >>> yes we have the optional port parameters. but i didn't remember what DT >>> discussed included the topic of having the value of PSID in the FMR. >>> >> >> Please refer to Satoru-san's emails on the topic. >> >>> >>> on the other hand, i think current talk is going on at the WG stage >>> rather than the DT. even if i didn't show objection to that issue in the >>> DT, i don't think i would have been disabled to show it in the WG. >>> >>> >>>> This is another type of 1:1 rules, which I agree is an item of >>>> clarification in the draft, but eminently possible under the current spec >>>> as the the MAP architecture is agnostic to how the IPv6+IPv4+Rules get to >>>> the device >>>> >>> >>> sorry i cannot catch the meaning of the "agnostic to"... :P i understand >>> "how the IPv6+IPv4+Rules get to the device" is the mission of MAP-DHCP >>> rather than the MAP architecture. >>> >> >> Agnostic to means, that the working of the MAP architecture doesn't rely >> on any specific MAP rule or address provisioning method. Should be noted >> that IPv6 addresses are also provisioned, and can be so by multiple methods. >> > > "any specific MAP rule" or any specific rule-making algorithm? if the > former, no objection here. if the latter, i don't see anything essential > other than a rule-making algorithm in the "MAP architecture". and this > rule-making algorithm is what i support through the MDT and the WG. > No, I said, "any specific MAP rule provisioning method". In other words, the MAP architecture is not tied to *how* the MAP info gets to the CPE, be that ipv6 addressing, dhcpv6 or a combination of the two. > > >> >>> >>> if the multiple-CE domain and the single-CE domain should have different >>> attributes, i don't think this is not a novelty. and i am against this >>> configuration parameter no matter if it is *stated* as a non-novelty or >>> not. >>> >> >> And what is the reason for this objection? >> > > does MAP intend to support mesh topology with the PSID value included in > the rule? if so, i doubt any CE device (especially those having limited > resources) can do with that. if it is not, the architecture happens with 2 > configurations not orthogonal: if PSID, no mesh -- it confuses that the > highest priority design goal of MAP is not statelessness and simplicity but > the PSID. > The mesh topology is, and never was, a goal above all others. MAP supports hub&spoke and mesh. Even without an explictly provisioned PSID, there will be practical implementation limits to how many MAP rules a CE can have. The DMR *always* takes traffic not matching a more specific rule to the BR. > > therefore i am objective of introducing PSID into the rule and making the > architecture stateless only in wording. > If you mean that by having PSID as part of the rule, moves MAP from being stateless to "stateful", then that's a misstatement. As per one of the earlier posts, stateless does NOT mean configuration less, and MAP always required configuration, with PSID as part of rules or not. How much configuration one wants to deal with is subject to specific deployment considerations, and MAP allows that amount of configuration to be optimized if a good deal of cases. The working of MAP is unchanged with the use of the PSID as part of the ruleset, given a tradeoff with resepcet to more rules. The main point here though is another: If the use of PSIDs in rules is useful, as it appears to be, then there seems to be no reason not to allow that. Regards, Woj. > > - maoke > > >> >> Regards, >> Woj. >> >>> >>> >>>
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
