Hi Fred, > -----邮件原件----- > 发件人: Templin, Fred L [mailto:[email protected]] > 发送时间: 2011年3月22日 23:06 > 收件人: Xu Xiaohu; 'Ole Troan'; 'Rémi Després' > 抄送: [email protected]; [email protected] > 主题: RE: > [Softwires][dhcwg]fwd:NewVersionNotificationfordraft-guo-softwire-6rd-ipv6 > -config-02 > > Hi again Xiaohu, > > > > Thanks for your explanation. I understand the advantages now. > > > > > > In your approach, to obtain stable IPv6 prefixes for CEs, > > some routing > > > protocol should be run between the CE and the BR while the BR > > > would have to > > > maintain a lot of routes for the delegated native IPv6 > > > prefixes. > > > > The routing protocol in this case would be DHCPv6 > > prefix delegation. To spread the load, we simply > > add more BRs, and make them communicate with each > > other either directly in a full mesh or via a set > > of gateways in a partial mesh. > > This might bear a few more words of explanation. By "the routing > protocol in this case would be DHCPv6 prefix delegation", what I > mean is that the BR acting as a Delegating Router should register > a "link up" event when a CE acting as a Requesting Router asks it > for a prefix delegation, and the BR should maintain that link as being > up until the CE either moves away or dies. On the backhaul network
Without any routing protocol, there should be some keep-alive mechanism running between the BR and the CE at least. Otherwise, the route for the delegated prefix could be pointed to an invalid or even a wrong next-hop (i. e., CE). Is my understanding right? Best wishes, Xiaohu > that connects BRs, then, I am assuming something like an iBGP > instance where all BRs advertise their links that are up and withdraw > their links that have gone down. > > Fred > [email protected]= _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
