From mailman-bounces@ietf.org Tue Jun 1 07:33:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18781 for ; Tue, 1 Jun 2004 07:33:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5Wg-0003a3-T7 for nemo-archive@lists.ietf.org; Tue, 01 Jun 2004 05:25:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:04:36 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From mailman-admin@ietf.org Tue Jun 1 11:31:54 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15694 for ; Tue, 1 Jun 2004 11:31:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV93o-0007JS-V3 for nemo-archive@lists.ietf.org; Tue, 01 Jun 2004 09:12:08 -0400 Date: Tue, 01 Jun 2004 09:12:08 -0400 Message-ID: <20040601131208.26555.50462.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-bounces@ietf.org Wed Jun 2 06:19:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12550 for ; Wed, 2 Jun 2004 06:19:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVSLA-0000Jm-Vu; Wed, 02 Jun 2004 05:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVRPW-0004MB-Ob for nemo@megatron.ietf.org; Wed, 02 Jun 2004 04:47:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08450 for ; Wed, 2 Jun 2004 04:47:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVRPS-0007Er-Jr for nemo@ietf.org; Wed, 02 Jun 2004 04:47:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVROE-0006I2-00 for nemo@ietf.org; Wed, 02 Jun 2004 04:46:27 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1BVRN0-0005iT-00; Wed, 02 Jun 2004 04:45:10 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i528j8EV024482; Wed, 2 Jun 2004 01:45:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i528ihMA002286; Wed, 2 Jun 2004 03:44:58 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 65FF6863810; Wed, 2 Jun 2004 10:44:42 +0200 (CEST) Message-ID: <40BD9373.2080908@motorola.com> Date: Wed, 02 Jun 2004 10:44:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060100020409050204000906" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: nemo-admin@ietf.org Subject: [nemo] admin: discarding spam and filtering their address and banning their subscriptions X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms060100020409050204000906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, When discarding unsolicited mails addressed to the nemo list (spam), I'm going to use the new mailman features that not only discard the offensive mail but also adds the from address to the "discards" filter and that prevents that address from ever subscribing to the nemo list. I'll have to take care to look closely at the address itself (because sometimes spammers spoof someone's legitimate email address) but then please count on me. Thierry, TJ, you also manage the discarding procedure, what do you think. Alex --------------ms060100020409050204000906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA2 MDIwODQ0MzVaMCMGCSqGSIb3DQEJBDEWBBQn5xjiQnon1pubEZp4lDzwFy255zBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAW4DLJW2Gl9gWOsU3epLDoaEw9/SIuJRw2Jnvu YeMB+DMHawGQgG0qfNljpaLIk2IzLiFUlpE4lKvbOZnNquLfN+aPmiomwbv0k0HQ7wUV9sph AtpXpzNIYVeehEA6M3aTxiRpyqAN6e1sPy8pVwJRMgTzNwZ8pf2B1iyGqBEMlgAAAAAAAA== --------------ms060100020409050204000906-- From nemo-bounces@ietf.org Wed Jun 2 22:03:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10199 for ; Wed, 2 Jun 2004 22:03:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVhQE-00067O-Bk; Wed, 02 Jun 2004 21:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVb8A-00049Z-D0 for nemo@megatron.ietf.org; Wed, 02 Jun 2004 15:10:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11782 for ; Wed, 2 Jun 2004 15:10:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVb88-0005Qt-Vy for nemo@ietf.org; Wed, 02 Jun 2004 15:10:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVb7T-0004zn-00 for nemo@ietf.org; Wed, 02 Jun 2004 15:09:48 -0400 Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1BVb6R-0004YT-00; Wed, 02 Jun 2004 15:08:43 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 4295E619E; Wed, 2 Jun 2004 12:08:07 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19351-07; Wed, 2 Jun 2004 12:08:06 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 5F783619C; Wed, 2 Jun 2004 12:08:06 -0700 (PDT) Received: from [192.168.0.100] (unknown [4.22.66.34]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 4779A617A; Wed, 2 Jun 2004 12:08:05 -0700 (PDT) In-Reply-To: <40BD9373.2080908@motorola.com> References: <40BD9373.2080908@motorola.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3FE2C2B2-B4C8-11D8-93E0-000A95DA08F2@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] admin: discarding spam and filtering their address and banning their subscriptions Date: Wed, 2 Jun 2004 12:08:36 -0700 To: Alexandru Petrescu X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Is it very common to have spammers subscribe to the list? It seems that if we can run spamassassin, we can avoid the hundreds of mails that get queued and we have to manually deny. TJ On Jun 2, 2004, at 1:44 AM, Alexandru Petrescu wrote: > Hi, > > When discarding unsolicited mails addressed to the nemo list (spam), > I'm > going to use the new mailman features that not only discard the > offensive mail but also adds the from address to the "discards" filter > and that prevents that address from ever subscribing to the nemo list. > > I'll have to take care to look closely at the address itself (because > sometimes spammers spoof someone's legitimate email address) but then > please count on me. > > Thierry, TJ, you also manage the discarding procedure, what do you > think. > > Alex From nemo-bounces@ietf.org Wed Jun 2 22:08:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10467 for ; Wed, 2 Jun 2004 22:08:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVhQe-0006PT-Ps; Wed, 02 Jun 2004 21:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVbMp-0001et-Bq for nemo@megatron.ietf.org; Wed, 02 Jun 2004 15:25:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13577 for ; Wed, 2 Jun 2004 15:25:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVbMY-00043X-Sz for nemo@ietf.org; Wed, 02 Jun 2004 15:25:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVbLQ-0003el-00 for nemo@ietf.org; Wed, 02 Jun 2004 15:24:13 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BVbKa-0003G1-00; Wed, 02 Jun 2004 15:23:20 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i52JNoF5027119; Wed, 2 Jun 2004 12:23:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i52JM3Du008783; Wed, 2 Jun 2004 14:22:05 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 93370865980; Wed, 2 Jun 2004 21:23:14 +0200 (CEST) Message-ID: <40BE291C.8050001@motorola.com> Date: Wed, 02 Jun 2004 21:23:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J.Kniveton" Subject: Re: [nemo] admin: discarding spam and filtering their address and banning their subscriptions References: <40BD9373.2080908@motorola.com> <3FE2C2B2-B4C8-11D8-93E0-000A95DA08F2@kniveton.com> In-Reply-To: <3FE2C2B2-B4C8-11D8-93E0-000A95DA08F2@kniveton.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040509090307030502020707" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: nemo@ietf.org, nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms040509090307030502020707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit T.J.Kniveton wrote: > Is it very common to have spammers subscribe to the list? I guess not common, but I've seen at least one case (IIRC it was this list here, but I won't swear). > It seems that if we can run spamassassin, we can avoid the hundreds > of mails that get queued and we have to manually deny. Yes, maybe. If spamassasin must run on the same server as mailman then I guess it is on the IETF.org jurisdiction. Things I've heard is that it may overload the respective machine. Alex --------------ms040509090307030502020707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA2 MDIxOTIzMDhaMCMGCSqGSIb3DQEJBDEWBBRhLX8HaNfeeW1P7VCFY3n27BqOjjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBpZji31ENFZA42pVYakfV7xWeLwuHDJ/4tjgPA 4V8OSJTTWs7M06+1gx/qf7q6xE6vpA1jj//C5rldlgPVglZBCpnZFcu1dooNLx0O6G5Kz3Bd bG/S+Ockt59nPXyFZ6vE5JK2SWPj4REHFHi0x8PdV8LaWVUjKlpHy7o+zM+7ZwAAAAAAAA== --------------ms040509090307030502020707-- From nemo-bounces@ietf.org Sat Jun 5 16:47:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05558 for ; Sat, 5 Jun 2004 16:47:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWi2T-0000Rv-30; Sat, 05 Jun 2004 16:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWhsF-0007Mx-5k for nemo@megatron.ietf.org; Sat, 05 Jun 2004 16:34:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04974 for ; Sat, 5 Jun 2004 16:34:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWhs8-0005yF-NT for nemo@ietf.org; Sat, 05 Jun 2004 16:34:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWhrA-0005gC-00 for nemo@ietf.org; Sat, 05 Jun 2004 16:33:33 -0400 Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1BWhqq-0005OP-00 for nemo@ietf.org; Sat, 05 Jun 2004 16:33:12 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 5F9E66FEE for ; Sat, 5 Jun 2004 13:32:23 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82472-09 for ; Sat, 5 Jun 2004 13:32:22 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 5F1576FD7; Sat, 5 Jun 2004 13:32:22 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 6C4BB6FE3 for ; Sat, 5 Jun 2004 13:32:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) To: IETF NEMO WG Message-Id: <88D08ABA-B72F-11D8-9E56-000A95DA08F2@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-786197065; protocol="application/pkcs7-signature" From: "T.J.Kniveton" Date: Sat, 5 Jun 2004 13:32:59 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: -0.6 X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] draft-ietf-nemo-basic-support-03 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-1-786197065 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Thanks to Vijay and everyone who contributed towards addressing the IESG comments. Draft version 3 has been submitted and is available on the web site. http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-basic- support-03.txt --Apple-Mail-1-786197065 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDYwNTIwMzI1 OVowIwYJKoZIhvcNAQkEMRYEFOL4iA8Ej4aypotr9JG6EpSIBKmMMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgDBd3ivw9jAG18EdrEm7MixE7eCZ2s1i3AUBQdnqFl2R LACYDC/gr589v8n0pfoZCvPspBEg3bUJCx7fKkNt5WRkbU5DTDjWIz//fgLxs36tw7UsxHJMIGma h0BNJJiyrVJ42TJhG/Qvx20BtiE3ygJLGa5b37xDk6J9ngrLtVc1AAAAAAAA --Apple-Mail-1-786197065-- From nemo-bounces@ietf.org Mon Jun 7 16:44:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17296 for ; Mon, 7 Jun 2004 16:44:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXQCP-0005u5-7E; Mon, 07 Jun 2004 15:54:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXQ1s-0003Tf-MF; Mon, 07 Jun 2004 15:43:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11213; Mon, 7 Jun 2004 15:43:30 -0400 (EDT) Message-Id: <200406071943.PAA11213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 07 Jun 2004 15:43:30 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility (NEMO) Basic Support Protocol Author(s) : V. Devarapalli, et al. Filename : draft-ietf-nemo-basic-support-03.txt Pages : 39 Date : 2004-6-7 This document describes the Network Mobility (NEMO) Basic Support protocol that enables mobile networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-basic-support-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-basic-support-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-7154514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154514.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Mon Jun 14 12:11:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12237 for ; Mon, 14 Jun 2004 12:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZtnk-0007qL-4y; Mon, 14 Jun 2004 11:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZtho-0006c7-7W for nemo@megatron.ietf.org; Mon, 14 Jun 2004 11:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10945 for ; Mon, 14 Jun 2004 11:49:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZthn-0007Zg-Em for nemo@ietf.org; Mon, 14 Jun 2004 11:49:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZtgo-0007HX-00 for nemo@ietf.org; Mon, 14 Jun 2004 11:48:03 -0400 Received: from bay1-f77.bay1.hotmail.com ([65.54.245.77] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BZtfn-0006kL-00 for nemo@ietf.org; Mon, 14 Jun 2004 11:46:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jun 2004 08:46:29 -0700 Received: from 203.227.205.177 by by1fd.bay1.hotmail.msn.com with HTTP; Mon, 14 Jun 2004 15:46:22 GMT X-Originating-IP: [203.227.205.177] X-Originating-Email: [saintnemocraft@hotmail.com] X-Sender: saintnemocraft@hotmail.com From: "jhon saint" To: nemo@ietf.org Date: Mon, 14 Jun 2004 15:46:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2004 15:46:29.0136 (UTC) FILETIME=[C2113900:01C45226] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA10945 Subject: [nemo] RIPng with NEMO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | +----+ | GW | +----+ | | 3ffe:10::/64 | --+-+---------------+- | | 3ffe:10::95/64 | | (3ffe:10::96/64, fe80::aaa:bbbb) fe80::ccc:ddd +----+ +----+=20 | HA | | MR | +----+ +----+ | | 3ffe:11::/64 ---+---- =20 We are implementing a mobile router with MIPL as a homework(?). Our MR acts only in explicit mode. When MR is at home, MR runs a routing protocol(ripng).. so, routing tables in this network is : (only for mobile network) +----------+----------------+----------------+--------------- | | dest | gw | dev ...=20 +----------+----------------+----------------+------------------ | HomeAgent| 3ffe:11::/64 | fe80::aaa:bbbb | ethx.... +----------+----------------+----------------+------------------ | Gateway | 3ffe:11::/64 | fe80::aaa:bbbb | ethx... +----------+----------------+----------------+------------------ now MR moves out from its home link, and sends bu for home registration=20 with prefix option (3ffe:11::/64) to HA. (and stops running routing protocol on its egress interface) Then, HA receives the bu message and sets up forwarding to MR's network with tunnel.. and advertise its routing information to=20 infrastructure(Gateway..:p).. at this point, routing tables in this network is : +----------+----------------+----------------+------------ | | dest | gw | dev ...=20 +----------+----------------+----------------+---------------- | HomeAgent| 3ffe:11::/64 | *3ffe:10::96* | *Tunnel* +----------+----------------+----------------+---------------- | Gateway | 3ffe:11::/64 | fe80::aaa:bbbb | ethx... +----------+----------------+----------------+-------------- We expected that if HA advertises its routing table (about mobile network= ), GW updates its route to the mobile network.. So, this was our expectation... -_- +----------+----------------+----------------+------------ | | dest | gw | dev ...=20 +----------+----------------+----------------+---------------- | HomeAgent| 3ffe:11::/64 | 3ffe:10::96 | Tunnel dev +----------+----------------+----------------+---------------- | Gateway | 3ffe:11::/64 |*fe80::ccc:dddb*| ethx... +----------+----------------+----------------+-------------- Sending ping from HA to MR's mobile network(3ffe:11::/64) works well. but, GW can't... We found GW didn't update its routing entry for the mobile network until the entry is expired... (after the entry expired and deleted, GW=20 finally update a path to the mobile network with ripng message from HA and GW can ping to=20 monet) In RFC2080 (RIPng for IPv6), [page 13] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D " If there is an existing route, compare the next hop address to the address of the router from which the datagram came. If this datagram is from the same router as the existing route, reinitialize the timeout. Next, compare the metrics. If the datagram is from the same router as the existing route, and the new metric is different than the old one; or, if the new metric is lower than the old one; do the following actions: ..... ... " Because of this, when GW receives new route info from HA about monet, GW ignores it.=20 So... we modified ripngd source code.. (we're using Zebra ripngd 0.94) ripngd.c / void ripng_route_process(...) / line 623 original code.. same =3D (IN6_ARE_ADDR_EQUAL (&rinfo->from, &from->sin6_addr) && (rinfo->ifindex =3D=3D ifp->ifindex)); -- =20 modified code.. same =3D (IN6_ARE_ADDR_EQUAL (&rinfo->from, &from->sin6_addr) || (rinfo->ifindex =3D=3D ifp->ifindex)); -- So, my question is.. (sorry.. too too long...) Our modification to ripng is necessary for NEMO support ? or, is there =20 any solution for this problem? =20 or.. our solution is totally in a wrong way? please~ help us~ Thanks..~~ _________________________________________________________________ =C3=A5=BB=F3=C0=A7=BF=A1 =B4=D9=B8=AE =BF=C3=B8=AE=B0=ED =B4=C0=B1=DF=C7=CF= =B0=D4 =C1=F1=B1=E4=B4=D9... MSN =BF=C2=B6=F3=C0=CE =BB=F3=BF=B5=B0=FC =20 http://vod.msn.co.kr =20 From nemo-bounces@ietf.org Mon Jun 14 18:38:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08838 for ; Mon, 14 Jun 2004 18:38:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZz9o-0000on-KY; Mon, 14 Jun 2004 17:38:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZxJp-0003TR-Ly for nemo@megatron.ietf.org; Mon, 14 Jun 2004 15:40:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24091 for ; Mon, 14 Jun 2004 15:40:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZxJo-0007VA-J3 for nemo@ietf.org; Mon, 14 Jun 2004 15:40:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZxIs-0007Cp-00 for nemo@ietf.org; Mon, 14 Jun 2004 15:39:34 -0400 Received: from bay1-f87.bay1.hotmail.com ([65.54.245.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BZxIN-0006tM-00 for nemo@ietf.org; Mon, 14 Jun 2004 15:39:03 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jun 2004 12:38:34 -0700 Received: from 203.227.205.181 by by1fd.bay1.hotmail.msn.com with HTTP; Mon, 14 Jun 2004 19:38:34 GMT X-Originating-IP: [203.227.205.181] X-Originating-Email: [saintnemocraft@hotmail.com] X-Sender: saintnemocraft@hotmail.com From: "jhon saint" To: nemo@ietf.org Date: Mon, 14 Jun 2004 19:38:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2004 19:38:34.0883 (UTC) FILETIME=[2E759530:01C45247] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA24091 Subject: [nemo] RIPng with NEMO again.. X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | +----+ | GW | +----+ | | 3ffe:10::/64 | --+-+---------------+- | | 3ffe:10::95/64 | | (3ffe:10::96/64, fe80::aaa:bbbb) fe80::ccc:ddd +----+ +----+=20 | HA | | MR | +----+ +----+ | | 3ffe:11::/64 ---+---- =20 We are implementing a mobile router with MIPL as a homework(?). Our MR acts only in explicit mode. When MR is at home, MR runs a routing protocol(ripng).. so, routing tables in this network is : (only for mobile network) +----------+----------------+----------------+--------------- | | dest | gw | dev ... +----------+----------------+----------------+------------------ | HomeAgent| 3ffe:11::/64 | fe80::aaa:bbbb | ethx.... +----------+----------------+----------------+------------------ | Gateway | 3ffe:11::/64 | fe80::aaa:bbbb | ethx... +----------+----------------+----------------+------------------ now MR moves out from its home link, and sends bu for home registration=20 with prefix option (3ffe:11::/64) to HA. (and stops running routing protocol on its egress interface) Then, HA receives the bu message and sets up forwarding to MR's network with tunnel.. and advertise its routing information to=20 infrastructure(Gateway..:p).. at this point, routing tables in this network is : +----------+----------------+----------------+------------ | | dest | gw | dev ... +----------+----------------+----------------+---------------- | HomeAgent| 3ffe:11::/64 | *3ffe:10::96* | *Tunnel* +----------+----------------+----------------+---------------- | Gateway | 3ffe:11::/64 | fe80::aaa:bbbb | ethx... +----------+----------------+----------------+-------------- We expected that if HA advertises its routing table (about mobile network= ), GW updates its route to the mobile network.. So, this was our expectation... -_- +----------+----------------+----------------+------------ | | dest | gw | dev ... +----------+----------------+----------------+---------------- | HomeAgent| 3ffe:11::/64 | 3ffe:10::96 | Tunnel dev +----------+----------------+----------------+---------------- | Gateway | 3ffe:11::/64 |*fe80::ccc:dddb*| ethx... +----------+----------------+----------------+-------------- Sending ping from HA to MR's mobile network(3ffe:11::/64) works well. but, GW can't... We found GW didn't update its routing entry for the mobile network until the entry is expired... (after the entry expired and deleted, GW=20 finally update a path to the mobile network with ripng message from HA and GW can ping to=20 monet) In RFC2080 (RIPng for IPv6), [page 13] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D " If there is an existing route, compare the next hop address to the address of the router from which the datagram came. If this datagram is from the same router as the existing route, reinitialize the timeout. Next, compare the metrics. If the datagram is from the same router as the existing route, and the new metric is different than the old one; or, if the new metric is lower than the old one; do the following actions: ..... ... " Because of this, when GW receives new route info from HA about monet, GW ignores it.=20 So... we modified ripngd source code.. (we're using Zebra ripngd 0.94) ripngd.c / void ripng_route_process(...) / line 623 original code.. same =3D (IN6_ARE_ADDR_EQUAL (&rinfo->from, &from->sin6_addr) && (rinfo->ifindex =3D=3D ifp->ifindex)); -- =20 modified code.. same =3D (IN6_ARE_ADDR_EQUAL (&rinfo->from, &from->sin6_addr) || (rinfo->ifindex =3D=3D ifp->ifindex)); -- So, my question is.. (sorry.. too too long...) Our modification to ripng is necessary for NEMO support ? or, is there =20 any solution for this problem? =20 or.. our solution is totally in a wrong way? please~ help us~ Thanks..~~ _________________________________________________________________ =BA=B8=B4=D9 =BA=FC=B8=A3=B0=ED =BA=B8=B1=E2 =C6=ED=C7=D1 =B4=BA=BD=BA. =BF= =C0=B4=C3=C0=C7 =C8=AD=C1=A6=B4=C2 MSN =B4=BA=BD=BA=BF=A1=BC=AD =C8=AE=C0= =CE=C7=CF=BC=BC=BF=E4. =20 http://www.msn.co.kr/news/ =20 From nemo-bounces@ietf.org Mon Jun 14 22:31:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22800 for ; Mon, 14 Jun 2004 22:31:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba3CS-0007Kr-W6; Mon, 14 Jun 2004 21:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba2OK-00016k-6l for nemo@megatron.ietf.org; Mon, 14 Jun 2004 21:05:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17863 for ; Mon, 14 Jun 2004 21:05:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba2OI-0002o0-9w for nemo@ietf.org; Mon, 14 Jun 2004 21:05:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba2NM-0002WV-00 for nemo@ietf.org; Mon, 14 Jun 2004 21:04:33 -0400 Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1Ba2Mm-0002F7-00 for nemo@ietf.org; Mon, 14 Jun 2004 21:03:57 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id CF76961D7; Mon, 14 Jun 2004 18:03:41 -0700 (PDT) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13321-08; Mon, 14 Jun 2004 18:03:40 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id CC8C761CA; Mon, 14 Jun 2004 18:03:40 -0700 (PDT) Received: from [192.103.17.194] (unknown [192.103.17.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id C453661AE; Mon, 14 Jun 2004 18:03:39 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--567438978; protocol="application/pkcs7-signature" Message-Id: From: "T.J.Kniveton" Subject: Re: [nemo] RIPng with NEMO again.. Date: Mon, 14 Jun 2004 18:03:46 -0700 To: "jhon saint" X-Mailer: Apple Mail (2.618) X-Spam-Score: -1.0 X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-2--567438978 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thank you for bringing this up. We are happy to see that you are implementing NEMO and gaining operational experience between NEMO and a routing protocol. This is very good. Now to your question: There are processing rules under section 2.4.2 of RFC 2080. However, some of the rules are confusing and imply certain tests. Let's look at the section on processing updates where a route already exists: > If there is an existing route, compare the next hop address to the > address of the router from which the datagram came. If this > datagram > is from the same router as the existing route, reinitialize the > timeout. Next, compare the metrics. If the datagram is from the > same router as the existing route, and the new metric is different > than the old one; or, if the new metric is lower than the old one; > do > the following actions: > > - Adopt the route from the datagram. That is, put the new metric > in, > and adjust the next hop address (if necessary). > > - Set the route change flag and signal the output process to trigger > an update. > > - If the new metric is infinity, start the deletion process > (described above); otherwise, re-initialize the timeout. > > If the new metric is infinity, the deletion process begins for the > route, which is no longer used for routing packets. Note that the > deletion process is started only when the metric is first set to > infinity. If the metric was already infinity, then a new deletion > process is not started. > Notice that in the first paragraph, each sentence/rule explicitly tests whether the datagram is from the same router as the existing route. However, the last paragraph does NOT make this test. By that logic, ANY router on the link can remove any route by setting its metric to infinity. This does not have to be malicious; any route set to infinity on one router will kill other routers' entries if processed this way. If we assume that the rule for deletion does include an implied rule that the deletion comes from the same router as the existing route, then we have a problem. If the MR is on the same link as the HA and all the other routers, it will send a RIPng solicited response or regular update. This will contain the mobile network prefix (MNP) and a metric of 1. The receiving router will add the network cost (1), so it will put an entry in its routing table: MNP MR's HoA 2 This is fine. But now the MR goes away. What *should* happen is that the route should be deleted. It will be deleted if it times out, but otherwise we have to explicitly delete it. If we read RFC 2080 literally, the HA could delete the entry by proxy, simply by putting a metric of 16 in its triggered update, and then send another one, with its own metric (2), which would go into the receiver as metric 3. The entries would be: MNP MR's HoA 16 and then MNP HA 3 However, implementations might process this differently depending on whether they make this (dangerous) assumption. For instance, there could be a router just starting up that has a route with infinity because it does not yet know the correct route. If it advertises it on the link, it would cause the route entry for that prefix to be deleted on all other routers. If we assume that the rule requires the advertisement to come from the router already in the routing entry, then we can not explicitly delete it (except in the corner case where the MR knows it's going away, before it leaves the link). This is because the triggered update must come from the MR itself, who has already left the link. Options: I'll present a few possible ways to handle this. 1. MR-raised metric Under this scenario, the MR could advertise an artificially high metric, so that when it leaves the link, the HA's normal metric will capture the entry. For instance, the MR could advertise metric 2, or metric 5, for the MNP. When it leaves, the HA will receive a BU from the MR and send a triggered update with its own address as next hop, and metric 1 (received as 2). 2. MR lives on a link behind the HA To me, this makes the most sense. There was a lot of negative comments on this, and maybe I'll address those in another note. But here's the crux of it: The MR (and MNs) are ALWAYS served by their HA. Even when they're on the home network, the HA should be their default router. This can occur via a physical separate access link for MN/MRs, or it can occur by putting a routing entry in the HA and having the MRs on the same link. The MR never needs to send any RIPng messages; its mobility is handled by the HA, even in the RIP domain, as it should be. 3. Fix RFC This would comprise 2 subparts: a. Update the text we discussed above, to make it clear and deterministic. b. Include a way to explicitly remove routes, other than by timeout, given that the router in the existing route entry has either crashed, powered down, or otherwise moved off link. (Given that all neighbor routers are trusted equally, there should be no problem for one router to remove another's route entry if it knows the router is no longer reachable). TJ --Apple-Mail-2--567438978 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDYxNTAxMDM0 N1owIwYJKoZIhvcNAQkEMRYEFJw0QNFg7nLA7PTrxwEL7ZHzZ3MOMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgKqtqhZyd/Xh1gWqroSIJcD+h82Gnh1WY4ZE5Q1sRhQ0 1++QcvDtvtQyXTXLRj7aQrnspc+mXEXatHO2Mr/ta1x7JHsdwk+Kl36vfJNj+XYBkvmtidQjP6Fn mxE6PqE+vZ1Ioy627ZK9t7uYi+bU6f9KvmScjstVuKzsyhBGc7bHAAAAAAAA --Apple-Mail-2--567438978-- From nemo-bounces@ietf.org Tue Jun 15 03:19:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28436 for ; Tue, 15 Jun 2004 03:19:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba8B9-0006b7-Qy; Tue, 15 Jun 2004 03:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba86h-0005TF-F6 for nemo@megatron.ietf.org; Tue, 15 Jun 2004 03:11:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27994 for ; Tue, 15 Jun 2004 03:11:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba86f-000199-6f for nemo@ietf.org; Tue, 15 Jun 2004 03:11:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba85e-0000lF-00 for nemo@ietf.org; Tue, 15 Jun 2004 03:10:39 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Ba84a-00008Y-00 for nemo@ietf.org; Tue, 15 Jun 2004 03:09:32 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZC009DD971IM@mailout2.samsung.com> for nemo@ietf.org; Tue, 15 Jun 2004 16:09:01 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZC009J4950AR@mailout2.samsung.com> for nemo@ietf.org; Tue, 15 Jun 2004 16:07:48 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZC008DN94VCZ@mmp2.samsung.com> for nemo@ietf.org; Tue, 15 Jun 2004 16:07:48 +0900 (KST) Date: Tue, 15 Jun 2004 12:39:51 +0530 From: "O.L.N.Rao" To: NEMO Message-id: <007b01c452a7$c3088cb0$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_YBKqcv/csjbgBKSvAKLHTw)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] Conflicting statements - RAs on e-gress interfaces X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_YBKqcv/csjbgBKSvAKLHTw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hello All, I am just cut-pasting the snips from the NEMO Basic Support Protocol (Draft Version 3) which are conflicting. [SNIP 1] 5.6. Neighbor Discovery for Mobile Router When the Mobile Router is at home, it MAY be configured to send Router Advertisements and reply to Router Solicitations on the interface attached to the home link. The value of the Router *Lifetime field MUST be set to zero* to prevent other nodes from configuring the Mobile Router as the default router. [SNIP 2] 5.8. Returning Home - The Mobile Router MAY send router advertisements on its egress interfaces. But the router *lifetime SHOULD be set to 0*, so that hosts on the home link do not pick the Mobile Router as the default router. I guess following the lines of 5.6 would be better choice. Let me know if i am missing any thing. Thank you, Regards, O.L.N. Rao --Boundary_(ID_YBKqcv/csjbgBKSvAKLHTw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hello All,
 
    I am just cut-pasting the snips from the NEMO Basic Support Protocol (Draft Version 3)
    which are conflicting.
 
    [SNIP 1]
 
    5.6. Neighbor Discovery for Mobile Router
 
    When the Mobile Router is at home, it MAY be configured to send
   Router Advertisements and reply to Router Solicitations on the
   interface attached to the home link.  The value of the Router
   *Lifetime field MUST be set to zero* to prevent other nodes from
   configuring the Mobile Router as the default router.
 
    [SNIP 2]
 
    5.8. Returning Home
 
    -  The Mobile Router MAY send router advertisements on its egress
       interfaces.  But the router *lifetime SHOULD be set to 0*, so that
       hosts on the home link do not pick the Mobile Router as the
       default router.
 
    I guess following the lines of 5.6 would be better choice.
 
    Let me know if i am missing any thing.
 
    Thank you,
 
