John,
2012-04-10 15:15, John E Drake: > Remi, > > As an observer, it seems as though you think you are running the WG rather > than being a participant in it. Be sure I am far too realistic to believe that! But I did invest lot of time and energy to build what a number of people find a good proposal. Current effort is to avoid this to be lost just because of a premature decision, one that would not reflect the clear lack of consensus for MAP that we saw in Paris. Regards, RD > > Thanks, > > John > > Sent from my iPhone > > From: [email protected] [mailto:[email protected]] On > Behalf Of Rémi Després > Sent: Tuesday, April 10, 2012 5:52 AM > To: Wojciech Dec > Cc: Softwires WG; [email protected]; Softwire Chairs > Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How? > > > Le 2012-04-10 à 12:07, Wojciech Dec a écrit : > > > The pre-standard-still-being-defined DHCPv6 option was not tested, and CLI > based configuration including scripting was applied. > > > > Question closed. > > For you, that's your choice, fair enough. > > But not closed for the WG: members deserve to know how CEs are proposed to > know whether they must work in mesh or hub-an-spoke topology (even if MAP > remains experimental). > > RD > > > > -Woj. > > On 10 April 2012 12:01, Rémi Després <[email protected]> wrote: > Wojciech, > > This isn't answers to questions I asked. > They remain open. > > RD > > Le 2012-04-10 à 11:51, Wojciech Dec a écrit : > > > Remi, > > you're apparently confusing matters. There is no need to have a DHCPv6 > option, or a million node deployment to test MAP implementations. DS-lite is > a good example, with implementations and standards track before the DHCPv6 > option. > > Needless to say, if you're implying that tests of MAP without testing the > standards based DHCPv6 option are insufficient, then any test of 4rd-u or > anything for that matter without using the fully standards DHCP option would > be equally flawed. > At the very least however, MAP does not need to prove on thing: Compatibility > with IPv6, which 4rd-u would need to. > > -Woj. > > On 10 April 2012 11:37, Rémi Després <[email protected]> wrote: > Hello, all, > > We have heard many times that MAP is completely specified, and has been > extensively tested. > Yet: > - mapping rules of tested configurations have not been provided > - several missing points of the MAP-T+E specification have been identified > (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html). > > This mail is just about ONE of these, the hub-and-spoke issue. > It has been discussed several times but AFAIK still without a complete answer. > > The difficulty is that: > - The MAP-DHCPv6 draft has no parameter to indicate whether the ISP-chosen > topology is mesh or hub-and-spoke. > - According to the MAP-address-and-port draft, "each MAP node in the domain > has the same set of rules". > - As answered in the mail below, the choice "needs to be provisioned. either > explicitly or implicitly (via the rules)". > > Questions I have are then: > - Is the choice provisioned explicitly, implicitly, or possibly both? > - How? > - Which tests have confirmed that it worked? > > Answer by any one who asserts he or she understands how MAP works will be > welcome. > > Thanks, > RD > > > > > > > > > De : Ole Trøan <[email protected]> > > Date : 2012-03-14 14:29 > > À : Rémi Després <[email protected]> > > Cc : Tomasz Mrugalski <[email protected]>, Softwires WG > > <[email protected]> > > Objet : Rép : [Softwires] Question about hub-and-spoke operation in MAP > > > > Remi, > > > >> I couldn't figure out by how CEs can be required to work hub-and-spoke > >> without some DHCPv6 indication: > >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how do > >> they know whether their ISP expects direct paths between them (mesh) or BR > >> hairpinning (hub-and-spoke)? > >> > > > > that's correct it needs to be provisioned. either explicitly or implicitly > > (via the rules). > > > > cheers, > > Ole > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
