Hi Ian, Please see inline,
> [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? Thanks for posing this Q to the other operators (and sharing your view). > [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. If the same option provides prefix-length and prefix, then MAP-E, -T and lw4o6 can leverage it accordingly. This is how MAP-DHCP already does it (for MAP modes) and could be exploited to include lw4o6. This kinda approach is widely used in other protocols: IPv6 RA PIO - http://tools.ietf.org/html/rfc4861#section-4.6.2 MPLS OAM - http://tools.ietf.org/html/rfc4379#section-3.2.2 Cheers, Rajiv -----Original Message----- From: Ian Farrer <[email protected]> Date: Friday, April 26, 2013 11:52 AM To: Rajiv Asati <[email protected]>, Ole Troan <[email protected]> Cc: Softwires-wg list <[email protected]> Subject: Re: [Softwires] Provisioning Format for CPE BR/lwAFTR Address >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
