Re: [Softwires] Topology of the home network in draft-tsou-softwire-gwinit-6rd-01

[Tina TSOU <[e-mail]>]

For broadband services in Metro Networks, MPLS or BGP tunnel will  
cause too much cost. So they are not widely used for broadband services.
But ISPs may provide MPLS or BGP tunnel for enterprise users.


B. R.
Tina
http://tinatsou.weebly.com


On Nov 8, 2010, at 6:53 PM, Ole Troan wrote:

> Tina,
>
>>>> Consider an operator facing a high subscriber growth rate.  As a
>>>>  result of this growth rate, the operator faces pressure on its  
>>>> stock
>>>>  of available public IPv4 addresses.  For this reason, the  
>>>> operator is
>>>>  motivated to offer IPv6 access as quickly as possible.
>>>>
>>>>  The backbone network will be the first part of the operator's  
>>>> network
>>>>  to support IPv6.  The metro network is not so easily upgraded to
>>>>  support IPv6 since many devices need to be modified and there  
>>>> may be
>>>>  some impact to existing services.  Thus any means of providing  
>>>> IPv6
>>>>  access has to minimize the changes required to devices in the  
>>>> metro
>>>>  network.
>>>
>>> what is it that makes existing softwires mesh solutions unsuitable  
>>> for crossing the IPv4 only metro network? I'm thinking  
>>> specifically on 6PE or BGP tunnels.
>> Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are  
>> more appropriately used in core network. There are fewer uses of  
>> MPLS in metro network. BGP tunnels are also more appropriate for  
>> core network.
>>
>> Essentially the authors are talking about a situation where 6rd is  
>> an applicable technology, but needs modification to meet the  
>> constraints of maximized savings of IPv4 addresses and no provider  
>> access to customer site equipment. The IPv4 address savings occur  
>> only if the customer site is IPv6-only, but the proposal still  
>> works for dual-stack customer sites. The technical solution is to  
>> move the IPv6 in IPv4 tunnel endpoint to the provider edge rather  
>> than have it in equipment on the customer site, and use the  
>> provider gateway IPv4 address in the IPv6 prefix given to the  
>> customer site. As Ralph pointed out, the protocol in RFC 5969  
>> should be able to be applied without change.
>>
>> The authors will restructure the draft to illustrate this latter  
>> point. As Ralph suggested, it will be submitted with the intention  
>> of becoming an Informational describing an alternative deployment  
>> of 6rd to meet the constraints we described above. I hope this plan  
>> meets with the chairs' approval.
>
> 1) is BGP tunneling not applicable because these devices don't  
> support BGP? or not support MPLS?
> 2) my concern with using 6rd for this purpose is that while  
> automatic tunneling by encoding the tunnel end point in the payload  
> address is convenient. offering a 'sensible' sized IPv6 prefix to  
> end users is going to be problematic. note this is purely a concern  
> from a deployment perspective. I have no doubt that you can _use_  
> 6rd this way. just because we _can_, _should_ we?
> can you give some examples of how you deliver e.g. /56 or /64 to end  
> users, using gi-6rd? (without expecting the SP to have a /16 of v6  
> space obviously).
>
> cheers,
> Ole
>