From acee.lindem@ericsson.com Mon Apr 2 16:26:20 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442BD21F85A4 for ; Mon, 2 Apr 2012 16:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rPfAtr2+v80 for ; Mon, 2 Apr 2012 16:26:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C126921F856A for ; Mon, 2 Apr 2012 16:26:19 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q32NQHdY005209 for ; Mon, 2 Apr 2012 18:26:19 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.83]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 2 Apr 2012 19:26:16 -0400 From: Acee Lindem To: OSPF List Date: Mon, 2 Apr 2012 19:26:10 -0400 Thread-Topic: IETF 83 WG Minutes Thread-Index: Ac0RKAAdAgHmioVlR3uvhBqtJQ4ulA== Message-ID: <1E555FB5-94BB-4998-BCC2-0E5BAA28ACC2@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-9-767168859"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] IETF 83 WG Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:26:20 -0000 --Apple-Mail-9-767168859 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All,=20 I've uploaded the minutes from our meeting last Tuesday. Thanks to = Alvaro Retano for taking the them. We had a quite an animated discussion = on Topology Transparent Zones and hopefully we were able to capture = everyone's comments.=20 http://www.ietf.org/proceedings/83/minutes/minutes-83-ospf.txt Thanks, Acee=20= --Apple-Mail-9-767168859 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwMjIzMjYxMVowIwYJKoZI hvcNAQkEMRYEFEiX0GGNup++qk8UDpg86lcNwuwSMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgINHp1xxqc1wMLxxXJ2ftR73qjbyzU/W27xrM+OOptFwWVLKDQTHPLw/kNDRjcTE TOr+hHWwgrrs3o6nc+tyShPDiC3PF0gwA5FDOCPr7oZ0Er/aA0u/zTXBLZWursaw/MlPTk378frF OQ3Dk1sjkJUDfel4dN0rkTIBbjjQX0d+AAAAAAAA --Apple-Mail-9-767168859-- From acee.lindem@ericsson.com Mon Apr 2 16:32:19 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C8221F8674 for ; Mon, 2 Apr 2012 16:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfKFpWMlbcma for ; Mon, 2 Apr 2012 16:32:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B179D21F85FD for ; Mon, 2 Apr 2012 16:32:02 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q32NW1V5010529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Apr 2012 18:32:02 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.83]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 2 Apr 2012 19:32:01 -0400 From: Acee Lindem To: OSPF List Date: Mon, 2 Apr 2012 19:31:54 -0400 Thread-Topic: [OSPF] IETF 83 WG Minutes (resent w/o signature) Thread-Index: Ac0RKM084iV+oEcaRFGF/cPa2ftIMA== Message-ID: <945E2565-5531-4B5F-A024-F363B9187638@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-10-767512985"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] IETF 83 WG Minutes (resent w/o signature) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:32:19 -0000 --Apple-Mail-10-767512985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All,=20 I've uploaded the minutes from our meeting last Tuesday. Thanks to = Alvaro Retano for taking them. We had a quite an animated discussion on = Topology Transparent Zones and hopefully we were able to capture = everyone's comments.=20 http://www.ietf.org/proceedings/83/minutes/minutes-83-ospf.txt Thanks, Acee=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-10-767512985 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwMjIzMzE1NVowIwYJKoZI hvcNAQkEMRYEFAzLMvwVPeD0ZYi0tj7Acu3TMtqhMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgI2vCSvIUeku8IlBlZJ7qv4qsfeeXTDKMzDWkLxqk/SkFLAcDKM5SdMDiGIoWXea E35TPe7+27Ggzn7RtLBMIF2PyWTnv0hbjL6hYJNOfk4zTMJBh4tbz4WZAXTAtmi2E4Vm2BlUr7c4 fj4ezI1RN3j+65ElBJ/YAq1Uw6X84LlHAAAAAAAA --Apple-Mail-10-767512985-- From acee.lindem@ericsson.com Mon Apr 2 16:35:13 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62A821F8752 for ; Mon, 2 Apr 2012 16:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3GltD17a9Gs for ; Mon, 2 Apr 2012 16:35:13 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD421F867B for ; Mon, 2 Apr 2012 16:35:13 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q32NZCno010679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Apr 2012 18:35:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.83]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 2 Apr 2012 19:35:11 -0400 From: Acee Lindem To: OSPF List Date: Mon, 2 Apr 2012 19:35:06 -0400 Thread-Topic: [OSPF] IETF 83 WG Minutes (resent w/o signature) Thread-Index: Ac0RKT7jNuTQ6YtERZq0O1zqeq255w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] IETF 83 WG Minutes (resent w/o signature) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:35:13 -0000 All,=20 I've uploaded the minutes from our meeting last Tuesday. Thanks to Alvaro R= etano for taking them. We had a quite an animated discussion on Topology Tr= ansparent Zones and hopefully we were able to capture everyone's comments.= =20 http://www.ietf.org/proceedings/83/minutes/minutes-83-ospf.txt Thanks, Acee=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Thu Apr 12 10:45:43 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FD521F8589 for ; Thu, 12 Apr 2012 10:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmgQnxk-ULKy for ; Thu, 12 Apr 2012 10:45:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6381221F8531 for ; Thu, 12 Apr 2012 10:45:42 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3CHje1P010729; Thu, 12 Apr 2012 12:45:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.83]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 12 Apr 2012 13:45:35 -0400 From: Acee Lindem To: OSPF List , Stewart Bryant Date: Thu, 12 Apr 2012 13:45:33 -0400 Thread-Topic: draft-acee-ospf-ospfv3-autoconfig-01.txt and Stewart's Question Thread-Index: Ac0Y1BAX/f1dZs0xTGWdlhz2gE4ZXg== Message-ID: <4A019821-7B50-4055-B91E-652E821E443A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] draft-acee-ospf-ospfv3-autoconfig-01.txt and Stewart's Question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:45:43 -0000 In response to Stewart Bryant's request, I looked at draft-simpson-isis-ppp= -unique-02.txt for similarities. The only similarity is that both drafts us= e a random number for a unique router identifier. IMHO, this technique is o= bvious enough that there is no need to reference the expired ISIS draft. I also received some off-list comments from Abhay Roy and Manav Bhatia rega= rding mitigation of the effects of duplicate router IDs in the OSPFv3 routi= ng domain prior to duplicate detection and resolution. I intend to address = these in the next revision. At that time, we will ask for WG adoption. Thanks, Acee From acee.lindem@ericsson.com Thu Apr 12 10:59:25 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31FF21F85D7 for ; Thu, 12 Apr 2012 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.736 X-Spam-Level: X-Spam-Status: No, score=-5.736 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VjX9sqMtz5t for ; Thu, 12 Apr 2012 10:59:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C4FD721F85B5 for ; Thu, 12 Apr 2012 10:59:24 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3CHwpnS013760; Thu, 12 Apr 2012 12:59:24 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.83]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 12 Apr 2012 13:59:16 -0400 From: Acee Lindem Date: Thu, 12 Apr 2012 13:59:15 -0400 Thread-Topic: [OSPF] draft-acee-ospf-ospfv3-autoconfig-01.txt and Stewart's Question Thread-Index: Ac0Y1fm2JxgjGvCCRj+upty2juenzA== Message-ID: <397C575F-BE9D-4631-9248-51A444963631@ericsson.com> References: <4A019821-7B50-4055-B91E-652E821E443A@ericsson.com> In-Reply-To: <4A019821-7B50-4055-B91E-652E821E443A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] draft-acee-ospf-ospfv3-autoconfig-01.txt and Stewart's Question X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:59:25 -0000 On Apr 12, 2012, at 1:45 PM, Acee Lindem wrote: > In response to Stewart Bryant's request, I looked at draft-simpson-isis-p= pp-unique-02.txt for similarities. The only similarity is that both drafts = use a random number for a unique router identifier. IMHO, this technique is= obvious enough that there is no need to reference the expired ISIS draft. In support of my supposition of obviousness, I Googled "unique system ID ra= ndom number" and it yielded 21,800,000 results.=20 Thanks, Acee=20 >=20 > I also received some off-list comments from Abhay Roy and Manav Bhatia re= garding mitigation of the effects of duplicate router IDs in the OSPFv3 rou= ting domain prior to duplicate detection and resolution. I intend to addres= s these in the next revision. At that time, we will ask for WG adoption. >=20 > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From sshamim@cisco.com Fri Apr 13 09:15:37 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A413121F8624 for ; Fri, 13 Apr 2012 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF5tbakbcR4a for ; Fri, 13 Apr 2012 09:15:36 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AFC9821F8618 for ; Fri, 13 Apr 2012 09:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sshamim@cisco.com; l=7215; q=dns/txt; s=iport; t=1334333736; x=1335543336; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=zsbU5DiSzt+8JvhaE5ma/Wjmrx02vzYi6IjEcNMBVqA=; b=gRBCBuTnUqeFsQUA9OhMX8VGS26T9sxWkRjKJLO7mmlJNgV3Db8A5Rga oLcqtPhSiTVKcBO2+X7jtnP0Hkk9L2ZzVjmhFtfq1vaq65yLKbU+COHeS 7rp5U17nvj517RN5VPT11rzxJZTLw+fCoauW300ProPxm2KLrlc/icPtl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkLAKNQiE+rRDoG/2dsb2JhbABFgxyyWgOBBoEHghASARQTAgFPgSUGExQOh2uYKIEooAGMMIUnBIhajRKFcohbgWmDBQ X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="40445425" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Apr 2012 16:15:33 +0000 Received: from [10.20.173.249] (sjc-sshamim-8918.cisco.com [10.20.173.249]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3DGFWqh027539 for ; Fri, 13 Apr 2012 16:15:32 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 13 Apr 2012 11:16:34 -0500 From: Faraz Shamim To: Message-ID: Thread-Topic: RFC1583Compatibility In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [OSPF] RFC1583Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:15:37 -0000 Acee, I would like to know what the rest of the OSPF WG think about this. I want to see if anyone has implemented it differently. Requesting for Comments from the rest of the community ;-) On 4/13/12 10:57 AM, "Faraz Shamim" wrote: >If you read section G.7 of RFC 2178 it appears that >RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS >external >if received from multiple area AND change the summary range cost to pick >up MAXIMUM cost. But when you read C.1, under RFC1583Compatibility it >says that this parameter applies to AS external. No where it mentions >the summary cost should be changed to MINIMUM per RFC 1583. Since G.7 >does not even exist in RFC 2328 so whoever >reads RFC 2328 would always think that RFC1583Compatibility is ONLY >related to AS external path preference. > >Can you please confirm if RFC1583Compatibility should only affect AS >external path preference or should it also touch the summary cost and set >it to MINIMUM per RFC 1583? > >Thanks, > >Faraz >From RFC 2178: G.7 Advertising same external route from multiple areas This document fixes routing loops which can occur in RFC 1583 when the same external destination is advertised by AS boundary routers in separate areas. There are two manifestations of this problem. The first, discovered by Dennis Ferguson, occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs to change, resulting in a routing loop. The second manifestation was discovered by Richard Woundy. It is caused by an incomplete application of OSPF's preference of intra- area routes over inter-area routes: paths to any given ASBR/forwarding address are selected first based on intra-area preference, while the comparison between separate ASBRs/forwarding addresses is driven only by cost, ignoring intra-area preference. His example is replicated in Figure 19. Both router A3 and router B3 are originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, based on shorter cost to ASBR B3 (via B1->B2->B3). However, the shorter route to B3 is not available to B1, due to B1's preference for the (higher cost) intra-area route to B3 through Area A. This leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a routing loop. Moy Standards Track [Page 207] RFC 2178 OSPF Version 2 July 1997 The following two changes have been made to prevent these routing loops: o When originating a type 3 summary-LSA for a configured area address range, the cost of the summary-LSA is now set to the maximum cost of the range's component networks (instead of the previous algorithm which set the cost to the minimum component cost). This change affects Sections 3.5 and 12.4.3, Figures 7 and 8, and Tables 6 and 13. o The preference rules for choosing among multiple AS- external-LSAs have been changed. Where previously cost was the only determining factor, now the preference is driven first by type of path (intra-area or inter-area, through non-backbone area or through backbone) to the ASBR/forwarding address, using cost only to break ties. This change affects Sections 16.4 and 16.4.1. After implementing this change, the example in Figure 19 is modified as follows. Router A1 now chooses A3 as the next 10.0.0.0/8 ---------- | +----+ | XX | +----+ RIP / \ RIP --------------------- -------------------- ! ! ! ! +----+ +----+ 1 +----+......+----+.... | A3 |------| A1 |---------------| B1 |------| B3 | . +----+ 6 +----+ +----+ 8 +----+ . 1| . / . OSPF backbone | . / . +----+ 2 / . | B2 |------- Area A. +----+................ Figure 19: Example routing loop when the same external route is advertised from multiple areas hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for both choices is that ASBRs/forwarding addresses are now chosen based first on intra-area preference, and then by cost. Moy Standards Track [Page 208] RFC 2178 OSPF Version 2 July 1997 Unfortunately, this change is not backward compatible. While the change prevents routing loops when all routers run the new preference rules, it can actually create routing loops when some routers are running the new preference rules and other routers implement RFC 1583. For this reason, a new configuration parameter has been added: RFC1583Compatibility. Only when RFC1583Compatibility is set to "disabled" will the new preference rules take effect. See Appendix C for more details. C.1 Global parameters In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below. [SNIP..] RFC1583Compatibility Controls the preference rules used in Section 16.4 when choosing among multiple AS-external-LSAs advertising the same destination. When set to "enabled", the preference rules remain those specified by RFC 1583 ([Ref9]). When set to "disabled", the preference rules are those stated in Section 16.4.1, which prevent routing loops when AS- external-LSAs for the same destination have been originated from different areas (see Section G.7). Set to "enabled" by default. In order to minimize the chance of routing loops, all OSPF routers in an OSPF routing domain should have RFC1583Compatibility set identically. When there are routers present that have not been updated with the functionality specified in Section 16.4.1 of this memo, all routers should have RFC1583Compatibility set to "enabled". Otherwise, all routers should have RFC1583Compatibility set to "disabled", preventing all routing loops. From acee.lindem@ericsson.com Tue Apr 17 07:19:40 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B676011E8080 for ; Tue, 17 Apr 2012 07:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEjbGxOSTRBQ for ; Tue, 17 Apr 2012 07:19:36 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A6CFA11E8094 for ; Tue, 17 Apr 2012 07:19:36 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3HEJYhn018064; Tue, 17 Apr 2012 09:19:35 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.242]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 17 Apr 2012 10:19:29 -0400 From: Acee Lindem To: Faraz Shamim Date: Tue, 17 Apr 2012 10:19:27 -0400 Thread-Topic: [OSPF] RFC1583Compatibility Thread-Index: Ac0cpRljiVRYayDLT7WIRZpDcpLJAw== Message-ID: <210FCC0F-4027-484D-B034-DF30DB558E80@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] RFC1583Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:19:40 -0000 Hi Faraz, On Apr 13, 2012, at 12:16 PM, Faraz Shamim wrote: > Acee, >=20 > I would like to know what the rest of the OSPF WG think about this. I wan= t > to see if anyone has implemented it differently. >=20 > Requesting for Comments from the rest of the community ;-) >=20 > On 4/13/12 10:57 AM, "Faraz Shamim" wrote: >=20 >> If you read section G.7 of RFC 2178 it appears that >> RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS >> external=20 >> if received from multiple area AND change the summary range cost to pick >> up MAXIMUM cost. But when you read C.1, under RFC1583Compatibility it >> says that this parameter applies to AS external. No where it mentions >> the summary cost should be changed to MINIMUM per RFC 1583. Since G.7 >> does not even exist in RFC 2328 so whoever >> reads RFC 2328 would always think that RFC1583Compatibility is ONLY >> related to AS external path preference. >>=20 >> Can you please confirm if RFC1583Compatibility should only affect AS >> external path preference or should it also touch the summary cost and se= t >> it to MINIMUM per RFC 1583? I agree that RFC1583Compatibility should only affect AS external path prefe= rence. This is also the interpretation in my implementation and the open so= urce quagga implementation.=20 Thanks, Acee=20 >>=20 >> Thanks, >>=20 >> Faraz >=20 > From RFC 2178: >=20 > G.7 Advertising same external route from multiple areas >=20 > This document fixes routing loops which can occur in RFC 1583 when > the same external destination is advertised by AS boundary routers in > separate areas. There are two manifestations of this problem. The > first, discovered by Dennis Ferguson, occurs when an aggregated > forwarding address is in use. In this case, the desirability of the > forwarding address can change for the worse as a packet crosses an > area aggregation boundary on the way to the forwarding address, which > in turn can cause the preference of AS-external-LSAs to change, > resulting in a routing loop. >=20 > The second manifestation was discovered by Richard Woundy. It is > caused by an incomplete application of OSPF's preference of intra- > area routes over inter-area routes: paths to any given > ASBR/forwarding address are selected first based on intra-area > preference, while the comparison between separate ASBRs/forwarding > addresses is driven only by cost, ignoring intra-area preference. His > example is replicated in Figure 19. Both router A3 and router B3 are > originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 > metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, > based on shorter cost to ASBR B3 (via B1->B2->B3). However, the > shorter route to B3 is not available to B1, due to B1's preference > for the (higher cost) intra-area route to B3 through Area A. This > leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a > routing loop. >=20 >=20 >=20 >=20 > Moy Standards Track [Page 207] >=20 > RFC 2178 OSPF Version 2 July 1997 >=20 >=20 > The following two changes have been made to prevent these routing > loops: >=20 > o When originating a type 3 summary-LSA for a configured area > address range, the cost of the summary-LSA is now set to the > maximum cost of the range's component networks (instead of the > previous algorithm which set the cost to the minimum component > cost). This change affects Sections 3.5 and 12.4.3, Figures 7 > and 8, and Tables 6 and 13. >=20 > o The preference rules for choosing among multiple AS- > external-LSAs have been changed. Where previously cost was the > only determining factor, now the preference is driven first by > type of path (intra-area or inter-area, through non-backbone area > or through backbone) to the ASBR/forwarding address, using cost > only to break ties. This change affects Sections 16.4 and 16.4.1. >=20 > After implementing this change, the example in Figure 19 is modified > as follows. Router A1 now chooses A3 as the next >=20 > 10.0.0.0/8 > ---------- > | > +----+ > | XX | > +----+ > RIP / \ RIP > --------------------- -------------------- > ! ! > ! ! > +----+ +----+ 1 +----+......+----+.... > | A3 |------| A1 |---------------| B1 |------| B3 | . > +----+ 6 +----+ +----+ 8 +----+ . > 1| . / . > OSPF backbone | . / . > +----+ 2 / . > | B2 |------- Area A. > +----+................ >=20 > Figure 19: Example routing loop when the > same external route is advertised from multiple > areas >=20 > hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for > both choices is that ASBRs/forwarding addresses are now chosen based > first on intra-area preference, and then by cost. >=20 >=20 > Moy Standards Track [Page 208] >=20 > RFC 2178 OSPF Version 2 July 1997 >=20 >=20 > Unfortunately, this change is not backward compatible. While the > change prevents routing loops when all routers run the new preference > rules, it can actually create routing loops when some routers are > running the new preference rules and other routers implement RFC > 1583. For this reason, a new configuration parameter has been added: > RFC1583Compatibility. Only when RFC1583Compatibility is set to > "disabled" will the new preference rules take effect. See Appendix C > for more details. >=20 >=20 >=20 >=20 > C.1 Global parameters >=20 > In general, a separate copy of the OSPF protocol is run for each > area. Because of this, most configuration parameters are defined on > a per-area basis. The few global configuration parameters are listed > below. >=20 > [SNIP..] >=20 > RFC1583Compatibility > Controls the preference rules used in Section 16.4 when choosing > among multiple AS-external-LSAs advertising the same destination. > When set to "enabled", the preference rules remain those > specified by RFC 1583 ([Ref9]). When set to "disabled", the > preference rules are those stated in Section 16.4.1, which > prevent routing loops when AS- external-LSAs for the same > destination have been originated from different areas (see > Section G.7). Set to "enabled" by default. >=20 >=20 > In order to minimize the chance of routing loops, all OSPF > routers in an OSPF routing domain should have > RFC1583Compatibility set identically. When there are routers > present that have not been updated with the functionality > specified in Section 16.4.1 of this memo, all routers should have > RFC1583Compatibility set to "enabled". Otherwise, all routers > should have RFC1583Compatibility set to "disabled", preventing > all routing loops. >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From pmurphy@noc.usgs.net Tue Apr 17 08:23:30 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A7921F85A5 for ; Tue, 17 Apr 2012 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5EwDabzeWuR for ; Tue, 17 Apr 2012 08:23:26 -0700 (PDT) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by ietfa.amsl.com (Postfix) with ESMTP id 13F4221F85A2 for ; Tue, 17 Apr 2012 08:23:16 -0700 (PDT) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01OEF2XQ9AOW00L7QY@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Tue, 17 Apr 2012 08:23:15 -0700 (PDT) Date: Tue, 17 Apr 2012 08:23:15 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01OEF2XQ9AOY00L7QY@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Subject: Re: [OSPF] RFC1583Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:23:30 -0000 Acee, Faraz, It is hard to believe there are any RFC 1583 implementations still in operation. It is true that back when RFC 2178 (and later RFC 2328) was published, the WG was dealing with two real routing loop issues. However it seems academic now. Can't RFC1583Compatibility simply be retired along with RFC 1583? As for John's text, > Unfortunately, this change is not backward compatible. While the > change prevents routing loops when all routers run the new preference > rules, it can actually create routing loops when some routers are > running the new preference rules and other routers implement RFC > 1583. For this reason, a new configuration parameter has been added: > RFC1583Compatibility. Only when RFC1583Compatibility is set to > "disabled" will the new preference rules take effect. See Appendix C > for more details. I feel fairly confident the "new preference rules" refer to Section 16.4.1. It seems unlikely that leaving the summary cost at MAXIMUM when RFC1583Compatiblility is set to "enabled" would create more routing loops. Indeed the opposite seems true. My guess is this omission in RFC 2328 was intentional. I did hear the discussion about backward compatibility and I don't remember any mention of the summary cost change. Pat > Acee, > > I would like to know what the rest of the OSPF WG think about this. I want > to see if anyone has implemented it differently. > > Requesting for Comments from the rest of the community ;-) > > On 4/13/12 10:57 AM, "Faraz Shamim" wrote: > >> If you read section G.7 of RFC 2178 it appears that >> RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS >> external >> if received from multiple area AND change the summary range cost to pick >> up MAXIMUM cost. But when you read C.1, under RFC1583Compatibility it >> says that this parameter applies to AS external. No where it mentions >> the summary cost should be changed to MINIMUM per RFC 1583. Since G.7 >> does not even exist in RFC 2328 so whoever >> reads RFC 2328 would always think that RFC1583Compatibility is ONLY >> related to AS external path preference. >> >> Can you please confirm if RFC1583Compatibility should only affect AS >> external path preference or should it also touch the summary cost and set >> it to MINIMUM per RFC 1583? I agree that RFC1583Compatibility should only affect AS external path preference. This is also the interpretation in my implementation and the open source quagga implementation. Thanks, Acee >> >> Thanks, >> >> Faraz > > From RFC 2178: > > G.7 Advertising same external route from multiple areas > > This document fixes routing loops which can occur in RFC 1583 when > the same external destination is advertised by AS boundary routers in > separate areas. There are two manifestations of this problem. The > first, discovered by Dennis Ferguson, occurs when an aggregated > forwarding address is in use. In this case, the desirability of the > forwarding address can change for the worse as a packet crosses an > area aggregation boundary on the way to the forwarding address, which > in turn can cause the preference of AS-external-LSAs to change, > resulting in a routing loop. > > The second manifestation was discovered by Richard Woundy. It is > caused by an incomplete application of OSPF's preference of intra- > area routes over inter-area routes: paths to any given > ASBR/forwarding address are selected first based on intra-area > preference, while the comparison between separate ASBRs/forwarding > addresses is driven only by cost, ignoring intra-area preference. His > example is replicated in Figure 19. Both router A3 and router B3 are > originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 > metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, > based on shorter cost to ASBR B3 (via B1->B2->B3). However, the > shorter route to B3 is not available to B1, due to B1's preference > for the (higher cost) intra-area route to B3 through Area A. This > leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a > routing loop. > > > > > Moy Standards Track [Page 207] > > RFC 2178 OSPF Version 2 July 1997 > > > The following two changes have been made to prevent these routing > loops: > > o When originating a type 3 summary-LSA for a configured area > address range, the cost of the summary-LSA is now set to the > maximum cost of the range's component networks (instead of the > previous algorithm which set the cost to the minimum component > cost). This change affects Sections 3.5 and 12.4.3, Figures 7 > and 8, and Tables 6 and 13. > > o The preference rules for choosing among multiple AS- > external-LSAs have been changed. Where previously cost was the > only determining factor, now the preference is driven first by > type of path (intra-area or inter-area, through non-backbone area > or through backbone) to the ASBR/forwarding address, using cost > only to break ties. This change affects Sections 16.4 and 16.4.1. > > After implementing this change, the example in Figure 19 is modified > as follows. Router A1 now chooses A3 as the next > > 10.0.0.0/8 > ---------- > | > +----+ > | XX | > +----+ > RIP / \ RIP > --------------------- -------------------- > ! ! > ! ! > +----+ +----+ 1 +----+......+----+.... > | A3 |------| A1 |---------------| B1 |------| B3 | . > +----+ 6 +----+ +----+ 8 +----+ . > 1| . / . > OSPF backbone | . / . > +----+ 2 / . > | B2 |------- Area A. > +----+................ > > Figure 19: Example routing loop when the > same external route is advertised from multiple > areas > > hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for > both choices is that ASBRs/forwarding addresses are now chosen based > first on intra-area preference, and then by cost. > > > Moy Standards Track [Page 208] > > RFC 2178 OSPF Version 2 July 1997 > > > Unfortunately, this change is not backward compatible. While the > change prevents routing loops when all routers run the new preference > rules, it can actually create routing loops when some routers are > running the new preference rules and other routers implement RFC > 1583. For this reason, a new configuration parameter has been added: > RFC1583Compatibility. Only when RFC1583Compatibility is set to > "disabled" will the new preference rules take effect. See Appendix C > for more details. > > > > > C.1 Global parameters > > In general, a separate copy of the OSPF protocol is run for each > area. Because of this, most configuration parameters are defined on > a per-area basis. The few global configuration parameters are listed > below. > > [SNIP..] > > RFC1583Compatibility > Controls the preference rules used in Section 16.4 when choosing > among multiple AS-external-LSAs advertising the same destination. > When set to "enabled", the preference rules remain those > specified by RFC 1583 ([Ref9]). When set to "disabled", the > preference rules are those stated in Section 16.4.1, which > prevent routing loops when AS- external-LSAs for the same > destination have been originated from different areas (see > Section G.7). Set to "enabled" by default. > > > In order to minimize the chance of routing loops, all OSPF > routers in an OSPF routing domain should have > RFC1583Compatibility set identically. When there are routers > present that have not been updated with the functionality > specified in Section 16.4.1 of this memo, all routers should have > RFC1583Compatibility set to "enabled". Otherwise, all routers > should have RFC1583Compatibility set to "disabled", preventing > all routing loops. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From sshamim@cisco.com Tue Apr 17 09:24:43 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7216A21F8499 for ; Tue, 17 Apr 2012 09:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omAZb3k7UIvi for ; Tue, 17 Apr 2012 09:24:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0934021F848A for ; Tue, 17 Apr 2012 09:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sshamim@cisco.com; l=10319; q=dns/txt; s=iport; t=1334679879; x=1335889479; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ABWB4Ctlr9vKCjD+TwWt01Dc7r3/e8AhHCT6TkVsYm0=; b=cuef2vKR4PMGi5AdjaJlzNfRFQJQSG5jZdf2ILHNDFRO15SPB1Ys4NTs e5v/lCEw/jBf0OYsUxWWciVYd8AuvlkeACed8cZ0la8ILo4V3sjJjfaI5 IX4BGZMmU7WOJMM/kFlVJuFLBzuFQS/ZSZvhJaz6HZIc8VZ6YXj1A+D8o k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYHAFiYjU+rRDoI/2dsb2JhbABBA4Mcrh2BB4IJAQEBBAEBAQ8BFBMCARcaHggYVTAGARIUDodrDJoDoAUEjU6DKQSIXI0ThXKIW4FpgwU X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="38358145" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 17 Apr 2012 16:24:23 +0000 Received: from [10.20.173.249] (sjc-sshamim-8918.cisco.com [10.20.173.249]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3HGOFOI017370; Tue, 17 Apr 2012 16:24:20 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Apr 2012 11:25:54 -0500 From: Faraz Shamim To: "Pat Murphy - (650)329-4044" , Message-ID: Thread-Topic: [OSPF] RFC1583Compatibility In-Reply-To: <01OEF2XQ9AOY00L7QY@omega7.wr.usgs.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [OSPF] RFC1583Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:24:43 -0000 Pat, The issue is that the RFC 2328 recommends to set this parameter to "enabled" by default so this means you can not get rid of this parameter and start implementing 16.4.1 as a default in new devices or old devices with new code. Having a mix of 1583 and 2328 implementation(with respect to AS external path preference) will cause loop. There are numerous implementations that follow 2328 but when it comes to AS external path preference, they follow RFC 1583 to prevent loop. Not sure if 16.4.1 will ever see it's daylight but when it does, we can safely remove this parameter and retire 1583. Faraz On 4/17/12 10:23 AM, "Pat Murphy - (650)329-4044" wrote: >Acee, Faraz, > >It is hard to believe there are any RFC 1583 implementations still in >operation. It >is true that back when RFC 2178 (and later RFC 2328) was published, the >WG was dealing >with two real routing loop issues. However it seems academic now. Can't >RFC1583Compatibility simply be retired along with RFC 1583? > >As for John's text, > >> Unfortunately, this change is not backward compatible. While the >> change prevents routing loops when all routers run the new preference >> rules, it can actually create routing loops when some routers are >> running the new preference rules and other routers implement RFC >> 1583. For this reason, a new configuration parameter has been added: >> RFC1583Compatibility. Only when RFC1583Compatibility is set to >> "disabled" will the new preference rules take effect. See Appendix C >> for more details. > >I feel fairly confident the "new preference rules" refer to Section >16.4.1. It seems >unlikely that leaving the summary cost at MAXIMUM when >RFC1583Compatiblility is set to >"enabled" would create more routing loops. Indeed the opposite seems >true. My guess is >this omission in RFC 2328 was intentional. I did hear the discussion >about backward >compatibility and I don't remember any mention of the summary cost change. > >Pat > >> Acee, >> >> I would like to know what the rest of the OSPF WG think about this. I >>want >> to see if anyone has implemented it differently. >> >> Requesting for Comments from the rest of the community ;-) >> >> On 4/13/12 10:57 AM, "Faraz Shamim" wrote: >> >>> If you read section G.7 of RFC 2178 it appears that >>> RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS >>> external >>> if received from multiple area AND change the summary range cost to >>>pick >>> up MAXIMUM cost. But when you read C.1, under RFC1583Compatibility it >>> says that this parameter applies to AS external. No where it mentions >>> the summary cost should be changed to MINIMUM per RFC 1583. Since G.7 >>> does not even exist in RFC 2328 so whoever >>> reads RFC 2328 would always think that RFC1583Compatibility is ONLY >>> related to AS external path preference. >>> >>> Can you please confirm if RFC1583Compatibility should only affect AS >>> external path preference or should it also touch the summary cost and >>>set >>> it to MINIMUM per RFC 1583? > >I agree that RFC1583Compatibility should only affect AS external path >preference. This >is also the interpretation in my implementation and the open source >quagga >implementation. > >Thanks, >Acee > > > > > >>> >>> Thanks, >>> >>> Faraz >> >> From RFC 2178: >> >> G.7 Advertising same external route from multiple areas >> >> This document fixes routing loops which can occur in RFC 1583 when >> the same external destination is advertised by AS boundary routers in >> separate areas. There are two manifestations of this problem. The >> first, discovered by Dennis Ferguson, occurs when an aggregated >> forwarding address is in use. In this case, the desirability of the >> forwarding address can change for the worse as a packet crosses an >> area aggregation boundary on the way to the forwarding address, which >> in turn can cause the preference of AS-external-LSAs to change, >> resulting in a routing loop. >> >> The second manifestation was discovered by Richard Woundy. It is >> caused by an incomplete application of OSPF's preference of intra- >> area routes over inter-area routes: paths to any given >> ASBR/forwarding address are selected first based on intra-area >> preference, while the comparison between separate ASBRs/forwarding >> addresses is driven only by cost, ignoring intra-area preference. His >> example is replicated in Figure 19. Both router A3 and router B3 are >> originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 >> metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, >> based on shorter cost to ASBR B3 (via B1->B2->B3). However, the >> shorter route to B3 is not available to B1, due to B1's preference >> for the (higher cost) intra-area route to B3 through Area A. This >> leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a >> routing loop. >> >> >> >> >> Moy Standards Track [Page 207] >> >> RFC 2178 OSPF Version 2 July 1997 >> >> >> The following two changes have been made to prevent these routing >> loops: >> >> o When originating a type 3 summary-LSA for a configured area >> address range, the cost of the summary-LSA is now set to the >> maximum cost of the range's component networks (instead of the >> previous algorithm which set the cost to the minimum component >> cost). This change affects Sections 3.5 and 12.4.3, Figures 7 >> and 8, and Tables 6 and 13. >> >> o The preference rules for choosing among multiple AS- >> external-LSAs have been changed. Where previously cost was the >> only determining factor, now the preference is driven first by >> type of path (intra-area or inter-area, through non-backbone area >> or through backbone) to the ASBR/forwarding address, using cost >> only to break ties. This change affects Sections 16.4 and 16.4.1. >> >> After implementing this change, the example in Figure 19 is modified >> as follows. Router A1 now chooses A3 as the next >> >> 10.0.0.0/8 >> ---------- >> | >> +----+ >> | XX | >> +----+ >> RIP / \ RIP >> --------------------- -------------------- >> ! ! >> ! ! >> +----+ +----+ 1 +----+......+----+.... >> | A3 |------| A1 |---------------| B1 |------| B3 | . >> +----+ 6 +----+ +----+ 8 +----+ . >> 1| . / . >> OSPF backbone | . / . >> +----+ 2 / . >> | B2 |------- Area A. >> +----+................ >> >> Figure 19: Example routing loop when the >> same external route is advertised from multiple >> areas >> >> hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for >> both choices is that ASBRs/forwarding addresses are now chosen based >> first on intra-area preference, and then by cost. >> >> >> Moy Standards Track [Page 208] >> >> RFC 2178 OSPF Version 2 July 1997 >> >> >> Unfortunately, this change is not backward compatible. While the >> change prevents routing loops when all routers run the new preference >> rules, it can actually create routing loops when some routers are >> running the new preference rules and other routers implement RFC >> 1583. For this reason, a new configuration parameter has been added: >> RFC1583Compatibility. Only when RFC1583Compatibility is set to >> "disabled" will the new preference rules take effect. See Appendix C >> for more details. >> >> >> >> >> C.1 Global parameters >> >> In general, a separate copy of the OSPF protocol is run for each >> area. Because of this, most configuration parameters are defined on >> a per-area basis. The few global configuration parameters are listed >> below. >> >> [SNIP..] >> >> RFC1583Compatibility >> Controls the preference rules used in Section 16.4 when choosing >> among multiple AS-external-LSAs advertising the same destination. >> When set to "enabled", the preference rules remain those >> specified by RFC 1583 ([Ref9]). When set to "disabled", the >> preference rules are those stated in Section 16.4.1, which >> prevent routing loops when AS- external-LSAs for the same >> destination have been originated from different areas (see >> Section G.7). Set to "enabled" by default. >> >> >> In order to minimize the chance of routing loops, all OSPF >> routers in an OSPF routing domain should have >> RFC1583Compatibility set identically. When there are routers >> present that have not been updated with the functionality >> specified in Section 16.4.1 of this memo, all routers should have >> RFC1583Compatibility set to "enabled". Otherwise, all routers >> should have RFC1583Compatibility set to "disabled", preventing >> all routing loops. >> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From pmurphy@noc.usgs.net Tue Apr 17 12:30:51 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C5011E80B5 for ; Tue, 17 Apr 2012 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI9KsNVmFGiE for ; Tue, 17 Apr 2012 12:30:47 -0700 (PDT) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1D13A11E80A0 for ; Tue, 17 Apr 2012 12:30:47 -0700 (PDT) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01OEFBKLJ30000L702@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Tue, 17 Apr 2012 12:30:45 -0700 (PDT) Date: Tue, 17 Apr 2012 12:30:45 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01OEFBKLJ30200L702@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Subject: Re: [OSPF] RFC1583Compatibility X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:30:51 -0000 Faraz, You are right. It is set to enable by default. Sorry, it has been a long time since I looked at this spec. I suspect almost every RFC 2328 Internet deployment is running RFC 1583 compatibility mode. Implementations clearly provide for disabling the mode. However someone would have to know the ramifications of keeping the mode "enabled" before they would disable it. I doubt if most do. Hence the spec is stuck indefinitely. In truth, even though I knew the ramifications, I thought it was "disabled" by default. Out of curiosity I took a look at some Cisco and Juniper routers I helped deploy some time ago and noticed the cost of my original summary range aggregations appear to use the RFC 1583 MINIMUM as opposed to the RFC2328 MAXIMUM. These routers are running with the RFC1583Compatibility mode "enabled". I did not try a lab experiment to see what happens when their RFC1583Compatibility mode is "disabled". But, assuming the summary cost metric reverts to the RFC2328 MAXIMUM when the mode is "disabled", this seems contrary to the implementations you and Acee mentioned. Perhaps this RFC2328 vs RFC2178 issue needs some clarification, as you suggest. For what's its worth, with router memory so large these days, OSPF summary range aggregation has less appeal. I was surprised to find my aggregations still configured. Pat Date: Tue, 17 Apr 2012 11:25:54 -0500 From: Faraz Shamim Subject: Re: [OSPF] RFC1583Compatibility Pat, The issue is that the RFC 2328 recommends to set this parameter to "enabled" by default so this means you can not get rid of this parameter and start implementing 16.4.1 as a default in new devices or old devices with new code. Having a mix of 1583 and 2328 implementation(with respect to AS external path preference) will cause loop. There are numerous implementations that follow 2328 but when it comes to AS external path preference, they follow RFC 1583 to prevent loop. Not sure if 16.4.1 will ever see it's daylight but when it does, we can safely remove this parameter and retire 1583. Faraz On 4/17/12 10:23 AM, "Pat Murphy - (650)329-4044" wrote: >Acee, Faraz, > >It is hard to believe there are any RFC 1583 implementations still in >operation. It >is true that back when RFC 2178 (and later RFC 2328) was published, the >WG was dealing >with two real routing loop issues. However it seems academic now. Can't >RFC1583Compatibility simply be retired along with RFC 1583? > >As for John's text, > >> Unfortunately, this change is not backward compatible. While the >> change prevents routing loops when all routers run the new preference >> rules, it can actually create routing loops when some routers are >> running the new preference rules and other routers implement RFC >> 1583. For this reason, a new configuration parameter has been added: >> RFC1583Compatibility. Only when RFC1583Compatibility is set to >> "disabled" will the new preference rules take effect. See Appendix C >> for more details. > >I feel fairly confident the "new preference rules" refer to Section >16.4.1. It seems >unlikely that leaving the summary cost at MAXIMUM when >RFC1583Compatiblility is set to >"enabled" would create more routing loops. Indeed the opposite seems >true. My guess is >this omission in RFC 2328 was intentional. I did hear the discussion >about backward >compatibility and I don't remember any mention of the summary cost change. > >Pat > >> Acee, >> >> I would like to know what the rest of the OSPF WG think about this. I >>want >> to see if anyone has implemented it differently. >> >> Requesting for Comments from the rest of the community ;-) >> >> On 4/13/12 10:57 AM, "Faraz Shamim" wrote: >> >>> If you read section G.7 of RFC 2178 it appears that >>> RFC1583Compatibility would mean to apply 16.4.1 algorithm, for AS >>> external >>> if received from multiple area AND change the summary range cost to >>>pick >>> up MAXIMUM cost. But when you read C.1, under RFC1583Compatibility it >>> says that this parameter applies to AS external. No where it mentions >>> the summary cost should be changed to MINIMUM per RFC 1583. Since G.7 >>> does not even exist in RFC 2328 so whoever >>> reads RFC 2328 would always think that RFC1583Compatibility is ONLY >>> related to AS external path preference. >>> >>> Can you please confirm if RFC1583Compatibility should only affect AS >>> external path preference or should it also touch the summary cost and >>>set >>> it to MINIMUM per RFC 1583? > >I agree that RFC1583Compatibility should only affect AS external path >preference. This >is also the interpretation in my implementation and the open source >quagga >implementation. > >Thanks, >Acee > > > > > >>> >>> Thanks, >>> >>> Faraz >> >> From RFC 2178: >> >> G.7 Advertising same external route from multiple areas >> >> This document fixes routing loops which can occur in RFC 1583 when >> the same external destination is advertised by AS boundary routers in >> separate areas. There are two manifestations of this problem. The >> first, discovered by Dennis Ferguson, occurs when an aggregated >> forwarding address is in use. In this case, the desirability of the >> forwarding address can change for the worse as a packet crosses an >> area aggregation boundary on the way to the forwarding address, which >> in turn can cause the preference of AS-external-LSAs to change, >> resulting in a routing loop. >> >> The second manifestation was discovered by Richard Woundy. It is >> caused by an incomplete application of OSPF's preference of intra- >> area routes over inter-area routes: paths to any given >> ASBR/forwarding address are selected first based on intra-area >> preference, while the comparison between separate ASBRs/forwarding >> addresses is driven only by cost, ignoring intra-area preference. His >> example is replicated in Figure 19. Both router A3 and router B3 are >> originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 >> metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, >> based on shorter cost to ASBR B3 (via B1->B2->B3). However, the >> shorter route to B3 is not available to B1, due to B1's preference >> for the (higher cost) intra-area route to B3 through Area A. This >> leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a >> routing loop. >> >> >> >> >> Moy Standards Track [Page 207] >> >> RFC 2178 OSPF Version 2 July 1997 >> >> >> The following two changes have been made to prevent these routing >> loops: >> >> o When originating a type 3 summary-LSA for a configured area >> address range, the cost of the summary-LSA is now set to the >> maximum cost of the range's component networks (instead of the >> previous algorithm which set the cost to the minimum component >> cost). This change affects Sections 3.5 and 12.4.3, Figures 7 >> and 8, and Tables 6 and 13. >> >> o The preference rules for choosing among multiple AS- >> external-LSAs have been changed. Where previously cost was the >> only determining factor, now the preference is driven first by >> type of path (intra-area or inter-area, through non-backbone area >> or through backbone) to the ASBR/forwarding address, using cost >> only to break ties. This change affects Sections 16.4 and 16.4.1. >> >> After implementing this change, the example in Figure 19 is modified >> as follows. Router A1 now chooses A3 as the next >> >> 10.0.0.0/8 >> ---------- >> | >> +----+ >> | XX | >> +----+ >> RIP / \ RIP >> --------------------- -------------------- >> ! ! >> ! ! >> +----+ +----+ 1 +----+......+----+.... >> | A3 |------| A1 |---------------| B1 |------| B3 | . >> +----+ 6 +----+ +----+ 8 +----+ . >> 1| . / . >> OSPF backbone | . / . >> +----+ 2 / . >> | B2 |------- Area A. >> +----+................ >> >> Figure 19: Example routing loop when the >> same external route is advertised from multiple >> areas >> >> hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for >> both choices is that ASBRs/forwarding addresses are now chosen based >> first on intra-area preference, and then by cost. >> >> >> Moy Standards Track [Page 208] >> >> RFC 2178 OSPF Version 2 July 1997 >> >> >> Unfortunately, this change is not backward compatible. While the >> change prevents routing loops when all routers run the new preference >> rules, it can actually create routing loops when some routers are >> running the new preference rules and other routers implement RFC >> 1583. For this reason, a new configuration parameter has been added: >> RFC1583Compatibility. Only when RFC1583Compatibility is set to >> "disabled" will the new preference rules take effect. See Appendix C >> for more details. >> >> >> >> >> C.1 Global parameters >> >> In general, a separate copy of the OSPF protocol is run for each >> area. Because of this, most configuration parameters are defined on >> a per-area basis. The few global configuration parameters are listed >> below. >> >> [SNIP..] >> >> RFC1583Compatibility >> Controls the preference rules used in Section 16.4 when choosing >> among multiple AS-external-LSAs advertising the same destination. >> When set to "enabled", the preference rules remain those >> specified by RFC 1583 ([Ref9]). When set to "disabled", the >> preference rules are those stated in Section 16.4.1, which >> prevent routing loops when AS- external-LSAs for the same >> destination have been originated from different areas (see >> Section G.7). Set to "enabled" by default. >> >> >> In order to minimize the chance of routing loops, all OSPF >> routers in an OSPF routing domain should have >> RFC1583Compatibility set identically. When there are routers >> present that have not been updated with the functionality >> specified in Section 16.4.1 of this memo, all routers should have >> RFC1583Compatibility set to "enabled". Otherwise, all routers >> should have RFC1583Compatibility set to "disabled", preventing >> all routing loops. >> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From thirumavalavan.periyannan@ipinfusion.com Mon Apr 23 02:36:03 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2347E21F84D3 for ; Mon, 23 Apr 2012 02:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGlgcvshplmS for ; Mon, 23 Apr 2012 02:36:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68721F84D0 for ; Mon, 23 Apr 2012 02:36:02 -0700 (PDT) Received: from mail123-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Apr 2012 09:36:02 +0000 Received: from mail123-tx2 (localhost [127.0.0.1]) by mail123-tx2-R.bigfish.com (Postfix) with ESMTP id 44D01100414; Mon, 23 Apr 2012 09:36:01 +0000 (UTC) X-SpamScore: -16 X-BigFish: PS-16(zz9371I542M1432N98dK4015Izz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail123-tx2: domain of ipinfusion.com designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=thirumavalavan.periyannan@ipinfusion.com; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2 (MessageSwitch) id 1335173757951992_28318; Mon, 23 Apr 2012 09:35:57 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.238]) by mail123-tx2.bigfish.com (Postfix) with ESMTP id E50BB48007D; Mon, 23 Apr 2012 09:35:57 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Apr 2012 09:35:57 +0000 Received: from BL2PRD0510MB375.namprd05.prod.outlook.com ([169.254.4.185]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0143.004; Mon, 23 Apr 2012 09:35:56 +0000 From: Thirumavalavan Periyannan To: Acee Lindem Thread-Topic: OSPF hello/dead interval issue Thread-Index: Ac0hCBMg+afSO3WHQvWo3SQp/h37rgAK6UAAAAAPC8A= Date: Mon, 23 Apr 2012 09:35:55 +0000 Message-ID: <399DBD630D4CFE4CA477FE884EFCF355076016@BL2PRD0510MB375.namprd05.prod.outlook.com> References: <399DBD630D4CFE4CA477FE884EFCF355075D39@BL2PRD0510MB375.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [59.92.63.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0510HT001.namprd05.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0510HT001.namprd05.prod.outlook.com X-OriginatorOrg: ipinfusion.com Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF hello/dead interval issue X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 09:36:03 -0000 Thanks Acee. So its implementation issue. Thanks, Thiru -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Monday, April 23, 2012 3:00 PM To: Thirumavalavan Periyannan Subject: Re: OSPF hello/dead interval issue Hi Thiru, It is a proprietary option not supported by the OSPF protocol. In hello pac= kets, the hello interval is set to 0 and the dead interval is set to 1. I w= ould not support it given that BFD neighbor detection is available.=20 Acee=20 On Apr 23, 2012, at 12:21 AM, Thirumavalavan Periyannan wrote: > HI Acee, >=20 > I need some help related to OSPF hello/dead interval, >=20 > Some vendor routers allows me to configure dead interval value is less th= an hello interval. >=20 > Is it expected behavior? >=20 > Thanks, > Thiru. >=20 >=20