From pierrick.seite@orange-ftgroup.com Tue Nov 3 01:40:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A1F3A698F for ; Tue, 3 Nov 2009 01:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cer9BDdqx4Yo for ; Tue, 3 Nov 2009 01:40:08 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B488A3A680F for ; Tue, 3 Nov 2009 01:40:07 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 10:40:24 +0100 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: Tue, 3 Nov 2009 10:40:26 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4626FFADE@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version of draft-sarikaya-mif-dhcpv6solution Thread-Index: Acoxe1SihhrTm3cTQo2kzWJvqt306wq7ZEKg From: To: X-OriginalArrivalTime: 03 Nov 2009 09:40:24.0992 (UTC) FILETIME=[AB5ED200:01CA5C69] Subject: [mif] New Version of draft-sarikaya-mif-dhcpv6solution X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:40:09 -0000 Hello, A new version of draft-sarikaya-mif-dhcpv6solution (http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution) has been posted. This document defines DHCPv6 options to configure the multi-homed host's routing table. Comments are welcomed. Regards, Pierrick =20 > ----- Forwarded Message ---- > From: IETF I-D Submission Tool > To: sarikaya@ieee.org > Cc: xiayangsong@huawei.com; pierrick.seite@orange-ftgroup.com > Sent: Wednesday, September 9, 2009 11:18:28 AM > Subject: New Version Notification for draft-sarikaya-mif- dhcpv6solution-02 > > > A new version of I-D, draft-sarikaya-mif-dhcpv6solution-02.txt has been > successfuly submitted by Behcet Sarikaya and posted to the IETF repository. > > Filename: draft-sarikaya-mif-dhcpv6solution > Revision: 02 > Title: DHCPv6 Extension for Configuring Hosts with Multiple Interfaces > Creation_date: 2009-09-08 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This document defines a DHCPv6 option to help configure a multi-homed > host's routing table with new entries when the host attaches to a new > network on a new interface. > > > > > The IETF Secretariat. =20 >=20 >=20 >=20 From lars.eggert@nokia.com Tue Nov 3 09:28:05 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9BC28C136 for ; Tue, 3 Nov 2009 09:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXFQKFUNDy0n for ; Tue, 3 Nov 2009 09:28:04 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 9843F28C114 for ; Tue, 3 Nov 2009 09:28:04 -0800 (PST) Received: from [192.168.1.21] (adsl-99-145-150-174.dsl.pltn13.sbcglobal.net [99.145.150.174]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA3HRVDj045835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 19:28:12 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-6--210825220; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4626FFADE@ftrdmel0.rd.francetelecom.fr> Date: Tue, 3 Nov 2009 09:27:28 -0800 Message-Id: References: <843DA8228A1BA74CA31FB4E111A5C4626FFADE@ftrdmel0.rd.francetelecom.fr> To: pierrick.seite@orange-ftgroup.com X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Tue, 03 Nov 2009 19:28:17 +0200 (EET) Cc: "mif@ietf.org" Subject: Re: [mif] New Version of draft-sarikaya-mif-dhcpv6solution X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:28:05 -0000 --Apple-Mail-6--210825220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-11-3, at 1:40, pierrick.seite@orange-ftgroup.com wrote: > A new version of draft-sarikaya-mif-dhcpv6solution > (http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution) has > been > posted. > > This document defines DHCPv6 options to configure the multi-homed > host's > routing table. maybe I'm misunderstanding the charter, but I was under the impression that new protocols and protocol extensions are out of scope? Lars --Apple-Mail-6--210825220 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzE3MjcyOVowIwYJKoZIhvcNAQkEMRYEFHE+ZVt7YeBTXUpAXzOvzmPHLnBEMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC0TvGXEBeolmuREK0VuNb2SBLgxDdwss4IvTG4Yb3zyPMW4Wey7vPv9C+SJRhFCFS0ZHiR GihbD+f1tzbYFoB3/6tGPIV6mTPlq9H5f3Bmw1BQfuCdqr11KPlpwWNhTZnESSaETO/EXHGk2t5f M1RLDReA+ag5AMXt+LFH6mGp0gDbTeqqoDbSSmEpjIvDsBaB0YQRcL95SnliUVcrmkRHOilFveP/ lQCW0+1QEaYszofBJ8lOuWsZWPJIaiN20e8O6w/lV7Ddv//hP/s065kPwrGAwkgGA/WCbNuoto9Y DznddEfXWNqfL5eF2KbobF4FfLWdpGRU3X4S89c3a+6UAAAAAAAA --Apple-Mail-6--210825220-- From mrw@sandstorm.net Tue Nov 3 10:22:56 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9DF28C139 for ; Tue, 3 Nov 2009 10:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSBm4otGS4fZ for ; Tue, 3 Nov 2009 10:22:56 -0800 (PST) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id CC56F3A68CD for ; Tue, 3 Nov 2009 10:22:55 -0800 (PST) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id nA3INDT2003367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 13:23:13 -0500 (EST) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 13:23:13 -0500 References: <843DA8228A1BA74CA31FB4E111A5C4626FFADE@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) Cc: "mif@ietf.org" Subject: Re: [mif] New Version of draft-sarikaya-mif-dhcpv6solution X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:22:56 -0000 Hi Lars, You are right, Lars, solution documents are out of scope for the current MIF WG charter. We are currently chartered to work on (1) a problem statement, (2) a document that outlines current practices in this area, and (3) a document that analyzes those current practices. That said, there are several solution-space documents out there. Some of them are in current IETF WGs (such as 6man or DHCP), and some of them are not chartered in the IETF yet. Some people have chosen to make the MIF group aware of their ongoing work in this area. We do understand that MIF is not chartered to do any solutions work at this time. Margaret On Nov 3, 2009, at 12:27 PM, Lars Eggert wrote: > Hi, > > On 2009-11-3, at 1:40, pierrick.seite@orange-ftgroup.com wrote: >> A new version of draft-sarikaya-mif-dhcpv6solution >> (http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution) has >> been >> posted. >> >> This document defines DHCPv6 options to configure the multi-homed >> host's >> routing table. > > maybe I'm misunderstanding the charter, but I was under the > impression that new protocols and protocol extensions are out of > scope? > > Lars_______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From lars.eggert@nokia.com Tue Nov 3 13:05:39 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AAA3A68B3 for ; Tue, 3 Nov 2009 13:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHm5qLQDo-tF for ; Tue, 3 Nov 2009 13:05:38 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 817413A686C for ; Tue, 3 Nov 2009 13:05:38 -0800 (PST) Received: from [192.168.1.47] ([12.162.0.169]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA3L5mhh059443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 23:05:50 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-11--197738281; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Tue, 3 Nov 2009 13:05:35 -0800 Message-Id: References: <843DA8228A1BA74CA31FB4E111A5C4626FFADE@ftrdmel0.rd.francetelecom.fr> To: Margaret Wasserman X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Tue, 03 Nov 2009 23:05:52 +0200 (EET) Cc: "mif@ietf.org" Subject: Re: [mif] New Version of draft-sarikaya-mif-dhcpv6solution X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:05:39 -0000 --Apple-Mail-11--197738281 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, thanks for clarifying. I think it's totally appropriate to make these sorts of ideas known to MIF participants even under the current charter. Lats On 2009-11-3, at 10:23, Margaret Wasserman wrote: > > Hi Lars, > > You are right, Lars, solution documents are out of scope for the > current MIF WG charter. We are currently chartered to work on (1) a > problem statement, (2) a document that outlines current practices in > this area, and (3) a document that analyzes those current practices. > > That said, there are several solution-space documents out there. Some > of them are in current IETF WGs (such as 6man or DHCP), and some of > them are not chartered in the IETF yet. Some people have chosen to > make the MIF group aware of their ongoing work in this area. We do > understand that MIF is not chartered to do any solutions work at this > time. > > Margaret > > > On Nov 3, 2009, at 12:27 PM, Lars Eggert wrote: > >> Hi, >> >> On 2009-11-3, at 1:40, pierrick.seite@orange-ftgroup.com wrote: >>> A new version of draft-sarikaya-mif-dhcpv6solution >>> (http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution) has >>> been >>> posted. >>> >>> This document defines DHCPv6 options to configure the multi-homed >>> host's >>> routing table. >> >> maybe I'm misunderstanding the charter, but I was under the >> impression that new protocols and protocol extensions are out of >> scope? >> >> Lars_______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > --Apple-Mail-11--197738281 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzIxMDUzNlowIwYJKoZIhvcNAQkEMRYEFIA5T0dKwBHUmGudEPa/hrQfgGqbMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAEZp1ClpPaOzyqmcuQiHNiN33y5YLxJb7cXv7B9ObVy5xK+SCNOU1MHfnV3paJ5d6CsN80 j79u5uWkmYMlPjhvtW4HT3/ABAXoVOIbKey/kzUhhAljLWTju6auwxL1XjALPCMmrzGNoPgJnPoA uqR4K42fh597noTkkoICyNAvyq6wigABDGtBzXXu4eOdslDUpBQiX+ZVcN7JflXNqinm1cU79aXz MlZmeGqhZvoxaVvzmoTt1Gd5dP3N6ecScDlA7g4rPsM5B8ExrqTqgyfNKLSvW5ZNLyfbdgDfptEA RtXm0w56P4H7wzCMiG+a1LqfhLKwk5doCWjGooF4X/KoAAAAAAAA --Apple-Mail-11--197738281-- From mglt.ietf@gmail.com Thu Nov 5 06:48:39 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D1C3A6ACA; Thu, 5 Nov 2009 06:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30WEcuWXjdsx; Thu, 5 Nov 2009 06:48:38 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id E1DFE3A6AB7; Thu, 5 Nov 2009 06:48:37 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so19545gvc.15 for ; Thu, 05 Nov 2009 06:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UosYlT4cHZFLu8YCDFkE/F3I0RvHsKXU2hoMJVh1X24=; b=pngIvEJ9EKW2WCeqnPdbP9qyOxhyHLI1a74vJHv/UFfgbm6Z4SRZX2QoFS7Cts/lHD /fB21F5foWL0iXsoyhmMCTyX2dEIylbAevSBklGb6xJ9zszuqMPicOs/eztZ1ZD8iEOQ q1XBPBP6cNalDEWtag8wTQhxthF7Xtp4kDtoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j65pGnmFugRE44wPvn8be8OVe08ldZqqtH1UBzko/l/WI9GzTcz+BeN8n4ucFiPTM8 NqcMY3SDq2nzNbsj6TBfeXZKCiVdppF/eYWb2fYW9t/C8f6KQtFe9S2v6w2O7SroOO0O EcFveLk0O+v+Z2lokiKxGLyj8L/c/Z76K22UY= MIME-Version: 1.0 Received: by 10.102.197.14 with SMTP id u14mr1179348muf.39.1257432536138; Thu, 05 Nov 2009 06:48:56 -0800 (PST) In-Reply-To: References: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> Date: Thu, 5 Nov 2009 15:48:56 +0100 Message-ID: <51eafbcb0911050648u61f05eaamd6b94e608109e392@mail.gmail.com> From: Daniel Migault To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: multipart/alternative; boundary=0016364d274ba544800477a0d390 Cc: ipsec@ietf.org, multipathtcp@ietf.org, mif@ietf.org Subject: Re: [mif] [multipathtcp] IPsec multihoming and mobility X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 14:48:39 -0000 --0016364d274ba544800477a0d390 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for your comment, I appreciate your feed back. Sections of the requirements draft on SCTP, SHIM6 should be filled, and I will mention RFC3554 in the SCTP section. In both drafts we consider only IKEv2, so I don't think RFC3554 is really relevant. I am not an expert on IKEv1, but it looks that features introduce= d by RFC3554 are not longer necessary since with IKEv2 since IKEv2 provides the ability to negotiate multiple Traffic Selector, and TS are not associated to the ID Payload anymore. On the other hand IKEv2 or IKEv1 and RFC3554 does not enable to modify the Traffic Selectors of the Security Association. And this is one of the thing we address in the drafts. Regards, Daniel On Wed, Oct 21, 2009 at 3:44 PM, Michael T=FCxen < Michael.Tuexen@lurchi.franken.de> wrote: > Hi Daniel, > > have you looked at > http://www.ietf.org/rfc/rfc3554.txt > > Best regards > Michael > > > On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote: > > Hi folks, >> >> We are currently working on IPsec issues and multihoming. Here are our >> starting work with a presentation of scenarios and requirements we addre= ss, >> as well as the design of an extension to MOBIKE. >> >> Scenarios and Requirements : >> http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 >> >> Protocol Design : >> http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 >> >> We are currently working implementing it, and looking on how other >> multihoming protocol can benefit from it. >> >> Feed backs and comments are really appreciated. >> >> Regards, >> >> Daniel >> >> >> -- >> Daniel Migault >> Orange Labs -- Security >> +33 6 70 72 69 58 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364d274ba544800477a0d390 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

Thanks for your comment, I appreciate your feed back. <= br>
Sections of the requirements draft on SCTP, SHIM6 should be filled, = and I will mention RFC3554 in the SCTP section.

In both drafts we c= onsider only IKEv2, so I don't think RFC3554 is really relevant. I am n= ot an expert on IKEv1, but it looks that features introduced by RFC3554 are= not longer necessary since with IKEv2 since IKEv2 provides the ability to = negotiate multiple Traffic Selector, and TS are not associated to the ID Pa= yload anymore.

On the other hand IKEv2 or IKEv1 and RFC3554 does not=A0 enable to modi= fy the Traffic Selectors of the Security Association. And this is one of th= e thing we address in the drafts.

Regards,

Daniel

On Wed, Oct 21, 2009 at 3:44 PM, Michael T=FCxen= <= Michael.Tuexen@lurchi.franken.de> wrote:
Hi Daniel,

have you looked at
http://ww= w.ietf.org/rfc/rfc3554.txt

Best regards
Michael


On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote:

=
Hi folks,

We are currently working on IPsec issues and multihoming. Here are our star= ting work with a presentation of scenarios and requirements we address, as = well as the design of an extension to MOBIKE.

Scenarios and Requirements :
http://tools.ietf.org/html/draft-mglt-ipsec-mm-requiremen= ts-00

Protocol Design :
http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00<= br>
We are currently working implementing it, and looking on how other multihom= ing protocol can benefit from it.

Feed backs =A0and comments are really appreciated.

Regards,

Daniel


--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp




--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--0016364d274ba544800477a0d390-- From marc.blanchet@viagenie.ca Sun Nov 8 22:55:22 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E0A3A69A5 for ; Sun, 8 Nov 2009 22:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3UbomKaenAU for ; Sun, 8 Nov 2009 22:55:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4A4173A6915 for ; Sun, 8 Nov 2009 22:55:21 -0800 (PST) Received: from host-19-125.meeting.ietf.org (host-19-125.meeting.ietf.org [133.93.19.125]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D263C210FD for ; Mon, 9 Nov 2009 01:55:46 -0500 (EST) Message-ID: <4AF7BCF0.9050105@viagenie.ca> Date: Mon, 09 Nov 2009 15:55:44 +0900 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:55:22 -0000 Hi, following the two comments on the mic about adding some text in the PS about API/Connection manager, here is first text proposal that would be added to section 5. "Some implementations, specially in the mobile world, have higher-level API and/or connection managers. These mechanisms are not standardized and do not necessarily behave the same way in the presence of the MIF problems. Therefore, a standard API could be considered." Please put more meat around the bone... Regards, Marc. From pierrick.seite@orange-ftgroup.com Mon Nov 9 08:24:44 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960673A683E for ; Mon, 9 Nov 2009 08:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg6vEVncSpeC for ; Mon, 9 Nov 2009 08:24:43 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 568433A6B9B for ; Mon, 9 Nov 2009 08:24:43 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 17:25:06 +0100 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: Mon, 9 Nov 2009 17:25:07 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4AF7BCF0.9050105@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] problem-statement: api Thread-Index: AcphCayNGvZAtURQT5SdUysw/rOHZwAN4cwg References: <4AF7BCF0.9050105@viagenie.ca> From: To: , X-OriginalArrivalTime: 09 Nov 2009 16:25:06.0865 (UTC) FILETIME=[32F91A10:01CA6159] Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:24:44 -0000 Hi, I couldn't attend the meeting, so I don't know exactly what it has been = said. However, I agree the ps should address API/Connection manager. = Actually, I think this feature is worth a dedicated section. So, based = on Marc's proposal, I'd propose the following text, please feel free to = comment/modify:=20 x. Connection management Some implementations, specially in the mobile world, have higher-level API, and/or connection managers, to address IP configuration issues in a = context of multiple provisioning domains. Depending on the = implementation, and/or OS, these mechanisms do not necessarily behave = the same way in the presence of the MIF problems = [draft-ietf-mif-current-practices]. Therefore, at least, standardization = of such an API should be considered in order to facilitate = implementation of mechanisms addressing MIF issues. In the same way, = harmonized behaviour of connection manager across different = implementations and/or OS would bring more consistency for MIF users; in = such a case, standardization of a framework for connection manager, = would be valuable.=20 Then in section 5, I'd reword a little bit the Marc's text: * When available, implementation of multiple interfaces API and/or = connection managers do not necessarily behave the same way in the = presence of the MIF problems. API and/or framework for connection = managers should be standardized for the sake of harmonization in = addressing MIF issues.=20 Feel free to comment. Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Marc > Blanchet > Envoy=E9=A0: lundi 9 novembre 2009 07:56 > =C0=A0: mif@ietf.org > Objet=A0: [mif] problem-statement: api >=20 > Hi, > following the two comments on the mic about adding some text in the = PS > about API/Connection manager, here is first text proposal that would = be > added to section 5. >=20 > "Some implementations, specially in the mobile world, have = higher-level > API and/or connection managers. These mechanisms are not standardized > and do not necessarily behave the same way in the presence of the MIF > problems. Therefore, a standard API could be considered." >=20 > Please put more meat around the bone... >=20 > Regards, Marc. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From miika.komu@hiit.fi Mon Nov 9 09:46:30 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7AA28C1BB for ; Mon, 9 Nov 2009 09:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo6MFSPoszHf for ; Mon, 9 Nov 2009 09:46:29 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id F0C4428C0DF for ; Mon, 9 Nov 2009 09:46:28 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id CC00725ED11; Mon, 9 Nov 2009 19:46:53 +0200 (EET) Message-ID: <4AF855B7.2000708@hiit.fi> Date: Mon, 09 Nov 2009 19:47:35 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4AF7BCF0.9050105@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:46:30 -0000 pierrick.seite@orange-ftgroup.com wrote: Hi, I have sent this link earlier to this mailing list but there was no discussion or comments: http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api http://www.ietf.org/mail-archive/web/mif/current/msg00549.html Would it be possible to have a section referencing this work in the problem statement draft? The draft is all about multihoming and APIs after all. > Hi, > > I couldn't attend the meeting, so I don't know exactly what it has been said. However, I agree the ps should address API/Connection manager. Actually, I think this feature is worth a dedicated section. So, based on Marc's proposal, I'd propose the following text, please feel free to comment/modify: > > x. Connection management > > Some implementations, specially in the mobile world, have higher-level > API, and/or connection managers, to address IP configuration issues in a context of multiple provisioning domains. Depending on the implementation, and/or OS, these mechanisms do not necessarily behave the same way in the presence of the MIF problems [draft-ietf-mif-current-practices]. Therefore, at least, standardization of such an API should be considered in order to facilitate implementation of mechanisms addressing MIF issues. In the same way, harmonized behaviour of connection manager across different implementations and/or OS would bring more consistency for MIF users; in such a case, standardization of a framework for connection manager, would be valuable. > > Then in section 5, I'd reword a little bit the Marc's text: > > * When available, implementation of multiple interfaces API and/or connection managers do not necessarily behave the same way in the presence of the MIF problems. API and/or framework for connection managers should be standardized for the sake of harmonization in addressing MIF issues. > > Feel free to comment. > > Regards, > Pierrick > >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Marc >> Blanchet >> Envoyé : lundi 9 novembre 2009 07:56 >> À : mif@ietf.org >> Objet : [mif] problem-statement: api >> >> Hi, >> following the two comments on the mic about adding some text in the PS >> about API/Connection manager, here is first text proposal that would be >> added to section 5. >> >> "Some implementations, specially in the mobile world, have higher-level >> API and/or connection managers. These mechanisms are not standardized >> and do not necessarily behave the same way in the presence of the MIF >> problems. Therefore, a standard API could be considered." >> >> Please put more meat around the bone... >> >> Regards, Marc. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From wherrin@gmail.com Mon Nov 9 10:13:54 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC4C3A6879 for ; Mon, 9 Nov 2009 10:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7qvLaUQ1epS for ; Mon, 9 Nov 2009 10:13:53 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id A37E03A6814 for ; Mon, 9 Nov 2009 10:13:53 -0800 (PST) Received: by ewy3 with SMTP id 3so3390934ewy.37 for ; Mon, 09 Nov 2009 10:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=EIbIppxCuI4ZXR7w/eLFmFI1XdpRyfnFVcV9Y35xwC8=; b=hQJeKfSbxQu0nJeTcEBvJOPU5226O6GTSn/2mmvSz5/8FDVdhE3SnwDCeJxws8+4LD xxJpmuvvjrh77mJow+2h2Vowpodz+Ghh31kjUJVkP+zrGicNV//5sJPJexxM6yCORYBp Vg8mTT3l52A+Pq8bDqqnSFQBRVKHrY/8XEXWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=CaOhqtptWHWRftUJ2THIbvecCJZ8P7rlTSIBgrK7Y3xwVvY0TOxyCrHqYibknY9Egu 2R1BxNz+ZzR3OqpduN4gSd+IPa543+J6vqwL5tacoBhCqCuqLpdWt66qEzVjUZXvOk1y vZJ2ZtLcKaWgoj/d0NYJq3SUhBo/ve273c7os= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.91.6 with SMTP id g6mr2627092wef.212.1257790456513; Mon, 09 Nov 2009 10:14:16 -0800 (PST) Date: Mon, 9 Nov 2009 13:14:16 -0500 X-Google-Sender-Auth: 35d34abf6a33fb3e Message-ID: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> From: William Herrin To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:13:55 -0000 Hi Folks, I'm just joining the list. I would join you at the meeting but I'm about half a world away right now... I've read the charter and the draft problem statement at http://www.ietf.org/id/draft-ietf-mif-problem-statement-01.txt and I've leafed through the list archives. I have some comments I'd like to share as I try to get up to speed. Feedback would be helpful. 1. The draft seems pretty focused on end-hosts, that is systems which originate or consume but don't forward IP packets. Routers are hosts too and figuring out how to handle packets to multiple upstreams in different administrative domains is important there as well. Otherwise we limit ourselves to only the simplest case: where no component larger than a single host is a member of two networks. As often as not, that isn't the case. The entire local LAN can be a member of two upstream networks and it'd be nice if entire routed subsystems could be members of two networks. Even if we don't want to address the router case explicitly, it might be helpful to look at whether the router case offers any insight into the grouping and relationship between the issues in the host case. Source address selection, for example, could be viewed through a routing lens: find the destination in the routing tables associated with each of the hosts's source addresses, return a list of source addresses for which the destination is reachable and weight the list based on the specificity and metric of the respective route. Looking at the problem from that angle, all hosts are MIF hosts. They have a unique loopback network which is administratively separate from any physical wire to which they attach. Put another way: from the perspective of MIF, loopback doesn't look like a special case. 2. DNS strikes me as a subset of a bigger problem: naming services. Other naming services such as the windows browser, windows domains, LDAP and NIS will be impacted in more or less the same way that the DNS is. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kchin.xor@gmail.com Mon Nov 9 10:19:01 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD23C3A682C for ; Mon, 9 Nov 2009 10:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nESKFAP8zLiF for ; Mon, 9 Nov 2009 10:19:00 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id 5645D3A6814 for ; Mon, 9 Nov 2009 10:19:00 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so305930gvc.15 for ; Mon, 09 Nov 2009 10:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hioHkoepXZnkXHolht7/e0wK8qSFh3G7u1N3FTaL+MQ=; b=XrH0oTJ92h+BqlMGQ6JUW5PmjE+zggZMa0I2/5Vl9NPRtF8uva9e8b3Jq+EO6+JWHq LXkRcViAx4+/Cgag/GwxkGIJ1LAVQET1EHpPfMCdN69z4LAA/JIKxxuQ2kBfykVl5e54 irQaEYpT0kzmtZJUqy2PKTvE/qJkEMXBN26xw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KbYYNMlPp1pCSGOVL3mn+ihvdsMhA6rpr10XFqcgTa+2Q6hpGqzwRE9jZGtmGtCMYq qvkrEyiz1zsqGeCtkCE3dReSejzjN5/My4uLiHhqGXaWMbIImTTxfWX+rP5awGf0zucP OBQbmCHkDnkx118W6+wnV1qO94VUrZzz3n4wU= MIME-Version: 1.0 Received: by 10.239.144.91 with SMTP id n27mr787716hba.180.1257790762849; Mon, 09 Nov 2009 10:19:22 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> References: <4AF7BCF0.9050105@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> Date: Mon, 9 Nov 2009 10:19:22 -0800 Message-ID: From: Kevin Chin To: pierrick.seite@orange-ftgroup.com Content-Type: multipart/alternative; boundary=001485f724369f15a90477f43bae Cc: mif@ietf.org Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:19:01 -0000 --001485f724369f15a90477f43bae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi- Re: "API and/or framework for connection managers should be standardized fo= r the sake of harmonization in addressing MIF issues" Why is there a need to address the API space? There is a big difference fro= m Problem Statement definition and API standardization. regards, Kevin On Mon, Nov 9, 2009 at 8:25 AM, wrote: > > Hi, > > I couldn't attend the meeting, so I don't know exactly what it has been > said. However, I agree the ps should address API/Connection manager. > Actually, I think this feature is worth a dedicated section. So, based on > Marc's proposal, I'd propose the following text, please feel free to > comment/modify: > > x. Connection management > > Some implementations, specially in the mobile world, have higher-level > API, and/or connection managers, to address IP configuration issues in a > context of multiple provisioning domains. Depending on the implementation= , > and/or OS, these mechanisms do not necessarily behave the same way in the > presence of the MIF problems [draft-ietf-mif-current-practices]. Therefor= e, > at least, standardization of such an API should be considered in order to > facilitate implementation of mechanisms addressing MIF issues. In the sam= e > way, harmonized behaviour of connection manager across different > implementations and/or OS would bring more consistency for MIF users; in > such a case, standardization of a framework for connection manager, would= be > valuable. > > Then in section 5, I'd reword a little bit the Marc's text: > > * When available, implementation of multiple interfaces API and/or > connection managers do not necessarily behave the same way in the presenc= e > of the MIF problems. API and/or framework for connection managers should = be > standardized for the sake of harmonization in addressing MIF issues. > > Feel free to comment. > > Regards, > Pierrick > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Marc > > Blanchet > > Envoy=E9 : lundi 9 novembre 2009 07:56 > > =C0 : mif@ietf.org > > Objet : [mif] problem-statement: api > > > > Hi, > > following the two comments on the mic about adding some text in the P= S > > about API/Connection manager, here is first text proposal that would be > > added to section 5. > > > > "Some implementations, specially in the mobile world, have higher-level > > API and/or connection managers. These mechanisms are not standardized > > and do not necessarily behave the same way in the presence of the MIF > > problems. Therefore, a standard API could be considered." > > > > Please put more meat around the bone... > > > > Regards, Marc. > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --001485f724369f15a90477f43bae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi-
=A0
Re: "API and/or framework for connection managers should be stand= ardized for the sake of harmonization in addressing MIF issues"
=A0
Why is there a need to address the=A0API space? There is a big differe= nce from Problem Statement definition and API standardization.
=A0
regards,
Kevin
=A0

=A0
On Mon, Nov 9, 2009 at 8:25 AM, <pierrick.seite@o= range-ftgroup.com> wrote:

Hi,

I couldn't at= tend the meeting, so I don't know exactly what it has been said. Howeve= r, I agree the ps should address API/Connection manager. Actually, I think = this feature is worth a dedicated section. So, based on Marc's proposal= , I'd propose the following text, please feel free to comment/modify:
x. Connection management

Some implementations, specially in the mobile world, = have higher-level
API, and/or connection managers, to address IP c= onfiguration issues in a context of multiple provisioning domains. Dependin= g on the implementation, and/or OS, these mechanisms do not necessarily beh= ave the same way in the presence of the MIF problems [draft-ietf-mif-curren= t-practices]. Therefore, at least, standardization of such an API should be= considered in order to facilitate implementation of mechanisms addressing = MIF issues. In the same way, harmonized behaviour of connection manager acr= oss different implementations and/or OS would bring more consistency for MI= F users; in such a case, standardization of a framework for connection mana= ger, would be valuable.

Then in section 5, I'd reword a little bit the Marc's text:
=
* When available, implementation of multiple interfaces API and/or conn= ection managers do not necessarily behave the same way in the presence of t= he MIF problems. API and/or framework for connection managers should be sta= ndardized for the sake of harmonization in addressing MIF issues.

Feel free to comment.

Regards,
Pierrick

> -----Mess= age d'origine-----
> De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Marc
> Blanchet
> Envoy=E9=A0: lundi 9 novembre 2009 07:56
> =C0= =A0: mif@ietf.org
> Objet=A0: [mi= f] problem-statement: api
>
> Hi,
> =A0 following the two comments o= n the mic about adding some text in the PS
> about API/Connection man= ager, here is first text proposal that would be
> added to section 5.=
>
> "Some implementations, specially in the mobile world, hav= e higher-level
> API and/or connection managers. These mechanisms are= not standardized
> and do not necessarily behave the same way in the= presence of the MIF
> problems. Therefore, a standard API could be considered."
>=
> Please put more meat around the bone...
>
> Regards, M= arc.
> _______________________________________________
> mif ma= iling list
> mif@ietf.org
> https://www.ietf= .org/mailman/listinfo/mif
__________________________________________= _____
mif mailing list
mif@ietf.org
https:= //www.ietf.org/mailman/listinfo/mif
<= br> --001485f724369f15a90477f43bae-- From yuri@ismailov.eu Mon Nov 9 14:14:40 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DBE3A6991 for ; Mon, 9 Nov 2009 14:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVG+TY7GOJ0U for ; Mon, 9 Nov 2009 14:14:39 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 105733A68C1 for ; Mon, 9 Nov 2009 14:14:38 -0800 (PST) Received: from [133.93.144.95] (host-144-95.meeting.ietf.org [133.93.144.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 28D1E576A94 for ; Mon, 9 Nov 2009 23:15:01 +0100 (CET) Message-ID: <4AF8945F.2010105@ismailov.eu> Date: Mon, 09 Nov 2009 23:14:55 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20091002) MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] The point about multiple listening sockets at the client side X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:14:40 -0000 Hi all, I've got a request to make this point on the list. It might be just the lack of my understanding and there is no any issue about that. The simple scenario below: A client with let's say 3 interfaces connects to a server through one of them for http download. Server decides to use all three interfaces at the client side. My question was if the client should open listening sockets for accepting server initiated connections over other interfaces? Regards Yuri From jan.melen@nomadiclab.com Mon Nov 9 14:44:54 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13E13A6904 for ; Mon, 9 Nov 2009 14:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9+JIW02OJQi for ; Mon, 9 Nov 2009 14:44:54 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 82E323A6926 for ; Mon, 9 Nov 2009 14:44:53 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 78C9D1EF138; Tue, 10 Nov 2009 00:45:18 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+d2scdWO3h1; Tue, 10 Nov 2009 00:45:17 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 355831EF135; Tue, 10 Nov 2009 00:45:15 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jan Melen In-Reply-To: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> Date: Tue, 10 Nov 2009 00:45:14 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6FA1EBD6-05A6-48A1-AD9B-F580443F6A33@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> To: William Herrin X-Mailer: Apple Mail (2.1076) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:44:55 -0000 Hi folks, On Nov 9, 2009, at 8:14 PM, William Herrin wrote: > Hi Folks, > > I'm just joining the list. I would join you at the meeting but I'm > about half a world away right now... > > I've read the charter and the draft problem statement at > http://www.ietf.org/id/draft-ietf-mif-problem-statement-01.txt and > I've leafed through the list archives. I have some comments I'd like > to share as I try to get up to speed. Feedback would be helpful. > > > 1. The draft seems pretty focused on end-hosts, that is systems which > originate or consume but don't forward IP packets. > > Routers are hosts too and figuring out how to handle packets to > multiple upstreams in different administrative domains is important > there as well. Otherwise we limit ourselves to only the simplest case: > where no component larger than a single host is a member of two > networks. As often as not, that isn't the case. The entire local LAN > can be a member of two upstream networks and it'd be nice if entire > routed subsystems could be members of two networks. > > Even if we don't want to address the router case explicitly, it might > be helpful to look at whether the router case offers any insight into > the grouping and relationship between the issues in the host case. > > Source address selection, for example, could be viewed through a > routing lens: find the destination in the routing tables associated > with each of the hosts's source addresses, return a list of source > addresses for which the destination is reachable and weight the list > based on the specificity and metric of the respective route. > > Looking at the problem from that angle, all hosts are MIF hosts. They > have a unique loopback network which is administratively separate from > any physical wire to which they attach. Put another way: from the > perspective of MIF, loopback doesn't look like a special case. > In the edge router products I think that there exists solutions how do they handle multiple interfaces and metrics of those. So if you have two interfaces through which you can reach the network the router usually makes the decision based on metrics and some times even based on policy based routing rules. But then again if the intent is to bring up issue on how a host (e.g. BSD) acts as a router or when using static addressing (not DHCP) that is whole different story. E.g. in all BSDs it is possible to use multiple defaultroutes based on the source address the application select using firewall rules. Almost all firewall implementations allow you to specify next hop for the packet based on source address, destination address, outgoing or incoming interface or by any combination of these. So if your BSD/Linux host acts as an router or you use static addresses in which case you know the addresses of defaultroutes before hand you can do a lot more than what ISC-DHCP can do. Even in the case of ISC-DHCP you could by creating dhclien-scripts change the default behavior of address lease for example to modify your firewall rules according to the address lease information. In the recent versions of FreeBSD 7.x-> there is introduced a functionality that allows you to have multiple routing tables and you can for example limit that certain process may access only certain routing table thus mandating that packets coming from that process are routed according to that table. This is useful for example in the cases where you have multiple virtual hosts or jails (sandboxes) running in one physical hardware thus you can limit and control how the packet are routed from that entity. So all in all. I think that most of the features that are needed to actually route packets based on source address or interface basis exist in the kernel but usually when you take the system out of the box (CD) they are not used. You have to really be a geek to get them to work as you would like to and not even then are things easy unless you really know how the kernel works. > > 2. DNS strikes me as a subset of a bigger problem: naming services. > Other naming services such as the windows browser, windows domains, > LDAP and NIS will be impacted in more or less the same way that the > DNS is. Agreed. DNS is really a problem as the first resolving of the address already mandates which interface you choose or if you use multiple and get multiple different answers how are you supposed to know which address is more appropriate..... Jan From lars.eggert@nokia.com Mon Nov 9 16:43:04 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B16D3A6908; Mon, 9 Nov 2009 16:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGKTUIsxkbxA; Mon, 9 Nov 2009 16:43:03 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 396243A68B3; Mon, 9 Nov 2009 16:43:03 -0800 (PST) Received: from host-24-27.meeting.ietf.org (host-24-27.meeting.ietf.org [133.93.24.27]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nAA0hHjv098744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Nov 2009 02:43:21 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-9-333722617; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AF8945F.2010105@ismailov.eu> Date: Tue, 10 Nov 2009 09:43:16 +0900 Message-Id: References: <4AF8945F.2010105@ismailov.eu> To: Yuri Ismailov X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 10 Nov 2009 02:43:23 +0200 (EET) Cc: "multipathtcp@ietf.org Mailing List" , mif@ietf.org Subject: Re: [mif] The point about multiple listening sockets at the client side X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:43:04 -0000 --Apple-Mail-9-333722617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I think you made this comment at the mike in MPTCP, so you probably want = to follow up on this on the MPTCP list. Lars On 2009-11-10, at 7:14, Yuri Ismailov wrote: > Hi all, > I've got a request to make this point on the list. It might be just = the > lack of my understanding and there is no any issue about that. > The simple scenario below: > A client with let's say 3 interfaces connects to a server through one = of > them for http download. > Server decides to use all three interfaces at the client side. > My question was if the client should open listening sockets for > accepting server initiated connections over other interfaces? >=20 > Regards > Yuri >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail-9-333722617 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTExMDAwNDMxN1owIwYJKoZIhvcNAQkEMRYEFLky8gsHNRUkBX2tfCWbRoQ44TVuMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCGtQV13fH+NFfUs4ggeV5JXfl9ON+19+Lgig1j8Gn6nmkjyjjfXOhXmRj9HFp2TL5BcI2N RAOOytooqMv1XySxep7wcYOuauFEy3pjGI5assTxQiuFy+L1IoHlHFJWFFWo7UP6bPQlDKPb9jfu qvB0pcwzoyvGbTZNkkZFXmuku33FG3SNs5PSwdQmZOJ2KD6Khmxc9lw4kVFBnvzoTn/bAQ8RiVCa FCXDdSyA/MrfucuZIsfeJjfvkI/kVj94WeX6kH4IOTvua55Tdkgv6yCeu6h2zVdqKD85s4mA2gJu QtPE1ZlaDz8IwH82joLuvjgmPCEqepgvXCXxLFSv332CAAAAAAAA --Apple-Mail-9-333722617-- From yuri@ismailov.eu Mon Nov 9 16:46:54 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3CF3A63EB for ; Mon, 9 Nov 2009 16:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-p5QF6DszSy for ; Mon, 9 Nov 2009 16:46:53 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 471363A6839 for ; Mon, 9 Nov 2009 16:46:53 -0800 (PST) Received: from [133.93.19.5] (host-19-5.meeting.ietf.org [133.93.19.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 60407576A7A for ; Tue, 10 Nov 2009 01:47:18 +0100 (CET) Message-ID: <4AF8B80F.4080401@ismailov.eu> Date: Tue, 10 Nov 2009 01:47:11 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20091002) MIME-Version: 1.0 To: mif@ietf.org Content-Type: multipart/mixed; boundary="------------010409090604050205000001" Subject: [mif] [Fwd: The point about multiple listening sockets at the client side] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:46:54 -0000 This is a multi-part message in MIME format. --------------010409090604050205000001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry folks, disregard my previous emai pleasel. It is the wrong WG:-) regarsd Yuri --------------010409090604050205000001 Content-Type: message/rfc822; name="[mif] The point about multiple listening sockets at the client side.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[mif] The point about multiple listening sockets at the clie"; filename*1="nt side.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: Delivered-To: yuri@ismailov.eu Received: from localhost (unknown [192.168.76.14]) by mailin1.eurodns.com (Postfix) with ESMTP id 10E9A4D005C for ; Mon, 9 Nov 2009 23:15:27 +0100 (CET) X-Virus-Scanned: amavisd-new at eurodns.com Received: from mailin1.eurodns.com ([192.168.76.17]) by localhost (mailfilter1.eurodns.com [192.168.76.14]) (amavisd-new, port 10024) with ESMTP id xfiV8ZetIb28 for ; Mon, 9 Nov 2009 23:15:12 +0100 (CET) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (mailin1.eurodns.com: domain of ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; envelope-from=mif-bounces@ietf.org; helo=mail.ietf.org; Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mailin1.eurodns.com (Postfix) with ESMTP id E9AC44D007F for ; Mon, 9 Nov 2009 23:15:11 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032A03A69B8; Mon, 9 Nov 2009 14:14:41 -0800 (PST) X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DBE3A6991 for ; Mon, 9 Nov 2009 14:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVG+TY7GOJ0U for ; Mon, 9 Nov 2009 14:14:39 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 105733A68C1 for ; Mon, 9 Nov 2009 14:14:38 -0800 (PST) Received: from [133.93.144.95] (host-144-95.meeting.ietf.org [133.93.144.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 28D1E576A94 for ; Mon, 9 Nov 2009 23:15:01 +0100 (CET) Message-ID: <4AF8945F.2010105@ismailov.eu> Date: Mon, 09 Nov 2009 23:14:55 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20091002) MIME-Version: 1.0 To: mif@ietf.org Subject: [mif] The point about multiple listening sockets at the client side X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi all, I've got a request to make this point on the list. It might be just the lack of my understanding and there is no any issue about that. The simple scenario below: A client with let's say 3 interfaces connects to a server through one of them for http download. Server decides to use all three interfaces at the client side. My question was if the client should open listening sockets for accepting server initiated connections over other interfaces? Regards Yuri _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------010409090604050205000001-- From maxpassion@gmail.com Mon Nov 9 19:11:32 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D2B3A686C for ; Mon, 9 Nov 2009 19:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm+EHZ4P2iqj for ; Mon, 9 Nov 2009 19:11:30 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C47BF3A681B for ; Mon, 9 Nov 2009 19:11:30 -0800 (PST) Received: by pzk42 with SMTP id 42so2997252pzk.31 for ; Mon, 09 Nov 2009 19:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=z1YJYprNDosU5NQrHkpB1PGx1Hqg5Dv8HxpjUvTawp0=; b=IHzRWV/0QFxNwGathinVemn6JU1lMPGGFZqCNA5GRsRbjTcndOwqH5JpgTsne7m6PX MvND/Z4bZQJxnNr3RvMau6L3V41ZCkXm8msQpIAr/bu/9yu2ACq9sDiZYQQLKxz7p3cL g++nONao7+mJJ77sz2jSuuxxwMSmaC5JtW3g8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J0mvpXiuuVKFe3hRLB2mLrWnPdb2W9u3ZOKoCabpM+NWJ76ivTKFp/T3c0hK2m5S7a 0YeJEp3evDM+YIRgs6vbikpULnHkukp+3Yy9r4v4nqQmRLxvpFs5t1F4g0e+i8U678/Z 9fVPBf85GqItG3rTd0F+1MrvCnX1Std0DULIw= MIME-Version: 1.0 Received: by 10.142.195.4 with SMTP id s4mr913987wff.264.1257822715301; Mon, 09 Nov 2009 19:11:55 -0800 (PST) In-Reply-To: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> Date: Tue, 10 Nov 2009 11:11:55 +0800 Message-ID: <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> From: liu dapeng To: William Herrin Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:11:32 -0000 Hi William, 2009/11/10, William Herrin : > Hi Folks, > > I'm just joining the list. I would join you at the meeting but I'm > about half a world away right now... > > I've read the charter and the draft problem statement at > http://www.ietf.org/id/draft-ietf-mif-problem-statement-01.txt and > I've leafed through the list archives. I have some comments I'd like > to share as I try to get up to speed. Feedback would be helpful. > > > 1. The draft seems pretty focused on end-hosts, that is systems which > originate or consume but don't forward IP packets. > > Routers are hosts too and figuring out how to handle packets to > multiple upstreams in different administrative domains is important > there as well. Otherwise we limit ourselves to only the simplest case: > where no component larger than a single host is a member of two > networks. As often as not, that isn't the case. The entire local LAN > can be a member of two upstream networks and it'd be nice if entire > routed subsystems could be members of two networks. In my understanding, router normally does not have the multiple interfaces issue, since router is designed to forward packets across different interfaces and there is no default route issue in router. so what problems are you thinking that need to be solved? > Even if we don't want to address the router case explicitly, it might > be helpful to look at whether the router case offers any insight into > the grouping and relationship between the issues in the host case. > > Source address selection, for example, could be viewed through a > routing lens: find the destination in the routing tables associated > with each of the hosts's source addresses, return a list of source > addresses for which the destination is reachable and weight the list > based on the specificity and metric of the respective route. > > Looking at the problem from that angle, all hosts are MIF hosts. They > have a unique loopback network which is administratively separate from > any physical wire to which they attach. Put another way: from the > perspective of MIF, loopback doesn't look like a special case. > > > > 2. DNS strikes me as a subset of a bigger problem: naming services. > Other naming services such as the windows browser, windows domains, > LDAP and NIS will be impacted in more or less the same way that the > DNS is. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From wherrin@gmail.com Mon Nov 9 20:02:43 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D2B3A6A32 for ; Mon, 9 Nov 2009 20:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8mKuFMaJuXQ for ; Mon, 9 Nov 2009 20:02:42 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 8EE393A691E for ; Mon, 9 Nov 2009 20:02:41 -0800 (PST) Received: by ewy3 with SMTP id 3so3869767ewy.37 for ; Mon, 09 Nov 2009 20:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=T5wuD4Lb6LH7B1rb/RUDbCO0eocQmNFLpLK3IAA0KZk=; b=GqKnjFEcnrd6gv32LAS8cvfmuTlKN5oy/f21exRXU3MudYBHVatTc3FiRAjbh05BP0 8hcvkkFSq7xg+6UeqSVl4GctmmJFtQVDk9whsS5FBsK8egCb7Cqx3yklYmysyvUI1dy8 4KTtA7JLied8KAiBS/5AqRkJ8IiD+RULZJ3zU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oy4ReG/0xZvAXiqKgl+6d5N3KR0b8BkHpesMDtiXx41lHtv006AsBF5sVbHWv8Okmq gXneTh6oqQS4H+u4vNC4VoZcTUsn/qCbxjtYztckrVgGcIAEm98QgaAJVE7QfmLZ4VF2 4pLUGD0RTXX6niWHDpvv2YtUADpeCDRdJZWTk= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.86.212 with SMTP id w62mr251686wee.131.1257825784253; Mon, 09 Nov 2009 20:03:04 -0800 (PST) In-Reply-To: <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> Date: Mon, 9 Nov 2009 23:03:04 -0500 X-Google-Sender-Auth: 1b4618ce808847a1 Message-ID: <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> From: William Herrin To: liu dapeng Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:02:43 -0000 On Mon, Nov 9, 2009 at 10:11 PM, liu dapeng wrote: >> Routers are hosts too and figuring out how to handle packets to >> multiple upstreams in different administrative domains is important >> there as well. Otherwise we limit ourselves to only the simplest case: >> where no component larger than a single host is a member of two >> networks. As often as not, that isn't the case. The entire local LAN >> can be a member of two upstream networks and it'd be nice if entire >> routed subsystems could be members of two networks. > > In my understanding, router normally does not have the multiple > interfaces issue, since router is designed to forward packets across > different interfaces and there is no default route issue in router. so > what problems are you thinking that need to be solved? Hi, Starting from a post-multipath TCP world... The situation that jumps to mind is: 3 offices, A B and C. B connects to A with a T1. C connects to A with a T1. B connects to C with a T1. So they're connected in a triangle. A connects to the Internet with a DSL. B also connects to the Internet with a WiMax link. Server located at C called CS. It has an address from the DSL ISP and an address from the WiMax ISP. CS(DSL)->CA router->AC Router->DSL Router->Internet CS(WiMax)->CB router->BC Router->WiMax Router->Internet But if the CA T1 is down then: CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL Router->Internet And while CS has two addresses and network blocks, it has only one ethernet interface on which it talks to both the CA and CB routers. Following me? The routers in the picture have two different routing domains depending on the source address. Add an Internet cable modem to site C and now you have to handle 3 routing domains on every router in the system. But if you keep thinking about it, maybe you don't try to introduce routing domains at all. Maybe you introduce source+destation CIDR pairs instead of just destination CIDRs. So, the DSL at A offers 1.2.3.0/24+0.0.0.0/0, the WiMax at B announces 4.5.6.0/24+0.0.0.0/0 and the cable modem at C announces 7.8.9.0/24+0.0.0.0/0. On the flip side, the site-C routers announce 0.0.0.0/0+1.2.3.32/28, 0.0.0.0/0+4.5.6.32/28 and 0.0.0.0/0+7.8.9.32/28. Now there's just one routing domain and six routes which work sensibly in a dynamic routing protocol. And if CS gets hacked and tries to send a packet to 9.9.9.9 from the forged source address 8.8.8.8, the packet dies at the first router because there's no route for 8.8.8.8/32+9.9.9.9/32. Now if you go back and think of host CS the same way as the routers, CS has the following routes: 1.2.3.35/32+1.2.3.32/28->eth0 1.2.3.35/32+0.0.0.0/0->Router CA metric 2 1.2.3.35/32+0.0.0.0/0->Router CB metric 3 4.5.6.35/32+4.5.6.32/28->eth0 4.5.6.35/32+0.0.0.0/0->Router CB metric 2 4.5.6.35/32+0.0.0.0/0->Router CA metric 3 7.8.9.35/32+7.8.9.32/28->eth0 7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1 127.0.0.0/8+127.0.0.0/8->loopback Or so goes my train of thought anyway... Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From caozhenpku@gmail.com Mon Nov 9 20:09:46 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7EF3A689E for ; Mon, 9 Nov 2009 20:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYpoBRb9Hemi for ; Mon, 9 Nov 2009 20:09:45 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id ED43A3A6841 for ; Mon, 9 Nov 2009 20:09:44 -0800 (PST) Received: by pwi6 with SMTP id 6so843083pwi.29 for ; Mon, 09 Nov 2009 20:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HQbz3cWrPBCKpJuyfOAmqI1WLaV1tmeGOim/ZPwC0b4=; b=iZnZdFVnKF28PiD+WZ+waHg/+ZO0eOmJ0gdMNKjzz6WLkX4t+mVK3J945sEb/Jsi47 IF9i8TJS1enMvcRC6C9a3op/fuWdM8I8esaRhRoa8dYiwJJJl79jEE7jV0/ZXPyfDRoz t2QwO8E2RJTZUDDLI/nHjosc1Xhsd2pHkSBGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AUAuy1rfxm7wLModjioSsUIqEj9s0DfKbwINa7JeS0RDqnuZyGLI+wX+mgNA5FItPg IuBro/oKIO0G+IcQeW6YDZDZACRniyfRKd9LQe8d9rbLQleC/Xop8kZmh9H3DcBPI332 y6OJhT+hIux6MhWmIKNBwUJdoI3mkbdRMPovw= MIME-Version: 1.0 Received: by 10.142.56.9 with SMTP id e9mr881586wfa.62.1257826207522; Mon, 09 Nov 2009 20:10:07 -0800 (PST) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> References: <4AF7BCF0.9050105@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> Date: Tue, 10 Nov 2009 12:10:07 +0800 Message-ID: From: Zhen Cao To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:09:46 -0000 Hi, Although i was not at the meeting site, i attended the meeting using the audio streaming service and was clear that people agreed to elaborate the API issues more clearly in the PS draft. There is a subsection 3.6 talking about socket API, you might want to merge your text into that section? For the text you provided, I suggest we describe in a way that is more problem oriented. IMO, the problem is two fold, (a) we do not have advanced API to support some MIF features and (b) different implementations deliver different higher level API, so there is a harmonization problem between them. I provided the text as follows: "First, TCP/IP stack currently does not provide advanced API to specify the source IP address or to set preferences on the address selection policies for both IPv4 and IPv6 address family. Secondly, differently operation system implementations delivery different set of high level API, some exported with connection managers to address connection issues to multiple provisioning domains. These mechanisms do not necessarily behave the same way in the presence of the MIF problems [draft-ietf-mif-current-practices]. This results in the inconsistence problem and makes application developers confused when they want to develop application across different platforms" -Z On Tue, Nov 10, 2009 at 12:25 AM, wrot= e: > > Hi, > > I couldn't attend the meeting, so I don't know exactly what it has been s= aid. However, I agree the ps should address API/Connection manager. Actuall= y, I think this feature is worth a dedicated section. So, based on Marc's p= roposal, I'd propose the following text, please feel free to comment/modify= : > > x. Connection management > > Some implementations, specially in the mobile world, have higher-level > API, and/or connection managers, to address IP configuration issues in a = context of multiple provisioning domains. Depending on the implementation, = and/or OS, these mechanisms do not necessarily behave the same way in the p= resence of the MIF problems [draft-ietf-mif-current-practices]. Therefore, = at least, standardization of such an API should be considered in order to f= acilitate implementation of mechanisms addressing MIF issues. In the same w= ay, harmonized behaviour of connection manager across different implementat= ions and/or OS would bring more consistency for MIF users; in such a case, = standardization of a framework for connection manager, would be valuable. > > Then in section 5, I'd reword a little bit the Marc's text: > > * When available, implementation of multiple interfaces API and/or connec= tion managers do not necessarily behave the same way in the presence of the= MIF problems. API and/or framework for connection managers should be stand= ardized for the sake of harmonization in addressing MIF issues. > > Feel free to comment. > > Regards, > Pierrick > >> -----Message d'origine----- >> De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Marc >> Blanchet >> Envoy=E9=A0: lundi 9 novembre 2009 07:56 >> =C0=A0: mif@ietf.org >> Objet=A0: [mif] problem-statement: api >> >> Hi, >> =A0 following the two comments on the mic about adding some text in the = PS >> about API/Connection manager, here is first text proposal that would be >> added to section 5. >> >> "Some implementations, specially in the mobile world, have higher-level >> API and/or connection managers. These mechanisms are not standardized >> and do not necessarily behave the same way in the presence of the MIF >> problems. Therefore, a standard API could be considered." >> >> Please put more meat around the bone... >> >> Regards, Marc. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From jan.melen@nomadiclab.com Mon Nov 9 21:00:02 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382823A692D for ; Mon, 9 Nov 2009 21:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzvdPmF8ZB2h for ; Mon, 9 Nov 2009 21:00:01 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id C07EC3A6820 for ; Mon, 9 Nov 2009 21:00:00 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3127B1EF138; Tue, 10 Nov 2009 07:00:26 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNFi68Hv+-Ea; Tue, 10 Nov 2009 07:00:25 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id A97AA1EF135; Tue, 10 Nov 2009 07:00:23 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jan Melen In-Reply-To: <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> Date: Tue, 10 Nov 2009 07:00:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> To: William Herrin X-Mailer: Apple Mail (2.1076) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:00:02 -0000 Hi William, See inline..... On Nov 10, 2009, at 6:03 AM, William Herrin wrote: > On Mon, Nov 9, 2009 at 10:11 PM, liu dapeng > wrote: >>> Routers are hosts too and figuring out how to handle packets to >>> multiple upstreams in different administrative domains is important >>> there as well. Otherwise we limit ourselves to only the simplest >>> case: >>> where no component larger than a single host is a member of two >>> networks. As often as not, that isn't the case. The entire local LAN >>> can be a member of two upstream networks and it'd be nice if entire >>> routed subsystems could be members of two networks. >> >> In my understanding, router normally does not have the multiple >> interfaces issue, since router is designed to forward packets across >> different interfaces and there is no default route issue in router. >> so >> what problems are you thinking that need to be solved? > > Hi, > > Starting from a post-multipath TCP world... > > The situation that jumps to mind is: > > 3 offices, A B and C. > > B connects to A with a T1. > C connects to A with a T1. > B connects to C with a T1. So they're connected in a triangle. > > A connects to the Internet with a DSL. > B also connects to the Internet with a WiMax link. > > Server located at C called CS. It has an address from the DSL ISP and > an address from the WiMax ISP. > > CS(DSL)->CA router->AC Router->DSL Router->Internet > CS(WiMax)->CB router->BC Router->WiMax Router->Internet > > But if the CA T1 is down then: > CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL > Router->Internet The CA router can't for the packet that has the source address of the DSL ISP to the CB router. The source address filtering in the WiMax ISP would drop the packet. If the CA router would do translation of addresses it would somewhat work but still the end-host mif function would not have any control. If then again the CA router would replace the source address with the address CS(WiMax) the return packet would come back on a socket that is not open. Or maybe I misunderstood something from this... > And while CS has two addresses and network blocks, it has only one > ethernet interface on which it talks to both the CA and CB routers. > > > Following me? The routers in the picture have two different routing > domains depending on the source address. > So far.... > > Add an Internet cable modem to site C and now you have to handle 3 > routing domains on every router in the system. > > > But if you keep thinking about it, maybe you don't try to introduce > routing domains at all. Maybe you introduce source+destation CIDR > pairs instead of just destination CIDRs. So, the DSL at A offers > 1.2.3.0/24+0.0.0.0/0, the WiMax at B announces 4.5.6.0/24+0.0.0.0/0 > and the cable modem at C announces 7.8.9.0/24+0.0.0.0/0. On the flip > side, the site-C routers announce 0.0.0.0/0+1.2.3.32/28, > 0.0.0.0/0+4.5.6.32/28 and 0.0.0.0/0+7.8.9.32/28. Now there's just one > routing domain and six routes which work sensibly in a dynamic routing > protocol. > > And if CS gets hacked and tries to send a packet to 9.9.9.9 from the > forged source address 8.8.8.8, the packet dies at the first router > because there's no route for 8.8.8.8/32+9.9.9.9/32. > > Now if you go back and think of host CS the same way as the routers, > CS has the following routes: > 1.2.3.35/32+1.2.3.32/28->eth0 > 1.2.3.35/32+0.0.0.0/0->Router CA metric 2 > 1.2.3.35/32+0.0.0.0/0->Router CB metric 3 > 4.5.6.35/32+4.5.6.32/28->eth0 > 4.5.6.35/32+0.0.0.0/0->Router CB metric 2 > 4.5.6.35/32+0.0.0.0/0->Router CA metric 3 > 7.8.9.35/32+7.8.9.32/28->eth0 > 7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1 > 127.0.0.0/8+127.0.0.0/8->loopback If any of the default routes fail in such configuration it should be the routing protocol that stops advertising default route through that interface at that point in which case it would result that default route through that interface deprecates in few minutes and the traffic will be routed through another router. Existing connections will break if there is no translation in place in the network see the earlier comments about source address filtering. DHCP has very poor or non-existing mechanisms to inform the clients about changes in the network routing information as the protocol is designed to be pull instead of push where as all routing protocols are much more appropriate for this type of operation. Regards, Jan From jan.melen@nomadiclab.com Mon Nov 9 21:16:39 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31AB3A67F7 for ; Mon, 9 Nov 2009 21:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzkeb6xBR4ae for ; Mon, 9 Nov 2009 21:16:38 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 473803A6A45 for ; Mon, 9 Nov 2009 21:16:38 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DC7FF1EF138; Tue, 10 Nov 2009 07:17:04 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB+hJpggooci; Tue, 10 Nov 2009 07:17:04 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 32A221EF135; Tue, 10 Nov 2009 07:17:02 +0200 (EET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: Jan Melen In-Reply-To: <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> Date: Tue, 10 Nov 2009 07:17:01 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> To: William Herrin , mif@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:16:39 -0000 Hi William again, I'm replying to my own mail sorry for that but forgot one thing from the previous mail. If we forget about the failure case then I think that the scenario you proposed is valid for MIF meaning that what ever mechanism we use to select the source address we should also select the default router accordingly regardless whether the routers are on the same link or different links of the host. That I think was already in the scope of MIF problem statement if I understood correctly Marc and Margaret yesterday at WG meeting. Marc or Margaret may correct me if I've misunderstood something..... Regards, Jan On Nov 10, 2009, at 7:00 AM, Jan Melen wrote: > Hi William, > > See inline..... > > On Nov 10, 2009, at 6:03 AM, William Herrin wrote: > >> On Mon, Nov 9, 2009 at 10:11 PM, liu dapeng >> wrote: >>>> Routers are hosts too and figuring out how to handle packets to >>>> multiple upstreams in different administrative domains is important >>>> there as well. Otherwise we limit ourselves to only the simplest >>>> case: >>>> where no component larger than a single host is a member of two >>>> networks. As often as not, that isn't the case. The entire local >>>> LAN >>>> can be a member of two upstream networks and it'd be nice if entire >>>> routed subsystems could be members of two networks. >>> >>> In my understanding, router normally does not have the multiple >>> interfaces issue, since router is designed to forward packets across >>> different interfaces and there is no default route issue in >>> router. so >>> what problems are you thinking that need to be solved? >> >> Hi, >> >> Starting from a post-multipath TCP world... >> >> The situation that jumps to mind is: >> >> 3 offices, A B and C. >> >> B connects to A with a T1. >> C connects to A with a T1. >> B connects to C with a T1. So they're connected in a triangle. >> >> A connects to the Internet with a DSL. >> B also connects to the Internet with a WiMax link. >> >> Server located at C called CS. It has an address from the DSL ISP and >> an address from the WiMax ISP. >> >> CS(DSL)->CA router->AC Router->DSL Router->Internet >> CS(WiMax)->CB router->BC Router->WiMax Router->Internet >> >> But if the CA T1 is down then: >> CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL >> Router->Internet > > > The CA router can't for the packet that has the source address of > the DSL ISP to the CB router. The source address filtering in the > WiMax ISP would drop the packet. If the CA router would do > translation of addresses it would somewhat work but still the end- > host mif function would not have any control. If then again the CA > router would replace the source address with the address CS(WiMax) > the return packet would come back on a socket that is not open. > > Or maybe I misunderstood something from this... > >> And while CS has two addresses and network blocks, it has only one >> ethernet interface on which it talks to both the CA and CB routers. >> >> >> Following me? The routers in the picture have two different routing >> domains depending on the source address. >> > > > So far.... > > >> >> Add an Internet cable modem to site C and now you have to handle 3 >> routing domains on every router in the system. >> >> >> But if you keep thinking about it, maybe you don't try to introduce >> routing domains at all. Maybe you introduce source+destation CIDR >> pairs instead of just destination CIDRs. So, the DSL at A offers >> 1.2.3.0/24+0.0.0.0/0, the WiMax at B announces 4.5.6.0/24+0.0.0.0/0 >> and the cable modem at C announces 7.8.9.0/24+0.0.0.0/0. On the flip >> side, the site-C routers announce 0.0.0.0/0+1.2.3.32/28, >> 0.0.0.0/0+4.5.6.32/28 and 0.0.0.0/0+7.8.9.32/28. Now there's just one >> routing domain and six routes which work sensibly in a dynamic >> routing >> protocol. >> >> And if CS gets hacked and tries to send a packet to 9.9.9.9 from the >> forged source address 8.8.8.8, the packet dies at the first router >> because there's no route for 8.8.8.8/32+9.9.9.9/32. >> >> Now if you go back and think of host CS the same way as the routers, >> CS has the following routes: >> 1.2.3.35/32+1.2.3.32/28->eth0 >> 1.2.3.35/32+0.0.0.0/0->Router CA metric 2 >> 1.2.3.35/32+0.0.0.0/0->Router CB metric 3 >> 4.5.6.35/32+4.5.6.32/28->eth0 >> 4.5.6.35/32+0.0.0.0/0->Router CB metric 2 >> 4.5.6.35/32+0.0.0.0/0->Router CA metric 3 >> 7.8.9.35/32+7.8.9.32/28->eth0 >> 7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1 >> 127.0.0.0/8+127.0.0.0/8->loopback > > > If any of the default routes fail in such configuration it should be > the routing protocol that stops advertising default route through > that interface at that point in which case it would result that > default route through that interface deprecates in few minutes and > the traffic will be routed through another router. Existing > connections will break if there is no translation in place in the > network see the earlier comments about source address filtering. > > DHCP has very poor or non-existing mechanisms to inform the clients > about changes in the network routing information as the protocol is > designed to be pull instead of push where as all routing protocols > are much more appropriate for this type of operation. > > Regards, > Jan > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange-ftgroup.com Tue Nov 10 01:00:06 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07EC3A6A67 for ; Tue, 10 Nov 2009 01:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSONw5A99xwz for ; Tue, 10 Nov 2009 01:00:05 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 28CC13A6862 for ; Tue, 10 Nov 2009 01:00:05 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 10:00:28 +0100 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, 10 Nov 2009 10:00:28 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46273AC39@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4AF855B7.2000708@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] problem-statement: api Thread-Index: AcphZKCnJGmiLsb9RPaGZ8n7WPuOHAAfn3PA References: <4AF7BCF0.9050105@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> <4AF855B7.2000708@hiit.fi> From: To: X-OriginalArrivalTime: 10 Nov 2009 09:00:28.0686 (UTC) FILETIME=[3FF3CAE0:01CA61E4] Cc: mif@ietf.org Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:00:06 -0000 Hi Mika, Sorry for having missed your first email. That's a good input we can = refer to, but without focusing in shim specific issue. If no objection = from the WG, we could include the reference into the API section we are = currently discussing. Thanks. Regards, Pierrick > -----Message d'origine----- > De=A0: Miika Komu [mailto:miika.komu@hiit.fi] > Envoy=E9=A0: lundi 9 novembre 2009 18:48 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: marc.blanchet@viagenie.ca; mif@ietf.org > Objet=A0: Re: [mif] problem-statement: api >=20 > pierrick.seite@orange-ftgroup.com wrote: >=20 > Hi, >=20 > I have sent this link earlier to this mailing list but there was no > discussion or comments: >=20 > http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api > http://www.ietf.org/mail-archive/web/mif/current/msg00549.html >=20 > Would it be possible to have a section referencing this work in the > problem statement draft? The draft is all about multihoming and APIs > after all. >=20 > > Hi, > > > > I couldn't attend the meeting, so I don't know exactly what it has = been > said. However, I agree the ps should address API/Connection manager. > Actually, I think this feature is worth a dedicated section. So, based = on > Marc's proposal, I'd propose the following text, please feel free to > comment/modify: > > > > x. Connection management > > > > Some implementations, specially in the mobile world, have = higher-level > > API, and/or connection managers, to address IP configuration issues = in a > context of multiple provisioning domains. Depending on the = implementation, > and/or OS, these mechanisms do not necessarily behave the same way in = the > presence of the MIF problems [draft-ietf-mif-current-practices]. > Therefore, at least, standardization of such an API should be = considered > in order to facilitate implementation of mechanisms addressing MIF = issues. > In the same way, harmonized behaviour of connection manager across > different implementations and/or OS would bring more consistency for = MIF > users; in such a case, standardization of a framework for connection > manager, would be valuable. > > > > Then in section 5, I'd reword a little bit the Marc's text: > > > > * When available, implementation of multiple interfaces API and/or > connection managers do not necessarily behave the same way in the = presence > of the MIF problems. API and/or framework for connection managers = should > be standardized for the sake of harmonization in addressing MIF = issues. > > > > Feel free to comment. > > > > Regards, > > Pierrick > > > >> -----Message d'origine----- > >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Marc > >> Blanchet > >> Envoy=E9 : lundi 9 novembre 2009 07:56 > >> =C0 : mif@ietf.org > >> Objet : [mif] problem-statement: api > >> > >> Hi, > >> following the two comments on the mic about adding some text in = the > PS > >> about API/Connection manager, here is first text proposal that = would be > >> added to section 5. > >> > >> "Some implementations, specially in the mobile world, have = higher-level > >> API and/or connection managers. These mechanisms are not = standardized > >> and do not necessarily behave the same way in the presence of the = MIF > >> problems. Therefore, a standard API could be considered." > >> > >> Please put more meat around the bone... > >> > >> Regards, Marc. > >> _______________________________________________ > >> mif mailing list > >> mif@ietf.org > >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange-ftgroup.com Tue Nov 10 01:35:31 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D8428C149 for ; Tue, 10 Nov 2009 01:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqtfpuacoegW for ; Tue, 10 Nov 2009 01:35:30 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id BDF5C28C0F5 for ; Tue, 10 Nov 2009 01:35:29 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 10:35:53 +0100 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_01CA61E9.31EAF77F" Date: Tue, 10 Nov 2009 10:35:52 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46273AC8C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] problem-statement: api Thread-Index: AcphaTwKplPSvyZXTK++KuRuFlwXYgAex9mw References: <4AF7BCF0.9050105@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 10 Nov 2009 09:35:53.0059 (UTC) FILETIME=[322D6330:01CA61E9] Cc: mif@ietf.org Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:35:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA61E9.31EAF77F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kevin, =20 Actually we have already an API section in the ps draft, even if = standardization of the API is not in the current MIF charter. FMU of = meeting discussion, the idea is just to improve the actual API section = with some words about issues with having disparate API behaviour across = different OS; and, at least, stress that multi-platform applications = using such an API (e.g. connection managers) would take benefit from = standardization in the field.=20 =20 Regards, Pierrick =20 ________________________________ De : Kevin Chin [mailto:kchin.xor@gmail.com]=20 Envoy=E9 : lundi 9 novembre 2009 19:19 =C0 : SEITE Pierrick RD-RESA-REN Cc : marc.blanchet@viagenie.ca; mif@ietf.org Objet : Re: [mif] problem-statement: api =20 Hi- =20 Re: "API and/or framework for connection managers should be standardized = for the sake of harmonization in addressing MIF issues" =20 Why is there a need to address the API space? There is a big difference = from Problem Statement definition and API standardization. =20 regards, Kevin =20 =20 On Mon, Nov 9, 2009 at 8:25 AM, = wrote: Hi, I couldn't attend the meeting, so I don't know exactly what it has been = said. However, I agree the ps should address API/Connection manager. = Actually, I think this feature is worth a dedicated section. So, based = on Marc's proposal, I'd propose the following text, please feel free to = comment/modify: x. Connection management Some implementations, specially in the mobile world, have higher-level API, and/or connection managers, to address IP configuration issues in a = context of multiple provisioning domains. Depending on the = implementation, and/or OS, these mechanisms do not necessarily behave = the same way in the presence of the MIF problems = [draft-ietf-mif-current-practices]. Therefore, at least, standardization = of such an API should be considered in order to facilitate = implementation of mechanisms addressing MIF issues. In the same way, = harmonized behaviour of connection manager across different = implementations and/or OS would bring more consistency for MIF users; in = such a case, standardization of a framework for connection manager, = would be valuable. Then in section 5, I'd reword a little bit the Marc's text: * When available, implementation of multiple interfaces API and/or = connection managers do not necessarily behave the same way in the = presence of the MIF problems. API and/or framework for connection = managers should be standardized for the sake of harmonization in = addressing MIF issues. Feel free to comment. Regards, Pierrick > -----Message d'origine----- > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Marc > Blanchet > Envoy=E9 : lundi 9 novembre 2009 07:56 > =C0 : mif@ietf.org > Objet : [mif] problem-statement: api > > Hi, > following the two comments on the mic about adding some text in the = PS > about API/Connection manager, here is first text proposal that would = be > added to section 5. > > "Some implementations, specially in the mobile world, have = higher-level > API and/or connection managers. These mechanisms are not standardized > and do not necessarily behave the same way in the presence of the MIF > problems. Therefore, a standard API could be considered." > > Please put more meat around the bone... > > Regards, Marc. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif =20 ------_=_NextPart_001_01CA61E9.31EAF77F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Kevin,

 

Actually we have already an API section in the ps = draft, even if standardization of the API is not in the current MIF charter. FMU of = meeting discussion, the idea is just to improve the actual API section with some = words about issues with having disparate API behaviour across different OS; = and, at least, stress that multi-platform applications using such an API (e.g. connection managers) would take benefit from standardization in the = field.

 

Regards,

Pierrick

 

De : Kevin = Chin [mailto:kchin.xor@gmail.com]
Envoy=E9 : lundi 9 = novembre 2009 19:19
=C0 : SEITE Pierrick RD-RESA-REN
Cc : marc.blanchet@viagenie.ca; mif@ietf.org
Objet : Re: [mif] problem-statement: api

 

Hi-

 

Re: "API and/or framework for connection managers should be standardized for the sake of harmonization in addressing MIF = issues"

 

Why is there a need to address the API space? There is a = big difference from Problem Statement definition and API = standardization.

 

regards,

Kevin

 


 

On Mon, Nov 9, 2009 at 8:25 AM, <pierrick.seite@orange-f= tgroup.com> wrote:


Hi,

I couldn't attend the meeting, so I don't know exactly what it has been = said. However, I agree the ps should address API/Connection manager. Actually, = I think this feature is worth a dedicated section. So, based on Marc's = proposal, I'd propose the following text, please feel free to comment/modify:

x. Connection management


Some implementations, specially in the mobile world, have = higher-level

API, and/or connection managers, to address IP configuration = issues in a context of multiple provisioning domains. Depending on the = implementation, and/or OS, these mechanisms do not necessarily behave the same way in = the presence of the MIF problems [draft-ietf-mif-current-practices]. = Therefore, at least, standardization of such an API should be considered in order to facilitate implementation of mechanisms addressing MIF issues. In the = same way, harmonized behaviour of connection manager across different = implementations and/or OS would bring more consistency for MIF users; in such a case, standardization of a framework for connection manager, would be = valuable.

Then in section 5, I'd reword a little bit the Marc's text:

* When available, implementation of multiple interfaces API and/or = connection managers do not necessarily behave the same way in the presence of the = MIF problems. API and/or framework for connection managers should be = standardized for the sake of harmonization in addressing MIF issues.

Feel free to comment.

Regards,
Pierrick

> -----Message d'origine-----
> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Marc
> Blanchet
> Envoy=E9 : lundi 9 novembre 2009 07:56
> =C0 : mif@ietf.org
> Objet : [mif] problem-statement: = api

>
> Hi,
>   following the two comments on the mic about adding some text = in the PS
> about API/Connection manager, here is first text proposal that = would be
> added to section 5.
>
> "Some implementations, specially in the mobile world, have higher-level
> API and/or connection managers. These mechanisms are not = standardized
> and do not necessarily behave the same way in the presence of the = MIF
> problems. Therefore, a standard API could be considered."
>
> Please put more meat around the bone...
>
> Regards, Marc.
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

 

------_=_NextPart_001_01CA61E9.31EAF77F-- From pierrick.seite@orange-ftgroup.com Tue Nov 10 02:14:41 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB1B28C16D for ; Tue, 10 Nov 2009 02:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3LxrDVoDvY9 for ; Tue, 10 Nov 2009 02:14:39 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AAF7228C16E for ; Tue, 10 Nov 2009 02:14:38 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 11:15:03 +0100 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, 10 Nov 2009 11:15:01 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46273ACF9@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] problem-statement: api Thread-Index: Acphu7Hb2m+5dJGaQvCt6lWL6IJ/mQAMouZg References: <4AF7BCF0.9050105@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46273AAFF@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 10 Nov 2009 10:15:03.0006 (UTC) FILETIME=[AADAD7E0:01CA61EE] Cc: mif@ietf.org Subject: Re: [mif] problem-statement: api X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 10:14:41 -0000 Hi, > -----Message d'origine----- > De=A0: Zhen Cao [mailto:caozhenpku@gmail.com] > Envoy=E9=A0: mardi 10 novembre 2009 05:10 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: marc.blanchet@viagenie.ca; mif@ietf.org > Objet=A0: Re: [mif] problem-statement: api >=20 > Hi, >=20 > Although i was not at the meeting site, i attended the meeting using > the audio streaming service and was clear that people agreed to > elaborate the API issues more clearly in the PS draft. >=20 > There is a subsection 3.6 talking about socket API, you might want to > merge your text into that section?=20 You're right. For the text you provided, I > suggest we describe in a way that is more problem oriented. IMO, the > problem is two fold, (a) we do not have advanced API to support some > MIF features and (b) different implementations deliver different > higher level API, so there is a harmonization problem between them. >=20 That makes sense, thanks. > I provided the text as follows: >=20 > "First, TCP/IP stack currently does not provide advanced API to > specify the source IP address or to set preferences on the address > selection policies for both IPv4 and IPv6 address family. Secondly, > differently operation system implementations delivery different set of > high level API, some exported with connection managers to address > connection issues to multiple provisioning domains. These mechanisms > do not necessarily behave the same way in the presence of the MIF > problems [draft-ietf-mif-current-practices]. This results in the > inconsistence problem and makes application developers confused when > they want to develop application across different platforms" >=20 > -Z >=20 > On Tue, Nov 10, 2009 at 12:25 AM, > wrote: > > > > Hi, > > > > I couldn't attend the meeting, so I don't know exactly what it has = been > said. However, I agree the ps should address API/Connection manager. > Actually, I think this feature is worth a dedicated section. So, based = on > Marc's proposal, I'd propose the following text, please feel free to > comment/modify: > > > > x. Connection management > > > > Some implementations, specially in the mobile world, have = higher-level > > API, and/or connection managers, to address IP configuration issues = in a > context of multiple provisioning domains. Depending on the = implementation, > and/or OS, these mechanisms do not necessarily behave the same way in = the > presence of the MIF problems [draft-ietf-mif-current-practices]. > Therefore, at least, standardization of such an API should be = considered > in order to facilitate implementation of mechanisms addressing MIF = issues. > In the same way, harmonized behaviour of connection manager across > different implementations and/or OS would bring more consistency for = MIF > users; in such a case, standardization of a framework for connection > manager, would be valuable. > > > > Then in section 5, I'd reword a little bit the Marc's text: > > > > * When available, implementation of multiple interfaces API and/or > connection managers do not necessarily behave the same way in the = presence > of the MIF problems. API and/or framework for connection managers = should > be standardized for the sake of harmonization in addressing MIF = issues. > > > > Feel free to comment. > > > > Regards, > > Pierrick > > > >> -----Message d'origine----- > >> De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la = part de > Marc > >> Blanchet > >> Envoy=E9=A0: lundi 9 novembre 2009 07:56 > >> =C0=A0: mif@ietf.org > >> Objet=A0: [mif] problem-statement: api > >> > >> Hi, > >> =A0 following the two comments on the mic about adding some text in = the > PS > >> about API/Connection manager, here is first text proposal that = would be > >> added to section 5. > >> > >> "Some implementations, specially in the mobile world, have = higher-level > >> API and/or connection managers. These mechanisms are not = standardized > >> and do not necessarily behave the same way in the presence of the = MIF > >> problems. Therefore, a standard API could be considered." > >> > >> Please put more meat around the bone... > >> > >> Regards, Marc. > >> _______________________________________________ > >> mif mailing list > >> mif@ietf.org > >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > From wherrin@gmail.com Tue Nov 10 08:44:48 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B74C3A6B38 for ; Tue, 10 Nov 2009 08:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMkYxLF57n0M for ; Tue, 10 Nov 2009 08:44:47 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id F3A6F28C136 for ; Tue, 10 Nov 2009 08:44:33 -0800 (PST) Received: by ewy18 with SMTP id 18so201525ewy.43 for ; Tue, 10 Nov 2009 08:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=bSXDGdtXxhWQMbxUcCtmo1RZRM11DCx6+/4KlIhrAVI=; b=e/rYssVzuLvd8lUiyWg0oKSE3xVZReloTgaAZYV74lhTZzQ9aG1R00+zwQ5+1iO80p rt2eloQOaM5NEgWfspl6GMH70C5rEcHAr20s4Rxx3fPhYacKGeylYH5CozXIPfoTQlmI ZM3uL7zddM5ivyUta+yjAXWAnfNHaLIwdxRio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=p1h2u+plzjwu9nqvNVEi95duOYNhVyQio2Emsn7X/C25r1LFREhcwU29LKLheCw4Kw LJH5ozAgRjPCQLqoxJ/68R0K18dW43nw4eV0BQb8KQ2/rD54J4mFR81pDkzLNSRf4MyA VfOnHWZIUr0LJ2yaYdYYUEAkzLS6hsujJF+K4= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.86.212 with SMTP id w62mr104940wee.131.1257871496483; Tue, 10 Nov 2009 08:44:56 -0800 (PST) In-Reply-To: <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> Date: Tue, 10 Nov 2009 11:44:56 -0500 X-Google-Sender-Auth: 56b106cf4995e53c Message-ID: <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> From: William Herrin To: Jan Melen Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:44:48 -0000 On Tue, Nov 10, 2009 at 12:00 AM, Jan Melen wrote: > On Nov 10, 2009, at 6:03 AM, William Herrin wrote: >> Starting from a post-multipath TCP world... >> >> The situation that jumps to mind is: >> >> 3 offices, A B and C. >> >> B connects to A with a T1. >> C connects to A with a T1. >> B connects to C with a T1. So they're connected in a triangle. >> >> A connects to the Internet with a DSL. >> B also connects to the Internet with a WiMax link. >> >> Server located at C called CS. It has an address from the DSL ISP and >> an address from the WiMax ISP. >> >> CS(DSL)->CA router->AC Router->DSL Router->Internet >> CS(WiMax)->CB router->BC Router->WiMax Router->Internet >> >> But if the CA T1 is down then: >> CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL >> Router->Internet > > > The CA router can't for the packet that has the source address of the DSL > ISP to the CB router. It should. If we remove the WiMax connection so there's only one network domain, we would certainly expect a packet for the Internet at router CA to find it's way to the DSL router at site A regardless of whether the T1 from site C to site A was up. Adding the WiMax internet link at site B should in no way impact CS(DSL)'s ability to reach the Internet via the DSL line at site A. That's among the reasons I think its important to consider the router case in addition to the host case. >> Now if you go back and think of host CS the same way as the routers, >> CS has the following routes: >> 1.2.3.35/32+1.2.3.32/28->eth0 >> 1.2.3.35/32+0.0.0.0/0->Router CA metric 2 >> 1.2.3.35/32+0.0.0.0/0->Router CB metric 3 >> 4.5.6.35/32+4.5.6.32/28->eth0 >> 4.5.6.35/32+0.0.0.0/0->Router CB metric 2 >> 4.5.6.35/32+0.0.0.0/0->Router CA metric 3 >> 7.8.9.35/32+7.8.9.32/28->eth0 >> 7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1 >> 127.0.0.0/8+127.0.0.0/8->loopback > > If any of the default routes fail in such configuration it should be the > routing protocol that stops advertising default route through that interface > at that point in which case it would result that default route through that > interface deprecates in few minutes and the traffic will be routed through > another router. Existing connections will break if there is no translation > in place in the network see the earlier comments about source address > filtering. Yes. That's the desired behavior: if the internet link is unavailable for a given source address then depending on the nature of the failure packets to the Internet from that source address either vanish into the ether or return a destination unreachable. It's then up to higher level protocols (like Multipath TCP) to detect and deal with the path failure, shifting the failed source address out of use. On the other hand, just because the Internet link was lost doesn't mean the administrative domain goes away. In the scenario I painted, the IP addresses from the failed Internet link are still valid for communication within three sites; they just aren't workable for a default route any more. > DHCP has very poor or non-existing mechanisms to inform the clients about > changes in the network routing information as the protocol is designed to be > pull instead of push where as all routing protocols are much more > appropriate for this type of operation. A good point to make in the problem statement if it isn't already there. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jan.melen@nomadiclab.com Tue Nov 10 10:44:27 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455D43A6B59 for ; Tue, 10 Nov 2009 10:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnbsL3W8yOBI for ; Tue, 10 Nov 2009 10:44:26 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4C2293A6B44 for ; Tue, 10 Nov 2009 10:44:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0983E1EF1EA; Tue, 10 Nov 2009 20:44:52 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAk4dh7Ln64G; Tue, 10 Nov 2009 20:44:51 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id AB0291EF12E; Tue, 10 Nov 2009 20:44:49 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-140-398613482 From: Jan Melen In-Reply-To: <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> Date: Tue, 10 Nov 2009 20:44:47 +0200 Message-Id: <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> To: William Herrin X-Mailer: Apple Mail (2.1076) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:44:27 -0000 --Apple-Mail-140-398613482 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On Nov 10, 2009, at 6:44 PM, William Herrin wrote: > On Tue, Nov 10, 2009 at 12:00 AM, Jan Melen > wrote: >> On Nov 10, 2009, at 6:03 AM, William Herrin wrote: >>> Starting from a post-multipath TCP world... >>> >>> The situation that jumps to mind is: >>> >>> 3 offices, A B and C. >>> >>> B connects to A with a T1. >>> C connects to A with a T1. >>> B connects to C with a T1. So they're connected in a triangle. >>> >>> A connects to the Internet with a DSL. >>> B also connects to the Internet with a WiMax link. >>> >>> Server located at C called CS. It has an address from the DSL ISP >>> and >>> an address from the WiMax ISP. >>> >>> CS(DSL)->CA router->AC Router->DSL Router->Internet >>> CS(WiMax)->CB router->BC Router->WiMax Router->Internet >>> >>> But if the CA T1 is down then: >>> CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL >>> Router->Internet >> >> >> The CA router can't for the packet that has the source address of >> the DSL >> ISP to the CB router. > > It should. If we remove the WiMax connection so there's only one > network domain, we would certainly expect a packet for the Internet at > router CA to find it's way to the DSL router at site A regardless of > whether the T1 from site C to site A was up. Adding the WiMax internet > link at site B should in no way impact CS(DSL)'s ability to reach the > Internet via the DSL line at site A. Oops sorry my mistake I though you were talking about that the connection to ISP went down but obviously you meant that the T1 connection between C and A dies. In that case, yes, the routing protocol should resolve this situation. As probably the routers A, B, C run some routing protocol (OSPF, BGP, RIP or whatever) that will have to resolve the situation and get the packets routed correctly through although using route that is less preferred than the route normally used due to higher metric value. Of course as we now are talking about multiple default routes that are advertised between the routers A, B, C so we need to add source address prefix in to the default route advertisements. Right? Then the C router should see that router A is advertising (default, prefix:1.2.3.0/24, metric 1) and B is advertising (default, prefix:1.2.3.0/24, metric 2). This information doesn't necessarily need to go all the way to client. If it does, e.g. there are two physically different routers that CS may use to reach networks A and B, then we need that CS listens to these advertisements and makes up his mind and if it is the CS that has to select the correct next hop router then DHCP is not the protocol you want to use to configure routes as it is designed to deliver more or less static routes that do not change (at least) during the address lease time. > That's among the reasons I think its important to consider the router > case in addition to the host case. > > >>> Now if you go back and think of host CS the same way as the routers, >>> CS has the following routes: >>> 1.2.3.35/32+1.2.3.32/28->eth0 >>> 1.2.3.35/32+0.0.0.0/0->Router CA metric 2 >>> 1.2.3.35/32+0.0.0.0/0->Router CB metric 3 >>> 4.5.6.35/32+4.5.6.32/28->eth0 >>> 4.5.6.35/32+0.0.0.0/0->Router CB metric 2 >>> 4.5.6.35/32+0.0.0.0/0->Router CA metric 3 >>> 7.8.9.35/32+7.8.9.32/28->eth0 >>> 7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1 >>> 127.0.0.0/8+127.0.0.0/8->loopback >> >> If any of the default routes fail in such configuration it should >> be the >> routing protocol that stops advertising default route through that >> interface >> at that point in which case it would result that default route >> through that >> interface deprecates in few minutes and the traffic will be routed >> through >> another router. Existing connections will break if there is no >> translation >> in place in the network see the earlier comments about source address >> filtering. > > Yes. That's the desired behavior: if the internet link is unavailable > for a given source address then depending on the nature of the failure > packets to the Internet from that source address either vanish into > the ether or return a destination unreachable. It's then up to higher > level protocols (like Multipath TCP) to detect and deal with the path > failure, shifting the failed source address out of use. > > On the other hand, just because the Internet link was lost doesn't > mean the administrative domain goes away. In the scenario I painted, > the IP addresses from the failed Internet link are still valid for > communication within three sites; they just aren't workable for a > default route any more. > Yep, the addresses are valid for internal traffic but the default route is not any more valid. > >> DHCP has very poor or non-existing mechanisms to inform the clients >> about >> changes in the network routing information as the protocol is >> designed to be >> pull instead of push where as all routing protocols are much more >> appropriate for this type of operation. > > A good point to make in the problem statement if it isn't already > there. > Regards, Jan --Apple-Mail-140-398613482 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Tue, Nov 10, 2009 at 12:00 AM, Jan Melen <jan.melen@nomadiclab.com> = wrote:
On Nov 10, 2009, at 6:03 AM, William = Herrin wrote:
Starting from a post-multipath TCP = world...

