Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming

[Alberto García <[e-mail]>]

Hi,
The requirements you state remind me the Proxy Shim6 proposal
(http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is also a
paper on the subject at
http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf
The abstract of the paper says:
"The P-SHIM6 architecture provides ISP independence to IPv6 sites without
compromising scalability. This architecture is based on a middle-box, the
P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the nodes of
a site, which are configured  with provider independent addresses. Incoming
and outgoing packets are processed by the P-SHIM6 box, which can assign
different locators to a given communication, either when it is started, or
dynamically after the communication has been established. As a consequence,
changes required for provider portability are minimized, and fine-grained
Traffic Engineering can be enforced at the P-SHIM6 box, in addition to the
fault tolerance support provided by SHIM6."

Regards,
Alberto

|  -----Mensaje original-----
|  De: [e-mail] [mailto:[e-mail]] En
|  nombre de Rémi Després
|  Enviado el: miércoles, 12 de enero de 2011 11:19
|  Para: Brian E Carpenter
|  CC: Internet Area
|  Asunto: [Int-area] e2e Address transparency - PI site routing - Multi-CPE
|  multihoming
|  
|  Brian,
|  
|  Here is a good opportunity to clarify an important point, on which I hope
we
|  can converge.
|  
|  The problem I worked on is how to combine:
|  - "e2e address transparency" (hosts know their own global addresses, and
|  use them)
|  - "PI site routing"  (e.g., in IPv6, ULA-only intra-site routing to avoid
|  renumbering problems)
|  - "Multi-CPE Multihoming" (the most complete multihoming model).
|  - "Per-site incremental deployment" (a site can use the solution
|  independently from what is done anywhere else).
|  
|  - LISP is off-scope because it doesn't permit per-site incremental
|  deployment.
|  
|  This problem has two complementary sub-problems:
|  . "Source-address selection" (how does a host select a particular e2e
source
|  address for an outgoing packet)?
|  . "Outgoing-CPE control" (the source address being selected, how to
ensure
|  that the packet goes via the right CPE)?
|  - Solutions for "source-address selection" do exist (SHIM6, SCTP,
draft-ietf-
|  v6ops-multihoming-without-nat66).
|  - AFAIK, a solution for "outgoing-CPE control" in the above context still
has
|  to be specified
|  
|  The key I briefly described for this "outgoing-CPE selection", in sec 3.3
of
|  draft-despres-softwire-sam-01), is that:
|  - For customer-site traversal, hosts encapsulate e2e packets in local
packets
|  (IPv6/IPv6).
|  - Hosts address these local packets to the right CPE's by using a
|  correspondence list between local CPE addresses and global IPv6 prefixes.
|  
|  Unless this is proved to be useless, I plan to pursue in this direction,
with
|  whoever is interested in making positive contributions.
|  
|  Best regards,
|  RD
|  
|  
|  
|  Le 11 janv. 2011 à 21:30, Brian E Carpenter a écrit :
|  >> ... it should be more useful to look for solutions that combine
provider
|  independence with address transparency, than accepting without effort to
|  sacrifice address transparency for provider independence.
|  >
|  > Indeed; we already have one of those standardised, which also has the
|  > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC
5535.
|  
|  (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about securing
|  multihoming address sets. None of these addresses the "outgoing-CPE
|  control" issue).
|  
|  
|  _______________________________________________
|  Int-area mailing list
|  [e-mail]
|  https://www.ietf.org/mailman/listinfo/int-area