From nemo-admin@ietf.org Thu Apr 1 04:38:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03396 for ; Thu, 1 Apr 2004 04:38:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yeC-0001Bi-5b; Thu, 01 Apr 2004 04:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ydB-0000yZ-CO for nemo@optimus.ietf.org; Thu, 01 Apr 2004 04:37:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03360 for ; Thu, 1 Apr 2004 04:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yd8-00054A-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:36:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ycK-00050T-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:36:09 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B8ybM-0004uM-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:35:08 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i319ZJU9015545; Thu, 1 Apr 2004 02:35:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i319Z5jF006426; Thu, 1 Apr 2004 03:35:06 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A001385C46E; Thu, 1 Apr 2004 11:35:04 +0200 (CEST) Message-ID: <406BE241.8080301@motorola.com> Date: Thu, 01 Apr 2004 11:34:57 +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: hardie@qualcomm.com Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Router lifetime in RAs from mobile routers References: <406B8E5A.7060301@iprg.nokia.com> In-Reply-To: <406B8E5A.7060301@iprg.nokia.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="------------ms040503010307070802000109" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms040503010307070802000109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, thanks for the comment; let me add further support to Vijay's explanation on motivating the MR's sending RA's with lifetime 0 (on the egress interface on the home link). Vijay Devarapalli wrote: > Ted: >> I'm a bit confused by this text in section 5.6: >> >>> 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. >> >> I don't see cases where the mobile router would have a different >> upstream link in its home link than a non-mobile router on this >> link. Right, neither do I; we haven't considered such cases. We didn't want the MR on the home link to be default router for any host on the home link, so RFC2461 says we can achieve this by having the MR to put lifetime 0 in the RA sent by MR. RFC 2461: > A router might want to send Router Advertisements without advertising > itself as a default router. For instance, a router might advertise > prefixes for address autoconfiguration while not wishing to forward > packets. Such a router sets the Router Lifetime field in outgoing > advertisements to zero. All routers on the home link (mobile or fixed) configure their default routes manually (or IGP), but not from received RA's; so the danger of MR becoming default upstream router is valid only at the hosts on the home link, not for the routers there. > Ted: >> Is there a use case where it is expected that all the routers on >> the home link might be mobile routers (so only mobile routers are >> replying to RSs?) We haven't considered such use cases. I think that you seem to agree with us about forbidding the MR to become an upstream default router for hosts on the home link - we don't want that either. Requiring MR to put lifetime 0 was _not_ motivated by use cases where all the routers on the home link be mobile routers. Alex > actually this restriction is there to protect IPv6 hosts on the home > link from configuring a mobile router as the default router instead > of a non-mobile router. > > you could have mobile nodes and mobile routers connecting to the same > home link when they are at home. when the mobile routers return > home, they can start acting like regular routers on the egress > interface (the interface with which they attach to the home link). > they can start sending router advertisements. but we dont want mobile > nodes (or any IPv6 host) on the home link to pick the mobile router > as the default router. so we recommed setting the lifetime in the > router advertisements to zero, so that no host on the home link picks > a mobile router as the default router. > > do you see a need for more text to explain this? > > Vijay --------------ms040503010307070802000109 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDEwOTM0NThaMCMGCSqGSIb3DQEJBDEWBBRVhc7VnsO+5IrRIDey+RARnb9LtjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBipydBS1OFWbyWjK4S44+CbfoeYiS/UsocX10n 5I4acflRLbhwHFfsx0fedeiwG+5DXIxpOzaBd+RDUlaAMdkedSJXfxjB9QunUU4XvNwUpJfz N7LjHa8Ojy1QuJvp/E8ApsJ0+3WJDwLq4SzqNHSym5yzerLfC3Ttcevv7yyrBgAAAAAAAA== --------------ms040503010307070802000109-- From exim@www1.ietf.org Thu Apr 1 04:40:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Thu, 1 Apr 2004 04:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yg5-0001X0-FS for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 04:40:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i319e1h5005868 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 04:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yg4-0001WZ-FS for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03429 for ; Thu, 1 Apr 2004 04:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yg1-0005GS-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 04:39:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yf6-0005D2-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 04:39:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8yeF-00059g-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 04:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yeC-0001Bi-5b; Thu, 01 Apr 2004 04:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ydB-0000yZ-CO for nemo@optimus.ietf.org; Thu, 01 Apr 2004 04:37:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03360 for ; Thu, 1 Apr 2004 04:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yd8-00054A-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:36:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ycK-00050T-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:36:09 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B8ybM-0004uM-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:35:08 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i319ZJU9015545; Thu, 1 Apr 2004 02:35:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i319Z5jF006426; Thu, 1 Apr 2004 03:35:06 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A001385C46E; Thu, 1 Apr 2004 11:35:04 +0200 (CEST) Message-ID: <406BE241.8080301@motorola.com> Date: Thu, 01 Apr 2004 11:34:57 +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: hardie@qualcomm.com Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Router lifetime in RAs from mobile routers References: <406B8E5A.7060301@iprg.nokia.com> In-Reply-To: <406B8E5A.7060301@iprg.nokia.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="------------ms040503010307070802000109" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms040503010307070802000109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, thanks for the comment; let me add further support to Vijay's explanation on motivating the MR's sending RA's with lifetime 0 (on the egress interface on the home link). Vijay Devarapalli wrote: > Ted: >> I'm a bit confused by this text in section 5.6: >> >>> 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. >> >> I don't see cases where the mobile router would have a different >> upstream link in its home link than a non-mobile router on this >> link. Right, neither do I; we haven't considered such cases. We didn't want the MR on the home link to be default router for any host on the home link, so RFC2461 says we can achieve this by having the MR to put lifetime 0 in the RA sent by MR. RFC 2461: > A router might want to send Router Advertisements without advertising > itself as a default router. For instance, a router might advertise > prefixes for address autoconfiguration while not wishing to forward > packets. Such a router sets the Router Lifetime field in outgoing > advertisements to zero. All routers on the home link (mobile or fixed) configure their default routes manually (or IGP), but not from received RA's; so the danger of MR becoming default upstream router is valid only at the hosts on the home link, not for the routers there. > Ted: >> Is there a use case where it is expected that all the routers on >> the home link might be mobile routers (so only mobile routers are >> replying to RSs?) We haven't considered such use cases. I think that you seem to agree with us about forbidding the MR to become an upstream default router for hosts on the home link - we don't want that either. Requiring MR to put lifetime 0 was _not_ motivated by use cases where all the routers on the home link be mobile routers. Alex > actually this restriction is there to protect IPv6 hosts on the home > link from configuring a mobile router as the default router instead > of a non-mobile router. > > you could have mobile nodes and mobile routers connecting to the same > home link when they are at home. when the mobile routers return > home, they can start acting like regular routers on the egress > interface (the interface with which they attach to the home link). > they can start sending router advertisements. but we dont want mobile > nodes (or any IPv6 host) on the home link to pick the mobile router > as the default router. so we recommed setting the lifetime in the > router advertisements to zero, so that no host on the home link picks > a mobile router as the default router. > > do you see a need for more text to explain this? > > Vijay --------------ms040503010307070802000109 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDEwOTM0NThaMCMGCSqGSIb3DQEJBDEWBBRVhc7VnsO+5IrRIDey+RARnb9LtjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBipydBS1OFWbyWjK4S44+CbfoeYiS/UsocX10n 5I4acflRLbhwHFfsx0fedeiwG+5DXIxpOzaBd+RDUlaAMdkedSJXfxjB9QunUU4XvNwUpJfz N7LjHa8Ojy1QuJvp/E8ApsJ0+3WJDwLq4SzqNHSym5yzerLfC3Ttcevv7yyrBgAAAAAAAA== --------------ms040503010307070802000109-- From nemo-admin@ietf.org Thu Apr 1 04:49:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03620 for ; Thu, 1 Apr 2004 04:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yoo-00022Q-5O; Thu, 01 Apr 2004 04:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ynu-00020d-NA for nemo@optimus.ietf.org; Thu, 01 Apr 2004 04:48:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03568 for ; Thu, 1 Apr 2004 04:48:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ynr-0005r8-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ymy-0005nI-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:47:09 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B8ymX-0005j5-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:46:41 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i319kgAh028738 for ; Thu, 1 Apr 2004 11:46:42 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:31:32 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8F4SWA4; Thu, 1 Apr 2004 10:30:52 +0200 Message-ID: <406BD324.3030001@ericsson.com> Date: Thu, 01 Apr 2004 10:30:28 +0200 X-Sybari-Trust: f55fadfe 2c4885b5 c2dda0f6 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 08:31:32.0891 (UTC) FILETIME=[BCECBEB0:01C417C3] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hesham, Soliman Hesham wrote: > I saw Steve Bellovin's comment on this section below. > Since I've been wanting to raise the same point, I have > a short comment. > > 8: This text is unclear: > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router > should be careful in including the same Mobile Network > Prefixes in the Binding Update to the Home Agent and in > the routing protocol updates. The Home Agent depending > on its configuration might not add routes based on the > prefix information in the Binding Updates at all, and > might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > > Do you mean "be careful to include the same information in > both places" -- redunancy is sometimes good. Or do you > mean "be careful to avoid doing this"? Personally, I think > the former is more appropriate, because it allows a check > on the validity of the routing information. Note that the > prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus > suggest that routing advertisements MUST NOT contain any > prefixes not known to the home agent by either implicit > mode configuration or explicit mode announcement. > > => Basically I think we need to make sure that the HA > checks the routing information exchanged and matches it > against the prefix information that it already knows from > the MNP table/manual config/BCEs ..etc to make sure that > MRs are authorised to advertise such prefix(es). > So we need tight coupling between the routing protocol > content and the content in the BU/manual config. > Otherwise Bad Guy could send a vaild BU and start announcing > someone else's prefix. > > Note that in many cases today IGPs are authenticated with > a single "domain key". To maintain this type of security > we need to verify that the MRs are authorised to advertise > reachability to the prefixes in question. > > I think a text change for this section will suffice. I basically agree with you. I think there may be two use cases here with slightly different assumptions: 1. All MRs and HA belong to the same administrative domain. They can have a single trust level (domain key). 2. MRs belong to different administrative domains or the HA and the MRs belong to different domains. Obviously they don't trust each other. In 1) it would be ok to separate BU authorization from routing protocol authorization. In 2) it wouldn't. What you propose is to always go with the assumption that entities don't trust each other and that we have multiple trust relationships. I'm just curious how difficult one can consider it is (implementation-wise) to exchange information a RIPng process with the HA function inside the HA. /Mattias From exim@www1.ietf.org Thu Apr 1 04:51:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03707 for ; Thu, 1 Apr 2004 04:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yqj-0002Fg-BA for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 04:51:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i319p1g7008650 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 04:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yqi-0002FP-V8 for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:51:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03685 for ; Thu, 1 Apr 2004 04:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yqf-00067O-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 04:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ypg-00060R-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 04:49:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8yon-0005uy-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 04:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yoo-00022Q-5O; Thu, 01 Apr 2004 04:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ynu-00020d-NA for nemo@optimus.ietf.org; Thu, 01 Apr 2004 04:48:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03568 for ; Thu, 1 Apr 2004 04:48:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ynr-0005r8-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ymy-0005nI-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:47:09 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B8ymX-0005j5-00 for nemo@ietf.org; Thu, 01 Apr 2004 04:46:41 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i319kgAh028738 for ; Thu, 1 Apr 2004 11:46:42 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:31:32 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8F4SWA4; Thu, 1 Apr 2004 10:30:52 +0200 Message-ID: <406BD324.3030001@ericsson.com> Date: Thu, 01 Apr 2004 10:30:28 +0200 X-Sybari-Trust: f55fadfe 2c4885b5 c2dda0f6 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 08:31:32.0891 (UTC) FILETIME=[BCECBEB0:01C417C3] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Hi Hesham, Soliman Hesham wrote: > I saw Steve Bellovin's comment on this section below. > Since I've been wanting to raise the same point, I have > a short comment. > > 8: This text is unclear: > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router > should be careful in including the same Mobile Network > Prefixes in the Binding Update to the Home Agent and in > the routing protocol updates. The Home Agent depending > on its configuration might not add routes based on the > prefix information in the Binding Updates at all, and > might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > > Do you mean "be careful to include the same information in > both places" -- redunancy is sometimes good. Or do you > mean "be careful to avoid doing this"? Personally, I think > the former is more appropriate, because it allows a check > on the validity of the routing information. Note that the > prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus > suggest that routing advertisements MUST NOT contain any > prefixes not known to the home agent by either implicit > mode configuration or explicit mode announcement. > > => Basically I think we need to make sure that the HA > checks the routing information exchanged and matches it > against the prefix information that it already knows from > the MNP table/manual config/BCEs ..etc to make sure that > MRs are authorised to advertise such prefix(es). > So we need tight coupling between the routing protocol > content and the content in the BU/manual config. > Otherwise Bad Guy could send a vaild BU and start announcing > someone else's prefix. > > Note that in many cases today IGPs are authenticated with > a single "domain key". To maintain this type of security > we need to verify that the MRs are authorised to advertise > reachability to the prefixes in question. > > I think a text change for this section will suffice. I basically agree with you. I think there may be two use cases here with slightly different assumptions: 1. All MRs and HA belong to the same administrative domain. They can have a single trust level (domain key). 2. MRs belong to different administrative domains or the HA and the MRs belong to different domains. Obviously they don't trust each other. In 1) it would be ok to separate BU authorization from routing protocol authorization. In 2) it wouldn't. What you propose is to always go with the assumption that entities don't trust each other and that we have multiple trust relationships. I'm just curious how difficult one can consider it is (implementation-wise) to exchange information a RIPng process with the HA function inside the HA. /Mattias From nemo-admin@ietf.org Thu Apr 1 07:14:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08213 for ; Thu, 1 Apr 2004 07:14:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9156-0005ik-Vq; Thu, 01 Apr 2004 07:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B914H-000552-CH for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:13:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08135 for ; Thu, 1 Apr 2004 07:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B914G-0002G0-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:13:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B913Q-0002Bi-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:12:17 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B912n-00026h-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:11:37 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31CBkU9004560 for ; Thu, 1 Apr 2004 05:11:46 -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 i31CAfRD004781 for ; Thu, 1 Apr 2004 06:11:26 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 01FEE855530 for ; Thu, 1 Apr 2004 14:10:41 +0200 (CEST) Message-ID: <406C06B8.1040909@motorola.com> Date: Thu, 01 Apr 2004 14:10:32 +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 Cc: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: 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="------------ms040804020303040209050001" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms040804020303040209050001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve Bellovin wrote about section 8 draft-02 in IESG review: > Do you mean "be careful to include the same information in both > places" -- redunancy is sometimes good. Or do you mean "be careful > to avoid doing this"? Personally, I think the former is more > appropriate, because it allows a check on the validity of the routing > information. I also think the text should be along the lines of "careful with that prefix, include same information in both places", and not "careful to avoid doing this". > Note that the prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus suggest > that routing advertisements MUST NOT contain any prefixes not known > to the home agent by either implicit mode configuration or explicit > mode announcement. Basically, I agree with this; this is a useful check. My preferred way to solve this potential conflicting information between the prefixes advertised by NEMO and the ones advertised by rt protocol is to have NEMO _not_ have prefixes in the BU, that is: implicit mode. Let only the rt protocol make do about prefixes. Moreover, there are at least three ways by which a host learns routes (rt protocol, icmp redirects, static config). Adding NEMO as a fourth means only complicates the picture: one wants all four means to distribute the same routing information; why not let NEMO just do the Home-Address - Care-of-Address binding. Alex --------------ms040804020303040209050001 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjEwMzJaMCMGCSqGSIb3DQEJBDEWBBQR4S69vQaGhCAOAO1P2/OfwvnNHzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYA3FEerahrMvDp+9RP3h1MWpI9HSxwIFtXk737f jzvuEMs/GjjaIj5vh0f9u7yY0CWIynk4bJYL6xckpT/4yuzBHTZwIMaIf/XSSVP7Ktf/2/hu TEfAMVtsyMOK+zUGa/LTkuC7HlZ72LWrPEIwknz8PMc+30SKdUtm/V5rINOF1AAAAAAAAA== --------------ms040804020303040209050001-- From exim@www1.ietf.org Thu Apr 1 07:16:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08327 for ; Thu, 1 Apr 2004 07:16:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B917G-00065C-PQ for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 07:16:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CGETt023378 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 07:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B917G-00064z-JL for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:16:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08302 for ; Thu, 1 Apr 2004 07:16:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B917G-0002Xv-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B916F-0002Po-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:15:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9159-0002Jg-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9156-0005ik-Vq; Thu, 01 Apr 2004 07:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B914H-000552-CH for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:13:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08135 for ; Thu, 1 Apr 2004 07:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B914G-0002G0-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:13:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B913Q-0002Bi-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:12:17 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B912n-00026h-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:11:37 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31CBkU9004560 for ; Thu, 1 Apr 2004 05:11:46 -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 i31CAfRD004781 for ; Thu, 1 Apr 2004 06:11:26 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 01FEE855530 for ; Thu, 1 Apr 2004 14:10:41 +0200 (CEST) Message-ID: <406C06B8.1040909@motorola.com> Date: Thu, 01 Apr 2004 14:10:32 +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 Cc: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: 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="------------ms040804020303040209050001" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms040804020303040209050001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve Bellovin wrote about section 8 draft-02 in IESG review: > Do you mean "be careful to include the same information in both > places" -- redunancy is sometimes good. Or do you mean "be careful > to avoid doing this"? Personally, I think the former is more > appropriate, because it allows a check on the validity of the routing > information. I also think the text should be along the lines of "careful with that prefix, include same information in both places", and not "careful to avoid doing this". > Note that the prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus suggest > that routing advertisements MUST NOT contain any prefixes not known > to the home agent by either implicit mode configuration or explicit > mode announcement. Basically, I agree with this; this is a useful check. My preferred way to solve this potential conflicting information between the prefixes advertised by NEMO and the ones advertised by rt protocol is to have NEMO _not_ have prefixes in the BU, that is: implicit mode. Let only the rt protocol make do about prefixes. Moreover, there are at least three ways by which a host learns routes (rt protocol, icmp redirects, static config). Adding NEMO as a fourth means only complicates the picture: one wants all four means to distribute the same routing information; why not let NEMO just do the Home-Address - Care-of-Address binding. Alex --------------ms040804020303040209050001 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjEwMzJaMCMGCSqGSIb3DQEJBDEWBBQR4S69vQaGhCAOAO1P2/OfwvnNHzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYA3FEerahrMvDp+9RP3h1MWpI9HSxwIFtXk737f jzvuEMs/GjjaIj5vh0f9u7yY0CWIynk4bJYL6xckpT/4yuzBHTZwIMaIf/XSSVP7Ktf/2/hu TEfAMVtsyMOK+zUGa/LTkuC7HlZ72LWrPEIwknz8PMc+30SKdUtm/V5rINOF1AAAAAAAAA== --------------ms040804020303040209050001-- From nemo-admin@ietf.org Thu Apr 1 07:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09246 for ; Thu, 1 Apr 2004 07:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91XB-0008GF-Op; Thu, 01 Apr 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91WL-0008Dp-5T for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09213 for ; Thu, 1 Apr 2004 07:42:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91WK-0004w5-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91VN-0004sG-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:41:09 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1B91V6-0004oH-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:40:52 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i31CeqI4014327 for ; Thu, 1 Apr 2004 05:40:52 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i31CYXGr014632 for ; Thu, 1 Apr 2004 06:34:33 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5F75A855531 for ; Thu, 1 Apr 2004 14:35:45 +0200 (CEST) Message-ID: <406C0C98.4050307@motorola.com> Date: Thu, 01 Apr 2004 14:35:36 +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: IETF NEMO WG 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="------------ms000501020205080409020105" 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 Subject: [nemo] issue 34 about Error in error processing, nemo base draft-02 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms000501020205080409020105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit S. Bellovin wrote: > 5.4: why is 140 not allowed in explicit mode? 6.6 implies that it > should be. True. My understanding is that the above remark comes from the following two paragraphs in draft-02: section 5.4 > If the Mobile Router sent a Binding Update to Home Agent in explict > mode then the Mobile Router interprets only the error status '141' > (Invalid Prefix) and '142' (Not Authorized for Prefix). For this > Binding Update, the Mobile Router MUST discard Binding > Acknowledgements with codes '140' and '143'. section 6.6: > If the Home Agent is configured not to support mobile routers, it > sets the status code in the Binding Acknowledgement to '140' (Mobile > Router Operation not permitted). I think, in order to solve this issue, one possibility: modify the above paragraph of section 6.6 to say that if this BAck corresponds to a BU received in implicit mode then send 140 (Mobile Router operation not permitted), otherwise send 141 (Invalid Prefix). Second possibility, modify the paragraph cited of section 5.4 to say that MR does interpret the 140 in the BAck in explicit mode too. And, if MR receives BAck 140 after having sent BU explicit, then send a similar explicit BU to another HA on the home link, and after all tried HA's and still not BAck 0, then stop. Alex --------------ms000501020205080409020105 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjM1MzZaMCMGCSqGSIb3DQEJBDEWBBQKhYKW3d0s9yseBThP8OgnKtc8lzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCLWwVXOPx6f8MMh7xGVWik1kUhx3LOFRlF2IJJ YrDeTg7PE4WDFq7hvgUlvLGYv3Bq8Uju1Oug0RU5fBl6nOYoCOA9Kho8B1hDki18an+R2NO3 RIB3rErMlS9bMllFBcgZgeHvdgXZ6BqK+Xt8KWT4kI4ZVH2vz1HGawYdp8j/fwAAAAAAAA== --------------ms000501020205080409020105-- From nemo-admin@ietf.org Thu Apr 1 07:44:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09280 for ; Thu, 1 Apr 2004 07:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Y9-0008QX-Ia; Thu, 01 Apr 2004 07:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91XF-0008J5-Lb for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09232 for ; Thu, 1 Apr 2004 07:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91XE-00050Q-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:43:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91WL-0004wJ-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:42:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B91Vi-0004oL-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:41:30 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Apr 2004 07:40:55 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Thu, 1 Apr 2004 07:40:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQXzpVfo2n1wG3mTx+0xqtmvCLHzQAFlwUA From: "Soliman Hesham" To: "Mattias Pettersson" CC: "IETF NEMO WG" X-OriginalArrivalTime: 01 Apr 2004 12:40:55.0923 (UTC) FILETIME=[93963C30:01C417E6] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Mattias,=20 >=20 > I basically agree with you. I think there may be two use=20 > cases here with=20 > slightly different assumptions: >=20 > 1. All MRs and HA belong to the same administrative domain. They can=20 > have a single trust level (domain key). =3D> Agreed. >=20 > 2. MRs belong to different administrative domains or the HA=20 > and the MRs=20 > belong to different domains. Obviously they don't trust each other. >=20 > In 1) it would be ok to separate BU authorization from=20 > routing protocol=20 > authorization. In 2) it wouldn't. What you propose is to=20 > always go with=20 > the assumption that entities don't trust each other and that we have=20 > multiple trust relationships. =3D> Agreed. I was just thinking of a general HA that might end up supporting both types of MRs (i.e. trusted and not trusted). So unless further configuration is done to distinguish between the two cases the HA won't know the difference. >=20 > I'm just curious how difficult one can consider it is=20 > (implementation-wise) to exchange information a RIPng=20 > process with the=20 > HA function inside the HA. =3D> It depends on the platform of course, but it also depends on whether a copy of the prefix table/BCE is available to user space processes (e.g. in a file). Hesham >=20 > /Mattias >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=20 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 From exim@www1.ietf.org Thu Apr 1 07:45:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09357 for ; Thu, 1 Apr 2004 07:45:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91ZH-00007p-Ip for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 07:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CjBYf000477 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 07:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91ZH-00007c-Dg for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09302 for ; Thu, 1 Apr 2004 07:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91ZG-0005CC-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:45:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91YE-00055c-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:44:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91XD-00050G-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91XB-0008GF-Op; Thu, 01 Apr 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91WL-0008Dp-5T for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09213 for ; Thu, 1 Apr 2004 07:42:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91WK-0004w5-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91VN-0004sG-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:41:09 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1B91V6-0004oH-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:40:52 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i31CeqI4014327 for ; Thu, 1 Apr 2004 05:40:52 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i31CYXGr014632 for ; Thu, 1 Apr 2004 06:34:33 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5F75A855531 for ; Thu, 1 Apr 2004 14:35:45 +0200 (CEST) Message-ID: <406C0C98.4050307@motorola.com> Date: Thu, 01 Apr 2004 14:35:36 +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: IETF NEMO WG 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="------------ms000501020205080409020105" Subject: [nemo] issue 34 about Error in error processing, nemo base draft-02 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms000501020205080409020105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit S. Bellovin wrote: > 5.4: why is 140 not allowed in explicit mode? 6.6 implies that it > should be. True. My understanding is that the above remark comes from the following two paragraphs in draft-02: section 5.4 > If the Mobile Router sent a Binding Update to Home Agent in explict > mode then the Mobile Router interprets only the error status '141' > (Invalid Prefix) and '142' (Not Authorized for Prefix). For this > Binding Update, the Mobile Router MUST discard Binding > Acknowledgements with codes '140' and '143'. section 6.6: > If the Home Agent is configured not to support mobile routers, it > sets the status code in the Binding Acknowledgement to '140' (Mobile > Router Operation not permitted). I think, in order to solve this issue, one possibility: modify the above paragraph of section 6.6 to say that if this BAck corresponds to a BU received in implicit mode then send 140 (Mobile Router operation not permitted), otherwise send 141 (Invalid Prefix). Second possibility, modify the paragraph cited of section 5.4 to say that MR does interpret the 140 in the BAck in explicit mode too. And, if MR receives BAck 140 after having sent BU explicit, then send a similar explicit BU to another HA on the home link, and after all tried HA's and still not BAck 0, then stop. Alex --------------ms000501020205080409020105 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjM1MzZaMCMGCSqGSIb3DQEJBDEWBBQKhYKW3d0s9yseBThP8OgnKtc8lzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCLWwVXOPx6f8MMh7xGVWik1kUhx3LOFRlF2IJJ YrDeTg7PE4WDFq7hvgUlvLGYv3Bq8Uju1Oug0RU5fBl6nOYoCOA9Kho8B1hDki18an+R2NO3 RIB3rErMlS9bMllFBcgZgeHvdgXZ6BqK+Xt8KWT4kI4ZVH2vz1HGawYdp8j/fwAAAAAAAA== --------------ms000501020205080409020105-- From exim@www1.ietf.org Thu Apr 1 07:46:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09455 for ; Thu, 1 Apr 2004 07:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91a8-0000A7-Lo for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 07:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Ck4Q7000619 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 07:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91a8-00009u-Hd for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09377 for ; Thu, 1 Apr 2004 07:46:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91a7-0005Kg-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:46:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91Z8-0005B0-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:45:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91Y9-00054p-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91Y9-0008QX-Ia; Thu, 01 Apr 2004 07:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91XF-0008J5-Lb for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09232 for ; Thu, 1 Apr 2004 07:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91XE-00050Q-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:43:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91WL-0004wJ-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:42:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B91Vi-0004oL-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:41:30 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Apr 2004 07:40:55 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Thu, 1 Apr 2004 07:40:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQXzpVfo2n1wG3mTx+0xqtmvCLHzQAFlwUA From: "Soliman Hesham" To: "Mattias Pettersson" CC: "IETF NEMO WG" X-OriginalArrivalTime: 01 Apr 2004 12:40:55.0923 (UTC) FILETIME=[93963C30:01C417E6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable Hi Mattias,=20 >=20 > I basically agree with you. I think there may be two use=20 > cases here with=20 > slightly different assumptions: >=20 > 1. All MRs and HA belong to the same administrative domain. They can=20 > have a single trust level (domain key). =3D> Agreed. >=20 > 2. MRs belong to different administrative domains or the HA=20 > and the MRs=20 > belong to different domains. Obviously they don't trust each other. >=20 > In 1) it would be ok to separate BU authorization from=20 > routing protocol=20 > authorization. In 2) it wouldn't. What you propose is to=20 > always go with=20 > the assumption that entities don't trust each other and that we have=20 > multiple trust relationships. =3D> Agreed. I was just thinking of a general HA that might end up supporting both types of MRs (i.e. trusted and not trusted). So unless further configuration is done to distinguish between the two cases the HA won't know the difference. >=20 > I'm just curious how difficult one can consider it is=20 > (implementation-wise) to exchange information a RIPng=20 > process with the=20 > HA function inside the HA. =3D> It depends on the platform of course, but it also depends on whether a copy of the prefix table/BCE is available to user space processes (e.g. in a file). Hesham >=20 > /Mattias >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=20 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 From nemo-admin@ietf.org Thu Apr 1 07:54:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09780 for ; Thu, 1 Apr 2004 07:54:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91hp-0000ox-Cv; Thu, 01 Apr 2004 07:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91gw-0000kC-AK for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:53:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09705 for ; Thu, 1 Apr 2004 07:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91gv-000670-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:53:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91fy-0005zF-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:52:06 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B91f2-0005uE-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:51:08 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31CpHU9026729 for ; Thu, 1 Apr 2004 05:51:17 -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 i31CotJV015620 for ; Thu, 1 Apr 2004 06:50:56 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C1D8985C46E for ; Thu, 1 Apr 2004 14:50:54 +0200 (CEST) Message-ID: <406C1027.4070601@motorola.com> Date: Thu, 01 Apr 2004 14:50:47 +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="------------ms010304080001000709030304" 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 Subject: [nemo] issue 35 on Error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms010304080001000709030304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG reviewer: > In section 6.6 under a certain condition (which is independent of > whether implicit or explicit mode is in use) it describes sending > error status code 140. However, in the description of what a MR does > with responses in explicit mode, error code 140 implies discard > response. If the MR is going to discard it, why send it? The MR > needs to know there was a problem, so I think the fix is to make it > process these. Right. The idea of MR dropping BAck 140 in explicit mode was to have the loop stopped, I'll explain below "loop". However, since this is the third time this issue comes up, I agree with having MR process BAck 140 explicit (or have HA send BAck 141 explicit) (two different ways). Idea of "loop" was that MR starts sending BU's implicit, gets back negative BAcks, then sends BU's explicit, and if still error then stop, avoid re-starting to send BU's implicit. But this loop could still be avoided with the suggested modifciations. Alex --------------ms010304080001000709030304 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjUwNDdaMCMGCSqGSIb3DQEJBDEWBBRlj9WqQtrmgmnz9IJ/AQe3IltwFzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC3OnFwH5muMXNBO0CvqZRCwpGBqj3vzD9cpBgr F1Ahh2gRNJgaW2qEj01gS+dmNbTtAlTB9R2yzk4M049Qosdmk7ES53uAF0PWbduN4ySXUSsB vvNiwPnAEwsg7ToK+5atOr3sZ8uvvmHB/ZKV+y5dIf+ot2vdvr7c93T548pvCAAAAAAAAA== --------------ms010304080001000709030304-- From exim@www1.ietf.org Thu Apr 1 07:56:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09849 for ; Thu, 1 Apr 2004 07:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91jn-00012F-8f for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 07:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Cu3PT003975 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 07:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91jn-000122-3P for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09828 for ; Thu, 1 Apr 2004 07:55:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91jm-0006Os-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91in-0006I8-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:55:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91hq-0006CZ-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91hp-0000ox-Cv; Thu, 01 Apr 2004 07:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91gw-0000kC-AK for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:53:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09705 for ; Thu, 1 Apr 2004 07:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91gv-000670-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:53:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91fy-0005zF-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:52:06 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B91f2-0005uE-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:51:08 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31CpHU9026729 for ; Thu, 1 Apr 2004 05:51:17 -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 i31CotJV015620 for ; Thu, 1 Apr 2004 06:50:56 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C1D8985C46E for ; Thu, 1 Apr 2004 14:50:54 +0200 (CEST) Message-ID: <406C1027.4070601@motorola.com> Date: Thu, 01 Apr 2004 14:50:47 +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="------------ms010304080001000709030304" Subject: [nemo] issue 35 on Error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms010304080001000709030304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG reviewer: > In section 6.6 under a certain condition (which is independent of > whether implicit or explicit mode is in use) it describes sending > error status code 140. However, in the description of what a MR does > with responses in explicit mode, error code 140 implies discard > response. If the MR is going to discard it, why send it? The MR > needs to know there was a problem, so I think the fix is to make it > process these. Right. The idea of MR dropping BAck 140 in explicit mode was to have the loop stopped, I'll explain below "loop". However, since this is the third time this issue comes up, I agree with having MR process BAck 140 explicit (or have HA send BAck 141 explicit) (two different ways). Idea of "loop" was that MR starts sending BU's implicit, gets back negative BAcks, then sends BU's explicit, and if still error then stop, avoid re-starting to send BU's implicit. But this loop could still be avoided with the suggested modifciations. Alex --------------ms010304080001000709030304 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjUwNDdaMCMGCSqGSIb3DQEJBDEWBBRlj9WqQtrmgmnz9IJ/AQe3IltwFzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC3OnFwH5muMXNBO0CvqZRCwpGBqj3vzD9cpBgr F1Ahh2gRNJgaW2qEj01gS+dmNbTtAlTB9R2yzk4M049Qosdmk7ES53uAF0PWbduN4ySXUSsB vvNiwPnAEwsg7ToK+5atOr3sZ8uvvmHB/ZKV+y5dIf+ot2vdvr7c93T548pvCAAAAAAAAA== --------------ms010304080001000709030304-- From nemo-admin@ietf.org Thu Apr 1 07:59:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09926 for ; Thu, 1 Apr 2004 07:59:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91mf-00019e-Nk; Thu, 01 Apr 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91lm-00018e-GM for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09885 for ; Thu, 1 Apr 2004 07:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91ll-0006Xi-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:58:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91kl-0006T2-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:57:04 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B91jn-0006P4-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:56:03 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i31Cu2qo019638 for ; Thu, 1 Apr 2004 05:56:02 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i31Ctndl029289 for ; Thu, 1 Apr 2004 06:55:51 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3A2DD85C46E for ; Thu, 1 Apr 2004 14:55:57 +0200 (CEST) Message-ID: <406C1159.9000909@motorola.com> Date: Thu, 01 Apr 2004 14:55:53 +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: IETF NEMO WG 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="------------ms090409010709070100000306" 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 Subject: [nemo] issue 35 on syntax error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms090409010709070100000306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG Reviewier: > Section 5.4 has a lot of wording problems, not the least of which is > the frequent use of the word "should" in lower case. I'm not sure if > they want them to be SHOULD, if not I advise use of a different word, > and if so, fix it. I think all occurences of "should" in section 5.4 should be "SHOULD". Alex --------------ms090409010709070100000306 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjU1NTNaMCMGCSqGSIb3DQEJBDEWBBQjfXl7yoNEj5wXqk2FjXQ0hs+o/jBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDG5oAF4/P2Pm19ByjzM3WHsdWybvfg+6QnWNg/ 550x1oOGruTFe8XL5i2qkx4Mwsmt46i6Gnop8ZnxqxFx9iS8CdN/iQNHKh6w5lYW6yiCChh5 jMiayZwLlbj2fbRGKvuM4mEgMUFtg/swINcKDPUp/MOxgTUzRYv35yEzsTuBywAAAAAAAA== --------------ms090409010709070100000306-- From exim@www1.ietf.org Thu Apr 1 08:01:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10032 for ; Thu, 1 Apr 2004 08:01:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91oi-0001Kv-LH for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 08:01:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31D18Nx005131 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 08:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91oi-0001Kg-Hg for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 08:01:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10010 for ; Thu, 1 Apr 2004 08:01:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91oh-0006qF-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:01:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91nf-0006ih-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:00:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91mf-0006c0-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 07:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91mf-00019e-Nk; Thu, 01 Apr 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91lm-00018e-GM for nemo@optimus.ietf.org; Thu, 01 Apr 2004 07:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09885 for ; Thu, 1 Apr 2004 07:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91ll-0006Xi-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:58:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91kl-0006T2-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:57:04 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B91jn-0006P4-00 for nemo@ietf.org; Thu, 01 Apr 2004 07:56:03 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i31Cu2qo019638 for ; Thu, 1 Apr 2004 05:56:02 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i31Ctndl029289 for ; Thu, 1 Apr 2004 06:55:51 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3A2DD85C46E for ; Thu, 1 Apr 2004 14:55:57 +0200 (CEST) Message-ID: <406C1159.9000909@motorola.com> Date: Thu, 01 Apr 2004 14:55:53 +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: IETF NEMO WG 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="------------ms090409010709070100000306" Subject: [nemo] issue 35 on syntax error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms090409010709070100000306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG Reviewier: > Section 5.4 has a lot of wording problems, not the least of which is > the frequent use of the word "should" in lower case. I'm not sure if > they want them to be SHOULD, if not I advise use of a different word, > and if so, fix it. I think all occurences of "should" in section 5.4 should be "SHOULD". Alex --------------ms090409010709070100000306 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMjU1NTNaMCMGCSqGSIb3DQEJBDEWBBQjfXl7yoNEj5wXqk2FjXQ0hs+o/jBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDG5oAF4/P2Pm19ByjzM3WHsdWybvfg+6QnWNg/ 550x1oOGruTFe8XL5i2qkx4Mwsmt46i6Gnop8ZnxqxFx9iS8CdN/iQNHKh6w5lYW6yiCChh5 jMiayZwLlbj2fbRGKvuM4mEgMUFtg/swINcKDPUp/MOxgTUzRYv35yEzsTuBywAAAAAAAA== --------------ms090409010709070100000306-- From nemo-admin@ietf.org Thu Apr 1 08:09:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10403 for ; Thu, 1 Apr 2004 08:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91wK-0001xI-Tx; Thu, 01 Apr 2004 08:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91vW-0001wL-OA for nemo@optimus.ietf.org; Thu, 01 Apr 2004 08:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10277 for ; Thu, 1 Apr 2004 08:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91vV-0007Sl-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:08:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91uY-0007Nh-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:07:11 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B91to-0007Jj-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:06:24 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31D6NqY022364 for ; Thu, 1 Apr 2004 15:06:23 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 15:06:23 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQAQMQ2; Thu, 1 Apr 2004 15:06:33 +0200 Message-ID: <406C13CF.4000004@ericsson.com> Date: Thu, 01 Apr 2004 15:06:23 +0200 X-Sybari-Trust: e69dc244 272a6e05 c9bf4b46 00000139 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 13:06:23.0394 (UTC) FILETIME=[2207D020:01C417EA] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Hi Mattias, > > > > > > > I basically agree with you. I think there may be two use > > cases here with > > slightly different assumptions: > > > > 1. All MRs and HA belong to the same administrative domain. They can > > have a single trust level (domain key). > > => Agreed. > > > > > 2. MRs belong to different administrative domains or the HA > > and the MRs > > belong to different domains. Obviously they don't trust each other. > > > > In 1) it would be ok to separate BU authorization from > > routing protocol > > authorization. In 2) it wouldn't. What you propose is to > > always go with > > the assumption that entities don't trust each other and that we have > > multiple trust relationships. > > => Agreed. I was just thinking of a general HA > that might end up supporting both types of MRs > (i.e. trusted and not trusted). So unless further > configuration is done to distinguish between > the two cases the HA won't know the difference. Yeah, you wouldn't want to mix the two cases. Thinking a bit more on this; maybe what we originally intended was to allow different kinds of network configurations. In my example 1) above, the administrator would possibly want to use routing protocols _as the only mechanism_ to pass prefixes and routing information from MR to HA (and not include them in BUs). It is then up to the IGP daemon to authorize the MR and the prefixes, if need be. In 2), the administrator would possibly want to use BUs _as the only mechanism_ to pass prefixes from the MR to HA. In this case it is up to the HA function to autorize the MR and the prefixes. Now I'm not sure whether we still want to keep the specs open for such configurations. It is ultimately up to the administrator of the HA to make sure routing information is correct and that no MR steals another MR's traffic. I think my original intention was to try to keep IGP and NEMO independent. That would mean that their respective authorization would also be kept independent. Now, is that a good idea? > > > > > I'm just curious how difficult one can consider it is > > (implementation-wise) to exchange information a RIPng > > process with the > > HA function inside the HA. > > => It depends on the platform of course, but it also > depends on whether a copy of the prefix table/BCE > is available to user space processes (e.g. in a file). And all IGP protocols (or at least their implementations on NEMO-enabled routers) must be updated to be able to handle this? /Mattias From nemo-admin@ietf.org Thu Apr 1 08:10:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10491 for ; Thu, 1 Apr 2004 08:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91xI-00026e-Ts; Thu, 01 Apr 2004 08:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91wO-0001zr-UK for nemo@optimus.ietf.org; Thu, 01 Apr 2004 08:09:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10322 for ; Thu, 1 Apr 2004 08:09:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91wO-0007Zl-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91vP-0007S5-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:08:04 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B91uR-0007Mm-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:07:03 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i31D73qo002089 for ; Thu, 1 Apr 2004 06:07:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i31D65VP020171 for ; Thu, 1 Apr 2004 07:06:05 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6AD66855530 for ; Thu, 1 Apr 2004 15:06:58 +0200 (CEST) Message-ID: <406C13EC.9040003@motorola.com> Date: Thu, 01 Apr 2004 15:06:52 +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: IETF NEMO WG 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="------------ms050006030005060204090905" 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 Subject: [nemo] issue 35 on simplex and bidir tunnels Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms050006030005060204090905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG Reviewer: > In the second paragraph of 5.5 they talk about the single > bi-directional tunnel and two simplex tunnels. They need to get > their terminology straight. Ok, the 2nd par of section 5.5 is: > The bi-directional tunnel between Mobile Router and Home Agent allows > packets to flow in both directions between these entities, while the > Mobile Router is connected to a Visited Link. The bi-directional > tunnel involves two virtual links [3]: one virtual link has the > address of the tunnel entry point as the Care-of Address of the > Mobile Router and the tunnel exit point as the address of the Home > Agent; the other virtual link has as tunnel entry point the Home > Agent address and as tunnel exit point the Care-of Address of the > Mobile Router. Both addresses are unicast addresses. All IPv6 > traffic to and from the mobile network is sent through this > bi-directional tunnel. I do not know whether "simplex tunnel" is defined anywhere, I was looking for such a term. If it exists, it should be used. Maybe a terminology issue here, Thierry? Formulation could of course be improved and I suggest (I substituted "as" with "equalling" and replaced ", while" with "whenever" on 2nd line): > The bi-directional tunnel between Mobile Router and Home Agent allows > packets to flow in both directions between these entities whenever the > Mobile Router is connected to a Visited Link. The bi-directional > tunnel involves two virtual links [3]: one virtual link has the > address of the tunnel entry point equalling the Care-of Address of > the Mobile Router and the address of the tunnel exit point equalling > the address of the Home Agent; the other virtual link has the address > of the tunnel entry point equalling the Home Agent address and the > address of the tunnel exit point equalling the Care-of Address of the > Mobile Router. Both the Home Agent address and the Care-of Address > are unicast addresses. All IPv6 traffic to and from the mobile > network is sent through this bi-directional tunnel. Alex --------------ms050006030005060204090905 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMzA2NTJaMCMGCSqGSIb3DQEJBDEWBBQpoXQ5f0xH6UnetSiaKtK/cQRJRjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYADRc7nU3DL5LPmPCmYqG1TSN62qfZHALT8Fxw7 xSKLZaWHSIprIbZJru0xVXmtGI4a3etRD1ijUpAC9dTJWz6DdC7HpPPhYgCwlRO+Ia3mU4VC mar7+mt0Jf+yqG1QF//WWPN2DGiQPIjRWvR4m6OD3qiKO6hTruudbAykrc0euQAAAAAAAA== --------------ms050006030005060204090905-- From exim@www1.ietf.org Thu Apr 1 08:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10576 for ; Thu, 1 Apr 2004 08:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91yK-0002Fv-UD for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 08:11:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31DB43f008660 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 08:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91yK-0002FM-NV for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 08:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10525 for ; Thu, 1 Apr 2004 08:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91yJ-00000K-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:11:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91xK-0007gv-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:10:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91wL-0007XO-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91wK-0001xI-Tx; Thu, 01 Apr 2004 08:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91vW-0001wL-OA for nemo@optimus.ietf.org; Thu, 01 Apr 2004 08:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10277 for ; Thu, 1 Apr 2004 08:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91vV-0007Sl-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:08:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91uY-0007Nh-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:07:11 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B91to-0007Jj-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:06:24 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31D6NqY022364 for ; Thu, 1 Apr 2004 15:06:23 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 15:06:23 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQAQMQ2; Thu, 1 Apr 2004 15:06:33 +0200 Message-ID: <406C13CF.4000004@ericsson.com> Date: Thu, 01 Apr 2004 15:06:23 +0200 X-Sybari-Trust: e69dc244 272a6e05 c9bf4b46 00000139 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 13:06:23.0394 (UTC) FILETIME=[2207D020:01C417EA] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Hi Mattias, > > > > > > > I basically agree with you. I think there may be two use > > cases here with > > slightly different assumptions: > > > > 1. All MRs and HA belong to the same administrative domain. They can > > have a single trust level (domain key). > > => Agreed. > > > > > 2. MRs belong to different administrative domains or the HA > > and the MRs > > belong to different domains. Obviously they don't trust each other. > > > > In 1) it would be ok to separate BU authorization from > > routing protocol > > authorization. In 2) it wouldn't. What you propose is to > > always go with > > the assumption that entities don't trust each other and that we have > > multiple trust relationships. > > => Agreed. I was just thinking of a general HA > that might end up supporting both types of MRs > (i.e. trusted and not trusted). So unless further > configuration is done to distinguish between > the two cases the HA won't know the difference. Yeah, you wouldn't want to mix the two cases. Thinking a bit more on this; maybe what we originally intended was to allow different kinds of network configurations. In my example 1) above, the administrator would possibly want to use routing protocols _as the only mechanism_ to pass prefixes and routing information from MR to HA (and not include them in BUs). It is then up to the IGP daemon to authorize the MR and the prefixes, if need be. In 2), the administrator would possibly want to use BUs _as the only mechanism_ to pass prefixes from the MR to HA. In this case it is up to the HA function to autorize the MR and the prefixes. Now I'm not sure whether we still want to keep the specs open for such configurations. It is ultimately up to the administrator of the HA to make sure routing information is correct and that no MR steals another MR's traffic. I think my original intention was to try to keep IGP and NEMO independent. That would mean that their respective authorization would also be kept independent. Now, is that a good idea? > > > > > I'm just curious how difficult one can consider it is > > (implementation-wise) to exchange information a RIPng > > process with the > > HA function inside the HA. > > => It depends on the platform of course, but it also > depends on whether a copy of the prefix table/BCE > is available to user space processes (e.g. in a file). And all IGP protocols (or at least their implementations on NEMO-enabled routers) must be updated to be able to handle this? /Mattias From exim@www1.ietf.org Thu Apr 1 08:11:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10594 for ; Thu, 1 Apr 2004 08:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91yQ-0002HJ-Fk for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 08:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31DBAdk008753 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 08:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91yQ-0002H6-Be for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 08:11:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10557 for ; Thu, 1 Apr 2004 08:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91yP-00001D-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91xa-0007j3-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:10:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B91xI-0007e6-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 08:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91xI-00026e-Ts; Thu, 01 Apr 2004 08:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B91wO-0001zr-UK for nemo@optimus.ietf.org; Thu, 01 Apr 2004 08:09:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10322 for ; Thu, 1 Apr 2004 08:09:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B91wO-0007Zl-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B91vP-0007S5-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:08:04 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B91uR-0007Mm-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:07:03 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i31D73qo002089 for ; Thu, 1 Apr 2004 06:07:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i31D65VP020171 for ; Thu, 1 Apr 2004 07:06:05 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6AD66855530 for ; Thu, 1 Apr 2004 15:06:58 +0200 (CEST) Message-ID: <406C13EC.9040003@motorola.com> Date: Thu, 01 Apr 2004 15:06:52 +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: IETF NEMO WG 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="------------ms050006030005060204090905" Subject: [nemo] issue 35 on simplex and bidir tunnels Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms050006030005060204090905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG Reviewer: > In the second paragraph of 5.5 they talk about the single > bi-directional tunnel and two simplex tunnels. They need to get > their terminology straight. Ok, the 2nd par of section 5.5 is: > The bi-directional tunnel between Mobile Router and Home Agent allows > packets to flow in both directions between these entities, while the > Mobile Router is connected to a Visited Link. The bi-directional > tunnel involves two virtual links [3]: one virtual link has the > address of the tunnel entry point as the Care-of Address of the > Mobile Router and the tunnel exit point as the address of the Home > Agent; the other virtual link has as tunnel entry point the Home > Agent address and as tunnel exit point the Care-of Address of the > Mobile Router. Both addresses are unicast addresses. All IPv6 > traffic to and from the mobile network is sent through this > bi-directional tunnel. I do not know whether "simplex tunnel" is defined anywhere, I was looking for such a term. If it exists, it should be used. Maybe a terminology issue here, Thierry? Formulation could of course be improved and I suggest (I substituted "as" with "equalling" and replaced ", while" with "whenever" on 2nd line): > The bi-directional tunnel between Mobile Router and Home Agent allows > packets to flow in both directions between these entities whenever the > Mobile Router is connected to a Visited Link. The bi-directional > tunnel involves two virtual links [3]: one virtual link has the > address of the tunnel entry point equalling the Care-of Address of > the Mobile Router and the address of the tunnel exit point equalling > the address of the Home Agent; the other virtual link has the address > of the tunnel entry point equalling the Home Agent address and the > address of the tunnel exit point equalling the Care-of Address of the > Mobile Router. Both the Home Agent address and the Care-of Address > are unicast addresses. All IPv6 traffic to and from the mobile > network is sent through this bi-directional tunnel. Alex --------------ms050006030005060204090905 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMzA2NTJaMCMGCSqGSIb3DQEJBDEWBBQpoXQ5f0xH6UnetSiaKtK/cQRJRjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYADRc7nU3DL5LPmPCmYqG1TSN62qfZHALT8Fxw7 xSKLZaWHSIprIbZJru0xVXmtGI4a3etRD1ijUpAC9dTJWz6DdC7HpPPhYgCwlRO+Ia3mU4VC mar7+mt0Jf+yqG1QF//WWPN2DGiQPIjRWvR4m6OD3qiKO6hTruudbAykrc0euQAAAAAAAA== --------------ms050006030005060204090905-- From nemo-admin@ietf.org Thu Apr 1 15:31:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00062 for ; Thu, 1 Apr 2004 15:31:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98p5-0003rm-Hy; Thu, 01 Apr 2004 15:29:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B924U-0003sf-7B for nemo@optimus.ietf.org; Thu, 01 Apr 2004 08:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11064 for ; Thu, 1 Apr 2004 08:17:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B924I-0000iq-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:17:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B923H-0000bE-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:16:12 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B922T-0000Rr-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:15:21 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31DFQU9014563 for ; Thu, 1 Apr 2004 06:15:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i31DF4jF032404 for ; Thu, 1 Apr 2004 07:15:05 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 199CE855530 for ; Thu, 1 Apr 2004 15:15:04 +0200 (CEST) Message-ID: <406C15D2.3010408@motorola.com> Date: Thu, 01 Apr 2004 15:14:58 +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: IETF NEMO WG 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="------------ms050702070409010101020602" 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 Subject: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms050702070409010101020602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit IESG Reviewer > In the third paragraph under section 5, the wording is quite strange. > I'm not sure what they are doing without more research than I have > time for, but my guess is that they are saying at the end that under > a specific set of criteria, they are relaxing a MUST in another > document to a MAY, but they need to be clearer on the intent. The paragraph in question is: > A Mobile Router MUST implement all requirements for IPv6 Mobile > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > expected to initiate sessions of its own and behaves purely as a > router serving the mobile network most of the time, then the Route > Optimization functionality MAY be implemented. I would suggest insertion of a preceding phrase like: A Mobile IPv6 Mobile Host SHOULD implement Route Optimization [2]; however, if a Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to NEMO MR RO MAY). Alex --------------ms050702070409010101020602 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MDExMzE0NThaMCMGCSqGSIb3DQEJBDEWBBRYHqyx+g+Jt4fS81co9sH1VLhQ8TBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBxZWC9804+hMINP7LXX47dF32BYbsSTYmKx3/s rgtGniKuegAWSzDYr/H4OZB4xJkMlcr+YN3TwuEFuptnMk26llFjJhQU6RL2fU+jkuogfT0x XNJJIdCYhg/80c/AjkT1C3gChNeNjQTkJkV7LztYt1L6PWs6ySTwJYtTuA+LSQAAAAAAAA== --------------ms050702070409010101020602-- From nemo-admin@ietf.org Thu Apr 1 15:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00173 for ; Thu, 1 Apr 2004 15:31:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98q8-0005ZZ-Eg; Thu, 01 Apr 2004 15:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94ki-0000Nj-B6 for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:09:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18025 for ; Thu, 1 Apr 2004 11:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94kf-0002FS-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:09:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94jj-00029v-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:08:11 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B94io-00025x-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:07:14 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i31G7DFG018149; Thu, 1 Apr 2004 09:07:13 -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 i31G3jJV027625; Thu, 1 Apr 2004 10:03:50 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 66D9B855530; Thu, 1 Apr 2004 18:03:45 +0200 (CEST) Message-ID: <406C3D61.2070001@motorola.com> Date: Thu, 01 Apr 2004 18:03:45 +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: IETF NEMO WG Cc: smb@research.att.com X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] issue 34 about Error in error processing, nemo base draft-02 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [repost, included CC] S. Bellovin wrote: | 5.4: why is 140 not allowed in explicit mode? 6.6 implies that it | should be. True. My understanding is that the above remark comes from the following two paragraphs in draft-02: section 5.4 | If the Mobile Router sent a Binding Update to Home Agent in explict | mode then the Mobile Router interprets only the error status '141' | (Invalid Prefix) and '142' (Not Authorized for Prefix). For this | Binding Update, the Mobile Router MUST discard Binding | Acknowledgements with codes '140' and '143'. section 6.6: | If the Home Agent is configured not to support mobile routers, it | sets the status code in the Binding Acknowledgement to '140' (Mobile | Router Operation not permitted). I think, in order to solve this issue, one possibility: modify the above paragraph of section 6.6 to say that if this BAck corresponds to a BU received in implicit mode then send 140 (Mobile Router operation not permitted), otherwise send 141 (Invalid Prefix). Second possibility, modify the paragraph cited of section 5.4 to say that MR does interpret the 140 in the BAck in explicit mode too. And, if MR receives BAck 140 after having sent BU explicit, then send a similar explicit BU to another HA on the home link, and after all tried HA's and still not BAck 0, then stop. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbD1hMmC0w56zj54RAvHBAKC9FlNN9Pt1KSdqg9rASKjQdmhedgCg25+9 h3ivafV/RfW9636il5WN7AI= =GFZt -----END PGP SIGNATURE----- From nemo-admin@ietf.org Thu Apr 1 15:31:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00200 for ; Thu, 1 Apr 2004 15:31:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98qC-0005h0-BI; Thu, 01 Apr 2004 15:31:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94lf-0000QA-Th for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18068 for ; Thu, 1 Apr 2004 11:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94ld-0002Mf-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:10:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94ko-0002GZ-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:09:18 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B94jw-0002BR-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:08:24 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31G8SWO020654; Thu, 1 Apr 2004 09:08:31 -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 i31G7aRD027043; Thu, 1 Apr 2004 10:08:08 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6713885C46E; Thu, 1 Apr 2004 18:07:36 +0200 (CEST) Message-ID: <406C3E48.6010207@motorola.com> Date: Thu, 01 Apr 2004 18:07:36 +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: IETF NEMO WG Cc: harald@alvestrand.no X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] issue 35 on Error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [repost to include CC] IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): | In section 6.6 under a certain condition (which is independent of | whether implicit or explicit mode is in use) it describes sending | error status code 140. However, in the description of what a MR does | with responses in explicit mode, error code 140 implies discard | response. If the MR is going to discard it, why send it? The MR | needs to know there was a problem, so I think the fix is to make it | process these. Right. The idea of MR dropping BAck 140 in explicit mode was to have the loop stopped, I'll explain below "loop". However, since this is the third time this issue comes up, I agree with having MR process BAck 140 explicit (or have HA send BAck 141 explicit) (two different ways). Idea of "loop" was that MR starts sending BU's implicit, gets back negative BAcks, then sends BU's explicit, and if still error then stop, avoid re-starting to send BU's implicit. But this loop could still be avoided with the suggested modifciations. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbD5IMmC0w56zj54RApLoAJ9Qgad1KKYPWwZ5ADJTvBOL+VM54QCg5oIw I1zncBHxWNNohB53qwTI208= =d6eJ -----END PGP SIGNATURE----- From nemo-admin@ietf.org Thu Apr 1 15:31:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00223 for ; Thu, 1 Apr 2004 15:31:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98qD-0005jV-7t; Thu, 01 Apr 2004 15:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94me-0000Rc-Gt for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18135 for ; Thu, 1 Apr 2004 11:11:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94mb-0002UU-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94lo-0002O9-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:10:20 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B94l2-0002Ie-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:09:32 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31G9dWO022391; Thu, 1 Apr 2004 09:09:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i31G9LjF020458; Thu, 1 Apr 2004 10:09:22 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E127C855530; Thu, 1 Apr 2004 18:09:20 +0200 (CEST) Message-ID: <406C3EB0.7020504@motorola.com> Date: Thu, 01 Apr 2004 18:09:20 +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: IETF NEMO WG Cc: harald@alvestrand.no X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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.1 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] issue 35 on syntax error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Repost] IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): | Section 5.4 has a lot of wording problems, not the least of which is | the frequent use of the word "should" in lower case. I'm not sure if | they want them to be SHOULD, if not I advise use of a different word, | and if so, fix it. I think all occurences of "should" in section 5.4 should be "SHOULD". Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbD6wMmC0w56zj54RAnG+AKDfysA+AQmAy+i16dJ/LFYkemm/9gCgrARJ YieK0LUaIJo4dLw3v4qbMtI= =g6bm -----END PGP SIGNATURE----- From exim@www1.ietf.org Thu Apr 1 15:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00495 for ; Thu, 1 Apr 2004 15:33:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98sP-0001ch-4z for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 15:33:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31KXJxR005409 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 15:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98sB-0000uH-PW for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 15:33:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00375 for ; Thu, 1 Apr 2004 15:33:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98s5-00079j-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:33:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98qu-0006vy-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:31:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B98q7-0006lS-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98q8-0005ZZ-Eg; Thu, 01 Apr 2004 15:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94ki-0000Nj-B6 for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:09:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18025 for ; Thu, 1 Apr 2004 11:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94kf-0002FS-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:09:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94jj-00029v-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:08:11 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B94io-00025x-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:07:14 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i31G7DFG018149; Thu, 1 Apr 2004 09:07:13 -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 i31G3jJV027625; Thu, 1 Apr 2004 10:03:50 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 66D9B855530; Thu, 1 Apr 2004 18:03:45 +0200 (CEST) Message-ID: <406C3D61.2070001@motorola.com> Date: Thu, 01 Apr 2004 18:03:45 +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: IETF NEMO WG Cc: smb@research.att.com X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] issue 34 about Error in error processing, nemo base draft-02 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [repost, included CC] S. Bellovin wrote: | 5.4: why is 140 not allowed in explicit mode? 6.6 implies that it | should be. True. My understanding is that the above remark comes from the following two paragraphs in draft-02: section 5.4 | If the Mobile Router sent a Binding Update to Home Agent in explict | mode then the Mobile Router interprets only the error status '141' | (Invalid Prefix) and '142' (Not Authorized for Prefix). For this | Binding Update, the Mobile Router MUST discard Binding | Acknowledgements with codes '140' and '143'. section 6.6: | If the Home Agent is configured not to support mobile routers, it | sets the status code in the Binding Acknowledgement to '140' (Mobile | Router Operation not permitted). I think, in order to solve this issue, one possibility: modify the above paragraph of section 6.6 to say that if this BAck corresponds to a BU received in implicit mode then send 140 (Mobile Router operation not permitted), otherwise send 141 (Invalid Prefix). Second possibility, modify the paragraph cited of section 5.4 to say that MR does interpret the 140 in the BAck in explicit mode too. And, if MR receives BAck 140 after having sent BU explicit, then send a similar explicit BU to another HA on the home link, and after all tried HA's and still not BAck 0, then stop. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbD1hMmC0w56zj54RAvHBAKC9FlNN9Pt1KSdqg9rASKjQdmhedgCg25+9 h3ivafV/RfW9636il5WN7AI= =GFZt -----END PGP SIGNATURE----- From exim@www1.ietf.org Thu Apr 1 15:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00497 for ; Thu, 1 Apr 2004 15:33:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98sP-0001dM-Fw for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 15:33:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31KXLOd005667 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 15:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98sL-0001Dz-Bf for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 15:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00400 for ; Thu, 1 Apr 2004 15:33:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98sE-0007Av-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:33:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98r2-0006xH-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:32:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B98qB-0006m3-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98qC-0005h0-BI; Thu, 01 Apr 2004 15:31:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94lf-0000QA-Th for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18068 for ; Thu, 1 Apr 2004 11:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94ld-0002Mf-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:10:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94ko-0002GZ-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:09:18 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B94jw-0002BR-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:08:24 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31G8SWO020654; Thu, 1 Apr 2004 09:08:31 -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 i31G7aRD027043; Thu, 1 Apr 2004 10:08:08 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6713885C46E; Thu, 1 Apr 2004 18:07:36 +0200 (CEST) Message-ID: <406C3E48.6010207@motorola.com> Date: Thu, 01 Apr 2004 18:07:36 +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: IETF NEMO WG Cc: harald@alvestrand.no X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] issue 35 on Error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [repost to include CC] IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): | In section 6.6 under a certain condition (which is independent of | whether implicit or explicit mode is in use) it describes sending | error status code 140. However, in the description of what a MR does | with responses in explicit mode, error code 140 implies discard | response. If the MR is going to discard it, why send it? The MR | needs to know there was a problem, so I think the fix is to make it | process these. Right. The idea of MR dropping BAck 140 in explicit mode was to have the loop stopped, I'll explain below "loop". However, since this is the third time this issue comes up, I agree with having MR process BAck 140 explicit (or have HA send BAck 141 explicit) (two different ways). Idea of "loop" was that MR starts sending BU's implicit, gets back negative BAcks, then sends BU's explicit, and if still error then stop, avoid re-starting to send BU's implicit. But this loop could still be avoided with the suggested modifciations. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbD5IMmC0w56zj54RApLoAJ9Qgad1KKYPWwZ5ADJTvBOL+VM54QCg5oIw I1zncBHxWNNohB53qwTI208= =d6eJ -----END PGP SIGNATURE----- From exim@www1.ietf.org Thu Apr 1 16:19:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00498 for ; Thu, 1 Apr 2004 15:33:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98sP-0001dm-Jq for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 15:33:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31KXOke006126 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 15:33:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98sO-0001L8-Ft for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 15:33:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00411 for ; Thu, 1 Apr 2004 15:33:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98sG-0007CK-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:33:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98r4-0006xh-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:32:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B98qC-0006m7-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98qD-0005jV-7t; Thu, 01 Apr 2004 15:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94me-0000Rc-Gt for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18135 for ; Thu, 1 Apr 2004 11:11:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94mb-0002UU-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94lo-0002O9-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:10:20 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B94l2-0002Ie-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:09:32 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31G9dWO022391; Thu, 1 Apr 2004 09:09:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i31G9LjF020458; Thu, 1 Apr 2004 10:09:22 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E127C855530; Thu, 1 Apr 2004 18:09:20 +0200 (CEST) Message-ID: <406C3EB0.7020504@motorola.com> Date: Thu, 01 Apr 2004 18:09:20 +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: IETF NEMO WG Cc: harald@alvestrand.no X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] issue 35 on syntax error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Repost] IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): | Section 5.4 has a lot of wording problems, not the least of which is | the frequent use of the word "should" in lower case. I'm not sure if | they want them to be SHOULD, if not I advise use of a different word, | and if so, fix it. I think all occurences of "should" in section 5.4 should be "SHOULD". Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbD6wMmC0w56zj54RAnG+AKDfysA+AQmAy+i16dJ/LFYkemm/9gCgrARJ YieK0LUaIJo4dLw3v4qbMtI= =g6bm -----END PGP SIGNATURE----- From mailman-admin@ietf.org Thu Apr 1 18:13:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07452 for ; Thu, 1 Apr 2004 18:13:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99Sq-0006Fc-Gc for nemo-archive@lists.ietf.org; Thu, 01 Apr 2004 16:11:04 -0500 Date: Thu, 01 Apr 2004 11:20:03 -0500 Message-ID: <20040401162003.11029.6054.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-admin@ietf.org Thu Apr 1 18:41:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09811 for ; Thu, 1 Apr 2004 18:41:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99c2-0000r7-OH; Thu, 01 Apr 2004 16:20:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94oi-0000W0-V4 for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13449 for ; Thu, 1 Apr 2004 08:56:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92g0-0005d8-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:56:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92f7-0005WS-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:55:18 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B92ek-0005RY-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:54:54 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Apr 2004 08:54:11 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Thu, 1 Apr 2004 08:54:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQX6iNo7PhFn5ulTSeJD82wTqql8gAAwgIA From: "Soliman Hesham" To: "Mattias Pettersson" CC: "IETF NEMO WG" X-OriginalArrivalTime: 01 Apr 2004 13:54:11.0470 (UTC) FILETIME=[CF897AE0:01C417F0] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Agreed. I was just thinking of a general HA > > that might end up supporting both types of MRs > > (i.e. trusted and not trusted). So unless further > > configuration is done to distinguish between > > the two cases the HA won't know the difference. >=20 > Yeah, you wouldn't want to mix the two cases. >=20 > Thinking a bit more on this; maybe what we originally=20 > intended was to=20 > allow different kinds of network configurations. >=20 > In my example 1) above, the administrator would possibly want to use=20 > routing protocols _as the only mechanism_ to pass prefixes=20 > and routing=20 > information from MR to HA (and not include them in BUs). It=20 > is then up=20 > to the IGP daemon to authorize the MR and the prefixes, if need be. >=20 > In 2), the administrator would possibly want to use BUs _as the only=20 > mechanism_ to pass prefixes from the MR to HA. In this case=20 > it is up to=20 > the HA function to autorize the MR and the prefixes. >=20 > Now I'm not sure whether we still want to keep the specs=20 > open for such=20 > configurations. It is ultimately up to the administrator of=20 > the HA to=20 > make sure routing information is correct and that no MR=20 > steals another=20 > MR's traffic. =3D> Sure, but the admin is only limited by the tools provided by the vendor. We need to make these tradeoffs clear in the spec to allow vendors/admins to make that choice.=20 But I get the feeling that there are too many options here. Given that there are different ways of implementing the MR, and that we don't know what vendors will support, what can we do? Either always make sure that=20 the information is checked in both the routing side and the MIP side, or somehow allow for "protocol support discovery ;)" between the MR and the HA. The latter seems like an overkill. For instance suppose that company X decided not to use IGPs in their MR and company Y decided to use the IGP. Say that one method is more IPR friendly :). Now, what does the HA do? Does the admin say: "We'll support your MR if it's from a certain vendor?"=20 >=20 > I think my original intention was to try to keep IGP and NEMO=20 > independent. That would mean that their respective=20 > authorization would=20 > also be kept independent. Now, is that a good idea? =3D> I don't know if it can be done if we allow the use of an IGP. There is basically two mechanisms that are=20 used for routing: The BU and routing protocol.=20 So it seems like some kind of correlation of the information is needed. > > =3D> It depends on the platform of course, but it also > > depends on whether a copy of the prefix table/BCE > > is available to user space processes (e.g. in a file). >=20 > And all IGP protocols (or at least their implementations on=20 > NEMO-enabled=20 > routers) must be updated to be able to handle this? =3D> Looks like it, unless there is another way of handling this. But this is not unusual. I mean, look at MIPv6 and=20 how many additions it made to ND. Note that the spec also requires the BU to trigger the IGP to inject routes in=20 the case where the MR's prefix is not aggregated under=20 the HA prefix. But hopefully this is a rare event with proper configuration. The problem here is that the MR is not always part of the same admin domain. Thus, some kind of authorisation is needed for the routing messages.=20 Relying on the MIP authorisation seems like a good way to leverage existing security and minimise the amount of=20 changes required in the IGP.=20 Hesham =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=20 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 From nemo-admin@ietf.org Thu Apr 1 18:55:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10836 for ; Thu, 1 Apr 2004 18:55:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A9j-0007S4-IP; Thu, 01 Apr 2004 16:55:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Vt-0001E1-HQ for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17857 for ; Thu, 1 Apr 2004 11:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94fw-0001my-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94f5-0001hi-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:03:24 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B94eM-0001ae-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:02:38 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31G2WWO012765; Thu, 1 Apr 2004 09:02:32 -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 i31G1eRD019373; Thu, 1 Apr 2004 10:02:09 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 040CD855530; Thu, 1 Apr 2004 18:01:40 +0200 (CEST) Message-ID: <406C3CE3.3070808@motorola.com> Date: Thu, 01 Apr 2004 18:01:39 +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: IETF NEMO WG Cc: smb@research.att.com X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Section 8 comment in IESG review Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [repost, included reviewer in CC] Steve Bellovin wrote about section 8 draft-nemo-02 in IESG review: | Do you mean "be careful to include the same information in both | places" -- redunancy is sometimes good. Or do you mean "be careful | to avoid doing this"? Personally, I think the former is more | appropriate, because it allows a check on the validity of the routing | information. I also think the text should be along the lines of "careful with that prefix, include same information in both places", and not "careful to avoid doing this". | Note that the prefixes announced via binding updates are checked for | authorization; routing data generally is not. I would thus suggest | that routing advertisements MUST NOT contain any prefixes not known | to the home agent by either implicit mode configuration or explicit | mode announcement. Basically, I agree with this; this is a useful check. My preferred way to solve this potential conflicting information between the prefixes advertised by NEMO and the ones advertised by rt protocol is to have NEMO _not_ have prefixes in the BU, that is: implicit mode. Let only the rt protocol make do about prefixes. Moreover, there are at least three ways by which a host learns routes (rt protocol, icmp redirects, static config). Adding NEMO as a fourth means only complicates the picture: one wants all four means to distribute the same routing information; why not let NEMO just do the Home-Address - Care-of-Address binding. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbDzjMmC0w56zj54RAkq8AKCJm7fNadHtHQD7FSs8kfrOvSPoSACeOyQe tzxFfp/8TlNYbE7GIUADUFk= =u5UP -----END PGP SIGNATURE----- From nemo-admin@ietf.org Thu Apr 1 18:58:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10946 for ; Thu, 1 Apr 2004 18:58:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9AAn-0007YO-Nl; Thu, 01 Apr 2004 16:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95fW-0001V8-3J for nemo@optimus.ietf.org; Thu, 01 Apr 2004 12:07:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18737 for ; Thu, 1 Apr 2004 11:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94uV-0003ig-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:19:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94sa-0003HE-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:17:21 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B94qr-0002r2-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:15:33 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i31GBmxO022054; Thu, 1 Apr 2004 09:11:48 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i31GBmdl010691; Thu, 1 Apr 2004 10:12:04 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B200B855530; Thu, 1 Apr 2004 18:11:55 +0200 (CEST) Message-ID: <406C3F4B.9020804@motorola.com> Date: Thu, 01 Apr 2004 18:11:55 +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: harald@alvestrand.no Cc: IETF NEMO WG X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] issue 35 on simplex and bidir tunnels Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Repost to include the right addresses] IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): | In the second paragraph of 5.5 they talk about the single | bi-directional tunnel and two simplex tunnels. They need to get | their terminology straight. Ok, the 2nd par of section 5.5 is: | The bi-directional tunnel between Mobile Router and Home Agent allows | packets to flow in both directions between these entities, while the | Mobile Router is connected to a Visited Link. The bi-directional | tunnel involves two virtual links [3]: one virtual link has the | address of the tunnel entry point as the Care-of Address of the | Mobile Router and the tunnel exit point as the address of the Home | Agent; the other virtual link has as tunnel entry point the Home | Agent address and as tunnel exit point the Care-of Address of the | Mobile Router. Both addresses are unicast addresses. All IPv6 | traffic to and from the mobile network is sent through this | bi-directional tunnel. I do not know whether "simplex tunnel" is defined anywhere, I was looking for such a term. If it exists, it should be used. Maybe a terminology issue here, Thierry? Formulation could of course be improved and I suggest (I substituted "as" with "equalling" and replaced ", while" with "whenever" on 2nd line): | The bi-directional tunnel between Mobile Router and Home Agent allows | packets to flow in both directions between these entities whenever | the Mobile Router is connected to a Visited Link. The bi-directional | tunnel involves two virtual links [3]: one virtual link has the | address of the tunnel entry point equalling the Care-of Address of | the Mobile Router and the address of the tunnel exit point equalling | the address of the Home Agent; the other virtual link has the | address of the tunnel entry point equalling the Home Agent address | and the address of the tunnel exit point equalling the Care-of | Address of the Mobile Router. Both the Home Agent address and the | Care-of Address are unicast addresses. All IPv6 traffic to and from | the mobile network is sent through this bi-directional tunnel. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFAbD9LMmC0w56zj54RAmwhAJwL2L2iq8UzFFAxEyrEE+RZ3mWXJACXSQQf SAtWpPFXGmhvgHkqjmrIug== =sRRS -----END PGP SIGNATURE----- From exim@www1.ietf.org Thu Apr 1 23:58:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08811 for ; Thu, 1 Apr 2004 23:58:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dyu-0000fN-T7 for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 21:00:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3220Sbk002557 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 21:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Agf-0002BD-QI for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 17:29:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04851 for ; Thu, 1 Apr 2004 17:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Agd-0003Ys-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 17:29:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Afi-0003Tc-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 17:28:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Aeh-0003Ng-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 17:27:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98yG-0003U7-1x for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 15:39:28 -0500 Date: Thu, 01 Apr 2004 11:17:15 -0500 Message-ID: <20040401161715.11029.99906.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, NO_REAL_NAME autolearn=no version=2.60 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-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From exim@www1.ietf.org Fri Apr 2 01:07:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11665 for ; Fri, 2 Apr 2004 01:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E95-0005vx-NI for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 21:10:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322AxUx022807 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 21:10:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Bpo-0000hz-53 for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:42:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09919 for ; Thu, 1 Apr 2004 18:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bpk-0003dP-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Bop-0003Vy-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:41:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bo0-0003NJ-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99c2-0000r7-OH; Thu, 01 Apr 2004 16:20:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94oi-0000W0-V4 for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13449 for ; Thu, 1 Apr 2004 08:56:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92g0-0005d8-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:56:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92f7-0005WS-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:55:18 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B92ek-0005RY-00 for nemo@ietf.org; Thu, 01 Apr 2004 08:54:54 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Apr 2004 08:54:11 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Thu, 1 Apr 2004 08:54:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQX6iNo7PhFn5ulTSeJD82wTqql8gAAwgIA From: "Soliman Hesham" To: "Mattias Pettersson" CC: "IETF NEMO WG" X-OriginalArrivalTime: 01 Apr 2004 13:54:11.0470 (UTC) FILETIME=[CF897AE0:01C417F0] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > > =3D> Agreed. I was just thinking of a general HA > > that might end up supporting both types of MRs > > (i.e. trusted and not trusted). So unless further > > configuration is done to distinguish between > > the two cases the HA won't know the difference. >=20 > Yeah, you wouldn't want to mix the two cases. >=20 > Thinking a bit more on this; maybe what we originally=20 > intended was to=20 > allow different kinds of network configurations. >=20 > In my example 1) above, the administrator would possibly want to use=20 > routing protocols _as the only mechanism_ to pass prefixes=20 > and routing=20 > information from MR to HA (and not include them in BUs). It=20 > is then up=20 > to the IGP daemon to authorize the MR and the prefixes, if need be. >=20 > In 2), the administrator would possibly want to use BUs _as the only=20 > mechanism_ to pass prefixes from the MR to HA. In this case=20 > it is up to=20 > the HA function to autorize the MR and the prefixes. >=20 > Now I'm not sure whether we still want to keep the specs=20 > open for such=20 > configurations. It is ultimately up to the administrator of=20 > the HA to=20 > make sure routing information is correct and that no MR=20 > steals another=20 > MR's traffic. =3D> Sure, but the admin is only limited by the tools provided by the vendor. We need to make these tradeoffs clear in the spec to allow vendors/admins to make that choice.=20 But I get the feeling that there are too many options here. Given that there are different ways of implementing the MR, and that we don't know what vendors will support, what can we do? Either always make sure that=20 the information is checked in both the routing side and the MIP side, or somehow allow for "protocol support discovery ;)" between the MR and the HA. The latter seems like an overkill. For instance suppose that company X decided not to use IGPs in their MR and company Y decided to use the IGP. Say that one method is more IPR friendly :). Now, what does the HA do? Does the admin say: "We'll support your MR if it's from a certain vendor?"=20 >=20 > I think my original intention was to try to keep IGP and NEMO=20 > independent. That would mean that their respective=20 > authorization would=20 > also be kept independent. Now, is that a good idea? =3D> I don't know if it can be done if we allow the use of an IGP. There is basically two mechanisms that are=20 used for routing: The BU and routing protocol.=20 So it seems like some kind of correlation of the information is needed. > > =3D> It depends on the platform of course, but it also > > depends on whether a copy of the prefix table/BCE > > is available to user space processes (e.g. in a file). >=20 > And all IGP protocols (or at least their implementations on=20 > NEMO-enabled=20 > routers) must be updated to be able to handle this? =3D> Looks like it, unless there is another way of handling this. But this is not unusual. I mean, look at MIPv6 and=20 how many additions it made to ND. Note that the spec also requires the BU to trigger the IGP to inject routes in=20 the case where the MR's prefix is not aggregated under=20 the HA prefix. But hopefully this is a rare event with proper configuration. The problem here is that the MR is not always part of the same admin domain. Thus, some kind of authorisation is needed for the routing messages.=20 Relying on the MIP authorisation seems like a good way to leverage existing security and minimise the amount of=20 changes required in the IGP.=20 Hesham =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=20 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 From exim@www1.ietf.org Fri Apr 2 03:13:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27921 for ; Fri, 2 Apr 2004 03:13:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EAI-0006Tk-Cp for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 21:12:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322CEBw024899 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 21:12:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9C32-0003JL-LM for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:56:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10915 for ; Thu, 1 Apr 2004 18:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9C2z-0005E0-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:56:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9C25-00056y-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:55:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9C1h-00050m-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:55:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A9j-0007S4-IP; Thu, 01 Apr 2004 16:55:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Vt-0001E1-HQ for nemo@optimus.ietf.org; Thu, 01 Apr 2004 11:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17857 for ; Thu, 1 Apr 2004 11:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94fw-0001my-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94f5-0001hi-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:03:24 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B94eM-0001ae-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:02:38 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31G2WWO012765; Thu, 1 Apr 2004 09:02:32 -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 i31G1eRD019373; Thu, 1 Apr 2004 10:02:09 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 040CD855530; Thu, 1 Apr 2004 18:01:40 +0200 (CEST) Message-ID: <406C3CE3.3070808@motorola.com> Date: Thu, 01 Apr 2004 18:01:39 +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: IETF NEMO WG Cc: smb@research.att.com X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Section 8 comment in IESG review Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [repost, included reviewer in CC] Steve Bellovin wrote about section 8 draft-nemo-02 in IESG review: | Do you mean "be careful to include the same information in both | places" -- redunancy is sometimes good. Or do you mean "be careful | to avoid doing this"? Personally, I think the former is more | appropriate, because it allows a check on the validity of the routing | information. I also think the text should be along the lines of "careful with that prefix, include same information in both places", and not "careful to avoid doing this". | Note that the prefixes announced via binding updates are checked for | authorization; routing data generally is not. I would thus suggest | that routing advertisements MUST NOT contain any prefixes not known | to the home agent by either implicit mode configuration or explicit | mode announcement. Basically, I agree with this; this is a useful check. My preferred way to solve this potential conflicting information between the prefixes advertised by NEMO and the ones advertised by rt protocol is to have NEMO _not_ have prefixes in the BU, that is: implicit mode. Let only the rt protocol make do about prefixes. Moreover, there are at least three ways by which a host learns routes (rt protocol, icmp redirects, static config). Adding NEMO as a fourth means only complicates the picture: one wants all four means to distribute the same routing information; why not let NEMO just do the Home-Address - Care-of-Address binding. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbDzjMmC0w56zj54RAkq8AKCJm7fNadHtHQD7FSs8kfrOvSPoSACeOyQe tzxFfp/8TlNYbE7GIUADUFk= =u5UP -----END PGP SIGNATURE----- From exim@www1.ietf.org Fri Apr 2 03:14:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27947 for ; Fri, 2 Apr 2004 03:14:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EAJ-0006Uy-5s for nemo-archive@odin.ietf.org; Thu, 01 Apr 2004 21:12:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322CFs0024970 for nemo-archive@odin.ietf.org; Thu, 1 Apr 2004 21:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9C5o-0003qI-Un for nemo-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:59:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11004 for ; Thu, 1 Apr 2004 18:59:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9C5l-0005V0-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:59:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9C4q-0005Ol-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:58:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9C3z-0005Jj-00 for nemo-web-archive@ietf.org; Thu, 01 Apr 2004 18:57:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9AAn-0007YO-Nl; Thu, 01 Apr 2004 16:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95fW-0001V8-3J for nemo@optimus.ietf.org; Thu, 01 Apr 2004 12:07:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18737 for ; Thu, 1 Apr 2004 11:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94uV-0003ig-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:19:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94sa-0003HE-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:17:21 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B94qr-0002r2-00 for nemo@ietf.org; Thu, 01 Apr 2004 11:15:33 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i31GBmxO022054; Thu, 1 Apr 2004 09:11:48 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i31GBmdl010691; Thu, 1 Apr 2004 10:12:04 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B200B855530; Thu, 1 Apr 2004 18:11:55 +0200 (CEST) Message-ID: <406C3F4B.9020804@motorola.com> Date: Thu, 01 Apr 2004 18:11:55 +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: harald@alvestrand.no Cc: IETF NEMO WG X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] issue 35 on simplex and bidir tunnels Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Repost to include the right addresses] IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): | In the second paragraph of 5.5 they talk about the single | bi-directional tunnel and two simplex tunnels. They need to get | their terminology straight. Ok, the 2nd par of section 5.5 is: | The bi-directional tunnel between Mobile Router and Home Agent allows | packets to flow in both directions between these entities, while the | Mobile Router is connected to a Visited Link. The bi-directional | tunnel involves two virtual links [3]: one virtual link has the | address of the tunnel entry point as the Care-of Address of the | Mobile Router and the tunnel exit point as the address of the Home | Agent; the other virtual link has as tunnel entry point the Home | Agent address and as tunnel exit point the Care-of Address of the | Mobile Router. Both addresses are unicast addresses. All IPv6 | traffic to and from the mobile network is sent through this | bi-directional tunnel. I do not know whether "simplex tunnel" is defined anywhere, I was looking for such a term. If it exists, it should be used. Maybe a terminology issue here, Thierry? Formulation could of course be improved and I suggest (I substituted "as" with "equalling" and replaced ", while" with "whenever" on 2nd line): | The bi-directional tunnel between Mobile Router and Home Agent allows | packets to flow in both directions between these entities whenever | the Mobile Router is connected to a Visited Link. The bi-directional | tunnel involves two virtual links [3]: one virtual link has the | address of the tunnel entry point equalling the Care-of Address of | the Mobile Router and the address of the tunnel exit point equalling | the address of the Home Agent; the other virtual link has the | address of the tunnel entry point equalling the Home Agent address | and the address of the tunnel exit point equalling the Care-of | Address of the Mobile Router. Both the Home Agent address and the | Care-of Address are unicast addresses. All IPv6 traffic to and from | the mobile network is sent through this bi-directional tunnel. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFAbD9LMmC0w56zj54RAmwhAJwL2L2iq8UzFFAxEyrEE+RZ3mWXJACXSQQf SAtWpPFXGmhvgHkqjmrIug== =sRRS -----END PGP SIGNATURE----- From nemo-admin@ietf.org Fri Apr 2 09:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11114 for ; Fri, 2 Apr 2004 09:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9LHQ-0007GT-NP; Fri, 02 Apr 2004 04:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ht1-0005rn-Kt for nemo@optimus.ietf.org; Fri, 02 Apr 2004 01:10:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11722 for ; Fri, 2 Apr 2004 01:10:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hsy-0002WV-00 for nemo@ietf.org; Fri, 02 Apr 2004 01:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Hs1-0002O3-00 for nemo@ietf.org; Fri, 02 Apr 2004 01:09:38 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hr7-0002DA-00 for nemo@ietf.org; Fri, 02 Apr 2004 01:08:41 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2004 22:17:55 +0000 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i325vmtG017585; Fri, 2 Apr 2004 08:07:35 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 2 Apr 2004 07:07:14 +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] issue 35 on how MR spec is relaxed with respect to MH RO Date: Fri, 2 Apr 2004 07:07:13 +0100 Message-ID: Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQYKGlrVgjf6YLAScGNVIoM+CERsgATwDRw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "IETF NEMO WG" X-OriginalArrivalTime: 02 Apr 2004 06:07:14.0159 (UTC) FILETIME=[BE54D7F0:01C41878] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable As a router provider, I agree with the MAY. I already fought that war in Yokohama in the general case of MIPv6. There are a lot of types of devices for which RO is not necessarily wanted (clustered servers, routers, embedded devices). NEMO MRs may be implemented in PCs running applications while they serve as home gateway. But in the latter case, it is the applications that really cause the need for RO, not the NEMO support. There's nothing in the basic NEMO flows that trigger a need for RO today. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Alexandru Petrescu > Sent: jeudi 1 avril 2004 15:15 > To: IETF NEMO WG > Subject: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO >=20 > IESG Reviewer > > In the third paragraph under section 5, the wording is quite strange. > > I'm not sure what they are doing without more research than I have > > time for, but my guess is that they are saying at the end that under > > a specific set of criteria, they are relaxing a MUST in another > > document to a MAY, but they need to be clearer on the intent. >=20 > The paragraph in question is: > > A Mobile Router MUST implement all requirements for IPv6 Mobile > > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > > expected to initiate sessions of its own and behaves purely as a > > router serving the mobile network most of the time, then the Route > > Optimization functionality MAY be implemented. >=20 > I would suggest insertion of a preceding phrase like: A Mobile IPv6 > Mobile Host SHOULD implement Route Optimization [2]; however, if a > Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to NEMO > MR RO MAY). >=20 > Alex From exim@www1.ietf.org Fri Apr 2 14:48:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24733 for ; Fri, 2 Apr 2004 14:48:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S0Q-0005hx-7i for nemo-archive@odin.ietf.org; Fri, 02 Apr 2004 11:58:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Gww8h021942 for nemo-archive@odin.ietf.org; Fri, 2 Apr 2004 11:58:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Q2S-00044n-MP for nemo-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 09:52:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11146 for ; Fri, 2 Apr 2004 09:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q2Q-0001jp-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 09:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Q1i-0001dY-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 09:52:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Q0q-0001W8-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 09:51:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9LHQ-0007GT-NP; Fri, 02 Apr 2004 04:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ht1-0005rn-Kt for nemo@optimus.ietf.org; Fri, 02 Apr 2004 01:10:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11722 for ; Fri, 2 Apr 2004 01:10:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hsy-0002WV-00 for nemo@ietf.org; Fri, 02 Apr 2004 01:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Hs1-0002O3-00 for nemo@ietf.org; Fri, 02 Apr 2004 01:09:38 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hr7-0002DA-00 for nemo@ietf.org; Fri, 02 Apr 2004 01:08:41 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2004 22:17:55 +0000 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i325vmtG017585; Fri, 2 Apr 2004 08:07:35 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 2 Apr 2004 07:07:14 +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] issue 35 on how MR spec is relaxed with respect to MH RO Date: Fri, 2 Apr 2004 07:07:13 +0100 Message-ID: Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQYKGlrVgjf6YLAScGNVIoM+CERsgATwDRw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "IETF NEMO WG" X-OriginalArrivalTime: 02 Apr 2004 06:07:14.0159 (UTC) FILETIME=[BE54D7F0:01C41878] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable As a router provider, I agree with the MAY. I already fought that war in Yokohama in the general case of MIPv6. There are a lot of types of devices for which RO is not necessarily wanted (clustered servers, routers, embedded devices). NEMO MRs may be implemented in PCs running applications while they serve as home gateway. But in the latter case, it is the applications that really cause the need for RO, not the NEMO support. There's nothing in the basic NEMO flows that trigger a need for RO today. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Alexandru Petrescu > Sent: jeudi 1 avril 2004 15:15 > To: IETF NEMO WG > Subject: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO >=20 > IESG Reviewer > > In the third paragraph under section 5, the wording is quite strange. > > I'm not sure what they are doing without more research than I have > > time for, but my guess is that they are saying at the end that under > > a specific set of criteria, they are relaxing a MUST in another > > document to a MAY, but they need to be clearer on the intent. >=20 > The paragraph in question is: > > A Mobile Router MUST implement all requirements for IPv6 Mobile > > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > > expected to initiate sessions of its own and behaves purely as a > > router serving the mobile network most of the time, then the Route > > Optimization functionality MAY be implemented. >=20 > I would suggest insertion of a preceding phrase like: A Mobile IPv6 > Mobile Host SHOULD implement Route Optimization [2]; however, if a > Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to NEMO > MR RO MAY). >=20 > Alex From nemo-admin@ietf.org Fri Apr 2 16:14:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29975 for ; Fri, 2 Apr 2004 16:14:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SYO-00017b-EA; Fri, 02 Apr 2004 12:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Qqv-0007Sq-W2 for nemo@optimus.ietf.org; Fri, 02 Apr 2004 10:45:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14762 for ; Fri, 2 Apr 2004 10:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Qqp-0001SX-00 for nemo@ietf.org; Fri, 02 Apr 2004 10:44:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Qpw-0001LJ-00 for nemo@ietf.org; Fri, 02 Apr 2004 10:44:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B9QpP-0001DK-00 for nemo@ietf.org; Fri, 02 Apr 2004 10:43:31 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 10:42:54 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Fri, 2 Apr 2004 10:42:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQYwcHAJPtXE6uqShS95d6e8WEnlAABfQ5g From: "Soliman Hesham" To: "IETF NEMO WG" X-OriginalArrivalTime: 02 Apr 2004 15:42:54.0949 (UTC) FILETIME=[2A3F2150:01C418C9] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I'm trying to understand the need for this statement at all. If RO is implemented it's implemented in the=20 context of host mobility (read: nothing to do with nemo). In this case the MR looks like a host and should follow MIPv6 in this context.=20 So why is this statement needed at all, independently of whether it's a should or may? Hesham > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Alexandru Petrescu > > Sent: jeudi 1 avril 2004 15:15 > > To: IETF NEMO WG > > Subject: [nemo] issue 35 on how MR spec is relaxed with=20 > respect to MH > RO > >=20 > > IESG Reviewer > > > In the third paragraph under section 5, the wording is quite > strange. > > > I'm not sure what they are doing without more research=20 > than I have > > > time for, but my guess is that they are saying at the=20 > end that under > > > a specific set of criteria, they are relaxing a MUST in another > > > document to a MAY, but they need to be clearer on the intent. > >=20 > > The paragraph in question is: > > > A Mobile Router MUST implement all requirements for IPv6 Mobile > > > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > > > expected to initiate sessions of its own and behaves purely as a > > > router serving the mobile network most of the time, then=20 > the Route > > > Optimization functionality MAY be implemented. > >=20 > > I would suggest insertion of a preceding phrase like: A Mobile IPv6 > > Mobile Host SHOULD implement Route Optimization [2]; however, if a > > Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to > NEMO > > MR RO MAY). > >=20 > > Alex >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=20 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 From nemo-admin@ietf.org Fri Apr 2 16:37:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02195 for ; Fri, 2 Apr 2004 16:37:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLl-00060R-WE; Fri, 02 Apr 2004 16:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UJt-00074s-Pu for nemo@optimus.ietf.org; Fri, 02 Apr 2004 14:27:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23347 for ; Fri, 2 Apr 2004 14:27:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UJr-0001Fo-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:27:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UIq-00018Q-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:26:09 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B9UIN-00011L-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:25:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32JP7X18382; Fri, 2 Apr 2004 11:25:07 -0800 X-mProtect: <200404021925> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwlopUA; Fri, 02 Apr 2004 11:25:05 PST Message-ID: <406DC180.9090107@iprg.nokia.com> Date: Fri, 02 Apr 2004 11:39:44 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > I saw Steve Bellovin's comment on this section below. > Since I've been wanting to raise the same point, I have > a short comment. > > 8: This text is unclear: > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router > should be careful in including the same Mobile Network > Prefixes in the Binding Update to the Home Agent and in > the routing protocol updates. The Home Agent depending > on its configuration might not add routes based on the > prefix information in the Binding Updates at all, and > might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > > Do you mean "be careful to include the same information in > both places" -- redunancy is sometimes good. Or do you > mean "be careful to avoid doing this"? Personally, I think > the former is more appropriate, because it allows a check > on the validity of the routing information. Note that the > prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus > suggest that routing advertisements MUST NOT contain any > prefixes not known to the home agent by either implicit > mode configuration or explicit mode announcement. > > => Basically I think we need to make sure that the HA > checks the routing information exchanged and matches it > against the prefix information that it already knows from > the MNP table/manual config/BCEs ..etc to make sure that > MRs are authorised to advertise such prefix(es). > So we need tight coupling between the routing protocol > content and the content in the BU/manual config. > Otherwise Bad Guy could send a vaild BU and start announcing > someone else's prefix. we actually wanted to avoid exactly this kind of tight coupling between running an IGP and NEMO basic support protocol. consider two fixed routers running an IGP inside a domain. is it possible for one router to advertise routes to prefixes that it acutally does not own? if yes, I dont think we need to fix it in NEMO if a mobile router lies to its Home Agent. if no, use the same mechanism that is used in the domain for verification also between the mobile router and the home agent. the bi-directional tunnel between the MR and the HA actually extends the IGP domain to include the MR. thats all. NEMO basic support protocol only creates the bi-directional tunnel (and few more things). we dont want NEMO to do the verification for routing protocol updates. comments? Vijay > > Note that in many cases today IGPs are authenticated with > a single "domain key". To maintain this type of security > we need to verify that the MRs are authorised to advertise > reachability to the prefixes in question. > > I think a text change for this section will suffice. > > Hesham > > > > ======================================================== > 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. > ======================================================== > > From nemo-admin@ietf.org Fri Apr 2 16:37:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02237 for ; Fri, 2 Apr 2004 16:37:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLo-00062v-Ia; Fri, 02 Apr 2004 16:37:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UPa-0007Gp-0S for nemo@optimus.ietf.org; Fri, 02 Apr 2004 14:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23577 for ; Fri, 2 Apr 2004 14:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UPX-00024P-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UOY-0001x0-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:32:03 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B9UNZ-0001iz-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:31:01 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32JURw27505; Fri, 2 Apr 2004 11:30:27 -0800 X-mProtect: <200404021930> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWWKWyy; Fri, 02 Apr 2004 11:30:20 PST Message-ID: <406DC2BB.50507@iprg.nokia.com> Date: Fri, 02 Apr 2004 11:44:59 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson CC: Soliman Hesham , IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: <406C13CF.4000004@ericsson.com> In-Reply-To: <406C13CF.4000004@ericsson.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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > Thinking a bit more on this; maybe what we originally intended was to > allow different kinds of network configurations. > > In my example 1) above, the administrator would possibly want to use > routing protocols _as the only mechanism_ to pass prefixes and routing > information from MR to HA (and not include them in BUs). It is then up > to the IGP daemon to authorize the MR and the prefixes, if need be. > > In 2), the administrator would possibly want to use BUs _as the only > mechanism_ to pass prefixes from the MR to HA. In this case it is up to > the HA function to autorize the MR and the prefixes. > > Now I'm not sure whether we still want to keep the specs open for such > configurations. It is ultimately up to the administrator of the HA to > make sure routing information is correct and that no MR steals another > MR's traffic. > > I think my original intention was to try to keep IGP and NEMO > independent. That would mean that their respective authorization would > also be kept independent. Now, is that a good idea? exactly. I prefer not mixing them up at all. if there is sufficient trust between the MR and HA and they are configured to exchange routing updates, just do that. nothing for NEMO to do here. NEMO only creates the bi-directional tunnel (and few other things). if IGP cannot be run, the MR includes prefixes in binding update in explicit mode. Vijay From exim@www1.ietf.org Fri Apr 2 17:00:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05480 for ; Fri, 2 Apr 2004 17:00:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wi1-00025V-6Y for nemo-archive@odin.ietf.org; Fri, 02 Apr 2004 17:00:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32M0HFs008025 for nemo-archive@odin.ietf.org; Fri, 2 Apr 2004 17:00:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wi0-00025A-Ns for nemo-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05320 for ; Fri, 2 Apr 2004 17:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Why-00039b-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 17:00:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WeD-0002GB-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 16:56:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wad-0001Ld-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:39 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WLq-0007bX-Hv for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 16:37:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLm-000615-GP; Fri, 02 Apr 2004 16:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UJu-00074u-Dw for nemo@optimus.ietf.org; Fri, 02 Apr 2004 14:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23350 for ; Fri, 2 Apr 2004 14:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UJr-0001Fv-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:27:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UIr-00018Y-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:26:10 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B9UIX-00011O-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:25:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32JPCi18730; Fri, 2 Apr 2004 11:25:12 -0800 X-mProtect: <200404021925> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdP0imAi; Fri, 02 Apr 2004 11:25:08 PST Message-ID: <406DC182.4010201@iprg.nokia.com> Date: Fri, 02 Apr 2004 11:39:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson CC: Soliman Hesham , IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: <406BD324.3030001@ericsson.com> In-Reply-To: <406BD324.3030001@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > Hi Hesham, > > Soliman Hesham wrote: > >> I saw Steve Bellovin's comment on this section below. >> Since I've been wanting to raise the same point, I have a short comment. >> >> 8: This text is unclear: >> >> When the Mobile Router and the Home Agent exchange routes >> through a dynamic routing protocol, the Mobile Router >> should be careful in including the same Mobile Network >> Prefixes in the Binding Update to the Home Agent and in >> the routing protocol updates. The Home Agent depending >> on its configuration might not add routes based on the >> prefix information in the Binding Updates at all, and >> might use only the routing protocol updates. Moreover, >> including the same prefix information in both the Binding >> Update and the routing protocol update is redundant. >> >> Do you mean "be careful to include the same information in >> both places" -- redunancy is sometimes good. Or do you >> mean "be careful to avoid doing this"? Personally, I think >> the former is more appropriate, because it allows a check >> on the validity of the routing information. Note that the >> prefixes announced via binding updates are checked for >> authorization; routing data generally is not. I would thus >> suggest that routing advertisements MUST NOT contain any >> prefixes not known to the home agent by either implicit >> mode configuration or explicit mode announcement. >> >> => Basically I think we need to make sure that the HA >> checks the routing information exchanged and matches it against the >> prefix information that it already knows from >> the MNP table/manual config/BCEs ..etc to make sure that >> MRs are authorised to advertise such prefix(es). So we need tight >> coupling between the routing protocol >> content and the content in the BU/manual config. >> Otherwise Bad Guy could send a vaild BU and start announcing >> someone else's prefix. >> Note that in many cases today IGPs are authenticated with >> a single "domain key". To maintain this type of security >> we need to verify that the MRs are authorised to advertise >> reachability to the prefixes in question. >> I think a text change for this section will suffice. > > > I basically agree with you. I think there may be two use cases here with > slightly different assumptions: > > 1. All MRs and HA belong to the same administrative domain. They can > have a single trust level (domain key). > > 2. MRs belong to different administrative domains or the HA and the MRs > belong to different domains. Obviously they don't trust each other. > > In 1) it would be ok to separate BU authorization from routing protocol > authorization. In 2) it wouldn't. What you propose is to always go with > the assumption that entities don't trust each other and that we have > multiple trust relationships. I would rather not run a routing protocol at all between MR and HA in case there isnt sufficient trust between the MR and the HA. we can make this more explicit if needed in the NEMO basic support spec. Vijay From exim@www1.ietf.org Fri Apr 2 17:10:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06899 for ; Fri, 2 Apr 2004 17:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WrG-000667-Jr for nemo-archive@odin.ietf.org; Fri, 02 Apr 2004 17:09:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32M9oNd023437 for nemo-archive@odin.ietf.org; Fri, 2 Apr 2004 17:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W3c-0006A3-2r for nemo-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:18:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00591 for ; Fri, 2 Apr 2004 16:18:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9W3a-0002rr-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 16:18:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9W2G-0002SW-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 16:17:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Vzh-0001x6-00 for nemo-web-archive@ietf.org; Fri, 02 Apr 2004 16:14:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SYO-00017b-EA; Fri, 02 Apr 2004 12:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Qqv-0007Sq-W2 for nemo@optimus.ietf.org; Fri, 02 Apr 2004 10:45:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14762 for ; Fri, 2 Apr 2004 10:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Qqp-0001SX-00 for nemo@ietf.org; Fri, 02 Apr 2004 10:44:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Qpw-0001LJ-00 for nemo@ietf.org; Fri, 02 Apr 2004 10:44:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B9QpP-0001DK-00 for nemo@ietf.org; Fri, 02 Apr 2004 10:43:31 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 10:42:54 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Fri, 2 Apr 2004 10:42:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQYwcHAJPtXE6uqShS95d6e8WEnlAABfQ5g From: "Soliman Hesham" To: "IETF NEMO WG" X-OriginalArrivalTime: 02 Apr 2004 15:42:54.0949 (UTC) FILETIME=[2A3F2150:01C418C9] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable I'm trying to understand the need for this statement at all. If RO is implemented it's implemented in the=20 context of host mobility (read: nothing to do with nemo). In this case the MR looks like a host and should follow MIPv6 in this context.=20 So why is this statement needed at all, independently of whether it's a should or may? Hesham > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Alexandru Petrescu > > Sent: jeudi 1 avril 2004 15:15 > > To: IETF NEMO WG > > Subject: [nemo] issue 35 on how MR spec is relaxed with=20 > respect to MH > RO > >=20 > > IESG Reviewer > > > In the third paragraph under section 5, the wording is quite > strange. > > > I'm not sure what they are doing without more research=20 > than I have > > > time for, but my guess is that they are saying at the=20 > end that under > > > a specific set of criteria, they are relaxing a MUST in another > > > document to a MAY, but they need to be clearer on the intent. > >=20 > > The paragraph in question is: > > > A Mobile Router MUST implement all requirements for IPv6 Mobile > > > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > > > expected to initiate sessions of its own and behaves purely as a > > > router serving the mobile network most of the time, then=20 > the Route > > > Optimization functionality MAY be implemented. > >=20 > > I would suggest insertion of a preceding phrase like: A Mobile IPv6 > > Mobile Host SHOULD implement Route Optimization [2]; however, if a > > Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to > NEMO > > MR RO MAY). > >=20 > > Alex >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=20 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 From nemo-admin@ietf.org Fri Apr 2 17:24:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02208 for ; Fri, 2 Apr 2004 16:37:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WLm-000615-GP; Fri, 02 Apr 2004 16:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UJu-00074u-Dw for nemo@optimus.ietf.org; Fri, 02 Apr 2004 14:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23350 for ; Fri, 2 Apr 2004 14:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UJr-0001Fv-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:27:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UIr-00018Y-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:26:10 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B9UIX-00011O-00 for nemo@ietf.org; Fri, 02 Apr 2004 14:25:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i32JPCi18730; Fri, 2 Apr 2004 11:25:12 -0800 X-mProtect: <200404021925> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdP0imAi; Fri, 02 Apr 2004 11:25:08 PST Message-ID: <406DC182.4010201@iprg.nokia.com> Date: Fri, 02 Apr 2004 11:39:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson CC: Soliman Hesham , IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: <406BD324.3030001@ericsson.com> In-Reply-To: <406BD324.3030001@ericsson.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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > Hi Hesham, > > Soliman Hesham wrote: > >> I saw Steve Bellovin's comment on this section below. >> Since I've been wanting to raise the same point, I have a short comment. >> >> 8: This text is unclear: >> >> When the Mobile Router and the Home Agent exchange routes >> through a dynamic routing protocol, the Mobile Router >> should be careful in including the same Mobile Network >> Prefixes in the Binding Update to the Home Agent and in >> the routing protocol updates. The Home Agent depending >> on its configuration might not add routes based on the >> prefix information in the Binding Updates at all, and >> might use only the routing protocol updates. Moreover, >> including the same prefix information in both the Binding >> Update and the routing protocol update is redundant. >> >> Do you mean "be careful to include the same information in >> both places" -- redunancy is sometimes good. Or do you >> mean "be careful to avoid doing this"? Personally, I think >> the former is more appropriate, because it allows a check >> on the validity of the routing information. Note that the >> prefixes announced via binding updates are checked for >> authorization; routing data generally is not. I would thus >> suggest that routing advertisements MUST NOT contain any >> prefixes not known to the home agent by either implicit >> mode configuration or explicit mode announcement. >> >> => Basically I think we need to make sure that the HA >> checks the routing information exchanged and matches it against the >> prefix information that it already knows from >> the MNP table/manual config/BCEs ..etc to make sure that >> MRs are authorised to advertise such prefix(es). So we need tight >> coupling between the routing protocol >> content and the content in the BU/manual config. >> Otherwise Bad Guy could send a vaild BU and start announcing >> someone else's prefix. >> Note that in many cases today IGPs are authenticated with >> a single "domain key". To maintain this type of security >> we need to verify that the MRs are authorised to advertise >> reachability to the prefixes in question. >> I think a text change for this section will suffice. > > > I basically agree with you. I think there may be two use cases here with > slightly different assumptions: > > 1. All MRs and HA belong to the same administrative domain. They can > have a single trust level (domain key). > > 2. MRs belong to different administrative domains or the HA and the MRs > belong to different domains. Obviously they don't trust each other. > > In 1) it would be ok to separate BU authorization from routing protocol > authorization. In 2) it wouldn't. What you propose is to always go with > the assumption that entities don't trust each other and that we have > multiple trust relationships. I would rather not run a routing protocol at all between MR and HA in case there isnt sufficient trust between the MR and the HA. we can make this more explicit if needed in the NEMO basic support spec. Vijay From nemo-admin@ietf.org Sat Apr 3 02:25:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10685 for ; Sat, 3 Apr 2004 02:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9fWX-0005I1-UJ; Sat, 03 Apr 2004 02:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9fWH-000592-BX for nemo@optimus.ietf.org; Sat, 03 Apr 2004 02:24:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10670 for ; Sat, 3 Apr 2004 02:24:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9fWD-0000bm-00 for nemo@ietf.org; Sat, 03 Apr 2004 02:24:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9fVQ-0000Tz-00 for nemo@ietf.org; Sat, 03 Apr 2004 02:23:53 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B9fUZ-0000Cm-00 for nemo@ietf.org; Sat, 03 Apr 2004 02:22:59 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 3 Apr 2004 02:22:18 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Sat, 3 Apr 2004 02:22:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review Thread-Index: AcQY6DcdNtqNtXgpT1asXpvHa+78uQAYho9Q From: "Soliman Hesham" To: "Vijay Devarapalli" CC: "IETF NEMO WG" X-OriginalArrivalTime: 03 Apr 2004 07:22:18.0648 (UTC) FILETIME=[65A11180:01C4194C] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Basically I think we need to make sure that the HA > > checks the routing information exchanged and matches it=20 > > against the prefix information that it already knows from > > the MNP table/manual config/BCEs ..etc to make sure that > > MRs are authorised to advertise such prefix(es).=20 > > So we need tight coupling between the routing protocol > > content and the content in the BU/manual config. > > Otherwise Bad Guy could send a vaild BU and start announcing > > someone else's prefix.=20 >=20 > we actually wanted to avoid exactly this kind of tight > coupling between running an IGP and NEMO basic support > protocol. =3D> That intention is reflected in the current text. >=20 > consider two fixed routers running an IGP inside a > domain. is it possible for one router to advertise routes > to prefixes that it acutally does not own? if yes, I > dont think we need to fix it in NEMO if a mobile router > lies to its Home Agent.=20 =3D> But this is not a fair comparison. Today routers will only do that due to misconfiguration. All routers in the same domain trust each other. However, this trust=20 could not be assumed in the case where the MR does not belong to the same admin domain.=20 > the bi-directional tunnel between the MR and the HA > actually extends the IGP domain to include the MR. thats > all.=20 =3D> I don't think that's the point. The point is whether the two nodes trust each other because they're under the same admin domain.=20 NEMO basic support protocol only creates the > bi-directional tunnel (and few more things). we dont want > NEMO to do the verification for routing protocol updates. =3D> I don't think we can get away with saying that=20 "we don't want to do this". If the WG decides that this=20 should not be done, then the draft MUST state that: "In the case where the MR and the Home Agent are not under the same administrative domain, the MR MUST not run=20 a routing protocol to the Home Agent".=20 I think this will avoid any ambiguity. But I don't know if this is what the WG wants. Hesham =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=20 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 From exim@www1.ietf.org Sat Apr 3 02:27:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10785 for ; Sat, 3 Apr 2004 02:27:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9fYe-0006Hp-9F for nemo-archive@odin.ietf.org; Sat, 03 Apr 2004 02:27:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i337RC1x024074 for nemo-archive@odin.ietf.org; Sat, 3 Apr 2004 02:27:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9fYc-0006Fd-Dh for nemo-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 02:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10765 for ; Sat, 3 Apr 2004 02:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9fY3-0000r7-00 for nemo-web-archive@ietf.org; Sat, 03 Apr 2004 02:26:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9fXD-0000k8-00 for nemo-web-archive@ietf.org; Sat, 03 Apr 2004 02:25:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9fWY-0000cH-00 for nemo-web-archive@ietf.org; Sat, 03 Apr 2004 02:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9fWX-0005I1-UJ; Sat, 03 Apr 2004 02:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9fWH-000592-BX for nemo@optimus.ietf.org; Sat, 03 Apr 2004 02:24:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10670 for ; Sat, 3 Apr 2004 02:24:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9fWD-0000bm-00 for nemo@ietf.org; Sat, 03 Apr 2004 02:24:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9fVQ-0000Tz-00 for nemo@ietf.org; Sat, 03 Apr 2004 02:23:53 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B9fUZ-0000Cm-00 for nemo@ietf.org; Sat, 03 Apr 2004 02:22:59 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 3 Apr 2004 02:22:18 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Sat, 3 Apr 2004 02:22:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review Thread-Index: AcQY6DcdNtqNtXgpT1asXpvHa+78uQAYho9Q From: "Soliman Hesham" To: "Vijay Devarapalli" CC: "IETF NEMO WG" X-OriginalArrivalTime: 03 Apr 2004 07:22:18.0648 (UTC) FILETIME=[65A11180:01C4194C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > > =3D> Basically I think we need to make sure that the HA > > checks the routing information exchanged and matches it=20 > > against the prefix information that it already knows from > > the MNP table/manual config/BCEs ..etc to make sure that > > MRs are authorised to advertise such prefix(es).=20 > > So we need tight coupling between the routing protocol > > content and the content in the BU/manual config. > > Otherwise Bad Guy could send a vaild BU and start announcing > > someone else's prefix.=20 >=20 > we actually wanted to avoid exactly this kind of tight > coupling between running an IGP and NEMO basic support > protocol. =3D> That intention is reflected in the current text. >=20 > consider two fixed routers running an IGP inside a > domain. is it possible for one router to advertise routes > to prefixes that it acutally does not own? if yes, I > dont think we need to fix it in NEMO if a mobile router > lies to its Home Agent.=20 =3D> But this is not a fair comparison. Today routers will only do that due to misconfiguration. All routers in the same domain trust each other. However, this trust=20 could not be assumed in the case where the MR does not belong to the same admin domain.=20 > the bi-directional tunnel between the MR and the HA > actually extends the IGP domain to include the MR. thats > all.=20 =3D> I don't think that's the point. The point is whether the two nodes trust each other because they're under the same admin domain.=20 NEMO basic support protocol only creates the > bi-directional tunnel (and few more things). we dont want > NEMO to do the verification for routing protocol updates. =3D> I don't think we can get away with saying that=20 "we don't want to do this". If the WG decides that this=20 should not be done, then the draft MUST state that: "In the case where the MR and the Home Agent are not under the same administrative domain, the MR MUST not run=20 a routing protocol to the Home Agent".=20 I think this will avoid any ambiguity. But I don't know if this is what the WG wants. Hesham =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=20 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 From nemo-admin@ietf.org Mon Apr 5 04:21:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16906 for ; Mon, 5 Apr 2004 04:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPLq-0001eW-Ic; Mon, 05 Apr 2004 04:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPLM-0001d6-H8 for nemo@optimus.ietf.org; Mon, 05 Apr 2004 04:20: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 EAA16892 for ; Mon, 5 Apr 2004 04:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPLJ-0005Ih-00 for nemo@ietf.org; Mon, 05 Apr 2004 04:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPKf-0005AZ-00 for nemo@ietf.org; Mon, 05 Apr 2004 04:19:50 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BAPJX-0004yH-00 for nemo@ietf.org; Mon, 05 Apr 2004 04:18:39 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i358IdPA007011 for ; Mon, 5 Apr 2004 10:18:40 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 10:18:39 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FB0BMK; Mon, 5 Apr 2004 10:19:25 +0200 Message-ID: <4071165E.10104@ericsson.com> Date: Mon, 05 Apr 2004 10:18:38 +0200 X-Sybari-Trust: 7ac7229e 2c4885b5 68d4687d 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2004 08:18:39.0587 (UTC) FILETIME=[99A6EB30:01C41AE6] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > the bi-directional tunnel between the MR and the HA > > actually extends the IGP domain to include the MR. thats > > all. > > => I don't think that's the point. The point is whether > the two nodes trust each other because they're under > the same admin domain. > > NEMO basic support protocol only creates the > > bi-directional tunnel (and few more things). we dont want > > NEMO to do the verification for routing protocol updates. > > => I don't think we can get away with saying that > "we don't want to do this". If the WG decides that this > should not be done, then the draft MUST state that: > "In the case where the MR and the Home Agent are not under > the same administrative domain, the MR MUST not run > a routing protocol to the Home Agent". > > I think this will avoid any ambiguity. But I don't know > if this is what the WG wants. Asking this question: does IGP fill an important role in the scenario where MRs and HA belong to different domains and MRs don't trust each other? IGP doesn't fit into that model. So would any sane admin allow that to be used? I think Vijay summarized it well with: "if there is sufficient trust between the MR and HA and they are configured to exchange routing updates, just do that. nothing for NEMO to do here. NEMO only creates the bi-directional tunnel (and few other things). if IGP cannot be run, the MR includes prefixes in binding update in explicit mode. " I would be happy with your statement above, Hesham. I would also like to hear from any implementor whether they have included IGP (dynamic routing) in their prototypes and what they think whether or not tying NEMO to IGP is considered a simple thing to do. /Mattias From exim@www1.ietf.org Mon Apr 5 04:36:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17506 for ; Mon, 5 Apr 2004 04:36:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPai-00043e-MX for nemo-archive@odin.ietf.org; Mon, 05 Apr 2004 04:36:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i358aO29015599 for nemo-archive@odin.ietf.org; Mon, 5 Apr 2004 04:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPai-00043V-14 for nemo-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 04:36:24 -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 EAA17445 for ; Mon, 5 Apr 2004 04:36:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPaf-00077k-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 04:36:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPZl-0006z7-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 04:35:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPYb-0006nH-07 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 04:34:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPLq-0001eW-Ic; Mon, 05 Apr 2004 04:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPLM-0001d6-H8 for nemo@optimus.ietf.org; Mon, 05 Apr 2004 04:20: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 EAA16892 for ; Mon, 5 Apr 2004 04:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPLJ-0005Ih-00 for nemo@ietf.org; Mon, 05 Apr 2004 04:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPKf-0005AZ-00 for nemo@ietf.org; Mon, 05 Apr 2004 04:19:50 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BAPJX-0004yH-00 for nemo@ietf.org; Mon, 05 Apr 2004 04:18:39 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i358IdPA007011 for ; Mon, 5 Apr 2004 10:18:40 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Apr 2004 10:18:39 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FB0BMK; Mon, 5 Apr 2004 10:19:25 +0200 Message-ID: <4071165E.10104@ericsson.com> Date: Mon, 05 Apr 2004 10:18:38 +0200 X-Sybari-Trust: 7ac7229e 2c4885b5 68d4687d 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: IETF NEMO WG Subject: Re: [nemo] Section 8 comment in IESG review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2004 08:18:39.0587 (UTC) FILETIME=[99A6EB30:01C41AE6] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > the bi-directional tunnel between the MR and the HA > > actually extends the IGP domain to include the MR. thats > > all. > > => I don't think that's the point. The point is whether > the two nodes trust each other because they're under > the same admin domain. > > NEMO basic support protocol only creates the > > bi-directional tunnel (and few more things). we dont want > > NEMO to do the verification for routing protocol updates. > > => I don't think we can get away with saying that > "we don't want to do this". If the WG decides that this > should not be done, then the draft MUST state that: > "In the case where the MR and the Home Agent are not under > the same administrative domain, the MR MUST not run > a routing protocol to the Home Agent". > > I think this will avoid any ambiguity. But I don't know > if this is what the WG wants. Asking this question: does IGP fill an important role in the scenario where MRs and HA belong to different domains and MRs don't trust each other? IGP doesn't fit into that model. So would any sane admin allow that to be used? I think Vijay summarized it well with: "if there is sufficient trust between the MR and HA and they are configured to exchange routing updates, just do that. nothing for NEMO to do here. NEMO only creates the bi-directional tunnel (and few other things). if IGP cannot be run, the MR includes prefixes in binding update in explicit mode. " I would be happy with your statement above, Hesham. I would also like to hear from any implementor whether they have included IGP (dynamic routing) in their prototypes and what they think whether or not tying NEMO to IGP is considered a simple thing to do. /Mattias From nemo-admin@ietf.org Mon Apr 5 06:29:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20857 for ; Mon, 5 Apr 2004 06:29:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARLn-0002n5-FG; Mon, 05 Apr 2004 06:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAQEk-0001A3-EP for nemo@optimus.ietf.org; Mon, 05 Apr 2004 05:17:46 -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 FAA18616 for ; Mon, 5 Apr 2004 05:17:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAQEh-0003wb-00 for nemo@ietf.org; Mon, 05 Apr 2004 05:17:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAQDZ-0003nV-00 for nemo@ietf.org; Mon, 05 Apr 2004 05:16:33 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BAQD6-0003ez-00 for nemo@ietf.org; Mon, 05 Apr 2004 05:16:05 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 05:15:33 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Mon, 5 Apr 2004 05:15:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review Thread-Index: AcQa5pyZtJ2TFbFKTwi2qtus6B4CogAAQ4CQ From: "Soliman Hesham" To: "Mattias Pettersson" CC: "IETF NEMO WG" X-OriginalArrivalTime: 05 Apr 2004 09:15:33.0356 (UTC) FILETIME=[8C6ABAC0:01C41AEE] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable =20 > > =3D> I don't think we can get away with saying that=20 > > "we don't want to do this". If the WG decides that this=20 > > should not be done, then the draft MUST state that: > > "In the case where the MR and the Home Agent are not under > > the same administrative domain, the MR MUST not run=20 > > a routing protocol to the Home Agent".=20 > >=20 > > I think this will avoid any ambiguity. But I don't know > > if this is what the WG wants. >=20 > Asking this question: does IGP fill an important role in the=20 > scenario=20 > where MRs and HA belong to different domains and MRs don't=20 > trust each=20 > other? IGP doesn't fit into that model. So would any sane=20 > admin allow=20 > that to be used? =3D> I consider myself sane and I wouldn't want to use IGPs in this scenario ;) >=20 > I think Vijay summarized it well with: > "if there is sufficient trust between the MR and HA and they are > configured to exchange routing updates, just do that. nothing > for NEMO to do here. NEMO only creates the bi-directional tunnel > (and few other things). >=20 > if IGP cannot be run, the MR includes prefixes in binding update > in explicit mode. " >=20 > I would be happy with your statement above, Hesham. =3D> Ok. I'm also fine with Vijay's "sufficient trust" part.=20 So something along those lines is ok with me. Hesham =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=20 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 From exim@www1.ietf.org Mon Apr 5 06:48:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22491 for ; Mon, 5 Apr 2004 06:48:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAReZ-0006lJ-UX for nemo-archive@odin.ietf.org; Mon, 05 Apr 2004 06:48:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35AmVbZ025979 for nemo-archive@odin.ietf.org; Mon, 5 Apr 2004 06:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAReZ-0006ke-P6 for nemo-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 06:48:31 -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 GAA22401 for ; Mon, 5 Apr 2004 06:48:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAReV-0007T1-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 06:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BARcq-00075K-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 06:46:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BARau-0006Yn-01 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 06:44:44 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BARLs-0001Ia-QG for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 06:29:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BARLn-0002n5-FG; Mon, 05 Apr 2004 06:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAQEk-0001A3-EP for nemo@optimus.ietf.org; Mon, 05 Apr 2004 05:17:46 -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 FAA18616 for ; Mon, 5 Apr 2004 05:17:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAQEh-0003wb-00 for nemo@ietf.org; Mon, 05 Apr 2004 05:17:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAQDZ-0003nV-00 for nemo@ietf.org; Mon, 05 Apr 2004 05:16:33 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BAQD6-0003ez-00 for nemo@ietf.org; Mon, 05 Apr 2004 05:16:05 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 05:15:33 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [nemo] Section 8 comment in IESG review Date: Mon, 5 Apr 2004 05:15:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Section 8 comment in IESG review Thread-Index: AcQa5pyZtJ2TFbFKTwi2qtus6B4CogAAQ4CQ From: "Soliman Hesham" To: "Mattias Pettersson" CC: "IETF NEMO WG" X-OriginalArrivalTime: 05 Apr 2004 09:15:33.0356 (UTC) FILETIME=[8C6ABAC0:01C41AEE] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable =20 > > =3D> I don't think we can get away with saying that=20 > > "we don't want to do this". If the WG decides that this=20 > > should not be done, then the draft MUST state that: > > "In the case where the MR and the Home Agent are not under > > the same administrative domain, the MR MUST not run=20 > > a routing protocol to the Home Agent".=20 > >=20 > > I think this will avoid any ambiguity. But I don't know > > if this is what the WG wants. >=20 > Asking this question: does IGP fill an important role in the=20 > scenario=20 > where MRs and HA belong to different domains and MRs don't=20 > trust each=20 > other? IGP doesn't fit into that model. So would any sane=20 > admin allow=20 > that to be used? =3D> I consider myself sane and I wouldn't want to use IGPs in this scenario ;) >=20 > I think Vijay summarized it well with: > "if there is sufficient trust between the MR and HA and they are > configured to exchange routing updates, just do that. nothing > for NEMO to do here. NEMO only creates the bi-directional tunnel > (and few other things). >=20 > if IGP cannot be run, the MR includes prefixes in binding update > in explicit mode. " >=20 > I would be happy with your statement above, Hesham. =3D> Ok. I'm also fine with Vijay's "sufficient trust" part.=20 So something along those lines is ok with me. Hesham =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=20 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 From nemo-admin@ietf.org Mon Apr 5 18:12:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15974 for ; Mon, 5 Apr 2004 18:12:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcK1-0002Kh-5U; Mon, 05 Apr 2004 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcJ6-0001na-LD for nemo@optimus.ietf.org; Mon, 05 Apr 2004 18:11: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 SAA15673 for ; Mon, 5 Apr 2004 18:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcJ3-0004JM-00 for nemo@ietf.org; Mon, 05 Apr 2004 18:11:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAc6N-0002Fh-00 for nemo@ietf.org; Mon, 05 Apr 2004 17:57:57 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BAbjK-0006jM-00 for nemo@ietf.org; Mon, 05 Apr 2004 17:34:06 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i35LXVV12516; Mon, 5 Apr 2004 14:33:31 -0700 X-mProtect: <200404052133> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfStEb3; Mon, 05 Apr 2004 14:33:28 PDT Message-ID: <4071D425.7060502@iprg.nokia.com> Date: Mon, 05 Apr 2004 14:48:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: smb@research.att.com CC: margaret@thingmagic.com, nemo@ietf.org 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 Subject: [nemo] your comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Steve, I am trying to address your comments on draft-ietf-nemo-basic-support > 3: What good does it to to check the source address of the > outer IPv6 header? Spoofing that is far too easy. when the Mobile Router (MR) receives a tunneled packet from the Home Agent (HA), it looks like the following IPv6 hdr (src=HA, dst=MR_CoA) IPv6 hdr (src=CN, dst=MNN) Payload MNN (Mobile network node) is one of the nodes inside the Mobile Network. when the MR decapsulates the above packet and forwards the inner packet, it has to perform a few tunnel checks. it has to verify that the source address on the outer IPv6 header is the Home Agent and the destination address in the inner packet is one of the nodes in the Mobile Network. such checks need to be performed always, right? this check however only needs to be done if there is no IPsec protection (in tunnel mode) for the packets. > > 5.4: why is 140 not allowed in explicit mode? 6.6 implies that it should be. you are right. I will fix this. the MR should process 140 always. > 6: no text in 6 about which modes Home Agents must support, similar to > the last paragraph of 5.2. we do have something in section 6 In order for a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in Section 8.4 of [1]. The Home Agent MUST implement both modes described in Section 5.2 of this document. > > 6.1.2: why is the prefix table check only a SHOULD and not a MUST? well, the mobile router and the HA most of the time share some kind of subscriber/provider relationship. the prefix table is needed only if you expect the mobile routers to misbehave. this was the concensus in the WG when this was discussed earlier. > > 8: This text is unclear: > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router > should be careful in including the same Mobile Network > Prefixes in the Binding Update to the Home Agent and in > the routing protocol updates. The Home Agent depending > on its configuration might not add routes based on the > prefix information in the Binding Updates at all, and > might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > > Do you mean "be careful to include the same information in > both places" -- redunancy is sometimes good. Or do you > mean "be careful to avoid doing this"? Personally, I think > the former is more appropriate, because it allows a check > on the validity of the routing information. Note that the > prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus > suggest that routing advertisements MUST NOT contain any > prefixes not known to the home agent by either implicit > mode configuration or explicit mode announcement. > > 9: When discussing Home Agent routing protocol processing, must > the HA check the authorization for routing messages in general, > or for the prefixes actually being announced? > we actually wanted to avoid any kind of coupling between running an IGP and the NEMO basic support protocol. when a routing protocol is used between the mobile router and the HA, the bi-directional tunnel between the MR and the HA actually extends the IGP domain to include the MR. thats all. NEMO basic support protocol only creates the bi-directional tunnel (and few more things). we dont want NEMO to do the verification for routing protocol updates. if there is enough trust between the MR and the HA and they are configured to run an IGP, they do it. otherwise the MR and the HA should not run an IGP when the MR is not at home. we can make this more explicit if needed. I have filed your comments under issue # 34 at http://people.nokia.net/vijayd/nemo/issues.html Vijay From exim@www1.ietf.org Mon Apr 5 19:00:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20371 for ; Mon, 5 Apr 2004 19:00:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAd4d-0000BW-2X for nemo-archive@odin.ietf.org; Mon, 05 Apr 2004 19:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35N0BOH000708 for nemo-archive@odin.ietf.org; Mon, 5 Apr 2004 19:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAd4c-0000BB-QX for nemo-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 19:00:10 -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 TAA20261 for ; Mon, 5 Apr 2004 19:00:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAd4Z-00029N-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 19:00:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAcru-0007YO-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 18:47:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAcKA-0004Vg-00 for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 18:12:10 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAcKA-0006Qe-Sm for nemo-web-archive@ietf.org; Mon, 05 Apr 2004 18:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcK1-0002Kh-5U; Mon, 05 Apr 2004 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcJ6-0001na-LD for nemo@optimus.ietf.org; Mon, 05 Apr 2004 18:11: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 SAA15673 for ; Mon, 5 Apr 2004 18:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcJ3-0004JM-00 for nemo@ietf.org; Mon, 05 Apr 2004 18:11:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAc6N-0002Fh-00 for nemo@ietf.org; Mon, 05 Apr 2004 17:57:57 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BAbjK-0006jM-00 for nemo@ietf.org; Mon, 05 Apr 2004 17:34:06 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i35LXVV12516; Mon, 5 Apr 2004 14:33:31 -0700 X-mProtect: <200404052133> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfStEb3; Mon, 05 Apr 2004 14:33:28 PDT Message-ID: <4071D425.7060502@iprg.nokia.com> Date: Mon, 05 Apr 2004 14:48:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: smb@research.att.com CC: margaret@thingmagic.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] your comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit hi Steve, I am trying to address your comments on draft-ietf-nemo-basic-support > 3: What good does it to to check the source address of the > outer IPv6 header? Spoofing that is far too easy. when the Mobile Router (MR) receives a tunneled packet from the Home Agent (HA), it looks like the following IPv6 hdr (src=HA, dst=MR_CoA) IPv6 hdr (src=CN, dst=MNN) Payload MNN (Mobile network node) is one of the nodes inside the Mobile Network. when the MR decapsulates the above packet and forwards the inner packet, it has to perform a few tunnel checks. it has to verify that the source address on the outer IPv6 header is the Home Agent and the destination address in the inner packet is one of the nodes in the Mobile Network. such checks need to be performed always, right? this check however only needs to be done if there is no IPsec protection (in tunnel mode) for the packets. > > 5.4: why is 140 not allowed in explicit mode? 6.6 implies that it should be. you are right. I will fix this. the MR should process 140 always. > 6: no text in 6 about which modes Home Agents must support, similar to > the last paragraph of 5.2. we do have something in section 6 In order for a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in Section 8.4 of [1]. The Home Agent MUST implement both modes described in Section 5.2 of this document. > > 6.1.2: why is the prefix table check only a SHOULD and not a MUST? well, the mobile router and the HA most of the time share some kind of subscriber/provider relationship. the prefix table is needed only if you expect the mobile routers to misbehave. this was the concensus in the WG when this was discussed earlier. > > 8: This text is unclear: > > When the Mobile Router and the Home Agent exchange routes > through a dynamic routing protocol, the Mobile Router > should be careful in including the same Mobile Network > Prefixes in the Binding Update to the Home Agent and in > the routing protocol updates. The Home Agent depending > on its configuration might not add routes based on the > prefix information in the Binding Updates at all, and > might use only the routing protocol updates. Moreover, > including the same prefix information in both the Binding > Update and the routing protocol update is redundant. > > Do you mean "be careful to include the same information in > both places" -- redunancy is sometimes good. Or do you > mean "be careful to avoid doing this"? Personally, I think > the former is more appropriate, because it allows a check > on the validity of the routing information. Note that the > prefixes announced via binding updates are checked for > authorization; routing data generally is not. I would thus > suggest that routing advertisements MUST NOT contain any > prefixes not known to the home agent by either implicit > mode configuration or explicit mode announcement. > > 9: When discussing Home Agent routing protocol processing, must > the HA check the authorization for routing messages in general, > or for the prefixes actually being announced? > we actually wanted to avoid any kind of coupling between running an IGP and the NEMO basic support protocol. when a routing protocol is used between the mobile router and the HA, the bi-directional tunnel between the MR and the HA actually extends the IGP domain to include the MR. thats all. NEMO basic support protocol only creates the bi-directional tunnel (and few more things). we dont want NEMO to do the verification for routing protocol updates. if there is enough trust between the MR and the HA and they are configured to run an IGP, they do it. otherwise the MR and the HA should not run an IGP when the MR is not at home. we can make this more explicit if needed. I have filed your comments under issue # 34 at http://people.nokia.net/vijayd/nemo/issues.html Vijay From nemo-admin@ietf.org Tue Apr 6 05:22:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25756 for ; Tue, 6 Apr 2004 05:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmmR-0004hA-Uv; Tue, 06 Apr 2004 05:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmmH-0004ez-3j for nemo@optimus.ietf.org; Tue, 06 Apr 2004 05:21:53 -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 FAA25638 for ; Tue, 6 Apr 2004 05:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmmD-00048R-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmZZ-0001eD-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:08:46 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAm1l-00068C-00 for nemo@ietf.org; Tue, 06 Apr 2004 04:33:51 -0400 Received: from dhcp-143-222.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-222.sfc.wide.ad.jp [203.178.143.222]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i368I8UV013345; Tue, 6 Apr 2004 17:18:58 +0900 Date: Tue, 06 Apr 2004 17:19:25 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , I agree with Hesham for RO stuff. The NEMO basic draft has enough pointers to MIP6 spec in each Section. We even give Section number of MIP6 draft for some pointers. One thing I feel uncomfortable is when MR acts as Mobile Node. For example, the draft says below in Section3. "For traffic originated by itself, the Mobile Router can use either reverse tunneling or route optimization as specified in [1]." When a Mobile Router supporting both MIP6 and NEMO uses the same HoA for both protocols, can MR use Binding Cache created by NEMO BU (i.e. R flag set) for host mobility purpose? I think when MR uses the same HoA, the MR should not send MIP6 BU. Even when MR re-registers its HoA without R-flag (MIP6 BU), HA just overwrites the BC created with NEMO BU. This may cause loop of sequence number errors. The returning home is more critical. Or MR must use different HoAs for NEMO and MIP? comments? regards, ryuji At Fri, 2 Apr 2004 10:42:54 -0500, Soliman Hesham wrote: > > I'm trying to understand the need for this statement > at all. If RO is implemented it's implemented in the > context of host mobility (read: nothing to do with nemo). > In this case the MR looks like a host and should follow > MIPv6 in this context. > > So why is this statement needed at all, independently > of whether it's a should or may? > > Hesham > > > > -----Original Message----- > > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > > Alexandru Petrescu > > > Sent: jeudi 1 avril 2004 15:15 > > > To: IETF NEMO WG > > > Subject: [nemo] issue 35 on how MR spec is relaxed with > > respect to MH > > RO > > > > > > IESG Reviewer > > > > In the third paragraph under section 5, the wording is quite > > strange. > > > > I'm not sure what they are doing without more research > > than I have > > > > time for, but my guess is that they are saying at the > > end that under > > > > a specific set of criteria, they are relaxing a MUST in another > > > > document to a MAY, but they need to be clearer on the intent. > > > > > > The paragraph in question is: > > > > A Mobile Router MUST implement all requirements for IPv6 Mobile > > > > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > > > > expected to initiate sessions of its own and behaves purely as a > > > > router serving the mobile network most of the time, then > > the Route > > > > Optimization functionality MAY be implemented. > > > > > > I would suggest insertion of a preceding phrase like: A Mobile IPv6 > > > Mobile Host SHOULD implement Route Optimization [2]; however, if a > > > Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to > > NEMO > > > MR RO MAY). > > > > > > Alex > > > > ======================================================== > 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. > ======================================================== > > From exim@www1.ietf.org Tue Apr 6 06:03:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27069 for ; Tue, 6 Apr 2004 06:03:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnQO-0004jC-B3 for nemo-archive@odin.ietf.org; Tue, 06 Apr 2004 06:03:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36A3KYZ018175 for nemo-archive@odin.ietf.org; Tue, 6 Apr 2004 06:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnQN-0004iz-TI for nemo-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 06:03:20 -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 GAA27008 for ; Tue, 6 Apr 2004 06:03:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnQK-0000FF-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 06:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmqJ-00050y-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 05:26:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAmmS-0004Bn-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 05:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmmR-0004hA-Uv; Tue, 06 Apr 2004 05:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmmH-0004ez-3j for nemo@optimus.ietf.org; Tue, 06 Apr 2004 05:21:53 -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 FAA25638 for ; Tue, 6 Apr 2004 05:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmmD-00048R-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmZZ-0001eD-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:08:46 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAm1l-00068C-00 for nemo@ietf.org; Tue, 06 Apr 2004 04:33:51 -0400 Received: from dhcp-143-222.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-222.sfc.wide.ad.jp [203.178.143.222]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i368I8UV013345; Tue, 6 Apr 2004 17:18:58 +0900 Date: Tue, 06 Apr 2004 17:19:25 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 I agree with Hesham for RO stuff. The NEMO basic draft has enough pointers to MIP6 spec in each Section. We even give Section number of MIP6 draft for some pointers. One thing I feel uncomfortable is when MR acts as Mobile Node. For example, the draft says below in Section3. "For traffic originated by itself, the Mobile Router can use either reverse tunneling or route optimization as specified in [1]." When a Mobile Router supporting both MIP6 and NEMO uses the same HoA for both protocols, can MR use Binding Cache created by NEMO BU (i.e. R flag set) for host mobility purpose? I think when MR uses the same HoA, the MR should not send MIP6 BU. Even when MR re-registers its HoA without R-flag (MIP6 BU), HA just overwrites the BC created with NEMO BU. This may cause loop of sequence number errors. The returning home is more critical. Or MR must use different HoAs for NEMO and MIP? comments? regards, ryuji At Fri, 2 Apr 2004 10:42:54 -0500, Soliman Hesham wrote: > > I'm trying to understand the need for this statement > at all. If RO is implemented it's implemented in the > context of host mobility (read: nothing to do with nemo). > In this case the MR looks like a host and should follow > MIPv6 in this context. > > So why is this statement needed at all, independently > of whether it's a should or may? > > Hesham > > > > -----Original Message----- > > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > > Alexandru Petrescu > > > Sent: jeudi 1 avril 2004 15:15 > > > To: IETF NEMO WG > > > Subject: [nemo] issue 35 on how MR spec is relaxed with > > respect to MH > > RO > > > > > > IESG Reviewer > > > > In the third paragraph under section 5, the wording is quite > > strange. > > > > I'm not sure what they are doing without more research > > than I have > > > > time for, but my guess is that they are saying at the > > end that under > > > > a specific set of criteria, they are relaxing a MUST in another > > > > document to a MAY, but they need to be clearer on the intent. > > > > > > The paragraph in question is: > > > > A Mobile Router MUST implement all requirements for IPv6 Mobile > > > > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > > > > expected to initiate sessions of its own and behaves purely as a > > > > router serving the mobile network most of the time, then > > the Route > > > > Optimization functionality MAY be implemented. > > > > > > I would suggest insertion of a preceding phrase like: A Mobile IPv6 > > > Mobile Host SHOULD implement Route Optimization [2]; however, if a > > > Mobile Router is not ... (relaxing the Mobile IPv6 MH RO SHOULD to > > NEMO > > > MR RO MAY). > > > > > > Alex > > > > ======================================================== > 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. > ======================================================== > > From nemo-admin@ietf.org Tue Apr 6 06:23:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00523 for ; Tue, 6 Apr 2004 06:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnjR-0003K7-AH; Tue, 06 Apr 2004 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnjM-0003Js-FK for nemo@optimus.ietf.org; Tue, 06 Apr 2004 06:22:56 -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 GAA00518 for ; Tue, 6 Apr 2004 06:22:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnjI-0003iC-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:22:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAnTR-0000q1-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:06:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAmwa-0005aw-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:32:32 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAmwc-0007hd-Af for nemo@ietf.org; Tue, 06 Apr 2004 05:32:34 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 05:31:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Tue, 6 Apr 2004 05:31:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQbtBMqrtOnej1kQIy7Rhy2i/XzrwABHUhw From: "Soliman Hesham" To: "Ryuji Wakikawa" CC: X-OriginalArrivalTime: 06 Apr 2004 09:31:45.0820 (UTC) FILETIME=[FA76B5C0:01C41BB9] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I agree with Hesham for RO stuff.=20 > The NEMO basic draft has enough pointers to MIP6 spec in=20 > each Section. > We even give Section number of MIP6 draft for some pointers. >=20 > One thing I feel uncomfortable is when MR acts as Mobile Node. > For example, the draft says below in Section3. > "For traffic originated by itself, the Mobile Router can use either > reverse tunneling or route optimization as specified in [1]." >=20 > When a Mobile Router supporting both MIP6 and NEMO uses the same HoA > for both protocols, can MR use Binding Cache created by NEMO BU > (i.e. R flag set) for host mobility purpose? =3D> Sure, why not ? >=20 > I think when MR uses the same HoA, the MR should not send MIP6 > BU.=20 =3D> Nemo extends the BU but AFAICS it doesn't exclude using=20 it for host mobility. I think this would be a mistake. > Or MR must use different HoAs for NEMO and MIP?=20 =3D> I think one address is enough and simple. Hesham >=20 > comments? >=20 > regards, > ryuji >=20 >=20 >=20 > At Fri, 2 Apr 2004 10:42:54 -0500, > Soliman Hesham wrote: > >=20 > > I'm trying to understand the need for this statement > > at all. If RO is implemented it's implemented in the=20 > > context of host mobility (read: nothing to do with nemo). > > In this case the MR looks like a host and should follow > > MIPv6 in this context.=20 > >=20 > > So why is this statement needed at all, independently > > of whether it's a should or may? > >=20 > > Hesham > >=20 > > > > -----Original Message----- > > > > From: nemo-admin@ietf.org=20 > [mailto:nemo-admin@ietf.org] On Behalf Of > > > Alexandru Petrescu > > > > Sent: jeudi 1 avril 2004 15:15 > > > > To: IETF NEMO WG > > > > Subject: [nemo] issue 35 on how MR spec is relaxed with=20 > > > respect to MH > > > RO > > > >=20 > > > > IESG Reviewer > > > > > In the third paragraph under section 5, the wording is quite > > > strange. > > > > > I'm not sure what they are doing without more research=20 > > > than I have > > > > > time for, but my guess is that they are saying at the=20 > > > end that under > > > > > a specific set of criteria, they are relaxing a=20 > MUST in another > > > > > document to a MAY, but they need to be clearer on=20 > the intent. > > > >=20 > > > > The paragraph in question is: > > > > > A Mobile Router MUST implement all requirements for=20 > IPv6 Mobile > > > > > Nodes, Section 8.5 in [1]. However if a Mobile=20 > Router is not > > > > > expected to initiate sessions of its own and=20 > behaves purely as a > > > > > router serving the mobile network most of the time, then=20 > > > the Route > > > > > Optimization functionality MAY be implemented. > > > >=20 > > > > I would suggest insertion of a preceding phrase like:=20 > A Mobile IPv6 > > > > Mobile Host SHOULD implement Route Optimization [2];=20 > however, if a > > > > Mobile Router is not ... (relaxing the Mobile IPv6 MH=20 > RO SHOULD to > > > NEMO > > > > MR RO MAY). > > > >=20 > > > > Alex > > >=20 > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole > > use of the intended recipient. Any review or distribution=20 > by others is=20 > > strictly prohibited. If you are not the intended=20 > 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 > >=20 > >=20 >=20 From nemo-admin@ietf.org Tue Apr 6 06:35:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00966 for ; Tue, 6 Apr 2004 06:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnv3-0005wl-8n; Tue, 06 Apr 2004 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnuB-0005jr-Gc for nemo@optimus.ietf.org; Tue, 06 Apr 2004 06:34:07 -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 GAA00880 for ; Tue, 6 Apr 2004 06:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnu7-0004bw-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:34:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAnXw-0001mR-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:11:11 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAn84-0006Uy-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:44:24 -0400 Received: from dhcp-143-222.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-222.sfc.wide.ad.jp [203.178.143.222]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i369gkUV014785; Tue, 6 Apr 2004 18:42:46 +0900 Date: Tue, 06 Apr 2004 18:44:04 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Tue, 6 Apr 2004 05:31:45 -0400, Soliman Hesham wrote: > > > > > I agree with Hesham for RO stuff. > > The NEMO basic draft has enough pointers to MIP6 spec in > > each Section. > > We even give Section number of MIP6 draft for some pointers. > > > > One thing I feel uncomfortable is when MR acts as Mobile Node. > > For example, the draft says below in Section3. > > "For traffic originated by itself, the Mobile Router can use either > > reverse tunneling or route optimization as specified in [1]." > > > > When a Mobile Router supporting both MIP6 and NEMO uses the same HoA > > for both protocols, can MR use Binding Cache created by NEMO BU > > (i.e. R flag set) for host mobility purpose? > > => Sure, why not ? > > > > > I think when MR uses the same HoA, the MR should not send MIP6 > > BU. > > => Nemo extends the BU but AFAICS it doesn't exclude using > it for host mobility. I think this would be a mistake. You missed my point. I wanted to say that when a MR uses the same HoA, the MR should not send both a normal BU (without R flag) and a BU with R-flag simultaneously for the same HoA. We should prohibit sending normal Binding Updates to HA for MR's HoA. > > Or MR must use different HoAs for NEMO and MIP? > > => I think one address is enough and simple. I agree on this. ryuji > Hesham > > > > > comments? > > > > regards, > > ryuji > > > > > > > > At Fri, 2 Apr 2004 10:42:54 -0500, > > Soliman Hesham wrote: > > > > > > I'm trying to understand the need for this statement > > > at all. If RO is implemented it's implemented in the > > > context of host mobility (read: nothing to do with nemo). > > > In this case the MR looks like a host and should follow > > > MIPv6 in this context. > > > > > > So why is this statement needed at all, independently > > > of whether it's a should or may? > > > > > > Hesham > > > > > > > > -----Original Message----- > > > > > From: nemo-admin@ietf.org > > [mailto:nemo-admin@ietf.org] On Behalf Of > > > > Alexandru Petrescu > > > > > Sent: jeudi 1 avril 2004 15:15 > > > > > To: IETF NEMO WG > > > > > Subject: [nemo] issue 35 on how MR spec is relaxed with > > > > respect to MH > > > > RO > > > > > > > > > > IESG Reviewer > > > > > > In the third paragraph under section 5, the wording is quite > > > > strange. > > > > > > I'm not sure what they are doing without more research > > > > than I have > > > > > > time for, but my guess is that they are saying at the > > > > end that under > > > > > > a specific set of criteria, they are relaxing a > > MUST in another > > > > > > document to a MAY, but they need to be clearer on > > the intent. > > > > > > > > > > The paragraph in question is: > > > > > > A Mobile Router MUST implement all requirements for > > IPv6 Mobile > > > > > > Nodes, Section 8.5 in [1]. However if a Mobile > > Router is not > > > > > > expected to initiate sessions of its own and > > behaves purely as a > > > > > > router serving the mobile network most of the time, then > > > > the Route > > > > > > Optimization functionality MAY be implemented. > > > > > > > > > > I would suggest insertion of a preceding phrase like: > > A Mobile IPv6 > > > > > Mobile Host SHOULD implement Route Optimization [2]; > > however, if a > > > > > Mobile Router is not ... (relaxing the Mobile IPv6 MH > > RO SHOULD to > > > > NEMO > > > > > MR RO MAY). > > > > > > > > > > Alex > > > > > > > > > > ======================================================== > > > 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. > > > ======================================================== > > > > > > > > From nemo-admin@ietf.org Tue Apr 6 07:11:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04803 for ; Tue, 6 Apr 2004 07:11:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoTt-00076I-Tw; Tue, 06 Apr 2004 07:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoT0-0006s3-Tb for nemo@optimus.ietf.org; Tue, 06 Apr 2004 07:10: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 HAA04562 for ; Tue, 6 Apr 2004 07:10:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoSw-0001E1-00 for nemo@ietf.org; Tue, 06 Apr 2004 07:10:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoFr-0006RE-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:56:31 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BAngt-0003TW-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:20:23 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 06:19:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Tue, 6 Apr 2004 06:19:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQbu60g51WIWPunRdCx0Ds+pYqpkgAA6u7g From: "Soliman Hesham" To: "Ryuji Wakikawa" CC: X-OriginalArrivalTime: 06 Apr 2004 10:19:52.0226 (UTC) FILETIME=[B2E55020:01C41BC0] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Nemo extends the BU but AFAICS it doesn't exclude using=20 > > it for host mobility. I think this would be a mistake. >=20 > You missed my point.=20 >=20 > I wanted to say that=20 > when a MR uses the same HoA, the MR should not send both a normal BU > (without R flag) and a BU with R-flag simultaneously for the=20 > same HoA. > We should prohibit sending normal Binding Updates to HA for MR's HoA. =3D> Sorry, it wasn't clear to me. Of course I agree with that. It's one BU, loaded with whatever extensions a node needs. Hesham =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=20 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 From exim@www1.ietf.org Tue Apr 6 07:11:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04878 for ; Tue, 6 Apr 2004 07:11:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoUN-0007Cv-KD for nemo-archive@odin.ietf.org; Tue, 06 Apr 2004 07:11:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36BBVQb027706 for nemo-archive@odin.ietf.org; Tue, 6 Apr 2004 07:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoUN-0007Cn-FB for nemo-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 07:11:31 -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 HAA04791 for ; Tue, 6 Apr 2004 07:11:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoUJ-0001TD-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:11:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoHH-0006nO-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 06:58:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAnjR-0003j9-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 06:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnjR-0003K7-AH; Tue, 06 Apr 2004 06:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnjM-0003Js-FK for nemo@optimus.ietf.org; Tue, 06 Apr 2004 06:22:56 -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 GAA00518 for ; Tue, 6 Apr 2004 06:22:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnjI-0003iC-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:22:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAnTR-0000q1-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:06:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAmwa-0005aw-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:32:32 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAmwc-0007hd-Af for nemo@ietf.org; Tue, 06 Apr 2004 05:32:34 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 05:31:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Tue, 6 Apr 2004 05:31:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQbtBMqrtOnej1kQIy7Rhy2i/XzrwABHUhw From: "Soliman Hesham" To: "Ryuji Wakikawa" CC: X-OriginalArrivalTime: 06 Apr 2004 09:31:45.0820 (UTC) FILETIME=[FA76B5C0:01C41BB9] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > I agree with Hesham for RO stuff.=20 > The NEMO basic draft has enough pointers to MIP6 spec in=20 > each Section. > We even give Section number of MIP6 draft for some pointers. >=20 > One thing I feel uncomfortable is when MR acts as Mobile Node. > For example, the draft says below in Section3. > "For traffic originated by itself, the Mobile Router can use either > reverse tunneling or route optimization as specified in [1]." >=20 > When a Mobile Router supporting both MIP6 and NEMO uses the same HoA > for both protocols, can MR use Binding Cache created by NEMO BU > (i.e. R flag set) for host mobility purpose? =3D> Sure, why not ? >=20 > I think when MR uses the same HoA, the MR should not send MIP6 > BU.=20 =3D> Nemo extends the BU but AFAICS it doesn't exclude using=20 it for host mobility. I think this would be a mistake. > Or MR must use different HoAs for NEMO and MIP?=20 =3D> I think one address is enough and simple. Hesham >=20 > comments? >=20 > regards, > ryuji >=20 >=20 >=20 > At Fri, 2 Apr 2004 10:42:54 -0500, > Soliman Hesham wrote: > >=20 > > I'm trying to understand the need for this statement > > at all. If RO is implemented it's implemented in the=20 > > context of host mobility (read: nothing to do with nemo). > > In this case the MR looks like a host and should follow > > MIPv6 in this context.=20 > >=20 > > So why is this statement needed at all, independently > > of whether it's a should or may? > >=20 > > Hesham > >=20 > > > > -----Original Message----- > > > > From: nemo-admin@ietf.org=20 > [mailto:nemo-admin@ietf.org] On Behalf Of > > > Alexandru Petrescu > > > > Sent: jeudi 1 avril 2004 15:15 > > > > To: IETF NEMO WG > > > > Subject: [nemo] issue 35 on how MR spec is relaxed with=20 > > > respect to MH > > > RO > > > >=20 > > > > IESG Reviewer > > > > > In the third paragraph under section 5, the wording is quite > > > strange. > > > > > I'm not sure what they are doing without more research=20 > > > than I have > > > > > time for, but my guess is that they are saying at the=20 > > > end that under > > > > > a specific set of criteria, they are relaxing a=20 > MUST in another > > > > > document to a MAY, but they need to be clearer on=20 > the intent. > > > >=20 > > > > The paragraph in question is: > > > > > A Mobile Router MUST implement all requirements for=20 > IPv6 Mobile > > > > > Nodes, Section 8.5 in [1]. However if a Mobile=20 > Router is not > > > > > expected to initiate sessions of its own and=20 > behaves purely as a > > > > > router serving the mobile network most of the time, then=20 > > > the Route > > > > > Optimization functionality MAY be implemented. > > > >=20 > > > > I would suggest insertion of a preceding phrase like:=20 > A Mobile IPv6 > > > > Mobile Host SHOULD implement Route Optimization [2];=20 > however, if a > > > > Mobile Router is not ... (relaxing the Mobile IPv6 MH=20 > RO SHOULD to > > > NEMO > > > > MR RO MAY). > > > >=20 > > > > Alex > > >=20 > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole > > use of the intended recipient. Any review or distribution=20 > by others is=20 > > strictly prohibited. If you are not the intended=20 > 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 > >=20 > >=20 >=20 From exim@www1.ietf.org Tue Apr 6 07:13:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05312 for ; Tue, 6 Apr 2004 07:13:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoW7-0007l9-GR for nemo-archive@odin.ietf.org; Tue, 06 Apr 2004 07:13:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36BDJIe029825 for nemo-archive@odin.ietf.org; Tue, 6 Apr 2004 07:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoW7-0007ky-Cs for nemo-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 07:13: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 HAA05162 for ; Tue, 6 Apr 2004 07:13:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoW6-0001nl-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:13:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoLQ-0007ae-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:02:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAnv1-0004gO-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 06:34:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnv3-0005wl-8n; Tue, 06 Apr 2004 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnuB-0005jr-Gc for nemo@optimus.ietf.org; Tue, 06 Apr 2004 06:34:07 -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 GAA00880 for ; Tue, 6 Apr 2004 06:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnu7-0004bw-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:34:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAnXw-0001mR-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:11:11 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAn84-0006Uy-00 for nemo@ietf.org; Tue, 06 Apr 2004 05:44:24 -0400 Received: from dhcp-143-222.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-222.sfc.wide.ad.jp [203.178.143.222]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i369gkUV014785; Tue, 6 Apr 2004 18:42:46 +0900 Date: Tue, 06 Apr 2004 18:44:04 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 At Tue, 6 Apr 2004 05:31:45 -0400, Soliman Hesham wrote: > > > > > I agree with Hesham for RO stuff. > > The NEMO basic draft has enough pointers to MIP6 spec in > > each Section. > > We even give Section number of MIP6 draft for some pointers. > > > > One thing I feel uncomfortable is when MR acts as Mobile Node. > > For example, the draft says below in Section3. > > "For traffic originated by itself, the Mobile Router can use either > > reverse tunneling or route optimization as specified in [1]." > > > > When a Mobile Router supporting both MIP6 and NEMO uses the same HoA > > for both protocols, can MR use Binding Cache created by NEMO BU > > (i.e. R flag set) for host mobility purpose? > > => Sure, why not ? > > > > > I think when MR uses the same HoA, the MR should not send MIP6 > > BU. > > => Nemo extends the BU but AFAICS it doesn't exclude using > it for host mobility. I think this would be a mistake. You missed my point. I wanted to say that when a MR uses the same HoA, the MR should not send both a normal BU (without R flag) and a BU with R-flag simultaneously for the same HoA. We should prohibit sending normal Binding Updates to HA for MR's HoA. > > Or MR must use different HoAs for NEMO and MIP? > > => I think one address is enough and simple. I agree on this. ryuji > Hesham > > > > > comments? > > > > regards, > > ryuji > > > > > > > > At Fri, 2 Apr 2004 10:42:54 -0500, > > Soliman Hesham wrote: > > > > > > I'm trying to understand the need for this statement > > > at all. If RO is implemented it's implemented in the > > > context of host mobility (read: nothing to do with nemo). > > > In this case the MR looks like a host and should follow > > > MIPv6 in this context. > > > > > > So why is this statement needed at all, independently > > > of whether it's a should or may? > > > > > > Hesham > > > > > > > > -----Original Message----- > > > > > From: nemo-admin@ietf.org > > [mailto:nemo-admin@ietf.org] On Behalf Of > > > > Alexandru Petrescu > > > > > Sent: jeudi 1 avril 2004 15:15 > > > > > To: IETF NEMO WG > > > > > Subject: [nemo] issue 35 on how MR spec is relaxed with > > > > respect to MH > > > > RO > > > > > > > > > > IESG Reviewer > > > > > > In the third paragraph under section 5, the wording is quite > > > > strange. > > > > > > I'm not sure what they are doing without more research > > > > than I have > > > > > > time for, but my guess is that they are saying at the > > > > end that under > > > > > > a specific set of criteria, they are relaxing a > > MUST in another > > > > > > document to a MAY, but they need to be clearer on > > the intent. > > > > > > > > > > The paragraph in question is: > > > > > > A Mobile Router MUST implement all requirements for > > IPv6 Mobile > > > > > > Nodes, Section 8.5 in [1]. However if a Mobile > > Router is not > > > > > > expected to initiate sessions of its own and > > behaves purely as a > > > > > > router serving the mobile network most of the time, then > > > > the Route > > > > > > Optimization functionality MAY be implemented. > > > > > > > > > > I would suggest insertion of a preceding phrase like: > > A Mobile IPv6 > > > > > Mobile Host SHOULD implement Route Optimization [2]; > > however, if a > > > > > Mobile Router is not ... (relaxing the Mobile IPv6 MH > > RO SHOULD to > > > > NEMO > > > > > MR RO MAY). > > > > > > > > > > Alex > > > > > > > > > > ======================================================== > > > 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. > > > ======================================================== > > > > > > > > From exim@www1.ietf.org Tue Apr 6 07:54:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06402 for ; Tue, 6 Apr 2004 07:54:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAp9N-00072M-RD for nemo-archive@odin.ietf.org; Tue, 06 Apr 2004 07:53:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36BrrUR027051 for nemo-archive@odin.ietf.org; Tue, 6 Apr 2004 07:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAp9N-00072E-Lh for nemo-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 07:53:53 -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 HAA06297 for ; Tue, 6 Apr 2004 07:53:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAp9M-0005YT-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:53:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoZc-0002Y8-00 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:16:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAoUz-0001a6-01 for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:12:09 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAoTv-0005bw-GR for nemo-web-archive@ietf.org; Tue, 06 Apr 2004 07:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoTt-00076I-Tw; Tue, 06 Apr 2004 07:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAoT0-0006s3-Tb for nemo@optimus.ietf.org; Tue, 06 Apr 2004 07:10: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 HAA04562 for ; Tue, 6 Apr 2004 07:10:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAoSw-0001E1-00 for nemo@ietf.org; Tue, 06 Apr 2004 07:10:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAoFr-0006RE-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:56:31 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BAngt-0003TW-00 for nemo@ietf.org; Tue, 06 Apr 2004 06:20:23 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 06:19:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Tue, 6 Apr 2004 06:19:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQbu60g51WIWPunRdCx0Ds+pYqpkgAA6u7g From: "Soliman Hesham" To: "Ryuji Wakikawa" CC: X-OriginalArrivalTime: 06 Apr 2004 10:19:52.0226 (UTC) FILETIME=[B2E55020:01C41BC0] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > > =3D> Nemo extends the BU but AFAICS it doesn't exclude using=20 > > it for host mobility. I think this would be a mistake. >=20 > You missed my point.=20 >=20 > I wanted to say that=20 > when a MR uses the same HoA, the MR should not send both a normal BU > (without R flag) and a BU with R-flag simultaneously for the=20 > same HoA. > We should prohibit sending normal Binding Updates to HA for MR's HoA. =3D> Sorry, it wasn't clear to me. Of course I agree with that. It's one BU, loaded with whatever extensions a node needs. Hesham =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=20 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 From nemo-admin@ietf.org Wed Apr 7 06:12:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04717 for ; Wed, 7 Apr 2004 06:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBA2K-0004y5-Cy; Wed, 07 Apr 2004 06:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBA1n-0004xl-TR for nemo@optimus.ietf.org; Wed, 07 Apr 2004 06:11: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 GAA04707 for ; Wed, 7 Apr 2004 06:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBA1k-0006Np-00 for nemo@ietf.org; Wed, 07 Apr 2004 06:11:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB93c-0006yQ-00 for nemo@ietf.org; Wed, 07 Apr 2004 05:09:17 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BB87d-0006W4-00 for nemo@ietf.org; Wed, 07 Apr 2004 04:09:21 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3789HAh027241 for ; Wed, 7 Apr 2004 10:09:22 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 10:09:17 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 212ZMPDM; Wed, 7 Apr 2004 10:09:17 +0200 Message-ID: <4073B72C.80909@ericsson.com> Date: Wed, 07 Apr 2004 10:09:16 +0200 X-Sybari-Trust: 3e71a5d3 2c4885b5 070f5455 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: [nemo] summary of same MNP to mutliple MRs discussion References: <406B5F89.1020503@iprg.nokia.com> In-Reply-To: <406B5F89.1020503@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2004 08:09:17.0552 (UTC) FILETIME=[9F7AAF00:01C41C77] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > it took me a while to go through the entire thread. I > am not sure what the problem is. the problem kept > shifting. :) here is a summary (from what I understood). Same happened to me. Now I'm through. :) > > first of all, the current spec prevents assigning the > same MNP to two mobile routers _if required_. it depends > on what is configured in the Prefix Table on the Home > Agent. if the Prefix Table on the Home Agent says that > a particular MNP was given out only to MR1, the Home > Agent sends a binding ack with status 142 to MR2 when > MR2 sends a BU to the Home Agent. > > if the Prefx Table says both MR1 and MR2 are authorized > for a MNP, then it _is_ possible for both MR1 and MR2 > to register with the Home Agent with the same MNP at > the same time. the HA then has two routes to the MNP, > one route pointing to MR1 and the second pointing to MR2. > this is what Hesham is talking about. the current NEMO > basic support spec works in this case. And it is made clear that this is supported? I think we need to tie in the discussions in issue 34. If an IGP is used, then the IGP will manage the routing table and create two entries. If only one HA is used, then the two entries will be in the routing table of this HA, each of them pointing out an HA-MR tunnel. If two separate HAs are used, where the two MRs register with one each, the IGP will make sure that each HA has two entries: one pointing out the local HA-MR tunnel, the other pointing out the other HA. On the other hand, if no IGP is used, we have to depend on the prefix table. I assume it will work when only one HA is in used. When two separate HAs are in use, there has to be an out-of-band synchronisation of the prefix tables on the two HAs. However, I think this synchronisation is out of specification. > > if the Mobile Network splits, with MR1 in one network > and MR2 in another network, both advertising the same > MNP and both registered with the Home Agent, then there > is a problem. Hesham wants this stated in the spec. the > Home Agent could pick the wrong route. Yes, but the form of distributed multilink subnet Pascal talked about would be a way to keep a split mobile network together. I think there are good reasons to support both a NEMO with a single MNP but multiple MRs, and allow it to split. > > then again, others have argued that if you expect two > mobile routers which were part of the same Mobile > Network (but not nested, both have uplinks) to move > away and split the mobile network into two, it is > stupid to assign the same MNP to both. each MR should > be delegated a unique MNP. I don't think it is stupid. Basically for the reasons Marcelo stated, I see a clear case for a simple multihomed NEMO, with as little changes as possible to the legacy MNNs. This simple case will, IMHO, include: - No requirements on MNNs about SAS, DR selection, care about different access technologies - The NEMO may split - Do not rely upon host multihoming solutions to become RFC and it is possibly solved by: - having only one MNP in the NEMO - letting the MRs and HAs have to see to that this works - letting the routers handle all routing decisions - have some form of multilink subnetting to handle the split. - just provide connectivity and do not differentiate between accesses (MNNs won't be able to; MRs and HAs may be able to) I think Hesham has a much more advanced case in mind. - moving access selection to the MNNs - MNN/end-user responsible for the cost of the access selected - somehow propagate available accesses to the MNNs - differentiate traffic from different apps - if MR has multiple accesses, MNN must be able to tell MR (and HA) to use one specific. This case puts a _lot_ of new requirements on the MNNs. Possibly legacy MNNs can fall back to a simpler case (we should make sure they can, which is why I am worried about allowing MRs to advertise different MNPs). I don't say that manufacturers of MNNs do not want to endorse these additional requirements, but we are primarily lacking a number of new protocols here. I fear this is too much for NEMO WG. > > on top of everything we dont have a clear definition > of what it means when two Mobile Networks merge or split. > (we are _not_ talking about nesting here). this is > almost MANET space. If one MNP is used: It is very much like multilink subnetting. A subnet that previously spanned a single link now spans two separate links. If the two links are connected to two router-mode interfaces of a multilink subnet router then they can still reach each other and still use the same MNP. Now with NEMO, the MLSR will be distributed over multiple MRs, so the each MR will have to tunnel traffic to another MR for MNNs that are in that MR's partition of the NEMO. On the other hand, without the distributed multilink subnetting, the NEMO is broken, of course. I would say that this case requires _coordination_ between MRs. If one MNP per MR is used: The NEMO essentially consists of two separate NEMOs, just merging their ingress links. An MNN may use the MRs of the other NEMO, but it will have to implement some form of host multihoming (optionally with session continuity support) to deal with SAS, DRS and NEMO split. I would say that this case _does not_ require coordination between MRs. /Mattias From exim@www1.ietf.org Wed Apr 7 08:30:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15970 for ; Wed, 7 Apr 2004 08:30:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCCB-00052k-IR for nemo-archive@odin.ietf.org; Wed, 07 Apr 2004 08:30:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37CUJxa019384 for nemo-archive@odin.ietf.org; Wed, 7 Apr 2004 08:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCCB-00052Z-Bv for nemo-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 08:30: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 IAA15876 for ; Wed, 7 Apr 2004 08:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBCCA-0005wU-00 for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 08:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBB6Q-0005xU-00 for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 07:20:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBA2N-0006Qt-00 for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 06:12:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBA2O-0003eg-6Y for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 06:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBA2K-0004y5-Cy; Wed, 07 Apr 2004 06:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBA1n-0004xl-TR for nemo@optimus.ietf.org; Wed, 07 Apr 2004 06:11: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 GAA04707 for ; Wed, 7 Apr 2004 06:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBA1k-0006Np-00 for nemo@ietf.org; Wed, 07 Apr 2004 06:11:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB93c-0006yQ-00 for nemo@ietf.org; Wed, 07 Apr 2004 05:09:17 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BB87d-0006W4-00 for nemo@ietf.org; Wed, 07 Apr 2004 04:09:21 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3789HAh027241 for ; Wed, 7 Apr 2004 10:09:22 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Apr 2004 10:09:17 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 212ZMPDM; Wed, 7 Apr 2004 10:09:17 +0200 Message-ID: <4073B72C.80909@ericsson.com> Date: Wed, 07 Apr 2004 10:09:16 +0200 X-Sybari-Trust: 3e71a5d3 2c4885b5 070f5455 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: [nemo] summary of same MNP to mutliple MRs discussion References: <406B5F89.1020503@iprg.nokia.com> In-Reply-To: <406B5F89.1020503@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2004 08:09:17.0552 (UTC) FILETIME=[9F7AAF00:01C41C77] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > it took me a while to go through the entire thread. I > am not sure what the problem is. the problem kept > shifting. :) here is a summary (from what I understood). Same happened to me. Now I'm through. :) > > first of all, the current spec prevents assigning the > same MNP to two mobile routers _if required_. it depends > on what is configured in the Prefix Table on the Home > Agent. if the Prefix Table on the Home Agent says that > a particular MNP was given out only to MR1, the Home > Agent sends a binding ack with status 142 to MR2 when > MR2 sends a BU to the Home Agent. > > if the Prefx Table says both MR1 and MR2 are authorized > for a MNP, then it _is_ possible for both MR1 and MR2 > to register with the Home Agent with the same MNP at > the same time. the HA then has two routes to the MNP, > one route pointing to MR1 and the second pointing to MR2. > this is what Hesham is talking about. the current NEMO > basic support spec works in this case. And it is made clear that this is supported? I think we need to tie in the discussions in issue 34. If an IGP is used, then the IGP will manage the routing table and create two entries. If only one HA is used, then the two entries will be in the routing table of this HA, each of them pointing out an HA-MR tunnel. If two separate HAs are used, where the two MRs register with one each, the IGP will make sure that each HA has two entries: one pointing out the local HA-MR tunnel, the other pointing out the other HA. On the other hand, if no IGP is used, we have to depend on the prefix table. I assume it will work when only one HA is in used. When two separate HAs are in use, there has to be an out-of-band synchronisation of the prefix tables on the two HAs. However, I think this synchronisation is out of specification. > > if the Mobile Network splits, with MR1 in one network > and MR2 in another network, both advertising the same > MNP and both registered with the Home Agent, then there > is a problem. Hesham wants this stated in the spec. the > Home Agent could pick the wrong route. Yes, but the form of distributed multilink subnet Pascal talked about would be a way to keep a split mobile network together. I think there are good reasons to support both a NEMO with a single MNP but multiple MRs, and allow it to split. > > then again, others have argued that if you expect two > mobile routers which were part of the same Mobile > Network (but not nested, both have uplinks) to move > away and split the mobile network into two, it is > stupid to assign the same MNP to both. each MR should > be delegated a unique MNP. I don't think it is stupid. Basically for the reasons Marcelo stated, I see a clear case for a simple multihomed NEMO, with as little changes as possible to the legacy MNNs. This simple case will, IMHO, include: - No requirements on MNNs about SAS, DR selection, care about different access technologies - The NEMO may split - Do not rely upon host multihoming solutions to become RFC and it is possibly solved by: - having only one MNP in the NEMO - letting the MRs and HAs have to see to that this works - letting the routers handle all routing decisions - have some form of multilink subnetting to handle the split. - just provide connectivity and do not differentiate between accesses (MNNs won't be able to; MRs and HAs may be able to) I think Hesham has a much more advanced case in mind. - moving access selection to the MNNs - MNN/end-user responsible for the cost of the access selected - somehow propagate available accesses to the MNNs - differentiate traffic from different apps - if MR has multiple accesses, MNN must be able to tell MR (and HA) to use one specific. This case puts a _lot_ of new requirements on the MNNs. Possibly legacy MNNs can fall back to a simpler case (we should make sure they can, which is why I am worried about allowing MRs to advertise different MNPs). I don't say that manufacturers of MNNs do not want to endorse these additional requirements, but we are primarily lacking a number of new protocols here. I fear this is too much for NEMO WG. > > on top of everything we dont have a clear definition > of what it means when two Mobile Networks merge or split. > (we are _not_ talking about nesting here). this is > almost MANET space. If one MNP is used: It is very much like multilink subnetting. A subnet that previously spanned a single link now spans two separate links. If the two links are connected to two router-mode interfaces of a multilink subnet router then they can still reach each other and still use the same MNP. Now with NEMO, the MLSR will be distributed over multiple MRs, so the each MR will have to tunnel traffic to another MR for MNNs that are in that MR's partition of the NEMO. On the other hand, without the distributed multilink subnetting, the NEMO is broken, of course. I would say that this case requires _coordination_ between MRs. If one MNP per MR is used: The NEMO essentially consists of two separate NEMOs, just merging their ingress links. An MNN may use the MRs of the other NEMO, but it will have to implement some form of host multihoming (optionally with session continuity support) to deal with SAS, DRS and NEMO split. I would say that this case _does not_ require coordination between MRs. /Mattias From nemo-admin@ietf.org Wed Apr 7 16:29:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29947 for ; Wed, 7 Apr 2004 16:29:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBJfS-0004GS-BF; Wed, 07 Apr 2004 16:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0hK-0005RJ-Bz for nemo@optimus.ietf.org; Tue, 06 Apr 2004 20:13:42 -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 UAA16936 for ; Tue, 6 Apr 2004 20:13:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0hI-0001cp-00 for nemo@ietf.org; Tue, 06 Apr 2004 20:13:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0AG-0004CI-00 for nemo@ietf.org; Tue, 06 Apr 2004 19:39:32 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1BAzCA-0005B1-00 for nemo@ietf.org; Tue, 06 Apr 2004 18:37:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 284F861B94; Wed, 7 Apr 2004 00:36:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14049-05; Wed, 7 Apr 2004 00:36:52 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D46561AD5; Wed, 7 Apr 2004 00:36:50 +0200 (CEST) Date: Tue, 06 Apr 2004 14:19:55 -0700 From: Harald Tveit Alvestrand To: Alexandru Petrescu , IETF NEMO WG Message-ID: <330238417.1081261195@localhost> In-Reply-To: <406C3E48.6010207@motorola.com> References: <406C3E48.6010207@motorola.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no 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: 7bit Subject: [nemo] Re: issue 35 on Error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex, I've checked back with Michael - he says that to the limit of his understanding, either change would work - it's the WG's business to decide which one you take.... thanks! Harald --On 1. april 2004 18:07 +0200 Alexandru Petrescu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [repost to include CC] > > IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): >| In section 6.6 under a certain condition (which is independent of >| whether implicit or explicit mode is in use) it describes sending >| error status code 140. However, in the description of what a MR does >| with responses in explicit mode, error code 140 implies discard >| response. If the MR is going to discard it, why send it? The MR >| needs to know there was a problem, so I think the fix is to make it >| process these. > > Right. The idea of MR dropping BAck 140 in explicit mode was to have > the loop stopped, I'll explain below "loop". However, since this is the > third time this issue comes up, I agree with having MR process BAck 140 > explicit (or have HA send BAck 141 explicit) (two different ways). > > Idea of "loop" was that MR starts sending BU's implicit, gets back > negative BAcks, then sends BU's explicit, and if still error then stop, > avoid re-starting to send BU's implicit. But this loop could still be > avoided with the suggested modifciations. > > Alex > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAbD5IMmC0w56zj54RApLoAJ9Qgad1KKYPWwZ5ADJTvBOL+VM54QCg5oIw > I1zncBHxWNNohB53qwTI208= > =d6eJ > -----END PGP SIGNATURE----- > > From exim@www1.ietf.org Wed Apr 7 20:29:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22097 for ; Wed, 7 Apr 2004 20:29:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNPS-00041d-3m for nemo-archive@odin.ietf.org; Wed, 07 Apr 2004 20:28:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i380SkBG015474 for nemo-archive@odin.ietf.org; Wed, 7 Apr 2004 20:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNPR-00041R-P2 for nemo-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 20:28:46 -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 UAA22008 for ; Wed, 7 Apr 2004 20:28:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNPP-0002aV-00 for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 20:28:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBL5q-000475-00 for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 18:00:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBJrV-0007HV-01 for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 16:41:29 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBJfV-0001V7-Jj for nemo-web-archive@ietf.org; Wed, 07 Apr 2004 16:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBJfS-0004GS-BF; Wed, 07 Apr 2004 16:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0hK-0005RJ-Bz for nemo@optimus.ietf.org; Tue, 06 Apr 2004 20:13:42 -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 UAA16936 for ; Tue, 6 Apr 2004 20:13:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0hI-0001cp-00 for nemo@ietf.org; Tue, 06 Apr 2004 20:13:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0AG-0004CI-00 for nemo@ietf.org; Tue, 06 Apr 2004 19:39:32 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1BAzCA-0005B1-00 for nemo@ietf.org; Tue, 06 Apr 2004 18:37:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 284F861B94; Wed, 7 Apr 2004 00:36:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14049-05; Wed, 7 Apr 2004 00:36:52 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D46561AD5; Wed, 7 Apr 2004 00:36:50 +0200 (CEST) Date: Tue, 06 Apr 2004 14:19:55 -0700 From: Harald Tveit Alvestrand To: Alexandru Petrescu , IETF NEMO WG Message-ID: <330238417.1081261195@localhost> In-Reply-To: <406C3E48.6010207@motorola.com> References: <406C3E48.6010207@motorola.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Content-Transfer-Encoding: 7bit Subject: [nemo] Re: issue 35 on Error in error processing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit Alex, I've checked back with Michael - he says that to the limit of his understanding, either change would work - it's the WG's business to decide which one you take.... thanks! Harald --On 1. april 2004 18:07 +0200 Alexandru Petrescu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [repost to include CC] > > IESG Reviewers H. Alvestrand and Michael Patton (GEN-ART rev): >| In section 6.6 under a certain condition (which is independent of >| whether implicit or explicit mode is in use) it describes sending >| error status code 140. However, in the description of what a MR does >| with responses in explicit mode, error code 140 implies discard >| response. If the MR is going to discard it, why send it? The MR >| needs to know there was a problem, so I think the fix is to make it >| process these. > > Right. The idea of MR dropping BAck 140 in explicit mode was to have > the loop stopped, I'll explain below "loop". However, since this is the > third time this issue comes up, I agree with having MR process BAck 140 > explicit (or have HA send BAck 141 explicit) (two different ways). > > Idea of "loop" was that MR starts sending BU's implicit, gets back > negative BAcks, then sends BU's explicit, and if still error then stop, > avoid re-starting to send BU's implicit. But this loop could still be > avoided with the suggested modifciations. > > Alex > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAbD5IMmC0w56zj54RApLoAJ9Qgad1KKYPWwZ5ADJTvBOL+VM54QCg5oIw > I1zncBHxWNNohB53qwTI208= > =d6eJ > -----END PGP SIGNATURE----- > > From nemo-admin@ietf.org Wed Apr 14 23:00:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13081 for ; Wed, 14 Apr 2004 23:00:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx4i-0006Uj-QO; Wed, 14 Apr 2004 22:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx0d-0005YT-Q4 for nemo@optimus.ietf.org; Wed, 14 Apr 2004 22:53:48 -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 WAA12849 for ; Wed, 14 Apr 2004 22:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx0a-0001g0-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwzh-0001dM-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:52:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BDwz1-0001YQ-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:52:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3F2pQx14017; Wed, 14 Apr 2004 19:51:26 -0700 X-mProtect: <200404150251> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWgSukK; Wed, 14 Apr 2004 19:51:24 PDT Message-ID: <407DEDE3.20209@iprg.nokia.com> Date: Wed, 14 Apr 2004 19:05:23 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO References: In-Reply-To: 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I dont see any concensus on this thread. I ofcourse favor removing this sentence. Vijay Soliman Hesham wrote: > > > > > => Nemo extends the BU but AFAICS it doesn't exclude using > > > it for host mobility. I think this would be a mistake. > > > > You missed my point. > > > > I wanted to say that > > when a MR uses the same HoA, the MR should not send both a normal BU > > (without R flag) and a BU with R-flag simultaneously for the > > same HoA. > > We should prohibit sending normal Binding Updates to HA for MR's HoA. > > => Sorry, it wasn't clear to me. Of course I agree with that. > It's one BU, loaded with whatever extensions a node needs. > > Hesham > > ======================================================== > 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. > ======================================================== > > From nemo-admin@ietf.org Wed Apr 14 23:03:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13197 for ; Wed, 14 Apr 2004 23:03:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx5h-0006qE-1q; Wed, 14 Apr 2004 22:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx3g-00064e-E3 for nemo@optimus.ietf.org; Wed, 14 Apr 2004 22:56:56 -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 WAA12904 for ; Wed, 14 Apr 2004 22:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx3c-0001pA-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:56:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDx3E-0001lY-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:56:29 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BDx1p-0001hQ-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:55:01 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 22:54:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Wed, 14 Apr 2004 22:54:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQilJGrM8n5QZTPQbaQZt1Fmh60CwAAP/8g From: "Soliman Hesham" To: "Vijay Devarapalli" CC: "Ryuji Wakikawa" , X-OriginalArrivalTime: 15 Apr 2004 02:54:30.0594 (UTC) FILETIME=[F9479A20:01C42294] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I dont see any concensus on this thread.=20 =3D> Who disagreed? I'll go thru emails again but I don't recall anyone disagreeing. I ofcourse > favor removing this sentence. =3D> ok. Hesham >=20 > Vijay >=20 > Soliman Hesham wrote: > >=20 > >=20 > > > > =3D> Nemo extends the BU but AFAICS it doesn't exclude using=20 > > > > it for host mobility. I think this would be a mistake. > > >=20 > > > You missed my point.=20 > > >=20 > > > I wanted to say that=20 > > > when a MR uses the same HoA, the MR should not send=20 > both a normal BU > > > (without R flag) and a BU with R-flag simultaneously for the=20 > > > same HoA. > > > We should prohibit sending normal Binding Updates to HA=20 > for MR's HoA. > >=20 > > =3D> Sorry, it wasn't clear to me. Of course I agree with that. > > It's one BU, loaded with whatever extensions a node needs. > >=20 > > Hesham > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole > > use of the intended recipient. Any review or distribution=20 > by others is=20 > > strictly prohibited. If you are not the intended=20 > 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 > >=20 > >=20 >=20 >=20 From exim@www1.ietf.org Wed Apr 14 23:08:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13405 for ; Wed, 14 Apr 2004 23:08:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxCa-0000Wc-SU for nemo-archive@odin.ietf.org; Wed, 14 Apr 2004 23:06:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F368Ov001998 for nemo-archive@odin.ietf.org; Wed, 14 Apr 2004 23:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx8M-0007fc-0a for nemo-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 23:01:46 -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 XAA13138 for ; Wed, 14 Apr 2004 23:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx8I-00029l-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:01:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDx7L-00025S-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:00:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDx6O-00020J-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 22:59:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx4i-0006Uj-QO; Wed, 14 Apr 2004 22:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx0d-0005YT-Q4 for nemo@optimus.ietf.org; Wed, 14 Apr 2004 22:53:48 -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 WAA12849 for ; Wed, 14 Apr 2004 22:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx0a-0001g0-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDwzh-0001dM-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:52:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BDwz1-0001YQ-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:52:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3F2pQx14017; Wed, 14 Apr 2004 19:51:26 -0700 X-mProtect: <200404150251> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWgSukK; Wed, 14 Apr 2004 19:51:24 PDT Message-ID: <407DEDE3.20209@iprg.nokia.com> Date: Wed, 14 Apr 2004 19:05:23 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit I dont see any concensus on this thread. I ofcourse favor removing this sentence. Vijay Soliman Hesham wrote: > > > > > => Nemo extends the BU but AFAICS it doesn't exclude using > > > it for host mobility. I think this would be a mistake. > > > > You missed my point. > > > > I wanted to say that > > when a MR uses the same HoA, the MR should not send both a normal BU > > (without R flag) and a BU with R-flag simultaneously for the > > same HoA. > > We should prohibit sending normal Binding Updates to HA for MR's HoA. > > => Sorry, it wasn't clear to me. Of course I agree with that. > It's one BU, loaded with whatever extensions a node needs. > > Hesham > > ======================================================== > 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. > ======================================================== > > From exim@www1.ietf.org Wed Apr 14 23:17:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13671 for ; Wed, 14 Apr 2004 23:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxF9-0001W8-U8 for nemo-archive@odin.ietf.org; Wed, 14 Apr 2004 23:08:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F38lQh005826 for nemo-archive@odin.ietf.org; Wed, 14 Apr 2004 23:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxDL-0000jk-Vm for nemo-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 23:06:56 -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 XAA13269 for ; Wed, 14 Apr 2004 23:06:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDxDG-0002Ro-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:06:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDxBM-0002KW-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:04:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDxA0-0002F3-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:03:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx5h-0006qE-1q; Wed, 14 Apr 2004 22:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDx3g-00064e-E3 for nemo@optimus.ietf.org; Wed, 14 Apr 2004 22:56:56 -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 WAA12904 for ; Wed, 14 Apr 2004 22:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDx3c-0001pA-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:56:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDx3E-0001lY-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:56:29 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1BDx1p-0001hQ-00 for nemo@ietf.org; Wed, 14 Apr 2004 22:55:01 -0400 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 22:54:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Date: Wed, 14 Apr 2004 22:54:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO Thread-Index: AcQilJGrM8n5QZTPQbaQZt1Fmh60CwAAP/8g From: "Soliman Hesham" To: "Vijay Devarapalli" CC: "Ryuji Wakikawa" , X-OriginalArrivalTime: 15 Apr 2004 02:54:30.0594 (UTC) FILETIME=[F9479A20:01C42294] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > I dont see any concensus on this thread.=20 =3D> Who disagreed? I'll go thru emails again but I don't recall anyone disagreeing. I ofcourse > favor removing this sentence. =3D> ok. Hesham >=20 > Vijay >=20 > Soliman Hesham wrote: > >=20 > >=20 > > > > =3D> Nemo extends the BU but AFAICS it doesn't exclude using=20 > > > > it for host mobility. I think this would be a mistake. > > >=20 > > > You missed my point.=20 > > >=20 > > > I wanted to say that=20 > > > when a MR uses the same HoA, the MR should not send=20 > both a normal BU > > > (without R flag) and a BU with R-flag simultaneously for the=20 > > > same HoA. > > > We should prohibit sending normal Binding Updates to HA=20 > for MR's HoA. > >=20 > > =3D> Sorry, it wasn't clear to me. Of course I agree with that. > > It's one BU, loaded with whatever extensions a node needs. > >=20 > > Hesham > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole > > use of the intended recipient. Any review or distribution=20 > by others is=20 > > strictly prohibited. If you are not the intended=20 > 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 > >=20 > >=20 >=20 >=20 From nemo-admin@ietf.org Wed Apr 14 23:28:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14069 for ; Wed, 14 Apr 2004 23:28:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxUs-0004xs-72; Wed, 14 Apr 2004 23:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxS4-0004VM-SK for nemo@optimus.ietf.org; Wed, 14 Apr 2004 23:22:08 -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 XAA13857 for ; Wed, 14 Apr 2004 23:22:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDxS2-0003PY-00 for nemo@ietf.org; Wed, 14 Apr 2004 23:22:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDxR3-0003KU-00 for nemo@ietf.org; Wed, 14 Apr 2004 23:21:07 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BDxQB-0003Br-00 for nemo@ietf.org; Wed, 14 Apr 2004 23:20:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3F3JYq27471; Wed, 14 Apr 2004 20:19:34 -0700 X-mProtect: <200404150319> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsFEMhE; Wed, 14 Apr 2004 20:19:32 PDT Message-ID: <407DF47C.3060301@iprg.nokia.com> Date: Wed, 14 Apr 2004 19:33:32 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: harald@alvestrand.no CC: margaret@thingmagic.com, nemo@ietf.org 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 Subject: [nemo] Michael's comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Michael and Harald, thanks for your review and comments. > Technical Problems > ------------------ > > In at least two places they have a requirement that a mobile router > that advertises it's network when at home must never advertise this > prefix on a visited network. This is a requirement which cannot, in > practice, be met in all cases. A periodic routing packet could be > sent in the interval between when the connectivity changes and the > router discovers that fact (think atmospheric effects on radio > transmission, or an Ethernet switch having the VLAN allocations > changed). once the mobile router realizes it is no longer on the Home Link, it should not advertise the Mobile Network Prefix in the visited link. we dont want the mobile router to disseminate wrong prefix information in the visited network. the mobile router recognizes that it is not longer on the home link based on the prefix information in the router advertisements advertised by the routers on the visited link. > > In section 6.6 under a certain condition (which is independent of > whether implicit or explicit mode is in use) it describes sending error > status code 140. However, in the description of what a MR does with > responses in explicit mode, error code 140 implies discard response. > If the MR is going to discard it, why send it? The MR needs to know > there was a problem, so I think the fix is to make it process these. you are right. this is a slip. Steve Bellovin also spotted it. the MR should process 140 in both implicit and explicit mode. this has been fixed now. > Other problems with the document > -------------------------------- > > Both sections 5.2 and 6.2 talk about only implicit and explicit modes > of operation and ignore dynamic routing. This case needs to be > covered in these sections as well. fixed this. > > In some places it says a success is indicated by a status code of 0 > while in others it says any code from 0-127 is success. It needs to > get that right everywhere. I couldnt find this. we do say that the success status is 0. in the Mobile IPv6 specification, 0-127 does indicate success, but anything other than 0 means the binding update was processed succesfully, but the Mobile Node has to do something in addition. this spec does not introduce any new status values between 0 and 127. status values greater than 127 indicate that the binding update was not processed succesfully. > > Section 5.4 has a lot of wording problems, not the least of which is > the frequent use of the word "should" in lower case. I'm not sure if > they want them to be SHOULD, if not I advise use of a different word, > and if so, fix it. I rewrote section 5.4 a bit. the new text is at http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre03.txt > > In the second paragraph of 5.5 they talk about the single > bi-directional tunnel and two simplex tunnels. They need to get their > terminology straight. RFC 2473 Bi-directional tunneling is achieved by merging two unidirectional mechanisms, that is, configuring two tunnels, each in opposite direction to the other - the entry-point node of one tunnel is the exit-point node of the other tunnel (see Fig.2). we should probably just point to this text and not try to rephrase it. > > The second one of the ticked items in 6.2 (i.e. the second indented > thing with a "-" in front) I just didn't get. I read it several > times, took a break, came back and read it several more times. After > that, it still wasn't clear to me what it was doing there. My > understanding of the words always resulted in either a tautology or a > non-sequitur, neither of which could have been their intent. in Mobile IPv6, the Home Agent rejects a binding update if the home address in the binding update is not configured from the prefix advertised on the home link. in NEMO, a mobile router could configure a home address from the prefix advertised in the Mobile Network. the prefix on the Mobile Network is always different from the prefix advertised on the home link. so we relaxing the MIPv6 requirement. the home agent only has to make sure that the home address belongs to the aggregated prefix that it is configured to serve. the aggregated prefix here includes the home prefix and all prefixes delegated to the all mobile routers that the home agent is currently supporting. > > In the third paragraph under section 5, the wording is quite strange. > I'm not sure what they are doing without more research than I have > time for, but my guess is that they are saying at the end that under a > specific set of criteria, they are relaxing a MUST in another document > to a MAY, but they need to be clearer on the intent. yup. I will add some text clarifying this. > > In section 8 they describe a requirement for confidentiality (and > there may be confidentiality aspects to other parts of the operation), > but there is no mention of confidentiality in the "Security > Considerations". I think there are other things that need to be in > there, too, but leave more detailed critique to the Security Area. good catch. added some text in the Security Considerations section. > > There are two sections titled "References", neither of which has a > section number or appears in the TOC. My first guess was that one was > supposed to be normative and the other informative, but if that's so > they have several references misfiled (5 is info not norm, 8&9 are > norm). moved 5 to informative. I dont think the two terminology documents should be normative. I made sure that this spec is self-contained with respect to terminilogy. you can get a better idea of what Mobile Routers are by looking up the terminology documents. that is why they are informative. > In several places they talk about operation in the various modes, but > never really say how a node decides which. I realize that the intent > is that it's locally configured in the MR, but I think it deserves > being explicitly said somewhere. this depends on local configuration on the mobile router. I will add some text making this more explicit. thanks again for the thorough review. Vijay ps: your comments are files as issue 35 at http://people.nokia.net/vijayd/nemo/issues.html From exim@www1.ietf.org Wed Apr 14 23:37:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14521 for ; Wed, 14 Apr 2004 23:37:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxfx-0007Uq-76 for nemo-archive@odin.ietf.org; Wed, 14 Apr 2004 23:36:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F3aTdX028812 for nemo-archive@odin.ietf.org; Wed, 14 Apr 2004 23:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxZR-0005zd-9D for nemo-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 23:29:45 -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 XAA14087 for ; Wed, 14 Apr 2004 23:29:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDxZP-0003nX-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:29:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDxYQ-0003lP-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:28:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDxXY-0003jp-00 for nemo-web-archive@ietf.org; Wed, 14 Apr 2004 23:27:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxUs-0004xs-72; Wed, 14 Apr 2004 23:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDxS4-0004VM-SK for nemo@optimus.ietf.org; Wed, 14 Apr 2004 23:22:08 -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 XAA13857 for ; Wed, 14 Apr 2004 23:22:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDxS2-0003PY-00 for nemo@ietf.org; Wed, 14 Apr 2004 23:22:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDxR3-0003KU-00 for nemo@ietf.org; Wed, 14 Apr 2004 23:21:07 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BDxQB-0003Br-00 for nemo@ietf.org; Wed, 14 Apr 2004 23:20:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3F3JYq27471; Wed, 14 Apr 2004 20:19:34 -0700 X-mProtect: <200404150319> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsFEMhE; Wed, 14 Apr 2004 20:19:32 PDT Message-ID: <407DF47C.3060301@iprg.nokia.com> Date: Wed, 14 Apr 2004 19:33:32 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: harald@alvestrand.no CC: margaret@thingmagic.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Michael's comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit hi Michael and Harald, thanks for your review and comments. > Technical Problems > ------------------ > > In at least two places they have a requirement that a mobile router > that advertises it's network when at home must never advertise this > prefix on a visited network. This is a requirement which cannot, in > practice, be met in all cases. A periodic routing packet could be > sent in the interval between when the connectivity changes and the > router discovers that fact (think atmospheric effects on radio > transmission, or an Ethernet switch having the VLAN allocations > changed). once the mobile router realizes it is no longer on the Home Link, it should not advertise the Mobile Network Prefix in the visited link. we dont want the mobile router to disseminate wrong prefix information in the visited network. the mobile router recognizes that it is not longer on the home link based on the prefix information in the router advertisements advertised by the routers on the visited link. > > In section 6.6 under a certain condition (which is independent of > whether implicit or explicit mode is in use) it describes sending error > status code 140. However, in the description of what a MR does with > responses in explicit mode, error code 140 implies discard response. > If the MR is going to discard it, why send it? The MR needs to know > there was a problem, so I think the fix is to make it process these. you are right. this is a slip. Steve Bellovin also spotted it. the MR should process 140 in both implicit and explicit mode. this has been fixed now. > Other problems with the document > -------------------------------- > > Both sections 5.2 and 6.2 talk about only implicit and explicit modes > of operation and ignore dynamic routing. This case needs to be > covered in these sections as well. fixed this. > > In some places it says a success is indicated by a status code of 0 > while in others it says any code from 0-127 is success. It needs to > get that right everywhere. I couldnt find this. we do say that the success status is 0. in the Mobile IPv6 specification, 0-127 does indicate success, but anything other than 0 means the binding update was processed succesfully, but the Mobile Node has to do something in addition. this spec does not introduce any new status values between 0 and 127. status values greater than 127 indicate that the binding update was not processed succesfully. > > Section 5.4 has a lot of wording problems, not the least of which is > the frequent use of the word "should" in lower case. I'm not sure if > they want them to be SHOULD, if not I advise use of a different word, > and if so, fix it. I rewrote section 5.4 a bit. the new text is at http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre03.txt > > In the second paragraph of 5.5 they talk about the single > bi-directional tunnel and two simplex tunnels. They need to get their > terminology straight. RFC 2473 Bi-directional tunneling is achieved by merging two unidirectional mechanisms, that is, configuring two tunnels, each in opposite direction to the other - the entry-point node of one tunnel is the exit-point node of the other tunnel (see Fig.2). we should probably just point to this text and not try to rephrase it. > > The second one of the ticked items in 6.2 (i.e. the second indented > thing with a "-" in front) I just didn't get. I read it several > times, took a break, came back and read it several more times. After > that, it still wasn't clear to me what it was doing there. My > understanding of the words always resulted in either a tautology or a > non-sequitur, neither of which could have been their intent. in Mobile IPv6, the Home Agent rejects a binding update if the home address in the binding update is not configured from the prefix advertised on the home link. in NEMO, a mobile router could configure a home address from the prefix advertised in the Mobile Network. the prefix on the Mobile Network is always different from the prefix advertised on the home link. so we relaxing the MIPv6 requirement. the home agent only has to make sure that the home address belongs to the aggregated prefix that it is configured to serve. the aggregated prefix here includes the home prefix and all prefixes delegated to the all mobile routers that the home agent is currently supporting. > > In the third paragraph under section 5, the wording is quite strange. > I'm not sure what they are doing without more research than I have > time for, but my guess is that they are saying at the end that under a > specific set of criteria, they are relaxing a MUST in another document > to a MAY, but they need to be clearer on the intent. yup. I will add some text clarifying this. > > In section 8 they describe a requirement for confidentiality (and > there may be confidentiality aspects to other parts of the operation), > but there is no mention of confidentiality in the "Security > Considerations". I think there are other things that need to be in > there, too, but leave more detailed critique to the Security Area. good catch. added some text in the Security Considerations section. > > There are two sections titled "References", neither of which has a > section number or appears in the TOC. My first guess was that one was > supposed to be normative and the other informative, but if that's so > they have several references misfiled (5 is info not norm, 8&9 are > norm). moved 5 to informative. I dont think the two terminology documents should be normative. I made sure that this spec is self-contained with respect to terminilogy. you can get a better idea of what Mobile Routers are by looking up the terminology documents. that is why they are informative. > In several places they talk about operation in the various modes, but > never really say how a node decides which. I realize that the intent > is that it's locally configured in the MR, but I think it deserves > being explicitly said somewhere. this depends on local configuration on the mobile router. I will add some text making this more explicit. thanks again for the thorough review. Vijay ps: your comments are files as issue 35 at http://people.nokia.net/vijayd/nemo/issues.html From nemo-admin@ietf.org Thu Apr 15 03:03:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06304 for ; Thu, 15 Apr 2004 03:03:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0n3-0007SL-1t; Thu, 15 Apr 2004 02:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0eO-0005Ac-Qf for nemo@optimus.ietf.org; Thu, 15 Apr 2004 02:47: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 CAA05518 for ; Thu, 15 Apr 2004 02:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0eL-000199-00 for nemo@ietf.org; Thu, 15 Apr 2004 02:47:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0dP-00014d-00 for nemo@ietf.org; Thu, 15 Apr 2004 02:46:04 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BE0ch-0000yg-00 for nemo@ietf.org; Thu, 15 Apr 2004 02:45:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3F6iiH07512; Wed, 14 Apr 2004 23:44:44 -0700 X-mProtect: <200404150644> Nokia Silicon Valley Messaging Protection Received: from danira-pool05018.americas.nokia.com (10.241.50.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd93tUVw; Wed, 14 Apr 2004 23:44:42 PDT Message-ID: <407E2F4C.2080909@iprg.nokia.com> Date: Wed, 14 Apr 2004 23:44:28 -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: Harald Tveit Alvestrand CC: margaret@thingmagic.com, nemo@ietf.org References: <407DF47C.3060301@iprg.nokia.com> <634093478.1081983012@localhost> In-Reply-To: <634093478.1081983012@localhost> 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 Subject: [nemo] Re: Michael's comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > Thanks for the update! > > --On 14. april 2004 19:33 -0700 Vijay Devarapalli > wrote: > >> hi Michael and Harald, >> >> thanks for your review and comments. >> >>> Technical Problems >>> ------------------ >>> >>> In at least two places they have a requirement that a mobile router >>> that advertises it's network when at home must never advertise this >>> prefix on a visited network. This is a requirement which cannot, in >>> practice, be met in all cases. A periodic routing packet could be >>> sent in the interval between when the connectivity changes and the >>> router discovers that fact (think atmospheric effects on radio >>> transmission, or an Ethernet switch having the VLAN allocations >>> changed). >> >> >> once the mobile router realizes it is no longer on the >> Home Link, it should not advertise the Mobile Network >> Prefix in the visited link. we dont want the mobile router >> to disseminate wrong prefix information in the visited >> network. >> >> the mobile router recognizes that it is not longer on the >> home link based on the prefix information in the router >> advertisements advertised by the routers on the visited >> link. > > > so the requirement is that "once the mobile router realizes it is no > longer on the home link, it MUST NOT advertise the Mobile Network Prefix"? right, this was the intention. Vijay > > I think that's sensible, and certainly looks implementable to me. It was > the requirement to do it before realizing that the move had happened > that was iffy.... > > Harald > > > > From exim@www1.ietf.org Thu Apr 15 03:07:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06540 for ; Thu, 15 Apr 2004 03:07:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0wh-0001q2-Tb for nemo-archive@odin.ietf.org; Thu, 15 Apr 2004 03:05:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F75xnP007067 for nemo-archive@odin.ietf.org; Thu, 15 Apr 2004 03:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0vh-0001O0-K8 for nemo-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 03:04:57 -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 DAA06369 for ; Thu, 15 Apr 2004 03:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0vd-0002WZ-00 for nemo-web-archive@ietf.org; Thu, 15 Apr 2004 03:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0uj-0002TD-00 for nemo-web-archive@ietf.org; Thu, 15 Apr 2004 03:03:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE0tx-0002QC-00 for nemo-web-archive@ietf.org; Thu, 15 Apr 2004 03:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0n3-0007SL-1t; Thu, 15 Apr 2004 02:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0eO-0005Ac-Qf for nemo@optimus.ietf.org; Thu, 15 Apr 2004 02:47: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 CAA05518 for ; Thu, 15 Apr 2004 02:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0eL-000199-00 for nemo@ietf.org; Thu, 15 Apr 2004 02:47:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0dP-00014d-00 for nemo@ietf.org; Thu, 15 Apr 2004 02:46:04 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BE0ch-0000yg-00 for nemo@ietf.org; Thu, 15 Apr 2004 02:45:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3F6iiH07512; Wed, 14 Apr 2004 23:44:44 -0700 X-mProtect: <200404150644> Nokia Silicon Valley Messaging Protection Received: from danira-pool05018.americas.nokia.com (10.241.50.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd93tUVw; Wed, 14 Apr 2004 23:44:42 PDT Message-ID: <407E2F4C.2080909@iprg.nokia.com> Date: Wed, 14 Apr 2004 23:44:28 -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: Harald Tveit Alvestrand CC: margaret@thingmagic.com, nemo@ietf.org References: <407DF47C.3060301@iprg.nokia.com> <634093478.1081983012@localhost> In-Reply-To: <634093478.1081983012@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Michael's comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > > Thanks for the update! > > --On 14. april 2004 19:33 -0700 Vijay Devarapalli > wrote: > >> hi Michael and Harald, >> >> thanks for your review and comments. >> >>> Technical Problems >>> ------------------ >>> >>> In at least two places they have a requirement that a mobile router >>> that advertises it's network when at home must never advertise this >>> prefix on a visited network. This is a requirement which cannot, in >>> practice, be met in all cases. A periodic routing packet could be >>> sent in the interval between when the connectivity changes and the >>> router discovers that fact (think atmospheric effects on radio >>> transmission, or an Ethernet switch having the VLAN allocations >>> changed). >> >> >> once the mobile router realizes it is no longer on the >> Home Link, it should not advertise the Mobile Network >> Prefix in the visited link. we dont want the mobile router >> to disseminate wrong prefix information in the visited >> network. >> >> the mobile router recognizes that it is not longer on the >> home link based on the prefix information in the router >> advertisements advertised by the routers on the visited >> link. > > > so the requirement is that "once the mobile router realizes it is no > longer on the home link, it MUST NOT advertise the Mobile Network Prefix"? right, this was the intention. Vijay > > I think that's sensible, and certainly looks implementable to me. It was > the requirement to do it before realizing that the move had happened > that was iffy.... > > Harald > > > > From nemo-admin@ietf.org Thu Apr 15 04:07:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09628 for ; Thu, 15 Apr 2004 04:07:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1i9-0001Ka-HB; Thu, 15 Apr 2004 03:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzsm-0006qP-LP for nemo@optimus.ietf.org; Thu, 15 Apr 2004 01:57:52 -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 BAA19633 for ; Thu, 15 Apr 2004 01:57:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzsj-0005Op-00 for nemo@ietf.org; Thu, 15 Apr 2004 01:57:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzrm-0005M6-00 for nemo@ietf.org; Thu, 15 Apr 2004 01:56:51 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1BDzqt-0005Fq-00 for nemo@ietf.org; Thu, 15 Apr 2004 01:55:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E170621B1; Thu, 15 Apr 2004 07:55:26 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26605-07; Thu, 15 Apr 2004 07:55:25 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC63361DEB; Thu, 15 Apr 2004 07:55:23 +0200 (CEST) Date: Wed, 14 Apr 2004 22:50:12 -0700 From: Harald Tveit Alvestrand To: Vijay Devarapalli Cc: margaret@thingmagic.com, nemo@ietf.org Message-ID: <634093478.1081983012@localhost> In-Reply-To: <407DF47C.3060301@iprg.nokia.com> References: <407DF47C.3060301@iprg.nokia.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no 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: 7bit Subject: [nemo] Re: Michael's comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for the update! --On 14. april 2004 19:33 -0700 Vijay Devarapalli wrote: > hi Michael and Harald, > > thanks for your review and comments. > >> Technical Problems >> ------------------ >> >> In at least two places they have a requirement that a mobile router >> that advertises it's network when at home must never advertise this >> prefix on a visited network. This is a requirement which cannot, in >> practice, be met in all cases. A periodic routing packet could be >> sent in the interval between when the connectivity changes and the >> router discovers that fact (think atmospheric effects on radio >> transmission, or an Ethernet switch having the VLAN allocations >> changed). > > once the mobile router realizes it is no longer on the > Home Link, it should not advertise the Mobile Network > Prefix in the visited link. we dont want the mobile router > to disseminate wrong prefix information in the visited > network. > > the mobile router recognizes that it is not longer on the > home link based on the prefix information in the router > advertisements advertised by the routers on the visited > link. so the requirement is that "once the mobile router realizes it is no longer on the home link, it MUST NOT advertise the Mobile Network Prefix"? I think that's sensible, and certainly looks implementable to me. It was the requirement to do it before realizing that the move had happened that was iffy.... Harald From exim@www1.ietf.org Thu Apr 15 04:14:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10507 for ; Thu, 15 Apr 2004 04:14:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1xI-0005uV-IQ for nemo-archive@odin.ietf.org; Thu, 15 Apr 2004 04:10:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F8AeZO022719 for nemo-archive@odin.ietf.org; Thu, 15 Apr 2004 04:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1vc-0004qO-1m for nemo-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 04:08:56 -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 EAA09794 for ; Thu, 15 Apr 2004 04:08:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1vZ-00002J-00 for nemo-web-archive@ietf.org; Thu, 15 Apr 2004 04:08:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1ub-0007l2-00 for nemo-web-archive@ietf.org; Thu, 15 Apr 2004 04:07:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE1tc-0007fi-00 for nemo-web-archive@ietf.org; Thu, 15 Apr 2004 04:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1i9-0001Ka-HB; Thu, 15 Apr 2004 03:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDzsm-0006qP-LP for nemo@optimus.ietf.org; Thu, 15 Apr 2004 01:57:52 -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 BAA19633 for ; Thu, 15 Apr 2004 01:57:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDzsj-0005Op-00 for nemo@ietf.org; Thu, 15 Apr 2004 01:57:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDzrm-0005M6-00 for nemo@ietf.org; Thu, 15 Apr 2004 01:56:51 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1BDzqt-0005Fq-00 for nemo@ietf.org; Thu, 15 Apr 2004 01:55:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E170621B1; Thu, 15 Apr 2004 07:55:26 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26605-07; Thu, 15 Apr 2004 07:55:25 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC63361DEB; Thu, 15 Apr 2004 07:55:23 +0200 (CEST) Date: Wed, 14 Apr 2004 22:50:12 -0700 From: Harald Tveit Alvestrand To: Vijay Devarapalli Cc: margaret@thingmagic.com, nemo@ietf.org Message-ID: <634093478.1081983012@localhost> In-Reply-To: <407DF47C.3060301@iprg.nokia.com> References: <407DF47C.3060301@iprg.nokia.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Michael's comments on NEMO spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit Thanks for the update! --On 14. april 2004 19:33 -0700 Vijay Devarapalli wrote: > hi Michael and Harald, > > thanks for your review and comments. > >> Technical Problems >> ------------------ >> >> In at least two places they have a requirement that a mobile router >> that advertises it's network when at home must never advertise this >> prefix on a visited network. This is a requirement which cannot, in >> practice, be met in all cases. A periodic routing packet could be >> sent in the interval between when the connectivity changes and the >> router discovers that fact (think atmospheric effects on radio >> transmission, or an Ethernet switch having the VLAN allocations >> changed). > > once the mobile router realizes it is no longer on the > Home Link, it should not advertise the Mobile Network > Prefix in the visited link. we dont want the mobile router > to disseminate wrong prefix information in the visited > network. > > the mobile router recognizes that it is not longer on the > home link based on the prefix information in the router > advertisements advertised by the routers on the visited > link. so the requirement is that "once the mobile router realizes it is no longer on the home link, it MUST NOT advertise the Mobile Network Prefix"? I think that's sensible, and certainly looks implementable to me. It was the requirement to do it before realizing that the move had happened that was iffy.... Harald From nemo-admin@ietf.org Fri Apr 16 05:20:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25355 for ; Fri, 16 Apr 2004 05:20:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPRA-0006RE-PF; Fri, 16 Apr 2004 05:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPOA-0005lc-Ml for nemo@optimus.ietf.org; Fri, 16 Apr 2004 05:11:58 -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 FAA24927 for ; Fri, 16 Apr 2004 05:11:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPO7-0007DJ-9o for nemo@ietf.org; Fri, 16 Apr 2004 05:11:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPNG-00077k-00 for nemo@ietf.org; Fri, 16 Apr 2004 05:11:03 -0400 Received: from web25007.mail.ukl.yahoo.com ([217.12.10.43]) by ietf-mx with smtp (Exim 4.12) id 1BEPMP-0006vK-00 for nemo@ietf.org; Fri, 16 Apr 2004 05:10:09 -0400 Message-ID: <20040416090933.62421.qmail@web25007.mail.ukl.yahoo.com> Received: from [137.194.192.85] by web25007.mail.ukl.yahoo.com via HTTP; Fri, 16 Apr 2004 11:09:33 CEST Date: Fri, 16 Apr 2004 11:09:33 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= To: nemo@ietf.org In-Reply-To: <20040415160005.14074.91754.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA24930 Subject: [nemo] Re: Question-HAHA Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In some drafts they propose to change mobile node's Home Agent (or the primary home Agent in=20 HA-HA protocol).=20 I read many documents on the nemo support but I could not answer this question : when a mobile node changes its home Agent does it have to change moreover its home address ? =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com From exim@www1.ietf.org Fri Apr 16 05:29:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25583 for ; Fri, 16 Apr 2004 05:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPbB-0008Ap-PL for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 05:25:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G9PPcS031411 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 05:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPWw-0007TN-GY for nemo-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 05:21: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 FAA25407 for ; Fri, 16 Apr 2004 05:20:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPWt-0000Oz-7K for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 05:20:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPVv-0000Jt-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 05:19:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEPVl-0000F5-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 05:19:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPRA-0006RE-PF; Fri, 16 Apr 2004 05:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPOA-0005lc-Ml for nemo@optimus.ietf.org; Fri, 16 Apr 2004 05:11:58 -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 FAA24927 for ; Fri, 16 Apr 2004 05:11:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPO7-0007DJ-9o for nemo@ietf.org; Fri, 16 Apr 2004 05:11:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPNG-00077k-00 for nemo@ietf.org; Fri, 16 Apr 2004 05:11:03 -0400 Received: from web25007.mail.ukl.yahoo.com ([217.12.10.43]) by ietf-mx with smtp (Exim 4.12) id 1BEPMP-0006vK-00 for nemo@ietf.org; Fri, 16 Apr 2004 05:10:09 -0400 Message-ID: <20040416090933.62421.qmail@web25007.mail.ukl.yahoo.com> Received: from [137.194.192.85] by web25007.mail.ukl.yahoo.com via HTTP; Fri, 16 Apr 2004 11:09:33 CEST Date: Fri, 16 Apr 2004 11:09:33 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= To: nemo@ietf.org In-Reply-To: <20040415160005.14074.91754.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA24930 Subject: [nemo] Re: Question-HAHA Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: quoted-printable Content-Transfer-Encoding: quoted-printable In some drafts they propose to change mobile node's Home Agent (or the primary home Agent in=20 HA-HA protocol).=20 I read many documents on the nemo support but I could not answer this question : when a mobile node changes its home Agent does it have to change moreover its home address ? =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com From nemo-admin@ietf.org Fri Apr 16 07:51:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02486 for ; Fri, 16 Apr 2004 07:51:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERmJ-0007PV-C3; Fri, 16 Apr 2004 07:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERjS-0006ou-MR for nemo@optimus.ietf.org; Fri, 16 Apr 2004 07:42: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 HAA02059 for ; Fri, 16 Apr 2004 07:42:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BERjR-0000oh-Uh for nemo@ietf.org; Fri, 16 Apr 2004 07:42:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BERiT-0000i5-00 for nemo@ietf.org; Fri, 16 Apr 2004 07:41:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BERhi-0000Uh-00 for nemo@ietf.org; Fri, 16 Apr 2004 07:40:18 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2004 04:51:26 -0700 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3GBd5Ah005184; Fri, 16 Apr 2004 07:39:45 -0400 (EDT) Received: from xbe-lon-312.cisco.com ([64.103.99.72]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Apr 2004 13:39:43 +0200 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, 16 Apr 2004 12:39:43 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: Question-HAHA Date: Fri, 16 Apr 2004 12:39:42 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQjk+Cd1ZBR3xkwTtmWMjMSJFZolwAEtjRA From: "Pascal Thubert \(pthubert\)" To: "Mazen TLAIS" , X-OriginalArrivalTime: 16 Apr 2004 11:39:43.0186 (UTC) FILETIME=[82A94B20:01C423A7] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: It depends on the model. If the MR takes its home address from its MNP = then it does not need to. If the Home address is from a home link, then = it needs to change if it takes a home agent on a different home link. = This may happen in the case of Home Agent Global Distribution with the = HAHA protocol. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = Mazen TLAIS > Sent: vendredi 16 avril 2004 11:10 > To: nemo@ietf.org > Subject: [nemo] Re: Question-HAHA >=20 > In some drafts they propose to change mobile node's > Home Agent (or the primary home Agent in > HA-HA protocol). >=20 > I read many documents on the nemo support but I could > not answer this question : >=20 > when a mobile node changes its home Agent does it have > to change moreover its home address ? >=20 >=20 >=20 >=20 >=20 >=20 > Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout = ! > Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ >=20 > Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger = !T=E9l=E9chargez Yahoo! Messenger sur > http://fr.messenger.yahoo.com From exim@www1.ietf.org Fri Apr 16 07:57:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02739 for ; Fri, 16 Apr 2004 07:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERwx-0000xk-EV for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 07:56:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GBu3P0003682 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 07:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERu6-0000SZ-GK for nemo-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 07:53: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 HAA02559 for ; Fri, 16 Apr 2004 07:53:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BERu5-00026q-NE for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 07:53:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BERtC-0001z4-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 07:52:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BERsN-0001sS-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 07:51:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERmJ-0007PV-C3; Fri, 16 Apr 2004 07:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BERjS-0006ou-MR for nemo@optimus.ietf.org; Fri, 16 Apr 2004 07:42: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 HAA02059 for ; Fri, 16 Apr 2004 07:42:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BERjR-0000oh-Uh for nemo@ietf.org; Fri, 16 Apr 2004 07:42:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BERiT-0000i5-00 for nemo@ietf.org; Fri, 16 Apr 2004 07:41:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BERhi-0000Uh-00 for nemo@ietf.org; Fri, 16 Apr 2004 07:40:18 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2004 04:51:26 -0700 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3GBd5Ah005184; Fri, 16 Apr 2004 07:39:45 -0400 (EDT) Received: from xbe-lon-312.cisco.com ([64.103.99.72]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 Apr 2004 13:39:43 +0200 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, 16 Apr 2004 12:39:43 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: Question-HAHA Date: Fri, 16 Apr 2004 12:39:42 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQjk+Cd1ZBR3xkwTtmWMjMSJFZolwAEtjRA From: "Pascal Thubert \(pthubert\)" To: "Mazen TLAIS" , X-OriginalArrivalTime: 16 Apr 2004 11:39:43.0186 (UTC) FILETIME=[82A94B20:01C423A7] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable Hi: It depends on the model. If the MR takes its home address from its MNP = then it does not need to. If the Home address is from a home link, then = it needs to change if it takes a home agent on a different home link. = This may happen in the case of Home Agent Global Distribution with the = HAHA protocol. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = Mazen TLAIS > Sent: vendredi 16 avril 2004 11:10 > To: nemo@ietf.org > Subject: [nemo] Re: Question-HAHA >=20 > In some drafts they propose to change mobile node's > Home Agent (or the primary home Agent in > HA-HA protocol). >=20 > I read many documents on the nemo support but I could > not answer this question : >=20 > when a mobile node changes its home Agent does it have > to change moreover its home address ? >=20 >=20 >=20 >=20 >=20 >=20 > Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout = ! > Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ >=20 > Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger = !T=E9l=E9chargez Yahoo! Messenger sur > http://fr.messenger.yahoo.com From nemo-admin@ietf.org Fri Apr 16 12:57:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21538 for ; Fri, 16 Apr 2004 12:57:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWSd-0003Ev-Rn; Fri, 16 Apr 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWJ7-0008Vr-ED for nemo@optimus.ietf.org; Fri, 16 Apr 2004 12:35:13 -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 MAA19881 for ; Fri, 16 Apr 2004 12:35: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 1BEWJ5-00025r-Mb for nemo@ietf.org; Fri, 16 Apr 2004 12:35:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWIE-00022Z-00 for nemo@ietf.org; Fri, 16 Apr 2004 12:34:18 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BEWHp-00020F-00 for nemo@ietf.org; Fri, 16 Apr 2004 12:33:53 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3GGY47n023405; Fri, 16 Apr 2004 09:34:04 -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 i3GGXnEb018128; Fri, 16 Apr 2004 11:33:49 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9248185C46E; Fri, 16 Apr 2004 18:33:48 +0200 (CEST) Message-ID: <40800AE5.40305@motorola.com> Date: Fri, 16 Apr 2004 18:33:41 +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: "Pascal Thubert (pthubert)" Cc: Mazen TLAIS , nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA References: In-Reply-To: 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="------------ms010100000704020409060908" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms010100000704020409060908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > It depends on the model. If the MR takes its home address from its > MNP then it does not need to. If the Home address is from a home > link, then it needs to change if it takes a home agent on a different > home link. This may happen in the case of Home Agent Global > Distribution with the HAHA protocol. Right, and in all the above cases all app-level communications running on MR or LFN will be interrupted when MR changes its HA, right? Alex --------------ms010100000704020409060908 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTYxNjMzNDFaMCMGCSqGSIb3DQEJBDEWBBTZTqLFt2XV/O0IodTLch+merRNMzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYA/g5DRliLtAbRg1wzOk8RUwh2iZ5bD33tTM3pL axzU+Xlaglzk+Iac8wDtkMEy8B+B9918Z5ZtEjP537XUFM9nGYe1EM5yWs+5WwUDLauaLHgk opAKtWEG1jlzWecInq/3Qg4pV/Kr/Dc/Oddu2SjzAlScLkwzVmZK16Ryq8ITeAAAAAAAAA== --------------ms010100000704020409060908-- From exim@www1.ietf.org Fri Apr 16 13:12:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22456 for ; Fri, 16 Apr 2004 13:12:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWi9-000113-3Z for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 13:01:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GH15J6003905 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 13:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWfe-0008Rl-KL for nemo-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 12:58: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 MAA21630 for ; Fri, 16 Apr 2004 12:58: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 1BEWfc-00040J-QX for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 12:58:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWef-0003uf-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 12:57:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEWdm-0003pq-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 12:56:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWSd-0003Ev-Rn; Fri, 16 Apr 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWJ7-0008Vr-ED for nemo@optimus.ietf.org; Fri, 16 Apr 2004 12:35:13 -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 MAA19881 for ; Fri, 16 Apr 2004 12:35: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 1BEWJ5-00025r-Mb for nemo@ietf.org; Fri, 16 Apr 2004 12:35:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWIE-00022Z-00 for nemo@ietf.org; Fri, 16 Apr 2004 12:34:18 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BEWHp-00020F-00 for nemo@ietf.org; Fri, 16 Apr 2004 12:33:53 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3GGY47n023405; Fri, 16 Apr 2004 09:34:04 -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 i3GGXnEb018128; Fri, 16 Apr 2004 11:33:49 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9248185C46E; Fri, 16 Apr 2004 18:33:48 +0200 (CEST) Message-ID: <40800AE5.40305@motorola.com> Date: Fri, 16 Apr 2004 18:33:41 +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: "Pascal Thubert (pthubert)" Cc: Mazen TLAIS , nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA References: In-Reply-To: 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="------------ms010100000704020409060908" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms010100000704020409060908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > It depends on the model. If the MR takes its home address from its > MNP then it does not need to. If the Home address is from a home > link, then it needs to change if it takes a home agent on a different > home link. This may happen in the case of Home Agent Global > Distribution with the HAHA protocol. Right, and in all the above cases all app-level communications running on MR or LFN will be interrupted when MR changes its HA, right? Alex --------------ms010100000704020409060908 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTYxNjMzNDFaMCMGCSqGSIb3DQEJBDEWBBTZTqLFt2XV/O0IodTLch+merRNMzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYA/g5DRliLtAbRg1wzOk8RUwh2iZ5bD33tTM3pL axzU+Xlaglzk+Iac8wDtkMEy8B+B9918Z5ZtEjP537XUFM9nGYe1EM5yWs+5WwUDLauaLHgk opAKtWEG1jlzWecInq/3Qg4pV/Kr/Dc/Oddu2SjzAlScLkwzVmZK16Ryq8ITeAAAAAAAAA== --------------ms010100000704020409060908-- From nemo-admin@ietf.org Fri Apr 16 13:42:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23761 for ; Fri, 16 Apr 2004 13:42:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEX7I-0000E6-Ky; Fri, 16 Apr 2004 13:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEX4k-0007rj-EI for nemo@optimus.ietf.org; Fri, 16 Apr 2004 13:24:26 -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 NAA22959 for ; Fri, 16 Apr 2004 13:24:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEX4i-0005ul-Cp for nemo@ietf.org; Fri, 16 Apr 2004 13:24:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEX3l-0005qn-00 for nemo@ietf.org; Fri, 16 Apr 2004 13:23:25 -0400 Received: from mail-gw0.york.ac.uk ([144.32.128.245]) by ietf-mx with esmtp (Exim 4.12) id 1BEX3O-0005mo-00 for nemo@ietf.org; Fri, 16 Apr 2004 13:23:02 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with SMTP id i3GHMUhx020597; Fri, 16 Apr 2004 18:22:30 +0100 (BST) Message-ID: <00d001c45558$f0037d20$68892090@grouse> From: "Jee J.Z." To: "Alexandru Petrescu" Cc: References: <40800AE5.40305@motorola.com> Subject: Re: [nemo] Re: Question-HAHA Date: Fri, 18 Jun 2004 18:23:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,DATE_IN_FUTURE_96_XX, FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Pascal Thubert (pthubert) wrote: > > It depends on the model. If the MR takes its home address from its > > MNP then it does not need to. If the Home address is from a home > > link, then it needs to change if it takes a home agent on a different > > home link. This may happen in the case of Home Agent Global > > Distribution with the HAHA protocol. > > Right, and in all the above cases all app->level communications running > on MR or LFN will be interrupted when MR >changes its HA, right? Why will all communications (running on MR or LFN) be interrupted in the first case (the MR does not need to change its home address)? Moreover, in the second case (the MR needs to change its home address), why will communications running on LFN be interrupted? Jee > Alex > > From exim@www1.ietf.org Fri Apr 16 13:53:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24324 for ; Fri, 16 Apr 2004 13:53:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXSv-00074m-38 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 13:49:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GHnPH8027195 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 13:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXND-000512-UE for nemo-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 13:43:31 -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 NAA23840 for ; Fri, 16 Apr 2004 13:43:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEXNB-0007Ee-LM for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 13:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEXMA-00079I-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 13:42:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEXLa-000753-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 13:41:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEX7I-0000E6-Ky; Fri, 16 Apr 2004 13:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEX4k-0007rj-EI for nemo@optimus.ietf.org; Fri, 16 Apr 2004 13:24:26 -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 NAA22959 for ; Fri, 16 Apr 2004 13:24:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEX4i-0005ul-Cp for nemo@ietf.org; Fri, 16 Apr 2004 13:24:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEX3l-0005qn-00 for nemo@ietf.org; Fri, 16 Apr 2004 13:23:25 -0400 Received: from mail-gw0.york.ac.uk ([144.32.128.245]) by ietf-mx with esmtp (Exim 4.12) id 1BEX3O-0005mo-00 for nemo@ietf.org; Fri, 16 Apr 2004 13:23:02 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with SMTP id i3GHMUhx020597; Fri, 16 Apr 2004 18:22:30 +0100 (BST) Message-ID: <00d001c45558$f0037d20$68892090@grouse> From: "Jee J.Z." To: "Alexandru Petrescu" Cc: References: <40800AE5.40305@motorola.com> Subject: Re: [nemo] Re: Question-HAHA Date: Fri, 18 Jun 2004 18:23:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=AWL,DATE_IN_FUTURE_96_XX, FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Pascal Thubert (pthubert) wrote: > > It depends on the model. If the MR takes its home address from its > > MNP then it does not need to. If the Home address is from a home > > link, then it needs to change if it takes a home agent on a different > > home link. This may happen in the case of Home Agent Global > > Distribution with the HAHA protocol. > > Right, and in all the above cases all app->level communications running > on MR or LFN will be interrupted when MR >changes its HA, right? Why will all communications (running on MR or LFN) be interrupted in the first case (the MR does not need to change its home address)? Moreover, in the second case (the MR needs to change its home address), why will communications running on LFN be interrupted? Jee > Alex > > From nemo-admin@ietf.org Fri Apr 16 17:44:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12179 for ; Fri, 16 Apr 2004 17:44:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEazG-0000k9-0F; Fri, 16 Apr 2004 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEawo-000858-OE for nemo@optimus.ietf.org; Fri, 16 Apr 2004 17:32:31 -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 RAA11421 for ; Fri, 16 Apr 2004 17:32:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEawm-0003ES-9f for nemo@ietf.org; Fri, 16 Apr 2004 17:32:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEavp-0003Cg-00 for nemo@ietf.org; Fri, 16 Apr 2004 17:31:29 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BEavH-0003B6-00 for nemo@ietf.org; Fri, 16 Apr 2004 17:30:55 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i3GLUqhS006729; Fri, 16 Apr 2004 14:30:53 -0700 (MST) Received: from motorola.com ([10.129.40.57]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i3GLTX7s015777; Fri, 16 Apr 2004 16:29:39 -0500 Message-ID: <4080506E.6060200@motorola.com> Date: Fri, 16 Apr 2004 23:30:22 +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: "Jee J.Z." CC: nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> In-Reply-To: <00d001c45558$f0037d20$68892090@grouse> 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="------------ms010601050607000102030308" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms010601050607000102030308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jee J.Z. wrote: >> Pascal Thubert (pthubert) wrote: >> >>> It depends on the model. If the MR takes its home address from >>> its MNP then it does not need to. If the Home address is from a >>> home link, then it needs to change if it takes a home agent on a >>> different home link. This may happen in the case of Home Agent >>> Global Distribution with the HAHA protocol. >> >> Right, and in all the above cases all app->level communications >> running on MR or LFN will be interrupted when MR >changes its HA, >> right? > > Why will all communications (running on MR or LFN) be interrupted in > the first case (the MR does not need to change its home address)? Because one can not have the same Home Address topologically correct at two different Home Agents that sit on different links (links separated by routers), right? > Moreover, in the second case (the MR needs to change its home > address), why will communications running on LFN be interrupted? Because the address of the LFN is derived from a prefix that is topologically correct at only one HA, and that prefix can not be topologically correct at another HA that sits on a different link (links separated by routers), right? On another hand, if it is assumed somehow that a MNP prefix or a Home Address can be made topologically correct at two distinct places in the network mesh (like with multi-homing or something) then no Mobile IPv6 is needed at all to tunnel traffic from a Home Address to a Care-of Address, because the Care-of Address is, in fact, the Home Address itself that was made topologically correct everywhere, no? Alex --------------ms010601050607000102030308 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTYyMTMwMjJaMCMGCSqGSIb3DQEJBDEWBBQX0U4V6yoSklD6CcP2TrfAD8K4ZzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAkgrDhwCMFtZYWYbBcx2kXObOU1VQ3BKTkWude hPw6MzLM4ha+U79i4KMg0SxPuXqBv8rSQofwMlP5XHEHwbkTcYTHOVUzk6hJdDUld2Uc5CQC bD4lDfqpaZdepESLy+DmKurC7p9C4FbrGSBcExCWUPr6SjllmRu4etiWWdKLzwAAAAAAAA== --------------ms010601050607000102030308-- From exim@www1.ietf.org Fri Apr 16 18:02:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12988 for ; Fri, 16 Apr 2004 18:02:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbJh-0006CS-Ep for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 17:56:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GLu9qo023825 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 17:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEb9e-0003qn-IJ for nemo-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:45:46 -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 RAA12274 for ; Fri, 16 Apr 2004 17:45: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 1BEb9c-0004BS-1B for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 17:45:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEb8h-00046y-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 17:44:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEb7m-000422-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 17:43:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEazG-0000k9-0F; Fri, 16 Apr 2004 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEawo-000858-OE for nemo@optimus.ietf.org; Fri, 16 Apr 2004 17:32:31 -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 RAA11421 for ; Fri, 16 Apr 2004 17:32:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEawm-0003ES-9f for nemo@ietf.org; Fri, 16 Apr 2004 17:32:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEavp-0003Cg-00 for nemo@ietf.org; Fri, 16 Apr 2004 17:31:29 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BEavH-0003B6-00 for nemo@ietf.org; Fri, 16 Apr 2004 17:30:55 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i3GLUqhS006729; Fri, 16 Apr 2004 14:30:53 -0700 (MST) Received: from motorola.com ([10.129.40.57]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i3GLTX7s015777; Fri, 16 Apr 2004 16:29:39 -0500 Message-ID: <4080506E.6060200@motorola.com> Date: Fri, 16 Apr 2004 23:30:22 +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: "Jee J.Z." CC: nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> In-Reply-To: <00d001c45558$f0037d20$68892090@grouse> 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="------------ms010601050607000102030308" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms010601050607000102030308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jee J.Z. wrote: >> Pascal Thubert (pthubert) wrote: >> >>> It depends on the model. If the MR takes its home address from >>> its MNP then it does not need to. If the Home address is from a >>> home link, then it needs to change if it takes a home agent on a >>> different home link. This may happen in the case of Home Agent >>> Global Distribution with the HAHA protocol. >> >> Right, and in all the above cases all app->level communications >> running on MR or LFN will be interrupted when MR >changes its HA, >> right? > > Why will all communications (running on MR or LFN) be interrupted in > the first case (the MR does not need to change its home address)? Because one can not have the same Home Address topologically correct at two different Home Agents that sit on different links (links separated by routers), right? > Moreover, in the second case (the MR needs to change its home > address), why will communications running on LFN be interrupted? Because the address of the LFN is derived from a prefix that is topologically correct at only one HA, and that prefix can not be topologically correct at another HA that sits on a different link (links separated by routers), right? On another hand, if it is assumed somehow that a MNP prefix or a Home Address can be made topologically correct at two distinct places in the network mesh (like with multi-homing or something) then no Mobile IPv6 is needed at all to tunnel traffic from a Home Address to a Care-of Address, because the Care-of Address is, in fact, the Home Address itself that was made topologically correct everywhere, no? Alex --------------ms010601050607000102030308 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTYyMTMwMjJaMCMGCSqGSIb3DQEJBDEWBBQX0U4V6yoSklD6CcP2TrfAD8K4ZzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAkgrDhwCMFtZYWYbBcx2kXObOU1VQ3BKTkWude hPw6MzLM4ha+U79i4KMg0SxPuXqBv8rSQofwMlP5XHEHwbkTcYTHOVUzk6hJdDUld2Uc5CQC bD4lDfqpaZdepESLy+DmKurC7p9C4FbrGSBcExCWUPr6SjllmRu4etiWWdKLzwAAAAAAAA== --------------ms010601050607000102030308-- From nemo-admin@ietf.org Fri Apr 16 19:46:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20504 for ; Fri, 16 Apr 2004 19:46:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcuI-0003Kv-0S; Fri, 16 Apr 2004 19:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcpq-0001Zq-CG for nemo@optimus.ietf.org; Fri, 16 Apr 2004 19:33:26 -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 TAA19755 for ; Fri, 16 Apr 2004 19:33:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcpo-0002rz-J0 for nemo@ietf.org; Fri, 16 Apr 2004 19:33:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcot-0002nl-00 for nemo@ietf.org; Fri, 16 Apr 2004 19:32:28 -0400 Received: from mail-gw0.york.ac.uk ([144.32.128.245]) by ietf-mx with esmtp (Exim 4.12) id 1BEcnv-0002fx-00 for nemo@ietf.org; Fri, 16 Apr 2004 19:31:27 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with SMTP id i3GNUnhx002614; Sat, 17 Apr 2004 00:30:49 +0100 (BST) Message-ID: <014b01c4558c$6427f860$68892090@grouse> From: "Jee J.Z." To: "Alexandru Petrescu" Cc: References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> <4080506E.6060200@motorola.com> Subject: Re: [nemo] Re: Question-HAHA Date: Sat, 19 Jun 2004 00:31:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.8 required=5.0 tests=AWL,DATE_IN_FUTURE_96_XX, FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Jee J.Z. wrote: > >> Pascal Thubert (pthubert) wrote: > >> > >>> It depends on the model. If the MR takes its home address from > >>> its MNP then it does not need to. If the Home address is from a > >>> home link, then it needs to change if it takes a home agent on a > >>> different home link. This may happen in the case of Home Agent > >>> Global Distribution with the HAHA protocol. > >> > >> Right, and in all the above cases all app->level communications > >> running on MR or LFN will be interrupted when MR >changes its HA, > >> right? > > > > Why will all communications (running on MR or LFN) be interrupted in > > the first case (the MR does not need to change its home address)? > > Because one can not have the same Home Address topologically correct at > two different Home Agents that sit on different links (links separated > by routers), right? If it's the case, why can the MR keep its home address unchanged as what Pascal has mentioned? I assume the MR can have the same home address because the two HAs are on the same link. > > Moreover, in the second case (the MR needs to change its home > > address), why will communications running on LFN be interrupted? > > Because the address of the LFN is derived from a prefix that is > topologically correct at only one HA, and that prefix can not be > topologically correct at another HA that sits on a different link (links > separated by routers), right? Isn't the HA of a LFN independent with the HA of its MR (please correct me if not)? I mean whether the home address of the MR changes or not, the home address of the LFN does not need to change, which means the communication session between the LFN and a CN will not be broken. > On another hand, if it is assumed somehow that a MNP prefix or a Home > Address can be made topologically correct at two distinct places in the > network mesh (like with multi-homing or something) then no Mobile IPv6 > is needed at all to tunnel traffic from a Home Address to a Care-of > Address, because the Care-of Address is, in fact, the Home Address > itself that was made topologically correct everywhere, no? IMHO, MNP prefix could be made topologically correct at two distinct places (please correct me if not), while home address can only be topologically correct on the same link. Regards, Jee > Alex > From exim@www1.ietf.org Fri Apr 16 20:01:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21345 for ; Fri, 16 Apr 2004 20:01:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdAM-0008Cr-32 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 19:54:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GNscGY031538 for nemo-archive@odin.ietf.org; Fri, 16 Apr 2004 19:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEd3U-0006ZY-EJ for nemo-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 19:47: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 TAA20638 for ; Fri, 16 Apr 2004 19:47: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 1BEd3S-0003oz-OY for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 19:47:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEd2V-0003je-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 19:46:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEd1f-0003ee-00 for nemo-web-archive@ietf.org; Fri, 16 Apr 2004 19:45:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcuI-0003Kv-0S; Fri, 16 Apr 2004 19:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcpq-0001Zq-CG for nemo@optimus.ietf.org; Fri, 16 Apr 2004 19:33:26 -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 TAA19755 for ; Fri, 16 Apr 2004 19:33:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEcpo-0002rz-J0 for nemo@ietf.org; Fri, 16 Apr 2004 19:33:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcot-0002nl-00 for nemo@ietf.org; Fri, 16 Apr 2004 19:32:28 -0400 Received: from mail-gw0.york.ac.uk ([144.32.128.245]) by ietf-mx with esmtp (Exim 4.12) id 1BEcnv-0002fx-00 for nemo@ietf.org; Fri, 16 Apr 2004 19:31:27 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with SMTP id i3GNUnhx002614; Sat, 17 Apr 2004 00:30:49 +0100 (BST) Message-ID: <014b01c4558c$6427f860$68892090@grouse> From: "Jee J.Z." To: "Alexandru Petrescu" Cc: References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> <4080506E.6060200@motorola.com> Subject: Re: [nemo] Re: Question-HAHA Date: Sat, 19 Jun 2004 00:31:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,DATE_IN_FUTURE_96_XX, FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Jee J.Z. wrote: > >> Pascal Thubert (pthubert) wrote: > >> > >>> It depends on the model. If the MR takes its home address from > >>> its MNP then it does not need to. If the Home address is from a > >>> home link, then it needs to change if it takes a home agent on a > >>> different home link. This may happen in the case of Home Agent > >>> Global Distribution with the HAHA protocol. > >> > >> Right, and in all the above cases all app->level communications > >> running on MR or LFN will be interrupted when MR >changes its HA, > >> right? > > > > Why will all communications (running on MR or LFN) be interrupted in > > the first case (the MR does not need to change its home address)? > > Because one can not have the same Home Address topologically correct at > two different Home Agents that sit on different links (links separated > by routers), right? If it's the case, why can the MR keep its home address unchanged as what Pascal has mentioned? I assume the MR can have the same home address because the two HAs are on the same link. > > Moreover, in the second case (the MR needs to change its home > > address), why will communications running on LFN be interrupted? > > Because the address of the LFN is derived from a prefix that is > topologically correct at only one HA, and that prefix can not be > topologically correct at another HA that sits on a different link (links > separated by routers), right? Isn't the HA of a LFN independent with the HA of its MR (please correct me if not)? I mean whether the home address of the MR changes or not, the home address of the LFN does not need to change, which means the communication session between the LFN and a CN will not be broken. > On another hand, if it is assumed somehow that a MNP prefix or a Home > Address can be made topologically correct at two distinct places in the > network mesh (like with multi-homing or something) then no Mobile IPv6 > is needed at all to tunnel traffic from a Home Address to a Care-of > Address, because the Care-of Address is, in fact, the Home Address > itself that was made topologically correct everywhere, no? IMHO, MNP prefix could be made topologically correct at two distinct places (please correct me if not), while home address can only be topologically correct on the same link. Regards, Jee > Alex > From nemo-admin@ietf.org Sat Apr 17 01:25:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06894 for ; Sat, 17 Apr 2004 01:25:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEiDL-0008WU-KO; Sat, 17 Apr 2004 01:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEiCA-00088Z-9e for nemo@optimus.ietf.org; Sat, 17 Apr 2004 01:16:50 -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 BAA06487 for ; Sat, 17 Apr 2004 01:16:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEiC7-0003Kw-8A for nemo@ietf.org; Sat, 17 Apr 2004 01:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEiBB-0003GP-00 for nemo@ietf.org; Sat, 17 Apr 2004 01:15:50 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BEiAW-0003AF-00 for nemo@ietf.org; Sat, 17 Apr 2004 01:15:08 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3H5COuT023442 for ; Sat, 17 Apr 2004 05:12:30 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004041713143405844 for ; Sat, 17 Apr 2004 13:14:34 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 17 Apr 2004 13:14:34 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4243A.DEFEAA1F" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 17 Apr 2004 13:14:34 +0800 Message-ID: Thread-Topic: Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKA== From: "Tan, Tat Kin" To: X-OriginalArrivalTime: 17 Apr 2004 05:14:34.0444 (UTC) FILETIME=[DF30D8C0:01C4243A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] Questions on multiple mobile network prefixes in a BU Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C4243A.DEFEAA1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I was reading the NEMO Basic Support Protocol draft-ietf-nemo-basic-support-02.txt and on page 7 where a statement was describing : "If the mobile network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all there prefixes, it includes multiple prefix information options in a single BU." My question is, how can this be achieved? I mean if there is 10 or 20 different nested networks are within that moving networks and could a single BU be able to cater all information? Will there be any risk associate of setting up such large scale? My concern also goes to the performance whereby could this be potentially delaying the binding processes? Million thanks. Rgds, Tatkin ------_=_NextPart_001_01C4243A.DEFEAA1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions on multiple mobile network prefixes in a BU

Hello,

I was reading the NEMO Basic Support = Protocol draft-ietf-nemo-basic-support-02.txt and on page 7 where a = statement was describing :

"If the mobile network has more = than one IPv6 prefix and wants the Home Agent to setup forwarding for = all there prefixes, it includes multiple prefix information options in a = single BU."

My question is, how can this be = achieved? I mean if there is 10 or 20 different nested networks are = within that moving networks and could a single BU be able to cater all = information? Will there be any risk associate of setting up such large = scale? My concern also goes to the performance whereby could this be = potentially delaying the binding processes?

Million thanks.


Rgds,
Tatkin

------_=_NextPart_001_01C4243A.DEFEAA1F-- From exim@www1.ietf.org Sat Apr 17 01:30:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07196 for ; Sat, 17 Apr 2004 01:30:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEiNg-0002jv-7O for nemo-archive@odin.ietf.org; Sat, 17 Apr 2004 01:28:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H5SiN3010526 for nemo-archive@odin.ietf.org; Sat, 17 Apr 2004 01:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEiLf-0002DN-RE for nemo-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 01:26: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 BAA06978 for ; Sat, 17 Apr 2004 01:26:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEiLc-000442-VD for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 01:26:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEiKh-0003zI-00 for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 01:25:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEiJu-0003uf-00 for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 01:24:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEiDL-0008WU-KO; Sat, 17 Apr 2004 01:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEiCA-00088Z-9e for nemo@optimus.ietf.org; Sat, 17 Apr 2004 01:16:50 -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 BAA06487 for ; Sat, 17 Apr 2004 01:16:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEiC7-0003Kw-8A for nemo@ietf.org; Sat, 17 Apr 2004 01:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEiBB-0003GP-00 for nemo@ietf.org; Sat, 17 Apr 2004 01:15:50 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BEiAW-0003AF-00 for nemo@ietf.org; Sat, 17 Apr 2004 01:15:08 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3H5COuT023442 for ; Sat, 17 Apr 2004 05:12:30 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004041713143405844 for ; Sat, 17 Apr 2004 13:14:34 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 17 Apr 2004 13:14:34 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4243A.DEFEAA1F" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 17 Apr 2004 13:14:34 +0800 Message-ID: Thread-Topic: Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKA== From: "Tan, Tat Kin" To: X-OriginalArrivalTime: 17 Apr 2004 05:14:34.0444 (UTC) FILETIME=[DF30D8C0:01C4243A] Subject: [nemo] Questions on multiple mobile network prefixes in a BU Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4243A.DEFEAA1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I was reading the NEMO Basic Support Protocol draft-ietf-nemo-basic-support-02.txt and on page 7 where a statement was describing : "If the mobile network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all there prefixes, it includes multiple prefix information options in a single BU." My question is, how can this be achieved? I mean if there is 10 or 20 different nested networks are within that moving networks and could a single BU be able to cater all information? Will there be any risk associate of setting up such large scale? My concern also goes to the performance whereby could this be potentially delaying the binding processes? Million thanks. Rgds, Tatkin ------_=_NextPart_001_01C4243A.DEFEAA1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions on multiple mobile network prefixes in a BU

Hello,

I was reading the NEMO Basic Support = Protocol draft-ietf-nemo-basic-support-02.txt and on page 7 where a = statement was describing :

"If the mobile network has more = than one IPv6 prefix and wants the Home Agent to setup forwarding for = all there prefixes, it includes multiple prefix information options in a = single BU."

My question is, how can this be = achieved? I mean if there is 10 or 20 different nested networks are = within that moving networks and could a single BU be able to cater all = information? Will there be any risk associate of setting up such large = scale? My concern also goes to the performance whereby could this be = potentially delaying the binding processes?

Million thanks.


Rgds,
Tatkin

------_=_NextPart_001_01C4243A.DEFEAA1F-- From nemo-admin@ietf.org Sat Apr 17 22:43:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10169 for ; Sat, 17 Apr 2004 22:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1pQ-00069C-14; Sat, 17 Apr 2004 22:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEyvF-0006in-El for nemo@optimus.ietf.org; Sat, 17 Apr 2004 19:08: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 TAA02002 for ; Sat, 17 Apr 2004 19:08: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 1BEyvB-0001oL-LH for nemo@ietf.org; Sat, 17 Apr 2004 19:08:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEyuA-0001fW-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:07:23 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BEytw-0001Wv-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:07:08 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3HN7IEV023399; Sat, 17 Apr 2004 16:07:18 -0700 (MST) Received: from motorola.com ([10.129.40.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i3HN5Y7h005850; Sat, 17 Apr 2004 18:05:38 -0500 Message-ID: <4081B87A.8090904@motorola.com> Date: Sun, 18 Apr 2004 01:06:34 +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: "Tan, Tat Kin" CC: nemo@ietf.org Subject: Re: [nemo] Questions on multiple mobile network prefixes in a BU References: In-Reply-To: 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="------------ms090305040708060303070808" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms090305040708060303070808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tan, Tat Kin wrote: > Hello, > > I was reading the NEMO Basic Support Protocol > draft-ietf-nemo-basic-support-02.txt and on page 7 where a statement > was describing : > > "If the mobile network has more than one IPv6 prefix and wants the > Home Agent to setup forwarding for all there prefixes, it includes > multiple prefix information options in a single BU." > > My question is, how can this be achieved? I mean if there is 10 or 20 > different nested networks are within that moving networks and could > a single BU be able to cater all information? No no, that capability of multiple prefixes within a BU is for only one MR. It is possible that MR has two fixed links in the moving network and that each link has a different prefix, such as the two prefixes are not related in an "aggregation" manner; in this case the MR sends both prefixes in the BU (instead of only one aggregated prefix). If there are 10 or 20 different nested networks then each MR of the 10 or 20 networks will send its own BU (with a simple or multiple MNP's); it's not that the uppermost MR will send a single BU with all the prefixes in all the moving networks below it. Alex --------------ms090305040708060303070808 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTcyMzA2MzVaMCMGCSqGSIb3DQEJBDEWBBRQRKN8AKIejFG8w3OqFOwk9vCtsTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDUGfY6CWEsIenfG47929csbbrJZ/3mBoaIh6yN 1GXnVEMVVIP0JmM+CapUf6N+71w7TpDEnvQhVVFPJQ/i/MDT0e2TFfxklWr8uBQSwVIhbMlB KLVksljA7l8p7L99s98Hqh93Pn7WQQ/bkS7A7zB9nopSy5Or9Iru324CpVdq0QAAAAAAAA== --------------ms090305040708060303070808-- From nemo-admin@ietf.org Sat Apr 17 22:45:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10363 for ; Sat, 17 Apr 2004 22:45:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1pU-0006AR-0Y; Sat, 17 Apr 2004 22:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEz6m-0001jb-VX for nemo@optimus.ietf.org; Sat, 17 Apr 2004 19:20: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 TAA02282 for ; Sat, 17 Apr 2004 19:20: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 1BEz6l-0003UM-Bj for nemo@ietf.org; Sat, 17 Apr 2004 19:20:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEz5o-0003Lh-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:19:25 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BEz4z-0003Cl-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:18:33 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i3HNIXLk022678; Sat, 17 Apr 2004 16:18:33 -0700 (MST) Received: from motorola.com ([10.129.40.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3HNI43d011979; Sat, 17 Apr 2004 18:18:08 -0500 Message-ID: <4081BB2E.5020302@motorola.com> Date: Sun, 18 Apr 2004 01:18:06 +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: "Jee J.Z." CC: nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> <4080506E.6060200@motorola.com> <014b01c4558c$6427f860$68892090@grouse> In-Reply-To: <014b01c4558c$6427f860$68892090@grouse> 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="------------ms080506060903080705070304" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms080506060903080705070304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jee J.Z. wrote: >>>>> It depends on the model. If the MR takes its home address >>>>> from its MNP then it does not need to. If the Home address is >>>>> from a home link, then it needs to change if it takes a home >>>>> agent on a different home link. This may happen in the case >>>>> of Home Agent Global Distribution with the HAHA protocol. >>>> >>>> Right, and in all the above cases all app->level communications >>>> running on MR or LFN will be interrupted when MR >changes its >>>> HA, right? >>> >>> Why will all communications (running on MR or LFN) be interrupted >>> in the first case (the MR does not need to change its home >>> address)? >> >> Because one can not have the same Home Address topologically >> correct at two different Home Agents that sit on different links >> (links separated by routers), right? > > If it's the case, why can the MR keep its home address unchanged as > what Pascal has mentioned? I don't know. > I assume the MR can have the same home address because the two HAs > are on the same link. When the HA's are on the same link then there is another mechanism defined by Mobile IPv6 by which the MR may choose among several HA's on the home link. >>> Moreover, in the second case (the MR needs to change its home >>> address), why will communications running on LFN be interrupted? >> >> Because the address of the LFN is derived from a prefix that is >> topologically correct at only one HA, and that prefix can not be >> topologically correct at another HA that sits on a different link >> (links separated by routers), right? > > Isn't the HA of a LFN independent with the HA of its MR (please > correct me if not)? LFN has no HA since it's fixed and runs no Mobile IPv6. When packets from CN are addressed to CN then it's MR's HA that intercepts these packets and forwarded/tunnelled to the MR's CoA. In this sense, one may say that MR's HA is the same as LFN's HA, although it's not quite correct since LFN does not do any Mobile IPv6. > I mean whether the home address of the MR changes or not, the home > address of the LFN does not need to change, This is correct, I understand that. > which means the communication session between the LFN and a CN will > not be broken. Comm from CN to LFN must be intercepted by MR's HA in order to be forwarded to current position of MR and further to LFN. So, LFN's address must be topologically correct at MR's HA (in practice, LFN's address is derived from MNP and MNP is topologically correct at HA). And, because the MR's home address can not be topologically correct at two different HA's the same MNP can not be either; so it's because the MR's HoA changes that CN-LFN comms are interrupted (not because the MR's CoA changes). > IMHO, MNP prefix could be made topologically correct at two distinct > places (please correct me if not), Please tell me how the MNP prefix is made topologically correct at two distinct places in the network (places separated by routers), and then I'll tell you why Mobile IP is not needed in that case. > while home address can only be topologically correct on the same > link. I think that if a unique MNP is valid at two different nets then a full /128 address can be made so too. Alex --------------ms080506060903080705070304 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTcyMzE4MDZaMCMGCSqGSIb3DQEJBDEWBBStL4JRbdJBLUCXZm98fJd95intwDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBwSb2ZKkSeIF0zBnrlwTJErKmrDW7elFk1Gv7U 8wHiGkl3i+yQEjfsfe5u3qZxMbpELFveB8qDX/QlMv5RuPO2nXpbVittsSXY1B08UKlNRWiV 4yGy/mou84ObWXbETsaHXuNcQUDPsUzPFB1BlhYD5lPHXudR+poaHTZ0roG2tAAAAAAAAA== --------------ms080506060903080705070304-- From exim@www1.ietf.org Sat Apr 17 23:00:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12074 for ; Sat, 17 Apr 2004 23:00:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2NP-0002dL-3o for nemo-archive@odin.ietf.org; Sat, 17 Apr 2004 22:49:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I2nleS010119 for nemo-archive@odin.ietf.org; Sat, 17 Apr 2004 22:49:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2IX-0007oD-BN for nemo-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 22:44:45 -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 WAA10347 for ; Sat, 17 Apr 2004 22:44:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF2IU-0004Ng-2k for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 22:44:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF2HS-0004BC-00 for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 22:43:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF2GV-0003y6-00 for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 22:42:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1pQ-00069C-14; Sat, 17 Apr 2004 22:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEyvF-0006in-El for nemo@optimus.ietf.org; Sat, 17 Apr 2004 19:08: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 TAA02002 for ; Sat, 17 Apr 2004 19:08: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 1BEyvB-0001oL-LH for nemo@ietf.org; Sat, 17 Apr 2004 19:08:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEyuA-0001fW-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:07:23 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BEytw-0001Wv-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:07:08 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3HN7IEV023399; Sat, 17 Apr 2004 16:07:18 -0700 (MST) Received: from motorola.com ([10.129.40.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i3HN5Y7h005850; Sat, 17 Apr 2004 18:05:38 -0500 Message-ID: <4081B87A.8090904@motorola.com> Date: Sun, 18 Apr 2004 01:06:34 +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: "Tan, Tat Kin" CC: nemo@ietf.org Subject: Re: [nemo] Questions on multiple mobile network prefixes in a BU References: In-Reply-To: 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="------------ms090305040708060303070808" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms090305040708060303070808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tan, Tat Kin wrote: > Hello, > > I was reading the NEMO Basic Support Protocol > draft-ietf-nemo-basic-support-02.txt and on page 7 where a statement > was describing : > > "If the mobile network has more than one IPv6 prefix and wants the > Home Agent to setup forwarding for all there prefixes, it includes > multiple prefix information options in a single BU." > > My question is, how can this be achieved? I mean if there is 10 or 20 > different nested networks are within that moving networks and could > a single BU be able to cater all information? No no, that capability of multiple prefixes within a BU is for only one MR. It is possible that MR has two fixed links in the moving network and that each link has a different prefix, such as the two prefixes are not related in an "aggregation" manner; in this case the MR sends both prefixes in the BU (instead of only one aggregated prefix). If there are 10 or 20 different nested networks then each MR of the 10 or 20 networks will send its own BU (with a simple or multiple MNP's); it's not that the uppermost MR will send a single BU with all the prefixes in all the moving networks below it. Alex --------------ms090305040708060303070808 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTcyMzA2MzVaMCMGCSqGSIb3DQEJBDEWBBRQRKN8AKIejFG8w3OqFOwk9vCtsTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDUGfY6CWEsIenfG47929csbbrJZ/3mBoaIh6yN 1GXnVEMVVIP0JmM+CapUf6N+71w7TpDEnvQhVVFPJQ/i/MDT0e2TFfxklWr8uBQSwVIhbMlB KLVksljA7l8p7L99s98Hqh93Pn7WQQ/bkS7A7zB9nopSy5Or9Iru324CpVdq0QAAAAAAAA== --------------ms090305040708060303070808-- From exim@www1.ietf.org Sat Apr 17 23:02:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12172 for ; Sat, 17 Apr 2004 23:02:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2OB-00030o-Sr for nemo-archive@odin.ietf.org; Sat, 17 Apr 2004 22:50:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I2oZqG011572 for nemo-archive@odin.ietf.org; Sat, 17 Apr 2004 22:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2KL-0000Si-Cd for nemo-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 22:46:37 -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 WAA10471 for ; Sat, 17 Apr 2004 22:46: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 1BF2KI-0004q2-0L for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 22:46:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF2JK-0004Zm-00 for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 22:45:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF2IO-0004N5-00 for nemo-web-archive@ietf.org; Sat, 17 Apr 2004 22:44:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1pU-0006AR-0Y; Sat, 17 Apr 2004 22:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEz6m-0001jb-VX for nemo@optimus.ietf.org; Sat, 17 Apr 2004 19:20: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 TAA02282 for ; Sat, 17 Apr 2004 19:20: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 1BEz6l-0003UM-Bj for nemo@ietf.org; Sat, 17 Apr 2004 19:20:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEz5o-0003Lh-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:19:25 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BEz4z-0003Cl-00 for nemo@ietf.org; Sat, 17 Apr 2004 19:18:33 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i3HNIXLk022678; Sat, 17 Apr 2004 16:18:33 -0700 (MST) Received: from motorola.com ([10.129.40.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3HNI43d011979; Sat, 17 Apr 2004 18:18:08 -0500 Message-ID: <4081BB2E.5020302@motorola.com> Date: Sun, 18 Apr 2004 01:18:06 +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: "Jee J.Z." CC: nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> <4080506E.6060200@motorola.com> <014b01c4558c$6427f860$68892090@grouse> In-Reply-To: <014b01c4558c$6427f860$68892090@grouse> 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="------------ms080506060903080705070304" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms080506060903080705070304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jee J.Z. wrote: >>>>> It depends on the model. If the MR takes its home address >>>>> from its MNP then it does not need to. If the Home address is >>>>> from a home link, then it needs to change if it takes a home >>>>> agent on a different home link. This may happen in the case >>>>> of Home Agent Global Distribution with the HAHA protocol. >>>> >>>> Right, and in all the above cases all app->level communications >>>> running on MR or LFN will be interrupted when MR >changes its >>>> HA, right? >>> >>> Why will all communications (running on MR or LFN) be interrupted >>> in the first case (the MR does not need to change its home >>> address)? >> >> Because one can not have the same Home Address topologically >> correct at two different Home Agents that sit on different links >> (links separated by routers), right? > > If it's the case, why can the MR keep its home address unchanged as > what Pascal has mentioned? I don't know. > I assume the MR can have the same home address because the two HAs > are on the same link. When the HA's are on the same link then there is another mechanism defined by Mobile IPv6 by which the MR may choose among several HA's on the home link. >>> Moreover, in the second case (the MR needs to change its home >>> address), why will communications running on LFN be interrupted? >> >> Because the address of the LFN is derived from a prefix that is >> topologically correct at only one HA, and that prefix can not be >> topologically correct at another HA that sits on a different link >> (links separated by routers), right? > > Isn't the HA of a LFN independent with the HA of its MR (please > correct me if not)? LFN has no HA since it's fixed and runs no Mobile IPv6. When packets from CN are addressed to CN then it's MR's HA that intercepts these packets and forwarded/tunnelled to the MR's CoA. In this sense, one may say that MR's HA is the same as LFN's HA, although it's not quite correct since LFN does not do any Mobile IPv6. > I mean whether the home address of the MR changes or not, the home > address of the LFN does not need to change, This is correct, I understand that. > which means the communication session between the LFN and a CN will > not be broken. Comm from CN to LFN must be intercepted by MR's HA in order to be forwarded to current position of MR and further to LFN. So, LFN's address must be topologically correct at MR's HA (in practice, LFN's address is derived from MNP and MNP is topologically correct at HA). And, because the MR's home address can not be topologically correct at two different HA's the same MNP can not be either; so it's because the MR's HoA changes that CN-LFN comms are interrupted (not because the MR's CoA changes). > IMHO, MNP prefix could be made topologically correct at two distinct > places (please correct me if not), Please tell me how the MNP prefix is made topologically correct at two distinct places in the network (places separated by routers), and then I'll tell you why Mobile IP is not needed in that case. > while home address can only be topologically correct on the same > link. I think that if a unique MNP is valid at two different nets then a full /128 address can be made so too. Alex --------------ms080506060903080705070304 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MTcyMzE4MDZaMCMGCSqGSIb3DQEJBDEWBBStL4JRbdJBLUCXZm98fJd95intwDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBwSb2ZKkSeIF0zBnrlwTJErKmrDW7elFk1Gv7U 8wHiGkl3i+yQEjfsfe5u3qZxMbpELFveB8qDX/QlMv5RuPO2nXpbVittsSXY1B08UKlNRWiV 4yGy/mou84ObWXbETsaHXuNcQUDPsUzPFB1BlhYD5lPHXudR+poaHTZ0roG2tAAAAAAAAA== --------------ms080506060903080705070304-- From nemo-admin@ietf.org Mon Apr 19 04:36:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26022 for ; Mon, 19 Apr 2004 04:36:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU6L-00018m-Vd; Mon, 19 Apr 2004 04:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU3O-0000L9-HL for nemo@optimus.ietf.org; Mon, 19 Apr 2004 04:22:58 -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 EAA25061 for ; Mon, 19 Apr 2004 04:22:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFU3L-0000No-L0 for nemo@ietf.org; Mon, 19 Apr 2004 04:22:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFU2c-0000Af-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:22:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BFU1p-0007jm-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:21:21 -0400 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2004 10:24:39 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3J8IKl0028328; Mon, 19 Apr 2004 10:19:53 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Apr 2004 09:20:38 +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] Questions on multiple mobile network prefixes in a BU Date: Mon, 19 Apr 2004 09:20:37 +0100 Message-ID: Thread-Topic: [nemo] Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKABquVjQ From: "Pascal Thubert \(pthubert\)" To: "Tan, Tat Kin" , X-OriginalArrivalTime: 19 Apr 2004 08:20:38.0479 (UTC) FILETIME=[324CE5F0:01C425E7] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >> My question is, how can this be achieved? I mean if there is 10 or 20 different nested networks are within that moving networks and could a single BU be able to cater all information?=20 Hi Tatkin,=20 I will not paraphrase Alex since I had a chance to read his mail and agree with his answer concerning the coverage of the nemo basic support. But I must admit that like you, I toyed with the idea of proxying BU prefix information, in the context of nested RO. Note that there's a number of issues to fix first like loop avoidance. I suggest we start looking at making clean trees of mobile routers and then we know that we can start proxying/bridging is a loopless fashion. Pascal From nemo-admin@ietf.org Mon Apr 19 04:40:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26303 for ; Mon, 19 Apr 2004 04:40:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU6V-0001BR-VW; Mon, 19 Apr 2004 04:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFTvg-0007GR-A4 for nemo@optimus.ietf.org; Mon, 19 Apr 2004 04:15:00 -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 EAA24655 for ; Mon, 19 Apr 2004 04:14:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTvd-0006Lq-J6 for nemo@ietf.org; Mon, 19 Apr 2004 04:14:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTug-00068V-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:13:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BFTu8-0005tn-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:13:24 -0400 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2004 10:16:42 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3J86LlS025304; Mon, 19 Apr 2004 10:12:03 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Apr 2004 09:12: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] Re: Question-HAHA Date: Mon, 19 Apr 2004 09:12:28 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQj+/XmPvoVe3NtQxKshdzdA9gNkQB57jUQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Jee J.Z." Cc: X-OriginalArrivalTime: 19 Apr 2004 08:12:29.0729 (UTC) FILETIME=[0EFB9110:01C425E6] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable You may want to give a look at the appendix in the HAHA protocol.=20 For the global HA distribution, there is an overall aggregation of all MNPs that is advertised by all HAs, wherever they are (they are not expected to be on a same link) to the infrastructure (the internet). So all the MNPs are 'topologically correct' at any of the HA regarding the external infrastructure. Then the HAs are cross connected with a mesh of tunnels, over which they run HAHA, in order to distribute a finer granularity of routes. The MNPs are partitioned in smaller aggregations that belong to a given home link, which aggregation is advertised by HAs to other HAs using HAHA. If a MRs binds to its normal HA, the HA does not need to reinject the MNP routes to the other HAs because the MNP belongs to the aggregation that it already advertises. By if a foreign MR binds a foreign MNP to the HA, then the HA needs to reinject the MNP granularity over HAHA, long as the binding stands. If the MR uses an MNP address to bind, it does not need to recomputed a Home Address, but if it uses a home link address, then it needs to compute it from the prefix on the new home link. For end to end communications, the MR has to choose between it's careof, it's home address and its address on MNP. We already discussed the heuristics for that choice. The MNP based address is the longest lasting one, but it's also the most costly in terms of path (hops). LFN communication should not be interrupted but for the duration of the BU and then the MNP route redistribution between HAs. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Alexandru Petrescu > Sent: vendredi 16 avril 2004 23:30 > To: Jee J.Z. > Cc: nemo@ietf.org > Subject: Re: [nemo] Re: Question-HAHA >=20 > Jee J.Z. wrote: > >> Pascal Thubert (pthubert) wrote: > >> > >>> It depends on the model. If the MR takes its home address from > >>> its MNP then it does not need to. If the Home address is from a > >>> home link, then it needs to change if it takes a home agent on a > >>> different home link. This may happen in the case of Home Agent > >>> Global Distribution with the HAHA protocol. > >> > >> Right, and in all the above cases all app->level communications > >> running on MR or LFN will be interrupted when MR >changes its HA, > >> right? > > > > Why will all communications (running on MR or LFN) be interrupted in > > the first case (the MR does not need to change its home address)? >=20 > Because one can not have the same Home Address topologically correct at > two different Home Agents that sit on different links (links separated > by routers), right? >=20 > > Moreover, in the second case (the MR needs to change its home > > address), why will communications running on LFN be interrupted? >=20 > Because the address of the LFN is derived from a prefix that is > topologically correct at only one HA, and that prefix can not be > topologically correct at another HA that sits on a different link (links > separated by routers), right? >=20 > On another hand, if it is assumed somehow that a MNP prefix or a Home > Address can be made topologically correct at two distinct places in the > network mesh (like with multi-homing or something) then no Mobile IPv6 > is needed at all to tunnel traffic from a Home Address to a Care-of > Address, because the Care-of Address is, in fact, the Home Address > itself that was made topologically correct everywhere, no? >=20 > Alex From exim@www1.ietf.org Mon Apr 19 05:07:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27921 for ; Mon, 19 Apr 2004 05:07:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFUgh-0002Pk-4R for nemo-archive@odin.ietf.org; Mon, 19 Apr 2004 05:03:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J93ZjP009276 for nemo-archive@odin.ietf.org; Mon, 19 Apr 2004 05:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFUZr-0001NJ-UD for nemo-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 04:56: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 EAA26922 for ; Mon, 19 Apr 2004 04:56:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFUZo-0000Cr-OC for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 04:56:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFUWK-00074a-00 for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 04:52:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFUUS-0006ex-09 for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 04:50:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU6V-0001BR-VW; Mon, 19 Apr 2004 04:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFTvg-0007GR-A4 for nemo@optimus.ietf.org; Mon, 19 Apr 2004 04:15:00 -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 EAA24655 for ; Mon, 19 Apr 2004 04:14:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTvd-0006Lq-J6 for nemo@ietf.org; Mon, 19 Apr 2004 04:14:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTug-00068V-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:13:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BFTu8-0005tn-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:13:24 -0400 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2004 10:16:42 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3J86LlS025304; Mon, 19 Apr 2004 10:12:03 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Apr 2004 09:12: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] Re: Question-HAHA Date: Mon, 19 Apr 2004 09:12:28 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQj+/XmPvoVe3NtQxKshdzdA9gNkQB57jUQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Jee J.Z." Cc: X-OriginalArrivalTime: 19 Apr 2004 08:12:29.0729 (UTC) FILETIME=[0EFB9110:01C425E6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable You may want to give a look at the appendix in the HAHA protocol.=20 For the global HA distribution, there is an overall aggregation of all MNPs that is advertised by all HAs, wherever they are (they are not expected to be on a same link) to the infrastructure (the internet). So all the MNPs are 'topologically correct' at any of the HA regarding the external infrastructure. Then the HAs are cross connected with a mesh of tunnels, over which they run HAHA, in order to distribute a finer granularity of routes. The MNPs are partitioned in smaller aggregations that belong to a given home link, which aggregation is advertised by HAs to other HAs using HAHA. If a MRs binds to its normal HA, the HA does not need to reinject the MNP routes to the other HAs because the MNP belongs to the aggregation that it already advertises. By if a foreign MR binds a foreign MNP to the HA, then the HA needs to reinject the MNP granularity over HAHA, long as the binding stands. If the MR uses an MNP address to bind, it does not need to recomputed a Home Address, but if it uses a home link address, then it needs to compute it from the prefix on the new home link. For end to end communications, the MR has to choose between it's careof, it's home address and its address on MNP. We already discussed the heuristics for that choice. The MNP based address is the longest lasting one, but it's also the most costly in terms of path (hops). LFN communication should not be interrupted but for the duration of the BU and then the MNP route redistribution between HAs. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Alexandru Petrescu > Sent: vendredi 16 avril 2004 23:30 > To: Jee J.Z. > Cc: nemo@ietf.org > Subject: Re: [nemo] Re: Question-HAHA >=20 > Jee J.Z. wrote: > >> Pascal Thubert (pthubert) wrote: > >> > >>> It depends on the model. If the MR takes its home address from > >>> its MNP then it does not need to. If the Home address is from a > >>> home link, then it needs to change if it takes a home agent on a > >>> different home link. This may happen in the case of Home Agent > >>> Global Distribution with the HAHA protocol. > >> > >> Right, and in all the above cases all app->level communications > >> running on MR or LFN will be interrupted when MR >changes its HA, > >> right? > > > > Why will all communications (running on MR or LFN) be interrupted in > > the first case (the MR does not need to change its home address)? >=20 > Because one can not have the same Home Address topologically correct at > two different Home Agents that sit on different links (links separated > by routers), right? >=20 > > Moreover, in the second case (the MR needs to change its home > > address), why will communications running on LFN be interrupted? >=20 > Because the address of the LFN is derived from a prefix that is > topologically correct at only one HA, and that prefix can not be > topologically correct at another HA that sits on a different link (links > separated by routers), right? >=20 > On another hand, if it is assumed somehow that a MNP prefix or a Home > Address can be made topologically correct at two distinct places in the > network mesh (like with multi-homing or something) then no Mobile IPv6 > is needed at all to tunnel traffic from a Home Address to a Care-of > Address, because the Care-of Address is, in fact, the Home Address > itself that was made topologically correct everywhere, no? >=20 > Alex From exim@www1.ietf.org Mon Apr 19 05:08:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28012 for ; Mon, 19 Apr 2004 05:08:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFUgn-0002TF-53 for nemo-archive@odin.ietf.org; Mon, 19 Apr 2004 05:03:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J93fsk009493 for nemo-archive@odin.ietf.org; Mon, 19 Apr 2004 05:03:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFUaR-0001Ym-IU for nemo-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 04:57:07 -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 EAA27074 for ; Mon, 19 Apr 2004 04:57:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFUaO-0000TE-9V for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 04:57:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFUX0-0007Fc-00 for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 04:53:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFUUT-0006fZ-01 for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 04:50:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU6L-00018m-Vd; Mon, 19 Apr 2004 04:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU3O-0000L9-HL for nemo@optimus.ietf.org; Mon, 19 Apr 2004 04:22:58 -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 EAA25061 for ; Mon, 19 Apr 2004 04:22:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFU3L-0000No-L0 for nemo@ietf.org; Mon, 19 Apr 2004 04:22:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFU2c-0000Af-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:22:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BFU1p-0007jm-00 for nemo@ietf.org; Mon, 19 Apr 2004 04:21:21 -0400 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2004 10:24:39 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3J8IKl0028328; Mon, 19 Apr 2004 10:19:53 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 Apr 2004 09:20:38 +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] Questions on multiple mobile network prefixes in a BU Date: Mon, 19 Apr 2004 09:20:37 +0100 Message-ID: Thread-Topic: [nemo] Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKABquVjQ From: "Pascal Thubert \(pthubert\)" To: "Tan, Tat Kin" , X-OriginalArrivalTime: 19 Apr 2004 08:20:38.0479 (UTC) FILETIME=[324CE5F0:01C425E7] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable >> My question is, how can this be achieved? I mean if there is 10 or 20 different nested networks are within that moving networks and could a single BU be able to cater all information?=20 Hi Tatkin,=20 I will not paraphrase Alex since I had a chance to read his mail and agree with his answer concerning the coverage of the nemo basic support. But I must admit that like you, I toyed with the idea of proxying BU prefix information, in the context of nested RO. Note that there's a number of issues to fix first like loop avoidance. I suggest we start looking at making clean trees of mobile routers and then we know that we can start proxying/bridging is a loopless fashion. Pascal From nemo-admin@ietf.org Mon Apr 19 11:37:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17301 for ; Mon, 19 Apr 2004 11:37:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFafl-0002a3-Ka; Mon, 19 Apr 2004 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFaZx-0001F0-JM for nemo@optimus.ietf.org; Mon, 19 Apr 2004 11:21:01 -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 LAA16598 for ; Mon, 19 Apr 2004 11:20:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFaZw-0000wy-H7 for nemo@ietf.org; Mon, 19 Apr 2004 11:21:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaYx-0000jD-00 for nemo@ietf.org; Mon, 19 Apr 2004 11:20:00 -0400 Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx with esmtp (Exim 4.12) id 1BFaXz-0000K0-00 for nemo@ietf.org; Mon, 19 Apr 2004 11:18:59 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with SMTP id i3JFIH7X012805; Mon, 19 Apr 2004 16:18:17 +0100 (BST) Message-ID: <007e01c457a3$180c46c0$68892090@grouse> From: "Jee J.Z." To: "Alexandru Petrescu" Cc: , "Pascal Thubert \(pthubert\)" References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> <4080506E.6060200@motorola.com> <014b01c4558c$6427f860$68892090@grouse> <4081BB2E.5020302@motorola.com> Subject: Re: [nemo] Re: Question-HAHA Date: Mon, 21 Jun 2004 16:19:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,DATE_IN_FUTURE_96_XX, FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alex, I get more clear on the issue after reading Pascal's explanations. Below inline is what I wrote and thought before Pascal's email, which sounds quite limited and could be flawed, and the HAHA protocol seems to have covered all I had thought of -- I'd better read it through. > Jee J.Z. wrote: > >>>>> It depends on the model. If the MR takes its home address > >>>>> from its MNP then it does not need to. If the Home address is > >>>>> from a home link, then it needs to change if it takes a home > >>>>> agent on a different home link. This may happen in the case > >>>>> of Home Agent Global Distribution with the HAHA protocol. > >>>> > >>>> Right, and in all the above cases all app->level communications > >>>> running on MR or LFN will be interrupted when MR >changes its > >>>> HA, right? > >>> > >>> Why will all communications (running on MR or LFN) be interrupted > >>> in the first case (the MR does not need to change its home > >>> address)? > >> > >> Because one can not have the same Home Address topologically > >> correct at two different Home Agents that sit on different links > >> (links separated by routers), right? > > > > If it's the case, why can the MR keep its home address unchanged as > > what Pascal has mentioned? > > I don't know. So this issue is still pending? > > I assume the MR can have the same home address because the two HAs > > are on the same link. > > When the HA's are on the same link then there is another mechanism > defined by Mobile IPv6 by which the MR may choose among several HA's on > the home link. Yes, but aren't we talking about handover among these HA's? For load balancing purpose, I think the MR may choose to handover to a new HA on the same link as the previous HA, so it can keep its home address unchanged. Do you mean this handover does not in the scope of HAHA? I can't think of MIPv6 can manage HA handover. > >>> Moreover, in the second case (the MR needs to change its home > >>> address), why will communications running on LFN be interrupted? > >> > >> Because the address of the LFN is derived from a prefix that is > >> topologically correct at only one HA, and that prefix can not be > >> topologically correct at another HA that sits on a different link > >> (links separated by routers), right? > > > > Isn't the HA of a LFN independent with the HA of its MR (please > > correct me if not)? > > LFN has no HA since it's fixed and runs no Mobile IPv6. When packets > from CN are addressed to CN then it's MR's HA that intercepts these > packets and forwarded/tunnelled to the MR's CoA. In this sense, one may > say that MR's HA is the same as LFN's HA, although it's not quite > correct since LFN does not do any Mobile IPv6. Thank you. That's my confusion on definitions. > > I mean whether the home address of the MR changes or not, the home > > address of the LFN does not need to change, > > This is correct, I understand that. > > > which means the communication session between the LFN and a CN will > > not be broken. > > Comm from CN to LFN must be intercepted by MR's HA in order to be > forwarded to current position of MR and further to LFN. So, LFN's > address must be topologically correct at MR's HA (in practice, LFN's > address is derived from MNP and MNP is topologically correct at HA). > And, because the MR's home address can not be topologically correct at > two different HA's the same MNP can not be either; so it's because the > MR's HoA changes that CN-LFN comms are interrupted (not because the MR's > CoA changes). OK, I understand now. > > IMHO, MNP prefix could be made topologically correct at two distinct > > places (please correct me if not), > > Please tell me how the MNP prefix is made topologically correct at two > distinct places in the network (places separated by routers), and then > I'll tell you why Mobile IP is not needed in that case. OK. Well, actually I am thinking whether MNP handover is possible. Say there are two HA's on different links. Both of them could advertise the reachability of an aggregation of the MR's MNP. When the MR selects one of the two HA's (say HA1), HA1 assigns the MNP to the MR and does the redirection job for the MNP; when the MR decides to change its HA to HA2, the MNP is handed over to HA2, and HA2 manages the MNP and does the redirection job. However, because the two HA's are on different links, the home address of the MR has to change. Regards, Jee > > while home address can only be topologically correct on the same > > link. > > I think that if a unique MNP is valid at two different nets then a full > /128 address can be made so too. > > Alex > From exim@www1.ietf.org Mon Apr 19 11:51:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17984 for ; Mon, 19 Apr 2004 11:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFazh-0006rs-68 for nemo-archive@odin.ietf.org; Mon, 19 Apr 2004 11:47:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JFlb9i026396 for nemo-archive@odin.ietf.org; Mon, 19 Apr 2004 11:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFarZ-0004oi-Vh for nemo-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 11:39: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 LAA17387 for ; Mon, 19 Apr 2004 11:39:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFarY-00053D-RF for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 11:39:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaqe-0004p9-00 for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 11:38:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFaph-0004bq-00 for nemo-web-archive@ietf.org; Mon, 19 Apr 2004 11:37:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFafl-0002a3-Ka; Mon, 19 Apr 2004 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFaZx-0001F0-JM for nemo@optimus.ietf.org; Mon, 19 Apr 2004 11:21:01 -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 LAA16598 for ; Mon, 19 Apr 2004 11:20:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFaZw-0000wy-H7 for nemo@ietf.org; Mon, 19 Apr 2004 11:21:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaYx-0000jD-00 for nemo@ietf.org; Mon, 19 Apr 2004 11:20:00 -0400 Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx with esmtp (Exim 4.12) id 1BFaXz-0000K0-00 for nemo@ietf.org; Mon, 19 Apr 2004 11:18:59 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with SMTP id i3JFIH7X012805; Mon, 19 Apr 2004 16:18:17 +0100 (BST) Message-ID: <007e01c457a3$180c46c0$68892090@grouse> From: "Jee J.Z." To: "Alexandru Petrescu" Cc: , "Pascal Thubert \(pthubert\)" References: <40800AE5.40305@motorola.com> <00d001c45558$f0037d20$68892090@grouse> <4080506E.6060200@motorola.com> <014b01c4558c$6427f860$68892090@grouse> <4081BB2E.5020302@motorola.com> Subject: Re: [nemo] Re: Question-HAHA Date: Mon, 21 Jun 2004 16:19:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-York-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,DATE_IN_FUTURE_96_XX, FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alex, I get more clear on the issue after reading Pascal's explanations. Below inline is what I wrote and thought before Pascal's email, which sounds quite limited and could be flawed, and the HAHA protocol seems to have covered all I had thought of -- I'd better read it through. > Jee J.Z. wrote: > >>>>> It depends on the model. If the MR takes its home address > >>>>> from its MNP then it does not need to. If the Home address is > >>>>> from a home link, then it needs to change if it takes a home > >>>>> agent on a different home link. This may happen in the case > >>>>> of Home Agent Global Distribution with the HAHA protocol. > >>>> > >>>> Right, and in all the above cases all app->level communications > >>>> running on MR or LFN will be interrupted when MR >changes its > >>>> HA, right? > >>> > >>> Why will all communications (running on MR or LFN) be interrupted > >>> in the first case (the MR does not need to change its home > >>> address)? > >> > >> Because one can not have the same Home Address topologically > >> correct at two different Home Agents that sit on different links > >> (links separated by routers), right? > > > > If it's the case, why can the MR keep its home address unchanged as > > what Pascal has mentioned? > > I don't know. So this issue is still pending? > > I assume the MR can have the same home address because the two HAs > > are on the same link. > > When the HA's are on the same link then there is another mechanism > defined by Mobile IPv6 by which the MR may choose among several HA's on > the home link. Yes, but aren't we talking about handover among these HA's? For load balancing purpose, I think the MR may choose to handover to a new HA on the same link as the previous HA, so it can keep its home address unchanged. Do you mean this handover does not in the scope of HAHA? I can't think of MIPv6 can manage HA handover. > >>> Moreover, in the second case (the MR needs to change its home > >>> address), why will communications running on LFN be interrupted? > >> > >> Because the address of the LFN is derived from a prefix that is > >> topologically correct at only one HA, and that prefix can not be > >> topologically correct at another HA that sits on a different link > >> (links separated by routers), right? > > > > Isn't the HA of a LFN independent with the HA of its MR (please > > correct me if not)? > > LFN has no HA since it's fixed and runs no Mobile IPv6. When packets > from CN are addressed to CN then it's MR's HA that intercepts these > packets and forwarded/tunnelled to the MR's CoA. In this sense, one may > say that MR's HA is the same as LFN's HA, although it's not quite > correct since LFN does not do any Mobile IPv6. Thank you. That's my confusion on definitions. > > I mean whether the home address of the MR changes or not, the home > > address of the LFN does not need to change, > > This is correct, I understand that. > > > which means the communication session between the LFN and a CN will > > not be broken. > > Comm from CN to LFN must be intercepted by MR's HA in order to be > forwarded to current position of MR and further to LFN. So, LFN's > address must be topologically correct at MR's HA (in practice, LFN's > address is derived from MNP and MNP is topologically correct at HA). > And, because the MR's home address can not be topologically correct at > two different HA's the same MNP can not be either; so it's because the > MR's HoA changes that CN-LFN comms are interrupted (not because the MR's > CoA changes). OK, I understand now. > > IMHO, MNP prefix could be made topologically correct at two distinct > > places (please correct me if not), > > Please tell me how the MNP prefix is made topologically correct at two > distinct places in the network (places separated by routers), and then > I'll tell you why Mobile IP is not needed in that case. OK. Well, actually I am thinking whether MNP handover is possible. Say there are two HA's on different links. Both of them could advertise the reachability of an aggregation of the MR's MNP. When the MR selects one of the two HA's (say HA1), HA1 assigns the MNP to the MR and does the redirection job for the MNP; when the MR decides to change its HA to HA2, the MNP is handed over to HA2, and HA2 manages the MNP and does the redirection job. However, because the two HA's are on different links, the home address of the MR has to change. Regards, Jee > > while home address can only be topologically correct on the same > > link. > > I think that if a unique MNP is valid at two different nets then a full > /128 address can be made so too. > > Alex > From nemo-admin@ietf.org Tue Apr 20 07:55:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11246 for ; Tue, 20 Apr 2004 07:55:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtkL-0001fC-Hq; Tue, 20 Apr 2004 07:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtfQ-0000Dh-4p for nemo@optimus.ietf.org; Tue, 20 Apr 2004 07:43:56 -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 HAA10781 for ; Tue, 20 Apr 2004 07:43:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFtfP-0000vl-6Y for nemo@ietf.org; Tue, 20 Apr 2004 07:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFteP-0000fA-00 for nemo@ietf.org; Tue, 20 Apr 2004 07:42:54 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1BFtdM-0000B6-00 for nemo@ietf.org; Tue, 20 Apr 2004 07:41:49 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D3678239FE; Tue, 20 Apr 2004 13:41:17 +0200 (CEST) Received: from lolo (unknown [163.117.252.57]) by smtp03.uc3m.es (Postfix) with SMTP id 0941D239F6; Tue, 20 Apr 2004 13:41:16 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" , "Jee J.Z." Cc: Subject: RE: [nemo] Re: Question-HAHA Date: Tue, 20 Apr 2004 13:37:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pascal, I am not sure that i am really understanding what you are proposing here, i must admit i have only made my first reading of the haha draft, but are you supposing that the aggregated home prefix will be injected through several providers? If so, i am not really sure this will be acceptable. I mean,the only known way to preserve routing system scalability is to use strict provider aggregation, which means that IPs will only inject its own aggregate into the routing system and that no end sites prefixes will be cisible in the global routing table. AFAIU you are proposing that that a route to the home prefix is injected in the DFZ routing table? is this correct? if so, how do plan to make the routing system scale? Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Pascal > Thubert (pthubert) > Enviado el: lunes, 19 de abril de 2004 10:12 > Para: Alexandru Petrescu; Jee J.Z. > CC: nemo@ietf.org > Asunto: RE: [nemo] Re: Question-HAHA > > > You may want to give a look at the appendix in the HAHA protocol. > > For the global HA distribution, there is an overall aggregation of all > MNPs that is advertised by all HAs, wherever they are (they are not > expected to be on a same link) to the infrastructure (the internet). So > all the MNPs are 'topologically correct' at any of the HA regarding the > external infrastructure. > > Then the HAs are cross connected with a mesh of tunnels, over which they > run HAHA, in order to distribute a finer granularity of routes. The MNPs > are partitioned in smaller aggregations that belong to a given home > link, which aggregation is advertised by HAs to other HAs using HAHA. If > a MRs binds to its normal HA, the HA does not need to reinject the MNP > routes to the other HAs because the MNP belongs to the aggregation that > it already advertises. > > By if a foreign MR binds a foreign MNP to the HA, then the HA needs to > reinject the MNP granularity over HAHA, long as the binding stands. If > the MR uses an MNP address to bind, it does not need to recomputed a > Home Address, but if it uses a home link address, then it needs to > compute it from the prefix on the new home link. > > For end to end communications, the MR has to choose between it's careof, > it's home address and its address on MNP. We already discussed the > heuristics for that choice. The MNP based address is the longest lasting > one, but it's also the most costly in terms of path (hops). > > LFN communication should not be interrupted but for the duration of the > BU and then the MNP route redistribution between HAs. > > Pascal > > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Alexandru Petrescu > > Sent: vendredi 16 avril 2004 23:30 > > To: Jee J.Z. > > Cc: nemo@ietf.org > > Subject: Re: [nemo] Re: Question-HAHA > > > > Jee J.Z. wrote: > > >> Pascal Thubert (pthubert) wrote: > > >> > > >>> It depends on the model. If the MR takes its home address from > > >>> its MNP then it does not need to. If the Home address is from a > > >>> home link, then it needs to change if it takes a home agent on a > > >>> different home link. This may happen in the case of Home Agent > > >>> Global Distribution with the HAHA protocol. > > >> > > >> Right, and in all the above cases all app->level communications > > >> running on MR or LFN will be interrupted when MR >changes its HA, > > >> right? > > > > > > Why will all communications (running on MR or LFN) be interrupted in > > > the first case (the MR does not need to change its home address)? > > > > Because one can not have the same Home Address topologically correct > at > > two different Home Agents that sit on different links (links separated > > by routers), right? > > > > > Moreover, in the second case (the MR needs to change its home > > > address), why will communications running on LFN be interrupted? > > > > Because the address of the LFN is derived from a prefix that is > > topologically correct at only one HA, and that prefix can not be > > topologically correct at another HA that sits on a different link > (links > > separated by routers), right? > > > > On another hand, if it is assumed somehow that a MNP prefix or a Home > > Address can be made topologically correct at two distinct places in > the > > network mesh (like with multi-homing or something) then no Mobile IPv6 > > is needed at all to tunnel traffic from a Home Address to a Care-of > > Address, because the Care-of Address is, in fact, the Home Address > > itself that was made topologically correct everywhere, no? > > > > Alex > From exim@www1.ietf.org Tue Apr 20 08:05:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11962 for ; Tue, 20 Apr 2004 08:05:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtxx-00052x-RW for nemo-archive@odin.ietf.org; Tue, 20 Apr 2004 08:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KC35Ot019396 for nemo-archive@odin.ietf.org; Tue, 20 Apr 2004 08:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFts7-0003V5-Eg for nemo-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 07:57:03 -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 HAA11300 for ; Tue, 20 Apr 2004 07:57:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFts6-0004Of-Dh for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 07:57:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFtr6-00048s-00 for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 07:56:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFtqP-0003tX-00 for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 07:55:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtkL-0001fC-Hq; Tue, 20 Apr 2004 07:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFtfQ-0000Dh-4p for nemo@optimus.ietf.org; Tue, 20 Apr 2004 07:43:56 -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 HAA10781 for ; Tue, 20 Apr 2004 07:43:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFtfP-0000vl-6Y for nemo@ietf.org; Tue, 20 Apr 2004 07:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFteP-0000fA-00 for nemo@ietf.org; Tue, 20 Apr 2004 07:42:54 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1BFtdM-0000B6-00 for nemo@ietf.org; Tue, 20 Apr 2004 07:41:49 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D3678239FE; Tue, 20 Apr 2004 13:41:17 +0200 (CEST) Received: from lolo (unknown [163.117.252.57]) by smtp03.uc3m.es (Postfix) with SMTP id 0941D239F6; Tue, 20 Apr 2004 13:41:16 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" , "Jee J.Z." Cc: Subject: RE: [nemo] Re: Question-HAHA Date: Tue, 20 Apr 2004 13:37:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: 7bit Content-Transfer-Encoding: 7bit Hi Pascal, I am not sure that i am really understanding what you are proposing here, i must admit i have only made my first reading of the haha draft, but are you supposing that the aggregated home prefix will be injected through several providers? If so, i am not really sure this will be acceptable. I mean,the only known way to preserve routing system scalability is to use strict provider aggregation, which means that IPs will only inject its own aggregate into the routing system and that no end sites prefixes will be cisible in the global routing table. AFAIU you are proposing that that a route to the home prefix is injected in the DFZ routing table? is this correct? if so, how do plan to make the routing system scale? Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Pascal > Thubert (pthubert) > Enviado el: lunes, 19 de abril de 2004 10:12 > Para: Alexandru Petrescu; Jee J.Z. > CC: nemo@ietf.org > Asunto: RE: [nemo] Re: Question-HAHA > > > You may want to give a look at the appendix in the HAHA protocol. > > For the global HA distribution, there is an overall aggregation of all > MNPs that is advertised by all HAs, wherever they are (they are not > expected to be on a same link) to the infrastructure (the internet). So > all the MNPs are 'topologically correct' at any of the HA regarding the > external infrastructure. > > Then the HAs are cross connected with a mesh of tunnels, over which they > run HAHA, in order to distribute a finer granularity of routes. The MNPs > are partitioned in smaller aggregations that belong to a given home > link, which aggregation is advertised by HAs to other HAs using HAHA. If > a MRs binds to its normal HA, the HA does not need to reinject the MNP > routes to the other HAs because the MNP belongs to the aggregation that > it already advertises. > > By if a foreign MR binds a foreign MNP to the HA, then the HA needs to > reinject the MNP granularity over HAHA, long as the binding stands. If > the MR uses an MNP address to bind, it does not need to recomputed a > Home Address, but if it uses a home link address, then it needs to > compute it from the prefix on the new home link. > > For end to end communications, the MR has to choose between it's careof, > it's home address and its address on MNP. We already discussed the > heuristics for that choice. The MNP based address is the longest lasting > one, but it's also the most costly in terms of path (hops). > > LFN communication should not be interrupted but for the duration of the > BU and then the MNP route redistribution between HAs. > > Pascal > > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Alexandru Petrescu > > Sent: vendredi 16 avril 2004 23:30 > > To: Jee J.Z. > > Cc: nemo@ietf.org > > Subject: Re: [nemo] Re: Question-HAHA > > > > Jee J.Z. wrote: > > >> Pascal Thubert (pthubert) wrote: > > >> > > >>> It depends on the model. If the MR takes its home address from > > >>> its MNP then it does not need to. If the Home address is from a > > >>> home link, then it needs to change if it takes a home agent on a > > >>> different home link. This may happen in the case of Home Agent > > >>> Global Distribution with the HAHA protocol. > > >> > > >> Right, and in all the above cases all app->level communications > > >> running on MR or LFN will be interrupted when MR >changes its HA, > > >> right? > > > > > > Why will all communications (running on MR or LFN) be interrupted in > > > the first case (the MR does not need to change its home address)? > > > > Because one can not have the same Home Address topologically correct > at > > two different Home Agents that sit on different links (links separated > > by routers), right? > > > > > Moreover, in the second case (the MR needs to change its home > > > address), why will communications running on LFN be interrupted? > > > > Because the address of the LFN is derived from a prefix that is > > topologically correct at only one HA, and that prefix can not be > > topologically correct at another HA that sits on a different link > (links > > separated by routers), right? > > > > On another hand, if it is assumed somehow that a MNP prefix or a Home > > Address can be made topologically correct at two distinct places in > the > > network mesh (like with multi-homing or something) then no Mobile IPv6 > > is needed at all to tunnel traffic from a Home Address to a Care-of > > Address, because the Care-of Address is, in fact, the Home Address > > itself that was made topologically correct everywhere, no? > > > > Alex > From nemo-admin@ietf.org Tue Apr 20 18:16:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02351 for ; Tue, 20 Apr 2004 18:16:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3LW-0003r3-2q; Tue, 20 Apr 2004 18:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2xc-0004ec-3O for nemo@optimus.ietf.org; Tue, 20 Apr 2004 17:39:22 -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 RAA27901 for ; Tue, 20 Apr 2004 17:39: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 1BG2xZ-0001wP-KZ for nemo@ietf.org; Tue, 20 Apr 2004 17:39:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2wb-0001qP-00 for nemo@ietf.org; Tue, 20 Apr 2004 17:38:17 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BG2vi-0001hd-00 for nemo@ietf.org; Tue, 20 Apr 2004 17:37:22 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3KLaGn20969; Tue, 20 Apr 2004 14:36:16 -0700 X-mProtect: <200404202136> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNSk66N; Tue, 20 Apr 2004 14:36:14 PDT Message-ID: <408597F2.5010109@iprg.nokia.com> Date: Tue, 20 Apr 2004 14:36:50 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO References: In-Reply-To: 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit well, maybe I was wrong. I will remove the sentence. Vijay Soliman Hesham wrote: > > > I dont see any concensus on this thread. > > => Who disagreed? I'll go thru emails again > but I don't recall anyone disagreeing. > > > I ofcourse > > favor removing this sentence. > > => ok. > > Hesham > > > > > Vijay > > > > Soliman Hesham wrote: > > > > > > > > > > > => Nemo extends the BU but AFAICS it doesn't exclude using > > > > > it for host mobility. I think this would be a mistake. > > > > > > > > You missed my point. > > > > > > > > I wanted to say that > > > > when a MR uses the same HoA, the MR should not send > > both a normal BU > > > > (without R flag) and a BU with R-flag simultaneously for the > > > > same HoA. > > > > We should prohibit sending normal Binding Updates to HA > > for MR's HoA. > > > > > > => Sorry, it wasn't clear to me. Of course I agree with that. > > > It's one BU, loaded with whatever extensions a node needs. > > > > > > Hesham > > > > > > ======================================================== > > > 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. > > > ======================================================== > > > > > > > > > > From exim@www1.ietf.org Tue Apr 20 18:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04463 for ; Tue, 20 Apr 2004 18:40:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3k5-000749-57 for nemo-archive@odin.ietf.org; Tue, 20 Apr 2004 18:29:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMTPgN027147 for nemo-archive@odin.ietf.org; Tue, 20 Apr 2004 18:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Zj-0000iq-R9 for nemo-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 18:18: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 SAA02887 for ; Tue, 20 Apr 2004 18:18:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3Zg-0006mK-Ve for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 18:18:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3Yc-0006aR-00 for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 18:17:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3X3-0006I3-00 for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 18:15:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3LW-0003r3-2q; Tue, 20 Apr 2004 18:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2xc-0004ec-3O for nemo@optimus.ietf.org; Tue, 20 Apr 2004 17:39:22 -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 RAA27901 for ; Tue, 20 Apr 2004 17:39: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 1BG2xZ-0001wP-KZ for nemo@ietf.org; Tue, 20 Apr 2004 17:39:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2wb-0001qP-00 for nemo@ietf.org; Tue, 20 Apr 2004 17:38:17 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BG2vi-0001hd-00 for nemo@ietf.org; Tue, 20 Apr 2004 17:37:22 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3KLaGn20969; Tue, 20 Apr 2004 14:36:16 -0700 X-mProtect: <200404202136> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNSk66N; Tue, 20 Apr 2004 14:36:14 PDT Message-ID: <408597F2.5010109@iprg.nokia.com> Date: Tue, 20 Apr 2004 14:36:50 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] issue 35 on how MR spec is relaxed with respect to MH RO References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit well, maybe I was wrong. I will remove the sentence. Vijay Soliman Hesham wrote: > > > I dont see any concensus on this thread. > > => Who disagreed? I'll go thru emails again > but I don't recall anyone disagreeing. > > > I ofcourse > > favor removing this sentence. > > => ok. > > Hesham > > > > > Vijay > > > > Soliman Hesham wrote: > > > > > > > > > > > => Nemo extends the BU but AFAICS it doesn't exclude using > > > > > it for host mobility. I think this would be a mistake. > > > > > > > > You missed my point. > > > > > > > > I wanted to say that > > > > when a MR uses the same HoA, the MR should not send > > both a normal BU > > > > (without R flag) and a BU with R-flag simultaneously for the > > > > same HoA. > > > > We should prohibit sending normal Binding Updates to HA > > for MR's HoA. > > > > > > => Sorry, it wasn't clear to me. Of course I agree with that. > > > It's one BU, loaded with whatever extensions a node needs. > > > > > > Hesham > > > > > > ======================================================== > > > 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. > > > ======================================================== > > > > > > > > > > From nemo-admin@ietf.org Tue Apr 20 20:36:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11164 for ; Tue, 20 Apr 2004 20:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5c1-0003O9-M1; Tue, 20 Apr 2004 20:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5YL-0000l8-AE for nemo@optimus.ietf.org; Tue, 20 Apr 2004 20:25: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 UAA10307 for ; Tue, 20 Apr 2004 20:25: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 1BG5YJ-0001G5-6J for nemo@ietf.org; Tue, 20 Apr 2004 20:25:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5XT-0001CJ-00 for nemo@ietf.org; Tue, 20 Apr 2004 20:24:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BG5Wn-00014k-00 for nemo@ietf.org; Tue, 20 Apr 2004 20:23:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3L0NDe32657; Tue, 20 Apr 2004 17:23:13 -0700 X-mProtect: <200404210023> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdC2c2rf; Tue, 20 Apr 2004 15:39:57 PDT Message-ID: <4085A6E1.1020300@iprg.nokia.com> Date: Tue, 20 Apr 2004 15:40:33 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson CC: nemo@ietf.org Subject: Re: [nemo] summary of same MNP to mutliple MRs discussion References: <406B5F89.1020503@iprg.nokia.com> <4073B72C.80909@ericsson.com> In-Reply-To: <4073B72C.80909@ericsson.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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Mattias, Mattias Pettersson wrote: >> >> if the Prefx Table says both MR1 and MR2 are authorized >> for a MNP, then it _is_ possible for both MR1 and MR2 >> to register with the Home Agent with the same MNP at >> the same time. the HA then has two routes to the MNP, >> one route pointing to MR1 and the second pointing to MR2. >> this is what Hesham is talking about. the current NEMO >> basic support spec works in this case. > > > And it is made clear that this is supported? maybe not. but the basic support spec does not prohibit this. my understanding is that this will be handled in this WG when multihoming for NEMO is addressed in a separate spec. > > I think we need to tie in the discussions in issue 34. > > If an IGP is used, then the IGP will manage the routing table and create > two entries. If only one HA is used, then the two entries will be in the > routing table of this HA, each of them pointing out an HA-MR tunnel. If > two separate HAs are used, where the two MRs register with one each, the > IGP will make sure that each HA has two entries: one pointing out the > local HA-MR tunnel, the other pointing out the other HA. > > On the other hand, if no IGP is used, we have to depend on the prefix > table. I assume it will work when only one HA is in used. When two > separate HAs are in use, there has to be an out-of-band synchronisation > of the prefix tables on the two HAs. However, I think this > synchronisation is out of specification. okay. >> if the Mobile Network splits, with MR1 in one network >> and MR2 in another network, both advertising the same >> MNP and both registered with the Home Agent, then there >> is a problem. Hesham wants this stated in the spec. the >> Home Agent could pick the wrong route. > > > Yes, but the form of distributed multilink subnet Pascal talked about > would be a way to keep a split mobile network together. > > I think there are good reasons to support both a NEMO with a single MNP > but multiple MRs, and allow it to split. distributed multilink subnets sound interesting. I think we need to look into them separately either in NEMO or in another WG. but not in the NEMO basic support. > >> on top of everything we dont have a clear definition >> of what it means when two Mobile Networks merge or split. >> (we are _not_ talking about nesting here). this is >> almost MANET space. > > > If one MNP is used: > > It is very much like multilink subnetting. A subnet that previously > spanned a single link now spans two separate links. If the two links are > connected to two router-mode interfaces of a multilink subnet router > then they can still reach each other and still use the same MNP. Now > with NEMO, the MLSR will be distributed over multiple MRs, so the each > MR will have to tunnel traffic to another MR for MNNs that are in that > MR's partition of the NEMO. > > On the other hand, without the distributed multilink subnetting, the > NEMO is broken, of course. > > I would say that this case requires _coordination_ between MRs. > > > If one MNP per MR is used: > > The NEMO essentially consists of two separate NEMOs, just merging their > ingress links. An MNN may use the MRs of the other NEMO, but it will > have to implement some form of host multihoming (optionally with session > continuity support) to deal with SAS, DRS and NEMO split. > > I would say that this case _does not_ require coordination between MRs. I think I understand now. it might be a good idea to write up a draft on this. Vijay From exim@www1.ietf.org Tue Apr 20 21:01:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12496 for ; Tue, 20 Apr 2004 21:01:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5wK-0003qu-U6 for nemo-archive@odin.ietf.org; Tue, 20 Apr 2004 20:50:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L0oCnX014804 for nemo-archive@odin.ietf.org; Tue, 20 Apr 2004 20:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5ko-0007yx-GX for nemo-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 20:38:18 -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 UAA11262 for ; Tue, 20 Apr 2004 20:38: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 1BG5km-0002cY-4h for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 20:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5jp-0002YY-00 for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 20:37:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG5it-0002UA-00 for nemo-web-archive@ietf.org; Tue, 20 Apr 2004 20:36:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5c1-0003O9-M1; Tue, 20 Apr 2004 20:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5YL-0000l8-AE for nemo@optimus.ietf.org; Tue, 20 Apr 2004 20:25: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 UAA10307 for ; Tue, 20 Apr 2004 20:25: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 1BG5YJ-0001G5-6J for nemo@ietf.org; Tue, 20 Apr 2004 20:25:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5XT-0001CJ-00 for nemo@ietf.org; Tue, 20 Apr 2004 20:24:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BG5Wn-00014k-00 for nemo@ietf.org; Tue, 20 Apr 2004 20:23:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3L0NDe32657; Tue, 20 Apr 2004 17:23:13 -0700 X-mProtect: <200404210023> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdC2c2rf; Tue, 20 Apr 2004 15:39:57 PDT Message-ID: <4085A6E1.1020300@iprg.nokia.com> Date: Tue, 20 Apr 2004 15:40:33 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson CC: nemo@ietf.org Subject: Re: [nemo] summary of same MNP to mutliple MRs discussion References: <406B5F89.1020503@iprg.nokia.com> <4073B72C.80909@ericsson.com> In-Reply-To: <4073B72C.80909@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Hi Mattias, Mattias Pettersson wrote: >> >> if the Prefx Table says both MR1 and MR2 are authorized >> for a MNP, then it _is_ possible for both MR1 and MR2 >> to register with the Home Agent with the same MNP at >> the same time. the HA then has two routes to the MNP, >> one route pointing to MR1 and the second pointing to MR2. >> this is what Hesham is talking about. the current NEMO >> basic support spec works in this case. > > > And it is made clear that this is supported? maybe not. but the basic support spec does not prohibit this. my understanding is that this will be handled in this WG when multihoming for NEMO is addressed in a separate spec. > > I think we need to tie in the discussions in issue 34. > > If an IGP is used, then the IGP will manage the routing table and create > two entries. If only one HA is used, then the two entries will be in the > routing table of this HA, each of them pointing out an HA-MR tunnel. If > two separate HAs are used, where the two MRs register with one each, the > IGP will make sure that each HA has two entries: one pointing out the > local HA-MR tunnel, the other pointing out the other HA. > > On the other hand, if no IGP is used, we have to depend on the prefix > table. I assume it will work when only one HA is in used. When two > separate HAs are in use, there has to be an out-of-band synchronisation > of the prefix tables on the two HAs. However, I think this > synchronisation is out of specification. okay. >> if the Mobile Network splits, with MR1 in one network >> and MR2 in another network, both advertising the same >> MNP and both registered with the Home Agent, then there >> is a problem. Hesham wants this stated in the spec. the >> Home Agent could pick the wrong route. > > > Yes, but the form of distributed multilink subnet Pascal talked about > would be a way to keep a split mobile network together. > > I think there are good reasons to support both a NEMO with a single MNP > but multiple MRs, and allow it to split. distributed multilink subnets sound interesting. I think we need to look into them separately either in NEMO or in another WG. but not in the NEMO basic support. > >> on top of everything we dont have a clear definition >> of what it means when two Mobile Networks merge or split. >> (we are _not_ talking about nesting here). this is >> almost MANET space. > > > If one MNP is used: > > It is very much like multilink subnetting. A subnet that previously > spanned a single link now spans two separate links. If the two links are > connected to two router-mode interfaces of a multilink subnet router > then they can still reach each other and still use the same MNP. Now > with NEMO, the MLSR will be distributed over multiple MRs, so the each > MR will have to tunnel traffic to another MR for MNNs that are in that > MR's partition of the NEMO. > > On the other hand, without the distributed multilink subnetting, the > NEMO is broken, of course. > > I would say that this case requires _coordination_ between MRs. > > > If one MNP per MR is used: > > The NEMO essentially consists of two separate NEMOs, just merging their > ingress links. An MNN may use the MRs of the other NEMO, but it will > have to implement some form of host multihoming (optionally with session > continuity support) to deal with SAS, DRS and NEMO split. > > I would say that this case _does not_ require coordination between MRs. I think I understand now. it might be a good idea to write up a draft on this. Vijay From nemo-admin@ietf.org Thu Apr 22 03:08:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07334 for ; Thu, 22 Apr 2004 03:08:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYAn-0000gU-PS; Thu, 22 Apr 2004 02:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGY4m-0006TB-EF for nemo@optimus.ietf.org; Thu, 22 Apr 2004 02:52:48 -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 CAA06463 for ; Thu, 22 Apr 2004 02:52:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGY4i-000409-Cd for nemo@ietf.org; Thu, 22 Apr 2004 02:52:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGY42-0003nP-00 for nemo@ietf.org; Thu, 22 Apr 2004 02:52:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BGY3N-0003X8-00 for nemo@ietf.org; Thu, 22 Apr 2004 02:51:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2004 08:55:33 +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 i3M6okbj017544; Thu, 22 Apr 2004 08:50:49 +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); Thu, 22 Apr 2004 07:50:59 +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-HAHA Date: Thu, 22 Apr 2004 07:50:58 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQmzIPfn9lkIEVcQyK5nWPoeflSGABaA/aA From: "Pascal Thubert \(pthubert\)" To: , "Alexandru Petrescu" , "Jee J.Z." Cc: X-OriginalArrivalTime: 22 Apr 2004 06:50:59.0140 (UTC) FILETIME=[2B342840:01C42836] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] > Sent: mardi 20 avril 2004 13:38 > To: Pascal Thubert (pthubert); Alexandru Petrescu; Jee J.Z. > Cc: nemo@ietf.org > Subject: RE: [nemo] Re: Question-HAHA >=20 > Hi Pascal, >=20 > I am not sure that i am really understanding what you are proposing here, i > must admit i have only made my first reading of the haha draft, but are you > supposing that the aggregated home prefix will be injected through several > providers? >=20 Well, I expect that a provider who proposes such a service owns several points of presence distributed worldwide, and advertises this mobile aggregation from some of these POPs. > If so, i am not really sure this will be acceptable. I mean,the only known > way to preserve routing system scalability is to use strict provider > aggregation, which means that IPs will only inject its own aggregate into > the routing system and that no end sites prefixes will be cisible in the > global routing table. > AFAIU you are proposing that that a route to the home prefix is injected in > the DFZ routing table? is this correct? if so, how do plan to make the > routing system scale? Only the most global aggregation of all the SP mobile services has to be exposed from several places. But I guess this is a valid discussion to have with actual deployers. > Regards, marcelo >=20 > > -----Mensaje original----- > > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Pascal > > Thubert (pthubert) > > Enviado el: lunes, 19 de abril de 2004 10:12 > > Para: Alexandru Petrescu; Jee J.Z. > > CC: nemo@ietf.org > > Asunto: RE: [nemo] Re: Question-HAHA > > > > > > You may want to give a look at the appendix in the HAHA protocol. > > > > For the global HA distribution, there is an overall aggregation of all > > MNPs that is advertised by all HAs, wherever they are (they are not > > expected to be on a same link) to the infrastructure (the internet). So > > all the MNPs are 'topologically correct' at any of the HA regarding the > > external infrastructure. > > > > Then the HAs are cross connected with a mesh of tunnels, over which they > > run HAHA, in order to distribute a finer granularity of routes. The MNPs > > are partitioned in smaller aggregations that belong to a given home > > link, which aggregation is advertised by HAs to other HAs using HAHA. If > > a MRs binds to its normal HA, the HA does not need to reinject the MNP > > routes to the other HAs because the MNP belongs to the aggregation that > > it already advertises. > > > > By if a foreign MR binds a foreign MNP to the HA, then the HA needs to > > reinject the MNP granularity over HAHA, long as the binding stands. If > > the MR uses an MNP address to bind, it does not need to recomputed a > > Home Address, but if it uses a home link address, then it needs to > > compute it from the prefix on the new home link. > > > > For end to end communications, the MR has to choose between it's careof, > > it's home address and its address on MNP. We already discussed the > > heuristics for that choice. The MNP based address is the longest lasting > > one, but it's also the most costly in terms of path (hops). > > > > LFN communication should not be interrupted but for the duration of the > > BU and then the MNP route redistribution between HAs. > > > > Pascal > > > > > -----Original Message----- > > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > > Alexandru Petrescu > > > Sent: vendredi 16 avril 2004 23:30 > > > To: Jee J.Z. > > > Cc: nemo@ietf.org > > > Subject: Re: [nemo] Re: Question-HAHA > > > > > > Jee J.Z. wrote: > > > >> Pascal Thubert (pthubert) wrote: > > > >> > > > >>> It depends on the model. If the MR takes its home address from > > > >>> its MNP then it does not need to. If the Home address is from a > > > >>> home link, then it needs to change if it takes a home agent on a > > > >>> different home link. This may happen in the case of Home Agent > > > >>> Global Distribution with the HAHA protocol. > > > >> > > > >> Right, and in all the above cases all app->level communications > > > >> running on MR or LFN will be interrupted when MR >changes its HA, > > > >> right? > > > > > > > > Why will all communications (running on MR or LFN) be interrupted in > > > > the first case (the MR does not need to change its home address)? > > > > > > Because one can not have the same Home Address topologically correct > > at > > > two different Home Agents that sit on different links (links separated > > > by routers), right? > > > > > > > Moreover, in the second case (the MR needs to change its home > > > > address), why will communications running on LFN be interrupted? > > > > > > Because the address of the LFN is derived from a prefix that is > > > topologically correct at only one HA, and that prefix can not be > > > topologically correct at another HA that sits on a different link > > (links > > > separated by routers), right? > > > > > > On another hand, if it is assumed somehow that a MNP prefix or a Home > > > Address can be made topologically correct at two distinct places in > > the > > > network mesh (like with multi-homing or something) then no Mobile IPv6 > > > is needed at all to tunnel traffic from a Home Address to a Care-of > > > Address, because the Care-of Address is, in fact, the Home Address > > > itself that was made topologically correct everywhere, no? > > > > > > Alex > > From exim@www1.ietf.org Thu Apr 22 03:24:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08443 for ; Thu, 22 Apr 2004 03:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYY5-00045U-Ox for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 03:23:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M7N5Ag015707 for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 03:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYLQ-0006cK-Dy for nemo-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 03:10:00 -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 DAA07470 for ; Thu, 22 Apr 2004 03:09:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGYLM-00004U-FU for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 03:09:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYKN-0007cq-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 03:08:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGYJH-0007My-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 03:07:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYAn-0000gU-PS; Thu, 22 Apr 2004 02:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGY4m-0006TB-EF for nemo@optimus.ietf.org; Thu, 22 Apr 2004 02:52:48 -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 CAA06463 for ; Thu, 22 Apr 2004 02:52:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGY4i-000409-Cd for nemo@ietf.org; Thu, 22 Apr 2004 02:52:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGY42-0003nP-00 for nemo@ietf.org; Thu, 22 Apr 2004 02:52:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BGY3N-0003X8-00 for nemo@ietf.org; Thu, 22 Apr 2004 02:51:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2004 08:55:33 +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 i3M6okbj017544; Thu, 22 Apr 2004 08:50:49 +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); Thu, 22 Apr 2004 07:50:59 +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-HAHA Date: Thu, 22 Apr 2004 07:50:58 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQmzIPfn9lkIEVcQyK5nWPoeflSGABaA/aA From: "Pascal Thubert \(pthubert\)" To: , "Alexandru Petrescu" , "Jee J.Z." Cc: X-OriginalArrivalTime: 22 Apr 2004 06:50:59.0140 (UTC) FILETIME=[2B342840:01C42836] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] > Sent: mardi 20 avril 2004 13:38 > To: Pascal Thubert (pthubert); Alexandru Petrescu; Jee J.Z. > Cc: nemo@ietf.org > Subject: RE: [nemo] Re: Question-HAHA >=20 > Hi Pascal, >=20 > I am not sure that i am really understanding what you are proposing here, i > must admit i have only made my first reading of the haha draft, but are you > supposing that the aggregated home prefix will be injected through several > providers? >=20 Well, I expect that a provider who proposes such a service owns several points of presence distributed worldwide, and advertises this mobile aggregation from some of these POPs. > If so, i am not really sure this will be acceptable. I mean,the only known > way to preserve routing system scalability is to use strict provider > aggregation, which means that IPs will only inject its own aggregate into > the routing system and that no end sites prefixes will be cisible in the > global routing table. > AFAIU you are proposing that that a route to the home prefix is injected in > the DFZ routing table? is this correct? if so, how do plan to make the > routing system scale? Only the most global aggregation of all the SP mobile services has to be exposed from several places. But I guess this is a valid discussion to have with actual deployers. > Regards, marcelo >=20 > > -----Mensaje original----- > > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Pascal > > Thubert (pthubert) > > Enviado el: lunes, 19 de abril de 2004 10:12 > > Para: Alexandru Petrescu; Jee J.Z. > > CC: nemo@ietf.org > > Asunto: RE: [nemo] Re: Question-HAHA > > > > > > You may want to give a look at the appendix in the HAHA protocol. > > > > For the global HA distribution, there is an overall aggregation of all > > MNPs that is advertised by all HAs, wherever they are (they are not > > expected to be on a same link) to the infrastructure (the internet). So > > all the MNPs are 'topologically correct' at any of the HA regarding the > > external infrastructure. > > > > Then the HAs are cross connected with a mesh of tunnels, over which they > > run HAHA, in order to distribute a finer granularity of routes. The MNPs > > are partitioned in smaller aggregations that belong to a given home > > link, which aggregation is advertised by HAs to other HAs using HAHA. If > > a MRs binds to its normal HA, the HA does not need to reinject the MNP > > routes to the other HAs because the MNP belongs to the aggregation that > > it already advertises. > > > > By if a foreign MR binds a foreign MNP to the HA, then the HA needs to > > reinject the MNP granularity over HAHA, long as the binding stands. If > > the MR uses an MNP address to bind, it does not need to recomputed a > > Home Address, but if it uses a home link address, then it needs to > > compute it from the prefix on the new home link. > > > > For end to end communications, the MR has to choose between it's careof, > > it's home address and its address on MNP. We already discussed the > > heuristics for that choice. The MNP based address is the longest lasting > > one, but it's also the most costly in terms of path (hops). > > > > LFN communication should not be interrupted but for the duration of the > > BU and then the MNP route redistribution between HAs. > > > > Pascal > > > > > -----Original Message----- > > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > > Alexandru Petrescu > > > Sent: vendredi 16 avril 2004 23:30 > > > To: Jee J.Z. > > > Cc: nemo@ietf.org > > > Subject: Re: [nemo] Re: Question-HAHA > > > > > > Jee J.Z. wrote: > > > >> Pascal Thubert (pthubert) wrote: > > > >> > > > >>> It depends on the model. If the MR takes its home address from > > > >>> its MNP then it does not need to. If the Home address is from a > > > >>> home link, then it needs to change if it takes a home agent on a > > > >>> different home link. This may happen in the case of Home Agent > > > >>> Global Distribution with the HAHA protocol. > > > >> > > > >> Right, and in all the above cases all app->level communications > > > >> running on MR or LFN will be interrupted when MR >changes its HA, > > > >> right? > > > > > > > > Why will all communications (running on MR or LFN) be interrupted in > > > > the first case (the MR does not need to change its home address)? > > > > > > Because one can not have the same Home Address topologically correct > > at > > > two different Home Agents that sit on different links (links separated > > > by routers), right? > > > > > > > Moreover, in the second case (the MR needs to change its home > > > > address), why will communications running on LFN be interrupted? > > > > > > Because the address of the LFN is derived from a prefix that is > > > topologically correct at only one HA, and that prefix can not be > > > topologically correct at another HA that sits on a different link > > (links > > > separated by routers), right? > > > > > > On another hand, if it is assumed somehow that a MNP prefix or a Home > > > Address can be made topologically correct at two distinct places in > > the > > > network mesh (like with multi-homing or something) then no Mobile IPv6 > > > is needed at all to tunnel traffic from a Home Address to a Care-of > > > Address, because the Care-of Address is, in fact, the Home Address > > > itself that was made topologically correct everywhere, no? > > > > > > Alex > > From nemo-admin@ietf.org Thu Apr 22 12:03:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07565 for ; Thu, 22 Apr 2004 12:03:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgVZ-0006zB-FW; Thu, 22 Apr 2004 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgNr-0004nM-MQ for nemo@optimus.ietf.org; Thu, 22 Apr 2004 11:45:03 -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 LAA06498 for ; Thu, 22 Apr 2004 11:45:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgNo-0003lc-Dw for nemo@ietf.org; Thu, 22 Apr 2004 11:45:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgMq-0003VO-00 for nemo@ietf.org; Thu, 22 Apr 2004 11:44:01 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BGgM0-0003EB-00 for nemo@ietf.org; Thu, 22 Apr 2004 11:43:08 -0400 Received: from MobileGravity.local.sfc.wide.ad.jp (p6ec6e0.tkyoac00.ap.so-net.ne.jp [218.110.198.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3MFeXrR013110; Fri, 23 Apr 2004 00:40:34 +0900 Date: Fri, 23 Apr 2004 00:42:58 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Cc: pthubert@cisco.com, mazentlais@yahoo.fr, nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA In-Reply-To: <40800AE5.40305@motorola.com> References: <40800AE5.40305@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Fri, 16 Apr 2004 18:33:41 +0200, Alexandru Petrescu wrote: > > [1 ] > Pascal Thubert (pthubert) wrote: > > It depends on the model. If the MR takes its home address from its > > MNP then it does not need to. If the Home address is from a home > > link, then it needs to change if it takes a home agent on a different > > home link. This may happen in the case of Home Agent Global > > Distribution with the HAHA protocol. > > Right, and in all the above cases all app-level communications running > on MR or LFN will be interrupted when MR changes its HA, right? Not true on the HAHA protocol. For example, if MR's MNP is managed as part of aggregated prefix, MR can switch any of HAs that serve the aggregated prefix without any interruption of CN-LFN communication. regards, ryuji From exim@www1.ietf.org Thu Apr 22 12:31:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08816 for ; Thu, 22 Apr 2004 12:31:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh37-0001Jy-Go for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 12:27:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MGRfRU005077 for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 12:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGghG-00020n-7T for nemo-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:05: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 MAA07647 for ; Thu, 22 Apr 2004 12:05:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGghC-0001RB-Qo for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 12:05:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGggK-0001An-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 12:04:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGgfQ-0000um-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 12:03:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgVZ-0006zB-FW; Thu, 22 Apr 2004 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgNr-0004nM-MQ for nemo@optimus.ietf.org; Thu, 22 Apr 2004 11:45:03 -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 LAA06498 for ; Thu, 22 Apr 2004 11:45:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgNo-0003lc-Dw for nemo@ietf.org; Thu, 22 Apr 2004 11:45:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgMq-0003VO-00 for nemo@ietf.org; Thu, 22 Apr 2004 11:44:01 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BGgM0-0003EB-00 for nemo@ietf.org; Thu, 22 Apr 2004 11:43:08 -0400 Received: from MobileGravity.local.sfc.wide.ad.jp (p6ec6e0.tkyoac00.ap.so-net.ne.jp [218.110.198.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3MFeXrR013110; Fri, 23 Apr 2004 00:40:34 +0900 Date: Fri, 23 Apr 2004 00:42:58 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Cc: pthubert@cisco.com, mazentlais@yahoo.fr, nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA In-Reply-To: <40800AE5.40305@motorola.com> References: <40800AE5.40305@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 At Fri, 16 Apr 2004 18:33:41 +0200, Alexandru Petrescu wrote: > > [1 ] > Pascal Thubert (pthubert) wrote: > > It depends on the model. If the MR takes its home address from its > > MNP then it does not need to. If the Home address is from a home > > link, then it needs to change if it takes a home agent on a different > > home link. This may happen in the case of Home Agent Global > > Distribution with the HAHA protocol. > > Right, and in all the above cases all app-level communications running > on MR or LFN will be interrupted when MR changes its HA, right? Not true on the HAHA protocol. For example, if MR's MNP is managed as part of aggregated prefix, MR can switch any of HAs that serve the aggregated prefix without any interruption of CN-LFN communication. regards, ryuji From nemo-admin@ietf.org Thu Apr 22 12:45:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09644 for ; Thu, 22 Apr 2004 12:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4W-0002E0-QW; Thu, 22 Apr 2004 12:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgvo-0007HU-Ua for nemo@optimus.ietf.org; Thu, 22 Apr 2004 12:20:13 -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 MAA08172 for ; Thu, 22 Apr 2004 12:20:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgvl-0005NR-76 for nemo@ietf.org; Thu, 22 Apr 2004 12:20:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgur-00056k-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:19:10 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BGgtt-0004p0-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:18:09 -0400 Received: from MobileGravity.local.sfc.wide.ad.jp (p6ec6e0.tkyoac00.ap.so-net.ne.jp [218.110.198.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3MGFprR013540; Fri, 23 Apr 2004 01:15:52 +0900 Date: Fri, 23 Apr 2004 01:18:18 +0900 Message-ID: From: Ryuji Wakikawa To: jz105@york.ac.uk Cc: Pascal Thubert , Alexandru.Petrescu@motorola.com, nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA In-Reply-To: <007e01c457a3$180c46c0$68892090@grouse> References: <007e01c457a3$180c46c0$68892090@grouse> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Jee and Alex At Mon, 21 Jun 2004 16:19:06 +0100, Jee J.Z. wrote: > Hi Alex, > > I get more clear on the issue after reading Pascal's explanations. Below > inline is what I wrote and thought before Pascal's email, which sounds quite > limited and could be flawed, and the HAHA protocol seems to have covered all > I had thought of -- I'd better read it through. We understood that the current HAHA draft is a bit hard to understand all conepts, because we put many things in the single draft. We are currently working on updates of HAHA. Pleas wait for a while to find the better version:-). And we really appreciate your comments on the HAHA draft. > > Jee J.Z. wrote: > > >>>>> It depends on the model. If the MR takes its home address > > >>>>> from its MNP then it does not need to. If the Home address is > > >>>>> from a home link, then it needs to change if it takes a home > > >>>>> agent on a different home link. This may happen in the case > > >>>>> of Home Agent Global Distribution with the HAHA protocol. > > >>>> > > >>>> Right, and in all the above cases all app->level communications > > >>>> running on MR or LFN will be interrupted when MR >changes its > > >>>> HA, right? > > >>> > > >>> Why will all communications (running on MR or LFN) be interrupted > > >>> in the first case (the MR does not need to change its home > > >>> address)? > > >> > > >> Because one can not have the same Home Address topologically > > >> correct at two different Home Agents that sit on different links > > >> (links separated by routers), right? > > > > > > If it's the case, why can the MR keep its home address unchanged as > > > what Pascal has mentioned? > > > > I don't know. > > So this issue is still pending? Which issue? When HoA is retrieved from MR's MNP, HoA is never changed unless MNP is changed. Whether MNP can change its serving HA is another problem. This is addressed by pascal's nemo-usage draft and HAHA. > > > I assume the MR can have the same home address because the two HAs > > > are on the same link. > > > > When the HA's are on the same link then there is another mechanism > > defined by Mobile IPv6 by which the MR may choose among several HA's on > > the home link. > > Yes, but aren't we talking about handover among these HA's? For load > balancing purpose, I think the MR may choose to handover to a new HA on the > same link as the previous HA, so it can keep its home address unchanged. Do > you mean this handover does not in the scope of HAHA? I can't think of MIPv6 > can manage HA handover. It is in the scope of HAHA. > > >>> Moreover, in the second case (the MR needs to change its home > > >>> address), why will communications running on LFN be interrupted? > > >> > > >> Because the address of the LFN is derived from a prefix that is > > >> topologically correct at only one HA, and that prefix can not be > > >> topologically correct at another HA that sits on a different link > > >> (links separated by routers), right? > > > > > > Isn't the HA of a LFN independent with the HA of its MR (please > > > correct me if not)? > > > > LFN has no HA since it's fixed and runs no Mobile IPv6. When packets > > from CN are addressed to CN then it's MR's HA that intercepts these > > packets and forwarded/tunnelled to the MR's CoA. In this sense, one may > > say that MR's HA is the same as LFN's HA, although it's not quite > > correct since LFN does not do any Mobile IPv6. > > Thank you. That's my confusion on definitions. > > > > I mean whether the home address of the MR changes or not, the home > > > address of the LFN does not need to change, > > > > This is correct, I understand that. > > > > > which means the communication session between the LFN and a CN will > > > not be broken. > > > > Comm from CN to LFN must be intercepted by MR's HA in order to be > > forwarded to current position of MR and further to LFN. So, LFN's > > address must be topologically correct at MR's HA (in practice, LFN's > > address is derived from MNP and MNP is topologically correct at HA). > > And, because the MR's home address can not be topologically correct at > > two different HA's the same MNP can not be either; so it's because the > > MR's HoA changes that CN-LFN comms are interrupted (not because the MR's > > CoA changes). > > OK, I understand now. LFN is not aware of HoA's change as long as MNP is not changed. > > > IMHO, MNP prefix could be made topologically correct at two distinct > > > places (please correct me if not), > > > > Please tell me how the MNP prefix is made topologically correct at two > > distinct places in the network (places separated by routers), and then > > I'll tell you why Mobile IP is not needed in that case. > > OK. Well, actually I am thinking whether MNP handover is possible. Say there > are two HA's on different links. Both of them could advertise the > reachability of an aggregation of the MR's MNP. When the MR selects one of > the two HA's (say HA1), HA1 assigns the MNP to the MR and does the > redirection job for the MNP; when the MR decides to change its HA to HA2, > the MNP is handed over to HA2, and HA2 manages the MNP and does the > redirection job. However, because the two HA's are on different links, the > home address of the MR has to change. It's possible. The point is whether we can allow HoA<->MNP relationship dynamically. My answer is yes with pascal's nemo-usage and HAHA protocol. please check fig2 and appendix of the haha draft. ryuji > Regards, > Jee > > > > while home address can only be topologically correct on the same > > > link. > > > > I think that if a unique MNP is valid at two different nets then a full > > /128 address can be made so too. > > > > Alex > > > > From exim@www1.ietf.org Thu Apr 22 13:00:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10685 for ; Thu, 22 Apr 2004 13:00:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhTF-00029S-9i for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 12:54:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MGsfMZ008263 for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 12:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhLu-0007wx-JN for nemo-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:47: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 MAA09692 for ; Thu, 22 Apr 2004 12:47: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 1BGhLp-0005Fj-Fo for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 12:47:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhKq-0004z3-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 12:46:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhJp-0004dS-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 12:44:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4W-0002E0-QW; Thu, 22 Apr 2004 12:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgvo-0007HU-Ua for nemo@optimus.ietf.org; Thu, 22 Apr 2004 12:20:13 -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 MAA08172 for ; Thu, 22 Apr 2004 12:20:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgvl-0005NR-76 for nemo@ietf.org; Thu, 22 Apr 2004 12:20:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgur-00056k-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:19:10 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BGgtt-0004p0-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:18:09 -0400 Received: from MobileGravity.local.sfc.wide.ad.jp (p6ec6e0.tkyoac00.ap.so-net.ne.jp [218.110.198.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3MGFprR013540; Fri, 23 Apr 2004 01:15:52 +0900 Date: Fri, 23 Apr 2004 01:18:18 +0900 Message-ID: From: Ryuji Wakikawa To: jz105@york.ac.uk Cc: Pascal Thubert , Alexandru.Petrescu@motorola.com, nemo@ietf.org Subject: Re: [nemo] Re: Question-HAHA In-Reply-To: <007e01c457a3$180c46c0$68892090@grouse> References: <007e01c457a3$180c46c0$68892090@grouse> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Hello Jee and Alex At Mon, 21 Jun 2004 16:19:06 +0100, Jee J.Z. wrote: > Hi Alex, > > I get more clear on the issue after reading Pascal's explanations. Below > inline is what I wrote and thought before Pascal's email, which sounds quite > limited and could be flawed, and the HAHA protocol seems to have covered all > I had thought of -- I'd better read it through. We understood that the current HAHA draft is a bit hard to understand all conepts, because we put many things in the single draft. We are currently working on updates of HAHA. Pleas wait for a while to find the better version:-). And we really appreciate your comments on the HAHA draft. > > Jee J.Z. wrote: > > >>>>> It depends on the model. If the MR takes its home address > > >>>>> from its MNP then it does not need to. If the Home address is > > >>>>> from a home link, then it needs to change if it takes a home > > >>>>> agent on a different home link. This may happen in the case > > >>>>> of Home Agent Global Distribution with the HAHA protocol. > > >>>> > > >>>> Right, and in all the above cases all app->level communications > > >>>> running on MR or LFN will be interrupted when MR >changes its > > >>>> HA, right? > > >>> > > >>> Why will all communications (running on MR or LFN) be interrupted > > >>> in the first case (the MR does not need to change its home > > >>> address)? > > >> > > >> Because one can not have the same Home Address topologically > > >> correct at two different Home Agents that sit on different links > > >> (links separated by routers), right? > > > > > > If it's the case, why can the MR keep its home address unchanged as > > > what Pascal has mentioned? > > > > I don't know. > > So this issue is still pending? Which issue? When HoA is retrieved from MR's MNP, HoA is never changed unless MNP is changed. Whether MNP can change its serving HA is another problem. This is addressed by pascal's nemo-usage draft and HAHA. > > > I assume the MR can have the same home address because the two HAs > > > are on the same link. > > > > When the HA's are on the same link then there is another mechanism > > defined by Mobile IPv6 by which the MR may choose among several HA's on > > the home link. > > Yes, but aren't we talking about handover among these HA's? For load > balancing purpose, I think the MR may choose to handover to a new HA on the > same link as the previous HA, so it can keep its home address unchanged. Do > you mean this handover does not in the scope of HAHA? I can't think of MIPv6 > can manage HA handover. It is in the scope of HAHA. > > >>> Moreover, in the second case (the MR needs to change its home > > >>> address), why will communications running on LFN be interrupted? > > >> > > >> Because the address of the LFN is derived from a prefix that is > > >> topologically correct at only one HA, and that prefix can not be > > >> topologically correct at another HA that sits on a different link > > >> (links separated by routers), right? > > > > > > Isn't the HA of a LFN independent with the HA of its MR (please > > > correct me if not)? > > > > LFN has no HA since it's fixed and runs no Mobile IPv6. When packets > > from CN are addressed to CN then it's MR's HA that intercepts these > > packets and forwarded/tunnelled to the MR's CoA. In this sense, one may > > say that MR's HA is the same as LFN's HA, although it's not quite > > correct since LFN does not do any Mobile IPv6. > > Thank you. That's my confusion on definitions. > > > > I mean whether the home address of the MR changes or not, the home > > > address of the LFN does not need to change, > > > > This is correct, I understand that. > > > > > which means the communication session between the LFN and a CN will > > > not be broken. > > > > Comm from CN to LFN must be intercepted by MR's HA in order to be > > forwarded to current position of MR and further to LFN. So, LFN's > > address must be topologically correct at MR's HA (in practice, LFN's > > address is derived from MNP and MNP is topologically correct at HA). > > And, because the MR's home address can not be topologically correct at > > two different HA's the same MNP can not be either; so it's because the > > MR's HoA changes that CN-LFN comms are interrupted (not because the MR's > > CoA changes). > > OK, I understand now. LFN is not aware of HoA's change as long as MNP is not changed. > > > IMHO, MNP prefix could be made topologically correct at two distinct > > > places (please correct me if not), > > > > Please tell me how the MNP prefix is made topologically correct at two > > distinct places in the network (places separated by routers), and then > > I'll tell you why Mobile IP is not needed in that case. > > OK. Well, actually I am thinking whether MNP handover is possible. Say there > are two HA's on different links. Both of them could advertise the > reachability of an aggregation of the MR's MNP. When the MR selects one of > the two HA's (say HA1), HA1 assigns the MNP to the MR and does the > redirection job for the MNP; when the MR decides to change its HA to HA2, > the MNP is handed over to HA2, and HA2 manages the MNP and does the > redirection job. However, because the two HA's are on different links, the > home address of the MR has to change. It's possible. The point is whether we can allow HoA<->MNP relationship dynamically. My answer is yes with pascal's nemo-usage and HAHA protocol. please check fig2 and appendix of the haha draft. ryuji > Regards, > Jee > > > > while home address can only be topologically correct on the same > > > link. > > > > I think that if a unique MNP is valid at two different nets then a full > > /128 address can be made so too. > > > > Alex > > > > From nemo-admin@ietf.org Thu Apr 22 13:02:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10853 for ; Thu, 22 Apr 2004 13:02:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhTb-0002Qv-Uf; Thu, 22 Apr 2004 12:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhLv-0007z1-1S for nemo@optimus.ietf.org; Thu, 22 Apr 2004 12:47:07 -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 MAA09700 for ; Thu, 22 Apr 2004 12:47:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhLq-0005Fv-Tv for nemo@ietf.org; Thu, 22 Apr 2004 12:47:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhKw-0004zl-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:46:06 -0400 Received: from web25003.mail.ukl.yahoo.com ([217.12.10.39]) by ietf-mx with smtp (Exim 4.12) id 1BGhK4-0004Sw-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:45:12 -0400 Message-ID: <20040422164443.34203.qmail@web25003.mail.ukl.yahoo.com> Received: from [137.194.2.20] by web25003.mail.ukl.yahoo.com via HTTP; Thu, 22 Apr 2004 18:44:43 CEST Date: Thu, 22 Apr 2004 18:44:43 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] Re: Question-HAHA To: Ryuji Wakikawa Cc: pthubert@cisco.com, Alexandru.Petrescu@motorola.com, nemo@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1946497581-1082652283=:32866" 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_20_30,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --0-1946497581-1082652283=:32866 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09701 Content-Transfer-Encoding: quoted-printable Ryuji Wakikawa wrote: =20 At Fri, 16 Apr 2004 18:33:41 +0200, Alexandru Petrescu wrote: >=20 > [1 ] > Pascal Thubert (pthubert) wrote: > > It depends on the model. If the MR takes its home address from its=20 > > MNP then it does not need to. If the Home address is from a home=20 > > link, then it needs to change if it takes a home agent on a different > > home link. This may happen in the case of Home Agent Global=20 > > Distribution with the HAHA protocol. >=20 > Right, and in all the above cases all app-level communications running > on MR or LFN will be interrupted when MR changes its HA, right? Not true on the HAHA protocol. For example, if MR's MNP is managed as part of aggregated prefix, MR can switch any of HAs that serve the aggregated prefix without any interruption of CN-LFN communication. regards, ryuji =20 -> Right, but in this case the MR does not have to change its home adress= . the interruption of CN-LFN communication will occurs=20 when the MR has to change its home adress. Right ?? =20 Mazen Tlais =20 =20 =09 --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr=E9ez votre Yahoo! Mail Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-1946497581-1082652283=:32866 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09701 Content-Transfer-Encoding: quoted-printable
Ryuji Wakikawa <ryuji@sfc.wide.ad.jp> wrote:
 
At Fri, 16 Apr 2004 18:33:41 +0200,
Alexandru Petrescu wrote:
= >
> [1 ]
> Pascal Thubert (p= thubert) wrote:
> > It depends on the model. If the MR takes its= home address from its
> > MNP then it does not need to. If the= Home address is from a home
> > link, then it needs to change = if it takes a home agent on a different
> > home link. This may = happen in the case of Home Agent Global
> > Distribution with t= he HAHA protocol.
>
> Right, and in all the above cases all = app-level communications running
> on MR or LFN will be interrupted= when MR changes its HA, right?

Not true on the HAHA protocol.
=
For example, if MR's MNP is managed as part of aggregated prefix, MR<= BR>can switch any of HAs that serve the aggregated prefix without any
= interruption of CN-LFN communication.

regards,
ryuji
 
-> Right, but in this case the MR does not have to change its hom= e adress. the interruption of CN-LFN communication will occurs
when the MR has to change its home adress.
Right ??
 
Mazen Tlais

 



 
<= p>
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Cr=E9ez vot= re Yahoo! Mail

Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-1946497581-1082652283=:32866-- From exim@www1.ietf.org Thu Apr 22 13:34:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12534 for ; Thu, 22 Apr 2004 13:34:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhwU-0003sQ-DP for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 13:24:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MHOscZ014897 for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 13:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhrH-0002Br-SQ for nemo-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 13:19:31 -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 NAA11605 for ; Thu, 22 Apr 2004 13:19: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 1BGhrD-0006Xu-Hm for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 13:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhpN-0005eC-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 13:17:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGhnk-00057l-01 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 13:15:52 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGham-0007mB-BN for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 13:02:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhTb-0002Qv-Uf; Thu, 22 Apr 2004 12:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhLv-0007z1-1S for nemo@optimus.ietf.org; Thu, 22 Apr 2004 12:47:07 -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 MAA09700 for ; Thu, 22 Apr 2004 12:47:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhLq-0005Fv-Tv for nemo@ietf.org; Thu, 22 Apr 2004 12:47:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhKw-0004zl-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:46:06 -0400 Received: from web25003.mail.ukl.yahoo.com ([217.12.10.39]) by ietf-mx with smtp (Exim 4.12) id 1BGhK4-0004Sw-00 for nemo@ietf.org; Thu, 22 Apr 2004 12:45:12 -0400 Message-ID: <20040422164443.34203.qmail@web25003.mail.ukl.yahoo.com> Received: from [137.194.2.20] by web25003.mail.ukl.yahoo.com via HTTP; Thu, 22 Apr 2004 18:44:43 CEST Date: Thu, 22 Apr 2004 18:44:43 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] Re: Question-HAHA To: Ryuji Wakikawa Cc: pthubert@cisco.com, Alexandru.Petrescu@motorola.com, nemo@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1946497581-1082652283=:32866" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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_20_30,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 --0-1946497581-1082652283=:32866 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09701 Content-Transfer-Encoding: quoted-printable Ryuji Wakikawa wrote: =20 At Fri, 16 Apr 2004 18:33:41 +0200, Alexandru Petrescu wrote: >=20 > [1 ] > Pascal Thubert (pthubert) wrote: > > It depends on the model. If the MR takes its home address from its=20 > > MNP then it does not need to. If the Home address is from a home=20 > > link, then it needs to change if it takes a home agent on a different > > home link. This may happen in the case of Home Agent Global=20 > > Distribution with the HAHA protocol. >=20 > Right, and in all the above cases all app-level communications running > on MR or LFN will be interrupted when MR changes its HA, right? Not true on the HAHA protocol. For example, if MR's MNP is managed as part of aggregated prefix, MR can switch any of HAs that serve the aggregated prefix without any interruption of CN-LFN communication. regards, ryuji =20 -> Right, but in this case the MR does not have to change its home adress= . the interruption of CN-LFN communication will occurs=20 when the MR has to change its home adress. Right ?? =20 Mazen Tlais =20 =20 =09 --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr=E9ez votre Yahoo! Mail Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-1946497581-1082652283=:32866 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09701 Content-Transfer-Encoding: quoted-printable
Ryuji Wakikawa <ryuji@sfc.wide.ad.jp> wrote:
 
At Fri, 16 Apr 2004 18:33:41 +0200,
Alexandru Petrescu wrote:
= >
> [1 ]
> Pascal Thubert (p= thubert) wrote:
> > It depends on the model. If the MR takes its= home address from its
> > MNP then it does not need to. If the= Home address is from a home
> > link, then it needs to change = if it takes a home agent on a different
> > home link. This may = happen in the case of Home Agent Global
> > Distribution with t= he HAHA protocol.
>
> Right, and in all the above cases all = app-level communications running
> on MR or LFN will be interrupted= when MR changes its HA, right?

Not true on the HAHA protocol.
=
For example, if MR's MNP is managed as part of aggregated prefix, MR<= BR>can switch any of HAs that serve the aggregated prefix without any
= interruption of CN-LFN communication.

regards,
ryuji
 
-> Right, but in this case the MR does not have to change its hom= e adress. the interruption of CN-LFN communication will occurs
when the MR has to change its home adress.
Right ??
 
Mazen Tlais

 



 
<= p>
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Cr=E9ez vot= re Yahoo! Mail

Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-1946497581-1082652283=:32866-- From nemo-admin@ietf.org Thu Apr 22 16:57:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29720 for ; Thu, 22 Apr 2004 16:57:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkKQ-00070G-Vf; Thu, 22 Apr 2004 15:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk4x-0001Gw-Lh for nemo@optimus.ietf.org; Thu, 22 Apr 2004 15:41:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22591; Thu, 22 Apr 2004 15:41:44 -0400 (EDT) Message-Id: <200404221941.PAA22591@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 22 Apr 2004 15:41:44 -0400 Subject: [nemo] I-D ACTION:draft-ietf-nemo-home-network-models-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --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 : NEMO Home Network models Author(s) : P. Thubert, et al. Filename : draft-ietf-nemo-home-network-models-00.txt Pages : 20 Date : 2004-4-22 This paper documents some usage patterns and the associated issues when deploying a Home Network for Nemo enabled Mobile Routers, conforming the NEMO Basic Support draft [7]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the NEMO and NEMO Design mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-00.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-home-network-models-00.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-home-network-models-00.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-4-22154156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-home-network-models-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-home-network-models-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-22154156.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Apr 22 17:58:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04794 for ; Thu, 22 Apr 2004 17:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlvN-000653-PS for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 17:40:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MLe15E023349 for nemo-archive@odin.ietf.org; Thu, 22 Apr 2004 17:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlHB-0003V3-Da for nemo-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 16:58:29 -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 QAA29889 for ; Thu, 22 Apr 2004 16:58:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlH7-0001uE-7m for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 16:58:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlGI-0001ck-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 16:57:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGlFQ-0001Js-00 for nemo-web-archive@ietf.org; Thu, 22 Apr 2004 16:56:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkKQ-00070G-Vf; Thu, 22 Apr 2004 15:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk4x-0001Gw-Lh for nemo@optimus.ietf.org; Thu, 22 Apr 2004 15:41:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22591; Thu, 22 Apr 2004 15:41:44 -0400 (EDT) Message-Id: <200404221941.PAA22591@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 22 Apr 2004 15:41:44 -0400 Subject: [nemo] I-D ACTION:draft-ietf-nemo-home-network-models-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : NEMO Home Network models Author(s) : P. Thubert, et al. Filename : draft-ietf-nemo-home-network-models-00.txt Pages : 20 Date : 2004-4-22 This paper documents some usage patterns and the associated issues when deploying a Home Network for Nemo enabled Mobile Routers, conforming the NEMO Basic Support draft [7]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the NEMO and NEMO Design mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-00.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-home-network-models-00.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-home-network-models-00.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-4-22154156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-home-network-models-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-home-network-models-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-22154156.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Fri Apr 23 11:14:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13851 for ; Fri, 23 Apr 2004 11:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Ff-000393-Kr; Fri, 23 Apr 2004 11:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2A1-0001j2-Bw for nemo@optimus.ietf.org; Fri, 23 Apr 2004 11:00:13 -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 LAA13161 for ; Fri, 23 Apr 2004 11:00:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH29y-0007Qs-LA for nemo@ietf.org; Fri, 23 Apr 2004 11:00:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH29C-0007Bo-00 for nemo@ietf.org; Fri, 23 Apr 2004 10:59:23 -0400 Received: from web25004.mail.ukl.yahoo.com ([217.12.10.40]) by ietf-mx with smtp (Exim 4.12) id 1BH28H-0006jA-00 for nemo@ietf.org; Fri, 23 Apr 2004 10:58:25 -0400 Message-ID: <20040423145754.50079.qmail@web25004.mail.ukl.yahoo.com> Received: from [137.194.192.85] by web25004.mail.ukl.yahoo.com via HTTP; Fri, 23 Apr 2004 16:57:54 CEST Date: Fri, 23 Apr 2004 16:57:54 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] Re: Question-HAHA To: nemo@ietf.org In-Reply-To: <20040422164443.34203.qmail@web25003.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA13162 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I have ome more question on the haha protocole, thanx for your explanation. =20 when you say : =20 there could be multiple home agents attached to different links serving the same home agent prefix.=20 Do you mean that these multiple home agents that serve the same home prefix moreover belong to the same operator? Mazen =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com From exim@www1.ietf.org Fri Apr 23 11:32:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14848 for ; Fri, 23 Apr 2004 11:32:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2WE-0007r2-Vw for nemo-archive@odin.ietf.org; Fri, 23 Apr 2004 11:23:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFNAka030187 for nemo-archive@odin.ietf.org; Fri, 23 Apr 2004 11:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2PM-0005wU-KF for nemo-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:16: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 LAA13948 for ; Fri, 23 Apr 2004 11:16: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 1BH2PL-0003rw-QF for nemo-web-archive@ietf.org; Fri, 23 Apr 2004 11:16:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2OL-0003bP-00 for nemo-web-archive@ietf.org; Fri, 23 Apr 2004 11:15:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2NN-0003Km-00 for nemo-web-archive@ietf.org; Fri, 23 Apr 2004 11:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Ff-000393-Kr; Fri, 23 Apr 2004 11:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2A1-0001j2-Bw for nemo@optimus.ietf.org; Fri, 23 Apr 2004 11:00:13 -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 LAA13161 for ; Fri, 23 Apr 2004 11:00:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH29y-0007Qs-LA for nemo@ietf.org; Fri, 23 Apr 2004 11:00:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH29C-0007Bo-00 for nemo@ietf.org; Fri, 23 Apr 2004 10:59:23 -0400 Received: from web25004.mail.ukl.yahoo.com ([217.12.10.40]) by ietf-mx with smtp (Exim 4.12) id 1BH28H-0006jA-00 for nemo@ietf.org; Fri, 23 Apr 2004 10:58:25 -0400 Message-ID: <20040423145754.50079.qmail@web25004.mail.ukl.yahoo.com> Received: from [137.194.192.85] by web25004.mail.ukl.yahoo.com via HTTP; Fri, 23 Apr 2004 16:57:54 CEST Date: Fri, 23 Apr 2004 16:57:54 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] Re: Question-HAHA To: nemo@ietf.org In-Reply-To: <20040422164443.34203.qmail@web25003.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA13162 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: quoted-printable Content-Transfer-Encoding: quoted-printable I have ome more question on the haha protocole, thanx for your explanation. =20 when you say : =20 there could be multiple home agents attached to different links serving the same home agent prefix.=20 Do you mean that these multiple home agents that serve the same home prefix moreover belong to the same operator? Mazen =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com From nemo-admin@ietf.org Fri Apr 23 19:24:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21815 for ; Fri, 23 Apr 2004 19:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9tr-0002yx-7m; Fri, 23 Apr 2004 19:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9nO-0000vi-Eu for nemo@optimus.ietf.org; Fri, 23 Apr 2004 19:09:22 -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 TAA21088 for ; Fri, 23 Apr 2004 19:09:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9nL-000300-4L for nemo@ietf.org; Fri, 23 Apr 2004 19:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9mM-0002jd-00 for nemo@ietf.org; Fri, 23 Apr 2004 19:08:20 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BH9lI-0002Fw-00 for nemo@ietf.org; Fri, 23 Apr 2004 19:07:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3NN6cI06572; Fri, 23 Apr 2004 16:06:38 -0700 X-mProtect: <200404232306> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7Nm8xa; Fri, 23 Apr 2004 16:06:36 PDT Message-ID: <4089A1A0.5080401@iprg.nokia.com> Date: Fri, 23 Apr 2004 16:07:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zinin@psg.com CC: margaret@thingmagic.com, nemo@ietf.org 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 Subject: [nemo] your comments on NEMO and routing protocools Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alex, thanks for some very good comments. > Alex Zinin: > > There are several things that concern me when I think about scaling > an implementation of a HA to support a large number of MRs. > > 1. Tunnel interface flapping > > If the tunnel interface goes up and down every time a MR moves to a new > visited network, with high level of mobility and sufficient number of MRs, > the amount of interface state changes well result in CPU overloading on > the HA, as well as high level of instability in the rest of the network > if e.g. a link-state protocol is deployed. > > I understand that the document cannot mandate the way tunnel interfaces > are implemented, but it would be really useful if it provided some > recommendations along the following lines: > > - a tunnel interface is consistently assigned to each remote MR > > - the state of the interface at the IP layer is not changed if > the MR moves from one visited network to another "smoothly", > i.e., does not lose connectivity for too long. This would > probably mean providing some grace period before taking the > interface down when the MR is temporarily unreachable, and > changing the tunnel's tail-end (MR's CoA) address without > flapping the interface. this is a good suggestion. we actually did want something like this, but didnt specify it in the spec. I will add some text on this. however, what do you mean by "consistently assigned"? If the MR is shut off for an extended period of time, the Home Agent should delete any state associated with an MR. or did you mean A tunnel interface is consistently assigned to each remote MR as long as the MR has a valid binding cache entry at the HA. > > 2. Hello packet processing > > The lessons we've learned with FR and ATM clouds suggest that with a large > number of interfaces, Hello packet processing may become a burden. It could > be useful if the document recommended to treat the Tunnel interfaces as > On-Demand circuits in OSPF per RFC 1793. okay. > > 3. Amount of information exchanged between HA and MR > > One disadvantage of using a link-state routing protocol like OSPF in the > NEMO case is that there is a possibility that MRs and mobile networks > will be told the topology of the whole area, or even the domain (if no > areas are used in the network), while the only thing MRs really need > is a default through the HA. > > The same argument works the other way per my comment 1 above. > > At the very minimum, there should be a recommendation that Tunnel > interfaces to MRs are NOT put in the same area as e.g. the backbone links. > > Separating Tunnel interfaces to MRs from the backbone and aggregating > prefix info from mobile networks should prevent potential instabilities > related to MR relocations from destabilizing the rest of the network. again, we will add this to the spec. > > Making the area to which a tunnel interface belongs Stub should save > the RM from too much info sent by the HA. > > To save different RMs from knowing too much about each other, the only > method currently available is to place them each in a separate stub > area, but this may stretch certain implementations. I guess we wont be able decide between making the home link a single area or making each tunnel interface a sub-area without some experimentation. we could point out the pros and cons of each approach and let the admin for the home link decide. we have another draft which talks about how an home link for NEMO can be designed. http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-00.txt this will be an informational document. not a proposed standard. > > More specific comments inline below: > >> 3. Overview of the NEMO Protocol > > ... >> It is also possible for the Mobile Router and the Home Agent to run >> a routing protocol through the bi-directional tunnel. In that case, >> the Mobile Router need not include prefix information in the Binding >> Update. Instead the Home Agent uses the routing protocol updates to >> setup forwarding for the mobile network. When running the routing >> protocol it is required that the bi-directional tunnel be treated as >> a tunnel interface. The tunnel interface is included as the list of >> interfaces on which routing protocol is active. > > "included AS the list of" or "included IN the list of"? ..included in the list of... fixed. > >> The Mobile Router >> should be configured not to run the routing protocol on its egress >> interface when it is away from the home link. > > Simply "should not run"? what it means is that the MR should not send any routing protocol messages on its egress interface when it attached to a visited link. modified the text as follows. The Mobile Router should be configured not to send any routing protocol messages on its egress interface when it is away from the home link and connected to a visited link. > >> Finally, the Home Agent may be configured with static routes to the >> Mobile Network Prefix via the Mobile Router's Home Address. In that >> case, the routes are set independently of the binding flows and the >> returning Home of a Mobile Router. The benefit is that such movement >> does not induce any additional signalling in the form of routing >> updates in the Home Network. The drawback of that model is that the >> routes are present even if the related Mobile Routers that are not >> reachable (at Home or bound) at a given point of time. > > remove "that" in the last sentence? > > In fact the statement in the last sentence is not necessarily true. If the HA > always associates a stable tunnel interface with each MR and simply changes the > interface state up/down depending on MR's reachability, then modern router > SW already will remove and install those static routes correctly. I am not sure we want to keep a stable tunnel interface to each MR all the time. as along as the MR has a binding cache entry at the HA, we can have a stable tunnel inteface for each MR. the tunnel is created when the MR sends a binding update to the HA. > > >> 4.3. Mobile Network Prefix Option > > A question that should probably be clarified in section 6: > > - can a single prefix previously communicated in a BU be deregistered from the > HA without flapping the whole set of prefixes? it is hard for the HA to figure what has changed in the BU without including a lot of information in the BU. and we dont expect a lot of prefixes to be assigned to a MR. > this may become handy when > a prefix is removed from one mobile network and placed to another. I am not sure this is going to be common. > > >> 6.3. Advertising Mobile Network Reachability >> >> In order to be able to receive packets meant for the mobile network, >> the Home Agent advertises reachability to the mobile network. If the >> Home Link is configured with a prefix that is an aggregation and if >> the Mobile Network Prefix is aggregated under that prefix, then the >> routing updates advertising reachability to the mobile network are >> sent only on the Home Link. > > The last sentences presupposes a distance-vector routing protocol (RIPng). > Link-state RPs (OSPFv3) do not support per-interface discrimination of > routing info. is the following better? If the Home Link is configured with a prefix that is an aggregation and if the Mobile Network Prefix is aggregated under that prefix, then the routing changes related to the Mobile Network are restricted to the Home Link. this does not assume a distance vector or link state routing protocol. > > BTW, "sent only on the Home link"--is this a requirement or an observation? observation. :) > >> If the Home Agent is the only default >> router on the Home Link, routes to the Mobile Network Prefix get >> aggregated naturally under the Home Agent and the Home Agent does not >> have to do anything special. >> >> If the Home Agent receives routing updates through a dynamic routing >> protocol from the Mobile Router, those routes are propagated by >> the routing protocol running on the Home Agent on the relevant >> interfaces. > > I suggest the above is changed to "Home Agent can be configured to propagate..." okay. > >> 6.4. Establishment of Bi-directional Tunnel > > Should the document say that the Tunnel interfaces should be unnumbered? > There is really no need to assign prefixes to them. right. there is no need to assign prefixes. > >> 8. Support for Dynamic Routing Protocols >> >> In the solution described so far, forwarding to the mobile network >> at the Home Agent is set up when the Home Agent receives a Binding >> Update from the Mobile Router. An alternative to this is for the >> Home Agent and the Mobile Router to run an intra-domain routing >> protocol like RIPng [11] and OSPF [12] through the bi-directional >> tunnel. The Mobile Router can continue running the same routing >> protocol that it was running when it was attached to the home link. >> >> This feature is very useful when the mobile network is large with >> multiple subnets containing different IPv6 prefixes. Routing changes >> in the mobile network are propagated to the Home Agent quickly. >> Routing changes in the home link are also propogated to the Mobile >> Router very quickly. > > The thing is, however, that both MR and HA do not need to know the > topologies behind each other, only the reachability info... it is however restricted to the home link. the intention really is to enable the MR to receive the same kind of routing information that it used to receive when attached to the home link. with your suggestion of treating the IP-in-IP tunnel as on-demand circuits when the MR is away from home, we should be able to reduce the amount of traffic. (?) > >> When the Mobile Router is attached to the home link, it runs a >> routing protocol by sending routing updates through its egress >> interface. When the mobile router moves and attaches to a visited >> network, it MUST stop sending routing updates on the interface with >> which it attaches to the visited link. > > One potential problem I could see with this is that a MR can send an > update on its link before it realizes that it is on a visited network. > The real answer here is enabling authentication in routing protocols > and proper key management--accidental updates will simply be dropped. oh.. we wanted to say if the MR realises that it is on a visited link, it stops sending routing protocol messages on the egress interface. the MR realizes that it is on a visited link when it sees different prefix information in a router advertisement from a router on the visited link. it is enough if it stops sending routing protocol messages on the egress interface after that. > >> This is very important so >> that IPv6 prefixes specific to the mobile network do not leak into >> the visited network. The Mobile Router then starts sending routing >> protocol messages through the bi-directional tunnel towards the Home >> Agent. Most routing protocols use link local addresses as source >> addresses for the routing information messages. The Mobile Router is >> allowed to use link local addresses for the inner IPv6 header of an >> encapsulated packet. But these messages after decapsulation MUST NOT >> be forwarded to another link by either the Mobile Router or the Home >> Agent. > > By "these messages" do you mean the routing protocol messages after they > are decapsulated or the inner IPv6 packets carrying them. the inner IPv6 packets. > If the former, > then they won't be forwarded anyways, since they have been received locally > already. If the latter, then do you mean all inner IPv6 packets or only > those with link-local addresses? only those with link-local addresses. > >> When the Home Agent receives the encapsulated routing protocol >> message, it processes the inner packets and updates its routing table >> accordingly. > > Should be the other way around: > > When the Home Agent receives the inner packet, it processes encapsulated > routing protocol messages and updates its routing table accordingly. > >> The next hop information in these routing entries is >> filled with the Mobile Router's link local address with the outgoing >> interface set to the bi-directional tunnel. > > Let's make it "As part of normal routing protocol operation, the next hop > information..." so that it doesn't sound like a change in RP's operation. okay. > >> Similary, the Home Agent also sends routing updates through the >> bi-directional tunnel to the Mobile Router. The Mobile Router >> processes these routing protocol messages and updates its routing >> table. For all routes advertised by the Home Agent, the Mobile >> Router sets the outgoing interface to the bi-directional tunnel to >> the Home Agent. >> >> When the Mobile Router and the Home Agent exchange routes through >> a dynamic routing protocol, the Mobile Router should be careful in >> including the same Mobile Network Prefixes in the Binding Update to >> the Home Agent and in the routing protocol updates. > > This isn't really a useful suggestion. It is not reasonable to expect > the MR to keep track of the routes that have been announced through > the tunnel and somehow make an intelligent decision about the contents > of the BU message, because e.g. in OSPF, the flooding mechanism that > performs the transport function has no clue about the semantics of > the LSA internals it carries. this is restricted to what the MR sends. if the MR knows that it has includes certain information in the routing protocol messages, it shouldnt include the same in binding updates. > >> The Home Agent >> depending on its configuration might not add routes based on the >> prefix information in the Binding Updates at all, and might use only >> the routing protocol updates. Moreover, including the same prefix >> information in both the Binding Update and the routing protocol >> update is redundant. > > There are also potential cases where the routing protocol has removed > a prefix and the HA still has it from the BU.... > > Should the doc simply suggest that the MR should not be configured > to announce prefixes in the BU if those prefixes will be delivered > to the HA by the routing protocol? people on the mailing list have argued in the past that we shouldnt have such restrictions in the spec. the only requirement should be the information should be consistent. I am fine with making this change, though. > >> Since the routing protocol messages from the Home Agent to the Mobile >> Router could potentially contain information about the internal >> routing structure of the home network, these messages require >> authentications and confidentiality protection. Confidentialy > Confidentiality > >> protection using IPsec ESP [4] MUST be supported and SHOULD be >> used. > > ESP at what level is meant above? If you mean at the Tunnel level, > please say so. draft-ietf-ospf-ospfv3-auth-04.txt requires the use of ESP in transport mode. with NEMO, tunnel mode should also be okay. when used in transport mode, the packet will be as follows IPv6 hdr (src=HA, dst=MR_CoA) IPv6 hdr (src=HA, dst=MR_HoA) ESP hdr Payload OSPFv3 payload when used in tunnel mode, the packet will be IPv6 hdr (src=HA, dst=MR_CoA) ESP hdr Ipv6 hdr (src=HA, dst=MR_HoA) Payload OSPFv3 payload in both cases, the address on the inner packet can be link local address. so we dont have a strong preference to tunnel or transport mode. > > "SHOULD be used" seems like a strange requirement that will be impossible to > check, since it is not for the implementation, but for the used. > >> For protecting routing protocol messages using ESP, the >> bi-directional tunnel between the Mobile Router and the Home >> Agent should be treated as the outgoing interface, with link local >> addresses as source and destination addresses for the messages. > > What is meant by "messages" here? Encapsulating packets or encapsulated packets? encapsulated packets > Why do you need to insist on link-local addresses here? OSPF, for example has a > case (virtual links) where packets are sent over more than one hop. you are right. global unicast addresses can also be used. I will remove the part about link local addresses. > >> IPsec ESP with a non-null encryption algorithm should be used >> in transport mode for protecting the routing protocol messages. >> Examples of SPD entries for protecting OSPFv3 messages are described >> in [13]. > > I suggest that the above is reworded to say something like "appropriate > authentication and confidentiality protection mechanisms defined in [12,13] > should be configured when necessary", instead of trying to define (again) here > what they are. okay. > >> 9. Security Considerations > ... >> When the Mobile Router is running a dynamic routing protocol as >> described in Section 8, it injects routing update messages into the >> Home Link. The Home Agent MUST verify that the Mobile Router is >> allowed to send routing updates before processing the messages and >> propagating the routing information. > > What is meant by "MUST verify" here? If protocol-specific authentication > mechanisms, then they of course may be configured, but mandating that seems > strange. If you mean source-address checking, then it is not a strong security > mechanism. the routing protocol messages ofcourse should be authenticated. but I am not sure if thats enough to verify if the mobile router is allowed to send routing protocol messages in the first place. the home agent could be serving a bunch of mobile routers, some of which might be authorized to run a routing protocol and the others not. so we have the additional check. Vijay From exim@www1.ietf.org Fri Apr 23 19:36:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22358 for ; Fri, 23 Apr 2004 19:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHABv-0007vy-P8 for nemo-archive@odin.ietf.org; Fri, 23 Apr 2004 19:34:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NNYhHw030495 for nemo-archive@odin.ietf.org; Fri, 23 Apr 2004 19:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHA30-0005FV-7d for nemo-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 19:25: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 TAA21865 for ; Fri, 23 Apr 2004 19:25: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 1BHA2y-0007DL-HS for nemo-web-archive@ietf.org; Fri, 23 Apr 2004 19:25:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHA28-0006y6-00 for nemo-web-archive@ietf.org; Fri, 23 Apr 2004 19:24:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHA1b-0006iO-00 for nemo-web-archive@ietf.org; Fri, 23 Apr 2004 19:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9tr-0002yx-7m; Fri, 23 Apr 2004 19:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9nO-0000vi-Eu for nemo@optimus.ietf.org; Fri, 23 Apr 2004 19:09:22 -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 TAA21088 for ; Fri, 23 Apr 2004 19:09:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9nL-000300-4L for nemo@ietf.org; Fri, 23 Apr 2004 19:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9mM-0002jd-00 for nemo@ietf.org; Fri, 23 Apr 2004 19:08:20 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1BH9lI-0002Fw-00 for nemo@ietf.org; Fri, 23 Apr 2004 19:07:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3NN6cI06572; Fri, 23 Apr 2004 16:06:38 -0700 X-mProtect: <200404232306> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7Nm8xa; Fri, 23 Apr 2004 16:06:36 PDT Message-ID: <4089A1A0.5080401@iprg.nokia.com> Date: Fri, 23 Apr 2004 16:07:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zinin@psg.com CC: margaret@thingmagic.com, nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] your comments on NEMO and routing protocools Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Hi Alex, thanks for some very good comments. > Alex Zinin: > > There are several things that concern me when I think about scaling > an implementation of a HA to support a large number of MRs. > > 1. Tunnel interface flapping > > If the tunnel interface goes up and down every time a MR moves to a new > visited network, with high level of mobility and sufficient number of MRs, > the amount of interface state changes well result in CPU overloading on > the HA, as well as high level of instability in the rest of the network > if e.g. a link-state protocol is deployed. > > I understand that the document cannot mandate the way tunnel interfaces > are implemented, but it would be really useful if it provided some > recommendations along the following lines: > > - a tunnel interface is consistently assigned to each remote MR > > - the state of the interface at the IP layer is not changed if > the MR moves from one visited network to another "smoothly", > i.e., does not lose connectivity for too long. This would > probably mean providing some grace period before taking the > interface down when the MR is temporarily unreachable, and > changing the tunnel's tail-end (MR's CoA) address without > flapping the interface. this is a good suggestion. we actually did want something like this, but didnt specify it in the spec. I will add some text on this. however, what do you mean by "consistently assigned"? If the MR is shut off for an extended period of time, the Home Agent should delete any state associated with an MR. or did you mean A tunnel interface is consistently assigned to each remote MR as long as the MR has a valid binding cache entry at the HA. > > 2. Hello packet processing > > The lessons we've learned with FR and ATM clouds suggest that with a large > number of interfaces, Hello packet processing may become a burden. It could > be useful if the document recommended to treat the Tunnel interfaces as > On-Demand circuits in OSPF per RFC 1793. okay. > > 3. Amount of information exchanged between HA and MR > > One disadvantage of using a link-state routing protocol like OSPF in the > NEMO case is that there is a possibility that MRs and mobile networks > will be told the topology of the whole area, or even the domain (if no > areas are used in the network), while the only thing MRs really need > is a default through the HA. > > The same argument works the other way per my comment 1 above. > > At the very minimum, there should be a recommendation that Tunnel > interfaces to MRs are NOT put in the same area as e.g. the backbone links. > > Separating Tunnel interfaces to MRs from the backbone and aggregating > prefix info from mobile networks should prevent potential instabilities > related to MR relocations from destabilizing the rest of the network. again, we will add this to the spec. > > Making the area to which a tunnel interface belongs Stub should save > the RM from too much info sent by the HA. > > To save different RMs from knowing too much about each other, the only > method currently available is to place them each in a separate stub > area, but this may stretch certain implementations. I guess we wont be able decide between making the home link a single area or making each tunnel interface a sub-area without some experimentation. we could point out the pros and cons of each approach and let the admin for the home link decide. we have another draft which talks about how an home link for NEMO can be designed. http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-00.txt this will be an informational document. not a proposed standard. > > More specific comments inline below: > >> 3. Overview of the NEMO Protocol > > ... >> It is also possible for the Mobile Router and the Home Agent to run >> a routing protocol through the bi-directional tunnel. In that case, >> the Mobile Router need not include prefix information in the Binding >> Update. Instead the Home Agent uses the routing protocol updates to >> setup forwarding for the mobile network. When running the routing >> protocol it is required that the bi-directional tunnel be treated as >> a tunnel interface. The tunnel interface is included as the list of >> interfaces on which routing protocol is active. > > "included AS the list of" or "included IN the list of"? ..included in the list of... fixed. > >> The Mobile Router >> should be configured not to run the routing protocol on its egress >> interface when it is away from the home link. > > Simply "should not run"? what it means is that the MR should not send any routing protocol messages on its egress interface when it attached to a visited link. modified the text as follows. The Mobile Router should be configured not to send any routing protocol messages on its egress interface when it is away from the home link and connected to a visited link. > >> Finally, the Home Agent may be configured with static routes to the >> Mobile Network Prefix via the Mobile Router's Home Address. In that >> case, the routes are set independently of the binding flows and the >> returning Home of a Mobile Router. The benefit is that such movement >> does not induce any additional signalling in the form of routing >> updates in the Home Network. The drawback of that model is that the >> routes are present even if the related Mobile Routers that are not >> reachable (at Home or bound) at a given point of time. > > remove "that" in the last sentence? > > In fact the statement in the last sentence is not necessarily true. If the HA > always associates a stable tunnel interface with each MR and simply changes the > interface state up/down depending on MR's reachability, then modern router > SW already will remove and install those static routes correctly. I am not sure we want to keep a stable tunnel interface to each MR all the time. as along as the MR has a binding cache entry at the HA, we can have a stable tunnel inteface for each MR. the tunnel is created when the MR sends a binding update to the HA. > > >> 4.3. Mobile Network Prefix Option > > A question that should probably be clarified in section 6: > > - can a single prefix previously communicated in a BU be deregistered from the > HA without flapping the whole set of prefixes? it is hard for the HA to figure what has changed in the BU without including a lot of information in the BU. and we dont expect a lot of prefixes to be assigned to a MR. > this may become handy when > a prefix is removed from one mobile network and placed to another. I am not sure this is going to be common. > > >> 6.3. Advertising Mobile Network Reachability >> >> In order to be able to receive packets meant for the mobile network, >> the Home Agent advertises reachability to the mobile network. If the >> Home Link is configured with a prefix that is an aggregation and if >> the Mobile Network Prefix is aggregated under that prefix, then the >> routing updates advertising reachability to the mobile network are >> sent only on the Home Link. > > The last sentences presupposes a distance-vector routing protocol (RIPng). > Link-state RPs (OSPFv3) do not support per-interface discrimination of > routing info. is the following better? If the Home Link is configured with a prefix that is an aggregation and if the Mobile Network Prefix is aggregated under that prefix, then the routing changes related to the Mobile Network are restricted to the Home Link. this does not assume a distance vector or link state routing protocol. > > BTW, "sent only on the Home link"--is this a requirement or an observation? observation. :) > >> If the Home Agent is the only default >> router on the Home Link, routes to the Mobile Network Prefix get >> aggregated naturally under the Home Agent and the Home Agent does not >> have to do anything special. >> >> If the Home Agent receives routing updates through a dynamic routing >> protocol from the Mobile Router, those routes are propagated by >> the routing protocol running on the Home Agent on the relevant >> interfaces. > > I suggest the above is changed to "Home Agent can be configured to propagate..." okay. > >> 6.4. Establishment of Bi-directional Tunnel > > Should the document say that the Tunnel interfaces should be unnumbered? > There is really no need to assign prefixes to them. right. there is no need to assign prefixes. > >> 8. Support for Dynamic Routing Protocols >> >> In the solution described so far, forwarding to the mobile network >> at the Home Agent is set up when the Home Agent receives a Binding >> Update from the Mobile Router. An alternative to this is for the >> Home Agent and the Mobile Router to run an intra-domain routing >> protocol like RIPng [11] and OSPF [12] through the bi-directional >> tunnel. The Mobile Router can continue running the same routing >> protocol that it was running when it was attached to the home link. >> >> This feature is very useful when the mobile network is large with >> multiple subnets containing different IPv6 prefixes. Routing changes >> in the mobile network are propagated to the Home Agent quickly. >> Routing changes in the home link are also propogated to the Mobile >> Router very quickly. > > The thing is, however, that both MR and HA do not need to know the > topologies behind each other, only the reachability info... it is however restricted to the home link. the intention really is to enable the MR to receive the same kind of routing information that it used to receive when attached to the home link. with your suggestion of treating the IP-in-IP tunnel as on-demand circuits when the MR is away from home, we should be able to reduce the amount of traffic. (?) > >> When the Mobile Router is attached to the home link, it runs a >> routing protocol by sending routing updates through its egress >> interface. When the mobile router moves and attaches to a visited >> network, it MUST stop sending routing updates on the interface with >> which it attaches to the visited link. > > One potential problem I could see with this is that a MR can send an > update on its link before it realizes that it is on a visited network. > The real answer here is enabling authentication in routing protocols > and proper key management--accidental updates will simply be dropped. oh.. we wanted to say if the MR realises that it is on a visited link, it stops sending routing protocol messages on the egress interface. the MR realizes that it is on a visited link when it sees different prefix information in a router advertisement from a router on the visited link. it is enough if it stops sending routing protocol messages on the egress interface after that. > >> This is very important so >> that IPv6 prefixes specific to the mobile network do not leak into >> the visited network. The Mobile Router then starts sending routing >> protocol messages through the bi-directional tunnel towards the Home >> Agent. Most routing protocols use link local addresses as source >> addresses for the routing information messages. The Mobile Router is >> allowed to use link local addresses for the inner IPv6 header of an >> encapsulated packet. But these messages after decapsulation MUST NOT >> be forwarded to another link by either the Mobile Router or the Home >> Agent. > > By "these messages" do you mean the routing protocol messages after they > are decapsulated or the inner IPv6 packets carrying them. the inner IPv6 packets. > If the former, > then they won't be forwarded anyways, since they have been received locally > already. If the latter, then do you mean all inner IPv6 packets or only > those with link-local addresses? only those with link-local addresses. > >> When the Home Agent receives the encapsulated routing protocol >> message, it processes the inner packets and updates its routing table >> accordingly. > > Should be the other way around: > > When the Home Agent receives the inner packet, it processes encapsulated > routing protocol messages and updates its routing table accordingly. > >> The next hop information in these routing entries is >> filled with the Mobile Router's link local address with the outgoing >> interface set to the bi-directional tunnel. > > Let's make it "As part of normal routing protocol operation, the next hop > information..." so that it doesn't sound like a change in RP's operation. okay. > >> Similary, the Home Agent also sends routing updates through the >> bi-directional tunnel to the Mobile Router. The Mobile Router >> processes these routing protocol messages and updates its routing >> table. For all routes advertised by the Home Agent, the Mobile >> Router sets the outgoing interface to the bi-directional tunnel to >> the Home Agent. >> >> When the Mobile Router and the Home Agent exchange routes through >> a dynamic routing protocol, the Mobile Router should be careful in >> including the same Mobile Network Prefixes in the Binding Update to >> the Home Agent and in the routing protocol updates. > > This isn't really a useful suggestion. It is not reasonable to expect > the MR to keep track of the routes that have been announced through > the tunnel and somehow make an intelligent decision about the contents > of the BU message, because e.g. in OSPF, the flooding mechanism that > performs the transport function has no clue about the semantics of > the LSA internals it carries. this is restricted to what the MR sends. if the MR knows that it has includes certain information in the routing protocol messages, it shouldnt include the same in binding updates. > >> The Home Agent >> depending on its configuration might not add routes based on the >> prefix information in the Binding Updates at all, and might use only >> the routing protocol updates. Moreover, including the same prefix >> information in both the Binding Update and the routing protocol >> update is redundant. > > There are also potential cases where the routing protocol has removed > a prefix and the HA still has it from the BU.... > > Should the doc simply suggest that the MR should not be configured > to announce prefixes in the BU if those prefixes will be delivered > to the HA by the routing protocol? people on the mailing list have argued in the past that we shouldnt have such restrictions in the spec. the only requirement should be the information should be consistent. I am fine with making this change, though. > >> Since the routing protocol messages from the Home Agent to the Mobile >> Router could potentially contain information about the internal >> routing structure of the home network, these messages require >> authentications and confidentiality protection. Confidentialy > Confidentiality > >> protection using IPsec ESP [4] MUST be supported and SHOULD be >> used. > > ESP at what level is meant above? If you mean at the Tunnel level, > please say so. draft-ietf-ospf-ospfv3-auth-04.txt requires the use of ESP in transport mode. with NEMO, tunnel mode should also be okay. when used in transport mode, the packet will be as follows IPv6 hdr (src=HA, dst=MR_CoA) IPv6 hdr (src=HA, dst=MR_HoA) ESP hdr Payload OSPFv3 payload when used in tunnel mode, the packet will be IPv6 hdr (src=HA, dst=MR_CoA) ESP hdr Ipv6 hdr (src=HA, dst=MR_HoA) Payload OSPFv3 payload in both cases, the address on the inner packet can be link local address. so we dont have a strong preference to tunnel or transport mode. > > "SHOULD be used" seems like a strange requirement that will be impossible to > check, since it is not for the implementation, but for the used. > >> For protecting routing protocol messages using ESP, the >> bi-directional tunnel between the Mobile Router and the Home >> Agent should be treated as the outgoing interface, with link local >> addresses as source and destination addresses for the messages. > > What is meant by "messages" here? Encapsulating packets or encapsulated packets? encapsulated packets > Why do you need to insist on link-local addresses here? OSPF, for example has a > case (virtual links) where packets are sent over more than one hop. you are right. global unicast addresses can also be used. I will remove the part about link local addresses. > >> IPsec ESP with a non-null encryption algorithm should be used >> in transport mode for protecting the routing protocol messages. >> Examples of SPD entries for protecting OSPFv3 messages are described >> in [13]. > > I suggest that the above is reworded to say something like "appropriate > authentication and confidentiality protection mechanisms defined in [12,13] > should be configured when necessary", instead of trying to define (again) here > what they are. okay. > >> 9. Security Considerations > ... >> When the Mobile Router is running a dynamic routing protocol as >> described in Section 8, it injects routing update messages into the >> Home Link. The Home Agent MUST verify that the Mobile Router is >> allowed to send routing updates before processing the messages and >> propagating the routing information. > > What is meant by "MUST verify" here? If protocol-specific authentication > mechanisms, then they of course may be configured, but mandating that seems > strange. If you mean source-address checking, then it is not a strong security > mechanism. the routing protocol messages ofcourse should be authenticated. but I am not sure if thats enough to verify if the mobile router is allowed to send routing protocol messages in the first place. the home agent could be serving a bunch of mobile routers, some of which might be authorized to run a routing protocol and the others not. so we have the additional check. Vijay From nemo-admin@ietf.org Sat Apr 24 04:21:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29783 for ; Sat, 24 Apr 2004 04:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHIMM-0000B2-Vi; Sat, 24 Apr 2004 04:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHIFS-0006kf-CB for nemo@optimus.ietf.org; Sat, 24 Apr 2004 04:10:54 -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 EAA29510 for ; Sat, 24 Apr 2004 04:10:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHIFP-0000I2-L4 for nemo@ietf.org; Sat, 24 Apr 2004 04:10:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHIEU-00002P-00 for nemo@ietf.org; Sat, 24 Apr 2004 04:09:55 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BHIDu-0007ZM-00 for nemo@ietf.org; Sat, 24 Apr 2004 04:09:18 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3O86jAq011545; Sat, 24 Apr 2004 08:06:51 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042416084605080 ; Sat, 24 Apr 2004 16:08:46 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 16:08:46 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C429D3.5E1EC770" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 24 Apr 2004 16:08:46 +0800 Message-ID: Thread-Topic: HAHA protocol Q Thread-Index: AcQp010Rzze6HCVQQ9KS0Z7qfQDNxw== From: "Tan, Tat Kin" To: Cc: X-OriginalArrivalTime: 24 Apr 2004 08:08:46.0996 (UTC) FILETIME=[5E49F540:01C429D3] 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_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] HAHA protocol Q Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C429D3.5E1EC770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have just started reading the nemo-haha-01.txt draft and maybe someone had already ask this question before?=20 That, in pg9 (sect 3 overview) where it says "Each HA intercepts packets and take responsibility for delivering intercepted packets to either the MN or the primary HA". I was a bit confused that will 2 HAs by chance be delivering a duplicated (same) message to MN? Could this scenario be possibly happen and how it can be avoided? I m thinking more on the scenario where the MN shares the similar distance of 2 HAs and the signaling strength may lead into this scenario? Cheers. Tatkin ------_=_NextPart_001_01C429D3.5E1EC770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HAHA protocol Q

Hello,

I have just started reading the = nemo-haha-01.txt draft and maybe someone had already ask this question = before?

That, in pg9 (sect 3 overview) where it = says "Each HA intercepts packets and take responsibility for = delivering intercepted packets to either the MN or the primary HA". = I was a bit confused that will 2 HAs by chance be delivering a = duplicated (same) message to MN? Could this scenario be possibly happen = and how it can be avoided? I m thinking more on the scenario where the = MN shares the similar distance of 2 HAs and the signaling strength may = lead into this scenario?

Cheers.

Tatkin

------_=_NextPart_001_01C429D3.5E1EC770-- From exim@www1.ietf.org Sat Apr 24 04:25:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29911 for ; Sat, 24 Apr 2004 04:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHIS2-0001kL-3E for nemo-archive@odin.ietf.org; Sat, 24 Apr 2004 04:23:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O8Nskn006708 for nemo-archive@odin.ietf.org; Sat, 24 Apr 2004 04:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHIQx-0001I7-1t for nemo-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 04:22: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 EAA29831 for ; Sat, 24 Apr 2004 04:22:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHIQu-0003Jc-AJ for nemo-web-archive@ietf.org; Sat, 24 Apr 2004 04:22:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHIPz-00034G-00 for nemo-web-archive@ietf.org; Sat, 24 Apr 2004 04:21:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHIPB-0002kq-00 for nemo-web-archive@ietf.org; Sat, 24 Apr 2004 04:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHIMM-0000B2-Vi; Sat, 24 Apr 2004 04:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHIFS-0006kf-CB for nemo@optimus.ietf.org; Sat, 24 Apr 2004 04:10:54 -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 EAA29510 for ; Sat, 24 Apr 2004 04:10:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHIFP-0000I2-L4 for nemo@ietf.org; Sat, 24 Apr 2004 04:10:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHIEU-00002P-00 for nemo@ietf.org; Sat, 24 Apr 2004 04:09:55 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BHIDu-0007ZM-00 for nemo@ietf.org; Sat, 24 Apr 2004 04:09:18 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3O86jAq011545; Sat, 24 Apr 2004 08:06:51 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042416084605080 ; Sat, 24 Apr 2004 16:08:46 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 16:08:46 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C429D3.5E1EC770" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 24 Apr 2004 16:08:46 +0800 Message-ID: Thread-Topic: HAHA protocol Q Thread-Index: AcQp010Rzze6HCVQQ9KS0Z7qfQDNxw== From: "Tan, Tat Kin" To: Cc: X-OriginalArrivalTime: 24 Apr 2004 08:08:46.0996 (UTC) FILETIME=[5E49F540:01C429D3] Subject: [nemo] HAHA protocol Q Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C429D3.5E1EC770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have just started reading the nemo-haha-01.txt draft and maybe someone had already ask this question before?=20 That, in pg9 (sect 3 overview) where it says "Each HA intercepts packets and take responsibility for delivering intercepted packets to either the MN or the primary HA". I was a bit confused that will 2 HAs by chance be delivering a duplicated (same) message to MN? Could this scenario be possibly happen and how it can be avoided? I m thinking more on the scenario where the MN shares the similar distance of 2 HAs and the signaling strength may lead into this scenario? Cheers. Tatkin ------_=_NextPart_001_01C429D3.5E1EC770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HAHA protocol Q

Hello,

I have just started reading the = nemo-haha-01.txt draft and maybe someone had already ask this question = before?

That, in pg9 (sect 3 overview) where it = says "Each HA intercepts packets and take responsibility for = delivering intercepted packets to either the MN or the primary HA". = I was a bit confused that will 2 HAs by chance be delivering a = duplicated (same) message to MN? Could this scenario be possibly happen = and how it can be avoided? I m thinking more on the scenario where the = MN shares the similar distance of 2 HAs and the signaling strength may = lead into this scenario?

Cheers.

Tatkin

------_=_NextPart_001_01C429D3.5E1EC770-- From nemo-admin@ietf.org Sat Apr 24 05:18:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03822 for ; Sat, 24 Apr 2004 05:18:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJEX-000698-PX; Sat, 24 Apr 2004 05:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJ6e-0003KV-Cj for nemo@optimus.ietf.org; Sat, 24 Apr 2004 05:05:52 -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 FAA02712 for ; Sat, 24 Apr 2004 05:05:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHJ6b-0006OV-4F for nemo@ietf.org; Sat, 24 Apr 2004 05:05:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJ5p-00068w-00 for nemo@ietf.org; Sat, 24 Apr 2004 05:05:01 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BHJ4x-0005YX-00 for nemo@ietf.org; Sat, 24 Apr 2004 05:04:08 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3O91eAo020164; Sat, 24 Apr 2004 09:01:40 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042417033605632 ; Sat, 24 Apr 2004 17:03:36 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 17:03:36 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C429DB.070C25EB" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 24 Apr 2004 17:03:36 +0800 Message-ID: Thread-Topic: HAHA protocol Q again Thread-Index: AcQp010Rzze6HCVQQ9KS0Z7qfQDNxwABqgbA From: "Tan, Tat Kin" To: Cc: X-OriginalArrivalTime: 24 Apr 2004 09:03:36.0933 (UTC) FILETIME=[073E8150:01C429DB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] HAHA protocol Q again Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C429DB.070C25EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello again, I have a question at HAHA protocl draft and at section 9 for scenario described in Figure 3, of which the sequence 6 and sequence 7. My question is, is that possible that when CN2 (sequence 7) sends to HA3, and HA3 instead of (as described in Figure 3) tunnelling to MN, somehow tunnel to other HAs like HA2 (or HA1?) and then only in turns tunnel back to MN? My question was base on a thought of how "intelligent" the HA could be and of course to factor in the different sub links for those HAs resided in. Please help me to understand that this will not generate extra overheads to the general network traffics. Million thanks. Rgds, Tatkin ------_=_NextPart_001_01C429DB.070C25EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HAHA protocol Q again

Hello again,

I have a question at = HAHA protocl draft and at section 9 for scenario described in Figure 3, = of which the sequence 6 and sequence 7.

My question is, is = that possible that when CN2 (sequence 7) sends to HA3, and HA3 instead = of (as described in Figure 3) tunnelling to MN, somehow tunnel to other = HAs like HA2 (or HA1?) and then only in turns tunnel back to MN? My = question was base on a thought of how "intelligent" the HA = could be and of course to factor in the different sub links for those = HAs resided in. Please help me to understand that this will not generate = extra overheads to the general network traffics.

Million = thanks.

Rgds,
Tatkin

------_=_NextPart_001_01C429DB.070C25EB-- From exim@www1.ietf.org Sat Apr 24 05:27:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04331 for ; Sat, 24 Apr 2004 05:27:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJNK-00013H-Uz for nemo-archive@odin.ietf.org; Sat, 24 Apr 2004 05:23:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O9N6oN004035 for nemo-archive@odin.ietf.org; Sat, 24 Apr 2004 05:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJKG-0008PE-JU for nemo-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 05:19:56 -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 FAA03936 for ; Sat, 24 Apr 2004 05:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHJKD-0002p7-Ed for nemo-web-archive@ietf.org; Sat, 24 Apr 2004 05:19:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJJD-0002XF-00 for nemo-web-archive@ietf.org; Sat, 24 Apr 2004 05:18:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHJIE-0002FG-00 for nemo-web-archive@ietf.org; Sat, 24 Apr 2004 05:17:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJEX-000698-PX; Sat, 24 Apr 2004 05:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJ6e-0003KV-Cj for nemo@optimus.ietf.org; Sat, 24 Apr 2004 05:05:52 -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 FAA02712 for ; Sat, 24 Apr 2004 05:05:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHJ6b-0006OV-4F for nemo@ietf.org; Sat, 24 Apr 2004 05:05:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJ5p-00068w-00 for nemo@ietf.org; Sat, 24 Apr 2004 05:05:01 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BHJ4x-0005YX-00 for nemo@ietf.org; Sat, 24 Apr 2004 05:04:08 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3O91eAo020164; Sat, 24 Apr 2004 09:01:40 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042417033605632 ; Sat, 24 Apr 2004 17:03:36 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 17:03:36 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C429DB.070C25EB" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 24 Apr 2004 17:03:36 +0800 Message-ID: Thread-Topic: HAHA protocol Q again Thread-Index: AcQp010Rzze6HCVQQ9KS0Z7qfQDNxwABqgbA From: "Tan, Tat Kin" To: Cc: X-OriginalArrivalTime: 24 Apr 2004 09:03:36.0933 (UTC) FILETIME=[073E8150:01C429DB] Subject: [nemo] HAHA protocol Q again Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C429DB.070C25EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello again, I have a question at HAHA protocl draft and at section 9 for scenario described in Figure 3, of which the sequence 6 and sequence 7. My question is, is that possible that when CN2 (sequence 7) sends to HA3, and HA3 instead of (as described in Figure 3) tunnelling to MN, somehow tunnel to other HAs like HA2 (or HA1?) and then only in turns tunnel back to MN? My question was base on a thought of how "intelligent" the HA could be and of course to factor in the different sub links for those HAs resided in. Please help me to understand that this will not generate extra overheads to the general network traffics. Million thanks. Rgds, Tatkin ------_=_NextPart_001_01C429DB.070C25EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HAHA protocol Q again

Hello again,

I have a question at = HAHA protocl draft and at section 9 for scenario described in Figure 3, = of which the sequence 6 and sequence 7.

My question is, is = that possible that when CN2 (sequence 7) sends to HA3, and HA3 instead = of (as described in Figure 3) tunnelling to MN, somehow tunnel to other = HAs like HA2 (or HA1?) and then only in turns tunnel back to MN? My = question was base on a thought of how "intelligent" the HA = could be and of course to factor in the different sub links for those = HAs resided in. Please help me to understand that this will not generate = extra overheads to the general network traffics.

Million = thanks.

Rgds,
Tatkin

------_=_NextPart_001_01C429DB.070C25EB-- From nemo-admin@ietf.org Mon Apr 26 00:29:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06907 for ; Mon, 26 Apr 2004 00:29:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHxfE-00034M-0D; Mon, 26 Apr 2004 00:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHx7j-0002ie-2H for nemo@optimus.ietf.org; Sun, 25 Apr 2004 23:49: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 XAA05342 for ; Sun, 25 Apr 2004 23:49:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHx7g-0001Ve-SE for nemo@ietf.org; Sun, 25 Apr 2004 23:49:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHx6n-0001KT-00 for nemo@ietf.org; Sun, 25 Apr 2004 23:48:42 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BHx6B-000165-00 for nemo@ietf.org; Sun, 25 Apr 2004 23:48:04 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3Q3jMEe007638; Mon, 26 Apr 2004 03:45:22 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042611471631011 ; Mon, 26 Apr 2004 11:47:16 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 11:47:16 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU Date: Mon, 26 Apr 2004 11:47:16 +0800 Message-ID: Thread-Topic: [nemo] Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKABquVjQAVZGUkA= From: "Tan, Tat Kin" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 26 Apr 2004 03:47:16.0845 (UTC) FILETIME=[2B0E69D0:01C42B41] 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: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Pascal and Alex, Thanks for both your explainations. I still have further questions if you do not mind. With what Alex had explained, that if there is 10 or 20 different nested networks then each of the MR of these 10 or 20 networks will send its own BU for updates and not all consolidated into 1 single BU by the upper most (in this text, the term "aggregated" is used).=20 First, how will the 10 or 20 networks know there needs an update and hence trigger the sending of BUs? If the 10 or 20 networks were told to update by some mechanism such as the upper most MR sending out information telling all its lower link to update, then would this be too much overhead interms of BU traffics? If this is true, this also mean the moving of the entire NEMO is not transparent to the networks within? The objective of the NEMO isnt it true that is to make the move of the network transparent to other nested network within? Second, based on the assumption of first question, will more security concerns be arise if the upper most MR is moving constantly (from Network A to B and then to C ....and so on), and the inner networks that updating the BU is being confused? (inner network may still be updating Network A while upper MR is already in C maybe....) ? Maybe this question is not valid since the NEMO objective is to make the network movement not a concern to inner networks...? I agree with Pascal's suggestion that to make a clean trees and then later worry abt the idea of proxying BU. Somehow, thoughts just came and it might just be too confusing :) Thanks. rgds, tatkin -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Monday, April 19, 2004 4:21 PM To: Tan, Tat Kin; nemo@ietf.org Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU >> My question is, how can this be achieved? I mean if there is 10 or 20 different nested networks are within that moving networks and could a single BU be able to cater all information?=20 Hi Tatkin,=20 I will not paraphrase Alex since I had a chance to read his mail and agree with his answer concerning the coverage of the nemo basic support. But I must admit that like you, I toyed with the idea of proxying BU prefix information, in the context of nested RO. Note that there's a number of issues to fix first like loop avoidance. I suggest we start looking at making clean trees of mobile routers and then we know that we can start proxying/bridging is a loopless fashion. Pascal From exim@www1.ietf.org Mon Apr 26 00:35:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07355 for ; Mon, 26 Apr 2004 00:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHxo4-0005i4-1H for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 00:33:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q4XO4j021946 for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 00:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHxmI-00052g-Tp for nemo-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 00:31:34 -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 AAA07032 for ; Mon, 26 Apr 2004 00:31: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 1BHxmG-0001q1-H9 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 00:31:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHxlG-0001bW-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 00:30:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHxkH-0001Js-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 00:29:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHxfE-00034M-0D; Mon, 26 Apr 2004 00:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHx7j-0002ie-2H for nemo@optimus.ietf.org; Sun, 25 Apr 2004 23:49: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 XAA05342 for ; Sun, 25 Apr 2004 23:49:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHx7g-0001Ve-SE for nemo@ietf.org; Sun, 25 Apr 2004 23:49:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHx6n-0001KT-00 for nemo@ietf.org; Sun, 25 Apr 2004 23:48:42 -0400 Received: from petasus.png.intel.com ([192.198.147.99]) by ietf-mx with esmtp (Exim 4.12) id 1BHx6B-000165-00 for nemo@ietf.org; Sun, 25 Apr 2004 23:48:04 -0400 Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.157.117]) by petasus.png.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3Q3jMEe007638; Mon, 26 Apr 2004 03:45:22 GMT Received: from pgsmsx331.gar.corp.intel.com ([172.30.190.37]) by pgsmsxvs01.png.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042611471631011 ; Mon, 26 Apr 2004 11:47:16 +0800 Received: from pgsmsx402.gar.corp.intel.com ([172.30.190.22]) by pgsmsx331.gar.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 11:47:16 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU Date: Mon, 26 Apr 2004 11:47:16 +0800 Message-ID: Thread-Topic: [nemo] Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKABquVjQAVZGUkA= From: "Tan, Tat Kin" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 26 Apr 2004 03:47:16.0845 (UTC) FILETIME=[2B0E69D0:01C42B41] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Pascal and Alex, Thanks for both your explainations. I still have further questions if you do not mind. With what Alex had explained, that if there is 10 or 20 different nested networks then each of the MR of these 10 or 20 networks will send its own BU for updates and not all consolidated into 1 single BU by the upper most (in this text, the term "aggregated" is used).=20 First, how will the 10 or 20 networks know there needs an update and hence trigger the sending of BUs? If the 10 or 20 networks were told to update by some mechanism such as the upper most MR sending out information telling all its lower link to update, then would this be too much overhead interms of BU traffics? If this is true, this also mean the moving of the entire NEMO is not transparent to the networks within? The objective of the NEMO isnt it true that is to make the move of the network transparent to other nested network within? Second, based on the assumption of first question, will more security concerns be arise if the upper most MR is moving constantly (from Network A to B and then to C ....and so on), and the inner networks that updating the BU is being confused? (inner network may still be updating Network A while upper MR is already in C maybe....) ? Maybe this question is not valid since the NEMO objective is to make the network movement not a concern to inner networks...? I agree with Pascal's suggestion that to make a clean trees and then later worry abt the idea of proxying BU. Somehow, thoughts just came and it might just be too confusing :) Thanks. rgds, tatkin -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Monday, April 19, 2004 4:21 PM To: Tan, Tat Kin; nemo@ietf.org Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU >> My question is, how can this be achieved? I mean if there is 10 or 20 different nested networks are within that moving networks and could a single BU be able to cater all information?=20 Hi Tatkin,=20 I will not paraphrase Alex since I had a chance to read his mail and agree with his answer concerning the coverage of the nemo basic support. But I must admit that like you, I toyed with the idea of proxying BU prefix information, in the context of nested RO. Note that there's a number of issues to fix first like loop avoidance. I suggest we start looking at making clean trees of mobile routers and then we know that we can start proxying/bridging is a loopless fashion. Pascal From nemo-admin@ietf.org Mon Apr 26 05:52:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07815 for ; Mon, 26 Apr 2004 05:52:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2iX-0000OK-BK; Mon, 26 Apr 2004 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2ac-0006qn-Cf for nemo@optimus.ietf.org; Mon, 26 Apr 2004 05:39:50 -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 FAA07130 for ; Mon, 26 Apr 2004 05:39:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI2aY-0004JQ-Rv for nemo@ietf.org; Mon, 26 Apr 2004 05:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI2Ze-00047t-00 for nemo@ietf.org; Mon, 26 Apr 2004 05:38:51 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BI2ZC-0003wH-00 for nemo@ietf.org; Mon, 26 Apr 2004 05:38:22 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3Q9YNJO023912; Mon, 26 Apr 2004 02:34:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3Q9c5NT025089; Mon, 26 Apr 2004 04:38:07 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 64B44865980; Mon, 26 Apr 2004 11:38:14 +0200 (CEST) Message-ID: <408CD87F.1090005@motorola.com> Date: Mon, 26 Apr 2004 11:38:07 +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: "Tan, Tat Kin" Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] Questions on multiple mobile network prefixes in a BU References: In-Reply-To: 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="------------ms020006060204040506050807" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms020006060204040506050807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tan, Tat Kin wrote: > With what Alex had explained, that if there is 10 or 20 different > nested networks then each of the MR of these 10 or 20 networks will > send its own BU for updates and not all consolidated into 1 single BU > by the upper most (in this text, the term "aggregated" is used). > > First, how will the 10 or 20 networks know there needs an update and > hence trigger the sending of BUs? Each MR "detects" it is in a foreign network when it receives an RA with a prefix different than its preconfigured home prefix (just like MH detects its is in a foreign network, by Mobile IPv6 mechanisms). After detecting it moved, it keeps sending BU's when a binding lifetime expires. > If the 10 or 20 networks were told to update by some mechanism such > as the upper most MR sending out information telling all its lower > link to update, then would this be too much overhead interms of BU > traffics? The fact that the "uppermost" or "top-level" or "root" MR sends a BU following a change in its Care-of Address does not mean that each MR below it must send a BU; each such MR sends BU only when that respective MR changes its CoA (no relation to the moments when upper MR's change their CoA). Alex --------------ms020006060204040506050807 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MjYwOTM4MDdaMCMGCSqGSIb3DQEJBDEWBBSB7z89mxiaE2ieFZvwXleST9HvhDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCZcu8Cbfyf1P+9zXm6Pbqhv2RnU0kp1xD4U/z3 z1G+j1rSE2fIlzh3cJqdd6H2nkFfrENKDyQWQim7NvjCbfugcrNiZtbbWH3BPhThQvBsfxR0 9wJmmWJVz92wnPHJG6txuW0U0K0Q9wPQpgpAXlXR8sQgyLcBMk35cHjV1z6xFgAAAAAAAA== --------------ms020006060204040506050807-- From exim@www1.ietf.org Mon Apr 26 05:56:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07883 for ; Mon, 26 Apr 2004 05:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2pc-000212-Vt for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 05:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q9tKOd007742 for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 05:55:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2oA-0001m4-GE for nemo-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 05:53:50 -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 FAA07844 for ; Mon, 26 Apr 2004 05:53:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI2o6-0007Au-Te for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 05:53:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI2nE-0006zi-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 05:52:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI2mm-0006oG-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 05:52:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2iX-0000OK-BK; Mon, 26 Apr 2004 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2ac-0006qn-Cf for nemo@optimus.ietf.org; Mon, 26 Apr 2004 05:39:50 -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 FAA07130 for ; Mon, 26 Apr 2004 05:39:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI2aY-0004JQ-Rv for nemo@ietf.org; Mon, 26 Apr 2004 05:39:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI2Ze-00047t-00 for nemo@ietf.org; Mon, 26 Apr 2004 05:38:51 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BI2ZC-0003wH-00 for nemo@ietf.org; Mon, 26 Apr 2004 05:38:22 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3Q9YNJO023912; Mon, 26 Apr 2004 02:34:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3Q9c5NT025089; Mon, 26 Apr 2004 04:38:07 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 64B44865980; Mon, 26 Apr 2004 11:38:14 +0200 (CEST) Message-ID: <408CD87F.1090005@motorola.com> Date: Mon, 26 Apr 2004 11:38:07 +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: "Tan, Tat Kin" Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] Questions on multiple mobile network prefixes in a BU References: In-Reply-To: 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="------------ms020006060204040506050807" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms020006060204040506050807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tan, Tat Kin wrote: > With what Alex had explained, that if there is 10 or 20 different > nested networks then each of the MR of these 10 or 20 networks will > send its own BU for updates and not all consolidated into 1 single BU > by the upper most (in this text, the term "aggregated" is used). > > First, how will the 10 or 20 networks know there needs an update and > hence trigger the sending of BUs? Each MR "detects" it is in a foreign network when it receives an RA with a prefix different than its preconfigured home prefix (just like MH detects its is in a foreign network, by Mobile IPv6 mechanisms). After detecting it moved, it keeps sending BU's when a binding lifetime expires. > If the 10 or 20 networks were told to update by some mechanism such > as the upper most MR sending out information telling all its lower > link to update, then would this be too much overhead interms of BU > traffics? The fact that the "uppermost" or "top-level" or "root" MR sends a BU following a change in its Care-of Address does not mean that each MR below it must send a BU; each such MR sends BU only when that respective MR changes its CoA (no relation to the moments when upper MR's change their CoA). Alex --------------ms020006060204040506050807 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MjYwOTM4MDdaMCMGCSqGSIb3DQEJBDEWBBSB7z89mxiaE2ieFZvwXleST9HvhDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCZcu8Cbfyf1P+9zXm6Pbqhv2RnU0kp1xD4U/z3 z1G+j1rSE2fIlzh3cJqdd6H2nkFfrENKDyQWQim7NvjCbfugcrNiZtbbWH3BPhThQvBsfxR0 9wJmmWJVz92wnPHJG6txuW0U0K0Q9wPQpgpAXlXR8sQgyLcBMk35cHjV1z6xFgAAAAAAAA== --------------ms020006060204040506050807-- From nemo-admin@ietf.org Mon Apr 26 08:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15184 for ; Mon, 26 Apr 2004 08:33: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 1BI5DN-000258-7E; Mon, 26 Apr 2004 08:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI56Y-0000pM-DH for nemo@optimus.ietf.org; Mon, 26 Apr 2004 08:20:58 -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 IAA14635 for ; Mon, 26 Apr 2004 08:20:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI56X-0007KQ-An for nemo@ietf.org; Mon, 26 Apr 2004 08:20:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI55Y-00078t-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:19:57 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI54u-0006xH-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:19:16 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QCJErR003865; Mon, 26 Apr 2004 21:19:14 +0900 Date: Mon, 26 Apr 2004 21:19:39 +0900 Message-ID: From: Ryuji Wakikawa To: tat.kin.tan@intel.com Cc: ryuji@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] HAHA protocol Q In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello It is my english error. sorry. I will correct this at the next version. The correct text is: One of Home Agent intercepts packets and take responsibility for delivering intercepted packets to either the Mobile Node or the primary Home Agent. regards, ryuji At Sat, 24 Apr 2004 16:08:46 +0800, Tan, Tat Kin wrote: > Hello, > > I have just started reading the nemo-haha-01.txt draft and maybe someone > had already ask this question before? > > That, in pg9 (sect 3 overview) where it says "Each HA intercepts packets > and take responsibility for delivering intercepted packets to either the > MN or the primary HA". I was a bit confused that will 2 HAs by chance be > delivering a duplicated (same) message to MN? Could this scenario be > possibly happen and how it can be avoided? I m thinking more on the > scenario where the MN shares the similar distance of 2 HAs and the > signaling strength may lead into this scenario? > > Cheers. From nemo-admin@ietf.org Mon Apr 26 08:49:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15881 for ; Mon, 26 Apr 2004 08:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5O3-0004Uk-JE; Mon, 26 Apr 2004 08:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5Mz-0004Bd-6Y for nemo@optimus.ietf.org; Mon, 26 Apr 2004 08:37:57 -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 IAA15460 for ; Mon, 26 Apr 2004 08:37:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5Mx-0002pC-Rw for nemo@ietf.org; Mon, 26 Apr 2004 08:37:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5M4-0002nP-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:37:01 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI5La-0002lC-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:36:30 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QCaSrR004045; Mon, 26 Apr 2004 21:36:28 +0900 Date: Mon, 26 Apr 2004 21:36:52 +0900 Message-ID: From: Ryuji Wakikawa To: tat.kin.tan@intel.com Cc: ryuji@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] HAHA protocol Q again In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Tatkin again At Sat, 24 Apr 2004 17:03:36 +0800, Tan, Tat Kin wrote: > Hello again, > > I have a question at HAHA protocl draft and at section 9 for scenario > described in Figure 3, of which the sequence 6 and sequence 7. > > My question is, is that possible that when CN2 (sequence 7) sends to > HA3, and HA3 instead of (as described in Figure 3) tunnelling to MN, > somehow tunnel to other HAs like HA2 (or HA1?) and then only in turns > tunnel back to MN? My question was base on a thought of how Yes, it is possible. The scenario is described in Figure 2 of Section9 (sequence 11). > "intelligent" the HA could be and of course to factor in the different > sub links for those HAs resided in. Please help me to understand that > this will not generate extra overheads to the general network traffics. It is up to how multiple HAs(home hinks) are configured on the Internet. If the home links are connected directly by L2 like VPN, we can ignore extra overheads. Home link is typically managed by single Service Provider, ISP can burden with those extra overheads. regards, ryuji From exim@www1.ietf.org Mon Apr 26 09:08:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18260 for ; Mon, 26 Apr 2004 09:08:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5mW-0000bI-1R for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 09:04:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QD4JV9002303 for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 09:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5bC-0006hj-Uu for nemo-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 08:52:38 -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 IAA16695 for ; Mon, 26 Apr 2004 08:52:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5bB-0003ti-Cy for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:52:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5Z6-0003Xo-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:50:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BI5Wf-000385-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:47:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BI5Id-0000dM-Cj for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:33:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5DN-000258-7E; Mon, 26 Apr 2004 08:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI56Y-0000pM-DH for nemo@optimus.ietf.org; Mon, 26 Apr 2004 08:20:58 -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 IAA14635 for ; Mon, 26 Apr 2004 08:20:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI56X-0007KQ-An for nemo@ietf.org; Mon, 26 Apr 2004 08:20:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI55Y-00078t-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:19:57 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI54u-0006xH-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:19:16 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QCJErR003865; Mon, 26 Apr 2004 21:19:14 +0900 Date: Mon, 26 Apr 2004 21:19:39 +0900 Message-ID: From: Ryuji Wakikawa To: tat.kin.tan@intel.com Cc: ryuji@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] HAHA protocol Q In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Hello It is my english error. sorry. I will correct this at the next version. The correct text is: One of Home Agent intercepts packets and take responsibility for delivering intercepted packets to either the Mobile Node or the primary Home Agent. regards, ryuji At Sat, 24 Apr 2004 16:08:46 +0800, Tan, Tat Kin wrote: > Hello, > > I have just started reading the nemo-haha-01.txt draft and maybe someone > had already ask this question before? > > That, in pg9 (sect 3 overview) where it says "Each HA intercepts packets > and take responsibility for delivering intercepted packets to either the > MN or the primary HA". I was a bit confused that will 2 HAs by chance be > delivering a duplicated (same) message to MN? Could this scenario be > possibly happen and how it can be avoided? I m thinking more on the > scenario where the MN shares the similar distance of 2 HAs and the > signaling strength may lead into this scenario? > > Cheers. From exim@www1.ietf.org Mon Apr 26 09:09:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18278 for ; Mon, 26 Apr 2004 09:09:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5mX-0000bv-3N for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 09:04:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QD4Ln9002341 for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 09:04:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5bQ-0006wP-EV for nemo-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 08:52:52 -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 IAA16752 for ; Mon, 26 Apr 2004 08:52:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5bO-0003ws-Re for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:52:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5a0-0003gi-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:51:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5Xf-0003Iy-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 08:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5O3-0004Uk-JE; Mon, 26 Apr 2004 08:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5Mz-0004Bd-6Y for nemo@optimus.ietf.org; Mon, 26 Apr 2004 08:37:57 -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 IAA15460 for ; Mon, 26 Apr 2004 08:37:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5Mx-0002pC-Rw for nemo@ietf.org; Mon, 26 Apr 2004 08:37:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5M4-0002nP-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:37:01 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1BI5La-0002lC-00 for nemo@ietf.org; Mon, 26 Apr 2004 08:36:30 -0400 Received: from wifi-139-148.sfc.wide.ad.jp.sfc.wide.ad.jp (n128-157.sfc.wide.ad.jp [203.178.128.157]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i3QCaSrR004045; Mon, 26 Apr 2004 21:36:28 +0900 Date: Mon, 26 Apr 2004 21:36:52 +0900 Message-ID: From: Ryuji Wakikawa To: tat.kin.tan@intel.com Cc: ryuji@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] HAHA protocol Q again In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Hello Tatkin again At Sat, 24 Apr 2004 17:03:36 +0800, Tan, Tat Kin wrote: > Hello again, > > I have a question at HAHA protocl draft and at section 9 for scenario > described in Figure 3, of which the sequence 6 and sequence 7. > > My question is, is that possible that when CN2 (sequence 7) sends to > HA3, and HA3 instead of (as described in Figure 3) tunnelling to MN, > somehow tunnel to other HAs like HA2 (or HA1?) and then only in turns > tunnel back to MN? My question was base on a thought of how Yes, it is possible. The scenario is described in Figure 2 of Section9 (sequence 11). > "intelligent" the HA could be and of course to factor in the different > sub links for those HAs resided in. Please help me to understand that > this will not generate extra overheads to the general network traffics. It is up to how multiple HAs(home hinks) are configured on the Internet. If the home links are connected directly by L2 like VPN, we can ignore extra overheads. Home link is typically managed by single Service Provider, ISP can burden with those extra overheads. regards, ryuji From nemo-admin@ietf.org Mon Apr 26 21:55:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09890 for ; Mon, 26 Apr 2004 21:55:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHlQ-00065O-RY; Mon, 26 Apr 2004 21:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHi2-0005jL-Ij for nemo@optimus.ietf.org; Mon, 26 Apr 2004 21:48: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 VAA09645 for ; Mon, 26 Apr 2004 21: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 1BIHhz-0005LF-Oj for nemo@ietf.org; Mon, 26 Apr 2004 21:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHh3-0005Ff-00 for nemo@ietf.org; Mon, 26 Apr 2004 21:47:30 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BIHgn-0005A4-00 for nemo@ietf.org; Mon, 26 Apr 2004 21:47:14 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i3R1fR1u009950 for ; Tue, 27 Apr 2004 10:41:27 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i3R1fRcu009949 for nemo@ietf.org; Tue, 27 Apr 2004 10:41:27 +0900 Date: Tue, 27 Apr 2004 10:41:27 +0900 From: Seongho Cho To: nemo@ietf.org Message-ID: <20040427104127.B9862@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi forks, To inform you that we have submitted a new I-D on neighbor MR authentication & registration mechanism for multihomed mobile networks. We propose a dynamic MR registration solution without extra signaling message, and hope that this I-D will initiate some discussions on this topic. Thanks. Bests, Seongho ----- Forwarded message from Internet-Drafts@ietf.org ----- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Date: Mon, 26 Apr 2004 15:26:20 -0400 Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor MR Authentication and Registration Mechanism in Multihomed Mobile Networks Author(s) : S. Cho, et al. Filename : draft-cho-nemo-mr-registration-00.txt Pages : 12 Date : 2004-4-26 In multihomed mobile networks, multiple Mobile Routers can be deployed to provide fault recovery or load sharing. Also, each Mobile Router (MR) can have a bi-directional tunnel with its own Home Agent (HA). In this multihomed mobile network scenario, the neighbor root MR can replace or share the operation of another MR. Therefore, MRs should cooperate with each other to provide session continuity or load sharing. We present an authentication and registration mechanism without introducing extra signaling messages. Using the Return Routability procedure of Mobile IPv6 and the Binding Update message with the neighbor MR registration option, the MR can authenticate and register the neighbor MR to its own HA. And the HA can use this registered neighbor MR information to provide fault recovery or load sharing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cho-nemo-mr-registration-00.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-cho-nemo-mr-registration-00.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-cho-nemo-mr-registration-00.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. ----- End forwarded message ----- From exim@www1.ietf.org Mon Apr 26 22:01:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10190 for ; Mon, 26 Apr 2004 22:01:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHsc-0006o0-FQ for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 21:59:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R1xQTG026160 for nemo-archive@odin.ietf.org; Mon, 26 Apr 2004 21:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHpq-0006Yt-5z for nemo-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 21:56:34 -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 VAA09974 for ; Mon, 26 Apr 2004 21:56: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 1BIHpn-00068C-4n for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 21:56:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHot-000629-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 21:55:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIHoG-0005wH-00 for nemo-web-archive@ietf.org; Mon, 26 Apr 2004 21:54:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHlQ-00065O-RY; Mon, 26 Apr 2004 21:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHi2-0005jL-Ij for nemo@optimus.ietf.org; Mon, 26 Apr 2004 21:48: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 VAA09645 for ; Mon, 26 Apr 2004 21: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 1BIHhz-0005LF-Oj for nemo@ietf.org; Mon, 26 Apr 2004 21:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHh3-0005Ff-00 for nemo@ietf.org; Mon, 26 Apr 2004 21:47:30 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1BIHgn-0005A4-00 for nemo@ietf.org; Mon, 26 Apr 2004 21:47:14 -0400 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i3R1fR1u009950 for ; Tue, 27 Apr 2004 10:41:27 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i3R1fRcu009949 for nemo@ietf.org; Tue, 27 Apr 2004 10:41:27 +0900 Date: Tue, 27 Apr 2004 10:41:27 +0900 From: Seongho Cho To: nemo@ietf.org Message-ID: <20040427104127.B9862@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Hi forks, To inform you that we have submitted a new I-D on neighbor MR authentication & registration mechanism for multihomed mobile networks. We propose a dynamic MR registration solution without extra signaling message, and hope that this I-D will initiate some discussions on this topic. Thanks. Bests, Seongho ----- Forwarded message from Internet-Drafts@ietf.org ----- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cho-nemo-mr-registration-00.txt Date: Mon, 26 Apr 2004 15:26:20 -0400 Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor MR Authentication and Registration Mechanism in Multihomed Mobile Networks Author(s) : S. Cho, et al. Filename : draft-cho-nemo-mr-registration-00.txt Pages : 12 Date : 2004-4-26 In multihomed mobile networks, multiple Mobile Routers can be deployed to provide fault recovery or load sharing. Also, each Mobile Router (MR) can have a bi-directional tunnel with its own Home Agent (HA). In this multihomed mobile network scenario, the neighbor root MR can replace or share the operation of another MR. Therefore, MRs should cooperate with each other to provide session continuity or load sharing. We present an authentication and registration mechanism without introducing extra signaling messages. Using the Return Routability procedure of Mobile IPv6 and the Binding Update message with the neighbor MR registration option, the MR can authenticate and register the neighbor MR to its own HA. And the HA can use this registered neighbor MR information to provide fault recovery or load sharing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cho-nemo-mr-registration-00.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-cho-nemo-mr-registration-00.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-cho-nemo-mr-registration-00.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. ----- End forwarded message ----- From nemo-admin@ietf.org Tue Apr 27 10:56:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05330 for ; Tue, 27 Apr 2004 10:56:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITtP-0004EK-FW; Tue, 27 Apr 2004 10:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITmY-0003AJ-9o for nemo@optimus.ietf.org; Tue, 27 Apr 2004 10:41:58 -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 KAA04597 for ; Tue, 27 Apr 2004 10:41:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITmR-00033y-VR for nemo@ietf.org; Tue, 27 Apr 2004 10:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITlY-00031n-00 for nemo@ietf.org; Tue, 27 Apr 2004 10:40:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BITkb-0002xY-00 for nemo@ietf.org; Tue, 27 Apr 2004 10:39:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2004 16:45:49 +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 i3REdNbl027875; Tue, 27 Apr 2004 16:39: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, 27 Apr 2004 15:39:40 +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-HAHA Date: Tue, 27 Apr 2004 15:39:39 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQpRZppMmAsHKsXSya1Ho/ndQpzHADHxfHw From: "Pascal Thubert \(pthubert\)" To: "Mazen TLAIS" , X-OriginalArrivalTime: 27 Apr 2004 14:39:40.0902 (UTC) FILETIME=[79254060:01C42C65] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Mazen: > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Mazen TLAIS > Sent: vendredi 23 avril 2004 16:58 > To: nemo@ietf.org > Subject: Re: [nemo] Re: Question-HAHA >=20 > I have ome more question on the haha protocole, thanx > for your explanation. >=20 > when you say : >=20 > there could be multiple home agents attached to > different links serving the same home agent prefix. >=20 > Do you mean that these multiple home agents that serve > the same home prefix moreover belong to the same > operator? >=20 This is my expectation. But I'm not sure there's something in the protocol about it. We must make sure that the protocol can be deployed, but we do not have to fix limits on how that happens. Pascal From exim@www1.ietf.org Tue Apr 27 11:11:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06241 for ; Tue, 27 Apr 2004 11:11:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUAh-0007tF-8S for nemo-archive@odin.ietf.org; Tue, 27 Apr 2004 11:06:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RF6tSx030324 for nemo-archive@odin.ietf.org; Tue, 27 Apr 2004 11:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIU22-0005pJ-AI for nemo-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 10:57:58 -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 KAA05375 for ; Tue, 27 Apr 2004 10:57:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIU1v-0003k8-TR for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 10:57:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIU10-0003iK-00 for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 10:56:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIU0T-0003gm-00 for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 10:56:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITtP-0004EK-FW; Tue, 27 Apr 2004 10:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITmY-0003AJ-9o for nemo@optimus.ietf.org; Tue, 27 Apr 2004 10:41:58 -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 KAA04597 for ; Tue, 27 Apr 2004 10:41:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITmR-00033y-VR for nemo@ietf.org; Tue, 27 Apr 2004 10:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITlY-00031n-00 for nemo@ietf.org; Tue, 27 Apr 2004 10:40:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BITkb-0002xY-00 for nemo@ietf.org; Tue, 27 Apr 2004 10:39:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2004 16:45:49 +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 i3REdNbl027875; Tue, 27 Apr 2004 16:39: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, 27 Apr 2004 15:39:40 +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-HAHA Date: Tue, 27 Apr 2004 15:39:39 +0100 Message-ID: Thread-Topic: [nemo] Re: Question-HAHA Thread-Index: AcQpRZppMmAsHKsXSya1Ho/ndQpzHADHxfHw From: "Pascal Thubert \(pthubert\)" To: "Mazen TLAIS" , X-OriginalArrivalTime: 27 Apr 2004 14:39:40.0902 (UTC) FILETIME=[79254060:01C42C65] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable Hi Mazen: > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Mazen TLAIS > Sent: vendredi 23 avril 2004 16:58 > To: nemo@ietf.org > Subject: Re: [nemo] Re: Question-HAHA >=20 > I have ome more question on the haha protocole, thanx > for your explanation. >=20 > when you say : >=20 > there could be multiple home agents attached to > different links serving the same home agent prefix. >=20 > Do you mean that these multiple home agents that serve > the same home prefix moreover belong to the same > operator? >=20 This is my expectation. But I'm not sure there's something in the protocol about it. We must make sure that the protocol can be deployed, but we do not have to fix limits on how that happens. Pascal From nemo-admin@ietf.org Tue Apr 27 22:09:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17262 for ; Tue, 27 Apr 2004 22:09:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeQa-0001x2-NF; Tue, 27 Apr 2004 22:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeO4-0001Zb-Cr for nemo@optimus.ietf.org; Tue, 27 Apr 2004 22:01:24 -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 WAA17001 for ; Tue, 27 Apr 2004 22:01:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIeNz-0006gK-BP for nemo@ietf.org; Tue, 27 Apr 2004 22:01:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeN2-0006Y7-00 for nemo@ietf.org; Tue, 27 Apr 2004 22:00:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BIeMG-0006Jg-00 for nemo@ietf.org; Tue, 27 Apr 2004 21:59:32 -0400 Received: from psl.com.sg ([10.81.113.126]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i3S1odhG004117 for ; Wed, 28 Apr 2004 09:50:39 +0800 (SGT) Message-ID: <408F1019.9020908@psl.com.sg> Date: Wed, 28 Apr 2004 09:59:53 +0800 From: Benjamin Koh Tien-Ming User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Subject: [nemo] Question on MR - CN Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi! I have a question on MR operation that I'm hoping someone can help clarify. In the case when the MR is away from home, a LFN sends a packet to a CN. Can the MR encapsulate the original packet and forward it directly to the CN using it's current CoA (Care-of-Address)? Are there any reasons against or problems with using such a method? Please direct me to a relevant thread if this question had been previously raised. Thanks! Regards, Benjamin From exim@www1.ietf.org Tue Apr 27 22:32:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18268 for ; Tue, 27 Apr 2004 22:32:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeki-0004FV-O0 for nemo-archive@odin.ietf.org; Tue, 27 Apr 2004 22:24:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S2Omrx016327 for nemo-archive@odin.ietf.org; Tue, 27 Apr 2004 22:24:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIegD-0003nc-VA for nemo-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 22:20:09 -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 WAA17677 for ; Tue, 27 Apr 2004 22:20:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIeg8-0001Ga-R4 for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 22:20:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIef3-00011J-00 for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 22:18:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIedb-0000nL-02 for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 22:17:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIeVv-00066r-CP for nemo-web-archive@ietf.org; Tue, 27 Apr 2004 22:09:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeQa-0001x2-NF; Tue, 27 Apr 2004 22:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeO4-0001Zb-Cr for nemo@optimus.ietf.org; Tue, 27 Apr 2004 22:01:24 -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 WAA17001 for ; Tue, 27 Apr 2004 22:01:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIeNz-0006gK-BP for nemo@ietf.org; Tue, 27 Apr 2004 22:01:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeN2-0006Y7-00 for nemo@ietf.org; Tue, 27 Apr 2004 22:00:21 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1BIeMG-0006Jg-00 for nemo@ietf.org; Tue, 27 Apr 2004 21:59:32 -0400 Received: from psl.com.sg ([10.81.113.126]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i3S1odhG004117 for ; Wed, 28 Apr 2004 09:50:39 +0800 (SGT) Message-ID: <408F1019.9020908@psl.com.sg> Date: Wed, 28 Apr 2004 09:59:53 +0800 From: Benjamin Koh Tien-Ming User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Question on MR - CN Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit Hi! I have a question on MR operation that I'm hoping someone can help clarify. In the case when the MR is away from home, a LFN sends a packet to a CN. Can the MR encapsulate the original packet and forward it directly to the CN using it's current CoA (Care-of-Address)? Are there any reasons against or problems with using such a method? Please direct me to a relevant thread if this question had been previously raised. Thanks! Regards, Benjamin From nemo-admin@ietf.org Wed Apr 28 11:36:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22177 for ; Wed, 28 Apr 2004 11:36:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqln-0007ZC-Ff; Wed, 28 Apr 2004 11:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqBN-0001fI-E0 for nemo@optimus.ietf.org; Wed, 28 Apr 2004 10:37:05 -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 KAA18610 for ; Wed, 28 Apr 2004 10:36:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqAx-0002Kl-CA for nemo@ietf.org; Wed, 28 Apr 2004 10:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIpiE-0006QJ-00 for nemo@ietf.org; Wed, 28 Apr 2004 10:06:58 -0400 Received: from web25009.mail.ukl.yahoo.com ([217.12.10.45]) by ietf-mx with smtp (Exim 4.12) id 1BIpht-0006N7-00 for nemo@ietf.org; Wed, 28 Apr 2004 10:06:38 -0400 Message-ID: <20040428140559.45350.qmail@web25009.mail.ukl.yahoo.com> Received: from [137.194.2.20] by web25009.mail.ukl.yahoo.com via HTTP; Wed, 28 Apr 2004 16:05:59 CEST Date: Wed, 28 Apr 2004 16:05:59 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: RE: [nemo] Re: Question-HAHA To: "Pascal Thubert \(pthubert\)" Cc: nemo@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-146473456-1083161159=:45348" 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_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --0-146473456-1083161159=:45348 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA18613 Content-Transfer-Encoding: quoted-printable thanks Pascal =20 This is my expectation too :-). =20 Regards Mazen "Pascal Thubert (pthubert)" wrote: Hi Mazen: > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Mazen TLAIS > Sent: vendredi 23 avril 2004 16:58 > To: nemo@ietf.org > Subject: Re: [nemo] Re: Question-HAHA >=20 > I have ome more question on the haha protocole, thanx > for your explanation. >=20 > when you say : >=20 > there could be multiple home agents attached to > different links serving the same home agent prefix. >=20 > Do you mean that these multiple home agents that serve > the same home prefix moreover belong to the same > operator? >=20 This is my expectation. But I'm not sure there's something in the protocol about it. We must make sure that the protocol can be deployed, but we do not have to fix limits on how that happens. Pascal =09 --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr=E9ez votre Yahoo! Mail Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-146473456-1083161159=:45348 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA18613 Content-Transfer-Encoding: quoted-printable
thanks Pascal
 
This is my expectation too :-).
 
Regards
Mazen


"Pascal Thubert (pthubert)" <pthubert@cisco.com>= wrote:
Hi Mazen:

> -----Original Messa= ge-----
> From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On= Behalf Of
Mazen TLAIS
> Sent: vendredi 23 avril 2004 16:58
= > To: nemo@ietf.org
> Subject: Re: [nemo] Re: Question-HAHA
&= gt;
> I have ome more question on the haha protocole, thanx
>= ; for your explanation.
>
> when you say :
>
> = there could be multiple home agents attached to
> different links s= erving the same home agent prefix.
>
> Do you mean that thes= e multiple home agents that serve
> the same home prefix moreover b= elong to the same
> operator?
>
This is my expectation. B= ut I'm not sure there's something in the
protocol about it. We must ma= ke sure that the protocol can be deployed,
but we do not have to fix l= imits on how that happens.

Pascal

Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Cr=E9ez vot= re Yahoo! Mail

Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-146473456-1083161159=:45348-- From nemo-admin@ietf.org Wed Apr 28 11:49:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22944 for ; Wed, 28 Apr 2004 11:49:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1c-000231-TZ; Wed, 28 Apr 2004 11:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqsF-0008Ut-IA for nemo@optimus.ietf.org; Wed, 28 Apr 2004 11:21: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 LAA21154 for ; Wed, 28 Apr 2004 11:21: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 1BIqsD-0006P8-77 for nemo@ietf.org; Wed, 28 Apr 2004 11:21:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqrJ-0006LQ-00 for nemo@ietf.org; Wed, 28 Apr 2004 11:20:26 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BIqqr-0006HK-00 for nemo@ietf.org; Wed, 28 Apr 2004 11:19:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2004 17:26:07 +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 i3SFJMbl010352; Wed, 28 Apr 2004 17:19:25 +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); Wed, 28 Apr 2004 16:19:39 +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] Questions on multiple mobile network prefixes in a BU Date: Wed, 28 Apr 2004 16:19:38 +0100 Message-ID: Thread-Topic: [nemo] Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKABquVjQAVZGUkAASYw0MA== From: "Pascal Thubert \(pthubert\)" To: "Tan, Tat Kin" , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 28 Apr 2004 15:19:39.0619 (UTC) FILETIME=[394E2B30:01C42D34] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tan, Tat Kin [mailto:tat.kin.tan@intel.com] > Sent: lundi 26 avril 2004 05:47 > To: Pascal Thubert (pthubert); Alexandru Petrescu > Cc: nemo@ietf.org > Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU >=20 > Hello Pascal and Alex, >=20 > Thanks for both your explainations. I still have further questions if > you do not mind. >=20 > With what Alex had explained, that if there is 10 or 20 different nested > networks then each of the MR of these 10 or 20 networks will send its > own BU for updates and not all consolidated into 1 single BU by the > upper most (in this text, the term "aggregated" is used). Note that you can not aggregate in classical terms unless you know that all the longer prefixes are below you, or that but some that are advertised separately. I'd rather use the word consolidated.=20 > First, how will the 10 or 20 networks know there needs an update and > hence trigger the sending of BUs?=20 With nemo basic, if your careof does not change, you do not need to rebind. Meaning that there a change high above you or below you in the tree, you do not need to know and rebind. But this happens at the cost of nested tunnels. If you want to do nested NEMO RO, it's a different story. You need to know, and depending on the solution, you may need a number of BUs. This is explained in the RO taxonomy draft http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx t (see 5.1 Nested Tunnels Optimization), and there's a solution for the problem in http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-04.txt.=20 So there is a need for some new messaging in nested Nemo to know that something above you has changed. There are a number of drafts that suggest extending RA, including RRH, HMRA... You'll soon find a new one called tree discovery :) > If the 10 or 20 networks were told to > update by some mechanism such as the upper most MR sending out > information telling all its lower link to update, then would this be too > much overhead interms of BU traffics? If this is true, this also mean See =20 1. Binding Update storm in=20 6.2 Recursive complexity in route optimization in the RO taxonomy draft. Avoiding the storm is one key design point for RRH... > the moving of the entire NEMO is not transparent to the networks within? > The objective of the NEMO isnt it true that is to make the move of the > network transparent to other nested network within? I guess that RO contradicts that postulate, though it's true for basic. But basic does not know how to avoid loops... Also, MRs may not trust each other and the MNP may be 'home' in various places of the world. So I do not see MRs proxy registering for other nested MRs when the move... In the other hand, there are local mobility management solutions. For Nemo, you may want to look at http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt which can be seen as a NEMO version of HMIP. >=20 > Second, based on the assumption of first question, will more security > concerns be arise if the upper most MR is moving constantly (from > Network A to B and then to C ....and so on), and the inner networks that > updating the BU is being confused? (inner network may still be updating > Network A while upper MR is already in C maybe....) ? Maybe this > question is not valid since the NEMO objective is to make the network > movement not a concern to inner networks...? We will need a pretty efficient mechanism there. I believe that the question is highly relevant, as part of the RO effort. But the solution is not in our charter, and may not be MIP based (its more like and efficient adhoc stuff based on the nested tree... > I agree with Pascal's suggestion that to make a clean trees and then > later worry abt the idea of proxying BU. Somehow, thoughts just came and > it might just be too confusing :) >=20 I really like your thinking. Thanks for all. Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Monday, April 19, 2004 4:21 PM > To: Tan, Tat Kin; nemo@ietf.org > Subject: RE: [nemo] Questions on multiple mobile network prefixes in a > BU >=20 >=20 > >> My question is, how can this be achieved? I mean if there is 10 or 20 > different nested networks are within that moving networks and could a > single BU be able to cater all information? >=20 > Hi Tatkin, >=20 > I will not paraphrase Alex since I had a chance to read his mail and > agree with his answer concerning the coverage of the nemo basic support. >=20 >=20 > But I must admit that like you, I toyed with the idea of proxying BU > prefix information, in the context of nested RO. Note that there's a > number of issues to fix first like loop avoidance. I suggest we start > looking at making clean trees of mobile routers and then we know that we > can start proxying/bridging is a loopless fashion. >=20 > Pascal From exim@www1.ietf.org Wed Apr 28 11:59:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24348 for ; Wed, 28 Apr 2004 11:59:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrLe-0000A0-Sc for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 11:51:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SFpk43000617 for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 11:51:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr89-0003eV-EL for nemo-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:37:49 -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 LAA22308 for ; Wed, 28 Apr 2004 11:37:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIr87-0000Av-3n for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:37:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIr7B-00005S-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:36:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIr6b-0007nU-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqln-0007ZC-Ff; Wed, 28 Apr 2004 11:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqBN-0001fI-E0 for nemo@optimus.ietf.org; Wed, 28 Apr 2004 10:37:05 -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 KAA18610 for ; Wed, 28 Apr 2004 10:36:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqAx-0002Kl-CA for nemo@ietf.org; Wed, 28 Apr 2004 10:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIpiE-0006QJ-00 for nemo@ietf.org; Wed, 28 Apr 2004 10:06:58 -0400 Received: from web25009.mail.ukl.yahoo.com ([217.12.10.45]) by ietf-mx with smtp (Exim 4.12) id 1BIpht-0006N7-00 for nemo@ietf.org; Wed, 28 Apr 2004 10:06:38 -0400 Message-ID: <20040428140559.45350.qmail@web25009.mail.ukl.yahoo.com> Received: from [137.194.2.20] by web25009.mail.ukl.yahoo.com via HTTP; Wed, 28 Apr 2004 16:05:59 CEST Date: Wed, 28 Apr 2004 16:05:59 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: RE: [nemo] Re: Question-HAHA To: "Pascal Thubert \(pthubert\)" Cc: nemo@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-146473456-1083161159=:45348" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-146473456-1083161159=:45348 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA18613 Content-Transfer-Encoding: quoted-printable thanks Pascal =20 This is my expectation too :-). =20 Regards Mazen "Pascal Thubert (pthubert)" wrote: Hi Mazen: > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Mazen TLAIS > Sent: vendredi 23 avril 2004 16:58 > To: nemo@ietf.org > Subject: Re: [nemo] Re: Question-HAHA >=20 > I have ome more question on the haha protocole, thanx > for your explanation. >=20 > when you say : >=20 > there could be multiple home agents attached to > different links serving the same home agent prefix. >=20 > Do you mean that these multiple home agents that serve > the same home prefix moreover belong to the same > operator? >=20 This is my expectation. But I'm not sure there's something in the protocol about it. We must make sure that the protocol can be deployed, but we do not have to fix limits on how that happens. Pascal =09 --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr=E9ez votre Yahoo! Mail Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-146473456-1083161159=:45348 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA18613 Content-Transfer-Encoding: quoted-printable
thanks Pascal
 
This is my expectation too :-).
 
Regards
Mazen


"Pascal Thubert (pthubert)" <pthubert@cisco.com>= wrote:
Hi Mazen:

> -----Original Messa= ge-----
> From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On= Behalf Of
Mazen TLAIS
> Sent: vendredi 23 avril 2004 16:58
= > To: nemo@ietf.org
> Subject: Re: [nemo] Re: Question-HAHA
&= gt;
> I have ome more question on the haha protocole, thanx
>= ; for your explanation.
>
> when you say :
>
> = there could be multiple home agents attached to
> different links s= erving the same home agent prefix.
>
> Do you mean that thes= e multiple home agents that serve
> the same home prefix moreover b= elong to the same
> operator?
>
This is my expectation. B= ut I'm not sure there's something in the
protocol about it. We must ma= ke sure that the protocol can be deployed,
but we do not have to fix l= imits on how that happens.

Pascal

Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Cr=E9ez vot= re Yahoo! Mail

Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger ! --0-146473456-1083161159=:45348-- From exim@www1.ietf.org Wed Apr 28 12:19:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25497 for ; Wed, 28 Apr 2004 12:19:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrb1-0004AG-LT for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SG7dWD016005 for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 12:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrQ4-0001Mi-K8 for nemo-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:56:20 -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 LAA23608 for ; Wed, 28 Apr 2004 11:56:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrQ2-00028E-5j for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:56:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrNO-0001ar-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:53:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrLt-0001JL-01 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:52:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrIg-0002md-Ja for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 11:48:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIr1c-000231-TZ; Wed, 28 Apr 2004 11:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqsF-0008Ut-IA for nemo@optimus.ietf.org; Wed, 28 Apr 2004 11:21: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 LAA21154 for ; Wed, 28 Apr 2004 11:21: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 1BIqsD-0006P8-77 for nemo@ietf.org; Wed, 28 Apr 2004 11:21:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqrJ-0006LQ-00 for nemo@ietf.org; Wed, 28 Apr 2004 11:20:26 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BIqqr-0006HK-00 for nemo@ietf.org; Wed, 28 Apr 2004 11:19:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2004 17:26:07 +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 i3SFJMbl010352; Wed, 28 Apr 2004 17:19:25 +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); Wed, 28 Apr 2004 16:19:39 +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] Questions on multiple mobile network prefixes in a BU Date: Wed, 28 Apr 2004 16:19:38 +0100 Message-ID: Thread-Topic: [nemo] Questions on multiple mobile network prefixes in a BU Thread-Index: AcQkOt6TM6nFKFapT4yrL7tbUEGLKABquVjQAVZGUkAASYw0MA== From: "Pascal Thubert \(pthubert\)" To: "Tan, Tat Kin" , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 28 Apr 2004 15:19:39.0619 (UTC) FILETIME=[394E2B30:01C42D34] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tan, Tat Kin [mailto:tat.kin.tan@intel.com] > Sent: lundi 26 avril 2004 05:47 > To: Pascal Thubert (pthubert); Alexandru Petrescu > Cc: nemo@ietf.org > Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU >=20 > Hello Pascal and Alex, >=20 > Thanks for both your explainations. I still have further questions if > you do not mind. >=20 > With what Alex had explained, that if there is 10 or 20 different nested > networks then each of the MR of these 10 or 20 networks will send its > own BU for updates and not all consolidated into 1 single BU by the > upper most (in this text, the term "aggregated" is used). Note that you can not aggregate in classical terms unless you know that all the longer prefixes are below you, or that but some that are advertised separately. I'd rather use the word consolidated.=20 > First, how will the 10 or 20 networks know there needs an update and > hence trigger the sending of BUs?=20 With nemo basic, if your careof does not change, you do not need to rebind. Meaning that there a change high above you or below you in the tree, you do not need to know and rebind. But this happens at the cost of nested tunnels. If you want to do nested NEMO RO, it's a different story. You need to know, and depending on the solution, you may need a number of BUs. This is explained in the RO taxonomy draft http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx t (see 5.1 Nested Tunnels Optimization), and there's a solution for the problem in http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-04.txt.=20 So there is a need for some new messaging in nested Nemo to know that something above you has changed. There are a number of drafts that suggest extending RA, including RRH, HMRA... You'll soon find a new one called tree discovery :) > If the 10 or 20 networks were told to > update by some mechanism such as the upper most MR sending out > information telling all its lower link to update, then would this be too > much overhead interms of BU traffics? If this is true, this also mean See =20 1. Binding Update storm in=20 6.2 Recursive complexity in route optimization in the RO taxonomy draft. Avoiding the storm is one key design point for RRH... > the moving of the entire NEMO is not transparent to the networks within? > The objective of the NEMO isnt it true that is to make the move of the > network transparent to other nested network within? I guess that RO contradicts that postulate, though it's true for basic. But basic does not know how to avoid loops... Also, MRs may not trust each other and the MNP may be 'home' in various places of the world. So I do not see MRs proxy registering for other nested MRs when the move... In the other hand, there are local mobility management solutions. For Nemo, you may want to look at http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt which can be seen as a NEMO version of HMIP. >=20 > Second, based on the assumption of first question, will more security > concerns be arise if the upper most MR is moving constantly (from > Network A to B and then to C ....and so on), and the inner networks that > updating the BU is being confused? (inner network may still be updating > Network A while upper MR is already in C maybe....) ? Maybe this > question is not valid since the NEMO objective is to make the network > movement not a concern to inner networks...? We will need a pretty efficient mechanism there. I believe that the question is highly relevant, as part of the RO effort. But the solution is not in our charter, and may not be MIP based (its more like and efficient adhoc stuff based on the nested tree... > I agree with Pascal's suggestion that to make a clean trees and then > later worry abt the idea of proxying BU. Somehow, thoughts just came and > it might just be too confusing :) >=20 I really like your thinking. Thanks for all. Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Monday, April 19, 2004 4:21 PM > To: Tan, Tat Kin; nemo@ietf.org > Subject: RE: [nemo] Questions on multiple mobile network prefixes in a > BU >=20 >=20 > >> My question is, how can this be achieved? I mean if there is 10 or 20 > different nested networks are within that moving networks and could a > single BU be able to cater all information? >=20 > Hi Tatkin, >=20 > I will not paraphrase Alex since I had a chance to read his mail and > agree with his answer concerning the coverage of the nemo basic support. >=20 >=20 > But I must admit that like you, I toyed with the idea of proxying BU > prefix information, in the context of nested RO. Note that there's a > number of issues to fix first like loop avoidance. I suggest we start > looking at making clean trees of mobile routers and then we know that we > can start proxying/bridging is a loopless fashion. >=20 > Pascal From nemo-admin@ietf.org Wed Apr 28 18:32:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29928 for ; Wed, 28 Apr 2004 18:32:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxXA-0000YV-G9; Wed, 28 Apr 2004 18:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxK3-0003bG-A9 for nemo@optimus.ietf.org; Wed, 28 Apr 2004 18:14:31 -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 SAA28170 for ; Wed, 28 Apr 2004 18:14:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxJz-00050L-8z for nemo@ietf.org; Wed, 28 Apr 2004 18:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxJ3-0004uY-00 for nemo@ietf.org; Wed, 28 Apr 2004 18:13:29 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BIxIF-0004rn-00 for nemo@ietf.org; Wed, 28 Apr 2004 18:12:39 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3SMBpaw006239; Wed, 28 Apr 2004 15:11:51 -0700 (MST) Received: from motorola.com (mvp-175-132-3-90.corp.mot.com [175.132.3.90]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i3SMBBk6007690; Wed, 28 Apr 2004 17:11:16 -0500 Message-ID: <40902BEE.4010507@motorola.com> Date: Thu, 29 Apr 2004 00:10:54 +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: "Pascal Thubert (pthubert)" CC: "Tan, Tat Kin" , nemo@ietf.org References: In-Reply-To: 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="------------ms080103030607080604030109" 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 Subject: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a BU) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms080103030607080604030109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > I guess that RO contradicts that postulate, though it's true for > basic. But basic does not know how to avoid loops... Loops with basic nemo support have been mentioned here at least twice. The earliest mention I know of was autumn last year (J. Arkko) in an email to nemo and then in the winter by E. K. Paik in draft-cho-nemo-hmra named "RA confliction problem". I've looked closely at both concerns and it is still unclear to me how the looping problem can be defined and potentially solved. In order to reduce the problem scope, I can say that its simplest form appears when a single MR is in a visited network and has one egress and one ingress interface, both wireless. The RA's sent by the ingress interface may be received by the egress interface (on the wireless air space between the two antennas) and then the egress interface configures a CoA (by the nemo and mip6 specs) that is valid in the internal link; thus making a sort of loop. Initially, I was thinking that such a problem has little chance to occur in practice with 802.11b because when one configures such a router s/he is forced to determine two different L2 networks for the two interfaces (via essid/enc) and thus the egress interface could not receive the RA's of the ingress interface. True, restricting the reasoning to 802.11b exclusively is little relevant to an IP solution that shoudl work over several wireless types. But imposing hte multiplicity of wireless links as a requirement is even more advantageous for avoiding the existence of loop problem: if egress is CDMA and ingress is WLAN then there is absolutely 0 chance for egress to receive RA from ingress. IMHO, that's what I think right now about the looping problem, looking for a better definition. So, I take advantage of your mentioning of the looping problem to ask: how do you Pascal think more exactly the looping problem looks like with nemo basic, thanks, Alex --------------ms080103030607080604030109 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MjgyMjEwNTRaMCMGCSqGSIb3DQEJBDEWBBQPksx11XpXpjgmaTOqXqSYg6s4ijBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCbjxMxPCsDpy/I5T+dAjcYjzQ1jeaJUl/h2RFG Bc1j8bKkkimIbrWDPbOLJRLj2VSGCBmq0d9tiZmHKySZ/fKuhIUsOlcpttOzL9W9OTzlcWR0 h8gkvEUNoLe0s53fd2qL/E/WB8nX4VjUpdvZskKvEv9mqvR0FJYcFxGMTQBrLQAAAAAAAA== --------------ms080103030607080604030109-- From exim@www1.ietf.org Wed Apr 28 18:56:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01172 for ; Wed, 28 Apr 2004 18:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxrS-00070k-1i for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 18:49:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMn2DT026949 for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 18:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxcW-0003v8-AM for nemo-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:33: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 SAA29995 for ; Wed, 28 Apr 2004 18:33: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 1BIxcS-0006ee-3A for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 18:33:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxbg-0006bj-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 18:32:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxb3-0006XH-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 18:32:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxXA-0000YV-G9; Wed, 28 Apr 2004 18:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxK3-0003bG-A9 for nemo@optimus.ietf.org; Wed, 28 Apr 2004 18:14:31 -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 SAA28170 for ; Wed, 28 Apr 2004 18:14:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxJz-00050L-8z for nemo@ietf.org; Wed, 28 Apr 2004 18:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxJ3-0004uY-00 for nemo@ietf.org; Wed, 28 Apr 2004 18:13:29 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BIxIF-0004rn-00 for nemo@ietf.org; Wed, 28 Apr 2004 18:12:39 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3SMBpaw006239; Wed, 28 Apr 2004 15:11:51 -0700 (MST) Received: from motorola.com (mvp-175-132-3-90.corp.mot.com [175.132.3.90]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i3SMBBk6007690; Wed, 28 Apr 2004 17:11:16 -0500 Message-ID: <40902BEE.4010507@motorola.com> Date: Thu, 29 Apr 2004 00:10:54 +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: "Pascal Thubert (pthubert)" CC: "Tan, Tat Kin" , nemo@ietf.org References: In-Reply-To: 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="------------ms080103030607080604030109" Subject: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a BU) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms080103030607080604030109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > I guess that RO contradicts that postulate, though it's true for > basic. But basic does not know how to avoid loops... Loops with basic nemo support have been mentioned here at least twice. The earliest mention I know of was autumn last year (J. Arkko) in an email to nemo and then in the winter by E. K. Paik in draft-cho-nemo-hmra named "RA confliction problem". I've looked closely at both concerns and it is still unclear to me how the looping problem can be defined and potentially solved. In order to reduce the problem scope, I can say that its simplest form appears when a single MR is in a visited network and has one egress and one ingress interface, both wireless. The RA's sent by the ingress interface may be received by the egress interface (on the wireless air space between the two antennas) and then the egress interface configures a CoA (by the nemo and mip6 specs) that is valid in the internal link; thus making a sort of loop. Initially, I was thinking that such a problem has little chance to occur in practice with 802.11b because when one configures such a router s/he is forced to determine two different L2 networks for the two interfaces (via essid/enc) and thus the egress interface could not receive the RA's of the ingress interface. True, restricting the reasoning to 802.11b exclusively is little relevant to an IP solution that shoudl work over several wireless types. But imposing hte multiplicity of wireless links as a requirement is even more advantageous for avoiding the existence of loop problem: if egress is CDMA and ingress is WLAN then there is absolutely 0 chance for egress to receive RA from ingress. IMHO, that's what I think right now about the looping problem, looking for a better definition. So, I take advantage of your mentioning of the looping problem to ask: how do you Pascal think more exactly the looping problem looks like with nemo basic, thanks, Alex --------------ms080103030607080604030109 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MjgyMjEwNTRaMCMGCSqGSIb3DQEJBDEWBBQPksx11XpXpjgmaTOqXqSYg6s4ijBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCbjxMxPCsDpy/I5T+dAjcYjzQ1jeaJUl/h2RFG Bc1j8bKkkimIbrWDPbOLJRLj2VSGCBmq0d9tiZmHKySZ/fKuhIUsOlcpttOzL9W9OTzlcWR0 h8gkvEUNoLe0s53fd2qL/E/WB8nX4VjUpdvZskKvEv9mqvR0FJYcFxGMTQBrLQAAAAAAAA== --------------ms080103030607080604030109-- From nemo-admin@ietf.org Wed Apr 28 21:52:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10385 for ; Wed, 28 Apr 2004 21:52:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0eh-0000qh-9q; Wed, 28 Apr 2004 21:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0cQ-0008UO-08 for nemo@optimus.ietf.org; Wed, 28 Apr 2004 21:45:42 -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 VAA10085 for ; Wed, 28 Apr 2004 21:45:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0cL-0000tn-SM for nemo@ietf.org; Wed, 28 Apr 2004 21:45:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0bM-0000nw-00 for nemo@ietf.org; Wed, 28 Apr 2004 21:44:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0aY-0000cD-00 for nemo@ietf.org; Wed, 28 Apr 2004 21:43:46 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2004 03:50:04 +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 i3T1ggc9005789; Thu, 29 Apr 2004 03:43:14 +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); Thu, 29 Apr 2004 02:43:31 +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: looping problem (was: Questions on multiple mobile network prefixes in a BU) Date: Thu, 29 Apr 2004 02:43:30 +0100 Message-ID: Thread-Topic: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a BU) Thread-Index: AcQtcV/3KXfnsVXbRDuW6QLOUiHGKQAGNwmw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" Cc: "Tan, Tat Kin" , X-OriginalArrivalTime: 29 Apr 2004 01:43:31.0387 (UTC) FILETIME=[6060B0B0:01C42D8B] 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Alex,=20 You're right, I need to explain more. Actually there's a draft coming up about that.=20 The Question was initially asked at the Nemo Bof in Yokohama by Steve Deering in person :)=20 When MRs attach to each other in order to form a nested NEMO, you may very well end up making loops unless you take a particular attention. It's not just a MR attaching to its back but also=20 MR1->MR2->MR3->MR1 , which is the point Jari made as well if I remember correctly. Like I said, draft coming up! Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Alexandru Petrescu > Sent: mercredi 28 avril 2004 15:11 > To: Pascal Thubert (pthubert) > Cc: Tan, Tat Kin; nemo@ietf.org > Subject: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a > BU) >=20 > Pascal Thubert (pthubert) wrote: > > I guess that RO contradicts that postulate, though it's true for > > basic. But basic does not know how to avoid loops... >=20 > Loops with basic nemo support have been mentioned here at least twice. > The earliest mention I know of was autumn last year (J. Arkko) in an > email to nemo and then in the winter by E. K. Paik in > draft-cho-nemo-hmra named "RA confliction problem". >=20 > I've looked closely at both concerns and it is still unclear to me how > the looping problem can be defined and potentially solved. >=20 > In order to reduce the problem scope, I can say that its simplest form > appears when a single MR is in a visited network and has one egress and > one ingress interface, both wireless. The RA's sent by the ingress > interface may be received by the egress interface (on the wireless air > space between the two antennas) and then the egress interface configures > a CoA (by the nemo and mip6 specs) that is valid in the internal link; > thus making a sort of loop. >=20 > Initially, I was thinking that such a problem has little chance to occur > in practice with 802.11b because when one configures such a router s/he > is forced to determine two different L2 networks for the two interfaces > (via essid/enc) and thus the egress interface could not receive the RA's > of the ingress interface. >=20 > True, restricting the reasoning to 802.11b exclusively is little > relevant to an IP solution that shoudl work over several wireless types. > But imposing hte multiplicity of wireless links as a requirement is > even more advantageous for avoiding the existence of loop problem: if > egress is CDMA and ingress is WLAN then there is absolutely 0 chance for > egress to receive RA from ingress. >=20 > IMHO, that's what I think right now about the looping problem, looking > for a better definition. >=20 > So, I take advantage of your mentioning of the looping problem to ask: > how do you Pascal think more exactly the looping problem looks like with > nemo basic, thanks, >=20 > Alex From exim@www1.ietf.org Wed Apr 28 22:11:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10910 for ; Wed, 28 Apr 2004 22:11:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0ny-0002Lw-7K for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 21:57:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T1vcAk009042 for nemo-archive@odin.ietf.org; Wed, 28 Apr 2004 21:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0k9-0001bv-DI for nemo-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 21:53:41 -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 VAA10424 for ; Wed, 28 Apr 2004 21:53:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0k5-0001ez-6S for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 21:53:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0jE-0001aX-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 21:52:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0ie-0001VX-00 for nemo-web-archive@ietf.org; Wed, 28 Apr 2004 21:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0eh-0000qh-9q; Wed, 28 Apr 2004 21:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ0cQ-0008UO-08 for nemo@optimus.ietf.org; Wed, 28 Apr 2004 21:45:42 -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 VAA10085 for ; Wed, 28 Apr 2004 21:45:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ0cL-0000tn-SM for nemo@ietf.org; Wed, 28 Apr 2004 21:45:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ0bM-0000nw-00 for nemo@ietf.org; Wed, 28 Apr 2004 21:44:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1BJ0aY-0000cD-00 for nemo@ietf.org; Wed, 28 Apr 2004 21:43:46 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2004 03:50:04 +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 i3T1ggc9005789; Thu, 29 Apr 2004 03:43:14 +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); Thu, 29 Apr 2004 02:43:31 +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: looping problem (was: Questions on multiple mobile network prefixes in a BU) Date: Thu, 29 Apr 2004 02:43:30 +0100 Message-ID: Thread-Topic: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a BU) Thread-Index: AcQtcV/3KXfnsVXbRDuW6QLOUiHGKQAGNwmw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" Cc: "Tan, Tat Kin" , X-OriginalArrivalTime: 29 Apr 2004 01:43:31.0387 (UTC) FILETIME=[6060B0B0:01C42D8B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: quoted-printable Hi Alex,=20 You're right, I need to explain more. Actually there's a draft coming up about that.=20 The Question was initially asked at the Nemo Bof in Yokohama by Steve Deering in person :)=20 When MRs attach to each other in order to form a nested NEMO, you may very well end up making loops unless you take a particular attention. It's not just a MR attaching to its back but also=20 MR1->MR2->MR3->MR1 , which is the point Jari made as well if I remember correctly. Like I said, draft coming up! Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Alexandru Petrescu > Sent: mercredi 28 avril 2004 15:11 > To: Pascal Thubert (pthubert) > Cc: Tan, Tat Kin; nemo@ietf.org > Subject: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a > BU) >=20 > Pascal Thubert (pthubert) wrote: > > I guess that RO contradicts that postulate, though it's true for > > basic. But basic does not know how to avoid loops... >=20 > Loops with basic nemo support have been mentioned here at least twice. > The earliest mention I know of was autumn last year (J. Arkko) in an > email to nemo and then in the winter by E. K. Paik in > draft-cho-nemo-hmra named "RA confliction problem". >=20 > I've looked closely at both concerns and it is still unclear to me how > the looping problem can be defined and potentially solved. >=20 > In order to reduce the problem scope, I can say that its simplest form > appears when a single MR is in a visited network and has one egress and > one ingress interface, both wireless. The RA's sent by the ingress > interface may be received by the egress interface (on the wireless air > space between the two antennas) and then the egress interface configures > a CoA (by the nemo and mip6 specs) that is valid in the internal link; > thus making a sort of loop. >=20 > Initially, I was thinking that such a problem has little chance to occur > in practice with 802.11b because when one configures such a router s/he > is forced to determine two different L2 networks for the two interfaces > (via essid/enc) and thus the egress interface could not receive the RA's > of the ingress interface. >=20 > True, restricting the reasoning to 802.11b exclusively is little > relevant to an IP solution that shoudl work over several wireless types. > But imposing hte multiplicity of wireless links as a requirement is > even more advantageous for avoiding the existence of loop problem: if > egress is CDMA and ingress is WLAN then there is absolutely 0 chance for > egress to receive RA from ingress. >=20 > IMHO, that's what I think right now about the looping problem, looking > for a better definition. >=20 > So, I take advantage of your mentioning of the looping problem to ask: > how do you Pascal think more exactly the looping problem looks like with > nemo basic, thanks, >=20 > Alex From nemo-admin@ietf.org Thu Apr 29 05:24:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15813 for ; Thu, 29 Apr 2004 05:24:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7i7-0004ls-9R; Thu, 29 Apr 2004 05:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7fD-0004Cv-F4 for nemo@optimus.ietf.org; Thu, 29 Apr 2004 05:17:03 -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 FAA15567 for ; Thu, 29 Apr 2004 05:16:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7f5-0007Ib-6U for nemo@ietf.org; Thu, 29 Apr 2004 05:16:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7e6-00077p-00 for nemo@ietf.org; Thu, 29 Apr 2004 05:15:55 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1BJ7d6-0006t8-00 for nemo@ietf.org; Thu, 29 Apr 2004 05:14:52 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i3T9EpNJ006494; Thu, 29 Apr 2004 02:14:51 -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 i3T9ECLi027527; Thu, 29 Apr 2004 04:14:22 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 34FEE863810; Thu, 29 Apr 2004 11:14:12 +0200 (CEST) Message-ID: <4090C75D.2070103@motorola.com> Date: Thu, 29 Apr 2004 11:14:05 +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: "Pascal Thubert (pthubert)" Cc: "Tan, Tat Kin" , nemo@ietf.org Subject: Re: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a BU) References: In-Reply-To: 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="------------ms050702040409040906000509" 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms050702040409040906000509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > You're right, I need to explain more. Actually there's a draft coming > up about that. Ok I look forward for that. > The Question was initially asked at the Nemo Bof in Yokohama by Steve > Deering in person :) Ok. > When MRs attach to each other in order to form a nested NEMO, you may > very well end up making loops unless you take a particular > attention. > It's not just a MR attaching to its back but also MR1->MR2->MR3->MR1 > , which is the point Jari made as well if I remember correctly. Right, I wanted to say that the simplest loop may appear with only one MR and if that loop appears with one MR then more complex loops may appear with a sequence of MR's too. > Like I said, draft coming up! The one with "Tree Discovery"? Alex --------------ms050702040409040906000509 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MjkwOTE0MDVaMCMGCSqGSIb3DQEJBDEWBBSmbpr72oXbGS0i665vClWf3CJBTDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBTJnSY5r/7Ebos2F6oVEb3CyNqtXgu7akk1BBb xxp2RV6l6z5BbIBjqzo5Wv/hRuxfr4/vaeNC5b5/C95FRjDh/Uc69Ab7unHBXRm9g88S9Wx9 iDEyn8untkKYFfRFuVy/UTzAEGcScRqkxMdmjV1Ip4TGqPSzAuNI9qL6hmtikgAAAAAAAA== --------------ms050702040409040906000509-- From exim@www1.ietf.org Thu Apr 29 05:38:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16150 for ; Thu, 29 Apr 2004 05:38:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7rZ-0006tc-B8 for nemo-archive@odin.ietf.org; Thu, 29 Apr 2004 05:29:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T9TnDU026506 for nemo-archive@odin.ietf.org; Thu, 29 Apr 2004 05:29:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7nx-0005xu-Np for nemo-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 05:26:05 -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 FAA15841 for ; Thu, 29 Apr 2004 05:25:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7np-0000xC-GB for nemo-web-archive@ietf.org; Thu, 29 Apr 2004 05:25:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7mq-0000ny-00 for nemo-web-archive@ietf.org; Thu, 29 Apr 2004 05:24:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ7mL-0000f4-00 for nemo-web-archive@ietf.org; Thu, 29 Apr 2004 05:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7i7-0004ls-9R; Thu, 29 Apr 2004 05:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7fD-0004Cv-F4 for nemo@optimus.ietf.org; Thu, 29 Apr 2004 05:17:03 -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 FAA15567 for ; Thu, 29 Apr 2004 05:16:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7f5-0007Ib-6U for nemo@ietf.org; Thu, 29 Apr 2004 05:16:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7e6-00077p-00 for nemo@ietf.org; Thu, 29 Apr 2004 05:15:55 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1BJ7d6-0006t8-00 for nemo@ietf.org; Thu, 29 Apr 2004 05:14:52 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i3T9EpNJ006494; Thu, 29 Apr 2004 02:14:51 -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 i3T9ECLi027527; Thu, 29 Apr 2004 04:14:22 -0500 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 34FEE863810; Thu, 29 Apr 2004 11:14:12 +0200 (CEST) Message-ID: <4090C75D.2070103@motorola.com> Date: Thu, 29 Apr 2004 11:14:05 +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: "Pascal Thubert (pthubert)" Cc: "Tan, Tat Kin" , nemo@ietf.org Subject: Re: [nemo] Re: looping problem (was: Questions on multiple mobile network prefixes in a BU) References: In-Reply-To: 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="------------ms050702040409040906000509" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 This is a cryptographically signed message in MIME format. --------------ms050702040409040906000509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > You're right, I need to explain more. Actually there's a draft coming > up about that. Ok I look forward for that. > The Question was initially asked at the Nemo Bof in Yokohama by Steve > Deering in person :) Ok. > When MRs attach to each other in order to form a nested NEMO, you may > very well end up making loops unless you take a particular > attention. > It's not just a MR attaching to its back but also MR1->MR2->MR3->MR1 > , which is the point Jari made as well if I remember correctly. Right, I wanted to say that the simplest loop may appear with only one MR and if that loop appears with one MR then more complex loops may appear with a sequence of MR's too. > Like I said, draft coming up! The one with "Tree Discovery"? Alex --------------ms050702040409040906000509 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0 MjkwOTE0MDVaMCMGCSqGSIb3DQEJBDEWBBSmbpr72oXbGS0i665vClWf3CJBTDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBTJnSY5r/7Ebos2F6oVEb3CyNqtXgu7akk1BBb xxp2RV6l6z5BbIBjqzo5Wv/hRuxfr4/vaeNC5b5/C95FRjDh/Uc69Ab7unHBXRm9g88S9Wx9 iDEyn8untkKYFfRFuVy/UTzAEGcScRqkxMdmjV1Ip4TGqPSzAuNI9qL6hmtikgAAAAAAAA== --------------ms050702040409040906000509-- From nemo-admin@ietf.org Fri Apr 30 10:14:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03583 for ; Fri, 30 Apr 2004 10:14:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYgO-0002Ny-B3; Fri, 30 Apr 2004 10:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYdY-0001AG-QD for nemo@optimus.ietf.org; Fri, 30 Apr 2004 10:05:08 -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 KAA02549 for ; Fri, 30 Apr 2004 10:05:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYdW-0004Pp-ID for nemo@ietf.org; Fri, 30 Apr 2004 10:05:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYcm-0004OE-00 for nemo@ietf.org; Fri, 30 Apr 2004 10:04:22 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJYbv-0004LR-00 for nemo@ietf.org; Fri, 30 Apr 2004 10:03:27 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3UDxTcJ029800 for ; Fri, 30 Apr 2004 06:59:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3UE3M02029348 for ; Fri, 30 Apr 2004 09:03:23 -0500 Received: from motorola.com (zfr01-2135.crm.mot.com [10.161.201.135]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 875FF865980 for ; Fri, 30 Apr 2004 16:03:22 +0200 (CEST) Message-ID: <40925CA9.6000101@motorola.com> Date: Fri, 30 Apr 2004 16:03:21 +0200 From: Christophe Janneteau 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 Content-Type: multipart/mixed; boundary="------------090804090608050208010301" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,MIME_SUSPECT_NAME, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Subject: [nemo] [Fwd: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------090804090608050208010301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, Just to inform you that we have submitted a new I-D on the support of IP multicast for mobile networks. The proposal relies on the use of the MLD-based multicast forwarding mechanism (from magma WG) inside the mobile network. I was expecting the draft to be announced on the NEMO mailing list too, but it was not...this is why I am sending this email now. Thanks Christophe --------------090804090608050208010301 Content-Type: message/rfc822; name="I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt" Return-Path: X-Original-To: Christophe.Janneteau@crm.mot.com Delivered-To: Christophe.Janneteau@crm.mot.com Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A750D863810; Wed, 28 Apr 2004 22:18:40 +0200 (CEST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3SKIA6R022852; Wed, 28 Apr 2004 15:18:30 -0500 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i3SKIHvv014873; Wed, 28 Apr 2004 13:18:17 -0700 (MST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIurD-0003OA-BY; Wed, 28 Apr 2004 15:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuk8-0001da-FJ for i-d-announce@optimus.ietf.org; Wed, 28 Apr 2004 15:29:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11001 for ; Wed, 28 Apr 2004 15:29:14 -0400 (EDT) Message-Id: <200404281929.PAA11001@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: From: Subject: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt Date: Wed, 28 Apr 2004 15:29:14 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Multicast for Mobile Networks with MLD-Proxy Author(s) : C. Janneteau, et al. Filename : draft-janneteau-nemo-multicast-mldproxy-00.txt Pages : 13 Date : 2004-4-28 This document addresses the problem of delivering IPv6 multicast traffic to nodes inside a mobile network. An approach based on the deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] in the mobile network, combined with the use of MLD [2][3] between the mobile router (MR) and the visited network, is proposed. Such a configuration allows multicast support for mobile networks, without the need to run a multicast routing protocol. In addition of being simple to implement and deploy, this approach provides global mobility in the Internet, and optimal multicast routing with nested mobile networks, while optimizing network and radio resources. This document does not specify new protocols, nor extensions to existing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.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-janneteau-nemo-multicast-mldproxy-00.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-janneteau-nemo-multicast-mldproxy-00.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-4-28153028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-janneteau-nemo-multicast-mldproxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153028.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce --------------090804090608050208010301-- From exim@www1.ietf.org Fri Apr 30 10:28:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04508 for ; Fri, 30 Apr 2004 10:28:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYus-0007NX-Ab for nemo-archive@odin.ietf.org; Fri, 30 Apr 2004 10:23:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UEN2wE028364 for nemo-archive@odin.ietf.org; Fri, 30 Apr 2004 10:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYo7-0005Yo-Ur for nemo-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 10:16: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 KAA03737 for ; Fri, 30 Apr 2004 10:16:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYo5-0004o0-El for nemo-web-archive@ietf.org; Fri, 30 Apr 2004 10:16:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYn7-0004le-00 for nemo-web-archive@ietf.org; Fri, 30 Apr 2004 10:15:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYmL-0004k9-00 for nemo-web-archive@ietf.org; Fri, 30 Apr 2004 10:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYgO-0002Ny-B3; Fri, 30 Apr 2004 10:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYdY-0001AG-QD for nemo@optimus.ietf.org; Fri, 30 Apr 2004 10:05:08 -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 KAA02549 for ; Fri, 30 Apr 2004 10:05:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYdW-0004Pp-ID for nemo@ietf.org; Fri, 30 Apr 2004 10:05:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYcm-0004OE-00 for nemo@ietf.org; Fri, 30 Apr 2004 10:04:22 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJYbv-0004LR-00 for nemo@ietf.org; Fri, 30 Apr 2004 10:03:27 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3UDxTcJ029800 for ; Fri, 30 Apr 2004 06:59:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3UE3M02029348 for ; Fri, 30 Apr 2004 09:03:23 -0500 Received: from motorola.com (zfr01-2135.crm.mot.com [10.161.201.135]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 875FF865980 for ; Fri, 30 Apr 2004 16:03:22 +0200 (CEST) Message-ID: <40925CA9.6000101@motorola.com> Date: Fri, 30 Apr 2004 16:03:21 +0200 From: Christophe Janneteau 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 Content-Type: multipart/mixed; boundary="------------090804090608050208010301" Subject: [nemo] [Fwd: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090804090608050208010301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, Just to inform you that we have submitted a new I-D on the support of IP multicast for mobile networks. The proposal relies on the use of the MLD-based multicast forwarding mechanism (from magma WG) inside the mobile network. I was expecting the draft to be announced on the NEMO mailing list too, but it was not...this is why I am sending this email now. Thanks Christophe --------------090804090608050208010301 Content-Type: message/rfc822; name="I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt" Return-Path: X-Original-To: Christophe.Janneteau@crm.mot.com Delivered-To: Christophe.Janneteau@crm.mot.com Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A750D863810; Wed, 28 Apr 2004 22:18:40 +0200 (CEST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3SKIA6R022852; Wed, 28 Apr 2004 15:18:30 -0500 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i3SKIHvv014873; Wed, 28 Apr 2004 13:18:17 -0700 (MST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIurD-0003OA-BY; Wed, 28 Apr 2004 15:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuk8-0001da-FJ for i-d-announce@optimus.ietf.org; Wed, 28 Apr 2004 15:29:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11001 for ; Wed, 28 Apr 2004 15:29:14 -0400 (EDT) Message-Id: <200404281929.PAA11001@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: From: Subject: I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt Date: Wed, 28 Apr 2004 15:29:14 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Multicast for Mobile Networks with MLD-Proxy Author(s) : C. Janneteau, et al. Filename : draft-janneteau-nemo-multicast-mldproxy-00.txt Pages : 13 Date : 2004-4-28 This document addresses the problem of delivering IPv6 multicast traffic to nodes inside a mobile network. An approach based on the deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1] in the mobile network, combined with the use of MLD [2][3] between the mobile router (MR) and the visited network, is proposed. Such a configuration allows multicast support for mobile networks, without the need to run a multicast routing protocol. In addition of being simple to implement and deploy, this approach provides global mobility in the Internet, and optimal multicast routing with nested mobile networks, while optimizing network and radio resources. This document does not specify new protocols, nor extensions to existing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.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-janneteau-nemo-multicast-mldproxy-00.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-janneteau-nemo-multicast-mldproxy-00.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-4-28153028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-janneteau-nemo-multicast-mldproxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153028.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce --------------090804090608050208010301--