The situation that jumps to mind = is:

3 offices, A B and = C.

B connects to A with a = T1.
C connects to A with a = T1.
B connects to C with a T1. So they're connected in a = triangle.

A connects to the Internet with = a DSL.
B also connects to the Internet with a WiMax = link.

Server located at C called CS. = It has an address from the DSL ISP = and
an address from the WiMax = ISP.

CS(DSL)->CA router->AC = Router->DSL = Router->Internet
CS(WiMax)->CB router->BC = Router->WiMax = Router->Internet

But if the CA T1 is down = then:
CS(DSL)->CA router->CB Router->BC Router->BA = Router->AB Router->DSL
Router->Internet


The CA router = can't for the packet that has the source address of the = DSL
ISP to the CB = router.

It should. If we remove the WiMax connection = so there's only one
network domain, we would certainly expect a = packet for the Internet at
router CA to find it's way to the DSL = router at site A regardless of
whether the T1 from site C to site A = was up. Adding the WiMax internet
link at site B should in no way = impact CS(DSL)'s ability to reach the
Internet via the DSL line at = site A.


Oops = sorry my mistake I though you were talking about that the connection to = ISP went down but obviously you meant that the T1 connection between C = and A dies. In that case, yes, the routing protocol should resolve this = situation. As probably the routers A, B, C run some routing protocol = (OSPF, BGP, RIP or whatever) that will have to resolve the situation and = get the packets routed correctly through although using route that is = less preferred than the route normally used due to higher metric value. = Of course as we now are talking about multiple default routes that are = advertised between the routers A, B, C so we need to add source address = prefix in to the default route advertisements. Right? Then the C router = should see that router A is advertising (default, prefix:1.2.3.0/24, = metric 1)  and B is advertising (default, prefix:1.2.3.0/24, = metric 2). This information doesn't necessarily need to go all the way = to client. If it does, e.g. there are two physically different routers = that CS may use to reach networks A and B, then we need that CS listens = to these advertisements and makes up his mind and if it is the CS that = has to select the correct next hop router then DHCP is not the protocol = you want to use to configure routes as it is designed to deliver more or = less static routes that do not change (at least) during the address = lease time.



