Hi all,

I just found in the folliowing draft there is some consideration about the
inter-AS scenario in which the core transit network consists of multiple
ASes. However, there seems no complete solution in current draft. I wonder
whether it is possible to convey the tunnel endpoint (the border IPv4/v6
router between IPv4 network and IPv6 network) address by an BGP extended
community attribute rather than the nexthop attribute? In this way, the
tunnel endpoint address could  keep unchanged during travelling across ASes,
and it doesn't require every ASBR along the forwarding path to perform
decap/encap operation.

Any comment is welcomed.

Xiaohu
 

> -----邮件原件-----
> 发件人: [email protected] 
> [mailto:[email protected]] 代表 The IESG
> 发送时间: 2009年4月7日 3:59
> 收件人: IETF-Announce
> 抄送: softwire mailing list; Internet Architecture Board; 
> softwire chair; RFC Editor
> 主题: [Softwires] Protocol Action: 'Softwire Mesh Framework' to 
> Proposed Standard
> 
> The IESG has approved the following document:
> 
> - 'Softwire Mesh Framework '
>    <draft-ietf-softwire-mesh-framework-06.txt> as a Proposed Standard
> 
> This document is the product of the Softwires Working Group. 
> 
> The IESG contact persons are Mark Townsley and Jari Arkko.
> 
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-mesh-f
> ramework-06.txt
> 
> Technical Summary
> 
> The Internet needs to be able to handle both IPv4 and IPv6 packets.
> However, it is expected that some constituent networks of the 
> Internet will be "single protocol" networks. One kind of 
> single protocol network can parse only IPv4 packets and can 
> process only
> IPv4 routing information; another kind can parse only IPv6 
> packets and can process only IPv6 routing information. It is 
> nevertheless required that either kind of single protocol 
> network be able to provide transit service for the "other" 
> protocol. This is done by passing the "other kind" of routing 
> information from one edge of the single protocol network to 
> the other, and by tunneling the "other kind" of data packet 
> from one edge to the other. The tunnels are known as 
> "Softwires". This framework document explains how the routing 
> information and the data packets of one protocol are passed 
> through a single protocol network of the other protocol. The 
> document is careful to specify when this can be done with 
> existing technology, and when it requires the development of 
> new or modified technology.
> 
> 
> Working Group Summary
> 
> The SOFTWIRE WG supports the development and advancement of 
> this document.
> 
> 
> Protocol Quality
> 
> This document was thoroughly reviewed by WG chairs and WG 
> members, including those with expertise in IPv4 to IPv6 
> transitions and interworking.
> 
> Dave Ward is the WG chair shepherd.
> 
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to