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: [email protected] [mailto:[email protected]] On Behalf Of Tina TSOU Sent: lunedì 8 novembre 2010 11.47 To: Ole Troan Cc: [email protected] 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 [email protected]<mailto:[email protected]> 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:[email protected]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.
<<inline: logo Ambiente_foglia.jpg>>
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