That's among the reasons I think its important to = consider the router
case in addition to the host = case.


Now = if you go back and think of host CS the same way as the = routers,
CS has the following = routes:
1.2.3.35/32+1.2.3.32/28->eth0
1.2.3.35/32+0.0.0.0/0->Router CA metric = 2
1.2.3.35/32+0.0.0.0/0->Router CB metric = 3
4.5.6.35/32+4.5.6.32/28->eth0
4.5.6.35/32+0.0.0.0/0->Router CB metric = 2
4.5.6.35/32+0.0.0.0/0->Router CA metric = 3
7.8.9.35/32+7.8.9.32/28->eth0
7.8.9.35/32+0.0.0.0/0->Cable Modem metric = 1
127.0.0.0/8+127.0.0.0/8->loopback

If any of the default routes fail in such configuration it = should be the
routing protocol = that stops advertising default route through that = interface
at that point in = which case it would result that default route through = that
interface deprecates in = few minutes and the traffic will be routed = through
another router. = Existing connections will break if there is no = translation
in place in the = network see the earlier comments about source = address
filtering.

Yes. That's the desired = behavior: if the internet link is unavailable
for a given source = address then depending on the nature of the failure
packets to the = Internet from that source address either vanish into
the ether or = return a destination unreachable. It's then up to higher
level = protocols (like Multipath TCP) to detect and deal with the = path
failure, shifting the failed source address out of = use.

