Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming
Rémi Després <remi.despres@free.fr> Wed, 12 January 2011 16:18 UTC
Return-Path: <remi.despres@free.fr>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A15228C131 for <int-area@core3.amsl.com>; Wed, 12 Jan 2011 08:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.429
X-Spam-Level:
X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ5eJX8IwEYY for <int-area@core3.amsl.com>; Wed, 12 Jan 2011 08:18:24 -0800 (PST)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 5CC213A6A4B for <int-area@ietf.org>; Wed, 12 Jan 2011 08:18:24 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 86A6A7000497; Wed, 12 Jan 2011 17:20:43 +0100 (CET)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 339317000480; Wed, 12 Jan 2011 17:20:43 +0100 (CET)
X-SFR-UUID: 20110112162043211.339317000480@msfrf2419.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es>
Date: Wed, 12 Jan 2011 17:20:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <48F6E98D-0626-4498-8C62-9E51FA1FA637@free.fr>
References: <4D2B3928.8050508@gont.com.ar> <20110111071329.109df03f@opy.nosense.org> <4D2B711F.9000705@gont.com.ar> <20110110.224735.41641090.sthaug@nethelp.no> <A01D82C4-9800-4C9B-94D5-24E5D6C1D6FB@free.fr> <4D2CBDFE.30902@gmail.com> <2342BA4A-F973-46AF-82C8-4E1C20CA8692@free.fr> <00b301cbb246$cda664c0$68f32e40$@it.uc3m.es>
To: Alberto García <alberto@it.uc3m.es>
X-Mailer: Apple Mail (2.1082)
Cc: 'Internet Area' <int-area@ietf.org>
Subject: Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jan 2011 16:18:26 -0000
Alberto, Thank you for this interesting reference I hadn't noticed. It did share the objective of combining of "PI site routing" with "Multi-CPE multihoming", but was NOT concerned with "e2e address transparency". Besides: - It needed a middle-box between all hosts and CPE's - It needed a new DNS RR type. Both have to be avoided in the solution I look for. Kind regards, RD Le 12 janv. 2011 à 11:52, Alberto García a écrit : > 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: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] 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 > | Int-area@ietf.org > | https://www.ietf.org/mailman/listinfo/int-area >
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Rémi Després
- Re: [Int-area] IP-capable nodes must support IPv6… George, Wes E [NTK]
- [Int-area] IP-capable nodes must support IPv6 - n… George, Wes E [NTK]
- Re: [Int-area] IP-capable nodes must support IPv6… Ed Jankiewicz
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Fred Baker
- Re: [Int-area] IP-capable nodes must support IPv6… Fred Baker
- Re: [Int-area] [v6ops] End-to-end "address transp… Rémi Després
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Matthew Kaufman
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Matthew Kaufman
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Brian E Carpenter
- Re: [Int-area] IP-capable nodes must support IPv6… Josh Rambo
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Josh Rambo
- Re: [Int-area] IP-capable nodes must support IPv6… Rajiv Asati (rajiva)
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Joe Touch
- Re: [Int-area] IP-capable nodes must support IPv6… Rajiv Asati (rajiva)
- Re: [Int-area] IP-capable nodes must support IPv6… Brian E Carpenter
- Re: [Int-area] IP-capable nodes must support IPv6… Fernando Gont
- Re: [Int-area] IP-capable nodes must support IPv6… Ed Jankiewicz
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Randy Bush
- Re: [Int-area] IP-capable nodes must support IPv6… Lee Howard
- Re: [Int-area] IP-capable nodes must support IPv6… Fernando Gont
- Re: [Int-area] IP-capable nodes must support IPv6… Joel Jaeggli
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Mark Smith
- [Int-area] End-to-end "address transparency" Rémi Després
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Gunter Van de Velde (gvandeve)
- Re: [Int-area] [v6ops] End-to-end "address transp… Rémi Després
- Re: [Int-area] [v6ops] IP-capable nodes must supp… George, Wes E [NTK]
- Re: [Int-area] IP-capable nodes must support IPv6… George, Wes E [NTK]
- [Int-area] draft-george-ipv6-required George, Wes E [NTK]
- Re: [Int-area] End-to-end "address transparency" Fernando Gont
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Joe Touch
- Re: [Int-area] End-to-end "address transparency" Behcet Sarikaya
- Re: [Int-area] draft-george-ipv6-required Ed Jankiewicz
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Rajiv Asati (rajiva)
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Lee Howard
- Re: [Int-area] [v6ops] IP-capable nodes must supp… George, Wes E [NTK]
- Re: [Int-area] IP-capable nodes must support IPv6… Rajiv Asati (rajiva)
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Joe Touch
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Lee Howard
- Re: [Int-area] [v6ops] End-to-end "address transp… Fernando Gont
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Mark Smith
- Re: [Int-area] End-to-end "address transparency" Brian E Carpenter
- Re: [Int-area] [v6ops] End-to-end "address transp… sthaug
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Noel Chiappa
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Mark Smith
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Joe Touch
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Lee Howard
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Joe Touch
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Brian E Carpenter
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Fred Baker
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Mark Smith
- Re: [Int-area] End-to-end "address transparency" Rémi Després
- Re: [Int-area] [v6ops] End-to-end "address transp… Brian E Carpenter
- [Int-area] e2e Address transparency - PI site rou… Rémi Després
- Re: [Int-area] e2e Address transparency - PI site… Alberto García
- Re: [Int-area] e2e Address transparency - PI site… Rémi Després
- Re: [Int-area] e2e Address transparency - PI site… Brian E Carpenter
- Re: [Int-area] e2e Address transparency - PI site… Rémi Després
- Re: [Int-area] e2e Address transparency - PI site… Eliot Lear
- Re: [Int-area] e2e Address transparency - PI site… Rémi Després
- Re: [Int-area] e2e Address transparency - PI site… Templin, Fred L
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Howard, Lee
- Re: [Int-area] [v6ops] IP-capable nodes must supp… Cameron Byrne
- Re: [Int-area] e2e Address transparency - PI site… Brian E Carpenter
- Re: [Int-area] draft-george-ipv6-required Joel Jaeggli
- Re: [Int-area] [v6ops] End-to-end "address transp… Joel Jaeggli
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith
- Re: [Int-area] [v6ops] End-to-end "address transp… Rémi Després
- Re: [Int-area] [v6ops] End-to-end "address transp… Jack Bates
- Re: [Int-area] [v6ops] End-to-end "address transp… Jack Bates
- Re: [Int-area] [v6ops] End-to-end "address transp… Rémi Després
- Re: [Int-area] [v6ops] End-to-end "address transp… Fred Baker
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith
- Re: [Int-area] [v6ops] End-to-end "address transp… Rémi Després
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith
- Re: [Int-area] [v6ops] End-to-end "address transp… Jack Bates
- Re: [Int-area] [v6ops] End-to-end "address transp… Fred Baker
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith
- Re: [Int-area] [v6ops] End-to-end "address transp… Jack Bates
- Re: [Int-area] [v6ops] End-to-end "address transp… Erik Kline
- Re: [Int-area] [v6ops] End-to-end "address transp… Fred Baker
- Re: [Int-area] [v6ops] End-to-end "address transp… Erik Kline
- Re: [Int-area] [v6ops] End-to-end "address transp… Fred Baker
- Re: [Int-area] [v6ops] End-to-end "address transp… Joel Jaeggli
- Re: [Int-area] [v6ops] End-to-end "address transp… Rémi Després
- Re: [Int-area] [v6ops] End-to-end "address transp… Jack Bates
- Re: [Int-area] [v6ops] End-to-end "address transp… Mark Smith