Subject: Re: Re: [Softwires] Problem Statement draft

From: "Yong" <[email-masked]>
Date: Wed, 26 Oct 2005 17:24:47 +0800

Hi, all,

Although the current P routers are only around 10 in cernet2, the total
number of the P routers deployed all over China will be much more based 
according the CNGI project in the coming years.
Since some of the access networks are IPv6 only, some PE also with CPE 
may also running a single IPv6 stack. Therefore, it is not worth updating 
all PE to support dual-stack.

On the other hand, since there are a large quantity of CPE routers, 
especially with deployment of IPv6, it is almost impossible to leave the
work of connection setup between different CPE routers to the administration
domain of access networks.

Best regards,
16:42:41 2005-10-26
********************************************************
*    CUI Yong                                          *
*    Ph.D, Department of Computer Science & Technology *
*    Tsinghua University, Beijing, P.R.China(100084)   *
*    Tel: (8610)-62795818-6859                         *
*    Email: [email-masked]             *
********************************************************

======= 2005-10-26 15:42:42 You wrote =======

>hi, all,
>
>Pekka Savola wrote:
>> 
>> On Mon, 24 Oct 2005, Durand, Alain wrote:
>> > I don't know if the problem statement draft had been publish yet or not,
>> > in any case, here is a link to it:
>> 
>> Yes, it has been.
>> 
>> A few quick comments below.  I think the 'hub and spoke' problem can
>> be reasonably well justified as indeed folks have talked about it a
>> LOT during the past 5 years or more.
>> 
>> On the other hand, the case for 'mesh' problem is smaller.  I cannot
>> see the justification for running v6-only core (for example) just so
>> you can make 10 P routers v6-only, when you already have to handle v4
>> addressing, routing, etc. for 20 PE routers!
>> 
>> It would make much more sense if none of the PE routers would need to
>> support v4 or v4 would only need to be supported in up to 2 routers
>> (solely for v4 peering and upstream connectivity plus tunnel
>> demarcation for customers).
>> 
>
>the reasons of the mesh model are:
>
>(1) other CNGI backbones may have more pure IPv6 P routers and less
>    dual stack PE routers. this model may also apply to other developing 
>    countries, they likely deploy IPv6 backbones, support many IPv6
>    access networks and limited IPv4 access networks.
>(2) the transition from IPv4 to IPv6 is happening, but the it may
>    take many years. it may exist a state that many IPv6 access networks
>    and several IPv4 access networks exist. in this case, not all the PE
>routers need
>    IPv4 support, but the number of access networks are still more then
>what setting
>    IPv4 tunnels between the access network can handle. 
>
>xing
>
>> ....
>> 
>>   - the editorial quality is not very good (full of typos etc.).
>> Some of the subsections also defined requirements while others
>> describe the scenarios.  It may or may not make sense to try to
>> separate hese.
>> 
>> 3.8.  Scaling
>> 
>>     In a hub and spoke model, an ISP MUST scale the solution to millions
>>     of softwire inititators by adding more hubs (i.e. softwire
>>     concentrator).
>> 
>> ==> s/MUST scale/must be able to scale/
>> 
>>     - End-point failure detection (must be encapsulated w/in the tunnel
>>     in the transmitting direction
>> 
>> ==> please clarify what you mean after '(', it's not clear.
>> 
>>     User Authentication
>> 
>> ==> is authentication of the server a requirement or non-requirement
>> (it'd be good to clarify this as this has often been raised when
>> thinking about the auth mechanism)?
>> 
>>      Reference Diagram
>> 
>>                      ._._._._              ._._._._
>>                     |        |            |        |
>>                     |  V4    |            |  V4    |
>>                     |access  |            |access  |
>>                     |island  |            |island  |
>>                      ._._._._              ._._._._
>> 
>> ==> I don't think this was the case we were talking about.  Shouldn't
>> all the islands be dual-stack?  This is pretty important consideration
>> -- the key point emerges when an island with protocol X would like
>> talk to an island with protocol Y. (where an island could be the rest
>> of the internet as well).
>> 
>>     The AFBR's are the only devices in the network that must be able to
>>     perform dual-stack operations and setup and encapsulate softwires in
>>     a mesh to the other islands.
>> 
>> ==> s/network/ISP's network/ -- the CPEs should obviously be
>> dual-stack, right, so those could set up tunnels if they wished to.
>> 
>>    It should be noted that according to reports the islands do not want
>>     to achieve network connectivity via tunneled Layer 2 mechanisms but,
>>     as distinct Layer 3 or MPLS routers.  This clearly helps scaling and
>>     Layer 2 discovery performance issues.
>> 
>> ==> it isn't clear enough what this point means.
>> 
>> 4.4.  Persistence, Discovery and Setup Time
>> 
>>     Discovery of the AFBRs and softwire encapsulation can be accomplished
>>     by the routing protocol (e.g.  BGP) during capability advertisement.
>>     Or, the endpoints can be passed in new data formats or attributes,
>>     yet to be defined.  The duration of the softwire for inter-island
>>     reachability is considered to be as long as the BGP peering session.
>>     Thus, dynamicity is very low.  The setup time should be on the order
>>     of the same duration to setup L3VPNs.
>> 
>> ==> the first sentences in particular seem like solutionism, reword?
>> ==> is it a requirement that islands must run BGP -- the document
>> seems to assume so?
>> 
>> --
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>> 
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/softwires
>

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Thu, 27 Oct 2005 00:31:16 +0800

Sometime mesh problem is not a simple issue.
 
As the network expand, especially in the transition stage,
manual configuration will has the limitation in the large scale network.
Some people are still expecting the automatic configuration
 
-Hui

	-----Original Message----- 
	From: Pekka Savola [mailto:[email-masked]] 
	Sent: 2005-10-26 (星期三) 17:29 
	To: Xing Li 
	Cc: Durand, Alain; [email-masked]; [email-masked] 
	Subject: Re: [Softwires] Problem Statement draft

	On Wed, 26 Oct 2005, Xing Li wrote:
	>    and several IPv4 access networks exist. in this case, not all the PE routers need
	
	To me, this seems even a stronger reason (from the ISP) to strive for
	a design which would not require having v4 support on PE routers just
	to support a v4 access router, right?
	
	Not sure how feasible this would be, but L2 tunneling seems to be an
	already widely deployed solution in this space.

��Z�g�N��{^��(~�b�隊V�v+lj�Zr���"}��j���w�u�퉩Z�ٚɷ���^rםo)Z���{-j|���������n��ʋ�j��yǢ��m�+���o)��֤z��j��y�(��zX���ajܨ��ޞ�m�觵��y��r*bz{i��zz-������׫o*ަ\����j�(�v���,��^jw]zW�z+_�����ܢjn�����^�)�yؚ��r��y��z�ʋ�����^�{^�ם��"�'��*.��-��\����+��������!�����b��h��ay�'������*-���z�(�hb����ޙ�^z����ߢ�m�G������p��/���~����Z����)�{"n)b�'譩�r���׫�*�br��[z�ڞ�ޮ��o,ʇ�+���