On the other hand, just because the Internet link was lost = doesn't
mean the administrative domain goes away. In the scenario I = painted,
the IP addresses from the failed Internet link are still = valid for
communication within three sites; they just aren't workable = for a
default route any = more.



Yep, = the addresses are valid for internal traffic but the default route is = not any more valid.



DHCP has very poor or = non-existing mechanisms to inform the clients = about
changes in the network = routing information as the protocol is designed to = be
pull instead of push where = as all routing protocols are much more
appropriate for this type of = operation.

A good point to make in the problem = statement if it isn't already there.



=
  Regards,
   =  Jan
= --Apple-Mail-140-398613482-- From trac@tools.ietf.org Tue Nov 10 14:11:49 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D8E3A697D for ; Tue, 10 Nov 2009 14:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNhw3j2fiRtI for ; Tue, 10 Nov 2009 14:11:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4A21D3A68EF for ; Tue, 10 Nov 2009 14:11:48 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7ywh-0006KF-Qr; Tue, 10 Nov 2009 14:12:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: mrw@sandstorm.net X-Trac-Project: mif Date: Tue, 10 Nov 2009 22:12:14 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/mif/trac/ticket/1 Message-ID: <055.a0b2efd97c620f820dfb0f2c0cf5a0b9@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mrw@sandstorm.net, mif@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Nov 2009 16:24:38 -0800 Cc: mif@ietf.org Subject: [mif] #1: Test Ticket X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:11:49 -0000 #1: Test Ticket -------------------------------+-------------------------------------------- Reporter: mrw@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: current-practices | Version: Severity: - | Keywords: -------------------------------+-------------------------------------------- This is a test ticket to see how the MIF issue tracker works. -- Ticket URL: mif From trac@tools.ietf.org Tue Nov 10 14:13:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA85D3A69DF for ; Tue, 10 Nov 2009 14:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eImBM6VyhsTH for ; Tue, 10 Nov 2009 14:13:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id A3EFA3A6993 for ; Tue, 10 Nov 2009 14:13:06 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N7yxy-0008Vd-GV; Tue, 10 Nov 2009 14:13:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: mrw@sandstorm.net X-Trac-Project: mif Date: Tue, 10 Nov 2009 22:13:34 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/mif/trac/ticket/2 Message-ID: <055.e9be263e1a555fc087c659db7ec05c4e@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mrw@sandstorm.net, mif@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Nov 2009 16:24:38 -0800 Cc: mif@ietf.org Subject: [mif] #2: Another test X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:13:08 -0000 #2: Another test -------------------------------+-------------------------------------------- Reporter: mrw@… | Owner: mrw@… Type: defect | Status: new Priority: major | Milestone: Component: current-practices | Version: Severity: - | Keywords: -------------------------------+-------------------------------------------- Still testing... -- Ticket URL: mif From trac@tools.ietf.org Tue Nov 10 19:25:55 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE91F3A6878 for ; Tue, 10 Nov 2009 19:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NrhAnuVagsG for ; Tue, 10 Nov 2009 19:25:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4D7C63A6807 for ; Tue, 10 Nov 2009 19:25:55 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N83qh-0001sJ-BQ; Tue, 10 Nov 2009 19:26:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: marc.blanchet@viagenie.ca X-Trac-Project: mif Date: Wed, 11 Nov 2009 03:26:23 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/mif/trac/ticket/3 Message-ID: <063.b6b535bc05ce5fbd04853ec9a4d31271@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: marc.blanchet@viagenie.ca, mif@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Nov 2009 20:46:56 -0800 Cc: mif@ietf.org Subject: [mif] #3: add discussion on API/connection manager X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:25:56 -0000 #3: add discussion on API/connection manager ---------------------------------------+------------------------------------ Reporter: marc.blanchet@… | Owner: marc.blanchet@… Type: enhancement | Status: new Priority: major | Milestone: Component: problem-statement | Version: Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ see comments during Hiroshima mif meeting. -- Ticket URL: mif From trac@tools.ietf.org Tue Nov 10 19:26:58 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA42E28C26A for ; Tue, 10 Nov 2009 19:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMDZT5DzNHxp for ; Tue, 10 Nov 2009 19:26:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4D65728C27E for ; Tue, 10 Nov 2009 19:26:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N83ri-0002nj-Bv; Tue, 10 Nov 2009 19:27:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: marc.blanchet@viagenie.ca X-Trac-Project: mif Date: Wed, 11 Nov 2009 03:27:26 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/mif/trac/ticket/4 Message-ID: <063.d8efb08c37bc9950278f127286bc8b61@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: marc.blanchet@viagenie.ca, mif@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 10 Nov 2009 20:46:56 -0800 Cc: mif@ietf.org Subject: [mif] #4: add reference to grobj X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:26:59 -0000 #4: add reference to grobj ---------------------------------------+------------------------------------ Reporter: marc.blanchet@… | Owner: marc.blanchet@… Type: enhancement | Status: new Priority: major | Milestone: Component: problem-statement | Version: Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ comment by Brian Carpenter to add grobj as related work. -- Ticket URL: mif From Xiangsong.Cui@huawei.com Sun Nov 15 23:14:44 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8744D28C0D6 for ; Sun, 15 Nov 2009 23:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TBoeRx581oL for ; Sun, 15 Nov 2009 23:14:43 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4C1EF28C0DD for ; Sun, 15 Nov 2009 23:14:43 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT600GR6XG8CS@szxga03-in.huawei.com> for mif@ietf.org; Mon, 16 Nov 2009 15:14:32 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KT600NMEXG703@szxga03-in.huawei.com> for mif@ietf.org; Mon, 16 Nov 2009 15:14:32 +0800 (CST) Date: Mon, 16 Nov 2009 15:14:30 +0800 From: Xiangsong Cui To: William Herrin , liu dapeng Message-id: <01ce01ca668c$714607f0$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 07:14:44 -0000 Hi William, Sorry for jumping into the discussion, I just want to remind that Router and Host are different concept. >>> Routers are hosts too and figuring out ...... Take the definition from RFC2460: router - a node that forwards IPv6 packets not explicitly addressed to itself. [See Note below]. host - any node that is not a router. [See Note below]. Although they are both node - a device that implements IPv6. Regards Xiangsong ----- Original Message ----- From: "William Herrin" To: "liu dapeng" Cc: Sent: Tuesday, November 10, 2009 12:03 PM Subject: Re: [mif] Some thoughts > On Mon, Nov 9, 2009 at 10:11 PM, liu dapeng wrote: >>> Routers are hosts too and figuring out how to handle packets to >>> multiple upstreams in different administrative domains is important >>> there as well. Otherwise we limit ourselves to only the simplest case: >>> where no component larger than a single host is a member of two >>> networks. As often as not, that isn't the case. The entire local LAN >>> can be a member of two upstream networks and it'd be nice if entire >>> routed subsystems could be members of two networks. >> >> In my understanding, router normally does not have the multiple >> interfaces issue, since router is designed to forward packets across >> different interfaces and there is no default route issue in router. so >> what problems are you thinking that need to be solved? > > Hi, > > Starting from a post-multipath TCP world... > > The situation that jumps to mind is: > > 3 offices, A B and C. > > B connects to A with a T1. > C connects to A with a T1. > B connects to C with a T1. So they're connected in a triangle. > > A connects to the Internet with a DSL. > B also connects to the Internet with a WiMax link. > > Server located at C called CS. It has an address from the DSL ISP and > an address from the WiMax ISP. > > CS(DSL)->CA router->AC Router->DSL Router->Internet > CS(WiMax)->CB router->BC Router->WiMax Router->Internet > > But if the CA T1 is down then: > CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL > Router->Internet > > And while CS has two addresses and network blocks, it has only one > ethernet interface on which it talks to both the CA and CB routers. > > > Following me? The routers in the picture have two different routing > domains depending on the source address. > > > Add an Internet cable modem to site C and now you have to handle 3 > routing domains on every router in the system. > > > But if you keep thinking about it, maybe you don't try to introduce > routing domains at all. Maybe you introduce source+destation CIDR > pairs instead of just destination CIDRs. So, the DSL at A offers > 1.2.3.0/24+0.0.0.0/0, the WiMax at B announces 4.5.6.0/24+0.0.0.0/0 > and the cable modem at C announces 7.8.9.0/24+0.0.0.0/0. On the flip > side, the site-C routers announce 0.0.0.0/0+1.2.3.32/28, > 0.0.0.0/0+4.5.6.32/28 and 0.0.0.0/0+7.8.9.32/28. Now there's just one > routing domain and six routes which work sensibly in a dynamic routing > protocol. > > And if CS gets hacked and tries to send a packet to 9.9.9.9 from the > forged source address 8.8.8.8, the packet dies at the first router > because there's no route for 8.8.8.8/32+9.9.9.9/32. > > Now if you go back and think of host CS the same way as the routers, > CS has the following routes: > 1.2.3.35/32+1.2.3.32/28->eth0 > 1.2.3.35/32+0.0.0.0/0->Router CA metric 2 > 1.2.3.35/32+0.0.0.0/0->Router CB metric 3 > 4.5.6.35/32+4.5.6.32/28->eth0 > 4.5.6.35/32+0.0.0.0/0->Router CB metric 2 > 4.5.6.35/32+0.0.0.0/0->Router CA metric 3 > 7.8.9.35/32+7.8.9.32/28->eth0 > 7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1 > 127.0.0.0/8+127.0.0.0/8->loopback > > Or so goes my train of thought anyway... > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From wherrin@gmail.com Mon Nov 16 08:06:22 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121E628C143 for ; Mon, 16 Nov 2009 08:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvXc74F4q5eb for ; Mon, 16 Nov 2009 08:06:21 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by core3.amsl.com (Postfix) with ESMTP id BD5B53A6767 for ; Mon, 16 Nov 2009 08:06:20 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so678899gvc.15 for ; Mon, 16 Nov 2009 08:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=DVm1lZEGl/hH2V1tHef//uoJDw9bHsvGxCJdJ/le6+w=; b=NGwiQQB8oncmKTZ531dej6s7gzmnaWORddvhOtSsmZkpw1sHEiLT2CackVSV9zlX0y AAUILTVt6zeJxL638yxHXW8rm+JwLIBTu3yWPwvjxle2pZ1DJZBIAAaubUo/4TVhb9Xx Pp6H+UcON+JguZsv3Xpaw2Z7bpJkmvUGIMGVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JbxWEmCS7TQmNS/U/xMnjpd7QtyOovdL3pSviG57vj1XuCXu13CMFygvs8yH1TJwtR 9Wx7GOms2Lm0gFDCGaHjaIlmtDmigvaMlhy0VvbKqmYKHa0XFwuC7xwrRcnB5vjy6j8x HFLdy09Q9e5QmE8Y6AVQfO4ujzDeNSt1DMlTI= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.85.143 with SMTP id u15mr2610124wee.205.1258387576453; Mon, 16 Nov 2009 08:06:16 -0800 (PST) In-Reply-To: <01ce01ca668c$714607f0$58106f0a@china.huawei.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <01ce01ca668c$714607f0$58106f0a@china.huawei.com> Date: Mon, 16 Nov 2009 11:06:16 -0500 X-Google-Sender-Auth: 3b7156212bc8710a Message-ID: <3c3e3fca0911160806i3aaf3abj97d7ad8f60ff02e4@mail.gmail.com> From: William Herrin To: Xiangsong Cui Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:06:22 -0000 On Mon, Nov 16, 2009 at 2:14 AM, Xiangsong Cui wrote: > I just want to remind that Router and Host are different concept. > >>>> Routers are hosts too and figuring out ...... > > Take the definition from RFC2460: Hi Xiangsong, Two observations: 1. MIF's charter is not IPv6 specific and the distinction you draw was not made for IPv4. 2. Both the IPv4 and IPv6 network stacks for PC's and routers have stayed more or less converged for quite a while. Higher end routers have some hardware assists that don't tend to show up in PCs but they're otherwise just close to identical. If we're to recommend that change, we ought to have better reasoning than, "we didn't want to deal with the router case" and we should very thoroughly explain that reasoning. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Mon Nov 16 08:08:45 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D76B28B797 for ; Mon, 16 Nov 2009 08:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAhZEAF3UAaB for ; Mon, 16 Nov 2009 08:08:44 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 26C043A6903 for ; Mon, 16 Nov 2009 08:08:43 -0800 (PST) Received: by bwz23 with SMTP id 23so5907652bwz.29 for ; Mon, 16 Nov 2009 08:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=lsJ3IXmVvFoMkMTr/o31ZRu3WVJhUFlwOHcMGEcDG+I=; b=uSeTmidDlIQ0RSbU1knmeIYG3IgqQB/aIKfrIeDxMualA2XUq9m92mkXOs7VeobAlH S/0lhcRDIg16OyabmxmyiXuRQJRtBFCUwcO+KQJpxcye/NB6QjxjeHtzdpKXw51trPj1 fnfHm+i0nD71+krFFLxFiRZrtZiRwA9M1Jc5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=GdpJAatv0Hl1n7eW14mxa4MH6SK+yAeQHJLq1SrkjGOI4jAHU4L+fVySeb/F1c8gv7 DRwau9ktZg1cf6TDtlu4Jw/WLA+gb8dqfntWj6dB17qtYpLPG4dbtPFjAJHlggsDUts0 UthsPffkMkUnz6KfVlbf/AjsY8BV0bRnuDDPs= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.89.135 with SMTP id c7mr1482819wef.62.1258387722516; Mon, 16 Nov 2009 08:08:42 -0800 (PST) In-Reply-To: <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> Date: Mon, 16 Nov 2009 11:08:42 -0500 X-Google-Sender-Auth: bfe7b6d06828ea75 Message-ID: <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> From: William Herrin To: Jan Melen Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:08:45 -0000 On Tue, Nov 10, 2009 at 1:44 PM, Jan Melen wrote: > Of course as we now are talking > about multiple default routes that are advertised between the routers A, B, > C so we need to add source address prefix in to the default route > advertisements. Right? Hi Jan, Do we? What about routes other than the default? Does it ever make sense for a small ISP to propogate three source address ranges on each link downstream instead of introducing DFZ routes of its own? We've identified at least two approaches here, tying source and destination together in the route and establishing entirely separate routing domains for each source range. Are there more ways to look at the problem? I think that's a worthwhile question for the problem statement. > we need that CS listens to these advertisements and makes up his mind and if > it is the CS that has to select the correct next hop router then DHCP is not > the protocol you want to use to configure routes as it is designed to > deliver more or less static routes that do not change (at least) during the > address lease time. How big a concern is that? Won't the higher-level protocols have to deal with dead path detection anyway? Even if you have a legitimate default route, there's no guarantee that all of your ISPs are fully connected right now. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Xiangsong.Cui@huawei.com Mon Nov 16 17:58:07 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203E83A672E for ; Mon, 16 Nov 2009 17:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.054 X-Spam-Level: * X-Spam-Status: No, score=1.054 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coxEmEkxQV2V for ; Mon, 16 Nov 2009 17:58:06 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C8D7F3A67AE for ; Mon, 16 Nov 2009 17:58:05 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT800HWHDGOHA@szxga04-in.huawei.com> for mif@ietf.org; Tue, 17 Nov 2009 09:58:01 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KT80045ADGOZ8@szxga04-in.huawei.com> for mif@ietf.org; Tue, 17 Nov 2009 09:58:00 +0800 (CST) Date: Tue, 17 Nov 2009 09:57:59 +0800 From: Xiangsong Cui To: William Herrin Message-id: <001c01ca6729$639cf030$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <01ce01ca668c$714607f0$58106f0a@china.huawei.com> <3c3e3fca0911160806i3aaf3abj97d7ad8f60ff02e4@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 01:58:07 -0000 Hi, This is just a comment but not objection to the discussion, About the difference between host and router, Wiki may also be taken as a reference, http://en.wikipedia.org/wiki/Host_(network) Yes, there are software routers, the configuration option in Linux PCs and others... but the operation of *pure host* and router are different practice. Regards Xiangsong ----- Original Message ----- From: "William Herrin" To: "Xiangsong Cui" Cc: "liu dapeng" ; Sent: Tuesday, November 17, 2009 12:06 AM Subject: Re: [mif] Some thoughts > On Mon, Nov 16, 2009 at 2:14 AM, Xiangsong Cui > wrote: >> I just want to remind that Router and Host are different concept. >> >>>>> Routers are hosts too and figuring out ...... >> >> Take the definition from RFC2460: > > Hi Xiangsong, > > Two observations: > > 1. MIF's charter is not IPv6 specific and the distinction you draw was > not made for IPv4. > > 2. Both the IPv4 and IPv6 network stacks for PC's and routers have > stayed more or less converged for quite a while. Higher end routers > have some hardware assists that don't tend to show up in PCs but > they're otherwise just close to identical. If we're to recommend that > change, we ought to have better reasoning than, "we didn't want to > deal with the router case" and we should very thoroughly explain that > reasoning. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From Scott.Brim@gmail.com Wed Nov 18 10:28:51 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2945528C0ED for ; Wed, 18 Nov 2009 10:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw2FEiFiDWn8 for ; Wed, 18 Nov 2009 10:28:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 478593A687E for ; Wed, 18 Nov 2009 10:28:50 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAD3MA0tAZnwN/2dsb2JhbABBkTetMIc2gWUIhgCIcoJLCIFoBA X-IronPort-AV: E=Sophos;i="4.44,766,1249257600"; d="scan'208";a="68787535" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2009 18:28:48 +0000 Received: from cisco.com (che-vpn-cluster-2-85.cisco.com [10.86.242.85]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAIISlZq027004 for ; Wed, 18 Nov 2009 18:28:47 GMT Date: Wed, 18 Nov 2009 03:31:22 -0600 From: Scott Brim To: mif@ietf.org Message-ID: <20091118093122.GN8871@cisco.com> Mail-Followup-To: Scott Brim , mif@ietf.org References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:28:51 -0000 Bill, I don't understand exactly what you're saying but it seems to be something like: - An endpoint may have multiple addresses assigned to it on a single interface. It could even have addresses from different PA prefixes from upstream providers. - If source address and upstream provider path don't match, packets could be dropped. - Address selection itself can't help here, so you suggest that routing take source address into account until packets get beyond where uRPF is enforced. Is that right? swb From wherrin@gmail.com Wed Nov 18 14:50:37 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F8B3A6AF5 for ; Wed, 18 Nov 2009 14:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAaMaTEftzTQ for ; Wed, 18 Nov 2009 14:50:36 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 676483A6AF3 for ; Wed, 18 Nov 2009 14:50:36 -0800 (PST) Received: by fxm7 with SMTP id 7so1810654fxm.29 for ; Wed, 18 Nov 2009 14:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=juPTqwLTzIfX4HgjZPSmNFucBqUOWmSH9XsvGnhCriY=; b=VgBL4QXsDczRKz7fN1ALrMMWAziadKksph4tiz/+hNPtWyxR0QfC+CziUY3ADIpjxX NWL8kmoh9Xnu6llvivFf7EeN41uC/eNwkyuqgJjRmnTCutlYCspxqTarfQ7fy4xSLcV6 Q8Rk3xF4AoOFux1SasFE7OnofpQ3fksrB5Gng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=J80rBtqKF7S6mkVLbQ16rxlOtJaR8F8+v5dDeCpLZWrBn0XmgZtINoxySIuQfLiX0Z gFkbFc+L8Y6xBS/LFmfDDjwPdvyX2ivqrN53qAlEYS5HQC/iLonoehKznYbnfbOy6ASf VoxG1xdyIocr3QQbS8VI1y2uHbRtmkXcPhzKw= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.87.194 with SMTP id y44mr747109wee.204.1258584634117; Wed, 18 Nov 2009 14:50:34 -0800 (PST) In-Reply-To: <20091118093122.GN8871@cisco.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> <20091118093122.GN8871@cisco.com> Date: Wed, 18 Nov 2009 17:50:34 -0500 X-Google-Sender-Auth: 0b9e6b2eac1133d6 Message-ID: <3c3e3fca0911181450w5c0b956fga77a219dc48d9871@mail.gmail.com> From: William Herrin To: Scott Brim , mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 22:50:37 -0000 On Wed, Nov 18, 2009 at 4:31 AM, Scott Brim wrote: > Bill, I don't understand exactly what you're saying but it seems to > be something like: > > =A0- An endpoint may have multiple addresses assigned to it on a single > =A0 =A0interface. =A0It could even have addresses from different PA > =A0 =A0prefixes from upstream providers. > =A0- If source address and upstream provider path don't match, packets > =A0 =A0could be dropped. > =A0- Address selection itself can't help here, so you suggest that > =A0 =A0routing take source address into account until packets get beyond > =A0 =A0where uRPF is enforced. Hi Scott, That too, but I'm trying to convey what I think is a more important notion: Address selection is classically a simple function on the routing table: pick the primary address of the interface the destination routes out of. With multiple administrative domains, address selection may *still* be a simple function on the routing table... the more significant difference may be in the routing table itself. That notion is suggested by the following example: (A,B,C)-D-(E,F) Where A, B, C are hosts, D is a router and E, F are ISPs supplying two different administrative domains with unique blocks of PA addresses. The two domains propogate from E and F down through D to hosts A, B and C. A, B, C and D *all* need to do the right thing with respect to source address selection and route selection based on source address. *AND* if D is a complex network instead of a simple router, that complex network needs a *dynamic routing protocol* that helps the routers in D do the right thing, not just static policy routing. I'm not sure if MIF is correctly scoped for that, but offer the thought that maybe it should be. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From remi.despres@free.fr Thu Nov 19 01:06:15 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0D23A693E for ; Thu, 19 Nov 2009 01:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UheqDGlG8sbL for ; Thu, 19 Nov 2009 01:06:14 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 356A93A68CC for ; Thu, 19 Nov 2009 01:06:12 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id D9EBAE080EF; Thu, 19 Nov 2009 10:06:06 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 88375E08010; Thu, 19 Nov 2009 10:06:03 +0100 (CET) In-Reply-To: <3c3e3fca0911181450w5c0b956fga77a219dc48d9871@mail.gmail.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> <20091118093122.GN8871@cisco.com> <3c3e3fca0911181450w5c0b956fga77a219dc48d9871@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 19 Nov 2009 10:06:02 +0100 To: William Herrin X-Mailer: Apple Mail (2.753.1) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:06:15 -0000 Le 18 nov. 09 =E0 23:50, William Herrin a =E9crit : > On Wed, Nov 18, 2009 at 4:31 AM, Scott Brim =20 > wrote: >> Bill, I don't understand exactly what you're saying but it seems to >> be something like: >> >> - An endpoint may have multiple addresses assigned to it on a single >> interface. It could even have addresses from different PA >> prefixes from upstream providers. >> - If source address and upstream provider path don't match, packets >> could be dropped. >> - Address selection itself can't help here, so you suggest that >> routing take source address into account until packets get beyond >> where uRPF is enforced. > > Hi Scott, > > That too, but I'm trying to convey what I think is a more important > notion: Address selection is classically a simple function on the > routing table: pick the primary address of the interface the > destination routes out of. With multiple administrative domains, > address selection may *still* be a simple function on the routing > table... the more significant difference may be in the routing table > itself. > > That notion is suggested by the following example: > > (A,B,C)-D-(E,F) > > Where A, B, C are hosts, D is a router and E, F are ISPs supplying two > different administrative domains with unique blocks of PA addresses. > The two domains propogate from E and F down through D to hosts A, B > and C. A, B, C and D *all* need to do the right thing with respect to > source address selection and route selection based on source address. Yes, that's the key. > *AND* if D is a complex network instead of a simple router, that > complex network needs a *dynamic routing protocol* that helps the > routers in D do the right thing, not just static policy routing. In a complex D, an alternative to a dynamic routing protocol consists =20= in a stateless address mapping, in border hosts and routers of D, =20 with encapsulation of global packets to traverse D. This is feasible with the SAM approach described in draft-despres-=20 softwire-mesh-sam-01. A customer-side border node, when it has to forward a global packet =20 toward the global Internet, selects the destination of the =20 encapsulating header based on which PA prefix it finds in the source =20 global address. This destination is the address of the provider-side =20 border router to which this PA prefix has been delegated (known by =20 some parameters received in DHCP ). If you have a look at this draft, maybe you can tell whether you =20 agree or not on the relationship with the point you make. Regards, RD > I'm not sure if MIF is correctly scoped for that, but offer the > thought that maybe it should be. > > Regards, > Bill Herrin > > > --=20 > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From jan.melen@nomadiclab.com Thu Nov 19 22:27:39 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1ED83A6935 for ; Thu, 19 Nov 2009 22:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8wGy2NmgAv3 for ; Thu, 19 Nov 2009 22:27:38 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1DE553A69A7 for ; Thu, 19 Nov 2009 22:27:36 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6F7931EF1EA; Fri, 20 Nov 2009 08:27:32 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlVTcw+kWfYH; Fri, 20 Nov 2009 08:27:31 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 83A8A1EF12E; Fri, 20 Nov 2009 08:27:31 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jan Melen In-Reply-To: <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> Date: Fri, 20 Nov 2009 08:27:30 +0200 Content-Transfer-Encoding: 7bit Message-Id: <82677ED5-9F97-4992-AD6C-AD037DC16700@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> To: William Herrin X-Mailer: Apple Mail (2.1076) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 06:27:39 -0000 Hi, On Nov 16, 2009, at 6:08 PM, William Herrin wrote: > On Tue, Nov 10, 2009 at 1:44 PM, Jan Melen > wrote: >> Of course as we now are talking >> about multiple default routes that are advertised between the >> routers A, B, >> C so we need to add source address prefix in to the default route >> advertisements. Right? > > Do we? What about routes other than the default? Does it ever make > sense for a small ISP to propogate three source address ranges on each > link downstream instead of introducing DFZ routes of its own? Yep, you're right one could also introduce DFZ routes. > We've identified at least two approaches here, tying source and > destination together in the route and establishing entirely separate > routing domains for each source range. Are there more ways to look at > the problem? > > I think that's a worthwhile question for the problem statement. > > >> we need that CS listens to these advertisements and makes up his >> mind and if >> it is the CS that has to select the correct next hop router then >> DHCP is not >> the protocol you want to use to configure routes as it is designed to >> deliver more or less static routes that do not change (at least) >> during the >> address lease time. > > How big a concern is that? Won't the higher-level protocols have to > deal with dead path detection anyway? Even if you have a legitimate > default route, there's no guarantee that all of your ISPs are fully > connected right now. Well it would be nice if one could avoid even trying such a route which is known to be dead, but of course through higher level protocols you can get the the information through time outs but that usually is not desirable as it introduces poor user experience. Jan From jan.melen@nomadiclab.com Thu Nov 19 22:41:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C183A6A79 for ; Thu, 19 Nov 2009 22:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdhOGgMfmPQw for ; Thu, 19 Nov 2009 22:41:01 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 5EEFF3A67A8 for ; Thu, 19 Nov 2009 22:41:01 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id AF8001EF1EA; Fri, 20 Nov 2009 08:40:58 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYw3h4tyFh3S; Fri, 20 Nov 2009 08:40:58 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 010EF1EF12E; Fri, 20 Nov 2009 08:40:57 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-17--928300229 From: Jan Melen In-Reply-To: Date: Fri, 20 Nov 2009 08:40:57 +0200 Message-Id: <639F6B1F-679D-4FB8-B9B2-075A8EE7D990@nomadiclab.com> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> <20091118093122.GN8871@cisco.com> <3c3e3fca0911181450w5c0b956fga77a219dc48d9871@mail.gmail.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1076) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 06:41:29 -0000 --Apple-Mail-17--928300229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Hi, On Nov 19, 2009, at 11:06 AM, R=E9mi Despr=E9s wrote: > > Le 18 nov. 09 =E0 23:50, William Herrin a =E9crit : > >> *AND* if D is a complex network instead of a simple router, that >> complex network needs a *dynamic routing protocol* that helps the >> routers in D do the right thing, not just static policy routing. > > In a complex D, an alternative to a dynamic routing protocol =20 > consists in a stateless address mapping, in border hosts and routers =20= > of D, with encapsulation of global packets to traverse D. > > This is feasible with the SAM approach described in draft-despres-=20 > softwire-mesh-sam-01. > A customer-side border node, when it has to forward a global packet =20= > toward the global Internet, selects the destination of the =20 > encapsulating header based on which PA prefix it finds in the source =20= > global address. This destination is the address of the provider-side =20= > border router to which this PA prefix has been delegated (known by =20 > some parameters received in DHCP ). > > If you have a look at this draft, maybe you can tell whether you =20 > agree or not on the relationship with the point you make. > Remi could you elaborate a bit more why would we need a encapsulation =20= inside D to solve the routing problem? Why don't we use existing =20 routing protocols instead to exchange the information and even do DFZ =20= routes inside D as was pointed out earlier? I don't think we want to =20 introduce something like SAM in to the end-hosts for doing this and =20 I'm not even convinced that we need for D either? Jan= --Apple-Mail-17--928300229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Le 18 nov. 09 =E0 23:50, William Herrin a =E9crit = :

