Hi Rajiv, Thanks for your response. Comments in line.
Cheers, Ian On 26/04/2013 17:12, "Rajiv Asati (rajiva)" <[email protected]> wrote: > >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. [ian] I'm also not sure about the need for this (I certainly don't plan to use it), but it's been raised. Do any other operators see a need for this in their architecture? > > >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. [ian] MAP-E & lw4o6 both need a /128 for the concentrator (whether this is supplied as a prefix or an FQDN) and will not work without this. MAP-T can not have a /128 prefix for the DMR (/96 is the longest). MAP-E & lw4o6 wouldn't work if they were provisioned with a MAP-T DMR compatible prefix. MAP-T wouldn't work if it was provisioned with a MAP-E / lw4o6 DMR compatible prefix. It makes sense to have a single option/sub-option for provisioning MAP-E and lw4o6 BRs and use a separate option/sub-option for MAP-T. > >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
