RE: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt
"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> Mon, 28 November 2005 08:30 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeP0-0008NB-7A; Mon, 28 Nov 2005 03:30:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeOw-0008My-Nm for nemo@megatron.ietf.org; Mon, 28 Nov 2005 03:30:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29254 for <nemo@ietf.org>; Mon, 28 Nov 2005 03:29:34 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egeim-0003hr-DZ for nemo@ietf.org; Mon, 28 Nov 2005 03:50:49 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Nov 2005 09:30:10 +0100
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAS8TxAX004152; Mon, 28 Nov 2005 09:30:05 +0100 (MET)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Nov 2005 09:30:02 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt
Date: Mon, 28 Nov 2005 09:29:59 +0100
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01859B56@xmb-ams-337.emea.cisco.com>
Thread-Topic: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt
Thread-Index: AcXz7RNAtmK5RSpfTJG4WubEAJYODQACB0gg
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Chan-Wah Ng <chanwah.ng@sg.panasonic.com>, Alexandru Petrescu <alexandru.petrescu@motorola.com>
X-OriginalArrivalTime: 28 Nov 2005 08:30:02.0810 (UTC) FILETIME=[ED8FF9A0:01C5F3F5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
Content-Transfer-Encoding: quoted-printable
Cc: nemo@ietf.org, Thierry Ernst <ernst@sfc.wide.ad.jp>
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org
The way I see it, it is a problem with the 'mobile home' model, and the HNM draft illustrates applications of NEMO. RO-PS lists all the problems with NEMO, that's its job. So I think the discussion is fine in RO-PS. On the side, I agree it's a bit stupid, is that it is late for Home Network model. It has passed through many reviews and is ready for IESG at this point. Finally, we want the largest audience so people can react more effectively. IMHO, there are more readers to RO-PS then HNM. So I'd go for RO-PS, but I'm ready for other opinions. Pascal >-----Original Message----- >From: Chan-Wah Ng [mailto:chanwah.ng@sg.panasonic.com] >Sent: Monday, November 28, 2005 8:32 AM >To: Alexandru Petrescu >Cc: Pascal Thubert (pthubert); Thierry Ernst; nemo@ietf.org >Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt > >Hello, Alex, > >Thank you for the text. I am now considering which is the most >appropriate place to hold the text. Currently, I am inclined to add it >as an appendix to RO-PS draft. > >It could, also be added to the home network model draft as an appendix >as well. > >Pascal, what do you think? > >/rgds >/cwng > >On Fri, 2005-11-25 at 14:17 +0100, Alexandru Petrescu wrote: >> Chan-Wah Ng wrote: >> > Hello Thierry, >> [...] >> >> o Avoid the Instability and Stalemate >> >> >> >> [1] described a potential stalemate situation when a Home Agent is >> >> nested within a Mobile Network. Route Optimization may circumvent >> >> such stalemate situations by directly forwarding traffic upstream. >> >> However, it should be noted that certain Route Optimization >> >> schemes may require signaling packets to be first routed via the >> >> Home Agent before an optimized route can be established. In such >> >> cases, a Route Optimization solution cannot avoid the stalemate. >> >> >> >> I'm not sure the paragraph above is clear enough. >> > >> > [1] is listed as "Normative". After reading [1] and if you still >> > feel its not clear enough, I am open to suggestions on how to improve >> > it :) >> >> About the "stalemate" problem. [1] is the ro problem statement draft, >> which in turn cites the home network models draft which cites back >> the ro problem statement draft. >> >> For example, the home network models draft says: >> > But note that SFO should never attach to one of its own Cabs. This >> > would create a stalemate situation, as documented in the NEMO RO >> > problem statement [11]. >> >> ... which leaves one wonder what exactly is the "stalemate" situation. >> So one goes to the ro ps draft and reads: >> > Several configurations for the Home Network are described in [9] >> > [home net models]. In particular, there is a mobile home scenario >> > where a (parent) Mobile Router is also a Home Agent for its mobile >> > network. In other words, the mobile network is itself an aggregation >> > of Mobile Network Prefixes assigned to (children) Mobile Routers. >> > >> > A stalemate situation exists in the case where the parent Mobile >> > Router visits one of its children. The child Mobile Router cannot >> > find its Home Agent in the Internet and thus cannot establish its >> > MRHA tunnel and forward the visitors traffic. The traffic from the >> > parent is thus blocked from reaching the Internet and it will never >> > bind to its own (grand parent) Home Agent. >> >> This last paragraph in the ro ps draft is the essence of the "stalemate" >> problem. If that paragraph is not enough for clear explanation, here's >> more detailed text about how the "stalemate" situation may occur >> (substitute "stalemate" for "cross-over tunnels": >> >> Two MR-HA tunnels are "crossing over" each other when the path >> between one tunnel's endpoints includes only one of the other >> tunnel's endpoints. >> >> Support of nested mobile networks is possible only when the path >> from MR2 to MR1's HA does not go through MR1 (path considered when >> both mobile routers are at home and no tunnels are in place). >> >> Consider a mobility configuration depicted below. MR1 is served by >> HA1/BR and MR2 is served by HA2. Both MR1 and MR2 are at home in >> the initial step. HA2 is placed inside the first mobile network, >> thus representing a "mobile" Home Agent. >> >> /-----CN >> ----------/ >> home link1 ------- | | >> -----------------------| HA1/BR|---| Internet | >> | ------- | | >> | ---------- >> ----- ----- >> | MR1 | | HA2 | >> ----- ----- >> | | >> -------------mobile network 1 / home link2 >> | >> ----- ----- >> | MR2 | | LFN | >> ----- ----- >> | | >> ------------mobile network 2 >> >> In the picture above, communication between CN and LFN follows a >> direct path as lons as both MR1 and MR2 are positioned at home. No >> encapsulation intervenes. >> >> In the next step, consider that the MR2's mobile network leaves home >> and visits a foreign network, under Access Router (AR) like in the >> figure below: >> >> /-----CN >> ----------/ >> home link 1 ------- | | >> ---------------| HA1/BR|---| Internet | >> | ------- | | >> ----- ----- ----------\ >> | MR1 | | HA2 | \ >> ----- ----- ----- >> | | | AR | >> ------------mobile net 1 ----- >> home link2 | >> ----- ----- >> | MR2 | | LFN | >> ----- ----- >> | | >> mobile net 2------------ >> >> Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs >> between MR2 and HA2. MR2 sends BU to HA2 and HA2 replies BAck to >> MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. >> After the tunnel MR2HA2 has been set up, the path taken by a packet >> from CN towards LFN can be summarized as: >> CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. Non-encapsulated packets >> are marked "->" while encapsulated packets are marked "=>". >> >> Consider next the attachment of the first mobile network under the >> second mobile network, like in the figure below: >> >> /-----CN >> ----------/ >> ------- | | >> | HA1/BR|---| Internet | >> ------- | | >> ----------\ >> \ >> ----- >> | AR | >> ----- >> | >> ----- ----- >> | MR2 | | LFN | >> ----- ----- >> | | >> mobile net 2------------ >> | >> ----- ----- >> | MR1 | | HA2 | >> ----- ----- >> | | >> mobile net 1------------ >> >> After this movement, MR1 acquires a CoA valid in the second mobile >> network. Subsequently, it sends a BU message addressed to HA1. >> This BU is encapsulated by MR2 and sent towards HA2, which is >> expected to be placed in mobile net 1 and expected to be at home. >> Once HA1/BR receives this encapsulated BU, it tries to deliver to >> MR1. Since MR1 is not at home, and a tunnel has not yet been set up >> between MR1 and HA1, HA1 is not able to route this packet and drops >> it. Thus, the tunnel establishment procedure between MR1 and HA1 is >> not possible, due to the fact that the tunnel between MR2 and HA2 >> has been previously torn down (when the mobile net 1 has moved from >> home). The communication between CN and LFN stops, even though both >> mobile networks are connected to the Internet. >> >> If both tunnels between MR1 and HA1, and between MR2 and HA2 >> were up simultaneously, they would have "crossed over" each other. >> If the tunnels MR1-HA1 and MR2-HA2 were drawn in the above picture, >> it could be noticed that the path of the tunnel MR1-HA1 includes >> only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two >> MR-HA tunnels are crossing over each other if the IP path between >> two endpoints of one tunnel includes one and only one endpoint of >> the other tunnel (assuming that both tunnels are up). When both >> endpoints of one tunnel are included in the path of the other >> tunnel, then tunnels are simply encapsulating each other. >> >> Alex >>
- [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analys… Internet-Drafts
- [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-an… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Alexandru Petrescu
- [nemo] Next steps in RO - was :draft-ietf-nemo-ro… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Carlos Jesús Bernardos Cano
- [nemo] Next steps in RO T.J. Kniveton
- Re: [nemo] Next steps in RO Chan-Wah NG
- Re: [nemo] Next steps in RO Carlos Jesús Bernardos Cano
- Re: [nemo] Next steps in RO T.J. Kniveton
- Re: [nemo] Next steps in RO Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst
- [nemo] Published work for RO solutions referenced… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Alexandru Petrescu
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- RE: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Pascal Thubert (pthubert)
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst