From nemo-bounces@ietf.org Wed May 02 23:59:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjSTe-0002LC-Qb; Wed, 02 May 2007 23:59:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjSTc-0002L7-UK for nemo@ietf.org; Wed, 02 May 2007 23:59:32 -0400 Received: from criges14.insa-lyon.fr ([134.214.76.242] helo=smtp.insa-lyon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjSTc-00036S-HB for nemo@ietf.org; Wed, 02 May 2007 23:59:32 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 8C9D9F3145 for ; Thu, 3 May 2007 05:59:28 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2YF7I9slObX for ; Thu, 3 May 2007 05:59:27 +0200 (CEST) Received: from [134.214.215.58] (unknown [134.214.215.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvalois) by smtp.insa-lyon.fr (Postfix) with ESMTP id 4C96EF3144 for ; Thu, 3 May 2007 05:59:27 +0200 (CEST) Message-ID: <46395E22.6060807@insa-lyon.fr> Date: Wed, 02 May 2007 23:59:30 -0400 From: Fabrice Valois User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [nemo] WiMob'07: Special Session on Mobility Models X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org CFP for IEEE WiMOB=922007 special session on Mobility Models for Mobile Ad hoc Networks, Mesh networks, Wireless networks and NEMO networks The session is a part of the 3rd IEEE International Conference on Wireless and Mobile Computing, Networking and Communications =93WiMob 2007=94 http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne Plaza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Because WiMob'07 conference is focused on wireless networks and because the performances of wireless networks are strongly linked to the mobility models used, we propose a special session focusing only on mobility models. This session is focused on these kind of wireless networks: - MANET: Mobile ad hoc networks where whole the topology is dynamic - Mesh networks and classical wireless networks offering an infrastructure topologies allowing fixed and mobile Internet for the end user. - Network Mobile (NEMO) networks offering new kind of dynamic topology where not only the user is mobile but also the network These kind of networks should deal with mobility: user mobility, group mobility, etc. But, what is really mobility? how mobility influences the performances? how to define new mobility models? etc. Scope of the Contributions for Mobility Models in the case of MANET, Mesh Networks, Wireless Networks and NEMO networks (include but are not limited to the following): - Performance evaluation of mobility models - New mobility models to mimic particular behavior - Theoretical aspects of mobility models - Theoretical frameworks for mobility - Mobility models based on realistic traces - Mobility management - Networking protocols and mobility models - Tools for mobility models (generators, integrators to simulators, ..) - etc. Authors are invited to submit a complete technical paper of their original work. Maximum length for submissions is 8 double column pages in IEEE format. The preferred submission format is PDF. Session Chair: Fabrice Valois, INSA Lyon, France Session Co-chair: Thomas Noel, University of Strasbourg, France Submissions should be sent attached by email to the session chairs at: fabrice.valois@insa-lyon.fr Thomas.Noel@dpt-info.u-strasbg.fr Important Dates : Manuscript Submission Due: May 25, 2007 Acceptance Notification: June 8, 2007 Final Manuscript Due: June 15, 2007 --=20 Fabrice Valois, Associate Professor INRIA ARES / CITI - INSA Lyon, Telecommunications Dpt. Web: http://fvalois.insa-lyon.fr/ Tel: +33 472 436 418 From jaak@wwdb.org Sun May 06 03:40:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkbM7-0000mB-UI for nemo-archive@lists.ietf.org; Sun, 06 May 2007 03:40:31 -0400 Received: from [64.80.119.38] (helo=aqqj) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkbM7-0004aW-KQ for nemo-archive@lists.ietf.org; Sun, 06 May 2007 03:40:31 -0400 Received: from ajski ([49.208.34.227]) by aqqj with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 02:57:58 -0400 Message-ID: <002701c78fab$e1168ec0$e322d031@ajski> From: "Booker Minna" To: Subject: If not, then use your phone book, look up "recycling" and call them, asking who they recommend for recycling old PCs. Date: Sun, 6 May 2007 02:57:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 The cream of the crop for 2007 - GET IN EARLY! DSDI IS SET TO ROCK YOUR PORTFOLIO! DSI Direct Sales, Inc. Symbol: DSDI Price: $0.04 There is a MASSIVE PROMOTION underway this weekend! This is hot, read the news and get on DSDI first thing Monday! (I have a nice Antec case, unused. IR keyboards should be compatible with whatever Palm (or Microsoft) throws at us in the future - I do not agree that IR is going away any time soon for PDAs, especially Palm OS. The Cisco IP Communicator, a software-based application that delivers enhanced telephony support through the PC, enables the staff to receive and place calls from a laptop, even from a hotel room. or is it just not worth the decrease in performance? com Worthwhile Sites WindowsNetworking. Net y, sobre todo, un rendimiento muy muy potente. Cisco Gold Certified Partner ISC, Inc. We have clients (as I'm sure many others do too) who still use faxes to transmit documents. For such a large company, Cisco is a very joined-up organisation - including its business partners. , "True has continuously developed innovative services as well as network technologies to meet business clients' needs. True is proud to have three of our managed services qualified under the Cisco Powered Program. ISC is a Cisco Gold Certified Partner that has earned many Cisco technology specializations, and has focused its business on the technology needs of several vertical markets, including healthcare. Screwing the fan to the adapter is practically impossible when the adapter is installed, so the fan is attached with Zip ties. ) You can view it online as well. I don't have my copy yet. The Cisco Medical Grade Network consists of Cisco 6509 with Supervisor Engine 720BXLs in the core at the main closet. Both have a nice, low-speed 80mm fan that moves a good amount of air quietly, and I can assure you that even after moving 100 GB of data through it, drives remain only slightly warm. Due to popular demand, I've put more details about this elsewhere on my site. Modern P4's varry between 120 watts (idling) and 180 (running hard). Due to heat build up in the power supply (which was getting a little too warm, I think), I added an 80mm case fan and a 60mm-to-80mm fan adapter to the back of my Soltek Qbic 3401. com PracticeXchange. From nemo-bounces@ietf.org Sun May 06 10:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hki3c-0007XF-N6; Sun, 06 May 2007 10:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hki3a-0007WL-R5; Sun, 06 May 2007 10:49:50 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hki3Z-00074C-EN; Sun, 06 May 2007 10:49:50 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l46EotQS017156; Sun, 6 May 2007 09:50:55 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 09:49:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 6 May 2007 10:47:10 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542DF8@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mipshop] Multicast Mobility mailing list Thread-Index: AceFcvIMCPI2dJgsQFK5TTi0G+B0qwAVRh+xAolYmEA= References: From: "Suresh Krishnan \(QB/EMC\)" To: "Rajeev Koodli" , , , , , , X-OriginalArrivalTime: 06 May 2007 14:49:48.0656 (UTC) FILETIME=[CB712700:01C78FED] X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [nemo] RE: [Mipshop] Multicast Mobility mailing list X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Rajeev, Sorry for the late reply. I am on vacation and checking mail very = irregularly. Thanks for the offer to take up the problem work in = mobopts. I was not sure whether the solution space falls within the = purview of mobopts. =20 Thanks Suresh ________________________________ From: Rajeev Koodli [mailto:rajeev.koodli@nokia.com] Sent: Mon 23/04/2007 12:54 PM To: Suresh Krishnan (QB/EMC); mipshop@ietf.org; nemo@ietf.org; = monami6@ietf.org; mobopts@ietf.org; mip4@ietf.org; netlmm@ietf.org Subject: Re: [Mipshop] Multicast Mobility mailing list Hi Suresh, Good to see interest on this topic. As you may be aware, MobOpts has been looking into this topic for a = while now. draft-schmidt-mobopts-mmcastv6-ps-02.txt is a good document illustrating the problems and existing approaches to solving them, with about 50 references. This is adopted as the RG document. I think we will have interesting work to do starting with the problem description (with possibly more than one work item). It would be good to have the interests channeled together for maximum benefit. MobOpts has also been successful in handing over relatively mature = topics to IETF WGs when it makes sense. This is also something we can investigate = on this topic. Regards, -Rajeev On 4/22/07 11:45 PM, "ext Suresh Krishnan (QB/EMC)" wrote: > Hi Folks, >=20 > We wanted to inform you that we have created a new mailing list in = order > to discuss the interactions occuring between mobility and multicast. = We > invite anyone interested in contributing to the work to subscribe and > collaborate. To register visit the list page at: >=20 > https://www1.ietf.org/mailman/listinfo/multimob >=20 > Several of you have expressed interest in this work and some documents > already exist without a home working group. >=20 > The primary problem that we foresee being discussed in the mailing = list > is issues with Multicast listener (receiver) mobility for multicast > routing. There are several other associated problems like sender > mobility, which can also be discussed. >=20 > Thanks > Suresh and Behcet > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop From nemo-bounces@ietf.org Mon May 07 15:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9Gb-0006u3-D4; Mon, 07 May 2007 15:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9Ga-0006ty-2L for nemo@ietf.org; Mon, 07 May 2007 15:53:04 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl9GX-0004wg-Ll for nemo@ietf.org; Mon, 07 May 2007 15:53:04 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l47JqqYF014961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 May 2007 12:53:01 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l47Jqq2T029841; Mon, 7 May 2007 12:52:52 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l47JqpLC029767; Mon, 7 May 2007 12:52:52 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 12:52:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C790E1.4B8A5842" Date: Mon, 7 May 2007 12:52:51 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A036854B3@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Beyond State of the Art contributions merge v2.doc thread-index: AcePFX83v5aWR9ShS1+LKI0PAofSdgAIQiuAAAtTOCAAVMuAUA== From: "Davis, Terry L" To: "Mobile Platform Internet Mailing List" X-OriginalArrivalTime: 07 May 2007 19:52:51.0772 (UTC) FILETIME=[4BD637C0:01C790E1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: nemo@ietf.org Subject: [nemo] FW: Beyond State of the Art contributions merge v2.doc X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C790E1.4B8A5842 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All =20 You may find this link to be interesting reading as it relates to our aircraft mobility and link state problem on handoff. =20 http://www.ist-gollum.org/, they are trying to produce a universal link layer (ULLA). Take care=20 Terry=20 ------_=_NextPart_001_01C790E1.4B8A5842 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All

 

You may find this link to be = interesting reading as it relates to our aircraft mobility and link state problem on handoff.

 

 http://www.ist-gollum.org/, they = are trying to produce a universal link layer = (ULLA).

Take care
Terry

------_=_NextPart_001_01C790E1.4B8A5842-- From nemo-bounces@ietf.org Mon May 07 17:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAZQ-0006Wb-EL; Mon, 07 May 2007 17:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAZQ-0006WW-03 for nemo@ietf.org; Mon, 07 May 2007 17:16:36 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlAZN-0000sS-LV for nemo@ietf.org; Mon, 07 May 2007 17:16:35 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l47LGSJ1016605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 May 2007 16:16:33 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l47LGS3v028325; Mon, 7 May 2007 14:16:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l47LGJdX028038; Mon, 7 May 2007 14:16:20 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 14:16:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C790EC.F4863896" Date: Mon, 7 May 2007 14:16:19 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A036854BC@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Beyond State of the Art contributions merge v2.doc thread-index: AcePFX83v5aWR9ShS1+LKI0PAofSdgAIQiuAAAtTOCAAVMuAUA== From: "Davis, Terry L" To: "Mobile Platform Internet Mailing List" X-OriginalArrivalTime: 07 May 2007 21:16:19.0695 (UTC) FILETIME=[F4CA9FF0:01C790EC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: nemo@ietf.org Subject: [nemo] FW: Beyond State of the Art contributions merge v2.doc X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C790EC.F4863896 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All =20 You may find this link to be interesting reading as it relates to our aircraft mobility and link state problem on handoff. =20 http://www.ist-gollum.org/, they are trying to produce a universal link layer (ULLA). Take care=20 Terry=20 ------_=_NextPart_001_01C790EC.F4863896 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All

 

You may find this link to be = interesting reading as it relates to our aircraft mobility and link state problem on handoff.

 

 http://www.ist-gollum.org/, they are trying to produce a universal link layer = (ULLA).

Take care
Terry

------_=_NextPart_001_01C790EC.F4863896-- From nemo-bounces@ietf.org Tue May 08 18:11:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXtq-0008Sr-FZ; Tue, 08 May 2007 18:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlX3B-0002rH-Gm; Tue, 08 May 2007 17:16:49 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlX39-0002mr-0J; Tue, 08 May 2007 17:16:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l48LGWeV012038; Wed, 9 May 2007 00:16:45 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 00:16:39 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:15:17 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 May 2007 21:15:17 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 08 May 2007 16:16:24 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List , Message-ID: Thread-Topic: DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 May 2007 21:15:17.0890 (UTC) FILETIME=[FA5DAE20:01C791B5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Tue, 08 May 2007 18:11:01 -0400 Cc: Subject: [nemo] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello, The DS-MIP6 I-D still has issue 93 open. This was discussed at IETF68. Vijay presented 4 options to solve the issue. These are captured in: https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf We need to make a decision on this issue and move forward with the I-D. At the meeting itself, I got the sense that option 3 was the one that had the least impact and easy to implement. Please consider this email as a consensus call for issue 93. The problem and choices are as follows (based on Vijay's slides): Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The encapculations are either: - IPv6-in-UDP-over-IPv4 - IPv4-in-UDP-over-IPv4 There is a need (or I guess desirable) to indicate the type of protocol being encapsulated in the UDP header. Choices are: 1. Parse the protocol header following the UDP header 2. Reserve a UDP port for each protocol header (i.e one UDP port for IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a DS-MIP6 "tunnel type message" 4. Encapsulated protocol header type is indicated in the BU message Pros and cons of these choices are in the slides that were presented at IETF68 (see URL above). Please provide your opinions and comments by May 15th, 07 on the MIP6 mailing list. -Raj From nemo-bounces@ietf.org Tue May 08 21:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HladB-00058E-Vm; Tue, 08 May 2007 21:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HladB-00056Y-3q for nemo@ietf.org; Tue, 08 May 2007 21:06:13 -0400 Received: from a2s13.a2hosting.com ([69.39.88.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HladA-00089W-Mp for nemo@ietf.org; Tue, 08 May 2007 21:06:13 -0400 Received: from a2s13.a2hosting.com ([69.39.88.160] helo=[127.0.0.1]) by a2s13.a2hosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Hlad9-0001zK-Vl for nemo@ietf.org; Tue, 08 May 2007 21:06:12 -0400 Message-ID: <46411E7B.20809@acm.org> Date: Tue, 08 May 2007 17:06:03 -0800 From: Ken Laberteaux User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------020901080408000400020106" X-A2hosting-MailScanner-Information: Please contact the ISP for more information X-A2hosting-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-A2hosting-MailScanner-SpamCheck: X-A2hosting-MailScanner-From: klaberte@acm.org X-Spam-Status: No X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2s13.a2hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - acm.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [nemo] Reminder: VANET 2007 Submissions due May 14 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --------------020901080408000400020106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------020901080408000400020106 Content-Type: text/plain; name="VANET-2007-CFP.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="VANET-2007-CFP.txt" ANNOUNCEMENT and CALL FOR PAPERS VANET 2007 The Fourth ACM International Workshop on Vehicular Ad Hoc Networks In conjunction with ACM MobiCom 2007 September 10, 2007 Montréal, QC, Canada Sponsored by ACM SIGMOBILE http://www.sigmobile.org/workshops/vanet2007/ Important Dates: Paper Submission Deadline: May 14, 2007, 11:59 p.m. GMT Notification of Acceptance: June 18, 2007 Camera-Ready Deadline: July 16, 2007 The goal of this workshop is to present and discuss recent advances in the development of wireless vehicular ad hoc networking (VANET) technologies. Based on short- to medium-range communication systems (vehicle-to-vehicle and vehicle-to-roadside), vehicular ad hoc networks will enable vehicular safety applications (including collision and other safety warnings) as well as non-safety applications (like real-time traffic congestion and routing information, high-speed tolling, mobile infotainment, and many others). The creation of high-performance, highly reliable, highly scalable, and secure VANET technologies presents an extraordinary challenge for the wireless research community. A high degree of communication reliability is needed under unfavorable conditions. Clearly, the specificity of vehicular ad hoc networks in terms of mobility behavior and applications scenarios and requirements makes VANET research an exciting and demanding application- and purpose-driven sub-discipline of wireless networking. Following the successes of VANET 2004 held in Philadelphia, VANET 2005 held in Cologne, Germany, and VANET 2006 in Los Angeles, CA, the Fourth ACM International Workshop on Vehicular Ad Hoc Networks (VANET) will be held in Montréal, QC, Canada September 14, 2007, in conjunction with MobiCom 2007. Authors are invited to submit papers presenting new research related to the theory or practice of vehicular ad hoc networks (VANET). All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Areas of interest include, but are not limited to: - Safety and non-safety applications - Roadside-to-vehicle and vehicle-to-vehicle communication - Communication protocol design - Channel modeling - Modulation and coding - Power control and scalability issues - Multi-channel organization and operation - Security issues and countermeasures - Privacy issues - Network management - Simulation frameworks & real-world testbeds VANET present a highly active field of research, development, standardization and field trials. Throughout the world, there are many national/international projects in government, industry, and academia devoted to VANET. These include the consortia like Vehicle Safety Consortium (US), Car-2-Car Communication Consortium (Europe) and Advanced Safety Vehicle Program (Japan), standardization efforts like IEEE 802.11p (WAVE), and field trials like the large-scale Vehicle Infrastructure Integration Program (VII) in the US. Submission Instructions All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 10 pages (single- or double-column), in font no smaller than 11 points, and must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Submitted papers will be judged based on their quality through a double-blind review process, where the identities of the authors are withheld from the reviewers. Detailed instructions for paper submission will be posted on the VANET 2007 web page at: http://www.sigmobile.org/workshops/vanet2007/. General Co-Chairs: Wieland Holfelder, DaimlerChrysler REDNA Paolo Santi, Italian Natl. Research Council Technical Program Co-Chairs: Yih-Chun Hu, University of Illinois at Urbana-Champaign Jean-Pierre Hubaux, EPFL Web Chair: Ken Laberteaux, Toyota Technical Center Technical Program Committee (partial list): Victor Bahl, Microsoft Research Fan Bai, General Motors Levente Buttyan, Budapest University of Technology and Economics Tracy Camp, Colorado School of Mines Eylem Ekici, Ohio State University Tamer ElBatt, San Diego Research Center Andreas Festag, NEC Europe Ltd Hannes Hartenstein, University of Karlsruhe Wieland Holfelder, DaimlerChrysler REDNA Yih-Chun Hu, University of Illinois at Urbana-Champaign Jean-Pierre Hubaux, EPFL Markus Jakobsson, Indiana University Daniel Jiang, DaimlerChrysler REDNA Frank Kargl, Ulm University Timo Kosch, BMW Ken Laberteaux, Toyota Technical Center Martin Mauve, Heinrich Heine University Düsseldorf Christof Paar, Ruhr-University Bochum Panos Papadimitratos, EPFL Adrian Perrig, Carnegie Mellon University Maxim Raya, EPFL Paolo Santi, CNR Rajeev Shorey, General Motors Research Pravin Varaiya, University of California at Berkeley --------------020901080408000400020106-- From nemo-bounces@ietf.org Tue May 08 21:20:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlar7-0000bf-IE; Tue, 08 May 2007 21:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlar6-0000bC-5U; Tue, 08 May 2007 21:20:36 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlar4-0001Wv-R8; Tue, 08 May 2007 21:20:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 May 2007 18:20:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAIaHhA References: From: "Vijay Devarapalli" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, My preference is for option 4. I know many preferred option=20 3, but it adds a 4 byte per-packet overhead for each tunneled data packet. I wish we can avoid that. Vijay=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, May 08, 2007 2:16 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 >=20 > Hello, >=20 > The DS-MIP6 I-D still has > issue 93 open. This was discussed at IETF68. Vijay presented 4 options > to solve the issue. These are captured in: >=20 > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >=20 > We need to make a decision on this issue and move forward with the > I-D. At the meeting itself, I got the sense that option 3 was the one > that had the least impact and easy to implement. >=20 > Please consider this email as a consensus call for issue 93. The > problem and choices are as follows (based on Vijay's slides): >=20 > Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The > encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type of > protocol being encapsulated in the UDP header. >=20 > Choices are: > 1. Parse the protocol header following the UDP header > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message >=20 > Pros and cons of these choices are in the slides that were presented > at IETF68 (see URL above). >=20 > Please provide your opinions and comments by May 15th, 07 on the MIP6 > mailing list. >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Tue May 08 22:03:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlbWi-0002aL-VF; Tue, 08 May 2007 22:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlbWf-0002Zm-Rd; Tue, 08 May 2007 22:03:34 -0400 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlbWb-00022r-Dv; Tue, 08 May 2007 22:03:33 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070509020325.UWIJ7838.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Wed, 9 May 2007 02:03:25 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005>; Wed, 9 May 2007 02:03:25 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Date: Wed, 9 May 2007 12:03:21 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0Sog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Message-Id: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj, At the meeting Sri (the author of the issue) and Kent said they didn't know that a UDP port was already reserved. Once we cleared that, the rationale for the issue was no longer applicable. I believe Sri said he wanted some time to be sure before the issue is rejected. More inline on the options: > Choices are: > 1. Parse the protocol header following the UDP header => This should be "parse the version field after the UDP header". This is what's already in the draft and it works fine today with any UDP encapsulation. > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) => This isn't needed. > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" => This is what the issue suggested but the additional 4 bytes are redundant. > 4. Encapsulated protocol header type is indicated in the BU message => Again, not needed IMO. I think option 1 is the right option. There is no reason given for a change. Hesham From nemo-bounces@ietf.org Tue May 08 22:17:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbjg-0003Gt-8Y; Tue, 08 May 2007 22:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbje-0003GN-9d; Tue, 08 May 2007 22:16:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlbjd-0003z5-UZ; Tue, 08 May 2007 22:16:58 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 19:16:57 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="419987936:sNHT48143176" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l492GvId029797; Tue, 8 May 2007 19:16:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l492GuEi006748; Wed, 9 May 2007 02:16:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 19:16:56 -0700 Received: from sgundavewxp ([10.32.246.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 19:16:55 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , References: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Tue, 8 May 2007 19:16:54 -0700 Message-ID: <019401c791e0$1d58d010$d3f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAABYFIA= X-OriginalArrivalTime: 09 May 2007 02:16:56.0143 (UTC) FILETIME=[1DC3EDF0:01C791E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2242; t=1178677017; x=1179541017; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=uOFG3aw0cGx1awpmdUCQWK8QnurzxdauYj5Q4FjiaqU=; b=OfqinzzDQhw4lEQdiTdwPFP/kMPYlx3038E+hu5qmhtYIyUUo4RPo5FSwDOFNmVXhkCofZ/a kQURJ+fADT3C9QvYvjkPIijQ2V9cfYn7E63s7R7tMawbApXBay0KjxV9P6z+5z+9Yrna3CQ04F XRcVqzafDK/OHwgPPuV91EU64=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham: Sure. I agree that the application can switch based on the IP version field. True. I'm ok either way. You can keep it the way you have it now or use an approach below. But, just one comment. I prefere 3519 style of thin wrapper. Reason: If we need to add Keepalive messages tomorrow, a separate subtype can be defined for the keepalive messages and so we can extend this. Off course, I do realize, you guys wanted to use BU/BA as the keepalive message and that processing in my opinion is bit expensive compared to a simple keepalive message and that too with the option of skipping keepalive message when any data traffic is seen. But, if you think this 4-byte wrapper is a waste for the keepalive extension that never be defined in future, I'm ok. Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Tuesday, May 08, 2007 7:03 PM > To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; nemo@ietf.org > Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 > > Hi Raj, > > At the meeting Sri (the author of the issue) and Kent said > they didn't know > that a UDP port was already reserved. Once we cleared that, > the rationale > for the issue was no longer applicable. I believe Sri said he > wanted some > time to be sure before the issue is rejected. > More inline on the options: > > > > Choices are: > > 1. Parse the protocol header following the UDP header > > => This should be "parse the version field after the UDP > header". This is > what's already in the draft and it works fine today with any UDP > encapsulation. > > > 2. Reserve a UDP port for each protocol header (i.e one > UDP port for > > IPv6-in-UDP-over-IPv4 and another for > IPv4-in-UDP-over-IPv4 etc.) > > => This isn't needed. > > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > => This is what the issue suggested but the additional 4 bytes are > redundant. > > > 4. Encapsulated protocol header type is indicated in the BU message > > => Again, not needed IMO. > > I think option 1 is the right option. There is no reason > given for a change. > > Hesham > > From nemo-bounces@ietf.org Tue May 08 22:27:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbtv-0001nK-Is; Tue, 08 May 2007 22:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbtt-0001mS-Be; Tue, 08 May 2007 22:27:33 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlbts-0005Hh-Sp; Tue, 08 May 2007 22:27:33 -0400 Received: from oaamta08ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070509022725.UMQQ15631.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com>; Wed, 9 May 2007 02:27:25 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070509022724.LMVG26028.oaamta08ps.mx.bigpond.com@PC20005>; Wed, 9 May 2007 02:27:24 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Wed, 9 May 2007 12:27:20 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAABYFIAAAJElMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <019401c791e0$1d58d010$d3f6200a@amer.cisco.com> Message-Id: <20070509022724.LMVG26028.oaamta08ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Sri, > Sure. I agree that the application can switch based > on the IP version field. True. I'm ok either way. You > can keep it the way you have it now or use an approach > below. But, just one comment. > > I prefere 3519 style of thin wrapper. Reason: If we > need to add Keepalive messages tomorrow, a separate > subtype can be defined for the keepalive messages and > so we can extend this. Off course, I do realize, you guys > wanted to use BU/BA as the keepalive message and that > processing in my opinion is bit expensive compared to a > simple keepalive message and that too with the option > of skipping keepalive message when any data traffic > is seen. But, if you think this 4-byte wrapper is a waste > for the keepalive extension that never be defined in > future, I'm ok. => I agree with you on the need for lighter weight keep-alive. I raised an issue a long time ago, and rejected it :), because there wasn't enough interest to justify its addition. However, I don't think it's related to this discussion because if we wanted a keep alive we could simply define a new option in the DO header or just encapsulate a "ping". So I don't see the correlation with this issue as the keepalive can always be sent in a ping using either IPv4 or IPv6 and the same parsing rules would apply. Hesham > > Sri > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Tuesday, May 08, 2007 7:03 PM > > To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; nemo@ietf.org > > Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > > > Hi Raj, > > > > At the meeting Sri (the author of the issue) and Kent said > > they didn't know > > that a UDP port was already reserved. Once we cleared that, > > the rationale > > for the issue was no longer applicable. I believe Sri said he > > wanted some > > time to be sure before the issue is rejected. > > More inline on the options: > > > > > > > Choices are: > > > 1. Parse the protocol header following the UDP header > > > > => This should be "parse the version field after the UDP > > header". This is > > what's already in the draft and it works fine today with any UDP > > encapsulation. > > > > > 2. Reserve a UDP port for each protocol header (i.e one > > UDP port for > > > IPv6-in-UDP-over-IPv4 and another for > > IPv4-in-UDP-over-IPv4 etc.) > > > > => This isn't needed. > > > > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > > > => This is what the issue suggested but the additional 4 bytes are > > redundant. > > > > > 4. Encapsulated protocol header type is indicated in > the BU message > > > > => Again, not needed IMO. > > > > I think option 1 is the right option. There is no reason > > given for a change. > > > > Hesham > > > > > From nemo-bounces@ietf.org Thu May 10 03:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2kF-00079G-VY; Thu, 10 May 2007 03:07:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2kE-00075s-Qz; Thu, 10 May 2007 03:07:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2kE-0000IC-HJ; Thu, 10 May 2007 03:07:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4A77BA16621; Thu, 10 May 2007 07:07:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 May 2007 02:07:09 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711426E083@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAIaHhAAD1bsAA= References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Sri Gundavelli Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, In case that we choose option 4 for the sake of saving the 4 bytes, do not we, at the same time, limit the option of carrying more than one type of traffic for the same session? I believe we can negotiate only one type in BU/BA. Right? If that is the case, would you consider option 3 again since it fits naturally in the IP packet processing without the need to peak into the encapsulated header to identify the traffic type. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Tuesday, May 08, 2007 8:21 PM > To: Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org > Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > Hi, >=20 > My preference is for option 4. I know many preferred option=20 > 3, but it adds a 4 byte per-packet overhead for each tunneled=20 > data packet. I wish we can avoid that. >=20 > Vijay=20 >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Tuesday, May 08, 2007 2:16 PM > > To: Mobile IPv6 Mailing List; nemo@ietf.org > > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > >=20 > >=20 > > Hello, > >=20 > > The DS-MIP6 I-D still has=20 > > issue 93 open. This was discussed at IETF68. Vijay=20 > presented 4 options=20 > > to solve the issue. These are captured in: > >=20 > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >=20 > > We need to make a decision on this issue and move forward with the=20 > > I-D. At the meeting itself, I got the sense that option 3=20 > was the one=20 > > that had the least impact and easy to implement. > >=20 > > Please consider this email as a consensus call for issue 93. The=20 > > problem and choices are as follows (based on Vijay's slides): > >=20 > > Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The=20 > > encapculations are either: > > - IPv6-in-UDP-over-IPv4 > > - IPv4-in-UDP-over-IPv4 > > There is a need (or I guess desirable) to indicate the type of=20 > > protocol being encapsulated in the UDP header. > >=20 > > Choices are: > > 1. Parse the protocol header following the UDP header 2.=20 > Reserve a UDP=20 > > port for each protocol header (i.e one UDP port for > > IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.)=20 > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > 4. Encapsulated protocol header type is indicated in the BU message > >=20 > > Pros and cons of these choices are in the slides that were=20 > presented=20 > > at IETF68 (see URL above). > >=20 > > Please provide your opinions and comments by May 15th, 07=20 > on the MIP6=20 > > mailing list. > >=20 > > -Raj > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Thu May 10 03:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2pK-0001KP-92; Thu, 10 May 2007 03:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2pJ-0001Jw-Bp for nemo@ietf.org; Thu, 10 May 2007 03:12:37 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2pI-0000n4-LC for nemo@ietf.org; Thu, 10 May 2007 03:12:37 -0400 Received: by nz-out-0506.google.com with SMTP id z6so521793nzd for ; Thu, 10 May 2007 00:12:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=sokaLNY1GNX1Mw4upXzkb5hQGvyNM7P44nnFPdzaZjiN9Rs3C8jWvBQx+DHal2EE1jeV4xd4UJPdaeGsprY9EqRavIN8EPLQ2EIwYdjmzM4+gVswHr/zfIX8nqoLJykGRWdt8j+sPBL2WenGwMrVLkMQqaAy6W8i1z3Z/he7BFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=UXmd1GVZlksoFpPV9TF04dATRmet3cGR4XmEA9jOibriYY4eeEo+Qw2artmy3ZUCggfND5xG3wTG3PVkNCw2YqLdZ8Ehd0cK6adnKDZ6ixVhcGrznBFfo7Mk+H3YwIyF6fQyu4S+EvFJjlBrCjpD/xXKzCX+G07h5UIKhF810Mo= Received: by 10.115.55.1 with SMTP id h1mr388913wak.1178781156111; Thu, 10 May 2007 00:12:36 -0700 (PDT) Received: from ?133.27.59.67? ( [133.27.59.67]) by mx.google.com with ESMTP id a8sm160001poa.2007.05.10.00.12.34; Thu, 10 May 2007 00:12:35 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 16:12:28 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, Mobile IPv6 Mailing List , Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, In your slide, you said "If DS-MIPv6 is not implemented in the kernel, then it is still an issue" for the option-1. What kind of problem is there? I believer an userland program can parse the headers and process the received packets accordingly. regards ryuji On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > Hi, > > My preference is for option 4. I know many preferred option > 3, but it adds a 4 byte per-packet overhead for each tunneled > data packet. I wish we can avoid that. > > Vijay > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Tuesday, May 08, 2007 2:16 PM >> To: Mobile IPv6 Mailing List; nemo@ietf.org >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >> >> >> Hello, >> >> The DS-MIP6 I-D still has >> issue 93 open. This was discussed at IETF68. Vijay presented 4 >> options >> to solve the issue. These are captured in: >> >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >> >> We need to make a decision on this issue and move forward with the >> I-D. At the meeting itself, I got the sense that option 3 was the one >> that had the least impact and easy to implement. >> >> Please consider this email as a consensus call for issue 93. The >> problem and choices are as follows (based on Vijay's slides): >> >> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >> encapculations are either: >> - IPv6-in-UDP-over-IPv4 >> - IPv4-in-UDP-over-IPv4 >> There is a need (or I guess desirable) to indicate the type of >> protocol being encapsulated in the UDP header. >> >> Choices are: >> 1. Parse the protocol header following the UDP header >> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >> 4. Encapsulated protocol header type is indicated in the BU message >> >> Pros and cons of these choices are in the slides that were presented >> at IETF68 (see URL above). >> >> Please provide your opinions and comments by May 15th, 07 on the MIP6 >> mailing list. >> >> -Raj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > From nemo-bounces@ietf.org Thu May 10 03:20:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2xD-0007D2-4Z; Thu, 10 May 2007 03:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2xB-0007CV-OF; Thu, 10 May 2007 03:20:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2xA-0001Xp-9E; Thu, 10 May 2007 03:20:45 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 10 May 2007 00:20:43 -0700 X-IronPort-AV: i="4.14,516,1170662400"; d="scan'208"; a="59012483:sNHT50601834" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4A7KhCD027353; Thu, 10 May 2007 00:20:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4A7Kkwn014514; Thu, 10 May 2007 07:20:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 00:20:42 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 00:20:42 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" , "'Vijay Devarapalli'" References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 00:20:42 -0700 Message-ID: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3A In-Reply-To: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 May 2007 07:20:42.0311 (UTC) FILETIME=[B7D23570:01C792D3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3844; t=1178781643; x=1179645643; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=7tHyTJw1VkAWmsat8rgYsWdxzR+vagxYU+J7ufFGbu4=; b=Zfd2Buf0CQ8BpkyU9HrfXO736qKt72tFehh35XW5fb/xN5p4ELgptBEz6SOZFlqOTxXD7Dg5 c4M0YRLkX6UxKFz2lgoOZDw5SPhqtSl63Vux2CFLRXPKiiROxnARi0fm; Authentication-Results: sj-dkim-5; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji: All protocol packets have payload qualifiers. Looking at the payload to determine the packet type, I'm not sure that is the followed convention. The protocol type in the IP header, or the next option type in the IPv6 headers, the protocol type in gre header, or the 3519 Data Message, all follow this style of containment. We can certainly switch by looking at the 1st byte of the IP packet, but that limits the payload to IP. We cannot carry GRE header over UDP tomorrow, or we cant define a separate control message such as a keepalive message. Why not use a simple type header and provide the room for carrying new payloads ? This may not address your specific comment on the user proc parsing of the packet. But, my comment is on the need for a TLV header. Sri > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > Sent: Thursday, May 10, 2007 12:12 AM > To: Vijay Devarapalli > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > Hi Vijay, > > In your slide, you said "If DS-MIPv6 is not implemented in the > kernel, then it is still an issue" > for the option-1. > > What kind of problem is there? > I believer an userland program can parse the headers > and process the received packets accordingly. > > regards > ryuji > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > Hi, > > > > My preference is for option 4. I know many preferred option > > 3, but it adds a 4 byte per-packet overhead for each tunneled > > data packet. I wish we can avoid that. > > > > Vijay > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Tuesday, May 08, 2007 2:16 PM > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > >> > >> > >> Hello, > >> > >> The DS-MIP6 I-D still has > >> issue 93 open. This was discussed at IETF68. Vijay presented 4 > >> options > >> to solve the issue. These are captured in: > >> > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >> > >> We need to make a decision on this issue and move forward with the > >> I-D. At the meeting itself, I got the sense that option 3 > was the one > >> that had the least impact and easy to implement. > >> > >> Please consider this email as a consensus call for issue 93. The > >> problem and choices are as follows (based on Vijay's slides): > >> > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > traversal. The > >> encapculations are either: > >> - IPv6-in-UDP-over-IPv4 > >> - IPv4-in-UDP-over-IPv4 > >> There is a need (or I guess desirable) to indicate the type of > >> protocol being encapsulated in the UDP header. > >> > >> Choices are: > >> 1. Parse the protocol header following the UDP header > >> 2. Reserve a UDP port for each protocol header (i.e one > UDP port for > >> IPv6-in-UDP-over-IPv4 and another for > IPv4-in-UDP-over-IPv4 etc.) > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >> 4. Encapsulated protocol header type is indicated in the BU message > >> > >> Pros and cons of these choices are in the slides that were > presented > >> at IETF68 (see URL above). > >> > >> Please provide your opinions and comments by May 15th, 07 > on the MIP6 > >> mailing list. > >> > >> -Raj > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Thu May 10 05:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm55c-0005Kr-6Y; Thu, 10 May 2007 05:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm55Z-0005Kg-Mt for nemo@ietf.org; Thu, 10 May 2007 05:37:35 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm55Y-0006d6-IB for nemo@ietf.org; Thu, 10 May 2007 05:37:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so407091pyh for ; Thu, 10 May 2007 02:37:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=oGIoOJ+97L+/GFT0tlilBZpNPfWL5iNSQnDcQZOi8AKELX8Op77b77CUMZT25RSHtwS7OupUrqqKOsAlLuA8rIN72QuR48i+aBk7eCMJaOtuOLxGHr7vu1ZpjYkA4E3OFrWwOggLUjkKw6Xt0lDfNDQ5RbWI3ju5qZmhakvjZvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=rBZEUHZG8wDz2vTGslc8Archi9fLO/lrpUMVl7uXxIxWRlvjhynmXYNnsowgGnCBOfnesqQsssH9vCA15F9jxsJdT3tG7KpMizDwr1sJ2ehkHzW1SX34DwT5/ZRGx4295KcZmarP6gPOOxfl9PJVeofeB4JqRf4GGgkEKTf3Dhs= Received: by 10.35.94.2 with SMTP id w2mr2708619pyl.1178789852201; Thu, 10 May 2007 02:37:32 -0700 (PDT) Received: from ?203.178.143.206? ( [203.178.143.206]) by mx.google.com with ESMTP id f77sm17781796pyh.2007.05.10.02.37.30; Thu, 10 May 2007 02:37:31 -0700 (PDT) In-Reply-To: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 18:37:25 +0900 To: Sri Gundavelli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Sri, The problem is not yet in DSMIP, because DSMIP only supports IPv4 and IPv6 packets in UDP. As Hesham said, the receiver can simply check the followed header (IP) and can determine whether IPv4 or IPv6. I am fine with 4 bytes if there is strong reason for that, however I want to see what kind of additional payloads is considered in the future. In addition, can this 4 bytes mandate only for non IP packets followed by UDP header? If the default is either IPv4 or IPv6, it isn't much big problem for implementations. ryuji On 2007/05/10, at 16:20, Sri Gundavelli wrote: > Hi Ryuji: > > All protocol packets have payload qualifiers. > Looking at the payload to determine the packet type, > I'm not sure that is the followed convention. The protocol > type in the IP header, or the next option type in > the IPv6 headers, the protocol type in gre header, > or the 3519 Data Message, all follow this style of > containment. We can certainly switch by looking at > the 1st byte of the IP packet, but that limits the payload > to IP. We cannot carry GRE header over UDP tomorrow, > or we cant define a separate control message such as > a keepalive message. Why not use a simple type header > and provide the room for carrying new payloads ? > > This may not address your specific comment on the > user proc parsing of the packet. But, my comment > is on the need for a TLV header. > > Sri > > > > > > > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Thursday, May 10, 2007 12:12 AM >> To: Vijay Devarapalli >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to >> close issue 93 >> >> Hi Vijay, >> >> In your slide, you said "If DS-MIPv6 is not implemented in the >> kernel, then it is still an issue" >> for the option-1. >> >> What kind of problem is there? >> I believer an userland program can parse the headers >> and process the received packets accordingly. >> >> regards >> ryuji >> >> On 2007/05/09, at 10:20, Vijay Devarapalli wrote: >> >>> Hi, >>> >>> My preference is for option 4. I know many preferred option >>> 3, but it adds a 4 byte per-packet overhead for each tunneled >>> data packet. I wish we can avoid that. >>> >>> Vijay >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Tuesday, May 08, 2007 2:16 PM >>>> To: Mobile IPv6 Mailing List; nemo@ietf.org >>>> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >>>> >>>> >>>> Hello, >>>> >>>> The DS-MIP6 I-D still has >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 >>>> options >>>> to solve the issue. These are captured in: >>>> >>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>> >>>> We need to make a decision on this issue and move forward with the >>>> I-D. At the meeting itself, I got the sense that option 3 >> was the one >>>> that had the least impact and easy to implement. >>>> >>>> Please consider this email as a consensus call for issue 93. The >>>> problem and choices are as follows (based on Vijay's slides): >>>> >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >> traversal. The >>>> encapculations are either: >>>> - IPv6-in-UDP-over-IPv4 >>>> - IPv4-in-UDP-over-IPv4 >>>> There is a need (or I guess desirable) to indicate the type of >>>> protocol being encapsulated in the UDP header. >>>> >>>> Choices are: >>>> 1. Parse the protocol header following the UDP header >>>> 2. Reserve a UDP port for each protocol header (i.e one >> UDP port for >>>> IPv6-in-UDP-over-IPv4 and another for >> IPv4-in-UDP-over-IPv4 etc.) >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>> 4. Encapsulated protocol header type is indicated in the BU message >>>> >>>> Pros and cons of these choices are in the slides that were >> presented >>>> at IETF68 (see URL above). >>>> >>>> Please provide your opinions and comments by May 15th, 07 >> on the MIP6 >>>> mailing list. >>>> >>>> -Raj >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Thu May 10 10:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9aT-0007fA-JY; Thu, 10 May 2007 10:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9aR-0007eS-K8; Thu, 10 May 2007 10:25:43 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9aP-0000hM-4Q; Thu, 10 May 2007 10:25:43 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070510142538.GPXT25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Thu, 10 May 2007 14:25:38 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005>; Thu, 10 May 2007 14:25:37 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 00:25:24 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfA= In-Reply-To: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > All protocol packets have payload qualifiers. > Looking at the payload to determine the packet type, > I'm not sure that is the followed convention. The protocol > type in the IP header, or the next option type in > the IPv6 headers, the protocol type in gre header, > or the 3519 Data Message, all follow this style of > containment. We can certainly switch by looking at > the 1st byte of the IP packet, but that limits the payload > to IP. We cannot carry GRE header over UDP tomorrow, => Why do we want GRE in MIP6? Are we going to tunnel GRE packets to hosts? IPv6 in general doesn't need GRE, we sure don't have any overlapping address problems... You might be thinking about PMIP here, but you can extend things specifically for that purpose quite easily. The base standard certainly shouldn't be compromised for PMIP. > or we cant define a separate control message such as > a keepalive message. => I thought I answered that point in the last email. Hesham Why not use a simple type header > and provide the room for carrying new payloads ? > > This may not address your specific comment on the > user proc parsing of the packet. But, my comment > is on the need for a TLV header. > > Sri > > > > > > > > > > -----Original Message----- > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > Sent: Thursday, May 10, 2007 12:12 AM > > To: Vijay Devarapalli > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > close issue 93 > > > > Hi Vijay, > > > > In your slide, you said "If DS-MIPv6 is not implemented in the > > kernel, then it is still an issue" > > for the option-1. > > > > What kind of problem is there? > > I believer an userland program can parse the headers > > and process the received packets accordingly. > > > > regards > > ryuji > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > Hi, > > > > > > My preference is for option 4. I know many preferred option > > > 3, but it adds a 4 byte per-packet overhead for each tunneled > > > data packet. I wish we can avoid that. > > > > > > Vijay > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > >> > > >> > > >> Hello, > > >> > > >> The DS-MIP6 I-D > still has > > >> issue 93 open. This was discussed at IETF68. Vijay presented 4 > > >> options > > >> to solve the issue. These are captured in: > > >> > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > >> > > >> We need to make a decision on this issue and move > forward with the > > >> I-D. At the meeting itself, I got the sense that option 3 > > was the one > > >> that had the least impact and easy to implement. > > >> > > >> Please consider this email as a consensus call for issue 93. The > > >> problem and choices are as follows (based on Vijay's slides): > > >> > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > traversal. The > > >> encapculations are either: > > >> - IPv6-in-UDP-over-IPv4 > > >> - IPv4-in-UDP-over-IPv4 > > >> There is a need (or I guess desirable) to indicate the type of > > >> protocol being encapsulated in the UDP header. > > >> > > >> Choices are: > > >> 1. Parse the protocol header following the UDP header > > >> 2. Reserve a UDP port for each protocol header (i.e one > > UDP port for > > >> IPv6-in-UDP-over-IPv4 and another for > > IPv4-in-UDP-over-IPv4 etc.) > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > >> 4. Encapsulated protocol header type is indicated in > the BU message > > >> > > >> Pros and cons of these choices are in the slides that were > > presented > > >> at IETF68 (see URL above). > > >> > > >> Please provide your opinions and comments by May 15th, 07 > > on the MIP6 > > >> mailing list. > > >> > > >> -Raj > > >> > > >> > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Thu May 10 14:52:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDkf-0000Ul-Vg; Thu, 10 May 2007 14:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDke-0000UJ-7q; Thu, 10 May 2007 14:52:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDkc-0005yB-Uy; Thu, 10 May 2007 14:52:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 11:52:16 -0700 X-IronPort-AV: i="4.14,518,1170662400"; d="scan'208"; a="484963636:sNHT4469767730" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AIqFCo004271; Thu, 10 May 2007 11:52:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4AIqB0j029150; Thu, 10 May 2007 18:52:15 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 11:52:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 May 2007 11:52:11 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5203D9CBD4@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABHx+jg From: "Kent Leung \(kleung\)" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 10 May 2007 18:52:12.0311 (UTC) FILETIME=[51C9CA70:01C79334] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=787; t=1178823135; x=1179687135; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20call=20to=20close=2 0issue=2093 |Sender:=20; bh=5EGNv7sAcefTrp9191Tz4ujkAN66D+QigAf+lZD6En0=; b=QMNWT3kxSdWrNnkuQv8D0+H4iiJYMMFnKsn8aJROtcIwnkJDc0Wq6pZDZmE3E9V4ou5l0X0O +0/ixK7IsTc8HimGTak9ceK+Ue8X9+9a4O1T82SUkyYiTlJlbVV6D3DuUXHREYwIbWTIg/NFKf 9CEi4KwYT74O+yzIhuFD25ZIE=; Authentication-Results: sj-dkim-1; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj. I vote for #3. This method is the most flexible. It allows the inclusion of GRE support, which is used to segregate the IPv4 sessions within a tunnel. This feature is valuable to PMIPv6, which is dependant on DSMIP6 for IPv4 support. Other use case may also arise (maybe NEMO?) in the future. IMHO, it's better to provide an extensible framework. Kent=20 -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Tuesday, May 08, 2007 2:16 PM To: Mobile IPv6 Mailing List; nemo@ietf.org Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 Hello, The DS-MIP6 I-D still has issue 93 open. This was discussed at IETF68. Vijay presented 4 options to solve the issue.=20 From nemo-bounces@ietf.org Thu May 10 15:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDsm-0007N8-8a; Thu, 10 May 2007 15:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDsk-0007Md-7C; Thu, 10 May 2007 15:00:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDsi-0006r9-UD; Thu, 10 May 2007 15:00:54 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4AJ0iA24548; Thu, 10 May 2007 19:00:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 14:00:36 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371142CE5A1@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAFUujYA== References: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, Please see comment inline. Regards, Ahmad =20 >=20 > > All protocol packets have payload qualifiers. > > Looking at the payload to determine the packet type, >=20 > I'm not sure that is the followed convention. The protocol >=20 > type in the IP header, or the next option type in > the IPv6=20 > headers, the protocol type in gre header, > or the 3519 Data=20 > Message, all follow this style of > containment. We can=20 > certainly switch by looking at > the 1st byte of the IP=20 > packet, but that limits the payload > to IP. We cannot carry=20 > GRE header over UDP tomorrow, >=20 > =3D> Why do we want GRE in MIP6? Are we going to tunnel GRE=20 > packets to hosts? > IPv6 in general doesn't need GRE, we sure don't have any=20 > overlapping address problems... >=20 > You might be thinking about PMIP here, but you can extend=20 > things specifically for that purpose quite easily. The base=20 > standard certainly shouldn't be compromised for PMIP. [Ahmad] Ok, But I believe it is more efficient if we choose an option (e.g. No. 3) which is flexible enough to address the current and possible (in-progress) future needs.=20 >=20 > > or we cant define a separate control message such as > a=20 > keepalive message.=20 >=20 > =3D> I thought I answered that point in the last email.=20 >=20 > Hesham >=20 >=20 >=20 From nemo-bounces@ietf.org Thu May 10 16:18:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmF5x-0005TW-Lf; Thu, 10 May 2007 16:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmF5w-0005SL-B2; Thu, 10 May 2007 16:18:36 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmF5u-0002uo-Rc; Thu, 10 May 2007 16:18:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AKIO8d018815; Thu, 10 May 2007 23:18:27 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:18:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 15:18:10 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2007 20:18:09 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 10 May 2007 15:18:09 -0500 From: Basavaraj Patil To: ext Hesham Soliman , "'Mobile IPv6 Mailing List'" , Message-ID: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/Y= In-Reply-To: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2007 20:18:10.0587 (UTC) FILETIME=[545C3EB0:01C79340] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [nemo] Re: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham, On 5/8/07 9:03 PM, "ext Hesham Soliman" wrote: > Hi Raj, > > At the meeting Sri (the author of the issue) and Kent said they didn't know > that a UDP port was already reserved. Once we cleared that, the rationale > for the issue was no longer applicable. I believe Sri said he wanted some > time to be sure before the issue is rejected. > More inline on the options: > > >> Choices are: >> 1. Parse the protocol header following the UDP header > > => This should be "parse the version field after the UDP header". This is > what's already in the draft and it works fine today with any UDP > encapsulation. Agree. So this option would impy: Do nothing. > >> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > > => This isn't needed. Okay. > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > => This is what the issue suggested but the additional 4 bytes are > redundant. So are you okay with using the tunnel type message as has been done in RFC3519? Not sure what you are implying by saying that the 4 bytes are redundant in this context. > >> 4. Encapsulated protocol header type is indicated in the BU message > > => Again, not needed IMO. > > I think option 1 is the right option. There is no reason given for a change. Sure... If the encapsulated packets are only IPv4 or IPv6, you could parse the version field and figure out the encapsulated packet type. And as you have said on the list in another email, is there a need for encapsulating any other type of packets between the MN and HA in UDP? I think this is an unknown. GRE has been mentioned, but I agree that it is not generally between an MN and HA. I don't know if you have thought about this option from the NEMO perspective as well. After all this I-D is intended to address hosts and mobile routers. And the other thing is if you want to have some flexibility by introducing the 4 byte header to explicitly indicate the encapsulated packet type (akin to RFC3519) Some explicit reasons for why in the case of MIP6/NEMO would we want the 4 byte header to indicate the encapsulated packet type would be good. Reasons I have heard so far: 1. PMIP6 relies on DS-MIP6 for IPv4 support and hence encapsulation of packets other than IPv4/6 (eg. GRE) should be possible in which case the header would be useful 2. Flexibility for future use 3. Reuse 3519 (don't know if this was mentioned) It would be good to hear from the NEMO folks as well on this issue as we may be overly focused on just MIP6 MNs. -Raj > > Hesham > > > From nemo-bounces@ietf.org Thu May 10 16:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFHk-00059v-Hx; Thu, 10 May 2007 16:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFHj-00053A-5P; Thu, 10 May 2007 16:30:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmFHi-0004Nf-Ih; Thu, 10 May 2007 16:30:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 13:30:43 -0700 X-IronPort-AV: i="4.14,519,1170662400"; d="scan'208"; a="147296515:sNHT61638840" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AKUgQr004795; Thu, 10 May 2007 13:30:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4AKUfEu016764; Thu, 10 May 2007 20:30:42 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:30:32 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:30:31 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 13:30:31 -0700 Message-ID: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAGGqp8A== In-Reply-To: <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 May 2007 20:30:32.0040 (UTC) FILETIME=[0E4CFE80:01C79342] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5991; t=1178829042; x=1179693042; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=L45mq37sObGlUTp9zoKyjvhSTYJL9E3eUtGpcqOwioQ=; b=nyBjJGSFba9zloGa0Y7MhadC5AktMesyM0mVMXO4RCqqs11McDVcc2F1BM6wvY/6UiqryOr2 Uq71sFQD+wbekyDKFUD1jueAO/U0d2AZy6d4z13sMo7hX84yZlDBbzFMBalVDQF7RQc237ynRl lleULIXAlSfHVjYxo5g0t55L0=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, > > All protocol packets have payload qualifiers. > > Looking at the payload to determine the packet type, > > I'm not sure that is the followed convention. The protocol > > type in the IP header, or the next option type in > > the IPv6 headers, the protocol type in gre header, > > or the 3519 Data Message, all follow this style of > > containment. We can certainly switch by looking at > > the 1st byte of the IP packet, but that limits the payload > > to IP. We cannot carry GRE header over UDP tomorrow, > > => Why do we want GRE in MIP6? Are we going to tunnel GRE > packets to hosts? > IPv6 in general doesn't need GRE, we sure don't have any > overlapping address > problems... > Agree, may not be useful for a pure MIP6 node, as the mode is in CCOA mode. But, if you enable NEMO, we need more flexibility on the marking of the MNP flows that go in the tunnel. > You might be thinking about PMIP here, but you can extend things > specifically for that purpose quite easily. The base standard > certainly > shouldn't be compromised for PMIP. > Sure. That's one use-case. PMIP leverages DSMIP6 and leaving a simple TLV wrapper will help in extensibility. I dont think it will compromise the base protocol, its just a simple wrapper, conventionally in all protocols, the prev header identifies the payload that follows. I agree from the perspective of the 3775, it may not be useful, but from 3963 or from PMIP6 perspective, it will be useful. You guys are doing this now, why not provide the hook as well. > > or we cant define a separate control message such as > > a keepalive message. > > => I thought I answered that point in the last email. > Sure. That's one way of building keepalives. > Hesham > > > > Why not use a simple type header > > and provide the room for carrying new payloads ? > > > > > This may not address your specific comment on the > > user proc parsing of the packet. But, my comment > > is on the need for a TLV header. > > > > Sri > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > > Sent: Thursday, May 10, 2007 12:12 AM > > > To: Vijay Devarapalli > > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > > close issue 93 > > > > > > Hi Vijay, > > > > > > In your slide, you said "If DS-MIPv6 is not implemented in the > > > kernel, then it is still an issue" > > > for the option-1. > > > > > > What kind of problem is there? > > > I believer an userland program can parse the headers > > > and process the received packets accordingly. > > > > > > regards > > > ryuji > > > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > > > Hi, > > > > > > > > My preference is for option 4. I know many preferred option > > > > 3, but it adds a 4 byte per-packet overhead for each tunneled > > > > data packet. I wish we can avoid that. > > > > > > > > Vijay > > > > > > > >> -----Original Message----- > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > >> > > > >> > > > >> Hello, > > > >> > > > >> The DS-MIP6 I-D > > still has > > > >> issue 93 open. This was discussed at IETF68. Vijay > presented 4 > > > >> options > > > >> to solve the issue. These are captured in: > > > >> > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > >> > > > >> We need to make a decision on this issue and move > > forward with the > > > >> I-D. At the meeting itself, I got the sense that option 3 > > > was the one > > > >> that had the least impact and easy to implement. > > > >> > > > >> Please consider this email as a consensus call for > issue 93. The > > > >> problem and choices are as follows (based on Vijay's slides): > > > >> > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > traversal. The > > > >> encapculations are either: > > > >> - IPv6-in-UDP-over-IPv4 > > > >> - IPv4-in-UDP-over-IPv4 > > > >> There is a need (or I guess desirable) to indicate the type of > > > >> protocol being encapsulated in the UDP header. > > > >> > > > >> Choices are: > > > >> 1. Parse the protocol header following the UDP header > > > >> 2. Reserve a UDP port for each protocol header (i.e one > > > UDP port for > > > >> IPv6-in-UDP-over-IPv4 and another for > > > IPv4-in-UDP-over-IPv4 etc.) > > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > > >> 4. Encapsulated protocol header type is indicated in > > the BU message > > > >> > > > >> Pros and cons of these choices are in the slides that were > > > presented > > > >> at IETF68 (see URL above). > > > >> > > > >> Please provide your opinions and comments by May 15th, 07 > > > on the MIP6 > > > >> mailing list. > > > >> > > > >> -Raj > > > >> > > > >> > > > >> _______________________________________________ > > > >> Mip6 mailing list > > > >> Mip6@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > >> > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Thu May 10 16:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFLV-0007Mv-3A; Thu, 10 May 2007 16:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFLU-0007MS-2q; Thu, 10 May 2007 16:34:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmFLS-0004nO-PR; Thu, 10 May 2007 16:34:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 13:34:38 -0700 X-IronPort-AV: i="4.14,519,1170662400"; d="scan'208"; a="147298059:sNHT42396489" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AKYcmr010659; Thu, 10 May 2007 13:34:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4AKYbZT009635; Thu, 10 May 2007 20:34:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:34:37 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:34:36 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 13:34:36 -0700 Message-ID: <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS5t/naLlqAWPCTRGzcTYFZ/7GZgAWzU5g In-Reply-To: <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 May 2007 20:34:37.0290 (UTC) FILETIME=[A07B2CA0:01C79342] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1142; t=1178829278; x=1179693278; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=m2MgILCmhuj8mIABzK9Fi7w9xXxAFSWBphFfCdjYpEw=; b=toEhY3qVIIaQxr7hqxeT/Y2drZrFxs0tD4fi3TTJkiU0aVLRxw27LMbmtYL+2PO+G1RiKFCK wDTU3w8+c5SRqM9/r/WmO6gmulpNf0JFKD8UV6IwEkEDy24RgFwBbhxi7L8ZU5FCpFrO4NopEz OHoFPz/beVdRNbJoH5zjkQ+EU=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji, > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > Sent: Thursday, May 10, 2007 2:37 AM > To: Sri Gundavelli > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > Hi Sri, > > The problem is not yet in DSMIP, because DSMIP only supports > IPv4 and > IPv6 packets in UDP. > As Hesham said, the receiver can simply check the followed header > (IP) and can determine whether IPv4 or IPv6. > Its not just about the streams. We need GRE tunnel header for various reasons, when ever there are multiple mobile node or LFN streams, the GRE header for its key carrying capability etc. will be useful, its also useful for PMIP6. So, its a good idea to do the right thing of putting a tiny header as all protocols do. > I am fine with 4 bytes if there is strong reason for that, > however I want to see what kind of additional payloads is considered > in the future. Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO. Will be useful. Sri From nemo-bounces@ietf.org Thu May 10 22:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKr6-0005C1-IL; Thu, 10 May 2007 22:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKr4-0005BW-T9; Thu, 10 May 2007 22:27:38 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmKr4-0002ip-3o; Thu, 10 May 2007 22:27:38 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070511022735.FEJM25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Fri, 11 May 2007 02:27:35 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005>; Fri, 11 May 2007 02:27:34 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 12:27:32 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAGGqp8AAMqgog In-Reply-To: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > Agree, may not be useful for a pure MIP6 node, as the mode > is in CCOA mode. But, if you enable NEMO, we need more > flexibility on the marking of the MNP flows that go in the > tunnel. => Could you elaborate on the nemo aspect you mention above? I don't understand why nemo is helped by this? Hesham > > > You might be thinking about PMIP here, but you can extend things > > specifically for that purpose quite easily. The base standard > > certainly > > shouldn't be compromised for PMIP. > > > > Sure. That's one use-case. PMIP leverages DSMIP6 and leaving > a simple TLV wrapper will help in extensibility. I dont think > it will compromise the base protocol, its just a simple wrapper, > conventionally in all protocols, the prev header identifies the > payload that follows. > > I agree from the perspective of the 3775, it may not be useful, > but from 3963 or from PMIP6 perspective, it will be useful. > You guys are doing this now, why not provide the hook as well. > > > > > or we cant define a separate control message such as > > > a keepalive message. > > > > => I thought I answered that point in the last email. > > > > Sure. That's one way of building keepalives. > > > > Hesham > > > > > > > > Why not use a simple type header > > > and provide the room for carrying new payloads ? > > > > > > > > This may not address your specific comment on the > > > user proc parsing of the packet. But, my comment > > > is on the need for a TLV header. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > > > Sent: Thursday, May 10, 2007 12:12 AM > > > > To: Vijay Devarapalli > > > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > > > close issue 93 > > > > > > > > Hi Vijay, > > > > > > > > In your slide, you said "If DS-MIPv6 is not > implemented in the > > > > kernel, then it is still an issue" > > > > for the option-1. > > > > > > > > What kind of problem is there? > > > > I believer an userland program can parse the headers > > > > and process the received packets accordingly. > > > > > > > > regards > > > > ryuji > > > > > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > > > > > Hi, > > > > > > > > > > My preference is for option 4. I know many preferred option > > > > > 3, but it adds a 4 byte per-packet overhead for > each tunneled > > > > > data packet. I wish we can avoid that. > > > > > > > > > > Vijay > > > > > > > > > >> -----Original Message----- > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > >> > > > > >> > > > > >> Hello, > > > > >> > > > > >> The DS-MIP6 I-D > > > still has > > > > >> issue 93 open. This was discussed at IETF68. Vijay > > presented 4 > > > > >> options > > > > >> to solve the issue. These are captured in: > > > > >> > > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > >> > > > > >> We need to make a decision on this issue and move > > > forward with the > > > > >> I-D. At the meeting itself, I got the sense that option 3 > > > > was the one > > > > >> that had the least impact and easy to implement. > > > > >> > > > > >> Please consider this email as a consensus call for > > issue 93. The > > > > >> problem and choices are as follows (based on > Vijay's slides): > > > > >> > > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > traversal. The > > > > >> encapculations are either: > > > > >> - IPv6-in-UDP-over-IPv4 > > > > >> - IPv4-in-UDP-over-IPv4 > > > > >> There is a need (or I guess desirable) to indicate > the type of > > > > >> protocol being encapsulated in the UDP header. > > > > >> > > > > >> Choices are: > > > > >> 1. Parse the protocol header following the UDP header > > > > >> 2. Reserve a UDP port for each protocol header (i.e one > > > > UDP port for > > > > >> IPv6-in-UDP-over-IPv4 and another for > > > > IPv4-in-UDP-over-IPv4 etc.) > > > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel > type message" > > > > >> 4. Encapsulated protocol header type is indicated in > > > the BU message > > > > >> > > > > >> Pros and cons of these choices are in the slides that were > > > > presented > > > > >> at IETF68 (see URL above). > > > > >> > > > > >> Please provide your opinions and comments by May 15th, 07 > > > > on the MIP6 > > > > >> mailing list. > > > > >> > > > > >> -Raj > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Mip6 mailing list > > > > >> Mip6@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >> > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Thu May 10 23:42:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmM1n-0002R5-6X; Thu, 10 May 2007 23:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmM1m-0002Qr-6G; Thu, 10 May 2007 23:42:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmM1k-00051X-JR; Thu, 10 May 2007 23:42:46 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 20:42:44 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485073156:sNHT54050090" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B3ghie016744; Thu, 10 May 2007 20:42:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4B3ghaI011078; Fri, 11 May 2007 03:42:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 20:42:43 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 20:42:42 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 20:42:42 -0700 Message-ID: <014701c7937e$6e6a2180$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAGGqp8AAMqgogAAIg/aA= In-Reply-To: <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 03:42:42.0680 (UTC) FILETIME=[6E2AA780:01C7937E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6924; t=1178854963; x=1179718963; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=QENSyye3e7DAaYRNJ6Kp1FuJUP9Qf+UHQeap5dGX/HI=; b=rKtQmAtSdoZylaUt3WN7SiFnRXb6TQU9MYTvFM9xfP70aQHiVUoeYNsfnGdeUK6z4FO81Nlf YD75fL5kvv4/cJ32gi59OmnZgoiOQp6GnAsf5Bw0K42zuEF+52qa2MW4; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham: > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 7:28 PM > To: 'Sri Gundavelli' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > > > > Agree, may not be useful for a pure MIP6 node, as the mode > > is in CCOA mode. But, if you enable NEMO, we need more > > flexibility on the marking of the MNP flows that go in the > > tunnel. > > => Could you elaborate on the nemo aspect you mention above? I don't > understand why nemo is helped by this? > We have some use cases where we use the GRE key to tag certain MNP flows and the tunnel peers use these keys as a form of a selector for differential treatment. Its a color code. The seq number and key fields in the GRE header are used. So support for carrying the GRE header over UDP will be possible with the TLV header. Thanks Sri > > > > > > You might be thinking about PMIP here, but you can extend things > > > specifically for that purpose quite easily. The base standard > > > certainly > > > shouldn't be compromised for PMIP. > > > > > > > Sure. That's one use-case. PMIP leverages DSMIP6 and leaving > > a simple TLV wrapper will help in extensibility. I dont think > > it will compromise the base protocol, its just a simple wrapper, > > conventionally in all protocols, the prev header identifies the > > payload that follows. > > > > I agree from the perspective of the 3775, it may not be useful, > > but from 3963 or from PMIP6 perspective, it will be useful. > > You guys are doing this now, why not provide the hook as well. > > > > > > > > or we cant define a separate control message such as > > > > a keepalive message. > > > > > > => I thought I answered that point in the last email. > > > > > > > Sure. That's one way of building keepalives. > > > > > > > Hesham > > > > > > > > > > > > Why not use a simple type header > > > > and provide the room for carrying new payloads ? > > > > > > > > > > > This may not address your specific comment on the > > > > user proc parsing of the packet. But, my comment > > > > is on the need for a TLV header. > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > > > > Sent: Thursday, May 10, 2007 12:12 AM > > > > > To: Vijay Devarapalli > > > > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > > > > close issue 93 > > > > > > > > > > Hi Vijay, > > > > > > > > > > In your slide, you said "If DS-MIPv6 is not > > implemented in the > > > > > kernel, then it is still an issue" > > > > > for the option-1. > > > > > > > > > > What kind of problem is there? > > > > > I believer an userland program can parse the headers > > > > > and process the received packets accordingly. > > > > > > > > > > regards > > > > > ryuji > > > > > > > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > My preference is for option 4. I know many > preferred option > > > > > > 3, but it adds a 4 byte per-packet overhead for > > each tunneled > > > > > > data packet. I wish we can avoid that. > > > > > > > > > > > > Vijay > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > > > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > > > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > > >> > > > > > >> > > > > > >> Hello, > > > > > >> > > > > > >> The DS-MIP6 I-D > > > > still has > > > > > >> issue 93 open. This was discussed at IETF68. Vijay > > > presented 4 > > > > > >> options > > > > > >> to solve the issue. These are captured in: > > > > > >> > > > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > > >> > > > > > >> We need to make a decision on this issue and move > > > > forward with the > > > > > >> I-D. At the meeting itself, I got the sense that > option 3 > > > > > was the one > > > > > >> that had the least impact and easy to implement. > > > > > >> > > > > > >> Please consider this email as a consensus call for > > > issue 93. The > > > > > >> problem and choices are as follows (based on > > Vijay's slides): > > > > > >> > > > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > > traversal. The > > > > > >> encapculations are either: > > > > > >> - IPv6-in-UDP-over-IPv4 > > > > > >> - IPv4-in-UDP-over-IPv4 > > > > > >> There is a need (or I guess desirable) to indicate > > the type of > > > > > >> protocol being encapsulated in the UDP header. > > > > > >> > > > > > >> Choices are: > > > > > >> 1. Parse the protocol header following the UDP header > > > > > >> 2. Reserve a UDP port for each protocol header (i.e one > > > > > UDP port for > > > > > >> IPv6-in-UDP-over-IPv4 and another for > > > > > IPv4-in-UDP-over-IPv4 etc.) > > > > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel > > type message" > > > > > >> 4. Encapsulated protocol header type is indicated in > > > > the BU message > > > > > >> > > > > > >> Pros and cons of these choices are in the slides > that were > > > > > presented > > > > > >> at IETF68 (see URL above). > > > > > >> > > > > > >> Please provide your opinions and comments by May > 15th, 07 > > > > > on the MIP6 > > > > > >> mailing list. > > > > > >> > > > > > >> -Raj > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Mip6 mailing list > > > > > >> Mip6@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >> > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > From nemo-bounces@ietf.org Fri May 11 00:03:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMM8-0000Rz-0V; Fri, 11 May 2007 00:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMM7-0000RW-04 for nemo@ietf.org; Fri, 11 May 2007 00:03:47 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMM6-0006wm-OH for nemo@ietf.org; Fri, 11 May 2007 00:03:46 -0400 Received: by wr-out-0506.google.com with SMTP id 71so854091wri for ; Thu, 10 May 2007 21:03:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=X4vKykJ6SjZoloqu7NPDmrT1j8rLZr6saNYdtYkpq+bFhE1Ge/pZFdULnRZ3gj+nKkPgUcgIBjvF25Mib4KtzDKEAgI6twTc/8VbGRw4wy5YfXUTIXaaaoghfaoAAdixmJaBGJBKRwHFME/X3nYYDig7fhj33oK8fRCyEn3EFYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=T8TgvfNOZN8aJlHLkYfVyhVQYxcUaFhpP5rjtXx0Cy75cBou4wuvsdV18Q5ApaYmQgW7DO0RRMkRDf2U7SWjJNKeBeb6hqsrdqGmTm4Ik2OWX18BdkSsJXtp3jgL3OK2WkL4lPUfWKPcTOI+mnCIL3EZdJJ+wCfAEiK29TdovxE= Received: by 10.114.181.1 with SMTP id d1mr850333waf.1178856226037; Thu, 10 May 2007 21:03:46 -0700 (PDT) Received: from ?203.178.143.206? ( [203.178.143.206]) by mx.google.com with ESMTP id m28sm91566poh.2007.05.10.21.03.39; Thu, 10 May 2007 21:03:44 -0700 (PDT) In-Reply-To: <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63944404-0BDD-41D3-90D5-1D3C8B8B52E4@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 13:03:32 +0900 To: Sri Gundavelli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Sri, OK, if WG agree to support other payload (GRE) in UDP encapsulation, we need to have some bits indicating the header type after the UDP header. However, this consensus call is hard to make, because the current DSMIP only supports IPv4/IPv6 tunnel and not GRE. In the current DSMIP spec, it is obvious that we need nothing here. If GRE is considered, we need to pick one from choices 2-4. Is this consensus call whether we support additional tunnel in UDP? :-p regards, ryuji On 2007/05/11, at 5:34, Sri Gundavelli wrote: > Hi Ryuji, > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Thursday, May 10, 2007 2:37 AM >> To: Sri Gundavelli >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' >> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to >> close issue 93 >> >> Hi Sri, >> >> The problem is not yet in DSMIP, because DSMIP only supports >> IPv4 and >> IPv6 packets in UDP. >> As Hesham said, the receiver can simply check the followed header >> (IP) and can determine whether IPv4 or IPv6. >> > > Its not just about the streams. We need GRE tunnel header for > various reasons, when ever there are multiple mobile node or LFN > streams, the GRE header for its key carrying capability etc. will > be useful, its also useful for PMIP6. So, its a good idea to > do the right thing of putting a tiny header as all protocols do. > > >> I am fine with 4 bytes if there is strong reason for that, >> however I want to see what kind of additional payloads is considered >> in the future. > > Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO. > Will be useful. > > Sri From nemo-bounces@ietf.org Fri May 11 00:08:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMQO-0001Si-CA; Fri, 11 May 2007 00:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMQM-0001S4-Fg; Fri, 11 May 2007 00:08:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMQL-0007rY-4d; Fri, 11 May 2007 00:08:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 21:08:09 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485074852:sNHT46510378" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B4884O031002; Thu, 10 May 2007 21:08:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B47k2I004663; Fri, 11 May 2007 04:08:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 21:08:04 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 21:08:04 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> <63944404-0BDD-41D3-90D5-1D3C8B8B52E4@gmail.com> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 21:08:04 -0700 Message-ID: <014e01c79381$f96b46d0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTgWIk3Z0yy58fQBu2OkoQEoZrEAAAE+cg In-Reply-To: <63944404-0BDD-41D3-90D5-1D3C8B8B52E4@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 04:08:04.0328 (UTC) FILETIME=[F923B680:01C79381] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2427; t=1178856488; x=1179720488; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=FXudBHboiKT3K5KP+PX4KbhEda7a4YCdz8j7T6lCvOY=; b=DIch1Vou0XgkaFNmRAsNqNcDiaZRo1NIAhep2M8qB+cVQqsdmdnGSDLq6DjVGJQsl8q1TO+w GEufyVC54a59eUtI0f05C0XAAGomydzY9F7UAkudTeg6/78YXkifx6fd; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji: Ok. Fair enough. Then I'd vote for Option#3. Having a thin header or a prev header identifying the next header is the followed convention. So, TLV format gives me that and I'd like to stick with that approach. I vote for option #3. Sri > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > Sent: Thursday, May 10, 2007 9:04 PM > To: Sri Gundavelli > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > Hi Sri, > > OK, if WG agree to support other payload (GRE) in UDP encapsulation, > we need to have some bits indicating the header type after the UDP > header. > > However, this consensus call is hard to make, because the current > DSMIP only > supports IPv4/IPv6 tunnel and not GRE. > In the current DSMIP spec, it is obvious that we need nothing here. > If GRE is considered, we need to pick one from choices 2-4. > > Is this consensus call whether we support additional tunnel > in UDP? :-p > > regards, > ryuji > > > > On 2007/05/11, at 5:34, Sri Gundavelli wrote: > > > Hi Ryuji, > > > > > >> -----Original Message----- > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > >> Sent: Thursday, May 10, 2007 2:37 AM > >> To: Sri Gundavelli > >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' > >> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > >> close issue 93 > >> > >> Hi Sri, > >> > >> The problem is not yet in DSMIP, because DSMIP only supports > >> IPv4 and > >> IPv6 packets in UDP. > >> As Hesham said, the receiver can simply check the followed header > >> (IP) and can determine whether IPv4 or IPv6. > >> > > > > Its not just about the streams. We need GRE tunnel header for > > various reasons, when ever there are multiple mobile node or LFN > > streams, the GRE header for its key carrying capability etc. will > > be useful, its also useful for PMIP6. So, its a good idea to > > do the right thing of putting a tiny header as all protocols do. > > > > > >> I am fine with 4 bytes if there is strong reason for that, > >> however I want to see what kind of additional payloads is > considered > >> in the future. > > > > Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 > and NEMO. > > Will be useful. > > > > Sri From nemo-bounces@ietf.org Fri May 11 00:14:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMWL-0007Kq-Kc; Fri, 11 May 2007 00:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMWJ-0007JV-Um; Fri, 11 May 2007 00:14:19 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMWI-0000OL-M0; Fri, 11 May 2007 00:14:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4B4EGh04148; Fri, 11 May 2007 04:14:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 May 2007 23:14:14 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371142CEDF9@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cg References: From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj, I hinted in several emails to option #3.=20 However, since the consensus call requires clear answers, I would like to vote for option # 3. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, May 08, 2007 4:16 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 >=20 > Hello, >=20 > The DS-MIP6 I-D =20 > still has issue 93 open. This was discussed at IETF68. Vijay=20 > presented 4 options to solve the issue. These are captured in: >=20 > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >=20 > We need to make a decision on this issue and move forward=20 > with the I-D. At the meeting itself, I got the sense that=20 > option 3 was the one that had the least impact and easy to implement. >=20 > Please consider this email as a consensus call for issue 93.=20 > The problem and choices are as follows (based on Vijay's slides): >=20 > Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type=20 > of protocol being encapsulated in the UDP header. >=20 > Choices are: > 1. Parse the protocol header following the UDP header 2.=20 > Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a=20 > DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message >=20 > Pros and cons of these choices are in the slides that were=20 > presented at IETF68 (see URL above). >=20 > Please provide your opinions and comments by May 15th, 07 on=20 > the MIP6 mailing list. >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Fri May 11 01:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNTf-0003Pw-JD; Fri, 11 May 2007 01:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNTd-0003PB-2O; Fri, 11 May 2007 01:15:37 -0400 Received: from mx05.syd.iprimus.net.au ([210.50.30.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNTb-0006HS-27; Fri, 11 May 2007 01:15:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACuZQ0bTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,520,1170594000"; d="dat'59?scan'59,208,59";a="45771896" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 11 May 2007 15:15:15 +1000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Date: Fri, 11 May 2007 15:15:09 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C793DF.2A72B8A0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/YAEg5cQA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MS-TNEF-Correlator: 00000000660B30941AE58D429C64D7B799B4C29B844F2600 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C793DF.2A72B8A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > >> Choices are: > >> 1. Parse the protocol header following the UDP header > > > > => This should be "parse the version field after the UDP > header". This is > > what's already in the draft and it works fine today with any UDP > > encapsulation. > > Agree. So this option would impy: Do nothing. => Yes. > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > > > => This is what the issue suggested but the additional 4 bytes are > > redundant. > > So are you okay with using the tunnel type message as has > been done in > RFC3519? Not sure what you are implying by saying that the 4 > bytes are > redundant in this context. => I meant that they are redundant because they have no justification for the operation of the spec. The rationale for the suggestion was that it was not really possible (or difficult) to tell whether the following packet was IPv4 or IPv6 if the implementation is in user space; and that it was diffcult to know the packet length. However, after we discussed this, it turned out that none of these issues are true, so I don't see why we need to add another 4 bytes to every packet. > > > > >> 4. Encapsulated protocol header type is indicated in the > BU message > > > > => Again, not needed IMO. > > > > I think option 1 is the right option. There is no reason > given for a change. > > Sure... If the encapsulated packets are only IPv4 or IPv6, > you could parse > the version field and figure out the encapsulated packet > type. And as you > have said on the list in another email, is there a need for > encapsulating > any other type of packets between the MN and HA in UDP? I > think this is an > unknown. GRE has been mentioned, but I agree that it is not generally > between an MN and HA. I don't know if you have thought about > this option > from the NEMO perspective as well. After all this I-D is > intended to address > hosts and mobile routers. => Sure, if there is something specific for nemo then we have to address it. I still don't know what that is though. I'd appreciate it if someone can explain it. And the other thing is if you want > to have some > flexibility by introducing the 4 byte header to explicitly > indicate the > encapsulated packet type (akin to RFC3519) > > Some explicit reasons for why in the case of MIP6/NEMO would > we want the 4 > byte header to indicate the encapsulated packet type would be good. > => Yes. > Reasons I have heard so far: > 1. PMIP6 relies on DS-MIP6 for IPv4 support and hence > encapsulation of > packets other than IPv4/6 (eg. GRE) should be possible in > which case the > header would be useful => I heard that too, but I don't know why we should add more overhead for every host and router just so PMIP might use GRE, unless we want to make MIP look like it's more wasteful. Also, I don't understand why GRE has to follow UDP and not run after the IP header? I need to re-read GRE to see if that's possible. > 2. Flexibility for future use > 3. Reuse 3519 (don't know if this was mentioned) => what do you mean by "reuse 3519"? You mean "make it look like 3519"? That's not a reason though is it? Hesham ------=_NextPart_000_000B_01C793DF.2A72B8A0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgoFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgCcCwAAJAAAAAsAAgABAAAAAwAmAAAA AAALACsAAAAAAAMALgAAAAAAAgExAAEAAAAYAAAAAAAAAGYLMJQa5Y1CnGTXt5m0wptETyYAHgBw AAEAAAAxAAAAW01pcDZdIERTLU1JUDY6IENvbnNlbnN1cyBjYWxsIHRvIGNsb3NlIGlzc3VlIDkz AAAAAAIBcQABAAAAJQAAAAHHkbYhxWB0ZzH9qRHblK0AESTVDYgACdEqIABYuz/2ABIOXEAAAAAL AAEOAAAAAAIBCg4BAAAAGAAAAAAAAABmCzCUGuWNQpxk17eZtMKbwoAAAAMAFA4BAAAAHgAoDgEA AAAnAAAAMDAwMDAwMDYBSGVzaGFtQGVsZXZhdGVtb2JpbGUuY29tAVdvcmsAAB4AKQ4BAAAAJwAA ADAwMDAwMDA2AUhlc2hhbUBlbGV2YXRlbW9iaWxlLmNvbQFXb3JrAAACARQ6AQAAABAAAACZlyk5 R4KuQZdS6xPkY33YAwDeP59OAAADAAlZAQAAAAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAA AAAAAwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAA AAAGhQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAggAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADACSACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAPoAIIAYA AAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwAfDgEAAAACAfgPAQAAABAAAABmCzCUGuWNQpxk17eZ tMKbAgH6DwEAAAAQAAAAZgswlBrljUKcZNe3mbTCmwMA/g8FAAAAAgEJEAEAAADhBwAA3QcAAEIP AABMWkZ1ulM5lQMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IR JQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQ8wsJAWQz NhZQC6YK4wqEGQqAID4dsB3AQ2hvJw3gB5EKwGU6HVoxLkQgUBPyIHRoIABwqQNgdG8XkSAgMGEE gZogAhBsF7AD8G5nIBN4VURQIOUdWBzlI0M9SR3AVGgEACBzHiB10GxkIGIgACIKsR/1fnYEkACQ AiAhUAiQJQFh3wGAEoEiBh1XIPQiH6Akc0sEACLpdxPgdCcecWw7GCAhEHkpMAOgICJkcqsm8R6A biUQaQVAdwWwtmsEICaQbiABBHBhKuB/A/AgICvBKuAiQSLpCfBj+GFwcyTwKjAmUR+gHVfNHVdB CcIfoFNvIBEkkT5vBTAmUixAJPIHcHB56DogRDFQbiCAJIAh0HYuHPokQVkHkDObHbQz3R+gTyzB GCAUEHImECUQLSJCcBfBK8NhMuBTLRBNSVA2JVB0dW5jLMADIHR5cCAAB4Fz8GFnZSIi7yP7JJEq Ek8gEwQBClAksHVnOYBz2w6wJRF1O/QhEGQsECZR6QdAIDQlIHkOsB5zObn/GCE4gC0QAjAvnx2x MUEekawgeQhgMbBrLSZ1AJD/IdU4fzmAHoAEIBPgBCEdZn8lMAnwK2ACIDwxC5AdZlKARkMzNTE5 PwewfyCAPKFB8TvDQiJB4jKRbP55IcI+oCSwLSAhxDvlPoD/RVg+vz/nKvQkkQWgAjAOwf0znkk5 IU0SSlYq4EHiTLj/JTAu4EMAIAMq4BPgJhAzEfwgakMAL1AmkC7gMeMCEE8nNDHABJBTFG9mIBNz /TkAYyjSNkEvQwdAIABTdv88tTHzROFKUywSROEzITZRbwdASVA3IQQQaQJgIAAonwWxPfABIA3g JPB0KSzh/yAQJrADICoQFCAgMCc0IWi5CrBjaxQgV2M4IHY+gL8FsV0xOEAGkDwESTFlB4D/AjBT FCkSA6BRgQXAVQAA0HxlOyvDV7pZ8lpCWpJr/zMgB+AgI1yUVhAh0CAgH6DqSCGgZSYRLCblY+BZ 4f8E8EMAFBBgogQAZDAsEUOg/wSgNsEIYE+lMyAswVSUH/G3PFMecyAQcgpQZDBzMVD7T0BGMSdH 4QngKgEtMVJB/wngYKFBwT3gK8EzMRKBPoZ/WqFj8lkBXJM0zjm/HbQ0/R+gRS7XNsEgbjjjX2M9 8M9TATbBKwUdV0JVOSZuH38j9jDQC3FkMFhyamI2wUm8TU8zlXSuT0AzQmsxts4xO4IgIgUQZ2gF QDHEf1VDSPJYUliiaQADoR1mZ/5pJhBTVDfAE9Eh0DEQbY/7BgBIES5/QE8wVKQuyHBS/1yTaEQC IFjxXTpkMB1XQiJ/BaAk8iVzHVcl3yvDJpBnf0gSZoR/31yjhDg48R+gQb83kgQgQiEn2FIiOWBp ZmF9KxRsBABNM2smXrALcGz/ZcF5s0HxN8BqY1NyHVcuyf8h0B1XLaJrRDjjVJGAxiUwTnRj4EYB ICJNTivDSP5BKvIiQUegT0CEOXjSMXM/JJEAcB1XQ7BiQi+BR1L+RUUDReNewiZRCYBkMD1S/09A OXAJ0Vene1MFQDmALMD/K4BY4UVZkeQDkZKHf2FpRf9iQ14BQiJSEyAgCGB6MgGgP2aCk8oxph1X A1IgE05F/3cAcHAmIVURL1BSMUThY+AfIYCJIScDWNExZEktRP87gh1XC4AOsCvgaoc2YSlY3x4g PQCVEiUQBGBiAxA2Qf9mgSYhQHY0B38CZcFUo3sk/2kAB4AzQ1TzUtJTYyzABGD/IBIyESAAnWSl JywBnAJSsX9a8ZxJO8VX0leSndJ/YSf9JtFwIGCqsXAxmPNUoKny/0ZCLuADoA7AC1OtIzTaiUL/ U7NbVSHCKRKdBFdwTSGEON8xUIp0qgGf2FYQeFlgAxD/LBAq4EmxpIEDYEAAqsAh1f8+hHEHbDGy EQ3gLBBY8aP5H3IkIBKOP4eaOOMoYWv3KwIxUEc1KX3vMTEHgLqH/3ulLIEFsWnyKwUu4B/xVJH9 OBIvoPMyNB1XZLG1Y0qjf0sLuem72r0fvicyNCUxZ95vBHB93jQPHTlSwdVPQO9SEyDxCyBo8mYK wB7IH5L/OBMYIIuAB5EmYTfmU3JdM/8vELBAN0arwR5Qji8vNFSBXx1XgMa0BgORXTIvOEAo/mUz gJZiWoAkyFknKwHEuH8kgBPQwyS8aiD1yfdRgWb/JPBOX850SlTKkJfWrftqE/8kxWriBGCBUiYR IPJTY2xU/6ZCK8OnVFKDaPLQAjkgeiP/UYKWcWQwQ7BWEAQRxUcxUP8AwFyww6JjMMqQePCLgOYR fywQKlHgk1dxDrDcIYkhbP9pAGQwaTZAESYhAZAr4Wny/5Z2WqEhZCIzK9JYc0OwJunf47Eg9JOC amYYIC0qopZjv1qhabJeAyozWSY0zjIfoP5Gt6lTctwgZhHb0x1XNfH/zYBRgkdiWaCcTDFzV3KX R3+/tcvHO8NGMEITT2JJoiKrGCD0RiJHoFn4diLl8/8sEeaI+ZUkcCozWHI3wHu12520X1N0R6A0 2kgHkBPgF6CQNNo02n0BEAAAAAMADTT9PwUAAwAPNP0/BQACARQ0AQAAABAAAABOSVRB+b+4AQCq ADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDA2NjBCMzA5NDFBRTU4RDQyOUM2NEQ3Qjc5OUI0QzI5 Qjg0NEYyNjAwAAAAAAMABhBu0EMxAwAHEC0JAAADABAQAwAAAAMAERAAAAAAHgAIEAEAAABlAAAA Q0hPSUNFU0FSRToxUEFSU0VUSEVQUk9UT0NPTEhFQURFUkZPTExPV0lOR1RIRVVEUEhFQURFUj1U SElTU0hPVUxEQkUiUEFSU0VUSEVWRVJTSU9ORklFTERBRlRFUlRIRVVEUAAAAACWmg== ------=_NextPart_000_000B_01C793DF.2A72B8A0-- From nemo-bounces@ietf.org Fri May 11 01:19:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNXY-0006YC-Ft; Fri, 11 May 2007 01:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNXW-0006Sz-Ag; Fri, 11 May 2007 01:19:38 -0400 Received: from mx05.syd.iprimus.net.au ([210.50.30.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNXU-0006TO-RC; Fri, 11 May 2007 01:19:38 -0400 Message-Id: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACuZQ0bTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,520,1170594000"; d="scan'208";a="45772462" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 11 May 2007 15:19:34 +1000 From: "Hesham Soliman" To: , Date: Fri, 11 May 2007 15:19:30 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [nemo] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, This concensus call on issue 93 made me a bit confused about the use of GRE. I have a simple question: Why can't people that want to use GRE (for PMIP) run it as follows: IP Heahder (proto 47 for GRE) GRE Header UDP ....etc Why do we need to add another layer to qualifiers instead of using the existing allocated numbers? It's been a couple of years since I read the GRE spec so I wanted to understand if this format is a problem Hesham From nemo-bounces@ietf.org Fri May 11 01:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNde-0001mH-OM; Fri, 11 May 2007 01:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNdc-0001ll-Nt; Fri, 11 May 2007 01:25:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNdb-00077j-C3; Fri, 11 May 2007 01:25:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 22:25:54 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="147486060:sNHT40923306" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4B5PsZE021775; Thu, 10 May 2007 22:25:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B5Po20007623; Fri, 11 May 2007 05:25:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:25:50 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:25:49 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> Date: Thu, 10 May 2007 22:25:50 -0700 Message-ID: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQ In-Reply-To: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 05:25:50.0021 (UTC) FILETIME=[D61BF750:01C7938C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=843; t=1178861154; x=1179725154; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=XjlyYErcK8PidzHhvyPci2spG5vSdDqTv4CIVboJGus=; b=y430YYubsp+bPy2YkOm3R8wXhwua9JHf1AYmgKhUhGSsMkDD13HZK7qP648QxrJ2Cc/r+q8L B8b2BegytCmF7Hiq0EGOA/IrP03JQ5MHOrMbbKJ0rlTC2Rb/x5N1IbLT; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 10:20 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] The use of GRE > > Hi all, > > This concensus call on issue 93 made me a bit confused about > the use of GRE. > I have a simple question: > > Why can't people that want to use GRE (for PMIP) run it as follows: > > IP Heahder (proto 47 for GRE) > GRE Header > UDP > ....etc > > Why do we need to add another layer to qualifiers instead of using the > existing allocated numbers? > > It's been a couple of years since I read the GRE spec so I wanted to > understand if this format is a problem > Problem will be with the NAT/PAT device. It wont create NAT bindings from the UDP header encapped in the GRE header. Sri From nemo-bounces@ietf.org Fri May 11 01:32:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNju-0006WJ-GN; Fri, 11 May 2007 01:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNjs-0006TE-KE; Fri, 11 May 2007 01:32:24 -0400 Received: from mx05.syd.iprimus.net.au ([210.50.30.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNjr-0008H0-7E; Fri, 11 May 2007 01:32:24 -0400 Message-Id: <5t7lbv$1bktaj@smtp05.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOucQ0bTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,520,1170594000"; d="scan'208";a="45774163" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 11 May 2007 15:32:16 +1000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Date: Fri, 11 May 2007 15:32:09 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eA= In-Reply-To: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > It's been a couple of years since I read the GRE spec so I > wanted to > > understand if this format is a problem > > > > Problem will be with the NAT/PAT device. It wont create NAT bindings > from the UDP header encapped in the GRE header. => So you want to use GRE in a *local* domain where a NAT separates the MAG and the LMA? In DSMIP we don't care or want to use GRE, therefore we don't have a NAT problem. But are you really saying that you have a NAT problem in NETLMM ? I think the reasons for this are getting very slim. I was hoping to actually see a good reason so I can say ok we've added 4 bytes but there is potenial benefits here, but given this I think it's just wasteful to do this and make it a default. If you want to use it in PMIP, I think you should add that additional UDP header specifically for PMIP and NAT cases, I don't think normal hosts and routers should carry the burden over the air interface for PMIP to avoid 8 bytes over a a wired network. Hesham > > Sri > > > From nemo-bounces@ietf.org Fri May 11 01:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNwx-0000BN-Je; Fri, 11 May 2007 01:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNww-0000AW-3G; Fri, 11 May 2007 01:45:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNwv-0001Sm-P0; Fri, 11 May 2007 01:45:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 22:45:53 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="420914011:sNHT47833132" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4B5jr5t019540; Thu, 10 May 2007 22:45:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B5jr20016667; Fri, 11 May 2007 05:45:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:45:52 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:45:52 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> <5t7lbv$1bktaj@smtp05.syd.iprimus.net.au> Date: Thu, 10 May 2007 22:45:52 -0700 Message-ID: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IA== In-Reply-To: <5t7lbv$1bktaj@smtp05.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 05:45:52.0631 (UTC) FILETIME=[A2EBB070:01C7938F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1989; t=1178862353; x=1179726353; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=E5XS4s7+1lxQUTWMuRbzv2+qBswpOamBsARQmFUxyQ0=; b=VUmwcR78Z7b2S4T+rNmRjgLJjumNoT7pE9987YHB4kZ1MtTaAPX2l/DtdAdgo6Tz07ZHeiKp 9eQ0WwTU0rlOhJ+vky35ep3sTpZEPieF0OYe8B+8dVFubSzjCcwZaZMW; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 10:32 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > > > > > It's been a couple of years since I read the GRE spec so I > > wanted to > > > understand if this format is a problem > > > > > > > Problem will be with the NAT/PAT device. It wont create > NAT bindings > > from the UDP header encapped in the GRE header. > > => So you want to use GRE in a *local* domain where a NAT > separates the MAG > and the LMA? > In DSMIP we don't care or want to use GRE, therefore we don't > have a NAT > problem. But are you really saying that you have a NAT > problem in NETLMM ? > MIP4 has GRE support and has wide use for the MR case also for the FA-CCOA mode. So, we can keep PMIP out of this discussion. IMO, GRE mode is useful for HA-MR tunnel. > I think the reasons for this are getting very slim. I was > hoping to actually > see a good reason so I can say ok we've added 4 bytes but > there is potenial > benefits here, but given this I think it's just wasteful to > do this and make > it a default. > > If you want to use it in PMIP, I think you should add that > additional UDP > header specifically for PMIP and NAT cases, I don't think > normal hosts and > routers should carry the burden over the air interface for > PMIP to avoid 8 > bytes over a a wired network. > We dont have to justify this just for PMIP. Its just another consumer, like NEMO. IMO, having a thin header, always helps, follows the conventional way of tagging. Also, to extend this later for NEMO, we cannot use the same port, as the old and new implementation will have a problem dealing with UDP payloads with GRE and no GRE headers, at the same time. Any ways, this is my one opinion. Sri > Hesham > > > > > Sri > > > > > > From nemo-bounces@ietf.org Fri May 11 01:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmO3D-0002tO-L8; Fri, 11 May 2007 01:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmO3C-0002sr-9B; Fri, 11 May 2007 01:52:22 -0400 Received: from mx03.syd.iprimus.net.au ([210.50.30.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmO3A-0002WX-RZ; Fri, 11 May 2007 01:52:22 -0400 Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp03.syd.iprimus.net.au with ESMTP; 11 May 2007 15:52:14 +1000 Message-Id: <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Date: Fri, 11 May 2007 15:52:08 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHg In-Reply-To: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > > => So you want to use GRE in a *local* domain where a NAT > > separates the MAG > > and the LMA? > > In DSMIP we don't care or want to use GRE, therefore we don't > > have a NAT > > problem. But are you really saying that you have a NAT > > problem in NETLMM ? > > > > MIP4 has GRE support and has wide use for the MR case also > for the FA-CCOA mode. So, we can keep PMIP out of this > discussion. IMO, GRE mode is useful for HA-MR tunnel. => You can also keep MIP4 out of this discussion because we're talking about DSMIPv6. If we take PMIP out of the discussion then there is no reason for GRE whatsoever. > > > > I think the reasons for this are getting very slim. I was > > hoping to actually > > see a good reason so I can say ok we've added 4 bytes but > > there is potenial > > benefits here, but given this I think it's just wasteful to > > do this and make > > it a default. > > > > If you want to use it in PMIP, I think you should add that > > additional UDP > > header specifically for PMIP and NAT cases, I don't think > > normal hosts and > > routers should carry the burden over the air interface for > > PMIP to avoid 8 > > bytes over a a wired network. > > > > We dont have to justify this just for PMIP. Its just another > consumer, like NEMO. IMO, having a thin header, always helps, > follows the conventional way of tagging. => My problem here is that you're not giving me any concrete reasons for a use case. Just saying "always helps" doesn't make me understand something new. There is only two IP versions today and this is not going to change till you and I retire, so I don't find this flexibility argument realistic. Also, to extend this > later for NEMO, we cannot use the same port, as the old => Extend what for nemo??? Nemo is already supported in this spec. Hesham From nemo-bounces@ietf.org Fri May 11 02:06:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOGw-0004hY-RR; Fri, 11 May 2007 02:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOGu-0004h2-Nl; Fri, 11 May 2007 02:06:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOGt-0004et-E4; Fri, 11 May 2007 02:06:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 23:06:31 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485091739:sNHT43085656" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4B66Ums001161; Thu, 10 May 2007 23:06:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4B66UaI012117; Fri, 11 May 2007 06:06:30 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:06:30 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:06:30 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> Date: Thu, 10 May 2007 23:06:26 -0700 Message-ID: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPA= In-Reply-To: <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 06:06:30.0084 (UTC) FILETIME=[84800840:01C79392] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1566; t=1178863590; x=1179727590; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=o+q8K++hEE4gngApedzu6G7nN39FQHhErQc+1VlGapA=; b=Bsr0ogKvOz1c242V+Y4OQI52+rg84k6Y9qQ/lJZ7CZqxRy9J5WCoqiywLiiggBv0HVY8ng8p hhaCC2P+boJ4nODeUMX7GT7xbw/aB6UnlZgdONE0ie+/3K7GNIzi3KaU; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > > > > > We dont have to justify this just for PMIP. Its just another > > consumer, like NEMO. IMO, having a thin header, always helps, > > follows the conventional way of tagging. > > => My problem here is that you're not giving me any concrete > reasons for a > use case. > Just saying "always helps" doesn't make me understand > something new. There > is only two IP versions today and this is not going to change > till you and I > retire, so I don't find this flexibility argument realistic. > GRE header is applicable when flows from multiple nodes are carried in the same tunnel. That's not the case for 3775 MN flows, but indeed is the case for 3963. The GRE header has the proper semantics that allows tunnel peers to process properly. The seq number in the header is useful when carrying real time traffic. Is this not a good reason ? Now, if you say there is no GRE tunneling for MIP6, off course, thats where I say, there is a chance we will introduce GRE tunnel mode for NEMO use cases in mind, learnt from the experience of supporting NEMOv4 deployments and applications. Sure, supporting GRE mode helps PMIP as well, I agree, if we apply it there. Second reason, I give is the convention that has been followed in all protocol designs so far, of prev header identifying the next header. No protocol is mucking around in the payloads to determine the type. Are these not good reasons ? Do they outweigh the 4 byte saving ? Again, this is my opinion. We can let others comment on this. Sri From nemo-bounces@ietf.org Fri May 11 02:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOVC-0006u8-FQ; Fri, 11 May 2007 02:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOVB-0006tc-9k; Fri, 11 May 2007 02:21:17 -0400 Received: from mx03.syd.iprimus.net.au ([210.50.30.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOVA-0006Wu-RK; Fri, 11 May 2007 02:21:17 -0400 Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp03.syd.iprimus.net.au with ESMTP; 11 May 2007 16:21:14 +1000 Message-Id: <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Date: Fri, 11 May 2007 16:21:04 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MA== In-Reply-To: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri, > > > > > > We dont have to justify this just for PMIP. Its just another > > > consumer, like NEMO. IMO, having a thin header, always helps, > > > follows the conventional way of tagging. > > > > => My problem here is that you're not giving me any concrete > > reasons for a > > use case. > > Just saying "always helps" doesn't make me understand > > something new. There > > is only two IP versions today and this is not going to change > > till you and I > > retire, so I don't find this flexibility argument realistic. > > > > > GRE header is applicable when flows from multiple nodes are carried > in the same tunnel. That's not the case for 3775 MN flows, but indeed > is the case for 3963. The GRE header has the proper semantics that > allows tunnel peers to process properly. The seq number in the header > is useful when carrying real time traffic. Is this not a > good reason ? => This is a classic example of hacks that lingered for such long time that it grew on people and they thought it's just the "normal" way of doing things. I think your arguments above are quite confused about GRE. It's like the very common arguments about NATs being good for security. The need for another abstraction layer for tunnelling was only to support virtual routing, especially for environments that conntain overlapping IPv4 addresses. Everything else you talk about above is available in IP and transport headers; and I won't even get into QoS for IP flows. You seem to think that this is a special case for nemo because there can be "many flows", which is not the case in a 3775 MN. This is clearly a confused view of things because a MN can of course generate many flows, from different addresses ....etc ....sigh > Now, if you say there is no GRE tunneling for MIP6, off course, thats > where I say, there is a chance we will introduce GRE tunnel mode > for NEMO use cases in mind, learnt from the experience of supporting > NEMOv4 deployments and applications. => I think I've said enough on this. I don't think I can add any more. I honestly think what you're listing above is either confused or a case of you wanting everyone else to fit some idea in your mind, which we don't know. Sure, supporting GRE mode helps > PMIP as well, I agree, if we apply it there. Second reason, I give > is the convention that has been followed in all protocol designs so > far, of prev header identifying the next header. No protocol > is mucking > around in the payloads to determine the type. => Mucking around? There is a very well known encoding mechanism called TLV where you have to inspect the first byte to know the type of information following it. I don't think that's referred to as mucking around, at least not in specs.. ;0 enuff said from me. Hesham Are these not good > reasons ? Do they outweigh the 4 byte saving ? Again, this is my > opinion. We can let others comment on this. > > > Sri > From nemo-bounces@ietf.org Fri May 11 02:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOdc-00059L-OR; Fri, 11 May 2007 02:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOdb-00058g-6K; Fri, 11 May 2007 02:29:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOda-0007cd-Nu; Fri, 11 May 2007 02:29:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 23:29:58 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485095804:sNHT49901744" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B6TwHZ028924; Thu, 10 May 2007 23:29:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B6Tr20006378; Fri, 11 May 2007 06:29:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:29:53 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:29:52 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> Date: Thu, 10 May 2007 23:29:52 -0700 Message-ID: <016b01c79395$c8b82530$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MAAAsbFg In-Reply-To: <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 06:29:52.0984 (UTC) FILETIME=[C8B19580:01C79395] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3559; t=1178864998; x=1179728998; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=B0aAlybJduoV4VS+4ABxBrgZ4J0kIFsKsAwWOMcaE5o=; b=DsC7omiB85Wsbx/b1lp7E3Om7gLaQX9rDuvZKlQAlyswP7ABIHNK83qWaxBM4DRtd2ttSgxz XElSeAGWukynts5KgodgUteKRplB8UW+aE/e6w8yinfbCfcGIus1MkHt; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, Ok. Thanks for the discussion. Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 11:21 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > Sri, > > > > > > > > > We dont have to justify this just for PMIP. Its just another > > > > consumer, like NEMO. IMO, having a thin header, always helps, > > > > follows the conventional way of tagging. > > > > > > => My problem here is that you're not giving me any concrete > > > reasons for a > > > use case. > > > Just saying "always helps" doesn't make me understand > > > something new. There > > > is only two IP versions today and this is not going to change > > > till you and I > > > retire, so I don't find this flexibility argument realistic. > > > > > > > > > GRE header is applicable when flows from multiple nodes are carried > > in the same tunnel. That's not the case for 3775 MN flows, > but indeed > > is the case for 3963. The GRE header has the proper semantics that > > allows tunnel peers to process properly. The seq number in > the header > > is useful when carrying real time traffic. Is this not a > > good reason ? > > => This is a classic example of hacks that lingered for such > long time that > it grew on people and they thought it's just the "normal" way of doing > things. > I think your arguments above are quite confused about GRE. > It's like the > very common arguments about NATs being good for security. > The need for another abstraction layer for tunnelling was > only to support > virtual routing, especially for environments that conntain > overlapping IPv4 > addresses. > > Everything else you talk about above is available in IP and transport > headers; and I won't even get into QoS for IP flows. You seem > to think that > this is a special case for nemo because there can be "many > flows", which is > not the case in a 3775 MN. This is clearly a confused view of > things because > a MN can of course generate many flows, from different > addresses ....etc > ....sigh > > > Now, if you say there is no GRE tunneling for MIP6, off > course, thats > > where I say, there is a chance we will introduce GRE tunnel mode > > for NEMO use cases in mind, learnt from the experience of > supporting > > NEMOv4 deployments and applications. > > => I think I've said enough on this. I don't think I can add > any more. I > honestly think what you're listing above is either confused > or a case of you > wanting everyone else to fit some idea in your mind, which we > don't know. > > > > Sure, supporting GRE mode helps > > PMIP as well, I agree, if we apply it there. Second reason, I give > > is the convention that has been followed in all protocol designs so > > far, of prev header identifying the next header. No protocol > > is mucking > > around in the payloads to determine the type. > > => Mucking around? There is a very well known encoding > mechanism called TLV > where you have to inspect the first byte to know the type of > information > following it. I don't think that's referred to as mucking > around, at least > not in specs.. ;0 > > enuff said from me. > Hesham > > Are these not good > > reasons ? Do they outweigh the 4 byte saving ? Again, this is my > > opinion. We can let others comment on this. > > > > > > Sri > > From nemo-bounces@ietf.org Fri May 11 02:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOl7-0007Cc-G7; Fri, 11 May 2007 02:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOl5-0007Bw-Mu; Fri, 11 May 2007 02:37:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOl5-00008B-AK; Fri, 11 May 2007 02:37:43 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4B6bdjJ017351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 May 2007 23:37:40 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4B6bda4027399; Thu, 10 May 2007 23:37:39 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:37:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 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: [Mip6] The use of GRE Date: Thu, 10 May 2007 23:37:38 -0700 Message-ID: In-Reply-To: <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MAAA6lwA References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> From: "Narayanan, Vidya" To: "Hesham Soliman" , "Sri Gundavelli" , , X-OriginalArrivalTime: 11 May 2007 06:37:39.0012 (UTC) FILETIME=[DE77D040:01C79396] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I'm confused by this thread - could someone explain the role of GRE for NEMO? From everything I've read so far on this thread, I'm with Hesham here - I don't understand why we need GRE to parse the multiple flows sent in the MR's tunnel. =20 Vidya=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, May 10, 2007 11:21 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: [nemo] RE: [Mip6] The use of GRE >=20 > Sri,=20 >=20 > > > > > > > > We dont have to justify this just for PMIP. Its just=20 > another > > > consumer, like NEMO. IMO, having a thin=20 > header, always helps, > > > follows the conventional way of=20 > tagging.=20 > > > > > > =3D> My problem here is that you're not giving me any=20 > concrete > > reasons for a > > use case. > > > Just saying "always helps" doesn't make me understand >=20 > > something new. There > > is only two IP versions today and=20 > this is not going to change > > till you and I > > retire,=20 > so I don't find this flexibility argument realistic.=20 > > > > > > > > > GRE header is applicable when flows from multiple nodes=20 > are carried > in the same tunnel. That's not the case for=20 > 3775 MN flows, but indeed > is the case for 3963. The GRE=20 > header has the proper semantics that > allows tunnel peers=20 > to process properly. The seq number in the header > is=20 > useful when carrying real time traffic. Is this not a > good reason ? >=20 > =3D> This is a classic example of hacks that lingered for such=20 > long time that it grew on people and they thought it's just=20 > the "normal" way of doing things.=20 > I think your arguments above are quite confused about GRE.=20 > It's like the very common arguments about NATs being good for=20 > security.=20 > The need for another abstraction layer for tunnelling was=20 > only to support virtual routing, especially for environments=20 > that conntain overlapping IPv4 addresses.=20 >=20 > Everything else you talk about above is available in IP and=20 > transport headers; and I won't even get into QoS for IP=20 > flows. You seem to think that this is a special case for nemo=20 > because there can be "many flows", which is not the case in a=20 > 3775 MN. This is clearly a confused view of things because a=20 > MN can of course generate many flows, from different=20 > addresses ....etc ....sigh=20 >=20 > > Now, if you say there is no GRE tunneling for MIP6, off=20 > course, thats > where I say, there is a chance we will=20 > introduce GRE tunnel mode > for NEMO use cases in mind,=20 > learnt from the experience of supporting > NEMOv4=20 > deployments and applications.=20 >=20 > =3D> I think I've said enough on this. I don't think I can add=20 > any more. I honestly think what you're listing above is=20 > either confused or a case of you wanting everyone else to fit=20 > some idea in your mind, which we don't know.=20 >=20 >=20 >=20 > Sure, supporting GRE mode helps > > PMIP as well, I agree, if we apply it there. Second=20 > reason, I give > is the convention that has been followed in=20 > all protocol designs so > far, of prev header identifying=20 > the next header. No protocol > is mucking > around in the=20 > payloads to determine the type.=20 >=20 > =3D> Mucking around? There is a very well known encoding=20 > mechanism called TLV where you have to inspect the first byte=20 > to know the type of information following it. I don't think=20 > that's referred to as mucking around, at least not in specs.. ;0 >=20 > enuff said from me. > Hesham >=20 > Are these not good > > reasons ? Do they outweigh the 4 byte saving ? Again, this=20 > is my > opinion. We can let others comment on this. > > > > > > Sri > >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Fri May 11 06:34:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSSA-0001hv-OJ; Fri, 11 May 2007 06:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSS8-0001b4-QS; Fri, 11 May 2007 06:34:24 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSS7-0002m8-Ie; Fri, 11 May 2007 06:34:24 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 65A5817C56; Fri, 11 May 2007 12:34:22 +0200 (CEST) Message-ID: <464446AD.3020302@gmail.com> Date: Fri, 11 May 2007 12:34:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> In-Reply-To: <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri Gundavelli wrote: >> I am fine with 4 bytes if there is strong reason for that, >> however I want to see what kind of additional payloads is >> considered in the future. > > Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO. > Will be useful. Sri - for NEMO, I don't understand. Implementations of MIP6 and NEMOv6 today don't use GRE, neither GRE keys; NEMOv6 implementations don't need GRE. Alex From nemo-bounces@ietf.org Fri May 11 06:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSUk-0003oG-JG; Fri, 11 May 2007 06:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSUj-0003nn-Kc; Fri, 11 May 2007 06:37:05 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSUi-00036u-Bv; Fri, 11 May 2007 06:37:05 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 8EE015478; Fri, 11 May 2007 12:37:02 +0200 (CEST) Message-ID: <4644474E.9080805@gmail.com> Date: Fri, 11 May 2007 12:37:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 References: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> <014701c7937e$6e6a2180$d4f6200a@amer.cisco.com> In-Reply-To: <014701c7937e$6e6a2180$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri Gundavelli wrote: > Hi Hesham: > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Thursday, May 10, 2007 7:28 PM >> To: 'Sri Gundavelli' >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' >> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to >> close issue 93 >> >> >> >> > Agree, may not be useful for a pure MIP6 node, as the mode >> > is in CCOA mode. But, if you enable NEMO, we need more >> > flexibility on the marking of the MNP flows that go in the >> > tunnel. >> >> => Could you elaborate on the nemo aspect you mention above? I don't >> understand why nemo is helped by this? >> > > We have some use cases where we use the GRE key to tag > certain MNP flows and the tunnel peers use these keys as > a form of a selector for differential treatment. Its a > color code. The seq number and key fields in the GRE header > are used. So support for carrying the GRE header over UDP > will be possible with the TLV header. Errr... this is too long and complicated and... undocumented? What is that use case more exactly? We can say that we 'tag' the MNP (Mobile Network Prefix) by the Home Address (not by the GRE key). You seem to mention UDP - do you mean that DS-MIPv6 (and not NEMOv6) needs GRE? Alex From nemo-bounces@ietf.org Fri May 11 06:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSeK-0001cf-DU; Fri, 11 May 2007 06:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSeI-0001cC-Vs; Fri, 11 May 2007 06:46:58 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSeH-00051H-JN; Fri, 11 May 2007 06:46:58 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 971B4182B0; Fri, 11 May 2007 12:46:56 +0200 (CEST) Message-ID: <464449A0.6000502@gmail.com> Date: Fri, 11 May 2007 12:46:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> In-Reply-To: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri Gundavelli wrote: > > >>>> >>> >>> We dont have to justify this just for PMIP. Its just another >>> consumer, like NEMO. IMO, having a thin header, always helps, >>> follows the conventional way of tagging. >> >> => My problem here is that you're not giving me any concrete >> reasons for a use case. Just saying "always helps" doesn't make me >> understand something new. There is only two IP versions today and >> this is not going to change till you and I retire, so I don't find >> this flexibility argument realistic. >> > > > GRE header is applicable when flows from multiple nodes are carried > in the same tunnel. That's not the case for 3775 MN flows, but indeed > is the case for 3963. The GRE header has the proper semantics that > allows tunnel peers to process properly Current implementations of NEMOv6 don't use GRE header and manage to distinguish the flows from different LFNs through the same MR. I don't know what is meant by 'same tunnel'. The tunnel from MR to HA has src MR's CoA and dst HA and inner is src LFN's address and dst CN. BAsed on that the HA receiving a encapsulated packet from LFN can very easily distinguish the flows. No need of GRE. > The seq number in the header is useful when carrying real time > traffic. But real-time protocols have their own mechanisms with sequence numbers no? Why an intermediary layer between network and transport when transport does it already. > Is this not a good reason ? Now, if you say there is no GRE tunneling > for MIP6, off course, thats where I say, there is a chance we will > introduce GRE tunnel mode for NEMO use cases in mind, learnt from the > experience of supporting NEMOv4 deployments and applications. _Some_ NEMOv4 deployments don't need GRE tunnels either. NEMOv4 implementations rely on MIP4 and MIP4 has three ways of encapsulating, only one them being GRE (the two others are IP-IP and UDP). Some NEMOv4 deployments don't need GRE and they work. > Sure, supporting GRE mode helps PMIP as well, I agree, if we apply it > there. Second reason, I give is the convention that has been > followed in all protocol designs so far, of prev header identifying > the next header. No protocol is mucking around in the payloads to > determine the type. Are these not good reasons ? Do they outweigh the > 4 byte saving ? Again, this is my opinion. We can let others comment > on this. Yes, I comment: I don't see the necessity of GRE in MIP6 at all, and probably _some_ necessity in MIP4 (but MIP4 can do without GRE). Alex From nemo-bounces@ietf.org Fri May 11 08:52:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUbs-0006JI-KT; Fri, 11 May 2007 08:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUbq-0006Im-5O; Fri, 11 May 2007 08:52:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUbo-0005O9-Qr; Fri, 11 May 2007 08:52:34 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4BCqVZS004975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 May 2007 05:52:32 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4BCqVlr023596; Fri, 11 May 2007 05:52:31 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 05:52:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 May 2007 05:53:02 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4579F25@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiACEBSSA References: From: "Tsirtsis, George" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 11 May 2007 12:52:30.0939 (UTC) FILETIME=[3CB382B0:01C793CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I support Option 1. (BTW, Option 4 does not work as far as I can tell) Please see justification below... -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Tuesday, May 08, 2007 10:16 PM To: Mobile IPv6 Mailing List; nemo@ietf.org Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 ... Choices are: 1. Parse the protocol header following the UDP header GT> This makes sense to me. It is simple, efficient and it is already defined in the draft. 2. Reserve a UDP port for each protocol header (i.e one UDP port for IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) GT> While this is a reasonable alternative, I have not heard a convincing argument to warrant a change from what the draft already defines (i.e., option 1 above). 3. One reserved UDP port and a DS-MIP6 "tunnel type message" GT> This seems wasteful and unnecessary, given (1 and 2) 4. Encapsulated protocol header type is indicated in the BU message GT> This does not seem to work at all. DSMIPv6 can register IPv4 and IPv6 addresses at the same time. This means that on a packet by packet basis the header encapsulated over UDP can change from IPv4 to IPv6 and back. Signaling one or the other in the BU (outbound indication) is clearly not sufficient and so the indication has to be inbound with the data. Regards George From nemo-bounces@ietf.org Fri May 11 15:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb7l-0000n0-Em; Fri, 11 May 2007 15:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb7k-0000ms-75; Fri, 11 May 2007 15:49:56 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmb7h-0001np-Mj; Fri, 11 May 2007 15:49:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BJngKi024650; Fri, 11 May 2007 22:49:47 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 22:49:44 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 14:49:10 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2007 19:49:09 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 11 May 2007 14:49:10 -0500 From: Basavaraj Patil To: ext Hesham Soliman , Mobile IPv6 Mailing List , Message-ID: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/YAEg5cQAAfOR18 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 May 2007 19:49:10.0404 (UTC) FILETIME=[718B2440:01C79405] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [nemo] Re: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hesham, On 5/11/07 12:15 AM, "ext Hesham Soliman" wrote: > > >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>> >>> => This is what the issue suggested but the additional 4 bytes are >>> redundant. >> >> So are you okay with using the tunnel type message as has >> been done in >> RFC3519? Not sure what you are implying by saying that the 4 >> bytes are >> redundant in this context. > > => I meant that they are redundant because they have no justification > for the operation of the spec. The rationale for the suggestion was that > it was not really possible (or difficult) to tell whether the following > packet was IPv4 or IPv6 if the implementation is in user space; and that > it was diffcult to know the packet length. However, after we discussed > this, it turned out that none of these issues are true, so I don't see > why we need to add another 4 bytes to every packet. Whether you view it from an implementation perspective or from protocol design perspective, does it not make sense to have the header indicate the type of header or encapsulation that exists following the parsing of a header? It is a matter of processing ease and clarity of the encapsulated packet type vs the overhead of 4 bytes on every packet. > >>> I think option 1 is the right option. There is no reason >>> given for a change. >> >> Sure... If the encapsulated packets are only IPv4 or IPv6, >> you could parse >> the version field and figure out the encapsulated packet >> type. And as you >> have said on the list in another email, is there a need for >> encapsulating >> any other type of packets between the MN and HA in UDP? I >> think this is an >> unknown. GRE has been mentioned, but I agree that it is not generally >> between an MN and HA. I don't know if you have thought about >> this option >> from the NEMO perspective as well. After all this I-D is >> intended to address >> hosts and mobile routers. > > => Sure, if there is something specific for nemo then we have to address > it. I still don't know what that is though. I'd appreciate it if someone > can explain it. > >> And the other thing is if you want >> to have some >> flexibility by introducing the 4 byte header to explicitly >> indicate the >> encapsulated packet type (akin to RFC3519) >> >> Some explicit reasons for why in the case of MIP6/NEMO would >> we want the 4 >> byte header to indicate the encapsulated packet type would be good. >> > > => Yes. > >> Reasons I have heard so far: >> 1. PMIP6 relies on DS-MIP6 for IPv4 support and hence >> encapsulation of >> packets other than IPv4/6 (eg. GRE) should be possible in >> which case the >> header would be useful > > => I heard that too, but I don't know why we should add more overhead > for every host and router just so PMIP might use GRE, unless we want to > make MIP look like it's more wasteful. Also, I don't understand why GRE > has to follow UDP and not run after the IP header? I need to re-read GRE > to see if that's possible. Okay.. > >> 2. Flexibility for future use Is the flexibility argument worth considering? Design the protocol with hooks for allowing it to be used in the case there exists encapsulation of packet types other than v4/v6 in the future... >> 3. Reuse 3519 (don't know if this was mentioned) > > => what do you mean by "reuse 3519"? You mean "make it look like 3519"? > That's not a reason though is it? Agree that its not a good reason. What I was implying was that we could learn from the 3519 experience and adopt a mechanism that has worked well. -Raj > > Hesham > > > From nemo-bounces@ietf.org Fri May 11 21:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgej-0003c3-6c; Fri, 11 May 2007 21:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgeh-0003ba-Gr; Fri, 11 May 2007 21:44:19 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmgeh-00033n-0u; Fri, 11 May 2007 21:44:19 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070512014416.GBZI14178.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Sat, 12 May 2007 01:44:16 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06sl.mx.bigpond.com with ESMTP id <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005>; Sat, 12 May 2007 01:44:15 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Date: Sat, 12 May 2007 11:44:12 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/YAEg5cQAAfOR18AAvywfA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj, I think there is some misunderstanding on this issue. Some people seem to think that there is no UDP port already allocated. I urge everyone to read the draft. Some answers to your comments inline: > > Whether you view it from an implementation perspective or > from protocol > design perspective, does it not make sense to have the > header indicate the > type of header or encapsulation that exists following the > parsing of a > header? => It certainly makes sense to to have a clear indication of the order of headers to the receiver. There are two ways of doing that: 1. Just define the format so that UDP is followed by IP (v4 or v6). This is effectively option 1 in your email. 2. Have a generic TLV to indicate the type of the header following UDP. This is effectively option 3. Honestly, the other two options are non-options, especially given George's email about option 4. The question is: when do you need 2) above? You obviously need it if there are many different things that can follow UDP and cannot all be parsed by simply reading the first byte. But this is not the case here because it's always IP. Now, I sent a separate email indicating that if someone wants to use GRE for PMIP reasons they can add the GRE header after IP and keep it transpared to the whole packet. So I don't see a reason for this "generic" header as flexible as it sounds, such flexibility is not needed. It is a matter of processing ease and clarity of the > encapsulated > packet type vs the overhead of 4 bytes on every packet. => The clarity is always there. I don't think the new header brings any thing new, it's only clearer on paper, an implementer would see no difference. > >> 2. Flexibility for future use > > Is the flexibility argument worth considering? Design the > protocol with > hooks for allowing it to be used in the case there exists > encapsulation of > packet types other than v4/v6 in the future... => Like I said, in general it sounds nice, but practically I don't see the need. There is a lot of nice and flexible things we can add but they're also wasteful by nature. I prefer to add things when needed. > > >> 3. Reuse 3519 (don't know if this was mentioned) > > > > => what do you mean by "reuse 3519"? You mean "make it > look like 3519"? > > That's not a reason though is it? > > Agree that its not a good reason. What I was implying was > that we could > learn from the 3519 experience and adopt a mechanism that > has worked well. => Ok. But this is not rocket science :) We know that either mechanism will work fine, but one of them will be 4 bytes heavier :) Hesham > > -Raj > > > > > Hesham > > > > > > > > From nemo-bounces@ietf.org Sat May 12 11:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmtiC-0000tb-R2; Sat, 12 May 2007 11:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmtiB-0000sj-CL; Sat, 12 May 2007 11:40:47 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hmtgh-0008Sd-1g; Sat, 12 May 2007 11:39:16 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1178984354!16033391!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29080 invoked from network); 12 May 2007 15:39:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 12 May 2007 15:39:14 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4CFdD2M004681; Sat, 12 May 2007 08:39:14 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4CFdDf5019476; Sat, 12 May 2007 10:39:13 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-50.corp.mot.com [10.169.4.50]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4CFdAOu019469; Sat, 12 May 2007 10:39:11 -0500 (CDT) Message-ID: <4645DF9D.4050005@gmail.com> Date: Sat, 12 May 2007 17:39:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman References: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> In-Reply-To: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Basavaraj Patil' Subject: [nemo] Re: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hesham Soliman wrote: [...] > => The clarity is always there. I don't think the new header brings > any thing new, it's only clearer on paper, an implementer would see > no difference. Hey, I agree with Hesham :-) It is sufficient to say in spec that the payload of the UDP packet is an IP packet that needs to be delivered back to the IP stack. This kind of behaviour is common in tunnelling implementations. If someone wants to write code about this, the pseudocode looks like this: void recv_packet (nb) { if (portnumber == DS-MIPv6) ip_input (nb - UDP_header) else udp_input (); return; } whereas the function with an intermediary layer would look like this: void recv_packet (nb { if (portnumber == DS-MIPv6) { parse_after_udp (nb); if (thin-layer says there's IP packet) ip_input (nb - UDP_header - thin-layer); else udp_input (); } return; } Remark more code (not only more headers). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Sat May 12 12:16:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuGi-0006si-PY; Sat, 12 May 2007 12:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuGg-0006rv-Kl; Sat, 12 May 2007 12:16:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmuGg-00016r-4Z; Sat, 12 May 2007 12:16:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 May 2007 09:16:25 -0700 X-IronPort-AV: i="4.14,526,1170662400"; d="scan'208"; a="148131663:sNHT57432762" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4CGGPrf009676; Sat, 12 May 2007 09:16:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4CGGPaI001194; Sat, 12 May 2007 16:16:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 May 2007 09:16:24 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 May 2007 09:16:24 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , "'Hesham Soliman'" References: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> <4645DF9D.4050005@gmail.com> Date: Sat, 12 May 2007 09:16:24 -0700 Message-ID: <021c01c794b0$e2d42f60$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceUrBAsuOzsZrTFSLWTxTlPAe8REgAAfMaw In-Reply-To: <4645DF9D.4050005@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 12 May 2007 16:16:24.0606 (UTC) FILETIME=[E2F2B3E0:01C794B0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2414; t=1178986585; x=1179850585; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20call=20to=20close=2 0issue=2093 |Sender:=20; bh=3u7E6uOKaKe16jZ+UE/0cdJBORoz22FhrPbkoVaiHfc=; b=wiRDt8rvkM8TnADfeAAbc0LwfPzwGly6qW9Cnwo3Uwf4aHPKMumSOmr7XlWszAleVLz4pxiE rUfJod6djl187PIdXPY/iljrk7a2x5NV9B/LplDm3PoAL9ZRjsqA3mZB; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex: > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Saturday, May 12, 2007 8:39 AM > To: Hesham Soliman > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > Hey, I agree with Hesham :-) > > It is sufficient to say in spec that the payload of the UDP > packet is an > IP packet that needs to be delivered back to the IP stack. > This kind of > behaviour is common in tunnelling implementations. If > someone wants to > write code about this, the pseudocode looks like this: > > void > recv_packet (nb) > { > if (portnumber == DS-MIPv6) > ip_input (nb - UDP_header) > else > udp_input (); > return; > } > > whereas the function with an intermediary layer would look like this: > > void > recv_packet (nb > { > if (portnumber == DS-MIPv6) > { > parse_after_udp (nb); > if (thin-layer says there's IP packet) > ip_input (nb - UDP_header - thin-layer); > else > udp_input (); > } > return; > } > > Remark more code (not only more headers). 1 line of code is more code, for checking the type of the message, rather assuming its an IP packet ? Is this argument right ? Also, your psueo code is assuming in_input is handling both versions of the packet. In most implementations, the handlers are different. So, on the extra code you are talking about, you have to check either the type field of the TLV header or the 1st byte in the payload any case. How do you do the error handling for dropping 1st byte that is not IPv4 or IPv6. So, where is the extra code ? For one last time, GRE tunneling is widely used for the semantics it provides, GRE key field, seq number fields etc. MIP4 support GRE and IPIP for a reason. We need GRE for many reasons and also for NAT traversal. 3519 supports the same model. Instead of closing the doors and arguing on the use case, why cant this simple hook be provided and be bit more flexible. Leaving this 4-byte TLV header, allows us to add keepalive message, GRE header or some other tunneling header. What is the cost ? 1 or 0 lines of handling code ? 4-bytes in the packet ? Are we sending Max MTU packets ? In wireless tx, does it even matter ? Why cant we just follow 3519 convention ? Sri From nemo-bounces@ietf.org Sat May 12 16:40:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyNf-00066g-Qi; Sat, 12 May 2007 16:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyNe-00066O-MS; Sat, 12 May 2007 16:39:54 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmyNe-0004Mu-AN; Sat, 12 May 2007 16:39:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1179002392!9758035!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 15956 invoked from network); 12 May 2007 20:39:53 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-15.tower-128.messagelabs.com with SMTP; 12 May 2007 20:39:53 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l4CKdqZ9028627; Sat, 12 May 2007 15:39:52 -0500 (CDT) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l4CKdpmB025067; Sat, 12 May 2007 15:39:51 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.155]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l4CKdm3Y025058; Sat, 12 May 2007 15:39:49 -0500 (CDT) Message-ID: <46462613.8070303@gmail.com> Date: Sat, 12 May 2007 22:39:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli References: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> <4645DF9D.4050005@gmail.com> <021c01c794b0$e2d42f60$d4f6200a@amer.cisco.com> In-Reply-To: <021c01c794b0$e2d42f60$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Alexandru Petrescu' Subject: [nemo] Re: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri Gundavelli wrote: >> Hey, I agree with Hesham :-) >> >> It is sufficient to say in spec that the payload of the UDP packet >> is an IP packet that needs to be delivered back to the IP stack. >> This kind of behaviour is common in tunnelling implementations. If >> someone wants to write code about this, the pseudocode looks like >> this: >> >> void recv_packet (nb) { if (portnumber == DS-MIPv6) ip_input (nb - >> UDP_header) else udp_input (); return; } >> >> whereas the function with an intermediary layer would look like >> this: >> >> void recv_packet (nb { if (portnumber == DS-MIPv6) { >> parse_after_udp (nb); if (thin-layer says there's IP packet) >> ip_input (nb - UDP_header - thin-layer); else udp_input (); } >> return; } >> >> Remark more code (not only more headers). > > 1 line of code is more code, for checking the type of the message, > rather assuming its an IP packet ? Is this argument right ? We can go into compilation details to find out which kinds of lines take the more time to execute (and it's actually the 'if's). > Also, your psueo code is assuming in_input is handling both versions > of the packet. In most implementations, the handlers are different. Right... I meant generic. > So, on the extra code you are talking about, you have to check either > the type field of the TLV header or the 1st byte in the payload any > case. How do you do the error handling for dropping 1st byte that is > not IPv4 or IPv6. So, where is the extra code ? Ok... it was generic and pseudo. Everything can be implemented. We better discuss protocol. > For one last time, GRE tunneling is widely used for the semantics it > provides, GRE key field, seq number fields etc. MIP4 support GRE and > IPIP for a reason. Do you agree MIP4 can work without GRE? I have an implementation that does. > We need GRE for many reasons and also for NAT traversal. 3519 > supports the same model. 3519 supports both IP-in-UDP and GRE-in-UDP tunnelling. An implementer has the choice to implement only one of them and it will work fine. Proposing GRE to DS-MIPv6 is an invitation to interoperability issues (what if my MR does GRE-in-UDP) but your HA only does IP-in-UDP). Do we want to open the door to new interoperability issues by allowing GRE as an option? > Instead of closing the doors and arguing on the use case, why cant > this simple hook be provided and be bit more flexible. Leaving this > 4-byte TLV header, allows us to add keepalive message, Keepalive message can be done as a Mobile IP message type extension, doesn't need to be a new TLV or GRE. > GRE header or some other tunneling header. What is the cost ? Ok, let's talk cost in terms of interoperability, not lines of code/memory/bits on wire. I think there is a significant risk in adding GRE as an option to DS-MIPv6, in terms of interoperability. Alex > 1 or 0 lines of handling code ? 4-bytes in the packet ? Are we > sending Max MTU packets ? In wireless tx, does it even matter ? Why > cant we just follow 3519 convention ? > > Sri > > > > > > > > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Mon May 14 10:05:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbAY-00042y-6g; Mon, 14 May 2007 10:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbAW-00040B-6g; Mon, 14 May 2007 10:04:56 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbAV-0000rM-Pu; Mon, 14 May 2007 10:04:56 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4EE4pLo010930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2007 07:04:52 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4EE4oKf025887; Mon, 14 May 2007 07:04:51 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 07:04:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2007 07:04:27 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> In-Reply-To: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzA= References: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> <016001c7938c$d6695400$d4f6200a@amer.cisco.com> From: "Tsirtsis, George" To: "Sri Gundavelli" , "Hesham Soliman" , , X-OriginalArrivalTime: 14 May 2007 14:04:50.0494 (UTC) FILETIME=[D6844DE0:01C79630] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, I have been trying to make sense of this discussion. After re-reading the whole thread I think we may be able to progress if we answer the following question: QUESTION: Does this group agree that GRE encapsulation needs to be supported in MIPv6? If the answer is "NO", then using the already defined UDP port and the IP version field to demux IPv4/IPv6 packets as already defined in DSMIPv6 is absolutely fine and there is no reason to change it. If the answer is "YES", then we have to consider the following: It is clear that the IP version field can not demux GRE. In that case: a) Leave GRE out of DSMIPv6 draft (which uses IP version field for demuxing). People interested in GRE should write up a draft defining how GRE is used in MIPv6. This is likely to result in a GRE specific method of encapsulation over UDP. This is likely to involve reservation of one more UDP port and the definition of a small pseudo-header as proposed by Sri and others. b) Be proactive and adopt the pseudo-header for all encapsulations. This would mean that DSMIPv6 draft is changed to indicate that over the reserved UDP port we add the TLV (or whatever structure) which indicates what the next header is i.e., IPv4, IPv6, GRE. =20 Personally, I am not a big fun of supporting GRE encapsulation for MIPv6. The reason is that in IPv6 we do not have (and must never have) to deal with overlapping address spaces (the main use of GRE tunneling in MIPv4).=20 Also note that even if we do decide to use the IP version field for demuxing now, there is nothing that prevents GRE encapsulation to be defined later, as indicated by (a) above, assuming that GRE support becomes necessary. Yes, then implementation will have to deal with two way of demuxing similar information but it is not the end of the world and it reduces the overhead (albeit not much) in the typical case. I hope this helps. Regards George -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Friday, May 11, 2007 6:26 AM To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org Subject: RE: [Mip6] The use of GRE =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, May 10, 2007 10:20 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] The use of GRE >=20 > Hi all,=20 >=20 > This concensus call on issue 93 made me a bit confused about=20 > the use of GRE. > I have a simple question:=20 >=20 > Why can't people that want to use GRE (for PMIP) run it as follows: >=20 > IP Heahder (proto 47 for GRE) > GRE Header=20 > UDP > ....etc >=20 > Why do we need to add another layer to qualifiers instead of using the > existing allocated numbers? >=20 > It's been a couple of years since I read the GRE spec so I wanted to > understand if this format is a problem >=20 Problem will be with the NAT/PAT device. It wont create NAT bindings from the UDP header encapped in the GRE header. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Mon May 14 10:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbIR-0000Ff-3c; Mon, 14 May 2007 10:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbIP-0000Bp-PJ; Mon, 14 May 2007 10:13:05 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbIP-0002Ba-8B; Mon, 14 May 2007 10:13:05 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070514141259.OQNZ14178.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Mon, 14 May 2007 14:12:59 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06sl.mx.bigpond.com with ESMTP id <20070514141258.UYKB28187.oaamta06sl.mx.bigpond.com@PC20005>; Mon, 14 May 2007 14:12:58 +0000 From: "Hesham Soliman" To: "'Tsirtsis, George'" , "'Sri Gundavelli'" , , Date: Tue, 15 May 2007 00:12:54 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAANz40A== In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070514141258.UYKB28187.oaamta06sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George, That's exactly the point, I just wish this would have been made clear from the start instead of talking around the issue. I see no reason for needing GRE in v6, including MIPv6. Hesham > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Tuesday, May 15, 2007 12:04 AM > To: Sri Gundavelli; Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > Folks, > > I have been trying to make sense of this discussion. After re-reading > the whole thread I think we may be able to progress if we answer the > following question: > > QUESTION: Does this group agree that GRE encapsulation needs to be > supported in MIPv6? > > If the answer is "NO", then using the already defined UDP > port and the > IP version field to demux IPv4/IPv6 packets as already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. > > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In > that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP version field > for demuxing). People interested in GRE should write up a > draft defining > how GRE is used in MIPv6. This is likely to result in a GRE specific > method of encapsulation over UDP. This is likely to involve > reservation > of one more UDP port and the definition of a small pseudo-header as > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all > encapsulations. This would mean that DSMIPv6 draft is changed to > indicate that over the reserved UDP port we add the TLV (or whatever > structure) which indicates what the next header is i.e., IPv4, IPv6, > GRE. > > > Personally, I am not a big fun of supporting GRE encapsulation for > MIPv6. The reason is that in IPv6 we do not have (and must > never have) > to deal with overlapping address spaces (the main use of GRE > tunneling > in MIPv4). > > Also note that even if we do decide to use the IP version field for > demuxing now, there is nothing that prevents GRE encapsulation to be > defined later, as indicated by (a) above, assuming that GRE support > becomes necessary. Yes, then implementation will have to > deal with two > way of demuxing similar information but it is not the end of > the world > and it reduces the overhead (albeit not much) in the typical case. > > I hope this helps. > Regards > George > > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, May 10, 2007 10:20 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] The use of GRE > > > > Hi all, > > > > This concensus call on issue 93 made me a bit confused about > > the use of GRE. > > I have a simple question: > > > > Why can't people that want to use GRE (for PMIP) run it as follows: > > > > IP Heahder (proto 47 for GRE) > > GRE Header > > UDP > > ....etc > > > > Why do we need to add another layer to qualifiers instead > of using the > > existing allocated numbers? > > > > It's been a couple of years since I read the GRE spec so I > wanted to > > understand if this format is a problem > > > > Problem will be with the NAT/PAT device. It wont create NAT bindings > from the UDP header encapped in the GRE header. > > Sri > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Mon May 14 13:43:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnea1-0002nT-Ki; Mon, 14 May 2007 13:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HneZz-0002nG-K5; Mon, 14 May 2007 13:43:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HneZy-0001QK-9H; Mon, 14 May 2007 13:43:27 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4EHhKug001986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2007 10:43:20 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4EHhJlj019542; Mon, 14 May 2007 10:43:20 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 10:43:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2007 10:42:21 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A096@NAEX16.na.qualcomm.com> In-Reply-To: <02C627D961164445AFBC01BBDD0EC3245526DC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAAZ+oYAAGjFpQ References: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au><016001c7938c$d6695400$d4f6200a@amer.cisco.com> <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <02C627D961164445AFBC01BBDD0EC3245526DC@DEEXC1U01.de.lucent.com> From: "Tsirtsis, George" To: "CASATI, Alessio (Alessio)" , "Sri Gundavelli" , "Hesham Soliman" , , X-OriginalArrivalTime: 14 May 2007 17:43:19.0592 (UTC) FILETIME=[5C25EA80:01C7964F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alessio, This is MIPv6, so I assume every mobile has a unique IPv6 Home Address. I think that (and NAT-traversal) guaranties that even if the same mobile has non-unique IPv4 addresses, routing works. I am not sure why GRE is needed for this....or is it? George -----Original Message----- From: CASATI, Alessio (Alessio) [mailto:acasati@alcatel-lucent.com]=20 Sent: Monday, May 14, 2007 6:13 PM To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; mip6@ietf.org; nemo@ietf.org Subject: RE: [Mip6] The use of GRE =20 *Folks, * *I have been trying to make sense of this discussion. After=20 *re-reading the whole thread I think we may be able to progress=20 *if we answer the following question: This is an excellent idea George! *QUESTION: Does this group agree that GRE encapsulation needs=20 *to be supported in MIPv6? YES *If the answer is "NO", then using the already defined UDP port=20 *and the IP version field to demux IPv4/IPv6 packets as already=20 *defined in *DSMIPv6 is absolutely fine and there is no reason to change it. Is port number sufficient to disambiguate a RFC 1918 "net 10"? (10.0.0.0/8). If not we need to answer Yes to the first question, most likely. Any views? Regards Alessio From nemo-bounces@ietf.org Tue May 15 03:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrBt-0005S5-Pg; Tue, 15 May 2007 03:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrBr-0005Ro-LH; Tue, 15 May 2007 03:11:23 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnrBq-00047S-TH; Tue, 15 May 2007 03:11:23 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 May 2007 09:11:22 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4F7BMTY011027; Tue, 15 May 2007 09:11:22 +0200 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 l4F7BKDR023552; Tue, 15 May 2007 07:11:21 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 09:11:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Mip6] The use of GRE Date: Tue, 15 May 2007 09:11:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MAAA6lwAAMmEb7A= References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> From: "Pascal Thubert \(pthubert\)" To: "Narayanan, Vidya" , "Hesham Soliman" , "Sri Gundavelli \(sgundave\)" , , X-OriginalArrivalTime: 15 May 2007 07:11:20.0843 (UTC) FILETIME=[3D39BDB0:01C796C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6357; t=1179213082; x=1180077082; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=+ahD7txqX32lxbmJP5znk84XDZ+d5tqG/WVpIXhSjDg=; b=AmsepvYzLlu49Cfd4D0MG7Fy7uI6cNCBPGStK0EU4pgR2DKVLlpIwU2Rg51bu/soqWOS94Qj OLptayq596lys1XxtljuRL2ZiRV4246X2nnfe+PeoueDwxFxf6DzM3QH; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vidya I think the discussion started with the idea of making the DSMIP tunnel more open to tunneling *anything*. This could be or have been done separately from DSMIP, for instance at the time of MIP6 or NEMO. If you look at it, all these protocols are tunnel set-up and maintenance protocols, with the HoA as the ID for the tunnel. So why tunnel only IPv6 in there?=20 That was (one of) Hesham's valid point(s) when he started his DS-MIP draft. So now we have support to tunnel IPv4, and we discriminate with protocol type. And the issue comes like is that all we'll ever need? Can't we make that more open for future use? And is this draft the right time for opening up? One question was, which future use?=20 One traditional use is L2 tunneling; if you want your MR to tunnel multiple flows treated as multiple VLANs in the mobile network, you might want to keep the VLANs up to the HA by inserting 802.1Q information, or the whole or compressed Ethernet packet in the MRHA tunnel. The L3 alternative (multiple VRFs) is much more complex to deploy on a MR. So I do agree with the original point that there will be multiple usages for that tunnel. At this point, I feel that we are back to a previous discussion on reverse Routability test: in traditional MIP or NEMO (without SeND) the MR can not be sure of its CoA, and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the right place to solve a problem that was already there? =20 I suspect that we have made some clear room for a number of small drafts that will apply to all MIP, DS-MIP and NEMO, to improve the security of the system or like in this case make it more open to the future. The new drafts will have to cope with existing protocols, including IPv6 in the MIP6 tunnel without GRE which is already a fact of life. My own suggestion is to be ready to receive these drafts as new WG items and carry them out swiftly, but not make a dependency for DS MIP on these discussions, either. DS-MIP has been pretty stable for a while, and the recent changes that were discussed (like the mapped CoA) were more on the religious side than fixing practical problems.=20 Pascal >-----Original Message----- >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >Sent: Friday, May 11, 2007 8:38 AM >To: Hesham Soliman; Sri Gundavelli (sgundave); mip6@ietf.org; nemo@ietf.org >Subject: RE: [nemo] RE: [Mip6] The use of GRE > >I'm confused by this thread - could someone explain the role of GRE for >NEMO? From everything I've read so far on this thread, I'm with Hesham >here - I don't understand why we need GRE to parse the multiple flows >sent in the MR's tunnel. > >Vidya > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Thursday, May 10, 2007 11:21 PM >> To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org >> Subject: [nemo] RE: [Mip6] The use of GRE >> >> Sri, >> >> > > > >> > > > We dont have to justify this just for PMIP. Its just >> another > > > consumer, like NEMO. IMO, having a thin >> header, always helps, > > > follows the conventional way of >> tagging. >> > > >> > > =3D> My problem here is that you're not giving me any >> concrete > > reasons for a > > use case. >> > > Just saying "always helps" doesn't make me understand > >> > something new. There > > is only two IP versions today and >> this is not going to change > > till you and I > > retire, >> so I don't find this flexibility argument realistic. >> > > >> > >> > >> > GRE header is applicable when flows from multiple nodes >> are carried > in the same tunnel. That's not the case for >> 3775 MN flows, but indeed > is the case for 3963. The GRE >> header has the proper semantics that > allows tunnel peers >> to process properly. The seq number in the header > is >> useful when carrying real time traffic. Is this not a > good reason ? >> >> =3D> This is a classic example of hacks that lingered for such >> long time that it grew on people and they thought it's just >> the "normal" way of doing things. >> I think your arguments above are quite confused about GRE. >> It's like the very common arguments about NATs being good for >> security. >> The need for another abstraction layer for tunnelling was >> only to support virtual routing, especially for environments >> that conntain overlapping IPv4 addresses. >> >> Everything else you talk about above is available in IP and >> transport headers; and I won't even get into QoS for IP >> flows. You seem to think that this is a special case for nemo >> because there can be "many flows", which is not the case in a >> 3775 MN. This is clearly a confused view of things because a >> MN can of course generate many flows, from different >> addresses ....etc ....sigh >> >> > Now, if you say there is no GRE tunneling for MIP6, off >> course, thats > where I say, there is a chance we will >> introduce GRE tunnel mode > for NEMO use cases in mind, >> learnt from the experience of supporting > NEMOv4 >> deployments and applications. >> >> =3D> I think I've said enough on this. I don't think I can add >> any more. I honestly think what you're listing above is >> either confused or a case of you wanting everyone else to fit >> some idea in your mind, which we don't know. >> >> >> >> Sure, supporting GRE mode helps >> > PMIP as well, I agree, if we apply it there. Second >> reason, I give > is the convention that has been followed in >> all protocol designs so > far, of prev header identifying >> the next header. No protocol > is mucking > around in the >> payloads to determine the type. >> >> =3D> Mucking around? There is a very well known encoding >> mechanism called TLV where you have to inspect the first byte >> to know the type of information following it. I don't think >> that's referred to as mucking around, at least not in specs.. ;0 >> >> enuff said from me. >> Hesham >> >> Are these not good >> > reasons ? Do they outweigh the 4 byte saving ? Again, this >> is my > opinion. We can let others comment on this. >> > >> > >> > Sri >> > >> >> >> > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Tue May 15 06:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnu9R-0000rj-W9; Tue, 15 May 2007 06:21:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnu9Q-0000rH-SR; Tue, 15 May 2007 06:21:04 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnu9P-0007ct-DW; Tue, 15 May 2007 06:21:04 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070515102054.MFYC25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Tue, 15 May 2007 10:20:54 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070515102054.JUIN7523.oaamta05sl.mx.bigpond.com@PC20005>; Tue, 15 May 2007 10:20:54 +0000 From: "Hesham Soliman" To: "'CASATI, Alessio \(Alessio\)'" , "'Tsirtsis, George'" , "'Sri Gundavelli'" , , Date: Tue, 15 May 2007 20:20:46 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <02C627D961164445AFBC01BBDD0EC324552868@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAAZ+oYAAGjFpQACELrbAAAbz04A== Message-Id: <20070515102054.JUIN7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alessio, Regardless of whether the packet is carrying IPv4 or IPv6, there is always a unique identifier in the packet, i.e. the IPv6 address. Overlapping addresses are only an issue when both the outer and inner addresses are private IPv4 addresses. But in this case the question is: where do you use GRE? Is GRE supported on your windows PC or your mobile phone? I don't think it is. So, it is natural to handle that in the network. I.e. from the FA (or v4-only AR) upwards in v4. To answer your question, I do believe GRE is useful for overlapping IP addresses to match a key to a VRF instance, but this is not what we're doing here. Hesham > -----Original Message----- > From: CASATI, Alessio (Alessio) [mailto:acasati@alcatel-lucent.com] > Sent: Tuesday, May 15, 2007 8:06 PM > To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; > mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > *Alessio, > * > *This is MIPv6, so I assume every mobile has a unique IPv6 > Home Address. > > I assume we are addressing the issue of carrying IPv4 in DSMIPv6, not > vanilla MIPv6 operation. > I agree that if there is a globally unique/routable(v6 or v4) address > carried in the "tunnel" then > there is no need of GRE (like there was no need in MIPv4 for that > matter, when a public IP address is used). > However, when private addresses are used, and we want to carry IPv4 > packets with private > Addresses encapsulated in v6 or v4, then the same issue arises as in > MIPv4, that is we need a field to > disambiguate private addresses. Does anyone know why GRE was > introduced > in MIPv4? Was it as a past time or because > there was a requirement? If there was a requirement then, can this go > away just because time has gone by? > I am just curious, as this may help in solving this case. > > (BTW, I hope we are discussing the same thing, since I am not sure > whether you mean this thread to be for vanilla MIPv6 > with v6 only operation, and not for DSMIPv6...) > > > Regards > Alessio > From nemo-bounces@ietf.org Tue May 15 07:44:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvSU-0005m8-8X; Tue, 15 May 2007 07:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvSS-0005lv-1H; Tue, 15 May 2007 07:44:48 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnvSR-0005o5-8k; Tue, 15 May 2007 07:44:48 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070515114444.QGKN25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Tue, 15 May 2007 11:44:44 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070515114444.JBAO15903.oaamta07sl.mx.bigpond.com@PC20005>; Tue, 15 May 2007 11:44:44 +0000 From: "Hesham Soliman" To: "'CASATI, Alessio \(Alessio\)'" , "'Tsirtsis, George'" , "'Sri Gundavelli'" , , Date: Tue, 15 May 2007 21:44:36 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <02C627D961164445AFBC01BBDD0EC3245528C4@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAAZ+oYAAGjFpQACELrbAAAbz04AAAQQfgAAGqCVA= Message-Id: <20070515114444.JBAO15903.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > I do agree that the main domain of application is PMIPv6 and this VRF > instance case you mention. > Is it the case PIMIPv6 support for v4 derives from DSMIPv6, then? => I don't know that it's applicable to the same scenarios. NETLMM assumed that v6 support is available in the client (AR), otherwise it's very strange to not design PMIPv4 :). Also, there is an assumption of the use of the MN_ID, which is unique. So one could either tag packets with the MN_ID or use GRE. Now, you could use GRE directly after the IP header as I suggested before. If all of that is insufficient (and I don't know why that would be the case) then, as already mentioned by George and Pascal, NETLMM can decide to do its extensions to support GRE *after* the UDP header. But there is no reason for us to mandate this feature in this spec when we clearly don't need it. It makes more sense to extend the spec for those specific cases that need it; *if* they need it. > > On support of GRE at MN, I am not sure whether concurrent access to 2 > IPv4 nets sharing the same HA address (so supported via 2 > VRFs on same > router) and with overlapping IP addresses should be > considered, as part > of use cases. > But if it was, then the case for a mux field in DSMIP at MN > should also > be assessed, as u rightly point out. => The scenario was not considered, but I don't think considering that scenario would automatically imply GRE from the host. If an ISP hosting an HA uses overlapping addresses and assumes such overlap in visited networks then I can't see how it would always rely on the host to do the job. In fixed (and mobile AFAIK) networks this scenario may happen in a wholesale/retail type split (unlikely in the fixed case though), in which case the tunnel back to the HA must be done by the visited network anyway. So I don't think there is an automatic relationship between where the tunnel starts and the existence of overlapping addresses, although I agree that it is a possible option. But realistically speaking, this support on the host doesn't exist and as we move to IPv6 it sure won't be needed, so it's strange to consider it in a standard at this stage. As we move away from band aid solutions in private addressing deployments, I hope we can leave those legacy band aids somewhere in the history alleys and avoid bringing them (in terms of development baggage) to new deployments, where they are not needed. Hesham > > Regards > Alessio > > *-----Original Message----- > *From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > *Sent: 15 May 2007 11:21 > *To: CASATI, Alessio (Alessio); 'Tsirtsis, George'; 'Sri > *Gundavelli'; mip6@ietf.org; nemo@ietf.org > *Subject: RE: [Mip6] The use of GRE > * > *Alessio, > * > *Regardless of whether the packet is carrying IPv4 or IPv6, > *there is always a unique identifier in the packet, i.e. the > *IPv6 address. Overlapping addresses are only an issue when > *both the outer and inner addresses are private IPv4 addresses. > *But in this case the question is: where do you use GRE? Is GRE > *supported on your windows PC or your mobile phone? I don't > *think it is. So, it is natural to handle that in the network. > *I.e. from the FA (or v4-only AR) upwards in v4. > * > *To answer your question, I do believe GRE is useful for > *overlapping IP addresses to match a key to a VRF instance, but > *this is not what we're doing here. > * > *Hesham > * > * > * > * > -----Original Message----- > * > From: CASATI, Alessio (Alessio) > [mailto:acasati@alcatel-lucent.com] > * > Sent: Tuesday, May 15, 2007 8:06 PM > * > To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; > > *mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of > *GRE > > *Alessio, > * > *This is MIPv6, so I assume every > *mobile has a unique IPv6 > Home Address. > * > > * > I assume we are addressing the issue of carrying IPv4 in > *DSMIPv6, not > vanilla MIPv6 operation. > * > I agree that if there is a globally unique/routable(v6 or > *v4) address > carried in the "tunnel" then > there is no > *need of GRE (like there was no need in MIPv4 for that > > *matter, when a public IP address is used). > * > However, when private addresses are used, and we want to > *carry IPv4 > packets with private > Addresses encapsulated > *in v6 or v4, then the same issue arises as in > MIPv4, that > *is we need a field to > disambiguate private addresses. Does > *anyone know why GRE was > introduced > in MIPv4? Was it as a > *past time or because > there was a requirement? If there was > *a requirement then, can this go > away just because time > has gone by? > * > I am just curious, as this may help in solving this case. > * > > * > (BTW, I hope we are discussing the same thing, since I am > *not sure > whether you mean this thread to be for vanilla > *MIPv6 > with v6 only operation, and not for DSMIPv6...) > > > * > Regards > Alessio > > * > * > * > From nemo-bounces@ietf.org Tue May 15 07:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvdO-0001Va-0P; Tue, 15 May 2007 07:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvdM-0001VK-7R; Tue, 15 May 2007 07:56:04 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnvdJ-0000JG-TL; Tue, 15 May 2007 07:56:04 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1179230159!16126037!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24890 invoked from network); 15 May 2007 11:55:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 15 May 2007 11:55:59 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4FBtwIt014033; Tue, 15 May 2007 04:55:58 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l4FBtvhO003449; Tue, 15 May 2007 06:55:57 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l4FBts7o003358; Tue, 15 May 2007 06:55:54 -0500 (CDT) Message-ID: <46499FC4.5030506@gmail.com> Date: Tue, 15 May 2007 13:55:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of GRE) References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: nemo@ietf.org, mip6@ietf.org, "Sri Gundavelli \(sgundave\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Vidya > > I think the discussion started with the idea of making the DSMIP > tunnel more open to tunneling *anything*. This could be or have been > done separately from DSMIP, for instance at the time of MIP6 or NEMO. > If you look at it, all these protocols are tunnel set-up and > maintenance protocols, with the HoA as the ID for the tunnel. So why > tunnel only IPv6 in there? > > That was (one of) Hesham's valid point(s) when he started his DS-MIP > draft. So now we have support to tunnel IPv4, and we discriminate > with protocol type. And the issue comes like is that all we'll ever > need? Can't we make that more open for future use? And is this draft > the right time for opening up? > > One question was, which future use? > > One traditional use is L2 tunneling; IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2. This is an architectural mistake: IPv6-MACheader-IPv4-MACheader. I think this is what you are proposing with encapsulating L2 tunnelling in GRE, is it so? > if you want your MR to tunnel multiple flows treated as multiple > VLANs in the mobile network, you might want to keep the VLANs up to > the HA by inserting 802.1Q information, or the whole or compressed > Ethernet packet in the MRHA tunnel. I think it is not a good idea to intersperse an L2 header between two IPv6 base headers. I think it is not good idea to propagate 802.1q information between MR and HA. > The L3 alternative (multiple VRFs) is much more complex to deploy on > a MR. I am not sure what you mean. What is VRF? Also, the L3 alternative (using NEMOv6 base spec and not using L2 headers between base IPv6 headers), is implemented widely. I am not sure why you say it is much more complex. > So I do agree with the original point that there will be multiple > usages for that tunnel. At this point, I feel that we are back to a > previous discussion on reverse Routability test: in traditional MIP > or NEMO (without SeND) the MR can not be sure of its CoA, What do you mean? Do you mean that NEMOv6+SeND is not enough for securing MR ownership of its Care-of Address? And that NEMOv6+GRE encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe Care-of Address? > and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the > right place to solve a problem that was already there? Good question. I agree the security model with DS-MIPv6 and IPv4 Care-of Addresses is different than simple NEMOv6. But I don't see GRE a solution here. Why do you see GRE as a security solution for DS-MIPv6? If HoA is used for identitying IP tunnels then IPsec SAs can link these HoAs, because HoA is an IP address. On the contrary, if GRE key is used to identify tunnels then GRE key can not be used with IPsec SAs. Besides, I don't think there exist protocol selectors for GRE headers. > I suspect that we have made some clear room for a number of small > drafts that will apply to all MIP, DS-MIP and NEMO, to improve the > security of the system or like in this case make it more open to the > future. The new drafts will have to cope with existing protocols, > including IPv6 in the MIP6 tunnel without GRE which is already a fact > of life. I agree MIP6 tunnel without GRE is already a fact of life. But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO. > My own suggestion is to be ready to receive these drafts as new WG > items and carry them out swiftly, but not make a dependency for DS > MIP on these discussions, either. DS-MIP has been pretty stable for a > while, and the recent changes that were discussed (like the mapped > CoA) were more on the religious side than fixing practical problems. Ok, somehow agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Wed May 16 05:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFTi-0001s5-90; Wed, 16 May 2007 05:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFTf-0001r5-VU; Wed, 16 May 2007 05:07:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoFTe-0001QT-DU; Wed, 16 May 2007 05:07:23 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4G97HPB023713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 May 2007 02:07:17 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4G97G4w005603; Wed, 16 May 2007 02:07:17 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 02:07:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 May 2007 02:07:14 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> In-Reply-To: <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAANlAPIAACy75g References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> From: "Tsirtsis, George" To: "Yoshi Tsuda (yotsuda)" , "Sri Gundavelli (sgundave)" , "Hesham Soliman" , , X-OriginalArrivalTime: 16 May 2007 09:07:16.0685 (UTC) FILETIME=[99A4BFD0:01C79799] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: yoshi@cisco.com Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Yoshi, Yes, you are right in that GRE does allow any protocol to go over it, and I was not aware that this use of GRE is common in combination with Mobile IP. I will take your work for it though. If people feel that GRE is indeed important for MIPv6 then, I wonder if it is a good idea to just add a "hook" for GRE support in DSMIPv6 draft. Would it not be better to add GRE encapsulation on MIPv6 more properly, and deal with how it is signaled, how GRE key management is done, how GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other issues?=20 Maybe it is just me but somehow I feel that DSMIPv6 has already become too big and a kind of a kitchen-sink draft for a lot of different things. Regards George -----Original Message----- From: Yoshi Tsuda (yotsuda) [mailto:yotsuda@cisco.com]=20 Sent: Tuesday, May 15, 2007 5:22 PM To: Tsirtsis, George; Sri Gundavelli (sgundave); Hesham Soliman; mip6@ietf.org; nemo@ietf.org Cc: yoshi@cisco.com Subject: RE: [Mip6] The use of GRE Hi George, > Personally, I am not a big fun of supporting GRE=20 > encapsulation for MIPv6. The reason is that in IPv6 we do not=20 > have (and must never have) to deal with overlapping address=20 > spaces (the main use of GRE tunneling in MIPv4).=20 I'm afraid, you might be missing the main use of GRE tunneling in MIPv4. The main use of GRE tunneling in MIPv4 - is NOT to deal with overlapping address spaces, - but to encapsulate any "Protocol type" of packets. In past, when I was implementing various MIPv4 MNs, I was told to implement GRE tunneling by many voices of customers to encapsulate TCP/IPv4, AppleTalk, or whatever protocol suites without worrying about used "Protocol type"s... Thanks. -Yoshi (in Cisco) > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Monday, May 14, 2007 11:04 PM > To: Sri Gundavelli (sgundave); Hesham Soliman; mip6@ietf.org;=20 > nemo@ietf.org > Subject: RE: [Mip6] The use of GRE >=20 > Folks, >=20 > I have been trying to make sense of this discussion. After=20 > re-reading the whole thread I think we may be able to=20 > progress if we answer the following question: >=20 > QUESTION: Does this group agree that GRE encapsulation needs=20 > to be supported in MIPv6? >=20 > If the answer is "NO", then using the already defined UDP=20 > port and the IP version field to demux IPv4/IPv6 packets as=20 > already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. >=20 > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP=20 > version field for demuxing). People interested in GRE should=20 > write up a draft defining how GRE is used in MIPv6. This is=20 > likely to result in a GRE specific method of encapsulation=20 > over UDP. This is likely to involve reservation of one more=20 > UDP port and the definition of a small pseudo-header as=20 > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all=20 > encapsulations. This would mean that DSMIPv6 draft is changed=20 > to indicate that over the reserved UDP port we add the TLV=20 > (or whatever > structure) which indicates what the next header is i.e.,=20 > IPv4, IPv6, GRE. > =20 >=20 > Personally, I am not a big fun of supporting GRE=20 > encapsulation for MIPv6. The reason is that in IPv6 we do not=20 > have (and must never have) to deal with overlapping address=20 > spaces (the main use of GRE tunneling in MIPv4).=20 >=20 > Also note that even if we do decide to use the IP version=20 > field for demuxing now, there is nothing that prevents GRE=20 > encapsulation to be defined later, as indicated by (a) above,=20 > assuming that GRE support becomes necessary. Yes, then=20 > implementation will have to deal with two way of demuxing=20 > similar information but it is not the end of the world and it=20 > reduces the overhead (albeit not much) in the typical case. >=20 > I hope this helps. > Regards > George >=20 >=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE >=20 > =20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, May 10, 2007 10:20 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] The use of GRE > >=20 > > Hi all, > >=20 > > This concensus call on issue 93 made me a bit confused=20 > about the use=20 > > of GRE. > > I have a simple question:=20 > >=20 > > Why can't people that want to use GRE (for PMIP) run it as follows: > >=20 > > IP Heahder (proto 47 for GRE) > > GRE Header > > UDP > > ....etc > >=20 > > Why do we need to add another layer to qualifiers instead=20 > of using the=20 > > existing allocated numbers? > >=20 > > It's been a couple of years since I read the GRE spec so I=20 > wanted to=20 > > understand if this format is a problem > >=20 >=20 > Problem will be with the NAT/PAT device. It wont create NAT=20 > bindings from the UDP header encapped in the GRE header. >=20 > Sri >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Wed May 16 11:39:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLbX-0006F5-NN; Wed, 16 May 2007 11:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLbV-0006ER-Kv; Wed, 16 May 2007 11:39:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLbU-0002fA-BD; Wed, 16 May 2007 11:39:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 May 2007 08:39:51 -0700 X-IronPort-AV: i="4.14,544,1170662400"; d="scan'208"; a="422581328:sNHT449709554" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4GFdpjF023519; Wed, 16 May 2007 08:39:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4GFdkaK025004; Wed, 16 May 2007 15:39:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:39:46 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:39:46 -0700 From: "Sri Gundavelli" To: "'Tsirtsis, George'" , "'Yoshi Tsuda \(yotsuda\)'" , "'Hesham Soliman'" , , References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> Date: Wed, 16 May 2007 08:39:42 -0700 Message-ID: <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAANlAPIAACy75gAC65H4A= In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 16 May 2007 15:39:46.0375 (UTC) FILETIME=[6E5A4570:01C797D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1334; t=1179329991; x=1180193991; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=fnFgPh4SIZVobzeuafGfk27dXv3zKCkU3hS+EoDVNyA=; b=l4Cx7fuyWYftooForVQOixAwPGHeLhlV1MaJ56s5JADdq0RJuRmlidwj7VRLdTriePCv7laI zURE2TQgC07ER1QIfdZzcaS09cTyoSP6WnieCiFqllrXeQw+tZXN49C8; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yoshi@cisco.com Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Wednesday, May 16, 2007 2:07 AM > To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham > Soliman; mip6@ietf.org; nemo@ietf.org > Cc: yoshi@cisco.com > Subject: RE: [Mip6] The use of GRE > > Hi Yoshi, > > Yes, you are right in that GRE does allow any protocol to go over it, > and I was not aware that this use of GRE is common in combination with > Mobile IP. I will take your work for it though. > > If people feel that GRE is indeed important for MIPv6 then, I > wonder if > it is a good idea to just add a "hook" for GRE support in > DSMIPv6 draft. > Would it not be better to add GRE encapsulation on MIPv6 more > properly, > and deal with how it is signaled, how GRE key management is done, how > GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other > issues? > > Maybe it is just me but somehow I feel that DSMIPv6 has already become > too big and a kind of a kitchen-sink draft for a lot of different > things. > Just a clarification. I dont think, the request was for extending DSMIP6 to support GRE. But, rather a request for a 4-byte TLV header that gives the room for adding new extensions, including GRE header. Again, just as in 3519. Regards Sri From nemo-bounces@ietf.org Wed May 16 13:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMzq-00081K-KK; Wed, 16 May 2007 13:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMzp-00080i-Km; Wed, 16 May 2007 13:09:05 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMzp-0005HN-0y; Wed, 16 May 2007 13:09:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4GH8e6B032492; Wed, 16 May 2007 20:08:55 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 20:08:46 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 12:08:44 -0500 Received: from 172.19.244.141 ([172.19.244.141]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 May 2007 17:08:43 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 16 May 2007 12:08:51 -0500 From: Basavaraj Patil To: "ext Tsirtsis, George" , Sri Gundavelli , Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQ== In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 May 2007 17:08:44.0468 (UTC) FILETIME=[DC1A9F40:01C797DC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Subject: [nemo] Re: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Some observations about the discussion so far: 1. If the only packet types encapsulated by the UDP header are IPv4/6 then we do not need the extra 4 byte header. 2. The need for the 4 byte header to spell the encapsulated packet type arises only if we believe GRE or other types of packets may be encapsulated in the tunnel between the MN and HA. Yoshi (at least) has indicated that he has had to implement GRE tunnelling support on the MN. Would help if any others can respond and clarify if tunnelling GRE over IP at the MN is normally done. 3. The 4 byte header in every packet is an overhead. Depending on the link type 4 bytes in every packet can be considered as being wasteful. 4. The need for GRE encapsulation for NEMO is not apparent; I think there was an explicit statement that GRE is not needed for NEMO. Recommendation: The DS-MIP6 I-D has been worked on at length in this WG. Its time to get this published and implementations tested. Proceed with the current model where we only have either IPv4/6 packets being encapsulated between the MN and HA by the UDP header. No additional 4 byte header to be added. When there is a valid justification and need for supporting encapsulation of GRE and/or other packet types, we can revise the specification if needed. Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need to support GRE encapsulation in that context, the Netlmm I-D may extend the DS-MIP6 spec and add the 4 byte header. -Raj On 5/14/07 9:04 AM, "ext Tsirtsis, George" wrote: > Folks, > > I have been trying to make sense of this discussion. After re-reading > the whole thread I think we may be able to progress if we answer the > following question: > > QUESTION: Does this group agree that GRE encapsulation needs to be > supported in MIPv6? > > If the answer is "NO", then using the already defined UDP port and the > IP version field to demux IPv4/IPv6 packets as already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. > > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP version field > for demuxing). People interested in GRE should write up a draft defining > how GRE is used in MIPv6. This is likely to result in a GRE specific > method of encapsulation over UDP. This is likely to involve reservation > of one more UDP port and the definition of a small pseudo-header as > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all > encapsulations. This would mean that DSMIPv6 draft is changed to > indicate that over the reserved UDP port we add the TLV (or whatever > structure) which indicates what the next header is i.e., IPv4, IPv6, > GRE. > > > Personally, I am not a big fun of supporting GRE encapsulation for > MIPv6. The reason is that in IPv6 we do not have (and must never have) > to deal with overlapping address spaces (the main use of GRE tunneling > in MIPv4). > > Also note that even if we do decide to use the IP version field for > demuxing now, there is nothing that prevents GRE encapsulation to be > defined later, as indicated by (a) above, assuming that GRE support > becomes necessary. Yes, then implementation will have to deal with two > way of demuxing similar information but it is not the end of the world > and it reduces the overhead (albeit not much) in the typical case. > > I hope this helps. > Regards > George > > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Thursday, May 10, 2007 10:20 PM >> To: mip6@ietf.org; nemo@ietf.org >> Subject: [Mip6] The use of GRE >> >> Hi all, >> >> This concensus call on issue 93 made me a bit confused about >> the use of GRE. >> I have a simple question: >> >> Why can't people that want to use GRE (for PMIP) run it as follows: >> >> IP Heahder (proto 47 for GRE) >> GRE Header >> UDP >> ....etc >> >> Why do we need to add another layer to qualifiers instead of using the >> existing allocated numbers? >> >> It's been a couple of years since I read the GRE spec so I wanted to >> understand if this format is a problem >> > > Problem will be with the NAT/PAT device. It wont create NAT bindings > from the UDP header encapped in the GRE header. > > Sri > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 From nemo-bounces@ietf.org Wed May 16 13:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNEa-0001T5-Vj; Wed, 16 May 2007 13:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNEZ-0001Sc-3T; Wed, 16 May 2007 13:24:19 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoNEW-0002tl-M5; Wed, 16 May 2007 13:24:19 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HoNEV-0003Hz-6f; Wed, 16 May 2007 19:24:15 +0200 Message-ID: <464B3E3F.5010802@levkowetz.com> Date: Wed, 16 May 2007 19:24:15 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: basavaraj.patil@nsn.com, mip6@ietf.org, nemo@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, Mobile IPv6 Mailing List Subject: [nemo] Re: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org on 2007-05-08 23:16 Basavaraj Patil said the following: ... > Choices are: > 1. Parse the protocol header following the UDP header > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message There has been some clarifications to Basavaraj's original formulation (above), and I agree with the clarifications. I'm responding to the original email to make the tallying simple. I originally thought that I'd find either 1. or 3. equally acceptable, but after the side discussion about GRE and alternative keepalives, I find that despite the small additional overhead of 4 bytes of solution 3., I prefer it because it is somewhat more future-proof. We don't strictly need 3. today, but it provides some freedom for tomorrow when compared with 1. (2. and 4. aren't tempting at all.) The choice was easier in 3519, although not obvious -- at first we thought we could do without the 4-byte overhead there too, but it looks increasingly as if it was a good idea to have the added header in that case. So: I prefer alternative 3. Henrik From nemo-bounces@ietf.org Wed May 16 15:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOrL-0003gR-BG; Wed, 16 May 2007 15:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOrJ-0003g7-C5; Wed, 16 May 2007 15:08:25 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoOrJ-0006Rt-4E; Wed, 16 May 2007 15:08:25 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1179342504!15649673!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28920 invoked from network); 16 May 2007 19:08:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 16 May 2007 19:08:24 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GJ8Nl2021161; Wed, 16 May 2007 12:08:23 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4GJ8NOe026706; Wed, 16 May 2007 14:08:23 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.95]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4GJ8JI1026634; Wed, 16 May 2007 14:08:20 -0500 (CDT) Message-ID: <464B56A2.1010408@gmail.com> Date: Wed, 16 May 2007 21:08:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> In-Reply-To: <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, yoshi@cisco.com, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri Gundavelli wrote: > > >> -----Original Message----- >> From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] >> Sent: Wednesday, May 16, 2007 2:07 AM >> To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham >> Soliman; mip6@ietf.org; nemo@ietf.org >> Cc: yoshi@cisco.com >> Subject: RE: [Mip6] The use of GRE >> >> Hi Yoshi, >> >> Yes, you are right in that GRE does allow any protocol to go over it, >> and I was not aware that this use of GRE is common in combination with >> Mobile IP. I will take your work for it though. >> >> If people feel that GRE is indeed important for MIPv6 then, I >> wonder if >> it is a good idea to just add a "hook" for GRE support in >> DSMIPv6 draft. >> Would it not be better to add GRE encapsulation on MIPv6 more >> properly, >> and deal with how it is signaled, how GRE key management is done, how >> GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other >> issues? >> >> Maybe it is just me but somehow I feel that DSMIPv6 has already become >> too big and a kind of a kitchen-sink draft for a lot of different >> things. >> > > > Just a clarification. I dont think, the request was for extending DSMIP6 > to support GRE. But, rather a request for a 4-byte TLV header that gives > the room for adding new extensions, including GRE header. Again, just as > in 3519. I really don't think 3519 has that TLV more than as an option. Probably it is there because somebody has insisted very hard to get it there. But in general I think it makes no sense at all to have TLVs or GRE between IP headers, or between TCP and UDP headers or anywhere else other than pure and last payload. It makes no sense to carry layer2 header within IP message. Alex > > Regards > Sri > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Wed May 16 15:19:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoP1o-0006tm-6B; Wed, 16 May 2007 15:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoP1m-0006qe-W9; Wed, 16 May 2007 15:19:15 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoP1l-00018e-DM; Wed, 16 May 2007 15:19:14 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1179343152!9947196!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9465 invoked from network); 16 May 2007 19:19:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 16 May 2007 19:19:12 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GJJBmr024281; Wed, 16 May 2007 12:19:12 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l4GJJBSF011296; Wed, 16 May 2007 14:19:11 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.95]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l4GJJ8q3011239; Wed, 16 May 2007 14:19:08 -0500 (CDT) Message-ID: <464B592B.3090405@gmail.com> Date: Wed, 16 May 2007 21:19:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [nemo] Re: [Mip6] The use of GRE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Basavaraj Patil wrote: > Some observations about the discussion so far: > > 1. If the only packet types encapsulated by the UDP header are IPv4/6 then > we do not need the extra 4 byte header. > 2. The need for the 4 byte header to spell the encapsulated packet type > arises only if we believe GRE or other types of packets may be encapsulated > in the tunnel between the MN and HA. Yoshi (at least) has indicated that he > has had to implement GRE tunnelling support on the MN. Would help if any > others can respond and clarify if tunnelling GRE over IP at the MN is > normally done. > 3. The 4 byte header in every packet is an overhead. Depending on the link > type 4 bytes in every packet can be considered as being wasteful. > 4. The need for GRE encapsulation for NEMO is not apparent; I think there > was an explicit statement that GRE is not needed for NEMO. I agree with this 1-4 list, and I think it summarizes well the points discussed so far, thanks. Another need for GRE that was mentioned is security. It is not technically clear either. > Recommendation: > > The DS-MIP6 I-D has been worked on at length in this WG. Its time to get > this published and implementations tested. > > Proceed with the current model where we only have either IPv4/6 packets > being encapsulated between the MN and HA by the UDP header. No additional 4 > byte header to be added. > > When there is a valid justification and need for supporting encapsulation of > GRE and/or other packet types, we can revise the specification if needed. > > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need > to support GRE encapsulation in that context, the Netlmm I-D may extend the > DS-MIP6 spec and add the 4 byte header. Raj, I find it extemely annoying the silence around the actual need for GRE. It is a known fact for anyone following WiMax SDO that WiMax needs GRE. It is also a known fact that several people expressing oppinions on this list are also expressing opinions on WiMax NWG. YEt these people are silent when the question "who needs GRE" is raised. This is very annoying. I understand very well your neutral Chair position and you summarized very well the GRE discussion so far - I appreciate that. But I think it is time to state clearly that GRE is pushed here _only_ because WiMax needs it. Every other technical reason for GRE is completely bogus: security (you didn't mention), NEMO and capacity to carry other than IPv4/IPv6 is pure speculative handwaving. Once we have that statement of interest from WiMax needs about GRE we can deal with it accordingly. Otherwise it looks as if you try to make it look as if it were a typical IETF discussion - it isn't. Alex > > -Raj > > On 5/14/07 9:04 AM, "ext Tsirtsis, George" wrote: > >> Folks, >> >> I have been trying to make sense of this discussion. After re-reading >> the whole thread I think we may be able to progress if we answer the >> following question: >> >> QUESTION: Does this group agree that GRE encapsulation needs to be >> supported in MIPv6? >> >> If the answer is "NO", then using the already defined UDP port and the >> IP version field to demux IPv4/IPv6 packets as already defined in >> DSMIPv6 is absolutely fine and there is no reason to change it. >> >> If the answer is "YES", then we have to consider the following: >> It is clear that the IP version field can not demux GRE. In that case: >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field >> for demuxing). People interested in GRE should write up a draft defining >> how GRE is used in MIPv6. This is likely to result in a GRE specific >> method of encapsulation over UDP. This is likely to involve reservation >> of one more UDP port and the definition of a small pseudo-header as >> proposed by Sri and others. >> b) Be proactive and adopt the pseudo-header for all >> encapsulations. This would mean that DSMIPv6 draft is changed to >> indicate that over the reserved UDP port we add the TLV (or whatever >> structure) which indicates what the next header is i.e., IPv4, IPv6, >> GRE. >> >> >> Personally, I am not a big fun of supporting GRE encapsulation for >> MIPv6. The reason is that in IPv6 we do not have (and must never have) >> to deal with overlapping address spaces (the main use of GRE tunneling >> in MIPv4). >> >> Also note that even if we do decide to use the IP version field for >> demuxing now, there is nothing that prevents GRE encapsulation to be >> defined later, as indicated by (a) above, assuming that GRE support >> becomes necessary. Yes, then implementation will have to deal with two >> way of demuxing similar information but it is not the end of the world >> and it reduces the overhead (albeit not much) in the typical case. >> >> I hope this helps. >> Regards >> George >> >> >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Friday, May 11, 2007 6:26 AM >> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >> Subject: RE: [Mip6] The use of GRE >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>> Sent: Thursday, May 10, 2007 10:20 PM >>> To: mip6@ietf.org; nemo@ietf.org >>> Subject: [Mip6] The use of GRE >>> >>> Hi all, >>> >>> This concensus call on issue 93 made me a bit confused about >>> the use of GRE. >>> I have a simple question: >>> >>> Why can't people that want to use GRE (for PMIP) run it as follows: >>> >>> IP Heahder (proto 47 for GRE) >>> GRE Header >>> UDP >>> ....etc >>> >>> Why do we need to add another layer to qualifiers instead of using the >>> existing allocated numbers? >>> >>> It's been a couple of years since I read the GRE spec so I wanted to >>> understand if this format is a problem >>> >> Problem will be with the NAT/PAT device. It wont create NAT bindings >> from the UDP header encapped in the GRE header. >> >> Sri >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Wed May 16 15:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPYP-0005aW-14; Wed, 16 May 2007 15:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPYO-0005a5-Fs; Wed, 16 May 2007 15:52:56 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoPYF-0004Se-VG; Wed, 16 May 2007 15:52:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4GJqUUW012098; Wed, 16 May 2007 22:52:39 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 22:52:38 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 14:52:18 -0500 Received: from 172.19.244.141 ([172.19.244.141]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 May 2007 19:52:18 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 16 May 2007 14:52:27 -0500 Subject: Re: [nemo] Re: [Mip6] The use of GRE From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceX87rK+RXnlQPmEdyCLAARJNUNiA== In-Reply-To: <464B592B.3090405@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 May 2007 19:52:18.0981 (UTC) FILETIME=[B6027550:01C797F3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex, On 5/16/07 2:19 PM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> Some observations about the discussion so far: >> >> 1. If the only packet types encapsulated by the UDP header are IPv4/6 then >> we do not need the extra 4 byte header. >> 2. The need for the 4 byte header to spell the encapsulated packet type >> arises only if we believe GRE or other types of packets may be encapsulated >> in the tunnel between the MN and HA. Yoshi (at least) has indicated that he >> has had to implement GRE tunnelling support on the MN. Would help if any >> others can respond and clarify if tunnelling GRE over IP at the MN is >> normally done. >> 3. The 4 byte header in every packet is an overhead. Depending on the link >> type 4 bytes in every packet can be considered as being wasteful. >> 4. The need for GRE encapsulation for NEMO is not apparent; I think there >> was an explicit statement that GRE is not needed for NEMO. > > I agree with this 1-4 list, and I think it summarizes well the points > discussed so far, thanks. > > Another need for GRE that was mentioned is security. It is not > technically clear either. I guess I missed the security argument. But as you say, the reasons are not very clear. > >> Recommendation: >> >> The DS-MIP6 I-D has been worked on at length in this WG. Its time to get >> this published and implementations tested. >> >> Proceed with the current model where we only have either IPv4/6 packets >> being encapsulated between the MN and HA by the UDP header. No additional 4 >> byte header to be added. >> >> When there is a valid justification and need for supporting encapsulation of >> GRE and/or other packet types, we can revise the specification if needed. >> >> Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need >> to support GRE encapsulation in that context, the Netlmm I-D may extend the >> DS-MIP6 spec and add the 4 byte header. > > Raj, I find it extemely annoying the silence around the actual need for > GRE. It is a known fact for anyone following WiMax SDO that WiMax needs > GRE. It is also a known fact that several people expressing oppinions > on this list are also expressing opinions on WiMax NWG. I am not sure if that is indeed the case. At least I have not perceived it as such from the current thread. Since I also am involved in WiMAX NWG, I can tell you that this issue of GRE support in DS-MIP6 has never been discussed in that forum. > > YEt these people are silent when the question "who needs GRE" is raised. > > This is very annoying. > > I understand very well your neutral Chair position and you summarized > very well the GRE discussion so far - I appreciate that. > > But I think it is time to state clearly that GRE is pushed here _only_ > because WiMax needs it. Every other technical reason for GRE is > completely bogus: security (you didn't mention), NEMO and capacity to > carry other than IPv4/IPv6 is pure speculative handwaving. > > Once we have that statement of interest from WiMax needs about GRE we > can deal with it accordingly. Otherwise it looks as if you try to make > it look as if it were a typical IETF discussion - it isn't. IMO, the discussion on this topic/thread was not motivated by who needs GRE. It was simply closing an issue that was raised and discussed at the Prague IETF. The argument about GRE arose only as a result of the need for the 4 byte header to indicate the encapsulated packet type. I believe this was a typical WG discussion. You may be reading much more into it than what it is. -Raj > > Alex > > From nemo-bounces@ietf.org Wed May 16 16:53:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQV0-000579-09; Wed, 16 May 2007 16:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQUy-00056h-10; Wed, 16 May 2007 16:53:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoQUw-0004OH-Me; Wed, 16 May 2007 16:53:28 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 May 2007 13:53:26 -0700 X-IronPort-AV: i="4.14,544,1170662400"; d="scan'208"; a="422717068:sNHT49370744" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4GKrPKa014307; Wed, 16 May 2007 13:53:25 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4GKrPV2023508; Wed, 16 May 2007 20:53:25 GMT Date: Wed, 16 May 2007 13:53:25 -0700 (PDT) From: Sri Gundavelli To: Alexandru Petrescu Subject: Re: [nemo] RE: [Mip6] The use of GRE In-Reply-To: <464B56A2.1010408@gmail.com> Message-ID: References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> <464B56A2.1010408@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2655; t=1179348806; x=1180212806; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[nemo]=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=ozDK8EEbkhQf+u4BfbjkYq6hZAayVFenMaa+oSTe6aU=; b=bhlduOoblN5ec5fFu5Bc+WEVz3gx2q1kCEPTDp0RU2u9iRP2uvsd2k4rdv2MJGLl4Ei1RwDC l1NbY35uEc2yBsX92VyTAUD12PP9dsAE80h2en2XD9/jRBzJPM3RZDvc; Authentication-Results: sj-dkim-7; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nemo@ietf.org, yoshi@cisco.com, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Wed, 16 May 2007, Alexandru Petrescu wrote: > Sri Gundavelli wrote: >> >> >> > -----Original Message----- >> > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] Sent: Wednesday, >> > May 16, 2007 2:07 AM >> > To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham Soliman; >> > mip6@ietf.org; nemo@ietf.org >> > Cc: yoshi@cisco.com >> > Subject: RE: [Mip6] The use of GRE >> > >> > Hi Yoshi, >> > >> > Yes, you are right in that GRE does allow any protocol to go over it, >> > and I was not aware that this use of GRE is common in combination with >> > Mobile IP. I will take your work for it though. >> > >> > If people feel that GRE is indeed important for MIPv6 then, I wonder if >> > it is a good idea to just add a "hook" for GRE support in DSMIPv6 >> > draft. >> > Would it not be better to add GRE encapsulation on MIPv6 more properly, >> > and deal with how it is signaled, how GRE key management is done, how >> > GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other >> > issues? >> > >> > Maybe it is just me but somehow I feel that DSMIPv6 has already become >> > too big and a kind of a kitchen-sink draft for a lot of different >> > things. >> > >> >> >> Just a clarification. I dont think, the request was for extending DSMIP6 >> to support GRE. But, rather a request for a 4-byte TLV header that gives >> the room for adding new extensions, including GRE header. Again, just as >> in 3519. > > I really don't think 3519 has that TLV more than as an option. Probably it > is there because somebody has insisted very hard to get it there. > > But in general I think it makes no sense at all to have TLVs or GRE between > IP headers, or between TCP and UDP headers or anywhere else other than pure > and last payload. > Well. it makes sense to me. Gave many reasons that I dont want to repeat here. If you judge things based on your preset notion of how requirements are arriving, its hard for you to get convinced. BTW, there was no comment on any justification based on the security argument. Not sure, how you ended up with that assumption. Also, this requirement is not comming from WiMAX. But, I dont have to prove it to you. If this requirement is indeed comming from WiMax, let it be so. If there is a need, so is it. This is a technical discussion. Judge it based on the merit. Any case, we disagree on this. I gave the reasons why we should add a simple 4-byte TLV header. If the WG is convinced, let it add that. Otherwise, we need to later allocate a special port just for GRE payload. Sri From nemo-bounces@ietf.org Wed May 16 17:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQv9-0007I8-OG; Wed, 16 May 2007 17:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQv8-0007I0-JE; Wed, 16 May 2007 17:20:30 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoQv8-0000lF-9V; Wed, 16 May 2007 17:20:30 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1179350429!13999666!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6393 invoked from network); 16 May 2007 21:20:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 16 May 2007 21:20:29 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GLKSj7025300; Wed, 16 May 2007 14:20:29 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l4GLKRvw019331; Wed, 16 May 2007 16:20:28 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.33]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l4GLKNd8019259; Wed, 16 May 2007 16:20:24 -0500 (CDT) Message-ID: <464B7596.3030806@gmail.com> Date: Wed, 16 May 2007 23:20:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> <464B56A2.1010408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nemo@ietf.org, yoshi@cisco.com, Alexandru Petrescu , mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sri Gundavelli wrote: > > > On Wed, 16 May 2007, Alexandru Petrescu wrote: > >> Sri Gundavelli wrote: >>> >>> >>>> -----Original Message----- From: Tsirtsis, George >>>> [mailto:tsirtsis@qualcomm.com] Sent: >>> Wednesday, > May 16, 2007 2:07 AM >>>> To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham >>> Soliman; > mip6@ietf.org; nemo@ietf.org >>>> Cc: yoshi@cisco.com Subject: RE: [Mip6] The use of GRE >>>>> Hi Yoshi, Yes, you are right in that GRE does allow any >>>>> protocol to go >>> over it, >>>> and I was not aware that this use of GRE is common in >>>> combination >>> with >>>> Mobile IP. I will take your work for it though. >>>>> If people feel that GRE is indeed important for MIPv6 then, I >>>>> >>>>> >>> wonder if >>>> it is a good idea to just add a "hook" for GRE support in >>>> DSMIPv6 draft. Would it not be better to add GRE encapsulation >>>> on MIPv6 more >>> properly, >>>> and deal with how it is signaled, how GRE key management is >>>> done, how GRE tunneling is used over IPv4 or IPv6 tunneling, >>>> and possibly other issues? > > Maybe it is just me but somehow >>>> I feel that DSMIPv6 >>> has already become >>>> too big and a kind of a kitchen-sink draft for a lot of >>>> different things. >>>> >>> >>> >>> Just a clarification. I dont think, the request was for extending >>> DSMIP6 to support GRE. But, rather a request for a 4-byte TLV >>> header that gives the room for adding new extensions, including >>> GRE header. Again, just as in 3519. >> >> I really don't think 3519 has that TLV more than as an option. >> Probably it is there because somebody has insisted very hard to get >> it there. >> >> But in general I think it makes no sense at all to have TLVs or GRE >> between IP headers, or between TCP and UDP headers or anywhere >> else other than pure and last payload. >> > > Well. it makes sense to me. Gave many reasons that I dont want to > repeat here. If you judge things based on your preset notion of how > requirements are arriving, its hard for you to get convinced. > > BTW, there was no comment on any justification based on the security > argument. Not sure, how you ended up with that assumption. I think this is what I read in yestarday Pascal's comment needing GRE for security reasons. Pascal said at http://www1.ietf.org/mail-archive/web/mip6/current/msg06157.html: > So I do agree with the original point that there will be multiple > usages for that [GRE, my note] tunnel. At this point, I feel that we > are back to a previous discussion on reverse Routability test: in > traditional MIP or NEMO (without SeND) the MR can not be sure of its > CoA, and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP > the right place to solve a problem that was already there? Sri said: > Also, this requirement is not comming from WiMAX. But, I dont have to > prove it to you. If this requirement is indeed comming from WiMax, > let it be so. If there is a need, so is it. This is a technical > discussion. Judge it based on the merit. Right... The technical merit of this GRE discussion is utterly senseless, sorry for exaggerating the qualifier. > Any case, we disagree on this. I gave the reasons why we should add a > simple 4-byte TLV header. If the WG is convinced, let it add that. > Otherwise, we need to later allocate a special port just for GRE > payload. Do you agree that DS-MIPv6, MIP6 and NEMO can work ok _without_ that TLV? Do you agree MIP4 can work ok without that TLV? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Wed May 16 17:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR8L-0001B1-25; Wed, 16 May 2007 17:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR8I-0001AJ-P0; Wed, 16 May 2007 17:34:06 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoR8I-0004ko-7Z; Wed, 16 May 2007 17:34:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 May 2007 14:33:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE thread-index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ References: From: "Vijay Devarapalli" To: "Basavaraj Patil" , "ext Tsirtsis, George" , "Sri Gundavelli" , "Hesham Soliman" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Subject: [nemo] RE: [Mip6] The use of GRE X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello Raj, We might actually end up with option 2. I see three reserved=20 UDP ports with DS-MIPv6 already. 1. One UDP port indicating IPv4/IPv6. You parse the IP version field to figure out whether it is IPv4 or IPv6. 2. One UDP port for ESP encapsulation. This happens when you=20 protect DS-MIPv6 traffic with ESP and use UDP encapsulation=20 for NAT traversal. The packet format would be IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4) UDP hdr ESP hdr IPv6 (src=3DMN-IPv6-HoA, dst=3DCN) Payload=20 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. So this is almost option 2. :) Option 2 was one reserved port per protocol that follows the UDP header. Vijay > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, May 16, 2007 10:09 AM > To: ext Tsirtsis, George; Sri Gundavelli; Hesham Soliman;=20 > mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] The use of GRE >=20 >=20 > Some observations about the discussion so far: >=20 > 1. If the only packet types encapsulated by the UDP header=20 > are IPv4/6 then > we do not need the extra 4 byte header. > 2. The need for the 4 byte header to spell the encapsulated=20 > packet type > arises only if we believe GRE or other types of packets may=20 > be encapsulated > in the tunnel between the MN and HA. Yoshi (at least) has=20 > indicated that he > has had to implement GRE tunnelling support on the MN. Would=20 > help if any > others can respond and clarify if tunnelling GRE over IP at the MN is > normally done. > 3. The 4 byte header in every packet is an overhead.=20 > Depending on the link > type 4 bytes in every packet can be considered as being wasteful. > 4. The need for GRE encapsulation for NEMO is not apparent; I=20 > think there > was an explicit statement that GRE is not needed for NEMO. >=20 > Recommendation: >=20 > The DS-MIP6 I-D has been worked on at length in this WG. Its=20 > time to get > this published and implementations tested. >=20 > Proceed with the current model where we only have either=20 > IPv4/6 packets > being encapsulated between the MN and HA by the UDP header.=20 > No additional 4 > byte header to be added. >=20 > When there is a valid justification and need for supporting=20 > encapsulation of > GRE and/or other packet types, we can revise the=20 > specification if needed. >=20 > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and=20 > there is a need > to support GRE encapsulation in that context, the Netlmm I-D=20 > may extend the > DS-MIP6 spec and add the 4 byte header. >=20 > -Raj >=20 > On 5/14/07 9:04 AM, "ext Tsirtsis, George"=20 > wrote: >=20 > > Folks, > >=20 > > I have been trying to make sense of this discussion. After=20 > re-reading > > the whole thread I think we may be able to progress if we answer the > > following question: > >=20 > > QUESTION: Does this group agree that GRE encapsulation needs to be > > supported in MIPv6? > >=20 > > If the answer is "NO", then using the already defined UDP=20 > port and the > > IP version field to demux IPv4/IPv6 packets as already defined in > > DSMIPv6 is absolutely fine and there is no reason to change it. > >=20 > > If the answer is "YES", then we have to consider the following: > > It is clear that the IP version field can not demux GRE. In=20 > that case: > > a) Leave GRE out of DSMIPv6 draft (which uses IP version field > > for demuxing). People interested in GRE should write up a=20 > draft defining > > how GRE is used in MIPv6. This is likely to result in a GRE specific > > method of encapsulation over UDP. This is likely to involve=20 > reservation > > of one more UDP port and the definition of a small pseudo-header as > > proposed by Sri and others. > > b) Be proactive and adopt the pseudo-header for all > > encapsulations. This would mean that DSMIPv6 draft is changed to > > indicate that over the reserved UDP port we add the TLV (or whatever > > structure) which indicates what the next header is i.e., IPv4, IPv6, > > GRE. > > =20 > >=20 > > Personally, I am not a big fun of supporting GRE encapsulation for > > MIPv6. The reason is that in IPv6 we do not have (and must=20 > never have) > > to deal with overlapping address spaces (the main use of=20 > GRE tunneling > > in MIPv4).=20 > >=20 > > Also note that even if we do decide to use the IP version field for > > demuxing now, there is nothing that prevents GRE encapsulation to be > > defined later, as indicated by (a) above, assuming that GRE support > > becomes necessary. Yes, then implementation will have to=20 > deal with two > > way of demuxing similar information but it is not the end=20 > of the world > > and it reduces the overhead (albeit not much) in the typical case. > >=20 > > I hope this helps. > > Regards > > George > >=20 > >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, May 11, 2007 6:26 AM > > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > > Subject: RE: [Mip6] The use of GRE > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > >> Sent: Thursday, May 10, 2007 10:20 PM > >> To: mip6@ietf.org; nemo@ietf.org > >> Subject: [Mip6] The use of GRE > >>=20 > >> Hi all,=20 > >>=20 > >> This concensus call on issue 93 made me a bit confused about > >> the use of GRE. > >> I have a simple question: > >>=20 > >> Why can't people that want to use GRE (for PMIP) run it as follows: > >>=20 > >> IP Heahder (proto 47 for GRE) > >> GRE Header=20 > >> UDP > >> ....etc > >>=20 > >> Why do we need to add another layer to qualifiers instead=20 > of using the > >> existing allocated numbers? > >>=20 > >> It's been a couple of years since I read the GRE spec so I=20 > wanted to > >> understand if this format is a problem > >>=20 > >=20 > > Problem will be with the NAT/PAT device. It wont create NAT bindings > > from the UDP header encapped in the GRE header. > >=20 > > Sri > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Wed May 16 17:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR9c-00026S-IP; Wed, 16 May 2007 17:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR9b-00026K-0f; Wed, 16 May 2007 17:35:27 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoR9a-0004wT-MB; Wed, 16 May 2007 17:35:26 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1179351325!23323774!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 30625 invoked from network); 16 May 2007 21:35:25 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-9.tower-119.messagelabs.com with SMTP; 16 May 2007 21:35:25 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l4GLZPSi018435; Wed, 16 May 2007 14:35:25 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l4GLZNIM005723; Wed, 16 May 2007 16:35:24 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.33]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4GLZKw4005651; Wed, 16 May 2007 16:35:21 -0500 (CDT) Message-ID: <464B7917.2010402@gmail.com> Date: Wed, 16 May 2007 23:35:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [nemo] Re: [Mip6] The use of GRE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Basavaraj Patil wrote: > Hi Alex, > > > On 5/16/07 2:19 PM, "ext Alexandru Petrescu" > wrote: > >> Basavaraj Patil wrote: >>> Some observations about the discussion so far: >>> >>> 1. If the only packet types encapsulated by the UDP header are >>> IPv4/6 then we do not need the extra 4 byte header. 2. The need >>> for the 4 byte header to spell the encapsulated packet type >>> arises only if we believe GRE or other types of packets may be >>> encapsulated in the tunnel between the MN and HA. Yoshi (at >>> least) has indicated that he has had to implement GRE tunnelling >>> support on the MN. Would help if any others can respond and >>> clarify if tunnelling GRE over IP at the MN is normally done. 3. >>> The 4 byte header in every packet is an overhead. Depending on >>> the link type 4 bytes in every packet can be considered as being >>> wasteful. 4. The need for GRE encapsulation for NEMO is not >>> apparent; I think there was an explicit statement that GRE is not >>> needed for NEMO. >> I agree with this 1-4 list, and I think it summarizes well the >> points discussed so far, thanks. >> >> Another need for GRE that was mentioned is security. It is not >> technically clear either. > > I guess I missed the security argument. But as you say, the reasons > are not very clear. Sorry, I think the security argument was made in a mail by Pascal yesterday http://www1.ietf.org/mail-archive/web/mip6/current/msg06157.html >> Raj, I find it extemely annoying the silence around the actual need >> for GRE. It is a known fact for anyone following WiMax SDO that >> WiMax needs GRE. It is also a known fact that several people >> expressing oppinions on this list are also expressing opinions on >> WiMax NWG. > > I am not sure if that is indeed the case. At least I have not > perceived it as such from the current thread. Right. Let me say differently: does WiMax need GRE in netlmm-PMIPv6 protocol? Is WiMax ok if netlmm-PMIPv6 protocol uses IPv6-in-IPv6 encapsulation as of rfc2473 "Generic Packet Tunnling in IPv6 Specification" instead of GRE as of rfc2784 "Generic Routing Encapsulation"? > Since I also am involved in WiMAX NWG, I can tell you > that this issue of GRE support in DS-MIP6 has never been discussed > in that forum. Ok. Did WiMax discuss at all GRE? Did WiMax already include GRE in some of its specs? >> YEt these people are silent when the question "who needs GRE" is >> raised. >> >> This is very annoying. >> >> I understand very well your neutral Chair position and you >> summarized very well the GRE discussion so far - I appreciate that. >> >> >> >> But I think it is time to state clearly that GRE is pushed here >> _only_ because WiMax needs it. Every other technical reason for >> GRE is completely bogus: security (you didn't mention), NEMO and >> capacity to carry other than IPv4/IPv6 is pure speculative >> handwaving. >> >> Once we have that statement of interest from WiMax needs about GRE >> we can deal with it accordingly. Otherwise it looks as if you try >> to make it look as if it were a typical IETF discussion - it isn't. >> >> > > IMO, the discussion on this topic/thread was not motivated by who > needs GRE. It was simply closing an issue that was raised and > discussed at the Prague IETF. The argument about GRE arose only as a > result of the need for the 4 byte header to indicate the encapsulated > packet type. I believe this was a typical WG discussion. You may be > reading much more into it than what it is. Sorry... I'm probably over-reacting on this. To come back to your recommendation, more reasonably, which was: > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is > a need to support GRE encapsulation in that context, the Netlmm I-D > may extend the DS-MIP6 spec and add the 4 byte header. I find it clear in your recommendation above that you consider NETLMM to need GRE. And I am not sure how to take this recommendation. I ask you: why do you consider NETLMM to need GRE? It is surprising to consider NETLMM to need GRE because NETLMM is based on MIP6 and MIP6 doesn't need nor use GRE. And then: do you make this recommendation as a MIP6 WG Chair to MIP6 WG members? Do you make this recommendation as a member of NETLMM WG? If latter I don't agree with your recommendation (as another NETLMM WG member). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Wed May 16 17:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRL3-0008KE-IB; Wed, 16 May 2007 17:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRL2-0008K2-Mg; Wed, 16 May 2007 17:47:16 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoRL1-00080Y-Bw; Wed, 16 May 2007 17:47:16 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1179352034!2593045!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6693 invoked from network); 16 May 2007 21:47:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 16 May 2007 21:47:14 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GLlDlt001143; Wed, 16 May 2007 14:47:13 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4GLlD70000862; Wed, 16 May 2007 16:47:13 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.33]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4GLlA3g000816; Wed, 16 May 2007 16:47:10 -0500 (CDT) Message-ID: <464B7BDD.6090506@gmail.com> Date: Wed, 16 May 2007 23:47:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > Hello Raj, > > We might actually end up with option 2. I see three reserved > UDP ports with DS-MIPv6 already. > > 1. One UDP port indicating IPv4/IPv6. You parse the IP version > field to figure out whether it is IPv4 or IPv6. > 2. One UDP port for ESP encapsulation. This happens when you > protect DS-MIPv6 traffic with ESP and use UDP encapsulation > for NAT traversal. The packet format would be > IPv4 hdr (src=MN-IPv4-CoA, dst=HA-IPv4) > UDP hdr > ESP hdr > IPv6 (src=MN-IPv6-HoA, dst=CN) > Payload > 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. Vijay, but _why_ reserving an UDP port for GRE encapsulation? Since Sri puts the accent so much on the technical merit, what is the technical merit of using GRE (compared to existing encapsulation methods)? Why developing two different ways for doing the same thing? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Wed May 16 18:09:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRgQ-0005Q7-TC; Wed, 16 May 2007 18:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRgP-0005Pq-A1; Wed, 16 May 2007 18:09:21 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoRgJ-0005uT-EN; Wed, 16 May 2007 18:09:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] The use of GRE Date: Wed, 16 May 2007 15:09:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] The use of GRE thread-index: AceYA8YenylAHriERpaTqWg2qn754wAArFNA References: <464B7BDD.6090506@gmail.com> From: "Vijay Devarapalli" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex,=20 "Why GRE?" is a separate topic. If someone wants to use GRE encapsulation to identify flows in DS-MIPv6, we would need to reserve another UDP port. Vijay > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, May 16, 2007 2:47 PM > To: Vijay Devarapalli > Cc: Basavaraj Patil; ext Tsirtsis, George; Sri Gundavelli;=20 > Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: Re: [nemo] RE: [Mip6] The use of GRE >=20 > Vijay Devarapalli wrote: > > Hello Raj, > >=20 > > We might actually end up with option 2. I see three reserved=20 > > UDP ports with DS-MIPv6 already. > >=20 > > 1. One UDP port indicating IPv4/IPv6. You parse the IP version > > field to figure out whether it is IPv4 or IPv6. > > 2. One UDP port for ESP encapsulation. This happens when you=20 > > protect DS-MIPv6 traffic with ESP and use UDP encapsulation=20 > > for NAT traversal. The packet format would be > > IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4) > > UDP hdr > > ESP hdr > > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN) > > Payload=20 > > 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. >=20 > Vijay, but _why_ reserving an UDP port for GRE encapsulation? >=20 > Since Sri puts the accent so much on the technical merit, what is the=20 > technical merit of using GRE (compared to existing=20 > encapsulation methods)? >=20 > Why developing two different ways for doing the same thing? >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 From nemo-bounces@ietf.org Wed May 16 19:32:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoSz0-00032D-7T; Wed, 16 May 2007 19:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoSyx-00031f-OE; Wed, 16 May 2007 19:32:35 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoSyw-0000VY-7Q; Wed, 16 May 2007 19:32:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 May 2007 16:32:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiACEBSSAARLbbLA= References: <2309978910A6A6478C2C7585692B0AF4579F25@NAEX16.na.qualcomm.com> From: "Vijay Devarapalli" To: "Tsirtsis, George" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Option 4 needs some more work. It is incomplete when you consider what is shown in the slides. We briefly touched upon this during the IETF meeting in Prague. Option 4 can be used in environments where you actually run the signaling protocol (Binding Update/ Binding Ack) and setup a flow (for a particular session/app). You run the signaling protocol each time you want to setup a separate flow.=20 I was planning to work on it and specify it in more detail, but don't have the time for it. I think we should remove option 4 from the list of options, unless someone wants to work on it and specify=20 it in more detail. Vijay > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Friday, May 11, 2007 5:53 AM > To: Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org > Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > I support Option 1. (BTW, Option 4 does not work as far as I can tell) > Please see justification below... >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, May 08, 2007 10:16 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > ... >=20 > Choices are: > 1. Parse the protocol header following the UDP header >=20 > GT> This makes sense to me. It is simple, efficient and it is already > defined in the draft. >=20 > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >=20 > GT> While this is a reasonable alternative, I have not heard a > convincing argument to warrant a change from what the draft already > defines (i.e., option 1 above). >=20 > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >=20 > GT> This seems wasteful and unnecessary, given (1 and 2) >=20 > 4. Encapsulated protocol header type is indicated in the BU message >=20 > GT> This does not seem to work at all. DSMIPv6 can register IPv4 and > IPv6 addresses at the same time. This means that on a packet by packet > basis the header encapsulated over UDP can change from IPv4=20 > to IPv6 and > back. Signaling one or the other in the BU (outbound indication) is > clearly not sufficient and so the indication has to be=20 > inbound with the > data. >=20 > Regards > George >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 From nemo-bounces@ietf.org Wed May 16 21:17:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoUce-00033Z-9U; Wed, 16 May 2007 21:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoUcc-0002xT-OC for nemo@ietf.org; Wed, 16 May 2007 21:17:38 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoUcZ-00061O-U5 for nemo@ietf.org; Wed, 16 May 2007 21:17:38 -0400 Received: by py-out-1112.google.com with SMTP id f31so681786pyh for ; Wed, 16 May 2007 18:17:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=tCpGupVB+NQZNZ+KWbnF+0JBXKBb+zNE51dDkKd98hJqLGCkiow8fOPuCpQBJB4HwuA2qnp0PAb46D8veYarE/+9FJ0EJ74JLNdRIghXXw5RZo2K9lAlJgyJdrkjTEzkPHnXmMvZ6HaeRjL/Ccdi+QlD79R4Iq4zdw0SahrPcwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=bVTQ1NhjePvLfPgUUeZwLdNWV7kNKteIxIizeaIOgLQgrmHGeJHJLmFPKGPceOCMeedQpL4u1HRg36ByaOj1/oTTBW3SXs0ox0F3N6HGKlQo40rh5dRg2cPG7rBQOzFoAuwpJXK3W8pa1apapDz6e/gYLwlRFD6WhpeDJaW5O/I= Received: by 10.35.27.2 with SMTP id e2mr15980372pyj.1179364655574; Wed, 16 May 2007 18:17:35 -0700 (PDT) Received: from ?203.178.143.234? ( [203.178.143.234]) by mx.google.com with ESMTP id w67sm5039443pyg.2007.05.16.18.17.32; Wed, 16 May 2007 18:17:34 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 10:17:28 +0900 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Raj, On 2007/05/17, at 2:08, Basavaraj Patil wrote: > > Some observations about the discussion so far: > > 1. If the only packet types encapsulated by the UDP header are > IPv4/6 then > we do not need the extra 4 byte header. > 2. The need for the 4 byte header to spell the encapsulated packet > type > arises only if we believe GRE or other types of packets may be > encapsulated > in the tunnel between the MN and HA. Yoshi (at least) has indicated > that he > has had to implement GRE tunnelling support on the MN. Would help > if any > others can respond and clarify if tunnelling GRE over IP at the MN is > normally done. > 3. The 4 byte header in every packet is an overhead. Depending on > the link > type 4 bytes in every packet can be considered as being wasteful. > 4. The need for GRE encapsulation for NEMO is not apparent; I think > there > was an explicit statement that GRE is not needed for NEMO. > > Recommendation: > > The DS-MIP6 I-D has been worked on at length in this WG. Its time > to get > this published and implementations tested. > > Proceed with the current model where we only have either IPv4/6 > packets > being encapsulated between the MN and HA by the UDP header. No > additional 4 > byte header to be added. > > When there is a valid justification and need for supporting > encapsulation of > GRE and/or other packet types, we can revise the specification if > needed. > > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there > is a need > to support GRE encapsulation in that context, the Netlmm I-D may > extend the > DS-MIP6 spec and add the 4 byte header. > It seems that many people want to support GRE on DSMIP. I am fine with either 4byte header or UDP port for GRE. I personally prefer Vijay's suggestion (UDP port for GRE). I understand it is important for DSMIP to leave space for future extensions. But this additional feature can easily be re-defined in different spec as DSMIP extension. We don't need to specify it in DSMIP now. The separate doc can overwrite the DSMIP spec if needed. regards, ryuji > -Raj > > On 5/14/07 9:04 AM, "ext Tsirtsis, George" > wrote: > >> Folks, >> >> I have been trying to make sense of this discussion. After re-reading >> the whole thread I think we may be able to progress if we answer the >> following question: >> >> QUESTION: Does this group agree that GRE encapsulation needs to be >> supported in MIPv6? >> >> If the answer is "NO", then using the already defined UDP port and >> the >> IP version field to demux IPv4/IPv6 packets as already defined in >> DSMIPv6 is absolutely fine and there is no reason to change it. >> >> If the answer is "YES", then we have to consider the following: >> It is clear that the IP version field can not demux GRE. In that >> case: >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field >> for demuxing). People interested in GRE should write up a draft >> defining >> how GRE is used in MIPv6. This is likely to result in a GRE specific >> method of encapsulation over UDP. This is likely to involve >> reservation >> of one more UDP port and the definition of a small pseudo-header as >> proposed by Sri and others. >> b) Be proactive and adopt the pseudo-header for all >> encapsulations. This would mean that DSMIPv6 draft is changed to >> indicate that over the reserved UDP port we add the TLV (or whatever >> structure) which indicates what the next header is i.e., IPv4, IPv6, >> GRE. >> >> >> Personally, I am not a big fun of supporting GRE encapsulation for >> MIPv6. The reason is that in IPv6 we do not have (and must never >> have) >> to deal with overlapping address spaces (the main use of GRE >> tunneling >> in MIPv4). >> >> Also note that even if we do decide to use the IP version field for >> demuxing now, there is nothing that prevents GRE encapsulation to be >> defined later, as indicated by (a) above, assuming that GRE support >> becomes necessary. Yes, then implementation will have to deal with >> two >> way of demuxing similar information but it is not the end of the >> world >> and it reduces the overhead (albeit not much) in the typical case. >> >> I hope this helps. >> Regards >> George >> >> >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Friday, May 11, 2007 6:26 AM >> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >> Subject: RE: [Mip6] The use of GRE >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>> Sent: Thursday, May 10, 2007 10:20 PM >>> To: mip6@ietf.org; nemo@ietf.org >>> Subject: [Mip6] The use of GRE >>> >>> Hi all, >>> >>> This concensus call on issue 93 made me a bit confused about >>> the use of GRE. >>> I have a simple question: >>> >>> Why can't people that want to use GRE (for PMIP) run it as follows: >>> >>> IP Heahder (proto 47 for GRE) >>> GRE Header >>> UDP >>> ....etc >>> >>> Why do we need to add another layer to qualifiers instead of >>> using the >>> existing allocated numbers? >>> >>> It's been a couple of years since I read the GRE spec so I wanted to >>> understand if this format is a problem >>> >> >> Problem will be with the NAT/PAT device. It wont create NAT bindings >> from the UDP header encapped in the GRE header. >> >> Sri >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > From nemo-bounces@ietf.org Thu May 17 01:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoYHs-0000OF-Fm; Thu, 17 May 2007 01:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoYHq-0000Nc-Du; Thu, 17 May 2007 01:12:26 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoYHn-0002zE-V2; Thu, 17 May 2007 01:12:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4H5BOA18540; Thu, 17 May 2007 05:11:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Mip6] The use of GRE Date: Thu, 17 May 2007 00:12:17 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceYITIRDessNkFPQNy4tPnaeacHAwAIADsA References: From: "Ahmad Muhanna" To: "RYUJI WAKIKAWA" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji, If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, is needed, then why do not we use a new UDP port to indicate the presence of the TLV which then can be used to indicate the next header for many protocols including GRE and ESP. This way we save one UDP port if we want to support ESP as per Vijay's proposal.=20 Regards, Ahmad =20 > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com]=20 > Sent: Wednesday, May 16, 2007 6:17 PM > To: Basavaraj Patil > Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Raj, >=20 >=20 >=20 > On 2007/05/17, at 2:08, Basavaraj Patil wrote: >=20 > > > > Some observations about the discussion so far: > > > > 1. If the only packet types encapsulated by the UDP header are > > IPv4/6 then > > we do not need the extra 4 byte header. > > 2. The need for the 4 byte header to spell the encapsulated packet=20 > > type arises only if we believe GRE or other types of packets may be=20 > > encapsulated in the tunnel between the MN and HA. Yoshi (at=20 > least) has=20 > > indicated that he has had to implement GRE tunnelling=20 > support on the=20 > > MN. Would help if any others can respond and clarify if=20 > tunnelling GRE=20 > > over IP at the MN is normally done. > > 3. The 4 byte header in every packet is an overhead.=20 > Depending on the=20 > > link type 4 bytes in every packet can be considered as=20 > being wasteful. > > 4. The need for GRE encapsulation for NEMO is not apparent; I think=20 > > there was an explicit statement that GRE is not needed for NEMO. > > > > Recommendation: > > > > The DS-MIP6 I-D has been worked on at length in this WG.=20 > Its time to=20 > > get this published and implementations tested. > > > > Proceed with the current model where we only have either IPv4/6=20 > > packets being encapsulated between the MN and HA by the UDP=20 > header. No=20 > > additional 4 byte header to be added. > > > > When there is a valid justification and need for supporting=20 > > encapsulation of GRE and/or other packet types, we can revise the=20 > > specification if needed. > > > > Since DS-MIP6 is a component of the PMIP6 work in Netlmm=20 > and there is=20 > > a need to support GRE encapsulation in that context, the Netlmm I-D=20 > > may extend the > > DS-MIP6 spec and add the 4 byte header. > > >=20 > It seems that many people want to support GRE on DSMIP. > I am fine with either 4byte header or UDP port for GRE. > I personally prefer Vijay's suggestion (UDP port for GRE). >=20 > I understand it is important for DSMIP to leave space for=20 > future extensions. > But this additional feature can easily be re-defined in=20 > different spec as DSMIP extension. > We don't need to specify it in DSMIP now. > The separate doc can overwrite the DSMIP spec if needed. >=20 > regards, > ryuji >=20 >=20 >=20 >=20 >=20 >=20 > > -Raj > > > > On 5/14/07 9:04 AM, "ext Tsirtsis, George" > > wrote: > > > >> Folks, > >> > >> I have been trying to make sense of this discussion. After=20 > re-reading=20 > >> the whole thread I think we may be able to progress if we=20 > answer the=20 > >> following question: > >> > >> QUESTION: Does this group agree that GRE encapsulation needs to be=20 > >> supported in MIPv6? > >> > >> If the answer is "NO", then using the already defined UDP port and=20 > >> the IP version field to demux IPv4/IPv6 packets as already=20 > defined in > >> DSMIPv6 is absolutely fine and there is no reason to change it. > >> > >> If the answer is "YES", then we have to consider the following: > >> It is clear that the IP version field can not demux GRE. In that > >> case: > >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for=20 > >> demuxing). People interested in GRE should write up a=20 > draft defining=20 > >> how GRE is used in MIPv6. This is likely to result in a=20 > GRE specific=20 > >> method of encapsulation over UDP. This is likely to involve=20 > >> reservation of one more UDP port and the definition of a small=20 > >> pseudo-header as proposed by Sri and others. > >> b) Be proactive and adopt the pseudo-header for all=20 > encapsulations.=20 > >> This would mean that DSMIPv6 draft is changed to indicate=20 > that over=20 > >> the reserved UDP port we add the TLV (or whatever > >> structure) which indicates what the next header is i.e.,=20 > IPv4, IPv6,=20 > >> GRE. > >> > >> > >> Personally, I am not a big fun of supporting GRE encapsulation for=20 > >> MIPv6. The reason is that in IPv6 we do not have (and must never > >> have) > >> to deal with overlapping address spaces (the main use of GRE=20 > >> tunneling in MIPv4). > >> > >> Also note that even if we do decide to use the IP version=20 > field for=20 > >> demuxing now, there is nothing that prevents GRE=20 > encapsulation to be=20 > >> defined later, as indicated by (a) above, assuming that=20 > GRE support=20 > >> becomes necessary. Yes, then implementation will have to deal with=20 > >> two way of demuxing similar information but it is not the=20 > end of the=20 > >> world and it reduces the overhead (albeit not much) in the typical=20 > >> case. > >> > >> I hope this helps. > >> Regards > >> George > >> > >> > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Friday, May 11, 2007 6:26 AM > >> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > >> Subject: RE: [Mip6] The use of GRE > >> > >> > >> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > >>> Sent: Thursday, May 10, 2007 10:20 PM > >>> To: mip6@ietf.org; nemo@ietf.org > >>> Subject: [Mip6] The use of GRE > >>> > >>> Hi all, > >>> > >>> This concensus call on issue 93 made me a bit confused=20 > about the use=20 > >>> of GRE. > >>> I have a simple question: > >>> > >>> Why can't people that want to use GRE (for PMIP) run it=20 > as follows: > >>> > >>> IP Heahder (proto 47 for GRE) > >>> GRE Header > >>> UDP > >>> ....etc > >>> > >>> Why do we need to add another layer to qualifiers instead=20 > of using=20 > >>> the existing allocated numbers? > >>> > >>> It's been a couple of years since I read the GRE spec so=20 > I wanted to=20 > >>> understand if this format is a problem > >>> > >> > >> Problem will be with the NAT/PAT device. It wont create=20 > NAT bindings=20 > >> from the UDP header encapped in the GRE header. > >> > >> Sri > >> > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >=20 >=20 >=20 From nemo-bounces@ietf.org Thu May 17 02:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZmr-0004k0-2K; Thu, 17 May 2007 02:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZmq-0004jf-8U; Thu, 17 May 2007 02:48:32 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoZmn-0006zz-PM; Thu, 17 May 2007 02:48:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4H6mQsR006961; Thu, 17 May 2007 09:48:27 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 09:48:26 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 09:48:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2007 09:48:25 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D0580A757@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAGl7lBQ References: From: To: , , X-OriginalArrivalTime: 17 May 2007 06:48:26.0602 (UTC) FILETIME=[5EF0B4A0:01C7984F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, >Choices are: >1. Parse the protocol header following the UDP header=20 >2. Reserve a UDP port for each protocol header (i.e one UDP port for IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)=20 >3. One reserved UDP port and a DS-MIP6 "tunnel type message" >4. Encapsulated protocol header type is indicated in the BU message > I prefer to go with option 2. From MN perspective the extensibility that a TLV header brings (e.g. support for GRE) is not important. So my suggestion is to allocate one port for IPv4-UDP-IPv4/IPv6 and define that now in the draft. If there is a need to support other protocols later, then allocate a new port. This way we can have a "green" protocol without the extra 4-byte overhead and still allow to add support for other protocols later. Having separate ports for IPv4-UDP-IPv4 and IPv4-UDP-IPv6 is something I don't like just because we'd need to have separate keepalives for both ports. Cheers, Markku From nemo-bounces@ietf.org Thu May 17 04:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hobdy-0001jO-1H; Thu, 17 May 2007 04:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hobdu-0001jB-D2; Thu, 17 May 2007 04:47:27 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hobds-0000If-Cq; Thu, 17 May 2007 04:47:26 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hobdk-0001Cq-TX; Thu, 17 May 2007 10:47:17 +0200 Message-ID: <464C1692.10907@levkowetz.com> Date: Thu, 17 May 2007 10:47:14 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: amuhanna@nortel.com, ryuji.wakikawa@gmail.com, basavaraj.patil@nsn.com, nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Folks, on 2007-05-17 07:12 Ahmad Muhanna said the following: > Hi Ryuji, > > If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, > is needed, then why do not we use a new UDP port to indicate the > presence of the TLV which then can be used to indicate the next header > for many protocols including GRE and ESP. This way we save one UDP port > if we want to support ESP as per Vijay's proposal. At least I am very far from agreeing on one additional assigned UDP port. The number of unassigned UDP port in the range that can be assigned by IANA (0 - 1023) is now down to 281, by my count, so this should be considered a scarce resource. I'm not even sure whether it makes sense to ask for a new port for DS-MIPv6 rather than multiplex over for instance the MIPv4 port, but I think we can at least ask the question. But asking for 2 ports, to carry 2 different kinds of DS-MIPv6 payloads, seems just wrong. Henrik From nemo-bounces@ietf.org Thu May 17 09:25:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hofyk-0006iu-Pe; Thu, 17 May 2007 09:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hofyj-0006ik-V3 for nemo@ietf.org; Thu, 17 May 2007 09:25:13 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hofyj-0001oO-B1 for nemo@ietf.org; Thu, 17 May 2007 09:25:13 -0400 Received: by wx-out-0506.google.com with SMTP id h31so565319wxd for ; Thu, 17 May 2007 06:25:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=N/9e8LCnmmuakMHI69MXN2+atM1bXNKUnCg1wcsMMhOaPyrhpZJ1sNkjHELOC6BoGr/Jcqe5mdA7LNMSJsj0gbqE6WbYDAIlSAHcpQ4LX6GNkv5nQRaWoud6GM57bkTFlgb3gYSfjRyRlqi8RiSzMJNE1IAdsiGmtVI7VfExf98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=k1IX/70rj1RBLc/8fCyiw47OpLRsSD6a32t1PmAh8I8e8iBiFK4u/U4lllsjjOTcXEQ6XQEFlQzB3MxB0tm09BlhHSxV9pwcJB9HUkJLf3n/0W6uYwJr5GmEWJdMNKqjKvcybpP/MrKJQUhLFWtwebh9McX2TCEJnmLdauW885s= Received: by 10.90.69.8 with SMTP id r8mr372750aga.1179408312723; Thu, 17 May 2007 06:25:12 -0700 (PDT) Received: from ?10.0.1.200? ( [219.110.221.36]) by mx.google.com with ESMTP id 7sm2538131agc.2007.05.17.06.25.09; Thu, 17 May 2007 06:25:11 -0700 (PDT) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 22:25:05 +0900 To: Ahmad Muhanna X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi This is fine. I just want to avoid 4bytes in every packets over wireless. However, I noticed that if this GRE/ESP support is only for netlmm, it isn't big problem. The path between MAG and LMA is not wireless. I need to see what tunnel (GRE, ESP) is supported for which protocol (MIP6, NEMO, PMIP?) in DSMIP. ryuji On 2007/05/17, at 14:12, Ahmad Muhanna wrote: > Hi Ryuji, > > If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, > is needed, then why do not we use a new UDP port to indicate the > presence of the TLV which then can be used to indicate the next header > for many protocols including GRE and ESP. This way we save one UDP > port > if we want to support ESP as per Vijay's proposal. > > Regards, > Ahmad > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Wednesday, May 16, 2007 6:17 PM >> To: Basavaraj Patil >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli >> Subject: Re: [nemo] Re: [Mip6] The use of GRE >> >> Hi Raj, >> >> >> >> On 2007/05/17, at 2:08, Basavaraj Patil wrote: >> >>> >>> Some observations about the discussion so far: >>> >>> 1. If the only packet types encapsulated by the UDP header are >>> IPv4/6 then >>> we do not need the extra 4 byte header. >>> 2. The need for the 4 byte header to spell the encapsulated packet >>> type arises only if we believe GRE or other types of packets may be >>> encapsulated in the tunnel between the MN and HA. Yoshi (at >> least) has >>> indicated that he has had to implement GRE tunnelling >> support on the >>> MN. Would help if any others can respond and clarify if >> tunnelling GRE >>> over IP at the MN is normally done. >>> 3. The 4 byte header in every packet is an overhead. >> Depending on the >>> link type 4 bytes in every packet can be considered as >> being wasteful. >>> 4. The need for GRE encapsulation for NEMO is not apparent; I think >>> there was an explicit statement that GRE is not needed for NEMO. >>> >>> Recommendation: >>> >>> The DS-MIP6 I-D has been worked on at length in this WG. >> Its time to >>> get this published and implementations tested. >>> >>> Proceed with the current model where we only have either IPv4/6 >>> packets being encapsulated between the MN and HA by the UDP >> header. No >>> additional 4 byte header to be added. >>> >>> When there is a valid justification and need for supporting >>> encapsulation of GRE and/or other packet types, we can revise the >>> specification if needed. >>> >>> Since DS-MIP6 is a component of the PMIP6 work in Netlmm >> and there is >>> a need to support GRE encapsulation in that context, the Netlmm I-D >>> may extend the >>> DS-MIP6 spec and add the 4 byte header. >>> >> >> It seems that many people want to support GRE on DSMIP. >> I am fine with either 4byte header or UDP port for GRE. >> I personally prefer Vijay's suggestion (UDP port for GRE). >> >> I understand it is important for DSMIP to leave space for >> future extensions. >> But this additional feature can easily be re-defined in >> different spec as DSMIP extension. >> We don't need to specify it in DSMIP now. >> The separate doc can overwrite the DSMIP spec if needed. >> >> regards, >> ryuji >> >> >> >> >> >> >>> -Raj >>> >>> On 5/14/07 9:04 AM, "ext Tsirtsis, George" >>> wrote: >>> >>>> Folks, >>>> >>>> I have been trying to make sense of this discussion. After >> re-reading >>>> the whole thread I think we may be able to progress if we >> answer the >>>> following question: >>>> >>>> QUESTION: Does this group agree that GRE encapsulation needs to be >>>> supported in MIPv6? >>>> >>>> If the answer is "NO", then using the already defined UDP port and >>>> the IP version field to demux IPv4/IPv6 packets as already >> defined in >>>> DSMIPv6 is absolutely fine and there is no reason to change it. >>>> >>>> If the answer is "YES", then we have to consider the following: >>>> It is clear that the IP version field can not demux GRE. In that >>>> case: >>>> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for >>>> demuxing). People interested in GRE should write up a >> draft defining >>>> how GRE is used in MIPv6. This is likely to result in a >> GRE specific >>>> method of encapsulation over UDP. This is likely to involve >>>> reservation of one more UDP port and the definition of a small >>>> pseudo-header as proposed by Sri and others. >>>> b) Be proactive and adopt the pseudo-header for all >> encapsulations. >>>> This would mean that DSMIPv6 draft is changed to indicate >> that over >>>> the reserved UDP port we add the TLV (or whatever >>>> structure) which indicates what the next header is i.e., >> IPv4, IPv6, >>>> GRE. >>>> >>>> >>>> Personally, I am not a big fun of supporting GRE encapsulation for >>>> MIPv6. The reason is that in IPv6 we do not have (and must never >>>> have) >>>> to deal with overlapping address spaces (the main use of GRE >>>> tunneling in MIPv4). >>>> >>>> Also note that even if we do decide to use the IP version >> field for >>>> demuxing now, there is nothing that prevents GRE >> encapsulation to be >>>> defined later, as indicated by (a) above, assuming that >> GRE support >>>> becomes necessary. Yes, then implementation will have to deal with >>>> two way of demuxing similar information but it is not the >> end of the >>>> world and it reduces the overhead (albeit not much) in the typical >>>> case. >>>> >>>> I hope this helps. >>>> Regards >>>> George >>>> >>>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Friday, May 11, 2007 6:26 AM >>>> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >>>> Subject: RE: [Mip6] The use of GRE >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>>>> Sent: Thursday, May 10, 2007 10:20 PM >>>>> To: mip6@ietf.org; nemo@ietf.org >>>>> Subject: [Mip6] The use of GRE >>>>> >>>>> Hi all, >>>>> >>>>> This concensus call on issue 93 made me a bit confused >> about the use >>>>> of GRE. >>>>> I have a simple question: >>>>> >>>>> Why can't people that want to use GRE (for PMIP) run it >> as follows: >>>>> >>>>> IP Heahder (proto 47 for GRE) >>>>> GRE Header >>>>> UDP >>>>> ....etc >>>>> >>>>> Why do we need to add another layer to qualifiers instead >> of using >>>>> the existing allocated numbers? >>>>> >>>>> It's been a couple of years since I read the GRE spec so >> I wanted to >>>>> understand if this format is a problem >>>>> >>>> >>>> Problem will be with the NAT/PAT device. It wont create >> NAT bindings >>>> from the UDP header encapped in the GRE header. >>>> >>>> Sri >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >> >> >> From nemo-bounces@ietf.org Thu May 17 09:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hog2H-000051-Kq; Thu, 17 May 2007 09:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hog2G-0008VH-MY for nemo@ietf.org; Thu, 17 May 2007 09:28:52 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hog2F-00048W-Ed for nemo@ietf.org; Thu, 17 May 2007 09:28:52 -0400 Received: by wx-out-0506.google.com with SMTP id h31so566535wxd for ; Thu, 17 May 2007 06:28:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=i/3zeaU2Tev4xG8/D1rj2ZROa8+mW9hUboIoPhq+9Zf11dNUtSlIv+42mK74p0TiP+8iYqdxkzJKgAZGoRCMdxNtQ5IEGi6IFotkdeHUaIa2x7/qtxTV27Zuddghdk+em5huE9zjMeWxX+fizGOcbxZ36zeyjT2ZxJks1/WEy10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=qPQQxYmWNadgXV3Yi7JMTClZj7OspObO41y/Bt1CxWKC7aHz4iqYIMFnqZiqp0ur6kNTmy6CgTlBm32SK5WQBIG/bqCZJuwQl106UOPKcbSjrwqQ9wJ2nZ/RCZOnf5Ss9UbMqJiBVAW1NhU9BpXQGDa5NGFCPXe2VwQM4Xg/nbM= Received: by 10.90.66.9 with SMTP id o9mr475037aga.1179408531241; Thu, 17 May 2007 06:28:51 -0700 (PDT) Received: from ?10.0.1.200? ( [219.110.221.36]) by mx.google.com with ESMTP id 8sm2548270agd.2007.05.17.06.28.48; Thu, 17 May 2007 06:28:50 -0700 (PDT) In-Reply-To: <464C1692.10907@levkowetz.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 22:28:45 +0900 To: Henrik Levkowetz X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli , Basavaraj Patil , Ahmad Muhanna X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Henrik, I have to agree with you, but the additional 4 bytes in air are also consumed scarce resource, i.e wireless... regards, ryuji On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > Folks, > > on 2007-05-17 07:12 Ahmad Muhanna said the following: >> Hi Ryuji, >> >> If we agree that a new UDP port for GRE, beside the one for IPv4/ >> IPv6, >> is needed, then why do not we use a new UDP port to indicate the >> presence of the TLV which then can be used to indicate the next >> header >> for many protocols including GRE and ESP. This way we save one UDP >> port >> if we want to support ESP as per Vijay's proposal. > > At least I am very far from agreeing on one additional assigned UDP > port. The number of unassigned UDP port in the range that can be > assigned by IANA (0 - 1023) is now down to 281, by my count, so this > should be considered a scarce resource. > > I'm not even sure whether it makes sense to ask for a new port for > DS-MIPv6 > rather than multiplex over for instance the MIPv4 port, but I think > we can > at least ask the question. But asking for 2 ports, to carry 2 > different > kinds of DS-MIPv6 payloads, seems just wrong. > > > Henrik From nemo-bounces@ietf.org Thu May 17 12:39:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj0Q-0003xf-6d; Thu, 17 May 2007 12:39:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj0O-0003xS-ID; Thu, 17 May 2007 12:39:08 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hoj0M-0007Q3-5m; Thu, 17 May 2007 12:39:08 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1179419945!14048261!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29227 invoked from network); 17 May 2007 16:39:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 17 May 2007 16:39:05 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4HGd48T011882; Thu, 17 May 2007 09:39:05 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l4HGd4CH020811; Thu, 17 May 2007 11:39:04 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-31-8-211.am.mot.com [10.31.8.211]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4HGd12N020771; Thu, 17 May 2007 11:39:02 -0500 (CDT) Message-ID: <464C8524.2080704@gmail.com> Date: Thu, 17 May 2007 18:39:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <464B7BDD.6090506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-0, 17/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nemo@ietf.org, Alexandru Petrescu , Sri Gundavelli , mip6@ietf.org, Basavaraj Patil X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > Alex, > > "Why GRE?" is a separate topic. If someone wants to use GRE > encapsulation to identify flows in DS-MIPv6, we would need to > reserve another UDP port. I think we rather should recommend to use existing application standardized tools to identify flows in DS-MIP6 instead of rushing to reserve new UDP port numbers. I think that if there is no need of GRE there is no need of GRE port number either. Alex > > Vijay > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, May 16, 2007 2:47 PM >> To: Vijay Devarapalli >> Cc: Basavaraj Patil; ext Tsirtsis, George; Sri Gundavelli; >> Hesham Soliman; mip6@ietf.org; nemo@ietf.org >> Subject: Re: [nemo] RE: [Mip6] The use of GRE >> >> Vijay Devarapalli wrote: >>> Hello Raj, >>> >>> We might actually end up with option 2. I see three reserved >>> UDP ports with DS-MIPv6 already. >>> >>> 1. One UDP port indicating IPv4/IPv6. You parse the IP version >>> field to figure out whether it is IPv4 or IPv6. >>> 2. One UDP port for ESP encapsulation. This happens when you >>> protect DS-MIPv6 traffic with ESP and use UDP encapsulation >>> for NAT traversal. The packet format would be >>> IPv4 hdr (src=MN-IPv4-CoA, dst=HA-IPv4) >>> UDP hdr >>> ESP hdr >>> IPv6 (src=MN-IPv6-HoA, dst=CN) >>> Payload >>> 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. >> Vijay, but _why_ reserving an UDP port for GRE encapsulation? >> >> Since Sri puts the accent so much on the technical merit, what is the >> technical merit of using GRE (compared to existing >> encapsulation methods)? >> >> Why developing two different ways for doing the same thing? >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu May 17 12:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj2Q-0004pF-Te; Thu, 17 May 2007 12:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj2P-0004ok-3P; Thu, 17 May 2007 12:41:13 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hoj2O-0007vF-FR; Thu, 17 May 2007 12:41:13 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1179420071!1605804!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13135 invoked from network); 17 May 2007 16:41:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 17 May 2007 16:41:11 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4HGfB1L012462; Thu, 17 May 2007 09:41:11 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4HGfAQP024630; Thu, 17 May 2007 11:41:10 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-31-8-211.am.mot.com [10.31.8.211]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4HGf7lc024471; Thu, 17 May 2007 11:41:08 -0500 (CDT) Message-ID: <464C85A2.6070303@gmail.com> Date: Thu, 17 May 2007 18:41:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-0, 17/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ahmad Muhanna wrote: > Hi Ryuji, > > If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, > is needed, then why do not we use a new UDP port to indicate the > presence of the TLV which then can be used to indicate the next header > for many protocols including GRE and ESP. This way we save one UDP port > if we want to support ESP as per Vijay's proposal. Another possibility (no GRE, no new TLV. no new port number) is to extend existing Mobile IPv4 message types to contain whatever data that TLV or GRE needs. Alex > > Regards, > Ahmad > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Wednesday, May 16, 2007 6:17 PM >> To: Basavaraj Patil >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli >> Subject: Re: [nemo] Re: [Mip6] The use of GRE >> >> Hi Raj, >> >> >> >> On 2007/05/17, at 2:08, Basavaraj Patil wrote: >> >>> Some observations about the discussion so far: >>> >>> 1. If the only packet types encapsulated by the UDP header are >>> IPv4/6 then >>> we do not need the extra 4 byte header. >>> 2. The need for the 4 byte header to spell the encapsulated packet >>> type arises only if we believe GRE or other types of packets may be >>> encapsulated in the tunnel between the MN and HA. Yoshi (at >> least) has >>> indicated that he has had to implement GRE tunnelling >> support on the >>> MN. Would help if any others can respond and clarify if >> tunnelling GRE >>> over IP at the MN is normally done. >>> 3. The 4 byte header in every packet is an overhead. >> Depending on the >>> link type 4 bytes in every packet can be considered as >> being wasteful. >>> 4. The need for GRE encapsulation for NEMO is not apparent; I think >>> there was an explicit statement that GRE is not needed for NEMO. >>> >>> Recommendation: >>> >>> The DS-MIP6 I-D has been worked on at length in this WG. >> Its time to >>> get this published and implementations tested. >>> >>> Proceed with the current model where we only have either IPv4/6 >>> packets being encapsulated between the MN and HA by the UDP >> header. No >>> additional 4 byte header to be added. >>> >>> When there is a valid justification and need for supporting >>> encapsulation of GRE and/or other packet types, we can revise the >>> specification if needed. >>> >>> Since DS-MIP6 is a component of the PMIP6 work in Netlmm >> and there is >>> a need to support GRE encapsulation in that context, the Netlmm I-D >>> may extend the >>> DS-MIP6 spec and add the 4 byte header. >>> >> It seems that many people want to support GRE on DSMIP. >> I am fine with either 4byte header or UDP port for GRE. >> I personally prefer Vijay's suggestion (UDP port for GRE). >> >> I understand it is important for DSMIP to leave space for >> future extensions. >> But this additional feature can easily be re-defined in >> different spec as DSMIP extension. >> We don't need to specify it in DSMIP now. >> The separate doc can overwrite the DSMIP spec if needed. >> >> regards, >> ryuji >> >> >> >> >> >> >>> -Raj >>> >>> On 5/14/07 9:04 AM, "ext Tsirtsis, George" >>> wrote: >>> >>>> Folks, >>>> >>>> I have been trying to make sense of this discussion. After >> re-reading >>>> the whole thread I think we may be able to progress if we >> answer the >>>> following question: >>>> >>>> QUESTION: Does this group agree that GRE encapsulation needs to be >>>> supported in MIPv6? >>>> >>>> If the answer is "NO", then using the already defined UDP port and >>>> the IP version field to demux IPv4/IPv6 packets as already >> defined in >>>> DSMIPv6 is absolutely fine and there is no reason to change it. >>>> >>>> If the answer is "YES", then we have to consider the following: >>>> It is clear that the IP version field can not demux GRE. In that >>>> case: >>>> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for >>>> demuxing). People interested in GRE should write up a >> draft defining >>>> how GRE is used in MIPv6. This is likely to result in a >> GRE specific >>>> method of encapsulation over UDP. This is likely to involve >>>> reservation of one more UDP port and the definition of a small >>>> pseudo-header as proposed by Sri and others. >>>> b) Be proactive and adopt the pseudo-header for all >> encapsulations. >>>> This would mean that DSMIPv6 draft is changed to indicate >> that over >>>> the reserved UDP port we add the TLV (or whatever >>>> structure) which indicates what the next header is i.e., >> IPv4, IPv6, >>>> GRE. >>>> >>>> >>>> Personally, I am not a big fun of supporting GRE encapsulation for >>>> MIPv6. The reason is that in IPv6 we do not have (and must never >>>> have) >>>> to deal with overlapping address spaces (the main use of GRE >>>> tunneling in MIPv4). >>>> >>>> Also note that even if we do decide to use the IP version >> field for >>>> demuxing now, there is nothing that prevents GRE >> encapsulation to be >>>> defined later, as indicated by (a) above, assuming that >> GRE support >>>> becomes necessary. Yes, then implementation will have to deal with >>>> two way of demuxing similar information but it is not the >> end of the >>>> world and it reduces the overhead (albeit not much) in the typical >>>> case. >>>> >>>> I hope this helps. >>>> Regards >>>> George >>>> >>>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Friday, May 11, 2007 6:26 AM >>>> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >>>> Subject: RE: [Mip6] The use of GRE >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>>>> Sent: Thursday, May 10, 2007 10:20 PM >>>>> To: mip6@ietf.org; nemo@ietf.org >>>>> Subject: [Mip6] The use of GRE >>>>> >>>>> Hi all, >>>>> >>>>> This concensus call on issue 93 made me a bit confused >> about the use >>>>> of GRE. >>>>> I have a simple question: >>>>> >>>>> Why can't people that want to use GRE (for PMIP) run it >> as follows: >>>>> IP Heahder (proto 47 for GRE) >>>>> GRE Header >>>>> UDP >>>>> ....etc >>>>> >>>>> Why do we need to add another layer to qualifiers instead >> of using >>>>> the existing allocated numbers? >>>>> >>>>> It's been a couple of years since I read the GRE spec so >> I wanted to >>>>> understand if this format is a problem >>>>> >>>> Problem will be with the NAT/PAT device. It wont create >> NAT bindings >>>> from the UDP header encapped in the GRE header. >>>> >>>> Sri >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Thu May 17 12:56:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojGl-0002Y0-AB; Thu, 17 May 2007 12:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojGk-0002XZ-Ay; Thu, 17 May 2007 12:56:02 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojGi-0004a9-L8; Thu, 17 May 2007 12:56:02 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HojGe-0005Kr-2T; Thu, 17 May 2007 18:55:56 +0200 Message-ID: <464C891C.9010407@levkowetz.com> Date: Thu, 17 May 2007 18:55:56 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> In-Reply-To: <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ryuji.wakikawa@gmail.com, amuhanna@nortel.com, basavaraj.patil@nsn.com, nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli , Basavaraj Patil , Ahmad Muhanna X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji, on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > Hi Henrik, > > I have to agree with you, but the additional 4 bytes in air > are also consumed scarce resource, i.e wireless... Humm. What is the bandwidth of your expected wireless link, how often do you send BUs, and how much other traffic? With very simple assumptions, like a voice stream and a BU every 4 minutes, you get: Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes 4 bytes overhead per BU/BA message = 8 bytes Extra overhead due to 4-byte header: 0.0016% I think we can ignore this. Henrik > regards, > ryuji > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >> Folks, >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: >>> Hi Ryuji, >>> >>> If we agree that a new UDP port for GRE, beside the one for IPv4/ >>> IPv6, >>> is needed, then why do not we use a new UDP port to indicate the >>> presence of the TLV which then can be used to indicate the next >>> header >>> for many protocols including GRE and ESP. This way we save one UDP >>> port >>> if we want to support ESP as per Vijay's proposal. >> >> At least I am very far from agreeing on one additional assigned UDP >> port. The number of unassigned UDP port in the range that can be >> assigned by IANA (0 - 1023) is now down to 281, by my count, so this >> should be considered a scarce resource. >> >> I'm not even sure whether it makes sense to ask for a new port for >> DS-MIPv6 >> rather than multiplex over for instance the MIPv4 port, but I think >> we can >> at least ask the question. But asking for 2 ports, to carry 2 >> different >> kinds of DS-MIPv6 payloads, seems just wrong. >> >> >> Henrik > > From nemo-bounces@ietf.org Thu May 17 14:07:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokNV-0007CA-Im; Thu, 17 May 2007 14:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokNU-0007Bi-4r; Thu, 17 May 2007 14:07:04 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HokNS-0006jh-Ra; Thu, 17 May 2007 14:07:04 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4HI6iB17602; Thu, 17 May 2007 18:06:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Mip6] The use of GRE Date: Thu, 17 May 2007 13:06:41 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711451AF72@zrc2hxm2.corp.nortel.com> In-Reply-To: <464C891C.9010407@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceYpD+DsLVp0dCOS4qqYXGVbtPRtAACaMYA References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> From: "Ahmad Muhanna" To: "Henrik Levkowetz" , "RYUJI WAKIKAWA" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org >=20 > Hi Ryuji, >=20 > on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > > Hi Henrik, > >=20 > > I have to agree with you, but the additional 4 bytes in air=20 > are also=20 > > consumed scarce resource, i.e wireless... >=20 > Humm. What is the bandwidth of your expected wireless link,=20 > how often do you send BUs, and how much other traffic? >=20 > With very simple assumptions, like a voice stream and a BU=20 > every 4 minutes, you get: >=20 > Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 bytes > 4 bytes overhead per BU/BA message =3D 8 bytes >=20 > Extra overhead due to 4-byte header: 0.0016% >=20 > I think we can ignore this. [Ahmad] Yep. I like this simple yet valuable analysis.:) >=20 >=20 > Henrik >=20 >=20 > > regards, > > ryuji > >=20 > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >=20 > >> Folks, > >> > >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >>> Hi Ryuji, > >>> > >>> If we agree that a new UDP port for GRE, beside the one for IPv4/=20 > >>> IPv6, is needed, then why do not we use a new UDP port to=20 > indicate=20 > >>> the presence of the TLV which then can be used to=20 > indicate the next=20 > >>> header for many protocols including GRE and ESP. This way we save=20 > >>> one UDP port if we want to support ESP as per Vijay's proposal. > >> > >> At least I am very far from agreeing on one additional=20 > assigned UDP=20 > >> port. The number of unassigned UDP port in the range that can be=20 > >> assigned by IANA (0 - 1023) is now down to 281, by my=20 > count, so this=20 > >> should be considered a scarce resource. > >> > >> I'm not even sure whether it makes sense to ask for a new port for > >> DS-MIPv6 > >> rather than multiplex over for instance the MIPv4 port,=20 > but I think=20 > >> we can at least ask the question. But asking for 2 ports,=20 > to carry 2=20 > >> different kinds of DS-MIPv6 payloads, seems just wrong. > >> > >> > >> Henrik > >=20 > >=20 >=20 From nemo-bounces@ietf.org Thu May 17 21:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoqrK-0007rP-2e; Thu, 17 May 2007 21:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoqrI-0007rH-H8; Thu, 17 May 2007 21:02:16 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoqrH-00033e-7l; Thu, 17 May 2007 21:02:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 18:02:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceYpIK0JbIgR5eHRXuNGgD/CFGyigAQydPQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> From: "Vijay Devarapalli" To: "Henrik Levkowetz" , "RYUJI WAKIKAWA" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: nemo@ietf.org, mip6@ietf.org, Ahmad Muhanna , Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Isn't the 4 byte overhead on every data packet in the voice stream? Not just the BU/BAck. I must be missing something. Vijay=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Thursday, May 17, 2007 9:56 AM > To: RYUJI WAKIKAWA > Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli; Basavaraj=20 > Patil; Ahmad Muhanna > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Ryuji, >=20 > on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > > Hi Henrik, > >=20 > > I have to agree with you, but the additional 4 bytes in air > > are also consumed scarce resource, i.e wireless... >=20 > Humm. What is the bandwidth of your expected wireless link, > how often do you send BUs, and how much other traffic? >=20 > With very simple assumptions, like a voice stream and a BU > every 4 minutes, you get: >=20 > Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 bytes > 4 bytes overhead per BU/BA message =3D 8 bytes >=20 > Extra overhead due to 4-byte header: 0.0016% >=20 > I think we can ignore this. >=20 >=20 > Henrik >=20 >=20 > > regards, > > ryuji > >=20 > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >=20 > >> Folks, > >> > >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >>> Hi Ryuji, > >>> > >>> If we agree that a new UDP port for GRE, beside the one for IPv4/=20 > >>> IPv6, > >>> is needed, then why do not we use a new UDP port to indicate the > >>> presence of the TLV which then can be used to indicate the next =20 > >>> header > >>> for many protocols including GRE and ESP. This way we=20 > save one UDP =20 > >>> port > >>> if we want to support ESP as per Vijay's proposal. > >> > >> At least I am very far from agreeing on one additional assigned UDP > >> port. The number of unassigned UDP port in the range that can be > >> assigned by IANA (0 - 1023) is now down to 281, by my=20 > count, so this > >> should be considered a scarce resource. > >> > >> I'm not even sure whether it makes sense to ask for a new=20 > port for =20 > >> DS-MIPv6 > >> rather than multiplex over for instance the MIPv4 port,=20 > but I think =20 > >> we can > >> at least ask the question. But asking for 2 ports, to carry 2 =20 > >> different > >> kinds of DS-MIPv6 payloads, seems just wrong. > >> > >> > >> Henrik > >=20 > >=20 >=20 >=20 From nemo-bounces@ietf.org Thu May 17 21:05:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoquU-0001u8-Mo; Thu, 17 May 2007 21:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoquT-0001tb-4W; Thu, 17 May 2007 21:05:33 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoquP-0003Z9-3c; Thu, 17 May 2007 21:05:33 -0400 Received: from oaamta05ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070518010526.TPMN23363.omta05ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com>; Fri, 18 May 2007 01:05:26 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05ps.mx.bigpond.com with ESMTP id <20070518010526.NGNL11252.oaamta05ps.mx.bigpond.com@PC20005>; Fri, 18 May 2007 01:05:26 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" , "'RYUJI WAKIKAWA'" Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Fri, 18 May 2007 11:05:16 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYpIGdGJvQHyPgSXCMHKRdu0PQ1gAQ/X0w In-Reply-To: <464C891C.9010407@levkowetz.com> Message-Id: <20070518010526.NGNL11252.oaamta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nemo@ietf.org, mip6@ietf.org, 'Ahmad Muhanna' , 'Basavaraj Patil' , 'Sri Gundavelli' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > With very simple assumptions, like a voice stream and a BU > every 4 minutes, you get: > > Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes > 4 bytes overhead per BU/BA message = 8 bytes => That's not accurate, the 4-byte o/h is in every packet, it's not just the BU/BA. Hesham > > Extra overhead due to 4-byte header: 0.0016% > > I think we can ignore this. > > > Henrik > > > > regards, > > ryuji > > > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > > > >> Folks, > >> > >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >>> Hi Ryuji, > >>> > >>> If we agree that a new UDP port for GRE, beside the one > for IPv4/ > >>> IPv6, > >>> is needed, then why do not we use a new UDP port to indicate the > >>> presence of the TLV which then can be used to indicate the next > >>> header > >>> for many protocols including GRE and ESP. This way we > save one UDP > >>> port > >>> if we want to support ESP as per Vijay's proposal. > >> > >> At least I am very far from agreeing on one additional > assigned UDP > >> port. The number of unassigned UDP port in the range that can be > >> assigned by IANA (0 - 1023) is now down to 281, by my > count, so this > >> should be considered a scarce resource. > >> > >> I'm not even sure whether it makes sense to ask for a new > port for > >> DS-MIPv6 > >> rather than multiplex over for instance the MIPv4 port, > but I think > >> we can > >> at least ask the question. But asking for 2 ports, to carry 2 > >> different > >> kinds of DS-MIPv6 payloads, seems just wrong. > >> > >> > >> Henrik > > > > > > From nemo-bounces@ietf.org Fri May 18 04:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoxw2-0005VS-Em; Fri, 18 May 2007 04:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoxw1-0005Uu-6w; Fri, 18 May 2007 04:35:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoxvz-0005FX-HI; Fri, 18 May 2007 04:35:37 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 May 2007 10:35:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4I8ZYmV006552; Fri, 18 May 2007 10:35:34 +0200 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 l4I8ZQDf001073; Fri, 18 May 2007 08:35:33 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:35:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of GRE) Date: Fri, 18 May 2007 10:35:02 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03F2CB04@xmb-ams-337.emea.cisco.com> In-Reply-To: <46499FC4.5030506@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of GRE) Thread-Index: AceW6AOh2ULQdzZSRw2mEixcfn2HUACPg2zg References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> <46499FC4.5030506@gmail.com> From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 18 May 2007 08:35:09.0519 (UTC) FILETIME=[71CA0DF0:01C79927] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4852; t=1179477334; x=1180341334; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20L3-in-L2-in-L3-in-L2=20and=20GRE=20improves=20MIP6=20 security=20(was=3A=20[nemo]=20RE=3A=20[Mip6]=20The=20use=20of=20GRE) |Sender:=20; bh=8urUojDdt97zzeq6J2Takytxj4+Vn1NsZVyJsJp87c8=; b=RuVHRmYFupZCyiDpXbnxyhJZD51TdWRYt5272r0voB4A52hp+/S1VRHBytRnhQKTO/5xnNA8 /ksifyLf7u7ZfjCqfM7MxGjhpuLamz3IAOgMIezLe4mZNrP7GUKD2Dyj; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: nemo@ietf.org, mip6@ietf.org, "Sri Gundavelli \(sgundave\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex: I'm surprised you're surprised. That's what L2TP has always been.=20 You might want to read about softwire, and in particular the new developments in: http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t pv2-03.txt=20 Pascal >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Tuesday, May 15, 2007 1:56 PM >To: Pascal Thubert (pthubert) >Cc: Narayanan, Vidya; Hesham Soliman; Sri Gundavelli (sgundave); mip6@ietf.org; nemo@ietf.org >Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of >GRE) > >Pascal Thubert (pthubert) wrote: >> Hi Vidya >> >> I think the discussion started with the idea of making the DSMIP >> tunnel more open to tunneling *anything*. This could be or have been >> done separately from DSMIP, for instance at the time of MIP6 or NEMO. >> If you look at it, all these protocols are tunnel set-up and >> maintenance protocols, with the HoA as the ID for the tunnel. So why >> tunnel only IPv6 in there? >> >> That was (one of) Hesham's valid point(s) when he started his DS-MIP >> draft. So now we have support to tunnel IPv4, and we discriminate >> with protocol type. And the issue comes like is that all we'll ever >> need? Can't we make that more open for future use? And is this draft >> the right time for opening up? >> >> One question was, which future use? >> >> One traditional use is L2 tunneling; > >IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2. This is >an architectural mistake: IPv6-MACheader-IPv4-MACheader. > >I think this is what you are proposing with encapsulating L2 tunnelling >in GRE, is it so? > >> if you want your MR to tunnel multiple flows treated as multiple >> VLANs in the mobile network, you might want to keep the VLANs up to >> the HA by inserting 802.1Q information, or the whole or compressed >> Ethernet packet in the MRHA tunnel. > >I think it is not a good idea to intersperse an L2 header between two >IPv6 base headers. > >I think it is not good idea to propagate 802.1q information between MR >and HA. > >> The L3 alternative (multiple VRFs) is much more complex to deploy on >> a MR. > >I am not sure what you mean. > >What is VRF? > >Also, the L3 alternative (using NEMOv6 base spec and not using L2 >headers between base IPv6 headers), is implemented widely. I am not >sure why you say it is much more complex. > >> So I do agree with the original point that there will be multiple >> usages for that tunnel. At this point, I feel that we are back to a >> previous discussion on reverse Routability test: in traditional MIP >> or NEMO (without SeND) the MR can not be sure of its CoA, > >What do you mean? Do you mean that NEMOv6+SeND is not enough for >securing MR ownership of its Care-of Address? And that NEMOv6+GRE >encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe >Care-of Address? > >> and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the >> right place to solve a problem that was already there? > >Good question. I agree the security model with DS-MIPv6 and IPv4 >Care-of Addresses is different than simple NEMOv6. But I don't see GRE >a solution here. Why do you see GRE as a security solution for DS-MIPv6? > >If HoA is used for identitying IP tunnels then IPsec SAs can link these >HoAs, because HoA is an IP address. On the contrary, if GRE key is used >to identify tunnels then GRE key can not be used with IPsec SAs. >Besides, I don't think there exist protocol selectors for GRE headers. > >> I suspect that we have made some clear room for a number of small >> drafts that will apply to all MIP, DS-MIP and NEMO, to improve the >> security of the system or like in this case make it more open to the >> future. The new drafts will have to cope with existing protocols, >> including IPv6 in the MIP6 tunnel without GRE which is already a fact >> of life. > >I agree MIP6 tunnel without GRE is already a fact of life. > >But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO. > >> My own suggestion is to be ready to receive these drafts as new WG >> items and carry them out swiftly, but not make a dependency for DS >> MIP on these discussions, either. DS-MIP has been pretty stable for a >> while, and the recent changes that were discussed (like the mapped >> CoA) were more on the religious side than fixing practical problems. > >Ok, somehow agree. > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ From nemo-bounces@ietf.org Fri May 18 04:40:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy16-0008WN-Oz; Fri, 18 May 2007 04:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy15-0008WC-KW; Fri, 18 May 2007 04:40:51 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoy13-0005bo-Qz; Fri, 18 May 2007 04:40:51 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hoy11-0005nX-1r; Fri, 18 May 2007 10:40:47 +0200 Message-ID: <464D668E.5090000@levkowetz.com> Date: Fri, 18 May 2007 10:40:46 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Vijay.Devarapalli@AzaireNet.com, ryuji.wakikawa@gmail.com, nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com, basavaraj.patil@nsn.com, amuhanna@nortel.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org, Basavaraj Patil , Ahmad Muhanna X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, on 2007-05-18 03:02 Vijay Devarapalli said the following: > Isn't the 4 byte overhead on every data packet in the voice > stream? Not just the BU/BAck. Yes, of course. Quite right. Wrong time of day for me, I guess. So the correct data depends on packet size, but not on BU interval. For a 1280 total packet size, this means the overhead is 4/1276, or 0.3%. For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 header is 20bytes, the first udp header 8, the IPv6 header 40, the second udp header is 8, and the rtp header is 12 bytes. Altogether 88 bytes header and 40 bytes payload, which gives the added overhead of 4 bytes and 4/128 = 3.1%. This is more serious, but also shows that we should probably consider whether we can reduce/compress the whole set of headers, rather than focus on the demultiplexing-enabling 4 bytes. It might even be the case that having the demultiplexing-enabling 4 bytes gives us the freedom we need to define alternative tunnelling with less overhead. Henrik > I must be missing something. > > Vijay > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Thursday, May 17, 2007 9:56 AM >> To: RYUJI WAKIKAWA >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli; Basavaraj >> Patil; Ahmad Muhanna >> Subject: Re: [nemo] Re: [Mip6] The use of GRE >> >> Hi Ryuji, >> >> on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: >> > Hi Henrik, >> > >> > I have to agree with you, but the additional 4 bytes in air >> > are also consumed scarce resource, i.e wireless... >> >> Humm. What is the bandwidth of your expected wireless link, >> how often do you send BUs, and how much other traffic? >> >> With very simple assumptions, like a voice stream and a BU >> every 4 minutes, you get: >> >> Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes >> 4 bytes overhead per BU/BA message = 8 bytes >> >> Extra overhead due to 4-byte header: 0.0016% >> >> I think we can ignore this. >> >> >> Henrik >> >> >> > regards, >> > ryuji >> > >> > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: >> > >> >> Folks, >> >> >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: >> >>> Hi Ryuji, >> >>> >> >>> If we agree that a new UDP port for GRE, beside the one for IPv4/ >> >>> IPv6, >> >>> is needed, then why do not we use a new UDP port to indicate the >> >>> presence of the TLV which then can be used to indicate the next >> >>> header >> >>> for many protocols including GRE and ESP. This way we >> save one UDP >> >>> port >> >>> if we want to support ESP as per Vijay's proposal. >> >> >> >> At least I am very far from agreeing on one additional assigned UDP >> >> port. The number of unassigned UDP port in the range that can be >> >> assigned by IANA (0 - 1023) is now down to 281, by my >> count, so this >> >> should be considered a scarce resource. >> >> >> >> I'm not even sure whether it makes sense to ask for a new >> port for >> >> DS-MIPv6 >> >> rather than multiplex over for instance the MIPv4 port, >> but I think >> >> we can >> >> at least ask the question. But asking for 2 ports, to carry 2 >> >> different >> >> kinds of DS-MIPv6 payloads, seems just wrong. >> >> >> >> >> >> Henrik >> > >> > >> >> > From nemo-bounces@ietf.org Fri May 18 04:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy1k-0000cO-TT; Fri, 18 May 2007 04:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy1j-0000cF-L5; Fri, 18 May 2007 04:41:31 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hoy1i-0005gQ-8U; Fri, 18 May 2007 04:41:31 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1179477689!15737789!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13826 invoked from network); 18 May 2007 08:41:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 18 May 2007 08:41:29 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4I8fS2T029026; Fri, 18 May 2007 01:41:29 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4I8fSgu016676; Fri, 18 May 2007 03:41:28 -0500 (CDT) Received: from [127.0.0.1] ([10.129.42.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4I8fPZV016655; Fri, 18 May 2007 03:41:26 -0500 (CDT) Message-ID: <464D66B5.2070509@gmail.com> Date: Fri, 18 May 2007 10:41:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> <46499FC4.5030506@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC03F2CB04@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03F2CB04@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-0, 17/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: nemo@ietf.org, Alexandru Petrescu , "Sri Gundavelli \(sgundave\)" , mip6@ietf.org Subject: [nemo] Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Alex: > > I'm surprised you're surprised. That's what L2TP has always been. > You might want to read about softwire, and in particular the new > developments in: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t > pv2-03.txt You're right, L2TP is to tunnel L2 packets. If GRE does the same thing as L2TP then why using GRE and not L2TP? Alex > > Pascal > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Tuesday, May 15, 2007 1:56 PM >> To: Pascal Thubert (pthubert) >> Cc: Narayanan, Vidya; Hesham Soliman; Sri Gundavelli (sgundave); > mip6@ietf.org; nemo@ietf.org >> Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: > [nemo] RE: [Mip6] The use of >> GRE) >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vidya >>> >>> I think the discussion started with the idea of making the DSMIP >>> tunnel more open to tunneling *anything*. This could be or have been >>> done separately from DSMIP, for instance at the time of MIP6 or NEMO. >>> If you look at it, all these protocols are tunnel set-up and >>> maintenance protocols, with the HoA as the ID for the tunnel. So why >>> tunnel only IPv6 in there? >>> >>> That was (one of) Hesham's valid point(s) when he started his DS-MIP >>> draft. So now we have support to tunnel IPv4, and we discriminate >>> with protocol type. And the issue comes like is that all we'll ever >>> need? Can't we make that more open for future use? And is this draft >>> the right time for opening up? >>> >>> One question was, which future use? >>> >>> One traditional use is L2 tunneling; >> IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2. This is >> an architectural mistake: IPv6-MACheader-IPv4-MACheader. >> >> I think this is what you are proposing with encapsulating L2 tunnelling >> in GRE, is it so? >> >>> if you want your MR to tunnel multiple flows treated as multiple >>> VLANs in the mobile network, you might want to keep the VLANs up to >>> the HA by inserting 802.1Q information, or the whole or compressed >>> Ethernet packet in the MRHA tunnel. >> I think it is not a good idea to intersperse an L2 header between two >> IPv6 base headers. >> >> I think it is not good idea to propagate 802.1q information between MR >> and HA. >> >>> The L3 alternative (multiple VRFs) is much more complex to deploy on >>> a MR. >> I am not sure what you mean. >> >> What is VRF? >> >> Also, the L3 alternative (using NEMOv6 base spec and not using L2 >> headers between base IPv6 headers), is implemented widely. I am not >> sure why you say it is much more complex. >> >>> So I do agree with the original point that there will be multiple >>> usages for that tunnel. At this point, I feel that we are back to a >>> previous discussion on reverse Routability test: in traditional MIP >>> or NEMO (without SeND) the MR can not be sure of its CoA, >> What do you mean? Do you mean that NEMOv6+SeND is not enough for >> securing MR ownership of its Care-of Address? And that NEMOv6+GRE >> encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe >> Care-of Address? >> >>> and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the >>> right place to solve a problem that was already there? >> Good question. I agree the security model with DS-MIPv6 and IPv4 >> Care-of Addresses is different than simple NEMOv6. But I don't see GRE >> a solution here. Why do you see GRE as a security solution for > DS-MIPv6? >> If HoA is used for identitying IP tunnels then IPsec SAs can link these >> HoAs, because HoA is an IP address. On the contrary, if GRE key is > used >> to identify tunnels then GRE key can not be used with IPsec SAs. >> Besides, I don't think there exist protocol selectors for GRE headers. >> >>> I suspect that we have made some clear room for a number of small >>> drafts that will apply to all MIP, DS-MIP and NEMO, to improve the >>> security of the system or like in this case make it more open to the >>> future. The new drafts will have to cope with existing protocols, >>> including IPv6 in the MIP6 tunnel without GRE which is already a fact >>> of life. >> I agree MIP6 tunnel without GRE is already a fact of life. >> >> But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO. >> >>> My own suggestion is to be ready to receive these drafts as new WG >>> items and carry them out swiftly, but not make a dependency for DS >>> MIP on these discussions, either. DS-MIP has been pretty stable for a >>> while, and the recent changes that were discussed (like the mapped >>> CoA) were more on the religious side than fixing practical problems. >> Ok, somehow agree. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nemo-bounces@ietf.org Fri May 18 14:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7dl-0007kh-8h; Fri, 18 May 2007 14:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7dk-0007iZ-E4; Fri, 18 May 2007 14:57:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7dk-0000Vj-2y; Fri, 18 May 2007 14:57:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Fri, 18 May 2007 11:57:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZKD2JhEPojzyBQaiTYPefHyxdogAVdT2w References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> From: "Vijay Devarapalli" To: "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org, Basavaraj Patil , Ahmad Muhanna X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Henrik,=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Friday, May 18, 2007 1:41 AM > To: Vijay Devarapalli > Cc: RYUJI WAKIKAWA; nemo@ietf.org; mip6@ietf.org; Sri=20 > Gundavelli; Basavaraj Patil; Ahmad Muhanna > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Vijay, >=20 > on 2007-05-18 03:02 Vijay Devarapalli said the following: > > Isn't the 4 byte overhead on every data packet in the voice > > stream? Not just the BU/BAck. >=20 > Yes, of course. Quite right. Wrong time of day for me, I guess. >=20 > So the correct data depends on packet size, but not on BU interval. > For a 1280 total packet size, this means the overhead is 4/1276, > or 0.3%. >=20 > For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 > header is 20bytes, the first udp header 8, the IPv6 header 40, the > second udp header is 8, and the rtp header is 12 bytes. Altogether > 88 bytes header and 40 bytes payload, which gives the added overhead > of 4 bytes and 4/128 =3D 3.1%. I would divide by 40, since we are calculating the overhead compared=20 to the actual payload, 4/40 =3D 10%. Vijay > This is more serious, but also shows that we should probably consider > whether we can reduce/compress the whole set of headers, rather than > focus on the demultiplexing-enabling 4 bytes. It might even be the > case that having the demultiplexing-enabling 4 bytes gives us the > freedom we need to define alternative tunnelling with less overhead. >=20 >=20 > Henrik >=20 >=20 > > I must be missing something. > >=20 > > Vijay=20 > >=20 > >> -----Original Message----- > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > >> Sent: Thursday, May 17, 2007 9:56 AM > >> To: RYUJI WAKIKAWA > >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli; Basavaraj=20 > >> Patil; Ahmad Muhanna > >> Subject: Re: [nemo] Re: [Mip6] The use of GRE > >>=20 > >> Hi Ryuji, > >>=20 > >> on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > >> > Hi Henrik, > >> >=20 > >> > I have to agree with you, but the additional 4 bytes in air > >> > are also consumed scarce resource, i.e wireless... > >>=20 > >> Humm. What is the bandwidth of your expected wireless link, > >> how often do you send BUs, and how much other traffic? > >>=20 > >> With very simple assumptions, like a voice stream and a BU > >> every 4 minutes, you get: > >>=20 > >> Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 bytes > >> 4 bytes overhead per BU/BA message =3D 8 bytes > >>=20 > >> Extra overhead due to 4-byte header: 0.0016% > >>=20 > >> I think we can ignore this. > >>=20 > >>=20 > >> Henrik > >>=20 > >>=20 > >> > regards, > >> > ryuji > >> >=20 > >> > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >> >=20 > >> >> Folks, > >> >> > >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >> >>> Hi Ryuji, > >> >>> > >> >>> If we agree that a new UDP port for GRE, beside the=20 > one for IPv4/=20 > >> >>> IPv6, > >> >>> is needed, then why do not we use a new UDP port to=20 > indicate the > >> >>> presence of the TLV which then can be used to indicate=20 > the next =20 > >> >>> header > >> >>> for many protocols including GRE and ESP. This way we=20 > >> save one UDP =20 > >> >>> port > >> >>> if we want to support ESP as per Vijay's proposal. > >> >> > >> >> At least I am very far from agreeing on one additional=20 > assigned UDP > >> >> port. The number of unassigned UDP port in the range=20 > that can be > >> >> assigned by IANA (0 - 1023) is now down to 281, by my=20 > >> count, so this > >> >> should be considered a scarce resource. > >> >> > >> >> I'm not even sure whether it makes sense to ask for a new=20 > >> port for =20 > >> >> DS-MIPv6 > >> >> rather than multiplex over for instance the MIPv4 port,=20 > >> but I think =20 > >> >> we can > >> >> at least ask the question. But asking for 2 ports, to carry 2 =20 > >> >> different > >> >> kinds of DS-MIPv6 payloads, seems just wrong. > >> >> > >> >> > >> >> Henrik > >> >=20 > >> >=20 > >>=20 > >>=20 > >=20 >=20 From nemo-bounces@ietf.org Fri May 18 21:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpDif-00030n-P9; Fri, 18 May 2007 21:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpDie-00030K-GJ; Fri, 18 May 2007 21:26:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpDid-0005Qn-61; Fri, 18 May 2007 21:26:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4J1QVf26395; Sat, 19 May 2007 01:26:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Mip6] The use of GRE Date: Fri, 18 May 2007 20:26:30 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371145D60D3@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceZKD2JhEPojzyBQaiTYPefHyxdogAVdT2wAAypjwA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, > > Subject: Re: [nemo] Re: [Mip6] The use of GRE > >=20 > > Hi Vijay, > >=20 > > on 2007-05-18 03:02 Vijay Devarapalli said the following: > > > Isn't the 4 byte overhead on every data packet in the=20 > voice stream?=20 > > > Not just the BU/BAck. > >=20 > > Yes, of course. Quite right. Wrong time of day for me, I guess. > >=20 > > So the correct data depends on packet size, but not on BU interval. > > For a 1280 total packet size, this means the overhead is 4/1276, or=20 > > 0.3%. > >=20 > > For a 16kbps voice stream, the payload size is 40 bytes, the IPv4=20 > > header is 20bytes, the first udp header 8, the IPv6 header 40, the=20 > > second udp header is 8, and the rtp header is 12 bytes. Altogether > > 88 bytes header and 40 bytes payload, which gives the added=20 > overhead=20 > > of 4 bytes and 4/128 =3D 3.1%. >=20 > I would divide by 40, since we are calculating the overhead=20 > compared to the actual payload, 4/40 =3D 10%. [Ahmad] Dividing by 40, IMO, is called a misleading and statically biased methodology. The wireless link does not know nor care what is payload and what is not. The wireless link probably cares that a packet of a length of 124 is now 128 after adding the TLV. I thought what Henrik was trying to quantify is the impact on the wireless link bandwidth due to the added 4 bytes TLV. On the other hand, let me say that this is almost the worst case scenario, however, for example if FTP in the picture and let us assume a packet length of 1300 bytes, then the impact is about 0.3%. One more thing, If we think of compressing this TLV, we probably end up with one byte! My 1.5 cents. :) >=20 > Vijay >=20 >=20 > > This is more serious, but also shows that we should=20 > probably consider=20 > > whether we can reduce/compress the whole set of headers,=20 > rather than=20 > > focus on the demultiplexing-enabling 4 bytes. It might even be the=20 > > case that having the demultiplexing-enabling 4 bytes gives us the=20 > > freedom we need to define alternative tunnelling with less overhead. > >=20 > >=20 > > Henrik > >=20 > >=20 > > > I must be missing something. > > >=20 > > > Vijay > > >=20 > > >> -----Original Message----- > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > >> Sent: Thursday, May 17, 2007 9:56 AM > > >> To: RYUJI WAKIKAWA > > >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli;=20 > Basavaraj Patil;=20 > > >> Ahmad Muhanna > > >> Subject: Re: [nemo] Re: [Mip6] The use of GRE > > >>=20 > > >> Hi Ryuji, > > >>=20 > > >> on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > > >> > Hi Henrik, > > >> >=20 > > >> > I have to agree with you, but the additional 4 bytes=20 > in air are=20 > > >> > also consumed scarce resource, i.e wireless... > > >>=20 > > >> Humm. What is the bandwidth of your expected wireless link, how=20 > > >> often do you send BUs, and how much other traffic? > > >>=20 > > >> With very simple assumptions, like a voice stream and a=20 > BU every 4=20 > > >> minutes, you get: > > >>=20 > > >> Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 = bytes > > >> 4 bytes overhead per BU/BA message =3D 8 bytes > > >>=20 > > >> Extra overhead due to 4-byte header: 0.0016% > > >>=20 > > >> I think we can ignore this. > > >>=20 > > >>=20 > > >> Henrik > > >>=20 > > >>=20 > > >> > regards, > > >> > ryuji > > >> >=20 > > >> > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > > >> >=20 > > >> >> Folks, > > >> >> > > >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > > >> >>> Hi Ryuji, > > >> >>> > > >> >>> If we agree that a new UDP port for GRE, beside the > > one for IPv4/ > > >> >>> IPv6, > > >> >>> is needed, then why do not we use a new UDP port to > > indicate the > > >> >>> presence of the TLV which then can be used to indicate > > the next > > >> >>> header > > >> >>> for many protocols including GRE and ESP. This way we > > >> save one UDP > > >> >>> port > > >> >>> if we want to support ESP as per Vijay's proposal. > > >> >> > > >> >> At least I am very far from agreeing on one additional > > assigned UDP > > >> >> port. The number of unassigned UDP port in the range > > that can be > > >> >> assigned by IANA (0 - 1023) is now down to 281, by my > > >> count, so this > > >> >> should be considered a scarce resource. > > >> >> > > >> >> I'm not even sure whether it makes sense to ask for a new > > >> port for > > >> >> DS-MIPv6 > > >> >> rather than multiplex over for instance the MIPv4 port, > > >> but I think > > >> >> we can > > >> >> at least ask the question. But asking for 2 ports,=20 > to carry 2=20 > > >> >> different kinds of DS-MIPv6 payloads, seems just wrong. > > >> >> > > >> >> > > >> >> Henrik > > >> >=20 > > >> >=20 > > >>=20 > > >>=20 > > >=20 > >=20 >=20 From nemo-bounces@ietf.org Sat May 19 02:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpI8m-00009x-2A; Sat, 19 May 2007 02:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpI8l-00008I-59; Sat, 19 May 2007 02:10:07 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpI8j-0003Xc-Gk; Sat, 19 May 2007 02:10:07 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HpI8d-000399-M8; Sat, 19 May 2007 08:09:59 +0200 Message-ID: <464E94B7.2060501@levkowetz.com> Date: Sat, 19 May 2007 08:09:59 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Vijay.Devarapalli@AzaireNet.com, nemo@ietf.org, sgundave@cisco.com, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vijay, on 2007-05-18 20:57 Vijay Devarapalli said the following: ... >> on 2007-05-18 03:02 Vijay Devarapalli said the following: >> > Isn't the 4 byte overhead on every data packet in the voice >> > stream? Not just the BU/BAck. >> >> Yes, of course. Quite right. Wrong time of day for me, I guess. >> >> So the correct data depends on packet size, but not on BU interval. >> For a 1280 total packet size, this means the overhead is 4/1276, >> or 0.3%. >> >> For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 >> header is 20bytes, the first udp header 8, the IPv6 header 40, the >> second udp header is 8, and the rtp header is 12 bytes. Altogether >> 88 bytes header and 40 bytes payload, which gives the added overhead >> of 4 bytes and 4/128 = 3.1%. > > I would divide by 40, since we are calculating the overhead compared > to the actual payload, 4/40 = 10%. No. That sounds as if the packet size increases by 10%, which it doesn't. As Ahmad says, that's misleading. Then you might as well pick a 1-byte payload, and claim the figure 400%. That would also be misleading. Both figures are technically correct under certain premises, but not helpful in this context. The figures 3.1% and 0.3% are the increased bandwidth consumption of the link in question, for these traffic types, if we do nothing about compression or header reduction. And regarding that, it would be interesting if you would also comment on the last part of my message (left in place below). Henrik > Vijay > > >> This is more serious, but also shows that we should probably consider >> whether we can reduce/compress the whole set of headers, rather than >> focus on the demultiplexing-enabling 4 bytes. It might even be the >> case that having the demultiplexing-enabling 4 bytes gives us the >> freedom we need to define alternative tunnelling with less overhead. >> >> >> Henrik From wrv@tds.net Mon May 21 06:59:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq5br-0006k9-Jh for nemo-archive@lists.ietf.org; Mon, 21 May 2007 06:59:28 -0400 Received: from [195.182.143.42] (helo=client143-42.unisnet.ru) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hq5bq-000879-VP for nemo-archive@lists.ietf.org; Mon, 21 May 2007 06:59:27 -0400 Received: (qmail 13451 invoked from network); Mon, 21 May 2007 14:59:27 +0400 Received: from unknown (HELO vzqtx) (71.130.234.34) by client143-42.unisnet.ru with SMTP; Mon, 21 May 2007 14:59:27 +0400 Message-ID: <000e01c79b97$197c4510$22ea8247@vzqtx> From: "best man" To: Subject: Specifies the URL of a web service provider. Date: Mon, 21 May 2007 14:59:27 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac GPSI Announces Market Attack Into $1 Trillion Market! Global Payment Solutions Symbol: GPSI Price: $0.03 GPSI announced its plans to address the huge influx of immigrant workers into the US that need banking solutions that they otherwise would not qualify for. This market is expected to represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! Next, you need to package the classes into a WAR file along with the deployment descriptor for web services, sun-jaxws. You can download the sample archive for the tip Writing a Handler in JAX-WS. You can fix that by changing the reverse method in the bean. It's used to transmit AJAX requests asynchronously over HTTP to a server-side component. This tip is second in the series. In this case, if the base is an instance of javax. DataSource, and JAXB objects. HandlerChain annotation with the location of the handler chain file. However, before doing that, here is some background on the VariableResolver and PropertyResolver classes and how they are used to evaluate a unified EL example expression. The client calls the credit card web service to authorize payment on a credit card provided by the customer. About the Author Ed Burns is a senior staff engineer at Sun Microsystems. TECH TIPS SURVEY Over the past year we've made some changes in the Enterprise Technologies Tech Tips. DataSource, and JAXB objects. For example, set the value of javaee. He currently works on the development of the JAX-WS Reference Implementation. Each interceptor in the chain can perform a specific operation before a business method is invoked or in response to a lifecycle event. HandlerChain, that can be used with JAX-WS code to specify handler chains associated with a port component or service. In the example of the unified EL expression, sessionScope is an implicit object. It's used to transmit AJAX requests asynchronously over HTTP to a server-side component. Allows web services to work directly with messages. This tip shows different ways to configure handlers on a web service client. After the artifacts are generated, they're compiled using the javac compiler. In the sample, the authorizePayment method is a utility method used to authorize charges on the credit card. The packaging is performed in the sample through an ant task that has the target build. AroundInvoke; import javax. You do this by specifying a Java EE qname-pattern in the element. If you haven't already done so, download GlassFish from the GlassFish Community Downloads page. Tech Tips Quiz Over the years, the Enterprise Java Technologies Tech Tips have covered a wide variety of enterprise Java technology topics. The testAuthorizePayment method creates a service using the url for the WSDL located on the server and the service QName identifying the wsdl:service element. Although the interceptor method in this example is defined in a separate class, it could have simply been added to the bean class itself. Because the JNDIELResolver simply adds JNDI capabilities to the EL, a null base argument means that it must look at the value of the property argument. Please specify a name for the item. Extract the contents of the sample package. The two new APIs are javax. " What the system does with the unitPrice property depends on the usage context. A major advantage of using a named query is that you can rerun it multiple times, providing different parameters for each run. Let's look at these steps and files a little closer. The environment variable is set by the script you executed earlier. In the sample, this is done using an ant task with the target name compile-server. A non-null base argument must be of type javax. The JavaServer Faces technology runtime calls myVariableResolver. Map implementation that wraps the attribute set for the current javax. This sets the handler chains for all the proxies created using that service. The three strategies are single table per class hierarchy, joined subclass, and single table per class. properties file as appropriate. The Dispatch instance invokes the service method using the Source object as input and gets output of type Source. jsp page calls the loadOrder method in the stateless session bean. war file, and deploys the . From zuxph@telia.com Mon May 21 15:13:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqDK2-000111-Mt for nemo-archive@lists.ietf.org; Mon, 21 May 2007 15:13:34 -0400 Received: from p54bb6d79.dip.t-dialin.net ([84.187.109.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HqDK1-0000CM-QT for nemo-archive@lists.ietf.org; Mon, 21 May 2007 15:13:34 -0400 Received: from [88.168.212.173] (helo=kxzs) by p54bb6d79.dip.t-dialin.net with smtp (Exim 4.62 (FreeBSD)) id 1IdPp-0001Ho-9Y; Mon, 21 May 2007 21:18:17 +0200 Message-ID: <000c01c79bdc$193d0bd0$add4a858@kxzs> From: "Ninette Petty" To: Subject: is an open source solution that is freely available to everybody. Date: Mon, 21 May 2007 21:13:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 GPSI Announces Market Attack Into $1 Trillion Market! Global Payment Solutions Symbol: GPSI Price: $0.03 GPSI announced its plans to address the huge influx of immigrant workers into the US that need banking solutions that they otherwise would not qualify for. This market is expected to represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! sanctions are in place. was simply waiting for a pretext to escalate into an attack on Iran, that was the perfect chance,'' but that was not to be, the Iran expert told a web-based forum. Just use this code below and replace BLOGURL with your blog's URL. Result: seven pairs of underwear from sympathetic fellow passengers. role in the region and evolve a regional cooperation mechanism. Soldier-bloggers have dropped offline as a result. In another entry, Heald recounts a passenger's anger that John would encourage tours of Istanbul's mosques. The weather was fine today but the smell was not. "This means there is more urgency than ever to reduce our emissions. His blog at johnheald. com Blogstorms Categories Homepage News Feeds Recent Headlines Resources RSS Feed Twitter Technorati Considering Widget Ads? Whether you're a die-hard fiction lover, a gadget geek, an avid collector of classic films or just a fan of what we sell, you'll find all sorts of entries that will interest you. Any authors you had subscribed to from Plogs have been transferred over to your Amazon Daily, as well as reminders and activity from friends. Most professional bloggers probably would not be happy with a widget that contained an ad because it would compete with other advertising already on their blogs. "They're censoring political views which they believe may incite terrorism. The guidelines essentially turn military commanders into editors and censors. You can see the menu in the screenshot below for a Google search for the keyword "test. Bloggers Blog: Print Magazine for Bloggers and Podcasters Launches BloggersBlog. Thus, while still being anxious about Iran's nuclear programme, the position of the GCC countries has dramatically altered from being mere spectators in the war of words between the U. "It was just such a blatant reflection of a society where the government is becoming increasingly scared of ideas, which I think reflects so poorly on the way we're headed," she says. "It was just such a blatant reflection of a society where the government is becoming increasingly scared of ideas, which I think reflects so poorly on the way we're headed," she says. That is political censorship," he says. Bloggers Blog: Army Clamps Down on Blogs Again BloggersBlog. The article says several more radio station social networks will be launched in June. Bloggers Blog: Technorati Considering Widget Ads? From nemo-bounces@ietf.org Mon May 21 21:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqInZ-0004qE-JG; Mon, 21 May 2007 21:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqInX-0004q5-Ke for nemo@ietf.org; Mon, 21 May 2007 21:04:23 -0400 Received: from criges14.insa-lyon.fr ([134.214.76.242] helo=smtp.insa-lyon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqInW-0006bU-3n for nemo@ietf.org; Mon, 21 May 2007 21:04:23 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 73850F3157 for ; Tue, 22 May 2007 03:04:19 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft3IY5cOKbO3 for ; Tue, 22 May 2007 03:04:19 +0200 (CEST) Received: from [134.214.215.58] (unknown [134.214.215.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvalois) by smtp.insa-lyon.fr (Postfix) with ESMTP id EA6BDF3145 for ; Tue, 22 May 2007 03:04:18 +0200 (CEST) Message-ID: <46524192.8040208@insa-lyon.fr> Date: Mon, 21 May 2007 21:04:18 -0400 From: Fabrice Valois User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [nemo] WiMob'07: Special Session on Mobility Models X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org CFP for IEEE WiMOB=922007 Special Session on Mobility Models for Mobile Ad hoc Networks, Mesh networks, Wireless networks and NEMO networks The session is a part of the 3rd IEEE International Conference on Wireless and Mobile Computing, Networking and Communications =93WiMob 2007=94 http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne Plaza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Because WiMob'07 conference is focused on wireless networks and because the performances of wireless networks are strongly linked to the mobility models used, we propose a special session focusing only on mobility models. This session is focused on these kind of wireless networks: - MANET: Mobile ad hoc networks where whole the topology is dynamic - Mesh networks and classical wireless networks offering an infrastructure topologies allowing fixed and mobile Internet for the end user. - Network Mobility (NEMO) networks offering new kind of dynamic topology where not only the user is mobile but also the network These kind of networks should deal with mobility: user mobility, group mobility, etc. But, what is really mobility? how mobility influences the performances? how to define new mobility models? etc. Scope of the Contributions for Mobility Models in the case of MANET, Mesh Networks, Wireless Networks and NEMO (include but are not limited to the following): - Performance evaluation of mobility models - New mobility models to mimic particular behavior - Theoretical aspects of mobility models - Theoretical frameworks for mobility - Mobility models based on realistic traces - Mobility management - Networking protocols and mobility models - Tools for mobility models (generators, integrators to simulators,..) - etc. Authors are invited to submit a complete technical paper of their original work. Maximum length for submissions is 8 double column pages in IEEE format. The preferred submission format is PDF. Accepted papers will be published as regular paper in the proceedings of WiMob 2007 and will be available in IEEE Xplore. Session Chair: Fabrice Valois, INSA Lyon, France Session Co-chair: Thomas Noel, University of Strasbourg, France Submissions should be sent attached by email to the session chairs at: fabrice.valois@insa-lyon.fr Thomas.Noel@dpt-info.u-strasbg.fr Important Dates : Manuscript Submission Due: May 25, 2007 Acceptance Notification: June 8, 2007 Final Manuscript Due: June 15, 2007 --=20 Fabrice Valois, Associate Professor INRIA ARES / CITI - INSA Lyon, Telecommunications Dpt. Web: http://fvalois.insa-lyon.fr/ Tel: +33 472 436 418 From nemo-bounces@ietf.org Tue May 22 00:43:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMDf-0001WP-Qk; Tue, 22 May 2007 00:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMDe-0001WH-LE; Tue, 22 May 2007 00:43:34 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqMDd-0002jU-CX; Tue, 22 May 2007 00:43:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Mon, 21 May 2007 21:43:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZKD2JhEPojzyBQaiTYPefHyxdogAVdT2wAAypjwAAnrCvoA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> <6FC4416DDE56C44DA0AEE67BC7CA4371145D60D3@zrc2hxm2.corp.nortel.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj Patil , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ahmad, =20 > > > For a 16kbps voice stream, the payload size is 40 bytes, the IPv4=20 > > > header is 20bytes, the first udp header 8, the IPv6=20 > header 40, the=20 > > > second udp header is 8, and the rtp header is 12 bytes. =20 > Altogether > > > 88 bytes header and 40 bytes payload, which gives the added=20 > > overhead=20 > > > of 4 bytes and 4/128 =3D 3.1%. > >=20 > > I would divide by 40, since we are calculating the overhead=20 > > compared to the actual payload, 4/40 =3D 10%. >=20 > [Ahmad] > Dividing by 40, IMO, is called a misleading and statically biased > methodology. The wireless link does not know nor care what is payload > and what is not. The wireless link probably cares that a packet of a > length of 124 is now 128 after adding the TLV. I thought what=20 > Henrik was > trying to quantify is the impact on the wireless link bandwidth due to > the added 4 bytes TLV. I was looking at how much overhead we are adding in addition to the existing overhead. Not in comparison to the existing overhead. I hope you see the difference.=20 > On the other hand, let me say that this is almost the worst case > scenario, however, for example if FTP in the picture and let=20 > us assume a > packet length of 1300 bytes, then the impact is about 0.3%. Of course. For large packets, this is not an issue. Vijay From nemo-bounces@ietf.org Tue May 22 00:50:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMK8-0007G7-Eb; Tue, 22 May 2007 00:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMK7-0007Ca-6n; Tue, 22 May 2007 00:50:15 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqMK5-0005dO-QT; Tue, 22 May 2007 00:50:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Mon, 21 May 2007 21:50:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZ3FhanKtMaQzBQWaBmBD9ekso5wCT6huQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> <464E94B7.2060501@levkowetz.com> From: "Vijay Devarapalli" To: "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Henrik, =20 > >> This is more serious, but also shows that we should probably = consider > >> whether we can reduce/compress the whole set of headers, rather = than > >> focus on the demultiplexing-enabling 4 bytes. It might even be the > >> case that having the demultiplexing-enabling 4 bytes gives us the > >> freedom we need to define alternative tunnelling with less = overhead. Yes, this is a good idea. I have come across an IPR'ed solution (not mine) in this space. It proposes to compress the inner=20 headers when you use IP-in-IP tunneling with Mobile IP (both v4 and v6). I don't have a reference to it now. Vijay From nemo-bounces@ietf.org Tue May 22 04:32:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPml-0007gY-Dj; Tue, 22 May 2007 04:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPmk-0007gO-3X for nemo@ietf.org; Tue, 22 May 2007 04:32:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqPmi-0004CT-RQ for nemo@ietf.org; Tue, 22 May 2007 04:32:02 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A9D7B1986A3 for ; Tue, 22 May 2007 11:31:59 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 698F9198675 for ; Tue, 22 May 2007 11:31:59 +0300 (EEST) Message-ID: <4652AA81.5000908@piuha.net> Date: Tue, 22 May 2007 11:32:01 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ml-nemo References: <20070215190321.c8b41447.thierry.ernst@inria.fr> In-Reply-To: <20070215190321.c8b41447.thierry.ernst@inria.fr> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [nemo] draft-ietf-nemo-multihoming-issues-07.txt situation X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, On my request, the chairs have solicited reviews from other WGs associated with the multihoming topic. Unfortunately, we did not receive any reviews. We have now decided to go for IETF Last Call and hope that we get at least some additional reviews during this period. Jari From ohyowrthj@tpnet.pl Tue May 22 08:07:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqT9U-0002SA-UF for nemo-archive@lists.ietf.org; Tue, 22 May 2007 08:07:44 -0400 Received: from gnq106.internetdsl.tpnet.pl ([83.3.94.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqT9T-0006NC-GV for nemo-archive@lists.ietf.org; Tue, 22 May 2007 08:07:44 -0400 From: "explains comments" To: nemo-archive@lists.ietf.org Subject: Aggressive Investors Alert Date: Tue, 22 May 2007 14:07:48 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C79C7A.94331F70" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcecepQzTo+vPkxPROen1o4ykmcNxg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <11F4BD21FA217E9.48EFD715BC@tpnet.pl> X-Spam-Score: 4.8 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0002_01C79C7A.94331F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andover Medical, Inc. Closes Acquisition of Ortho-Medical Products, Inc.

Andover Medical, Inc.
Symbol: ADOV.OB
Price: $0.60

Andover Medical, Inc. (OTC Bulletin Board: ADOV.OB), a single source provider of orthopedic, podiatric and urological durable medical equipment ("DME") and incontinence treatment solutions, announced today that it has closed the acquisition of Ortho-Medical Products, Inc. This is hot, read the news and watch for more on Tuesday!

Get on ADOV.OB first thing Tuesday!
------=_NextPart_000_0002_01C79C7A.94331F70-- From nemo-bounces@ietf.org Tue May 22 09:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqUK4-0002u0-Gm; Tue, 22 May 2007 09:22:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqUK1-0002tE-7B; Tue, 22 May 2007 09:22:41 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HqUJz-0004vJ-Ub; Tue, 22 May 2007 09:22:41 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D4C44175FC; Tue, 22 May 2007 13:22:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HqUJV-0004V3-KH; Tue, 22 May 2007 09:22:09 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 22 May 2007 09:22:09 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org Subject: [nemo] Last Call: draft-ietf-nemo-multihoming-issues (Analysis of Multihoming in Network Mobility Support) to Informational RFC X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The IESG has received a request from the Network Mobility WG (nemo) to consider the following document: - 'Analysis of Multihoming in Network Mobility Support ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12101&rfc_flag=0 From tko@invpro.com Tue May 22 11:12:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqW29-00042M-2L for nemo-archive@lists.ietf.org; Tue, 22 May 2007 11:12:21 -0400 Received: from [125.234.149.190] (helo=cunv) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HqW24-0004rP-BG for nemo-archive@lists.ietf.org; Tue, 22 May 2007 11:12:21 -0400 Received: (qmail 3391 invoked from network); Tue, 22 May 2007 22:12:09 +0700 Received: from unknown (HELO zex) (175.172.150.59) by cunv with SMTP; Tue, 22 May 2007 22:12:09 +0700 Message-ID: <000b01c79c83$90f850b0$3b96acaf@zex> From: "Win" To: Subject: Robin said she didn't see him at the end of the night. Date: Tue, 22 May 2007 22:12:09 +0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.7 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 GPSI Closes Deal To Increase Revenue By $2.9 Million Annually! Global Pay Solutions Inc. Sym: GPSI Monday Close: $0.031 The news is out and the deal is done. GPSI will provide 70,000 payroll cards in the Dominican Republic. Initial revenues of $400,000 will be followed by services fees over the year estimated at $2.5 Million. This is huge and only sets the beginning of their move into Latin America. Get on GPSI Today! Howard said he didn't do that and he's never done it on an airplane. Howard went around the room and asked the guys what they thought and then asked Tricia. The caller asked Tricia if she would ride the Sybian but Howard told him that she's too classy for that. In the clip Sal, as Fake Howard, says that he fucked Gary's wife in the ass. Gary told a story about how tired Artie was when he showed up down there. Gary said that Richard gets to a point where he starts slurring and telling everyone how much he loves them. Howard said that if he and Beth did get married, they wouldn't invite people to the ceremony but they would invite people to a reception party. They've been getting mistaken for each other for a while now. He said Bubba offered him some Vikodin and Percocet but Artie actually turned them down. Howard asked Gary about Ronnie's behavior at the wedding. Howard said he did run into him and then told a story about going out to eat on Friday night. He said it's not funny when he yells out ''Lets fuck some whores'' and things like that. Artie said he went to the reception when they were at the wedding and did go through the buffet himself one time. Bobo called in and asked Howard if he got horny on the plane and banged Beth. He said that Bubba actually bleeped it off the show down there. Howard claims that he does that for everyone, even Beetlejuice. Artie said there were some good looking girls there. That led to Robin saying that she saw Tim Sabean down there getting a massage and it was shocking to see him there. Howard got right back to Tricia and talked about how worked up he got watching some of her scenes in ''Battlestar Galictica. The guy was even talking about how gorgeous Heather was during the ceremony. He said one of the girls was cute but he was more attracted to this blonde at the bar across the street. Artie changed his vote after hearing all of this stuff and said that he'd have to vote him the biggest asshole. Howard said that if he and Beth did get married, they wouldn't invite people to the ceremony but they would invite people to a reception party. Howard figures that she will eventually get divorced and go to another man though. Howard checked out Tricia's pictures in Playboy and noticed that she covered up some areas. Sal agreed and said he doesn't have any racist thoughts. She said it was a curiosity thing and it was just a quick kiss. From djds@relyonmedia.com Tue May 22 11:28:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWHn-0000DW-NI for nemo-archive@lists.ietf.org; Tue, 22 May 2007 11:28:31 -0400 Received: from [125.234.149.190] (helo=cunv) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HqWHk-0003kB-4d for nemo-archive@lists.ietf.org; Tue, 22 May 2007 11:28:31 -0400 Received: from bfjh ([157.195.234.166]) by cunv with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 May 2007 22:28:22 +0700 Message-ID: <001e01c79c85$d58a9100$a6eac39d@bfjh> From: "Sullivan B. Leila" To: Subject: With some heavy hardware that would delight even the more demanding players and the best connections in pt, let's wait and see what they are capable of. Date: Tue, 22 May 2007 22:28:22 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001A_01C79CC0.81D8EE40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 ------=_NextPart_000_001A_01C79CC0.81D8EE40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001B_01C79CC0.81DD0CF0" ------=_NextPart_001_001B_01C79CC0.81DD0CF0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable "Product Description: Experience the dramatic intensity of the = frontlines of a war through the eyes of the first of a new breed of = super soldiers in this gritty and epic first-person action game. "But that's not the major update that we are here to talk about. "So, go to Spain, enjoy the weather and buy a Modded console. before knocking your lights out, while you watch them pounding to pieces = all of your built-with-care armies. Where would the great players be without a little God Mode, full = Weapons, Armour and Health or a little promenade through the walls ? = There you will find all the information you'll need to give a try at = this spectacular Half-Life Mod. The crew at Gang-Life on the other hand, = finished off their Glock Model. A veteran but still not knowing how to change between channels in mid = game ? Great news for the Portuguese EGaming community! Well, when it = comes to personal taste, you sure can't discuss it. This bonus level is being distributed with the consent of the FPS makers = and can be found here along with some instructions. Talk about making miracles in your own house. " which is great news to the MI series fans. More info at the Yahoo! It will also offer an amplified arsenal of = un-deadly weapons, bigger and badder bosses and the map editor Software = Development Kit. ------=_NextPart_001_001B_01C79CC0.81DD0CF0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D"recluse"
"Product Description: Experience the = dramatic=20 intensity of the frontlines of a war through the eyes of the first of a = new breed of=20 super soldiers in this gritty and epic first-person action = game.
"But that's not the major update that = we are here=20 to talk about.
"So, go to Spain, enjoy the weather and = buy a=20 Modded console.
before knocking your lights out, while = you watch=20 them pounding to pieces all of your built-with-care armies.
Where would the great players be = without a little=20 God Mode, full Weapons, Armour and Health or a little promenade through = the walls ?=20 There you will find all the information you'll need to give a try at = this=20 spectacular Half-Life Mod. The crew at Gang-Life on the other hand, = finished off=20 their Glock Model.
A veteran but still not knowing how to = change=20 between channels in mid game ? Great news for the Portuguese EGaming = community!=20 Well, when it comes to personal taste, you sure can't discuss = it.
This bonus level is being distributed = with the=20 consent of the FPS makers and can be found here along with some=20 instructions.
Talk about making miracles in your = own=20 house.
" which is great news to the MI = series=20 fans.
More info at the Yahoo! It will also = offer an=20 amplified arsenal of un-deadly weapons, bigger and badder bosses and the = map editor=20 Software Development Kit.
------=_NextPart_001_001B_01C79CC0.81DD0CF0-- ------=_NextPart_000_001A_01C79CC0.81D8EE40-- From nemo-bounces@ietf.org Wed May 23 22:20:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr2wD-0002BM-MA; Wed, 23 May 2007 22:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr2wC-0002Aw-1D for nemo@ietf.org; Wed, 23 May 2007 22:20:24 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr2wB-00020M-0Q for nemo@ietf.org; Wed, 23 May 2007 22:20:24 -0400 Received: by py-out-1112.google.com with SMTP id u52so740116pyb for ; Wed, 23 May 2007 19:20:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=nfGwZxbguwdGumzN4UfEAuLrHEd0SUg1igdtg17VVCApoGONZ8wjV4mlaPmsgE6VGBjfzv79QfYvfm3bgaL4cfcOSF6wPzvYfDogjPxY8HW3Sb8bEvQdkVaU6IdA+Ln3CYAE0DxjNpvNbg+JEALi+H5CbQF2BgsLCnaQEaz2mW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=eN3moBZfjXRFbpFBgNPTa/mfhfGLCmV6v/l68bBve/uGiE8sdC91cxmQ8vnnOKsanxw7k9NaZQrhPXaSRTIbPxlFAMiwuzBEfIquuhkV6XM/o9k/jquyV1PGZE/1gYkZHaAiZA0bDcXcGBk1uaG6ILbW9Y0wWkEKu6v/zN4I9Is= Received: by 10.35.41.8 with SMTP id t8mr2296007pyj.1179973221166; Wed, 23 May 2007 19:20:21 -0700 (PDT) Received: from ?203.178.143.190? ( [203.178.143.190]) by mx.google.com with ESMTP id n29sm3470189pyh.2007.05.23.19.20.17; Wed, 23 May 2007 19:20:19 -0700 (PDT) In-Reply-To: <464E94B7.2060501@levkowetz.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> <464E94B7.2060501@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <627BD674-CAF4-4F0A-8FA1-157EA9B8541D@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 24 May 2007 11:20:13 +0900 To: Henrik Levkowetz X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Sri Gundavelli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Henrik, sorry for my silence. Thanks for good analysis. In wireless, we should also consider the number of mobile nodes attached to the same access point. I just prefer decreasing the header parts from the packet as much as possible. As you show the example of VoIP, the header part is already two times bigger than the payload. BTW, I agree that some kind of header compression may be worth to apply here. regards, ryuji On 2007/05/19, at 15:09, Henrik Levkowetz wrote: > Hi Vijay, > > on 2007-05-18 20:57 Vijay Devarapalli said the following: > ... >>> on 2007-05-18 03:02 Vijay Devarapalli said the following: >>>> Isn't the 4 byte overhead on every data packet in the voice >>>> stream? Not just the BU/BAck. >>> >>> Yes, of course. Quite right. Wrong time of day for me, I guess. >>> >>> So the correct data depends on packet size, but not on BU interval. >>> For a 1280 total packet size, this means the overhead is 4/1276, >>> or 0.3%. >>> >>> For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 >>> header is 20bytes, the first udp header 8, the IPv6 header 40, the >>> second udp header is 8, and the rtp header is 12 bytes. Altogether >>> 88 bytes header and 40 bytes payload, which gives the added overhead >>> of 4 bytes and 4/128 = 3.1%. >> >> I would divide by 40, since we are calculating the overhead compared >> to the actual payload, 4/40 = 10%. > > No. That sounds as if the packet size increases by 10%, which it > doesn't. As Ahmad says, that's misleading. Then you might as well > pick a 1-byte payload, and claim the figure 400%. That would also > be misleading. Both figures are technically correct under certain > premises, but not helpful in this context. > > The figures 3.1% and 0.3% are the increased bandwidth consumption of > the link in question, for these traffic types, if we do nothing about > compression or header reduction. > > And regarding that, it would be interesting if you would also comment > on the last part of my message (left in place below). > > > Henrik > >> Vijay >> >> >>> This is more serious, but also shows that we should probably >>> consider >>> whether we can reduce/compress the whole set of headers, rather than >>> focus on the demultiplexing-enabling 4 bytes. It might even be the >>> case that having the demultiplexing-enabling 4 bytes gives us the >>> freedom we need to define alternative tunnelling with less overhead. >>> >>> >>> Henrik > From nemo-bounces@ietf.org Sat May 26 03:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrqiU-0004cP-Hj; Sat, 26 May 2007 03:29:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrqiT-0004au-CU; Sat, 26 May 2007 03:29:33 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HrqiR-0004wM-CE; Sat, 26 May 2007 03:29:33 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm174657e8b3; Sat, 26 May 2007 15:40:40 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2f46536b3b; Tue, 22 May 2007 21:40:02 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 22 May 2007 21:40:02 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqUK4-0002tY-EE; Tue, 22 May 2007 09:22:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqUK1-0002tE-7B; Tue, 22 May 2007 09:22:41 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HqUJz-0004vJ-Ub; Tue, 22 May 2007 09:22:41 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D4C44175FC; Tue, 22 May 2007 13:22:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HqUJV-0004V3-KH; Tue, 22 May 2007 09:22:09 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 22 May 2007 09:22:09 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nemo@ietf.org Subject: [nemo] Last Call: draft-ietf-nemo-multihoming-issues (Analysis of Multihoming in Network Mobility Support) to Informational RFC X-BeenThere: nemo@ietf.org Reply-To: ietf@ietf.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The IESG has received a request from the Network Mobility WG (nemo) to consider the following document: - 'Analysis of Multihoming in Network Mobility Support ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12101&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From nemo-bounces@ietf.org Mon May 28 10:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgGM-0006jW-6y; Mon, 28 May 2007 10:31:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgGD-0006Sj-QR for nemo@ietf.org; Mon, 28 May 2007 10:31:49 -0400 Received: from criges14.insa-lyon.fr ([134.214.76.242] helo=smtp.insa-lyon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsgGD-00085E-C7 for nemo@ietf.org; Mon, 28 May 2007 10:31:49 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id A67A7F318C for ; Mon, 28 May 2007 16:31:46 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQyLt3GDbIqH for ; Mon, 28 May 2007 16:31:46 +0200 (CEST) Received: from [132.207.169.229] (unknown [132.207.169.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvalois) by smtp.insa-lyon.fr (Postfix) with ESMTP id 45C48F3192 for ; Mon, 28 May 2007 16:31:46 +0200 (CEST) Message-ID: <465AE7D8.10505@insa-lyon.fr> Date: Mon, 28 May 2007 10:31:52 -0400 From: Fabrice Valois User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [nemo] WiMob'07: Special Session on Mobility Models -- EXTENDED DEALINE: June 6, 2007 -- X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org (*** NEW EXTENDED DEADLINE ***) (*** MANUSCRIPT SUBMISSION DUE: June 6, 2007 ***) CFP for IEEE WiMOB=922007 Special Session on Mobility Models for Mobile Ad hoc Networks, Mesh networks, Wireless networks and NEMO networks The session is a part of the 3rd IEEE International Conference on Wireless and Mobile Computing, Networking and Communications =93WiMob 2007=94 Accepted papers will be published as regular paper in the proceedings of WiMob 2007 and will be available in IEEE Xplore. http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne Plaza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Because WiMob'07 conference is focused on wireless networks and because the performances of wireless networks are strongly linked to the mobility models used, we propose a special session focusing only on mobility models. This session is focused on these kind of wireless networks: - MANET: Mobile ad hoc networks where whole the topology is dynamic - Mesh networks and classical wireless networks offering an infrastructure topologies allowing fixed and mobile Internet for the end user. - Network Mobility (NEMO) networks offering new kind of dynamic topology where not only the user is mobile but also the network These kind of networks should deal with mobility: user mobility, group mobility, etc. But, what is really mobility? how mobility influences the performances? how to define new mobility models? etc. Scope of the Contributions for Mobility Models in the case of MANET, Mesh Networks, Wireless Networks and NEMO (include but are not limited to the following): - Performance evaluation of mobility models - New mobility models to mimic particular behavior - Theoretical aspects of mobility models - Theoretical frameworks for mobility - Mobility models based on realistic traces - Mobility management - Networking protocols and mobility models - Tools for mobility models (generators, integrators to simulators,..) - etc. Authors are invited to submit a complete technical paper of their original work. Maximum length for submissions is 8 double column pages in IEEE format. The preferred submission format is PDF. Session Chair: Fabrice Valois, INSA Lyon, France Session Co-chair: Thomas Noel, University of Strasbourg, France Submissions should be sent attached by email to the session chairs at: fabrice.valois@insa-lyon.fr Thomas.Noel@dpt-info.u-strasbg.fr Important Dates : Manuscript Submission Due: June 6, 2007 Acceptance Notification: June 15, 2007 Final Manuscript Due: June 22, 2007 --=20 Fabrice Valois, Associate Professor INRIA ARES / CITI - INSA Lyon, Telecommunications Dpt. Web: http://fvalois.insa-lyon.fr/ From nemo-bounces@ietf.org Thu May 31 05:19:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtgoD-0006N3-Dl; Thu, 31 May 2007 05:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtgoB-0006Mk-SE for nemo@ietf.org; Thu, 31 May 2007 05:19:03 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtgoA-0001cM-DM for nemo@ietf.org; Thu, 31 May 2007 05:19:03 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 23B0A200CAB3; Thu, 31 May 2007 11:38:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmiBg4voNwdZ; Thu, 31 May 2007 11:38:09 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0AFA3200017E; Thu, 31 May 2007 11:37:59 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2007 11:18:50 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD6960113890A@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-eddy-nemo-aero-reqs-00 Thread-Index: AcejZLOC38JDSHgoQlGWIh3g24YwHQ== From: "Roberto Baldessari" To: "Wesley Eddy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [nemo] Comments on draft-eddy-nemo-aero-reqs-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear Wesley, I read your draft and found it to be well focused with the WG goal and = also clear. Indeed, it helps us in refining the automotive requirements = in order them to be more focused on RO. In particular most of the described requirements are precise and, I = think, helpful for solution designers (i.e. separability, latency, = security and integrity). Some others are not clear to me or, better, I = think they are not exclusively or directly related to RO: - Req4 (availability): in my opinion any RO scheme will alleviate the = problem of a single point of failure instead of creating it. Or do you = mean that RO should work even if the HA is not available? We also = pointed out this, but then I've realized that "internet-less" RO might = distract the WG and prevent it to come to (at least) a basic RO scheme = MIPv6-like. RO without infrastructure should better be the focus of = other WGs - Req6 (scalability): it is hard to determine whether an RO scheme is = scalable in terms of signaling, as it depends on other variables = (network capacity, mobility,...). More than a absolute requirement, I = consider this as an important criterion in relative terms. I.e. a = solution with lower signaling will be preferred compared with one with = higher signaling - Req8 (security): I think it would be beneficial to specify whether or = not you require IPsec to be usable for LFN or only in the RO signaling = or in the tunnel MR-HA. We will also try to specify something more about = security in the automotive requirements. Best regards, Roberto =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Roberto Baldessari Research Staff Member Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-167 Fax: +49 (0)6221 4342-55 e-mail: roberto.baldessari@netlab.nec.de web: http://www.netlab.nec.de/ NEC Europe Limited | Registered Office:=20 NEC House, 1 Victoria Road, London W3 6BL=20 Registered in England 2832014=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Thu May 31 09:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkaR-0000sw-NX; Thu, 31 May 2007 09:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkaQ-0000sr-HT for nemo@ietf.org; Thu, 31 May 2007 09:21:06 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtkaO-0001Oh-Vv for nemo@ietf.org; Thu, 31 May 2007 09:21:06 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id CE7D2C21F for ; Thu, 31 May 2007 09:21:03 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l4VDL3tQ006526; Thu, 31 May 2007 09:21:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l4VDKsD1009706; Thu, 31 May 2007 09:20:56 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id T5nnptKfDcx5; Thu, 31 May 2007 09:20:54 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l4VDKoGi009644;Thu, 31 May 2007 09:20:50 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 963694FE94; Thu, 31 May 2007 09:19:18 -0400 (EDT) Date: Thu, 31 May 2007 09:19:18 -0400 From: Wesley Eddy To: Roberto Baldessari Message-ID: <20070531131918.GA30387@grc.nasa.gov> References: <113091BD57179D4491C19DA7E10CD6960113890A@mx1.office> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <113091BD57179D4491C19DA7E10CD6960113890A@mx1.office> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:90.55909 C:2 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org, MPI@multicasttech.com Subject: [nemo] Re: Comments on draft-eddy-nemo-aero-reqs-00 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Thu, May 31, 2007 at 11:18:50AM +0200, Roberto Baldessari wrote: > > Dear Wesley, > > I read your draft and found it to be well focused with the WG goal and > also clear. Indeed, it helps us in refining the automotive requirements > in order them to be more focused on RO. Good; thanks for the constructive comments. Here are some responses: > In particular most of the described requirements are precise and, I > think, helpful for solution designers (i.e. separability, latency, > security and integrity). Some others are not clear to me or, better, I > think they are not exclusively or directly related to RO: I think you're right, and we should at the very least refine the wording on the 3 requirements you mention (availability, scalability, and security). > - Req4 (availability): in my opinion any RO scheme will alleviate the > problem of a single point of failure instead of creating it. Or do you > mean that RO should work even if the HA is not available? We also > pointed out this, but then I've realized that "internet-less" RO might > distract the WG and prevent it to come to (at least) a basic RO scheme > MIPv6-like. RO without infrastructure should better be the focus of > other WGs Personally, I hadn't been thinking about the Internet-less case of not being able to reach any HA, but rather I was trying to say that it won't be acceptable for a solution to only work under the assumption that a single MR services a mobile network, or a single HA or access router services an MR (or set of MRs). In other words, we need the solution to co-exist peacefully with both HA reliability mechanisms (e.g. the one MIP6 is working on), multihoming mechanisms, and with multiple MRs. Do you think it would be more clear if I added a sentence that specifically excluded Internet-less operation from being required? > - Req6 (scalability): it is hard to determine whether an RO scheme is > scalable in terms of signaling, as it depends on other variables > (network capacity, mobility,...). More than a absolute requirement, I > consider this as an important criterion in relative terms. I.e. a > solution with lower signaling will be preferred compared with one with > higher signaling Agreed; this is an important metric, but one that's fairly scenario-dependent in measurement and evaluation. For aircraft, the mobility patterns are tough to guess at because they depend on the link technologies used. Since many of the current links are very low-rate, basing an analysis on them may not be particularly useful, although I gave some rough estimate of the time between changing VDL channels in the draft. I will check and see if the COCR document from the FAA/Eurocontrol Future Communications Study has any guidance on how we can specify scalability in greater detail for aeronautics. > - Req8 (security): I think it would be beneficial to specify whether > or not you require IPsec to be usable for LFN or only in the RO > signaling or in the tunnel MR-HA. We will also try to specify something > more about security in the automotive requirements. I think it should be possible to use in both cases, although it must be understood that in some cases, the security mechanisms can undo the RO, as Will Ivancic is very good at explaining :). My goals for this requirement were to (1) ensure that the data used to make RO decisions can be authenticable, and (2) ensure that flows using transport-mode IPsec can use RO between the two end-points, and flows using tunnel-mode IPsec can get RO between the MR and the groundward side of the tunnel. If I put some more explanation of this into the draft, would that help? I would be interested in reviewing the automotive requirements, if/when they are available. I'm not sure how similar they will be to the aero requirements, but it would be really neat if a common solution was acceptable for both. -- Wesley M. Eddy Verizon Federal Network Systems