I really don't see the need for having to specify more than one BR prefixes (of whatever length) inside a single MAP domain. Let alone FQDN or list of IP addresses.
The reason is that having multiple BR prefixes in the same domain would at best allow the upstream traffic to go to different BR. But it would nothing to differentiate the downstream traffic, as it can come from any BR. So, load-splitting would be very poor and yield no benefit. As far as availability is concerned, then any casting is already good enough. After all, most 6rd deployments stick with a single BR prefix. Lastly, it would be a severe mistake of ours to limit the BR to a prefix of /128 length. As few other operators (e.g. Reliance) have already noted their use of MAP-T, it would be prudent for the same provisioning option to work with it. Thankfully, this is correctly specified in the map-dhcp draft. Cheers, Rajiv -----Original Message----- From: Ole Troan <[email protected]> Date: Friday, April 26, 2013 4:39 AM To: Ian Farrer <[email protected]> Cc: Softwires-wg list <[email protected]> Subject: Re: [Softwires] Provisioning Format for CPE BR/lwAFTR Address >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. > >> 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. > >> 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). > - 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. > >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
