Dear all, Here is my opinions on the issues.
The DMR sub-option for MAP-T is not that compatible to the current logic of Unified CPE, i.e. using presence or absence of options to tell which mode to configure.Would it be possible to separate the DMR sub-option from MAP DHCP to another doc? As I see, this option causes the difference in provisioning between MAP-E and MAP-T. And currently there is no DMR in MAP-E draft. As for the multiple BRs issue, I think it reasonable to not constrain this usage. But more thinkings are required on how to make it work well. Or could we do as 6RD does (Ole: allow for multiple BRs, but not specify how multiple BRs could be used)? Personally speaking, I'm in favor of using RFC6334 for BR/lwAFTR address provisioning. In this way, we can leverage the existing standard, which may not delay the overall standardizing process, but also feasible. Hope this helps. Best Regards, Qi On 2013-5-3, at 下午11:23, <[email protected]> <[email protected]> wrote: > Hi Ole, > > See inline. > > Cheers, > Ian > > > > >> Ian, >> >>> Sorry to dig this one up again, but although there has been a fair bit >>> of discussion around the topic, I don't think that we have so far >>> reached an agreement on how to provision sw CPEs with the address of the >>> concentrator for MAP-E and lw4o6. We need to get a final answer on this >>> as there's a few drafts (softwire-unified-cpe, softwire-map-dhcp, >>> softwire-lw4over6) that are relying on it. >>> >>> To try and summarise what's already out there: >>> The Unified CPE & lw4o6 drafts propose the use of DHCPv6 Option 64 (the >>> DS-Lite AFTR FQDN option) >>> Map-dhcp describes the use of the default mapping rule (DMR) to provide >>> the /128 of the BR >>> >>> I think that it's reasonable to say that both work I.e. They contain >>> enough information to provision the client with the /128 of the >>> concentrator so that it can send traffic. >>> >>> Here are the arguments for/against each that I've seen. I've tried to >>> list all the ones that I've seen, so if I've missed any, then please add >>> them: >>> >>> DHCPv6 Option 64 >>> Pros >>> FQDN means that DNS round-robin load balancing could be used >> >> RFC6334 specifies that only the first AAAA should be used. > > [ian] Checking 6334 section 5 - "If any DNS response contains more than > one IPv6 address, the B4 > system picks only one IPv6 address and uses it as a remote tunnel > endpoint for the interface being configured in the current message > exchange." > > So you could use Option 64/DNS to provision multiple endpoints. You'd need > another mechanism (e.g. The bfd model) to detect failure and take > advantage of it, though. > >> >>> Reuse of an existing option >>> >>> Cons >>> Can not be extended with additional sub-options >> >> the CE needs to deal with DNS TTL and the added complexity of having the >> resulting "lifetime" of the >> default router be different than the lifetime of the address/mechanism. >> >> only one BR can be configured >> >>> map-dhcp DMR >>> Pros >>> Option has an 'encapsulated options' field, so could be extended with >>> additional functionality (although no additional functionality has >>> currently been proposed at this stage) >>> >>> Cons >>> Only one DMR /128 can be provisioned to a client, so round robin load >>> balancing can't be used >> >> you can use anycast. > > [ian] You can. But then, why do you need the list of addresses suggested > below? > >> >>> May conflict with the MAP-T (</128 prefix) DMR Could be considered to >>> be out of scope for this discussion, but if we are following the >>> mechanisms described in Unified CPE so that a CPE can work out which SW >>> mode to configure, then a dedicated MAP-T sub-option (not shared by any >>> other mode) is needed. This is related to conversations that I've had >>> around extending the Unified CPE model for other softwire approaches. >>> >>> My view: If there is additional functionality required in this option, >>> over an above the provisioning of a /128 prefix for the concentrator, >>> then the MAP DMR (limited to MAP-E) is the clear choice. However, if no >>> such functionality is needed, then we should re-use Option 64. >> >> does anyone know why a FQDN (with restrictions) was chosen for DS-lite? >> >> considerations: >> - MAP: should BR be inside or outside of the domain. if inside use an >> IPv4 address, if outside use an IPv6 address. >> (I believe we have agreed on outside, and for LW46 it must always be >> outside). > > [ian] I think it's simpler just to use outside as a single approach. > >> - should the CE have multiple BRs? and if so, what should it do between >> them? load-balance? >> the choice in 6rd was to allow for multiple BRs, but not specify how >> multiple BRs could be used >> >> my preference is for a simple list of IPv6 BR addresses. i.e. none of the >> two above options. > > [ian] As long as this is done as a separate option to the DMR, then I > think this would work. > >> >> 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