*AND* if D is a = complex network instead of a simple router, = that
complex network needs a = *dynamic routing protocol* that helps the
routers in D do the right thing, not just static policy = routing.

In a complex D, an alternative to a dynamic = routing protocol consists in a stateless address mapping, in border = hosts and routers of D, with encapsulation of global packets to traverse = D.

This is feasible with the SAM approach described in = draft-despres-softwire-mesh-sam-01.
A customer-side border node, when = it has to forward a global packet toward the global Internet, selects = the destination of the encapsulating header based on which PA prefix it = finds in the source global address. This destination is the address of = the provider-side border router to which this PA prefix has been = delegated (known by some parameters received in DHCP ).

If you = have a look at this draft, maybe you can tell whether you agree or not = on the relationship with the point you make.


Remi= could you elaborate a bit more why would we need a encapsulation inside = D to solve the routing problem? Why don't we use existing routing = protocols instead to exchange the information and even do DFZ routes = inside D as was pointed out earlier? I don't think we want to introduce = something like SAM in to the end-hosts for doing this and I'm not even = convinced that we need for D = either?

     = Jan
= --Apple-Mail-17--928300229-- From remi.despres@free.fr Fri Nov 20 05:03:14 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623A228C136 for ; Fri, 20 Nov 2009 05:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umPaDSDInBHW for ; Fri, 20 Nov 2009 05:03:13 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 62B043A6A94 for ; Fri, 20 Nov 2009 05:03:11 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 40CDFE0815D; Fri, 20 Nov 2009 14:03:04 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0637DE08076; Fri, 20 Nov 2009 14:03:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <639F6B1F-679D-4FB8-B9B2-075A8EE7D990@nomadiclab.com> Date: Fri, 20 Nov 2009 14:03:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AFA4A33-4378-4F81-98EB-11079D544CC0@free.fr> References: <3c3e3fca0911091014xfc423afwd17a37480c0fa59c@mail.gmail.com> <25e1aaa40911091911j4016fd98v9878dc8dd9456950@mail.gmail.com> <3c3e3fca0911092003y54ad7141w5dc9c62f7fbb9665@mail.gmail.com> <98AAB9B6-9984-4C05-913E-2541F0C294B9@nomadiclab.com> <3c3e3fca0911100844u5e57c0b1qb8d01f9e0b0e623e@mail.gmail.com> <826A7184-DBF9-4272-BDFF-919B9A2627B6@nomadiclab.com> <3c3e3fca0911160808y3f23f3a9ve17859c5dcc7d7d8@mail.gmail.com> <20091118093122.GN8871@cisco.com> <3c3e3fca0911181450w5c0b956fga77a219dc48d9871@mail.gmail.com> <639F6B1F-679D-4FB8-B9B2-075A8EE7D990@nomadiclab.com> To: Jan Melen X-Mailer: Apple Mail (2.1077) Cc: mif@ietf.org Subject: Re: [mif] Some thoughts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:03:14 -0000 Le 20 nov. 2009 =E0 07:40, Jan Melen a =E9crit : > Hi, >=20 > On Nov 19, 2009, at 11:06 AM, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 18 nov. 09 =E0 23:50, William Herrin a =E9crit : >>=20 >>> *AND* if D is a complex network instead of a simple router, that >>> complex network needs a *dynamic routing protocol* that helps the >>> routers in D do the right thing, not just static policy routing. >>=20 >> In a complex D, an alternative to a dynamic routing protocol consists = in a stateless address mapping, in border hosts and routers of D, with = encapsulation of global packets to traverse D. >>=20 >> This is feasible with the SAM approach described in = draft-despres-softwire-mesh-sam-01. >> A customer-side border node, when it has to forward a global packet = toward the global Internet, selects the destination of the encapsulating = header based on which PA prefix it finds in the source global address. = This destination is the address of the provider-side border router to = which this PA prefix has been delegated (known by some parameters = received in DHCP ). >>=20 >> If you have a look at this draft, maybe you can tell whether you = agree or not on the relationship with the point you make. >>=20 >=20 > Remi could you elaborate a bit more why would we need a encapsulation = inside D to solve the routing problem? Thanks to encapsulation, an end-to-end packet can be routed across a = local routing domain with a forced local destination. This one can = depend on which ISP delegated to the domain the prefix matched by the = E2E source address. =20 > Why don't we use existing routing protocols instead to exchange the = information and even do DFZ routes inside D as was pointed out earlier? Note that nodes that support a dynamic routing protocol compatible with = one supported by their ISPs don't *need* SAM. It is just an alternative. In favor of SAM is its simplicity (no protocol, no AS number...). > I don't think we want to introduce something like SAM in to the = end-hosts for doing this and I'm not even convinced that we need for D = either? In multihomed sites having several CPEs, a host that supports neither a = routing protocol nor SAM cannot ensure that a packet it sends send goes = to the right ISP (that which provided the PA prefix matched by the = source address). RD =20 From denghui02@hotmail.com Tue Nov 24 04:34:19 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D8328C10A for ; Tue, 24 Nov 2009 04:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl6I9YlYMf9g for ; Tue, 24 Nov 2009 04:34:19 -0800 (PST) Received: from col0-omc2-s11.col0.hotmail.com (col0-omc2-s11.col0.hotmail.com [65.55.34.85]) by core3.amsl.com (Postfix) with ESMTP id 27FFB3A680D for ; Tue, 24 Nov 2009 04:34:19 -0800 (PST) Received: from COL118-W55 ([65.55.34.72]) by col0-omc2-s11.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 04:33:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c82f4e25-8499-492f-853e-36fa9b693987_" X-Originating-IP: [117.89.16.225] From: Hui Deng To: , Margaret Wasserman Date: Tue, 24 Nov 2009 20:33:27 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2009 12:33:26.0943 (UTC) FILETIME=[522B92F0:01CA6D02] Subject: [mif] MIF minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:34:19 -0000 --_c82f4e25-8499-492f-853e-36fa9b693987_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello, all Draft minutes about last ietf meeting, http://www.ietf.org/proceedings/09nov/minutes/mif.txt Please review and comments on it, Thanks George for taking this -Hui & Margaret _________________________________________________________________ Keep your friends updated¡ªeven when you¡¯re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 --_c82f4e25-8499-492f-853e-36fa9b693987_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hello, all
 
