Re: [Softwires] Why RFC5512 can not be used for inter-AS softwire mesh

Hi Yiu,

> -----邮件原件-----
> 发件人: Yiu L. Lee [mailto:yiu_lee@cable.comcast.com]
> 发送时间: 2010年8月11日 4:48
> 收件人: xuxiaohu 41208; softwires@ietf.org
> 主题: 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" <xuxh@huawei.com> 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
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires