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

[Maglione Roberta <[e-mail]>]

Hi Tina,

>>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.

This claim sounds quite strange to me: many SPs already use IP/MPLS in aggregation network segment and there are a lot of discussions both in IETF and BBF and interest from different SPs about extending the use of IP/MPLS to access segment in order to have a single technology end-to-end  (access, aggregation and core) for all services.

Best regards,
Roberta
________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tina TSOU
Sent: lunedì 8 novembre 2010 11.47
To: Ole Troan
Cc: [e-mail]
Subject: Re: [Softwires] Topology of the home network in draft-tsou-softwire-gwinit-6rd-01


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




On Nov 8, 2010, at 2:39 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.

cheers,
Ole




  In contrast to the situation described for basic 6rd [
RFC5569
], the
  operator is assumed to be unable to manage IP devices on the customer
  premises.  As a result, the operator cannot assume that any of these
  devices are capable of supporting 6rd.


If the customer equipment is in bridged mode and IPv6 is deployed to
  sites via a Service Provider's (SP's) IPv4 network, the IPv6-only
  host needs a IPv6 address to visit the IPv6 service.  In this
  scenario, 6to4 or 6RD can be used.  However, each IPv6-only host may
  need one corresponding IPv4 address when using 6to4 or 6RD, which
  brings great address pressure to the operators.


If the customer equipment is in routing mode
, the operator has an
  opportunity to avoid assigning IPv4 addresses to sites running IPv6
  only.  Some other means is available for routing IPv6 traffic through
  the IPv4 network to that site.


This draft talks about "Some other means".

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



_______________________________________________
Softwires mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/softwires


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:[e-mail]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.