Hi Yiu, > -----邮件原件----- > 发件人: Yiu L. Lee [mailto:[email protected]] > 发送时间: 2010年8月11日 4:48 > 收件人: xuxiaohu 41208; [email protected] > 主题: Re: [Softwires] Why RFC5512 can not be used for inter-AS softwire mesh > > Hi Xiaohu, > > I agree that RFC5512 alone can't solve the problem because of the reason you > pointed out. Using extcommunity is an option for an operator who owns > multiple ASes to form Inter-AS softwire mesh inside its domain. However, you > may also want to mention that two different operators may want to directly > peer to each other for Inter-AS softwire because creating softwire requires > resource, an operator may want to have explicit peering relationship to > another operator to form the mesh.
Good points, I will include this scenario into the new version. Any further comments are welcome. Best wishes, Xiaohu > Regards, > Yiu > > > On 7/30/10 5:30 AM, "xuxiaohu 41208" <[email protected]> wrote: > > > Hi all, > > > > The abstract of RFC5512 (The BGP Encapsulation Subsequent Address Family > > Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute) is as follows: > > > > Abstract > > > > In certain situations, transporting a packet from one Border Gateway > > Protocol (BGP) speaker to another (the BGP next hop) requires that > > the packet be encapsulated by the first BGP speaker and decapsulated > > by the second. To support these situations, there needs to be some > > agreement between the two BGP speakers with regard to the > > "encapsulation information", i.e., the format of the encapsulation > > header as well as the contents of various fields of the header. > > > > According to RFC5512, the tunnel is started from one BGP router and terminated > > another (i.e. the BGP next hop), unless ensuring that an ASBR that is not > an > > AFBR does not change the next hop of the E-IP routes (i.e., option 3 for > > inter-AS softwire described in Softwire Mesh Framework [RFC5565]), RFC5512 > > alone can not be used to support inter-AS softwire mesh. > > > > As I mentioned during my presentation, the option 3 described in RFC5565 > > requires all non-AFBR ASBRs to be upgraded in order to support this > > capability. In contrast, our approach has not such limitation since we use > a > > transitive Extended Community attribute to carry the tunnel endpoint address. > > > > Best wishes, > > Xiaohu > > > > > > > > > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