Regards,
O.L.N. Rao
 
--Boundary_(ID_YBKqcv/csjbgBKSvAKLHTw)-- From nemo-bounces@ietf.org Tue Jun 15 03:42:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29357 for ; Tue, 15 Jun 2004 03:42:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba8WE-0001be-24; Tue, 15 Jun 2004 03:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba8MQ-00085N-Pk for nemo@megatron.ietf.org; Tue, 15 Jun 2004 03:27:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28662 for ; Tue, 15 Jun 2004 03:27:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba8MO-00067c-Cz for nemo@ietf.org; Tue, 15 Jun 2004 03:27:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba8LQ-0005oT-00 for nemo@ietf.org; Tue, 15 Jun 2004 03:26:57 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba8Kq-0005V2-00 for nemo@ietf.org; Tue, 15 Jun 2004 03:26:20 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jun 2004 03:25:40 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Conflicting statements - RAs on e-gress interfaces Date: Tue, 15 Jun 2004 03:25:40 -0400 Message-ID: Thread-Topic: [nemo] Conflicting statements - RAs on e-gress interfaces Thread-Index: AcRSqTU6aQm+Yl76Q9OU+UEeP5GhpwAATYcg From: "Soliman Hesham" To: "O.L.N.Rao" , "NEMO" X-OriginalArrivalTime: 15 Jun 2004 07:25:40.0952 (UTC) FILETIME=[F65DF580:01C452A9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I think 5.8 is actually a better choice.=20 MUST should not be used lightly as it means if you don't follow this recommendation something will=20 break. Nothing will break if a node uses the MR as a=20 default router. Of course if the MR moves then that node will discover that and switch routers. This is not desired as it takes time, but nothing breaks. In fact, in some cases it might be useful to use the MR as a default router, e.g. if no other routers exist.=20 So I don't think we should use MUST here. SHOULD or=20 even MAY are more appropriate IMO. Hesham -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On Behalf Of O.L.N.Rao Sent: Tuesday, June 15, 2004 3:10 AM To: NEMO Subject: [nemo] Conflicting statements - RAs on e-gress interfaces Hello All, I am just cut-pasting the snips from the NEMO Basic Support Protocol (Draft Version 3) which are conflicting. [SNIP 1] 5.6. Neighbor Discovery for Mobile Router When the Mobile Router is at home, it MAY be configured to send Router Advertisements and reply to Router Solicitations on the interface attached to the home link. The value of the Router *Lifetime field MUST be set to zero* to prevent other nodes from configuring the Mobile Router as the default router. [SNIP 2] 5.8. Returning Home - The Mobile Router MAY send router advertisements on its egress interfaces. But the router *lifetime SHOULD be set to 0*, so = that hosts on the home link do not pick the Mobile Router as the default router. I guess following the lines of 5.6 would be better choice. Let me know if i am missing any thing. Thank you, Regards, O.L.N. Rao =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Jun 15 04:41:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02581 for ; Tue, 15 Jun 2004 04:41:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba9Qp-0003wW-GJ; Tue, 15 Jun 2004 04:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba9IU-0002Z3-Tc for nemo@megatron.ietf.org; Tue, 15 Jun 2004 04:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02085 for ; Tue, 15 Jun 2004 04:27:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba9IS-0002WI-Io for nemo@ietf.org; Tue, 15 Jun 2004 04:27:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba9HL-0002C2-00 for nemo@ietf.org; Tue, 15 Jun 2004 04:26:48 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Ba9GY-0001ZM-00 for nemo@ietf.org; Tue, 15 Jun 2004 04:25:58 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2004 10:38:09 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5F8Owfj028290; Tue, 15 Jun 2004 10:25:26 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Jun 2004 09:26:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2004 09:26:15 +0100 Message-ID: Thread-Topic: Question about RO taxonomy(2nd mail) Thread-Index: AcRSd7nMYYmT3wYiQ8y3rfwshCE7sgANQxvA From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 15 Jun 2004 08:26:15.0835 (UTC) FILETIME=[6CED16B0:01C452B2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: Question about RO taxonomy(2nd mail) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 > I have a question about RO taxonomy. > In particular, I consider "nested mobile network" case. >=20 > In your draft, you only consider a DSR or an AODV as a internal routing > protocol. > That point is my question. > Why don't you consider MANET protocol of proactive method? >=20 > In general, reactive method has better performance when the node has high > mobility. > However, if there is a mobile network including nested mobile network like a > your example, > each mobile network may has low mobility. >=20 > Is there any special reason on that? You're right: The assumption was that the nodes were highly mobile regarding each other. Depending on the degree and the type of mobility, various MANET approaches apply. If they are moving together as a 'solid', a classical proactive solution does the trick.=20 You can use OSPF at home, make the MRHA tunnel a not so stubby area and make the MR an ASBR... In that case you can run the protocol you want in the solid cloud and exchange the routes with the HA. I'm not sure we have a use case for such a deployment, though. Maybe we can modify the text to make it more open (and vague actually :) Do you feel it's needed?=20 Pascal From nemo-bounces@ietf.org Tue Jun 15 14:27:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06721 for ; Tue, 15 Jun 2004 14:27:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaIb9-0000pP-Fg; Tue, 15 Jun 2004 14:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaITi-0008CU-RX for nemo@megatron.ietf.org; Tue, 15 Jun 2004 14:16:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06167 for ; Tue, 15 Jun 2004 14:16:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaITh-0004e2-Lq for nemo@ietf.org; Tue, 15 Jun 2004 14:16:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaISi-0004Ip-00 for nemo@ietf.org; Tue, 15 Jun 2004 14:15:09 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BaIRm-0003do-00 for nemo@ietf.org; Tue, 15 Jun 2004 14:14:10 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5FIDYt07069; Tue, 15 Jun 2004 11:13:34 -0700 X-mProtect: <200406151813> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14178.americas.nokia.com (172.18.141.78, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7zajas; Tue, 15 Jun 2004 11:13:33 PDT Message-ID: <40CF3C43.6080208@iprg.nokia.com> Date: Tue, 15 Jun 2004 11:13:23 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "O.L.N.Rao" Subject: Re: [nemo] Conflicting statements - RAs on e-gress interfaces References: <007b01c452a7$c3088cb0$7a476c6b@sisodomain.com> In-Reply-To: <007b01c452a7$c3088cb0$7a476c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: NEMO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit thanks for catching this. as Hesham mentioned SHOULD is probably better. Vijay O.L.N.Rao wrote: > Hello All, > > I am just cut-pasting the snips from the NEMO Basic Support Protocol > (Draft Version 3) > which are conflicting. > > [SNIP 1] > > 5.6. Neighbor Discovery for Mobile Router > > When the Mobile Router is at home, it MAY be configured to send > Router Advertisements and reply to Router Solicitations on the > interface attached to the home link. The value of the Router > *Lifetime field MUST be set to zero* to prevent other nodes from > configuring the Mobile Router as the default router. > > [SNIP 2] > > 5.8. Returning Home > > - The Mobile Router MAY send router advertisements on its egress > interfaces. But the router *lifetime SHOULD be set to 0*, so that > hosts on the home link do not pick the Mobile Router as the > default router. > > I guess following the lines of 5.6 would be better choice. > > Let me know if i am missing any thing. > > Thank you, > > Regards, > O.L.N. Rao > From nemo-bounces@ietf.org Wed Jun 16 11:31:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09500 for ; Wed, 16 Jun 2004 11:31:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bac9F-0008GM-2Q; Wed, 16 Jun 2004 11:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bac1G-0004e6-BA for nemo@megatron.ietf.org; Wed, 16 Jun 2004 11:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03794 for ; Wed, 16 Jun 2004 11:08:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bac1C-0006JF-PL for nemo@ietf.org; Wed, 16 Jun 2004 11:08:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BabBX-00063t-00 for nemo@ietf.org; Wed, 16 Jun 2004 10:14:41 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BaadC-0000uq-00 for nemo@ietf.org; Wed, 16 Jun 2004 09:39:10 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2004 15:51:45 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5GDc0fp012501; Wed, 16 Jun 2004 15:38:39 +0200 (MEST) Received: from xbe-lon-302.cisco.com ([64.103.98.21]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Jun 2004 15:34:28 +0200 Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Jun 2004 14:39:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: Question about RO taxonomy Date: Wed, 16 Jun 2004 14:39:09 +0100 Message-ID: Thread-Topic: [nemo] RE: Question about RO taxonomy Thread-Index: AcRTRGaXQi98HrkoThuMR/EpkSaHsgAQDRmg From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 16 Jun 2004 13:39:10.0373 (UTC) FILETIME=[4DD5FD50:01C453A7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jung-Hoon Cheon [mailto:jh.ch@samsung.com] > Sent: mercredi 16 juin 2004 03:48 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: RE: [nemo] RE: Question about RO taxonomy >=20 >=20 > >> I have a question about RO taxonomy. > >> In particular, I consider "nested mobile network" case. > >> > >> In your draft, you only consider a DSR or an AODV as a internal > >> routing protocol. > >> That point is my question. > >> Why don't you consider MANET protocol of proactive method? > >> > >> In general, reactive method has better performance when the node has > >> high mobility. > >> However, if there is a mobile network including nested mobile network > >> like a your example, > >> each mobile network may has low mobility. > >> > >> Is there any special reason on that? >=20 > > You're right: >=20 > > The assumption was that the nodes were highly mobile regarding each > > other. Depending on the degree and the type of mobility, various MANET > > approaches apply. If they are moving together as a 'solid', a classical > > proactive solution does the trick. >=20 > > You can use OSPF at home, make the MRHA tunnel a not so stubby area and > > make the MR an ASBR... In that case you can run the protocol you want in > > the solid cloud and exchange the routes with the HA. I'm not sure we > > have a use case for such a deployment, though. >=20 > Most vehicles are moving along route(on the road or in the air). > a mobile network with nested mobile networks seems a solid cloud. >=20 > Consider several buses with high school students are moving on the road. I wonder why you only consider high school students for that ;)=20 > Each bus is a mobile network separately. > When a student in a BUS 1 who want to communicate with other student > in a BUS 2, each mobile router can imagine that they located in same mobile > network. >=20 > At that time, to get information for rechability, > proactive solution is easier than reactive approches. > Of course, proactive solutions may load heavy work on mobile routers. >=20 > > Maybe we can modify the text to make it more open (and vague actually :) > > Do you feel it's needed? >=20 > IMHO we apply MANET protocol as a internal routing protocol case by case. > I wonder why did you only consider reactive solutions for that. Note that the word 'reactive' is never used. DSR and AODV are listed because both protocols are already extended to connect to the infrastructure via a gateway, which is the subject of the chapter, and not because they are reactive. DSR had the gateway for a long long time, and, if I'm right, Ryuji is an author of the draft that extends AODV in the same fashion. So both are listed as example, but are not intended as a restriction in any fashion :) In your example of a convoy, the (proactive) OSPF evolution that is being debated at the MANET WG seems to apply perfectly. You can make each bus an area, and the inter bus radio can be an area 0. Students do not have to be 'mobile', and the convoy is moving as a 'solid'. NEtwork MObility comes into play when you want that structure to communicate with the rest of the world. Does each bus manage its own MR, or does one take over for the whole group. In the first case, we are trivially back to basic. The second case - when one bus takes over the whole convoy- is an example of surrogate.=20 MANET is considered in the taxonomy for the Internal Routing and gateway model. If the gateway is MIP enabled then it's akin to the surrogate model. Otherwise the gateway needs to inject the routes in the infrastructure, or NAT the addresses within the mobile network. We have studied this in the lab and for our own use cases -we expected a bit less 'solidity' then your convoy-, a LORA proactive MANET seemed optimum inside the mobile cloud. Then it appeared that DHCP + NEMO was a cool approach to make the TLMR a surrogate gateway (a NEMO version of HMIP) and we drafted that.=20 What do you think? Pascal From nemo-bounces@ietf.org Wed Jun 16 16:30:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14285 for ; Wed, 16 Jun 2004 16:30:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bagtw-0003gh-Vc; Wed, 16 Jun 2004 16:20:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaURQ-0001ok-Ic for nemo@megatron.ietf.org; Wed, 16 Jun 2004 03:02:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13960 for ; Wed, 16 Jun 2004 03:02:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaURL-0006rH-QC for nemo@ietf.org; Wed, 16 Jun 2004 03:02:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaT5d-00007Y-00 for nemo@ietf.org; Wed, 16 Jun 2004 01:36:02 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BaPYQ-0004gx-00 for nemo@ietf.org; Tue, 15 Jun 2004 21:49:30 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZD00H0ZP0PJO@mailout1.samsung.com> for nemo@ietf.org; Wed, 16 Jun 2004 10:48:25 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZD00BGRP0JQ0@mailout1.samsung.com> for nemo@ietf.org; Wed, 16 Jun 2004 10:48:19 +0900 (KST) Received: from JunghoonCheon ([75.2.47.49]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZD00IIGP0IIZ@mmp1.samsung.com> for nemo@ietf.org; Wed, 16 Jun 2004 10:48:19 +0900 (KST) Date: Wed, 16 Jun 2004 10:48:19 +0900 From: Jung-Hoon Cheon Subject: RE: [nemo] RE: Question about RO taxonomy In-reply-to: To: "'Pascal Thubert (pthubert)'" Message-id: <011601c45343$fff55940$312f024b@JunghoonCheon> Organization: Samsung AIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 16 Jun 2004 16:12:42 -0400 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jh.ch@samsung.com List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7BIT >> I have a question about RO taxonomy. >> In particular, I consider "nested mobile network" case. >> >> In your draft, you only consider a DSR or an AODV as a internal >> routing protocol. >> That point is my question. >> Why don't you consider MANET protocol of proactive method? >> >> In general, reactive method has better performance when the node has >> high mobility. >> However, if there is a mobile network including nested mobile network >> like a your example, >> each mobile network may has low mobility. >> >> Is there any special reason on that? > You're right: > The assumption was that the nodes were highly mobile regarding each > other. Depending on the degree and the type of mobility, various MANET > approaches apply. If they are moving together as a 'solid', a classical > proactive solution does the trick. > You can use OSPF at home, make the MRHA tunnel a not so stubby area and > make the MR an ASBR... In that case you can run the protocol you want in > the solid cloud and exchange the routes with the HA. I'm not sure we > have a use case for such a deployment, though. Most vehicles are moving along route(on the road or in the air). a mobile network with nested mobile networks seems a solid cloud. Consider several buses with high school students are moving on the road. Each bus is a mobile network separately. When a student in a BUS 1 who want to communicate with other student in a BUS 2, each mobile router can imagine that they located in same mobile network. At that time, to get information for rechability, proactive solution is easier than reactive approches. Of course, proactive solutions may load heavy work on mobile routers. > Maybe we can modify the text to make it more open (and vague actually :) > Do you feel it's needed? IMHO we apply MANET protocol as a internal routing protocol case by case. I wonder why did you only consider reactive solutions for that. > Pascal Jung-Hoon From nemo-bounces@ietf.org Wed Jun 16 16:31:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14345 for ; Wed, 16 Jun 2004 16:31:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bagtx-0003hY-Fp; Wed, 16 Jun 2004 16:20:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacEw-0002gI-SX for nemo@megatron.ietf.org; Wed, 16 Jun 2004 11:22:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07253 for ; Wed, 16 Jun 2004 11:22:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacEs-0000pr-Hk for nemo@ietf.org; Wed, 16 Jun 2004 11:22:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BabSj-0000v4-00 for nemo@ietf.org; Wed, 16 Jun 2004 10:32:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaagC-0001Xl-00 for nemo@ietf.org; Wed, 16 Jun 2004 09:42:16 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaaMQ-0001LL-P8 for nemo@ietf.org; Wed, 16 Jun 2004 09:21:51 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZE00G8BAK5NG@mailout2.samsung.com> for nemo@ietf.org; Wed, 16 Jun 2004 18:33:41 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZE008QLAJ02K@mailout2.samsung.com> for nemo@ietf.org; Wed, 16 Jun 2004 18:33:01 +0900 (KST) Received: from JunghoonCheon ([75.2.47.49]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZE00521AJ0ZK@mmp2.samsung.com> for nemo@ietf.org; Wed, 16 Jun 2004 18:33:00 +0900 (KST) Date: Wed, 16 Jun 2004 18:33:01 +0900 From: Jung-Hoon Cheon Subject: RE: [nemo] RE: Question about RO taxonomy again To: "'Pascal Thubert (pthubert)'" Message-id: <019c01c45384$eadf7cc0$312f024b@JunghoonCheon> Organization: Samsung AIT MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 16 Jun 2004 16:13:41 -0400 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jh.ch@samsung.com List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7BIT >> I have a question about RO taxonomy. >> In particular, I consider "nested mobile network" case. >> >> In your draft, you only consider a DSR or an AODV as a internal >> routing protocol. >> That point is my question. >> Why don't you consider MANET protocol of proactive method? >> >> In general, reactive method has better performance when the node has >> high mobility. >> However, if there is a mobile network including nested mobile network >> like a your example, >> each mobile network may has low mobility. >> >> Is there any special reason on that? > You're right: > The assumption was that the nodes were highly mobile regarding each > other. Depending on the degree and the type of mobility, various MANET > approaches apply. If they are moving together as a 'solid', a classical > proactive solution does the trick. > You can use OSPF at home, make the MRHA tunnel a not so stubby area and > make the MR an ASBR... In that case you can run the protocol you want in > the solid cloud and exchange the routes with the HA. I'm not sure we > have a use case for such a deployment, though. Most vehicles are moving along route(on the road or in the air). a mobile network with nested mobile networks seems a solid cloud. Consider several buses with high school students are moving on the road. Each bus is a mobile network separately. When a student in a BUS 1 who want to communicate with other student in a BUS 2, each mobile router can imagine that they located in same mobile network. At that time, to get information for rechability, proactive solution is easier than reactive approches. Of course, proactive solutions may load heavy work on mobile routers. > Maybe we can modify the text to make it more open (and vague actually :) > Do you feel it's needed? IMHO we apply MANET protocol as a internal routing protocol case by case. I wonder why did you only consider reactive solutions for that. > Pascal Jung-Hoon From nemo-bounces@ietf.org Fri Jun 18 12:32:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03913 for ; Fri, 18 Jun 2004 12:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbM6w-0007oP-2M; Fri, 18 Jun 2004 12:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbLn0-0001Lw-II for nemo@megatron.ietf.org; Fri, 18 Jun 2004 12:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02169 for ; Fri, 18 Jun 2004 12:00:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbLmz-00078S-Fg for nemo@ietf.org; Fri, 18 Jun 2004 12:00:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbLk0-00068m-00 for nemo@ietf.org; Fri, 18 Jun 2004 11:57:22 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1BbLhH-00058q-00 for nemo@ietf.org; Fri, 18 Jun 2004 11:54:31 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZI00C01HHY5U@mailout2.samsung.com> for nemo@ietf.org; Sat, 19 Jun 2004 00:53:58 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZI007EKHHXUM@mailout2.samsung.com> for nemo@ietf.org; Sat, 19 Jun 2004 00:53:58 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZI0089HHHTGZ@mmp2.samsung.com> for nemo@ietf.org; Sat, 19 Jun 2004 00:53:55 +0900 (KST) Date: Fri, 18 Jun 2004 21:22:25 +0530 From: "O.L.N.Rao" Subject: Re: [nemo] Conflicting statements - RAs on e-gress interfaces To: NEMO Message-id: <00dd01c4554c$c0960870$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007b01c452a7$c3088cb0$7a476c6b@sisodomain.com> <40CF3C43.6080208@iprg.nokia.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Cc: Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7BIT That is fine... :) Thanks, O.L.N. Rao ----- Original Message ----- From: "Vijay Devarapalli" To: "O.L.N.Rao" Cc: "NEMO" Sent: Tuesday, June 15, 2004 11:43 PM Subject: Re: [nemo] Conflicting statements - RAs on e-gress interfaces > thanks for catching this. as Hesham mentioned SHOULD > is probably better. > > Vijay > > O.L.N.Rao wrote: > > Hello All, > > > > I am just cut-pasting the snips from the NEMO Basic Support Protocol > > (Draft Version 3) > > which are conflicting. > > > > [SNIP 1] > > > > 5.6. Neighbor Discovery for Mobile Router > > > > When the Mobile Router is at home, it MAY be configured to send > > Router Advertisements and reply to Router Solicitations on the > > interface attached to the home link. The value of the Router > > *Lifetime field MUST be set to zero* to prevent other nodes from > > configuring the Mobile Router as the default router. > > > > [SNIP 2] > > > > 5.8. Returning Home > > > > - The Mobile Router MAY send router advertisements on its egress > > interfaces. But the router *lifetime SHOULD be set to 0*, so that > > hosts on the home link do not pick the Mobile Router as the > > default router. > > > > I guess following the lines of 5.6 would be better choice. > > > > Let me know if i am missing any thing. > > > > Thank you, > > > > Regards, > > O.L.N. Rao > > > > > From nemo-bounces@ietf.org Fri Jun 25 11:35:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11349 for ; Fri, 25 Jun 2004 11:35:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdsas-0005MC-CJ; Fri, 25 Jun 2004 11:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrvR-0004eY-Ne for nemo@megatron.ietf.org; Fri, 25 Jun 2004 10:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05590 for ; Fri, 25 Jun 2004 10:43:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdrvQ-0000WA-Ss for nemo@ietf.org; Fri, 25 Jun 2004 10:43:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdruE-0007kQ-00 for nemo@ietf.org; Fri, 25 Jun 2004 10:42:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Bdrso-0006zK-00 for nemo@ietf.org; Fri, 25 Jun 2004 10:40:51 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2004 16:56:10 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5PEe1UL016599 for ; Fri, 25 Jun 2004 16:40:17 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Jun 2004 15:41:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jun 2004 15:41:02 +0100 Message-ID: Thread-Topic: Announcing RRH version 5 Thread-Index: AcRawkpxT5poPXuQTwGvol/bZ7Nc3w== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 25 Jun 2004 14:41:03.0351 (UTC) FILETIME=[70A93870:01C45AC2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] Announcing RRH version 5 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: RRH has been around since the WG was formed. In fact, since it's an RO feature, we had to hold it for some time in order to focus on the basic support; on the bright side, this left RRH a fair chance to mature, which it did. Overtime, a number of competing techniques have been proposed, but RRH still stands as one good way of performing RO.=20 In fact, now that Tree Discovery is available as a separate draft, the needs and values of RRH are much clearer. Tree Discovery traces an optimized spanning tree of MRs, rooted at the infrastructure; and on top of route optimization and tunnel compression, RRH alleviates security and privacy issues and allows forwarding by a MR that would not be bound home, which in particular breaks a classical mobile Home deadlock in basic NEMO. I believe it's time to discuss whether tree discovery and RRH are part of the things we want to work on as a WG. I'm not sure it all fits in the current charter. Yet RRH has been very well received by those exposed to it and provides a real value for Mobile Networks. The new update of the RRH draft is now available at: http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-05.txt Changes from -04 to -05: Tree Information option: now a reference to a separate draft. Removed RRH heartbeat. Added a DHAAD section Clarified how RRH solves the mobile home deadlock. new section "Optimum number of slots in RRH" from ICMP section Pascal From nemo-bounces@ietf.org Tue Jun 29 11:12:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25814 for ; Tue, 29 Jun 2004 11:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfJz2-0006Og-Lu; Tue, 29 Jun 2004 10:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfJwE-0005qD-W6 for nemo@megatron.ietf.org; Tue, 29 Jun 2004 10:50:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24644 for ; Tue, 29 Jun 2004 10:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfJwE-0005Ji-6P for nemo@ietf.org; Tue, 29 Jun 2004 10:50:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfJvM-0004zK-00 for nemo@ietf.org; Tue, 29 Jun 2004 10:49:28 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1BfJuj-0004eT-00 for nemo@ietf.org; Tue, 29 Jun 2004 10:48:49 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i5TEmjsx004771; Tue, 29 Jun 2004 07:48:45 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i5TEmhdv019358; Tue, 29 Jun 2004 09:48:44 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2C9DA86381E; Tue, 29 Jun 2004 16:48:43 +0200 (CEST) Message-ID: <40E18145.8080108@motorola.com> Date: Tue, 29 Jun 2004 16:48:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Announcing RRH version 5 References: In-Reply-To: X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050400080407020205090203" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms050400080407020205090203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Pascal, Pascal Thubert (pthubert) wrote: [about RRH...] > In fact, since it's an RO feature, we had to hold it for some time in > order to focus on the basic support; on the bright side, this left > RRH a fair chance to mature, which it did. Overtime, a number of > competing techniques have been proposed, but RRH still stands as one > good way of performing RO. > > In fact, now that Tree Discovery is available as a separate draft, > the needs and values of RRH are much clearer. Tree Discovery traces > an optimized spanning tree of MRs, rooted at the infrastructure; and > on top of route optimization and tunnel compression, RRH alleviates > security and privacy issues and allows forwarding by a MR that would > not be bound home, which in particular breaks a classical mobile Home > deadlock in basic NEMO. > > I believe it's time to discuss whether tree discovery and RRH are > part of the things we want to work on as a WG. I'm not sure it all > fits in the current charter. Informally speaking, there may be IPR on solutions for Route Optimization for Moving Networks. Alex --------------ms050400080407020205090203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA2 MjkxNDQ4MzdaMCMGCSqGSIb3DQEJBDEWBBTiR7TeJ9RZQxMiTOkGrCZoe0a6LjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDWAxgegVTxWkAHB1B2P3vSpfANY/DX1e2Khb7l Jbs4NcJAdOBzzbAnqF6WXXvLqFCLYT3pndDepelqJ0Xc1A5ee8ycaAPhYTzwT1p6b9LemyVW 7hXBZeohO7ka53KJ/WzCMDS75V5BrzygN4phLw2THWQclR/384kZxjqOrmUDwQAAAAAAAA== --------------ms050400080407020205090203-- From nemo-bounces@ietf.org Tue Jun 29 11:43:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27210 for ; Tue, 29 Jun 2004 11:43:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKVA-0002eP-8n; Tue, 29 Jun 2004 11:26:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKNG-0001kk-UB for nemo@megatron.ietf.org; Tue, 29 Jun 2004 11:18:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26147 for ; Tue, 29 Jun 2004 11:18:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfKNG-0007Up-3I for nemo@ietf.org; Tue, 29 Jun 2004 11:18:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfKME-000792-00 for nemo@ietf.org; Tue, 29 Jun 2004 11:17:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BfKL7-00069O-00 for nemo@ietf.org; Tue, 29 Jun 2004 11:16:05 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Jun 2004 17:32:37 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5TFFTU7017787; Tue, 29 Jun 2004 17:15:30 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jun 2004 16:16:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Announcing RRH version 5 Date: Tue, 29 Jun 2004 16:16:28 +0100 Message-ID: Thread-Topic: [nemo] Announcing RRH version 5 Thread-Index: AcRd6Gqg5aVVDP9oTumh/rPf8VZObQAAhaMw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 29 Jun 2004 15:16:29.0812 (UTC) FILETIME=[0DC86B40:01C45DEC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Alex :) > Pascal Thubert (pthubert) wrote: > [about RRH...] > > In fact, since it's an RO feature, we had to hold it for some time in > > order to focus on the basic support; on the bright side, this left > > RRH a fair chance to mature, which it did. Overtime, a number of > > competing techniques have been proposed, but RRH still stands as one > > good way of performing RO. > > > > In fact, now that Tree Discovery is available as a separate draft, > > the needs and values of RRH are much clearer. Tree Discovery traces > > an optimized spanning tree of MRs, rooted at the infrastructure; and > > on top of route optimization and tunnel compression, RRH alleviates > > security and privacy issues and allows forwarding by a MR that would > > not be bound home, which in particular breaks a classical mobile Home > > deadlock in basic NEMO. > > > > I believe it's time to discuss whether tree discovery and RRH are > > part of the things we want to work on as a WG. I'm not sure it all > > fits in the current charter. >=20 > Informally speaking, there may be IPR on solutions for Route > Optimization for Moving Networks. You must be right. There's none that I know of on the RRH draft, though. It's a simple, opportunistic adaptation of the IPv4 LSRR for the Nemo needs - and maybe other needs as well? I think it could move forward quite easily.=20 There's some IPR from Cisco on tree discovery; now, since it's handled the same way as all the rest of the NEMO related IPR from Cisco, if you can do basic, you can do it all.=20 Pascal=20 From nemo-bounces@ietf.org Tue Jun 29 12:01:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28605 for ; Tue, 29 Jun 2004 12:01:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKxC-0006jT-3L; Tue, 29 Jun 2004 11:55:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKqS-0005z0-2u for nemo@megatron.ietf.org; Tue, 29 Jun 2004 11:48:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27720 for ; Tue, 29 Jun 2004 11:48:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfKqR-0002VO-5r for nemo@ietf.org; Tue, 29 Jun 2004 11:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfKpe-00029k-00 for nemo@ietf.org; Tue, 29 Jun 2004 11:47:39 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1BfKol-0001m5-00 for nemo@ietf.org; Tue, 29 Jun 2004 11:46:43 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i5TFkBWH004165; Tue, 29 Jun 2004 08:46:12 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i5TFk9dv030247; Tue, 29 Jun 2004 10:46:10 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4CEAA865980; Tue, 29 Jun 2004 17:46:09 +0200 (CEST) Message-ID: <40E18EB8.1060302@motorola.com> Date: Tue, 29 Jun 2004 17:46:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Announcing RRH version 5 References: In-Reply-To: X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050204020106080409060401" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms050204020106080409060401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi again Pascal, Pascal Thubert (pthubert) wrote: > You must be right. There's none that I know of on the RRH draft, > though. It's a simple, opportunistic adaptation of the IPv4 LSRR for > the Nemo needs - and maybe other needs as well? Yes, how about RRH being looked into by other IPv6 WG's. As a matter of fact one could do lots of things with RRH exactly as one could do lots of things with Loose Source Routing, not necessarily the moving networks RO. > I think it could move forward quite easily. Talking early about IPR is important for future advancement. > There's some IPR from Cisco on tree discovery; A-ha. Good to know. Alex --------------ms050204020106080409060401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA2 MjkxNTQ2MDBaMCMGCSqGSIb3DQEJBDEWBBQPajxozLzm8oMtVv4omhiFPnB81TBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDCnz/Jqe27LcmJIf8kjZz1vpUdyyWSGEGwtm0i t5n9qfTzFwdfSlxFE+5mYiYM8B1CIJ+3TARa+4vVWtkPkoF5vzvmX//MRDWVKJX0KJGzzq7y RVxbZ403ks2f+5BL7fpMV3PtOi5MDWyIv6KztwAVfb6rHDqAU3bHiMllZVGOUAAAAAAAAA== --------------ms050204020106080409060401-- From nemo-bounces@ietf.org Tue Jun 29 12:26:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29939 for ; Tue, 29 Jun 2004 12:26:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfLKZ-0002rN-B5; Tue, 29 Jun 2004 12:19:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfL2z-0007bb-Lk for nemo@megatron.ietf.org; Tue, 29 Jun 2004 12:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28545 for ; Tue, 29 Jun 2004 12:01:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfL2y-00076p-Or for nemo@ietf.org; Tue, 29 Jun 2004 12:01:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfL24-0006j8-00 for nemo@ietf.org; Tue, 29 Jun 2004 12:00:29 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BfL12-0005y9-00 for nemo@ietf.org; Tue, 29 Jun 2004 11:59:24 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Jun 2004 18:15:59 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5TFwoU7025234; Tue, 29 Jun 2004 17:58:50 +0200 (MEST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jun 2004 16:59:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Announcing RRH version 5 Date: Tue, 29 Jun 2004 16:59:49 +0100 Message-ID: Thread-Topic: [nemo] Announcing RRH version 5 Thread-Index: AcRd8UGS2maWOtEWQNOpvqDC/iJKQgAAC2Qw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 29 Jun 2004 15:59:50.0471 (UTC) FILETIME=[1BE57D70:01C45DF2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >=20 > Yes, how about RRH being looked into by other IPv6 WG's. As a matter of > fact one could do lots of things with RRH exactly as one could do lots > of things with Loose Source Routing, not necessarily the moving networks RO. Well, there's still the question of what to do with it, when to actually reverse it etc... Just like MIP has a RH2, there is a specific MIP/NEMO RRH that gets stored in the BCE, and is reversed specifically in the DHAAD (and eventually the HoT if we work that out) flows. I guess that much is our job. If v6WG needs to extend it to a more global level, we can always benefit from the NEMO experience to do so.=20 Pascal