Re: [Softwires] [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast tunnel to BR acceptable for DHCP redundancy?//re: About draft-guo-softwire-6rd-ipv6-config-00

[Mark Townsley <[e-mail]>]

On 8/16/10 3:29 AM, Xu Xiaohu wrote:
> 
> 
>> -----邮件原件-----
>> 发件人: Ted Lemon [mailto:[e-mail]]
>> 发送时间: 2010年8月15日 1:15
>> 收件人: Xu Xiaohu
>> 抄送: 'Ole Troan'; [e-mail]; [e-mail]
>> 主题: Re: [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast
> tunnel
>> to BR acceptable for DHCP redundancy?//re: [Softwires] About
>> draft-guo-softwire-6rd-ipv6-config-00
>>
>> On Aug 8, 2010, at 11:59 PM, Xu Xiaohu wrote:
>>> In addition, in case that the DHCP
>>> server/relay on a given BR is unavailable due to some reason (e.g., no
>>> available address in the pool) but the other functions of it (e.g., the
>>> anycast route for it) are still available, once the DHCP message is
> tunneled
>>> to that BR, the DHCP service is unavailable any more. That's to say,
> it's
>>> hard to achieve the high availability for DHCP servers/relay agents
> since
>>> the DHCP information-request can not be relayed to other DHCP
>>> servers/relays.
>>
>> I don't see the problem here.   If you want redundancy, you should
> configure
>> each BR to relay to more than one DHCP server.   This would be the default
> anyway,
>> according to RFC3315 section 20, which requires the relay to multicast if
> not
>> otherwise configured.
> 
> However, the BR itself (no matter as a relay agent or a DHCP server) is a
> single point of failure, especially in the case where the DHCP service on
> the BR is unavailable while the route for it (anycast address) is still OK. 

Why would you ever deploy 6rd with one BR? We're talking about stateless
DHCP operation here, so *all* the BRs in the SP network could run this
(indeed, all would have to if addressed via the anycast address that 6rd
uses to reach the BRs since you don't know in advance which one you
would reach). As long as all participating BRs have the server or relay
function, I see no single point of failure problem.

- Mark