Draft minutes about last ietf meeting,
http://www.ietf.org/proceedings/09nov/minutes/mif.txt
Please review and comments on it,
 
Thanks George for taking this
 
-Hui & Margaret

Keep your friends updated¡ª even when you¡¯re not signed in. --_c82f4e25-8499-492f-853e-36fa9b693987_-- From denghui02@hotmail.com Tue Nov 24 07:44:56 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB953A6A8D for ; Tue, 24 Nov 2009 07:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNQ8kzycMOur for ; Tue, 24 Nov 2009 07:44:55 -0800 (PST) Received: from col0-omc2-s10.col0.hotmail.com (col0-omc2-s10.col0.hotmail.com [65.55.34.84]) by core3.amsl.com (Postfix) with ESMTP id CEC6A3A6AAA for ; Tue, 24 Nov 2009 07:44:55 -0800 (PST) Received: from COL118-W4 ([65.55.34.72]) by col0-omc2-s10.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 07:44:51 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f46fc6dc-88ef-48e0-bde7-c189dc0f09f6_" X-Originating-IP: [117.88.138.218] From: Hui Deng To: , , Gabriel Montenegro Date: Tue, 24 Nov 2009 23:44:51 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2009 15:44:51.0697 (UTC) FILETIME=[0F9DF610:01CA6D1D] Subject: [mif] Call for contributors for analysis document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:44:56 -0000 --_f46fc6dc-88ef-48e0-bde7-c189dc0f09f6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C all =20 Based on last working group meeting=2C we decide Gabriel will lead=20 the analysis document=2C and we also call for contributors from other host= vendors. so please=20 =20 _________________________________________________________________ Windows Live Hotmail: Your friends can get your Facebook updates=2C right f= rom Hotmail=AE. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so= cial-network-basics.aspx?ocid=3DPID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092= 009= --_f46fc6dc-88ef-48e0-bde7-c189dc0f09f6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C all
 =3B
Based on last working group meeting=2C we decide Gabriel will lead
the analysis document=2C and we also call for =3B contributors from oth= er host vendors.
so please

Windows Live Hotmail: Your friends can get your Facebook updates=2C right from = Hotmail=AE. = --_f46fc6dc-88ef-48e0-bde7-c189dc0f09f6_-- From denghui02@hotmail.com Tue Nov 24 07:47:18 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA883A6A8E for ; Tue, 24 Nov 2009 07:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eFSzz6JSS54 for ; Tue, 24 Nov 2009 07:47:17 -0800 (PST) Received: from col0-omc2-s15.col0.hotmail.com (col0-omc2-s15.col0.hotmail.com [65.55.34.89]) by core3.amsl.com (Postfix) with ESMTP id A2B1E3A6A85 for ; Tue, 24 Nov 2009 07:47:15 -0800 (PST) Received: from COL118-W24 ([65.55.34.72]) by col0-omc2-s15.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 07:47:11 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_4e63afff-2b0a-4f9b-a661-7a3bbe41e519_" X-Originating-IP: [117.88.138.218] From: Hui Deng To: , , Date: Tue, 24 Nov 2009 23:47:11 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2009 15:47:11.0543 (UTC) FILETIME=[62F8C470:01CA6D1D] Subject: [mif] Call for contributors for the analysis document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:47:18 -0000 --_4e63afff-2b0a-4f9b-a661-7a3bbe41e519_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Excuse me for previous wrong email, Hello, all Based on the last working group meeting, we decide that Gabriel will lead the analysis document, and we also call for contributors from other host vendors. so please write to chairs and Gabriel about your strong point on this. Many thanks -Hui & Margaret _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010 --_4e63afff-2b0a-4f9b-a661-7a3bbe41e519_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Excuse me for previous wrong email,

Hello, all
 
Based on the last working group meeting, we decide that Gabriel will lead
the analysis document, and we also call for contributors from other host vendors.
so please write to chairs and Gabriel about your strong point on this.
 
Many thanks
 
-Hui & Margaret

Windows Live: Keep your friends up to date with what you do online. --_4e63afff-2b0a-4f9b-a661-7a3bbe41e519_--