From acee.lindem@ericsson.com Mon Jul 2 03:12:17 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 B9D0011E8194 for ; Mon, 2 Jul 2012 03:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 wbT3rjT5vHLF for ; Mon, 2 Jul 2012 03:12:17 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2D11E8189 for ; Mon, 2 Jul 2012 03:12:17 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q62ACKfX007410 for ; Mon, 2 Jul 2012 05:12:21 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 2 Jul 2012 06:12:15 -0400 From: Acee Lindem To: OSPF List Date: Mon, 2 Jul 2012 06:12:12 -0400 Thread-Topic: OSPF WG Session Requests for Vancouver (IETF 84) Thread-Index: Ac1YOybk2ICGwpYmTSarRBvyLbSM4g== Message-ID: <21687FB2-D93D-4FA0-A64A-9B9EE36816F0@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-3--8003628"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] OSPF WG Session Requests for Vancouver (IETF 84) 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 Jul 2012 10:12:17 -0000 --Apple-Mail-3--8003628 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All, The OSPF WG will meet in Vancouver. Our session (still subject to change) is scheduled for Thursday, August 2nd, 1510-1710. Please send your session requests by July 16th, indicating: Draft name, Speaker and Desired Duration (presentation + Q&As). Thanks, Acee and Abhay --Apple-Mail-3--8003628 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwMjEwMTIxM1owIwYJKoZI hvcNAQkEMRYEFFjDwJwrONEXO2dDCzvhwm8ZK/HsMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIqAv1oPux1SnIRrnaUmlRh0dYMPvkV/k0rzjELPzlcOR0p2viUNBRsuQxTzL+QW h9O6C/gsH1Uyul6Ax8gmkSUg4TR9/S+LNTo7GCZQ5IXxq85UWZB5w+/kwSj1sGWsLKJHOG39lSXH O0C6bHkg9ApVREqgJbhDB50FNSI99YJjAAAAAAAA --Apple-Mail-3--8003628-- From alvaro.retana@hp.com Mon Jul 2 04:16:39 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 C712421F896B for ; Mon, 2 Jul 2012 04:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.156 X-Spam-Level: X-Spam-Status: No, score=-107.156 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pViuh5xqLY6l for ; Mon, 2 Jul 2012 04:16:39 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id 45A5321F8BDA for ; Mon, 2 Jul 2012 04:16:39 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id B15B8C1A2; Mon, 2 Jul 2012 11:16:43 +0000 (UTC) Received: from G2W1813G.americas.hpqcorp.net (16.238.8.212) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 2 Jul 2012 11:15:59 +0000 Received: from G1W3777.americas.hpqcorp.net ([169.254.11.42]) by G2W1813G.americas.hpqcorp.net ([fe80::2d8c:5671:edf9:26b0%12]) with mapi id 14.02.0283.003; Mon, 2 Jul 2012 11:15:59 +0000 From: "Retana, Alvaro" To: Shishio Tsuchiya , "ospf@ietf.org" Thread-Topic: I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: AQHNVg5HsUaborfKXU2QsMDIg0DSaJcSTL2AgAON5BA= Date: Mon, 2 Jul 2012 11:15:58 +0000 Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> In-Reply-To: <4FEE8683.1010706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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 Jul 2012 11:16:39 -0000 > -----Original Message----- > From: Shishio Tsuchiya [mailto:shtsuchi@cisco.com] > Sent: Saturday, June 30, 2012 12:54 AM Shishio: ... > http://tools.ietf.org/html/draft-ietf-ospf-rfc3137bis-01#section-4.1 > I think maximum both metric and R-bit should be equivalence in today > and future. > In order to avoid confusing for people,I recommend > -remove the sentence from abstract. > "However, OSPF does not specify a standard way to accomplish this." I will remove that. > -move R-bit to solution from Deployment Considerations > ex.) > 3. Proposed Solution > 3-1.maximum metric > 3-2.R-bit >=20 > What do you think of my recommendation? 3173 is about documenting the MaxLinkMetric approach, which is why we chose= to reference the R-bit as other solutions. 3137 is not about comparing or= describing the full functionality of the different approaches. Thanks! Alvaro. From acee.lindem@ericsson.com Mon Jul 2 06:56: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 3830C21F861E for ; Mon, 2 Jul 2012 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, 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 9XIe9ajAMVD1 for ; Mon, 2 Jul 2012 06:56:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6F55E21F8625 for ; Mon, 2 Jul 2012 06:56:12 -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 q62DuFE7029940; Mon, 2 Jul 2012 08:56:16 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 2 Jul 2012 09:56:09 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Mon, 2 Jul 2012 09:56:07 -0400 Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: Ac1YWm6fDGa8gsQXTzuP0mztrVAm0A== Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> In-Reply-To: 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-41-5431282"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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 Jul 2012 13:56:13 -0000 --Apple-Mail-41-5431282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alvaro,=20 On Jul 2, 2012, at 7:15 AM, Retana, Alvaro wrote: >> -----Original Message----- >> From: Shishio Tsuchiya [mailto:shtsuchi@cisco.com] >> Sent: Saturday, June 30, 2012 12:54 AM >=20 > Shishio: >=20 > ... >> http://tools.ietf.org/html/draft-ietf-ospf-rfc3137bis-01#section-4.1 >> I think maximum both metric and R-bit should be equivalence in today >> and future. >> In order to avoid confusing for people,I recommend >> -remove the sentence from abstract. >> "However, OSPF does not specify a standard way to accomplish this." >=20 > I will remove that. >=20 >> -move R-bit to solution from Deployment Considerations >> ex.) >> 3. Proposed Solution >> 3-1.maximum metric >> 3-2.R-bit >>=20 >> What do you think of my recommendation? >=20 > 3173 is about documenting the MaxLinkMetric approach, which is why we = chose to reference the R-bit as other solutions. 3137 is not about = comparing or describing the full functionality of the different = approaches. The main we respin RFCs is to incorporate changes and there is no reason = not to document the R-bit mechanism to accomplish the OSPFv3 stub router = function.=20 Thanks, Acee=20 >=20 > Thanks! >=20 > Alvaro. > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-41-5431282 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwMjEzNTYwOFowIwYJKoZI hvcNAQkEMRYEFPqOkEIrJN/Fi4Fn7VRja/Q3u3oFMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFauFDZcAbJUifOUp/tOm3uCiTckfGXRH19WpJ8FTi/iQ2m82RK4yeW6xvZZP16C PxrHjRciau8cjVLZW2WJAV0OkSpGjyFdD4tB4DJBidvlWFFmqGFtSUc5BLTxuQc662N6ux29vxeM RQ882C88W4UCUzVW3H1qm5bBA8VHnI6PAAAAAAAA --Apple-Mail-41-5431282-- From alvaro.retana@hp.com Mon Jul 2 08:06: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 5CAF221F86DC for ; Mon, 2 Jul 2012 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.311 X-Spam-Level: X-Spam-Status: No, score=-107.311 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 sEzVezyfGEUy for ; Mon, 2 Jul 2012 08:06:50 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8B56C21F86DB for ; Mon, 2 Jul 2012 08:06:50 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 8515E1C473; Mon, 2 Jul 2012 15:06:55 +0000 (UTC) Received: from G1W3627G.americas.hpqcorp.net (16.193.48.85) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 2 Jul 2012 15:05:35 +0000 Received: from G1W3777.americas.hpqcorp.net ([169.254.11.42]) by G1W3627G.americas.hpqcorp.net ([16.193.48.85]) with mapi id 14.02.0283.003; Mon, 2 Jul 2012 15:05:34 +0000 From: "Retana, Alvaro" To: Acee Lindem Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: AQHNVg5HsUaborfKXU2QsMDIg0DSaJcSTL2AgAON5BCAAC4dgIAAD8EQ Date: Mon, 2 Jul 2012 15:05:33 +0000 Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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 Jul 2012 15:06:51 -0000 Acee: > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Monday, July 02, 2012 9:56 AM ... > >> -move R-bit to solution from Deployment Considerations > >> ex.) > >> 3. Proposed Solution > >> 3-1.maximum metric > >> 3-2.R-bit > >> > >> What do you think of my recommendation? > > > > 3173 is about documenting the MaxLinkMetric approach, which is why we > chose to reference the R-bit as other solutions. 3137 is not about > comparing or describing the full functionality of the different > approaches. >=20 > The main we respin RFCs is to incorporate changes and there is no > reason not to document the R-bit mechanism to accomplish the OSPFv3 > stub router function. Besides from the reference (see below), what else do you think we should in= clude? The point I'm trying to make is: rfc5340 already defines and documents the = R-bit functionality (and it is the standard!). IMHO, there is no need to r= ehash here what is already defined and explained somewhere else...which is = why I think the reference is enough. Thanks! Alvaro. 4.1. Other Solutions This document describes a technique that has been implemented and deployed in a wide variety of networks. OSPFv3 [RFC5340] introduced additional options to provide similar, if not better, control of the forwarding topology; the R-bit and the V6-bit provide a more granular indication of whether a router is active and/or whether it should be used specifically for IPv6 traffic, respectively. It is left to network operators to decide which technique to use in their network. From acee.lindem@ericsson.com Mon Jul 2 08:29:31 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 68DEB21F86CB for ; Mon, 2 Jul 2012 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 dplxUMpeXAPX for ; Mon, 2 Jul 2012 08:29:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A221F861C for ; Mon, 2 Jul 2012 08:29:30 -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 q62FTWic017771; Mon, 2 Jul 2012 10:29:35 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 2 Jul 2012 11:29:32 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Mon, 2 Jul 2012 11:29:21 -0400 Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: Ac1YZ3o4/di48ousSnyLOVTcmmF2rw== Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> In-Reply-To: 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-6-11025589"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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 Jul 2012 15:29:31 -0000 --Apple-Mail-6-11025589 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alvaro, On Jul 2, 2012, at 11:05 AM, Retana, Alvaro wrote: > Acee: >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Monday, July 02, 2012 9:56 AM > ... >>>> -move R-bit to solution from Deployment Considerations >>>> ex.) >>>> 3. Proposed Solution >>>> 3-1.maximum metric >>>> 3-2.R-bit >>>>=20 >>>> What do you think of my recommendation? >>>=20 >>> 3173 is about documenting the MaxLinkMetric approach, which is why = we >> chose to reference the R-bit as other solutions. 3137 is not about >> comparing or describing the full functionality of the different >> approaches. >>=20 >> The main we respin RFCs is to incorporate changes and there is no >> reason not to document the R-bit mechanism to accomplish the OSPFv3 >> stub router function. >=20 > Besides from the reference (see below), what else do you think we = should include? >=20 > The point I'm trying to make is: rfc5340 already defines and documents = the R-bit functionality (and it is the standard!). IMHO, there is no = need to rehash here what is already defined and explained somewhere = else...which is why I think the reference is enough. I don't think you have to describe the mechanism. However, I agree R-bit = should be on equal ground as the max-metric links. Also, it would be = good to point out the difference in behavior. With max-metric links, = transit traffic is discouraged while with the R-bit, transit traffic is = completely suppressed.=20 Thanks,=20 Acee=20 >=20 > Thanks! >=20 > Alvaro. >=20 >=20 > 4.1. Other Solutions >=20 > This document describes a technique that has been implemented and > deployed in a wide variety of networks. OSPFv3 [RFC5340] introduced > additional options to provide similar, if not better, control of the > forwarding topology; the R-bit and the V6-bit provide a more = granular > indication of whether a router is active and/or whether it should be > used specifically for IPv6 traffic, respectively. >=20 > It is left to network operators to decide which technique to use in > their network. >=20 >=20 --Apple-Mail-6-11025589 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwMjE1MjkyMlowIwYJKoZI hvcNAQkEMRYEFMR0/3be1ZYuvVQ9YtpPXMW78d3FMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgG757wk7tKyTLMM5dnOHILarc5T7Kwbz6KIK4TTGa1Vnnm8kbEWIOLshgzPWLdxx b22ph7w+4+gT0WJ1stvkK08S9NpzsmmvOm4zlCl7xHc55+qbfB1GGhy4O/dSZ9hQzEwlVDyGqRNK rUdO9eIeUbEpocmOS2okX7LkBQoqFwEGAAAAAAAA --Apple-Mail-6-11025589-- From alvaro.retana@hp.com Mon Jul 2 09:24:10 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 309F821F873B for ; Mon, 2 Jul 2012 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.232 X-Spam-Level: X-Spam-Status: No, score=-109.232 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 MrwUxDTwhKIK for ; Mon, 2 Jul 2012 09:24:09 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 96F8921F85E5 for ; Mon, 2 Jul 2012 09:24:09 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id CE6C03844D; Mon, 2 Jul 2012 16:24:14 +0000 (UTC) Received: from G1W3625G.americas.hpqcorp.net (16.193.48.83) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 2 Jul 2012 16:23:09 +0000 Received: from G1W3777.americas.hpqcorp.net ([169.254.11.42]) by G1W3625G.americas.hpqcorp.net ([16.193.48.83]) with mapi id 14.02.0283.003; Mon, 2 Jul 2012 16:23:09 +0000 From: "Retana, Alvaro" To: Acee Lindem Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: AQHNVg5HsUaborfKXU2QsMDIg0DSaJcSTL2AgAON5BCAAC4dgIAAD8EQgAAKS4CAAArbEA== Date: Mon, 2 Jul 2012 16:23:08 +0000 Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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 Jul 2012 16:24:10 -0000 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Monday, July 02, 2012 11:29 AM ... > > Besides from the reference (see below), what else do you think we > should include? > > > > The point I'm trying to make is: rfc5340 already defines and > documents the R-bit functionality (and it is the standard!). IMHO, > there is no need to rehash here what is already defined and explained > somewhere else...which is why I think the reference is enough. >=20 > I don't think you have to describe the mechanism. However, I agree R- > bit should be on equal ground as the max-metric links. Also, it would > be good to point out the difference in behavior. With max-metric links, > transit traffic is discouraged while with the R-bit, transit traffic is > completely suppressed. Ok, I'll work on that. Alvaro. From dean.cheng@huawei.com Tue Jul 3 14:16: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 58B1511E8198 for ; Tue, 3 Jul 2012 14:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ujb6JnIJNmKB for ; Tue, 3 Jul 2012 14:16:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC17F11E8197 for ; Tue, 3 Jul 2012 14:16:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR59071; Tue, 03 Jul 2012 17:16:18 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Jul 2012 14:15:38 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Jul 2012 14:15:37 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.147]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 4 Jul 2012 05:15:30 +0800 From: Dean cheng To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst Thread-Index: Ac1WPhHoKi/atuSpQeyIAmKxUfNNkwDIkKzw Date: Tue, 3 Jul 2012 21:15:29 +0000 Message-ID: In-Reply-To: <614F31FC-7699-435F-8218-38DC10C64BFB@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.4] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F6851A3C643szxeml523mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst 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, 03 Jul 2012 21:16:13 -0000 --_000_DC7880973D477648AC15A3BA66253F6851A3C643szxeml523mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've made some editorial improvements and just posted as a -03 revision. http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-03 Comments welcome. Cheers Dean > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Friday, June 29, 2012 2:28 PM > To: OSPF List > Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf- > ipv4-embedded-ipv6-routing-02.tst > > > Speaking as WG Co-Chair, > > I'd like to WG last call this prior to Vancouver to volunteer to review > it? There hasn't been a lot of discussion after we concluded that the > translation was aligned with work in the BEHAVE WG. > Please take a look and post comments. It is not that long a draft by may > require you to at least scan RFC 6052. > > Thanks, > Acee --_000_DC7880973D477648AC15A3BA66253F6851A3C643szxeml523mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve made some editorial improvements and just posted

as a -03 revision.

 

http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-= ipv6-routing-03

 

Comments welcome.

 

Cheers

Dean

 

> -----Original Message-----

> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On= Behalf Of

> Acee Lindem

> Sent: Friday, June 29, 2012 2:28 PM

> To: OSPF List

> Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draf= t-ietf-ospf-

> ipv4-embedded-ipv6-routing-02.tst

>

>

> Speaking as WG Co-Chair,

>

> I'd like to WG last call this prior to Vancouver to volunteer to review

> it? There hasn't been a lot of discussion after we concluded t= hat the

> translation was aligned with work in the BEHAVE WG.

> Please take a look and post comments. It is not that long a dr= aft by may

> require you to at least scan RFC 6052.

>

> Thanks,

> Acee

--_000_DC7880973D477648AC15A3BA66253F6851A3C643szxeml523mbschi_-- From iesg-secretary@ietf.org Thu Jul 5 07:36:59 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 4ACC921F86A2; Thu, 5 Jul 2012 07:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4r6kshCrow2Q; Thu, 5 Jul 2012 07:36:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7863521F86B7; Thu, 5 Jul 2012 07:36:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120705143658.415.5294.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2012 07:36:58 -0700 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (OSPF Hybrid Broadcast and P2MP Interface Type) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:36:59 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPF Hybrid Broadcast and P2MP Interface Type' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as LSA database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Jul 5 08:23:01 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 BE6DE21F8702; Thu, 5 Jul 2012 08:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0AvAsX2eubxE; Thu, 5 Jul 2012 08:23:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59621F869D; Thu, 5 Jul 2012 08:23:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120705152300.7821.52582.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2012 08:23:00 -0700 Cc: ospf@ietf.org Subject: [OSPF] CORRECTED Last Call: (OSPF Hybrid Broadcast and P2MP Interface Type) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 15:23:02 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPF Hybrid Broadcast and P2MP Interface Type' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as LSA database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/ballot/ The following IPR declaration is applicable to this draft https://datatracker.ietf.org/ipr/1529/ From tanmoy.kundu@huawei.com Thu Jul 5 23:16:52 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 04A8811E80C8 for ; Thu, 5 Jul 2012 23:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.74 X-Spam-Level: X-Spam-Status: No, score=-3.74 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MSGID_MULTIPLE_AT=1.449, 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 1Dva27NmRodq for ; Thu, 5 Jul 2012 23:16:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5D39511E80CB for ; Thu, 5 Jul 2012 23:16:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHT31878; Fri, 06 Jul 2012 02:17:04 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 23:16:48 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 23:16:54 -0700 Received: from blrprnc05ns (10.18.96.94) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server id 14.1.323.3; Fri, 6 Jul 2012 14:16:46 +0800 From: Tanmoy To: 'Michael Barnes' , References: <908qFdaYu2288S03.1341017480@web03.cms.usa.net> In-Reply-To: <908qFdaYu2288S03.1341017480@web03.cms.usa.net> Date: Fri, 6 Jul 2012 11:46:45 +0530 Organization: Htipl Message-ID: <000301cd5b3e$ebf786a0$c3e693e0$@kundu@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1WWnyIBvfeJtYOTXOeT1IkufUG3gE3UEww Content-Language: en-us X-Originating-IP: [10.18.96.94] X-CFilter-Loop: Reflected Subject: Re: [OSPF] ABR/ASBR with clear R-bit? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tanmoy.kundu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 06:16:52 -0000 Hi Michael, As I understand the Motivation behind using R-Bit in router LSA in Multi-homed Hosts which just want to learn the routes by participating in routing but do not want to forward any transit traffic. However I also support your idea to use the R-bit as "... edge router with hosts attached, and the router is dual homed ...". But the question is How a router can determine whether the interface is just connected to only Hosts not any other router ? Lets consider the below topology where RTA and RTB are the router which is connected to IP network and H2-Hn are the host from a trusted/enterprise network. This would be an appropriate scenario where RTC would like to advertise its LSA with R-bit clear. +-----+ +-----+ | RTA | | RTB | +--+--+ +--+--+ | | 200::1/64 | Area 0 +-----+ | | | | 200::2/64 | (Area 2) +-----------+ RTC +-----------+ +--+--+ |3::1/64 (Area 1) | +---+---+--------+--------+ 3::2/64| 3::3/64| 3::n/64| +--+ +--+ +--+ | | | | | | +--+ +--+ +--+ H2 H3 Hn Considering above, I agree with you the RTC should advertise 3::/64 to RTA and RTB such that packet destined to the host should reach RTC and it fwd it to the host. For RTC, this as if local destined routes. But if it originates the inter-area prefixe for 200::/64, then RTA will send the 200::1 destined traffic towards RTC and it will become a transit router. - this way we will violate the RFC. So to avoid this I still, suggest to advertise only host prefixes from the interfaces. But to enable the router as " edge router with host attached, and the router is dual homed.." let the decision be on the implementation. It can either be a configuration driven to advertise such routes. Regards, - Tanmoy -----Original Message----- From: Michael Barnes [mailto:michael_barnes@usa.net] Sent: Saturday, June 30, 2012 6:21 AM To: tanmoy.kundu@huawei.com; ospf@ietf.org Subject: RE: [OSPF] ABR/ASBR with clear R-bit? Hi Tanmoy responses inline... ------ Original Message ------ Received: Thu, 17 May 2012 07:04:46 AM PDT From: Tanmoy To: ospf@ietf.orgCc: 'Michael Barnes' Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Michael, > > A couple of ideas... > > Firstly we should prevent that other routers do not use the R-bit clear > Router as transit for reaching the FA. To ensure this, the Router with R-bit > clear MUST not originate any inter-area network prefixes. It is allowed to > originate only inter-area host prefixes (128 prefix length) that correspond > to its own interface addresses. [This make sense too since this router does > not want to service transit traffic so there is no need to advertise the > attached networks]. I think the above is too restrictive and not very useful. We may as well say that the ABR with the R-bit clear MUST NOT advertise any inter-area prefixes. But I think that is not the right thing to do. Rather the ABR should be able to advertise inter-area prefixes of any length, but only for prefixes local to it (e.g. configured on its own interfaces). I think a common case for having the R-bit clear is for an edge router with hosts attached, and the router is dual homed, but should never be used for transit traffic. > Additionally : The R-bit clear ASBR can originate the AS-external route only > when there is a good chance that there is an alternate path to the FA. To do > this, the ASBR can examine the network LSA of the interface corresponding to > the FA and check that there is at least one other router with the R-bit set, > in which case the LSA can be originated. This part is fully optional and if > not followed, may result in AS-External LSAs that are not usable. Anyway, > the solution presented here is simple and not foolproof for all cases (e.g. > there is another router with the R-bit set, but it is reachable to a set of > routers in the topology only through the router with R-bit clear). More > robust but complex solutions are possible ;-) My first thought is that "a good chance that there is an alternate path to the FA" is not acceptable. Either the ASBR should be able to determine absolutely that there is an alternate path to the FA or it should not use that FA. This is not trivial in the intra-area case, and I don't think it is possible in the inter-area case. Therefor my opinion is that an ASBR should only advertise prefixes which are local to it (like the ABR). > With these restrictions/conditions, the following cases need to be examined: > > Case 1 : > R-bit Clear router is the only ABR for the other area. Based on the > restriction proposed, the R-Bit clear router will originate only directly > interface routes as Inter-area routes(with 128 prefix length). This will > ensure the other router cannot use it as a transit to reach the FA, since > the network is not visible at all. > > Case 2 : > There is another ABR in the area. In this case, since the other ABR router > will originate the inter-area route for the FA's network prefix, all routers > will consider the other router as the transit router and will calculate > reachability only through the other router. Since I do not agree with your idea to restrict the ASBR to only advertise its own /128 addresses, then case 2 will cause traffic to be black-holed. Regards, Michael > Regards, > - Tanmoy > > -----Original Message----- > From: Michael Barnes [mailto:michael_barnes@usa.net] > Sent: Tuesday, May 15, 2012 8:37 PM > To: tanmoy.kundu@huawei.com > Cc: ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > Hi Tanmoy, > > ------ Original Message ------ > Received: Mon, 14 May 2012 11:24:00 PM PDT > From: Tanmoy > To: "'Mike Dubrovskiy (mdubrovs)'" , 'Michael Barnes' > Cc: ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > > Hi Micheal/Mike, > > > > @Michael : Considering your suggestion I have one question, during SPF all > > router would add the Router with R-Bit clear as Stub node. Hence there is > no > > chance where this router being used as transit for forwarding address. > > This is true when the router is in the same area as the ASBR. However, if > the > router is in another area then it does not have a way to know if the > inter-area route transits the ASBR or is reachable through another router in > that area. > > > @Mike : we shall not consider this router to give up the ABR/ASBR status. > As > > Michael said, the router might need to advertise its own directly > connected > > routes as Inter or ASE/NSSA routes. > > > > I have one suggestion, since the Originator will know BEST about the > routes > > its originating, we shall put some restrictions there. > > Such as.. > > [1] Router with R-bit clear is allowed to originate AS-External/NSSA LSA > > for directly connected routes ONLY. > > [2] Router with R-bit clear is allowed to originate inter aera LSA to > other > > areas for the directly connected routes ONLY. > > The two above are essentially the same as what I suggested in my first > e-mail > of the thread. :-) > > > [3] For all other AS-External/NSSA destination where there is a valid > > Forwarding address can be derived, the LSA should be originated. > > All other sources MUST NOT be originated by the Router with R-Bit Clear. > > How does the ASBR know if the FA is reachable not via itself? Should it do > special type of SPF calculation to see if there is some other path? > > Thanks, > Michael > > > Thanks, > > - Tanmoy > > > > > > > > > > > > > > -----Original Message----- > > From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] > > Sent: Tuesday, May 15, 2012 5:06 AM > > To: Michael Barnes; tanmoy.kundu@huawei.com > > Cc: ospf@ietf.org > > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > > > Hi Michael, > > > > It seems that there's more than one way to skin a cat. > > > > How about this one: > > > > Router with R-bit cleared should be area internal router. > > In case if R-bit is cleared on ABR or ASBR, the router must give up the > > ABR/ASBR status. > > > > Mike > > > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > > Michael Barnes > > Sent: Monday, May 14, 2012 12:05 PM > > To: tanmoy.kundu@huawei.com > > Cc: ospf@ietf.org > > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > > > > Hi Tanmoy, > > > > I agree, this is an interesting use case. However, we must be careful to > > handle it correctly. Consider, for example, when the only path to the > > forwarding address is through the ASBR which has the R-bit cleared. > > Routers in the same area as the ASBR would be able to determine this > > without any trouble and not use the ASBR for transit. We need to > > consider that the ASBR may be advertising local routes as externals, and > > these should be reachable via the ASBR even when the R-bit is clear. If > > the forwarding address shares the same prefix, then it would also be > > reachable in this scenario. So how do other routers determine which > > external prefixes are reachable, or not, via the ASBR with the R-bit > > cleared? In particular, the routers which are in other areas? > > > > I can think of a couple of ways. A simple one would be for the ASBR to > > advertise the FA with an infinite metric. This would allow routers to > > calculate another path to the FA, if one is available, while ensuring > > the the ASBR itself would not be used as the transit to the FA. While at > > the same time allowing reachability to prefixes local to the ASBR, of > > course the local prefixes would not be advertised with the same FA. > > > > Thanks, > > Michael. From michael_barnes@usa.net Fri Jul 6 07:56:27 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 6745921F8665 for ; Fri, 6 Jul 2012 07:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_NUMERIC_HELO=2.067] 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 qS6GhWiMmsme for ; Fri, 6 Jul 2012 07:56:26 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E521F862B for ; Fri, 6 Jul 2012 07:56:26 -0700 (PDT) Received: from cmsout02.mbox.net (co02-lo [127.0.0.1]) by cmsout02.mbox.net (Postfix) with ESMTP id 2DC0313446B; Fri, 6 Jul 2012 14:56:42 +0000 (GMT) X-USANET-Received: from cmsout02.mbox.net [127.0.0.1] by cmsout02.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 083qgFo5n8464M02; Fri, 06 Jul 2012 14:56:39 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap02.cms.usa.net [165.212.11.2] by cmsout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID109qgFo5n6899X02; Fri, 06 Jul 2012 14:56:39 -0000 X-USANET-Source: 165.212.11.2 IN michael_barnes@usa.net imap02.cms.usa.net X-USANET-MsgId: XID109qgFo5n6899X02 Received: from web03.cms.usa.net [165.212.8.203] by imap02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 352qgFo5M7056M22; Fri, 06 Jul 2012 14:56:38 -0000 X-USANET-Auth: 165.212.8.203 AUTO michael_barnes@usa.net web03.cms.usa.net Received: from 198.144.206.23 [198.144.206.23] by web03.cms.usa.net (USANET web-mailer C8.MAIN.3.83I); Fri, 06 Jul 2012 14:56:38 -0000 Date: Fri, 06 Jul 2012 07:56:38 -0700 From: "Michael Barnes" To: , "'Michael Barnes'" , X-Mailer: USANET web-mailer (C8.MAIN.3.83I) Mime-Version: 1.0 Message-ID: <591qgFo4M3184S03.1341586598@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID352qgFo5M7056X22 Subject: Re: [OSPF] ABR/ASBR with clear R-bit? 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, 06 Jul 2012 14:56:27 -0000 Hi Tanmoy, I think we can say that behavior may be adjusted based on configuration, = and thus allow both scenarios to be handled appropriately. = More inline... ------ Original Message ------ Received: Thu, 05 Jul 2012 11:17:46 PM PDT From: Tanmoy To: "'Michael Barnes'" , Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > Hi Michael, = > As I understand the Motivation behind using R-Bit in router LSA in > Multi-homed Hosts which just want to learn the routes by participating = in > routing but do not want to forward any transit traffic. In this case, the device should not be either ABR or ASBR, so the problem= and would only need to advertise its own host address(es). > However I also support your idea to use the R-bit as "... edge router w= ith > hosts attached, and the router is dual homed ...". = > = > But the question is How a router can determine whether the interface is= just > connected to only Hosts not any other router ? > = > Lets consider the below topology where RTA and RTB are the router which= is > connected to IP network and H2-Hn are the host from a trusted/enterpris= e > network. = > This would be an appropriate scenario where RTC would like to advertise= its > LSA with R-bit clear. > = > +-----+ +-----+ = > | RTA | | RTB | = > +--+--+ +--+--+ = > | | 200::1/64 = > | Area 0 +-----+ | = > | | | 200::2/64 | (Area 2) > +-----------+ RTC +-----------+ = > +--+--+ = > |3::1/64 (Area 1) > | = > +---+---+--------+--------+ = > 3::2/64| 3::3/64| 3::n/64| = > +--+ +--+ +--+ = > | | | | | | = > +--+ +--+ +--+ = > H2 H3 Hn > = > Considering above, I agree with you the RTC should advertise 3::/64 to = RTA > and RTB such that packet destined to the host should reach RTC and it f= wd it > to the host. For RTC, this as if local destined routes. > But if it originates the inter-area prefixe for 200::/64, then RTA will= send > the 200::1 destined traffic towards RTC and it will become a transit router. > - this way we will violate the RFC. = True that packets from RTA would reach RTB via RTC, but only the packets = which are destined to 200::1, thus RTB in this case would be the end system. Therefor it seems to me that the RFC is not violated. > So to avoid this I still, suggest to advertise only host prefixes from = the > interfaces. = > But to enable the router as " edge router with host attached, and the router > is dual homed.." let the decision be on the implementation. It can eith= er be > a configuration driven to advertise such routes. I agree that allowing behavior to be adjusted by configuration is a good compromise. Regards, Michael > Regards, > - Tanmoy = > = > = > = > -----Original Message----- > From: Michael Barnes [mailto:michael_barnes@usa.net] = > Sent: Saturday, June 30, 2012 6:21 AM > To: tanmoy.kundu@huawei.com; ospf@ietf.org > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > = > Hi Tanmoy > = > responses inline... > = > ------ Original Message ------ > Received: Thu, 17 May 2012 07:04:46 AM PDT > From: Tanmoy > To: ospf@ietf.orgCc: 'Michael Barnes' > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > = > > Hi Michael, = > > = > > A couple of ideas... > > = > > Firstly we should prevent that other routers do not use the R-bit cle= ar > > Router as transit for reaching the FA. To ensure this, the Router wit= h > R-bit > > clear MUST not originate any inter-area network prefixes. It is allow= ed to > > originate only inter-area host prefixes (128 prefix length) that > correspond > > to its own interface addresses. [This make sense too since this route= r > does > > not want to service transit traffic so there is no need to advertise = the > > attached networks]. > = > I think the above is too restrictive and not very useful. We may as wel= l say > that the ABR with the R-bit clear MUST NOT advertise any inter-area > prefixes. > But I think that is not the right thing to do. Rather the ABR should be= able > to advertise inter-area prefixes of any length, but only for prefixes l= ocal > to > it (e.g. configured on its own interfaces). I think a common case for having > the R-bit clear is for an edge router with hosts attached, and the rout= er is > dual homed, but should never be used for transit traffic. > = > > Additionally : The R-bit clear ASBR can originate the AS-external rou= te > only > > when there is a good chance that there is an alternate path to the FA= =2E To > do > > this, the ASBR can examine the network LSA of the interface correspon= ding > to > > the FA and check that there is at least one other router with the R-b= it > set, > > in which case the LSA can be originated. This part is fully optional = and > if > > not followed, may result in AS-External LSAs that are not usable. Any= way, > > the solution presented here is simple and not foolproof for all cases= > (e.g. > > there is another router with the R-bit set, but it is reachable to a = set > of > > routers in the topology only through the router with R-bit clear). Mo= re > > robust but complex solutions are possible ;-) > = > My first thought is that "a good chance that there is an alternate path= to > the > FA" is not acceptable. Either the ASBR should be able to determine > absolutely > that there is an alternate path to the FA or it should not use that FA.= This > is not trivial in the intra-area case, and I don't think it is possible= in > the > inter-area case. Therefor my opinion is that an ASBR should only advert= ise > prefixes which are local to it (like the ABR). > = > > With these restrictions/conditions, the following cases need to be > examined: > > = > > Case 1 : = > > R-bit Clear router is the only ABR for the other area. Based on the > > restriction proposed, the R-Bit clear router will originate only dire= ctly > > interface routes as Inter-area routes(with 128 prefix length). This w= ill > > ensure the other router cannot use it as a transit to reach the FA, s= ince > > the network is not visible at all. > > = > > Case 2 : = > > There is another ABR in the area. In this case, since the other ABR router > > will originate the inter-area route for the FA's network prefix, all > routers > > will consider the other router as the transit router and will calcula= te > > reachability only through the other router. = > = > Since I do not agree with your idea to restrict the ASBR to only advert= ise > its > own /128 addresses, then case 2 will cause traffic to be black-holed. > = > Regards, > Michael > = > = > > Regards, > > - Tanmoy = > > = > > -----Original Message----- > > From: Michael Barnes [mailto:michael_barnes@usa.net] = > > Sent: Tuesday, May 15, 2012 8:37 PM > > To: tanmoy.kundu@huawei.com > > Cc: ospf@ietf.org > > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > = > > Hi Tanmoy, > > = > > ------ Original Message ------ > > Received: Mon, 14 May 2012 11:24:00 PM PDT > > From: Tanmoy > > To: "'Mike Dubrovskiy (mdubrovs)'" , 'Michael Bar= nes' > > Cc: ospf@ietf.org > > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > = > > > Hi Micheal/Mike, = > > > = > > > @Michael : Considering your suggestion I have one question, during = SPF > all > > > router would add the Router with R-Bit clear as Stub node. Hence th= ere > is > > no > > > chance where this router being used as transit for forwarding addre= ss. = > > = > > This is true when the router is in the same area as the ASBR. However= , if > > the > > router is in another area then it does not have a way to know if the > > inter-area route transits the ASBR or is reachable through another ro= uter > in > > that area. > > = > > > @Mike : we shall not consider this router to give up the ABR/ASBR > status. > > As > > > Michael said, the router might need to advertise its own directly > > connected > > > routes as Inter or ASE/NSSA routes. = > > > = > > > I have one suggestion, since the Originator will know BEST about th= e > > routes > > > its originating, we shall put some restrictions there. = > > > Such as.. > > > [1] Router with R-bit clear is allowed to originate AS-External/NS= SA > LSA > > > for directly connected routes ONLY. = > > > [2] Router with R-bit clear is allowed to originate inter aera LSA= to > > other > > > areas for the directly connected routes ONLY. = > > = > > The two above are essentially the same as what I suggested in my firs= t > > e-mail > > of the thread. :-) > > = > > > [3] For all other AS-External/NSSA destination where there is a va= lid > > > Forwarding address can be derived, the LSA should be originated. = > > > All other sources MUST NOT be originated by the Router with R-Bit Clear. > = > > = > > How does the ASBR know if the FA is reachable not via itself? Should = it do > > special type of SPF calculation to see if there is some other path? > > = > > Thanks, > > Michael > > = > > > Thanks, > > > - Tanmoy > > > = > > > = > > > = > > > = > > > = > > > = > > > -----Original Message----- > > > From: Mike Dubrovskiy (mdubrovs) [mailto:mdubrovs@cisco.com] = > > > Sent: Tuesday, May 15, 2012 5:06 AM > > > To: Michael Barnes; tanmoy.kundu@huawei.com > > > Cc: ospf@ietf.org > > > Subject: RE: [OSPF] ABR/ASBR with clear R-bit? > > > = > > > Hi Michael, > > > = > > > It seems that there's more than one way to skin a cat. > > > = > > > How about this one: > > > = > > > Router with R-bit cleared should be area internal router. > > > In case if R-bit is cleared on ABR or ASBR, the router must give up= the > > > ABR/ASBR status. > > > = > > > Mike > > > = > > > -----Original Message----- > > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behal= f Of > > > Michael Barnes > > > Sent: Monday, May 14, 2012 12:05 PM > > > To: tanmoy.kundu@huawei.com > > > Cc: ospf@ietf.org > > > Subject: Re: [OSPF] ABR/ASBR with clear R-bit? > > > = > > > Hi Tanmoy, > > > = > > > I agree, this is an interesting use case. However, we must be caref= ul to > > > handle it correctly. Consider, for example, when the only path to t= he > > > forwarding address is through the ASBR which has the R-bit cleared.= > > > Routers in the same area as the ASBR would be able to determine thi= s > > > without any trouble and not use the ASBR for transit. We need to > > > consider that the ASBR may be advertising local routes as externals= , and > > > these should be reachable via the ASBR even when the R-bit is clear= =2E If > > > the forwarding address shares the same prefix, then it would also b= e > > > reachable in this scenario. So how do other routers determine which= > > > external prefixes are reachable, or not, via the ASBR with the R-bi= t > > > cleared? In particular, the routers which are in other areas? > > > = > > > I can think of a couple of ways. A simple one would be for the ASBR= to > > > advertise the FA with an infinite metric. This would allow routers = to > > > calculate another path to the FA, if one is available, while ensuri= ng > > > the the ASBR itself would not be used as the transit to the FA. Whi= le at > > > the same time allowing reachability to prefixes local to the ASBR, = of > > > course the local prefixes would not be advertised with the same FA.= = > > > = > > > Thanks, > > > Michael. From joakim.tjernlund@transmode.se Sun Jul 8 04:06:59 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 B9B8D21F8504 for ; Sun, 8 Jul 2012 04:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, HELO_EQ_SE=0.35] 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 L-W6hMCeeEip for ; Sun, 8 Jul 2012 04:06:58 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [195.58.98.146]) by ietfa.amsl.com (Postfix) with ESMTP id BD21621F84FE for ; Sun, 8 Jul 2012 04:06:58 -0700 (PDT) Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id B94F12588EE for ; Sun, 8 Jul 2012 13:07:17 +0200 (CEST) X-KeepSent: 01AC438B:981360E6-C1257A35:003BEC04; type=4; name=$KeepSent To: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Joakim Tjernlund Date: Sun, 8 Jul 2012 13:07:15 +0200 X-MIMETrack: Serialize by Router on mail1/Transmode(Release 8.5.3FP1|March 07, 2012) at 08/07/2012 13:07:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OSPF] OSPF Hello questions 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: Sun, 08 Jul 2012 11:06:59 -0000 In RFC2328, last part of chapter 10.5 it reads: o Each Hello Packet causes the neighbor state machine to be executed with the event HelloReceived. o Then the list of neighbors contained in the Hello Packet is examined. If the router itself appears in this list, the neighbor state machine should be executed with the event 2- WayReceived. Otherwise, the neighbor state machine should be executed with the event 1-WayReceived, and the processing of the packet stops. o Next, if a change in the neighbor's Router Priority field was noted, the receiving interface's state machine is scheduled with the event NeighborChange. o If the neighbor is both declaring itself to be Designated Router (Hello Packet's Designated Router field = Neighbor IP address) and the Backup Designated Router field in the packet is equal to 0.0.0.0 and the receiving interface is in state Waiting, the receiving interface's state machine is scheduled with the event BackupSeen. Otherwise, if the neighbor is declaring itself to be Designated Router and it had not previously, or the neighbor is not declaring itself Designated Router where it had previously, the receiving interface's state machine is scheduled with the event NeighborChange. o If the neighbor is declaring itself to be Backup Designated Router (Hello Packet's Backup Designated Router field = Neighbor IP address) and the receiving interface is in state Waiting, the receiving interface's state machine is scheduled with the event BackupSeen. Otherwise, if the neighbor is declaring itself to be Backup Designated Router and it had not previously, or the neighbor is not declaring itself Backup Designated Router where it had previously, the receiving interface's state machine is scheduled with the event NeighborChange. Some questions: 1) Is it important that the above events are generated in this order? Is moving HelloReceived futher down allowed? 2) Following this list to the letter it seems that one could generate the same event several times. There could be 3 NeighborChange and 2 BackupSeen, is this the intentions or is it enough to generate each type at most once? Jocke From joakim.tjernlund@transmode.se Sun Jul 8 05:29:58 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 79C9B21F861F; Sun, 8 Jul 2012 05:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MISSING_HEADERS=1.292] 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 AdK3gujx586O; Sun, 8 Jul 2012 05:29:57 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [195.58.98.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78221F8505; Sun, 8 Jul 2012 05:29:57 -0700 (PDT) Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id 453D225894D; Sun, 8 Jul 2012 14:30:18 +0200 (CEST) In-Reply-To: References: X-KeepSent: 9967B78B:EAB787AF-C1257A35:0040F7D4; type=4; name=$KeepSent Cc: ospf@ietf.org, ospf-bounces@ietf.org X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Joakim Tjernlund Date: Sun, 8 Jul 2012 14:30:16 +0200 X-MIMETrack: Serialize by Router on mail1/Transmode(Release 8.5.3FP1|March 07, 2012) at 08/07/2012 14:30:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [OSPF] OSPF Hello questions 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: Sun, 08 Jul 2012 12:29:58 -0000 > From: Joakim Tjernlund > To: ospf@ietf.org, > Date: 2012/07/08 13:07 > Subject: [OSPF] OSPF Hello questions > Sent by: ospf-bounces@ietf.org > > > In RFC2328, last part of chapter 10.5 it reads: > > o Each Hello Packet causes the neighbor state machine to be > executed with the event HelloReceived. > > o Then the list of neighbors contained in the Hello Packet is > examined. If the router itself appears in this list, the > neighbor state machine should be executed with the event 2- > WayReceived. Otherwise, the neighbor state machine should > be executed with the event 1-WayReceived, and the processing > of the packet stops. > > o Next, if a change in the neighbor's Router Priority field > was noted, the receiving interface's state machine is > scheduled with the event NeighborChange. > > o If the neighbor is both declaring itself to be Designated > Router (Hello Packet's Designated Router field = Neighbor IP > address) and the Backup Designated Router field in the > packet is equal to 0.0.0.0 and the receiving interface is in > state Waiting, the receiving interface's state machine is > scheduled with the event BackupSeen. Otherwise, if the > neighbor is declaring itself to be Designated Router and it > had not previously, or the neighbor is not declaring itself > Designated Router where it had previously, the receiving > interface's state machine is scheduled with the event > NeighborChange. > > o If the neighbor is declaring itself to be Backup Designated > Router (Hello Packet's Backup Designated Router field = > Neighbor IP address) and the receiving interface is in state > Waiting, the receiving interface's state machine is > scheduled with the event BackupSeen. Otherwise, if the > neighbor is declaring itself to be Backup Designated Router > and it had not previously, or the neighbor is not declaring > itself Backup Designated Router where it had previously, the > receiving interface's state machine is scheduled with the > event NeighborChange. > > Some questions: > 1) Is it important that the above events are generated in this order? Is moving > HelloReceived futher down allowed? > > 2) Following this list to the letter it seems that one could generate the same > event several times. There could be 3 NeighborChange and 2 BackupSeen, is this > the intentions or is it enough to generate each type at most once? Follow up questions: 3) At what point should the hello options be saved into the internal neighbor state? 4) When should prio, DR and BDR be saved? The text mentions saving these a bit earlier but it is unclear if this should be undone when hello pkg should be stopped( see OneWayRecived for and example). From acee@lindem.com Sun Jul 8 11:40: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 7451721F85EF for ; Sun, 8 Jul 2012 11:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 d1HMx+MXJuXh for ; Sun, 8 Jul 2012 11:40:38 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4482121F8598 for ; Sun, 8 Jul 2012 11:40:38 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=QrvcLCOd c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=48vgC7mUAAAA:8 a=nUdd6ujHAAAA:8 a=wGHeqM6kv5M83-YkW7AA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Vh-BgY8JcNdqj1og:21 a=nfJnVYprk2zwBFUj:21 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:59223] helo=[192.168.1.114]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 1D/5C-28917-C34D9FF4; Sun, 08 Jul 2012 18:41:00 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Sun, 8 Jul 2012 14:40:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joakim Tjernlund X-Mailer: Apple Mail (2.1084) Cc: OSPF List Subject: Re: [OSPF] OSPF Hello questions 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: Sun, 08 Jul 2012 18:40:40 -0000 Hi Joakim, On Jul 8, 2012, at 8:30 AM, Joakim Tjernlund wrote: >> From: Joakim Tjernlund >> To: ospf@ietf.org, >> Date: 2012/07/08 13:07 >> Subject: [OSPF] OSPF Hello questions >> Sent by: ospf-bounces@ietf.org >>=20 >>=20 >> In RFC2328, last part of chapter 10.5 it reads: >>=20 >> o Each Hello Packet causes the neighbor state machine to be >> executed with the event HelloReceived. >>=20 >> o Then the list of neighbors contained in the Hello Packet = is >> examined. If the router itself appears in this list, the >> neighbor state machine should be executed with the event = 2- >> WayReceived. Otherwise, the neighbor state machine should >> be executed with the event 1-WayReceived, and the = processing >> of the packet stops. >>=20 >> o Next, if a change in the neighbor's Router Priority field >> was noted, the receiving interface's state machine is >> scheduled with the event NeighborChange. >>=20 >> o If the neighbor is both declaring itself to be Designated >> Router (Hello Packet's Designated Router field =3D = Neighbor IP >> address) and the Backup Designated Router field in the >> packet is equal to 0.0.0.0 and the receiving interface is = in >> state Waiting, the receiving interface's state machine is >> scheduled with the event BackupSeen. Otherwise, if the >> neighbor is declaring itself to be Designated Router and = it >> had not previously, or the neighbor is not declaring = itself >> Designated Router where it had previously, the receiving >> interface's state machine is scheduled with the event >> NeighborChange. >>=20 >> o If the neighbor is declaring itself to be Backup = Designated >> Router (Hello Packet's Backup Designated Router field =3D >> Neighbor IP address) and the receiving interface is in = state >> Waiting, the receiving interface's state machine is >> scheduled with the event BackupSeen. Otherwise, if the >> neighbor is declaring itself to be Backup Designated = Router >> and it had not previously, or the neighbor is not = declaring >> itself Backup Designated Router where it had previously, = the >> receiving interface's state machine is scheduled with the >> event NeighborChange. >>=20 >> Some questions: >> 1) Is it important that the above events are generated in this order? = Is moving >> HelloReceived futher down allowed? I don't see any advantage to moving it. HelloReceived is a Neighbor FSM = event and the other events are Interface FSM events. >>=20 >> 2) Following this list to the letter it seems that one could generate = the same >> event several times. There could be 3 NeighborChange and 2 = BackupSeen, is this >> the intentions or is it enough to generate each type at most once? Notice that the events are scheduled and not executed. You only need = schedule one of each type.=20 >=20 > Follow up questions: > 3) At what point should the hello options be saved into the internal = neighbor state? >=20 > 4) When should prio, DR and BDR be saved? The text mentions saving = these a bit earlier but > it is unclear if this should be undone when hello pkg should be = stopped( see OneWayRecived for > and example). This is implementation dependent but you must be able to denote = differences from the previous state. If you want to look at a good open = source reference implementation, go to: http://www.ospf.org/ Good Luck,=20 Acee=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From joakim.tjernlund@transmode.se Sun Jul 8 12:44:38 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 2872521F8668 for ; Sun, 8 Jul 2012 12:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_102=0.6] 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 4vMOtXnLDuob for ; Sun, 8 Jul 2012 12:44:37 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [195.58.98.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1051B21F865D for ; Sun, 8 Jul 2012 12:44:36 -0700 (PDT) Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id 54BF225892A; Sun, 8 Jul 2012 21:44:58 +0200 (CEST) In-Reply-To: References: X-KeepSent: FDC92C63:50C0B74F-C1257A35:006B7087; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Joakim Tjernlund Date: Sun, 8 Jul 2012 21:44:56 +0200 X-MIMETrack: Serialize by Router on mail1/Transmode(Release 8.5.3FP1|March 07, 2012) at 08/07/2012 21:44:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: OSPF List Subject: Re: [OSPF] OSPF Hello questions 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: Sun, 08 Jul 2012 19:44:38 -0000 Acee Lindem wrote on 2012/07/08 20:40:59: > > Hi Joakim, > > On Jul 8, 2012, at 8:30 AM, Joakim Tjernlund wrote: > > >> From: Joakim Tjernlund > >> To: ospf@ietf.org, > >> Date: 2012/07/08 13:07 > >> Subject: [OSPF] OSPF Hello questions > >> Sent by: ospf-bounces@ietf.org > >> > >> > >> In RFC2328, last part of chapter 10.5 it reads: > >> > >> o Each Hello Packet causes the neighbor state machine to be > >> executed with the event HelloReceived. > >> > >> o Then the list of neighbors contained in the Hello Packet is > >> examined. If the router itself appears in this list, the > >> neighbor state machine should be executed with the event 2- > >> WayReceived. Otherwise, the neighbor state machine should > >> be executed with the event 1-WayReceived, and the processing > >> of the packet stops. > >> > >> o Next, if a change in the neighbor's Router Priority field > >> was noted, the receiving interface's state machine is > >> scheduled with the event NeighborChange. > >> > >> o If the neighbor is both declaring itself to be Designated > >> Router (Hello Packet's Designated Router field = Neighbor IP > >> address) and the Backup Designated Router field in the > >> packet is equal to 0.0.0.0 and the receiving interface is in > >> state Waiting, the receiving interface's state machine is > >> scheduled with the event BackupSeen. Otherwise, if the > >> neighbor is declaring itself to be Designated Router and it > >> had not previously, or the neighbor is not declaring itself > >> Designated Router where it had previously, the receiving > >> interface's state machine is scheduled with the event > >> NeighborChange. > >> > >> o If the neighbor is declaring itself to be Backup Designated > >> Router (Hello Packet's Backup Designated Router field = > >> Neighbor IP address) and the receiving interface is in state > >> Waiting, the receiving interface's state machine is > >> scheduled with the event BackupSeen. Otherwise, if the > >> neighbor is declaring itself to be Backup Designated Router > >> and it had not previously, or the neighbor is not declaring > >> itself Backup Designated Router where it had previously, the > >> receiving interface's state machine is scheduled with the > >> event NeighborChange. > >> > >> Some questions: > >> 1) Is it important that the above events are generated in this order? Is moving > >> HelloReceived futher down allowed? > > I don't see any advantage to moving it. HelloReceived is a Neighbor FSM event and the other events are Interface FSM events. ahh, sorry I meant the Router Prio and its NeighborChange. > > >> > >> 2) Following this list to the letter it seems that one could generate the same > >> event several times. There could be 3 NeighborChange and 2 BackupSeen, is this > >> the intentions or is it enough to generate each type at most once? > > Notice that the events are scheduled and not executed. You only need schedule one of each type. Yes they are scheduled. Ok, so I only need one of NeighborChange and BackupSeen but is the order significant? Could I just always send BackupSeen(if needed) and then NeighborChange(if needed)? > > > > > Follow up questions: > > 3) At what point should the hello options be saved into the internal neighbor state? > > > > 4) When should prio, DR and BDR be saved? The text mentions saving these a bit earlier but > > it is unclear if this should be undone when hello pkg should be stopped( see OneWayRecived for > > and example). > > This is implementation dependent but you must be able to denote differences from the previous state. If you want to look at a good open source reference implementation, go to: http://www.ospf.org/ How is the first received Hello seen w.r.t changed prio, DR and BDR? Either one accepts those first values as is and consider prio, DR and BDR equal or you consider them all changed? Thanks for pointer to the reference impl. Jocke From acee@lindem.com Sun Jul 8 13:28:33 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 E161721F860D for ; Sun, 8 Jul 2012 13:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_102=0.6] 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 8Ffztez8AaUj for ; Sun, 8 Jul 2012 13:28:33 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFB721F8649 for ; Sun, 8 Jul 2012 13:28:32 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=IuCcgcDg c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=48vgC7mUAAAA:8 a=nUdd6ujHAAAA:8 a=QNAybPRv7bpnSgsBxI8A:9 a=CjuIK1q_8ugA:10 a=U-q-bRhx1rIA:10 a=lZB815dzVvQA:10 a=8qiwRfkxRm0UVeLL:21 a=jWRftxXGKCWv7QJu:21 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:60025] helo=[192.168.1.114]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 81/4C-17657-78DE9FF4; Sun, 08 Jul 2012 20:28:55 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Sun, 8 Jul 2012 16:28:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joakim Tjernlund X-Mailer: Apple Mail (2.1084) Cc: OSPF List Subject: Re: [OSPF] OSPF Hello questions 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: Sun, 08 Jul 2012 20:28:34 -0000 Hi Joakim, See inline.=20 On Jul 8, 2012, at 3:44 PM, Joakim Tjernlund wrote: > Acee Lindem wrote on 2012/07/08 20:40:59: >>=20 >> Hi Joakim, >>=20 >> On Jul 8, 2012, at 8:30 AM, Joakim Tjernlund wrote: >>=20 >>>> From: Joakim Tjernlund >>>> To: ospf@ietf.org, >>>> Date: 2012/07/08 13:07 >>>> Subject: [OSPF] OSPF Hello questions >>>> Sent by: ospf-bounces@ietf.org >>>>=20 >>>>=20 >>>> In RFC2328, last part of chapter 10.5 it reads: >>>>=20 >>>> o Each Hello Packet causes the neighbor state machine to be >>>> executed with the event HelloReceived. >>>>=20 >>>> o Then the list of neighbors contained in the Hello Packet = is >>>> examined. If the router itself appears in this list, the >>>> neighbor state machine should be executed with the event = 2- >>>> WayReceived. Otherwise, the neighbor state machine = should >>>> be executed with the event 1-WayReceived, and the = processing >>>> of the packet stops. >>>>=20 >>>> o Next, if a change in the neighbor's Router Priority field >>>> was noted, the receiving interface's state machine is >>>> scheduled with the event NeighborChange. >>>>=20 >>>> o If the neighbor is both declaring itself to be Designated >>>> Router (Hello Packet's Designated Router field =3D = Neighbor IP >>>> address) and the Backup Designated Router field in the >>>> packet is equal to 0.0.0.0 and the receiving interface is = in >>>> state Waiting, the receiving interface's state machine is >>>> scheduled with the event BackupSeen. Otherwise, if the >>>> neighbor is declaring itself to be Designated Router and = it >>>> had not previously, or the neighbor is not declaring = itself >>>> Designated Router where it had previously, the receiving >>>> interface's state machine is scheduled with the event >>>> NeighborChange. >>>>=20 >>>> o If the neighbor is declaring itself to be Backup = Designated >>>> Router (Hello Packet's Backup Designated Router field =3D >>>> Neighbor IP address) and the receiving interface is in = state >>>> Waiting, the receiving interface's state machine is >>>> scheduled with the event BackupSeen. Otherwise, if the >>>> neighbor is declaring itself to be Backup Designated = Router >>>> and it had not previously, or the neighbor is not = declaring >>>> itself Backup Designated Router where it had previously, = the >>>> receiving interface's state machine is scheduled with the >>>> event NeighborChange. >>>>=20 >>>> Some questions: >>>> 1) Is it important that the above events are generated in this = order? Is moving >>>> HelloReceived futher down allowed? >>=20 >> I don't see any advantage to moving it. HelloReceived is a Neighbor = FSM event and the other events are Interface FSM events. >=20 > ahh, sorry I meant the Router Prio and its NeighborChange. >=20 >>=20 >>>>=20 >>>> 2) Following this list to the letter it seems that one could = generate the same >>>> event several times. There could be 3 NeighborChange and 2 = BackupSeen, is this >>>> the intentions or is it enough to generate each type at most = once? >>=20 >> Notice that the events are scheduled and not executed. You only need = schedule one of each type. >=20 > Yes they are scheduled. Ok, so I only need one of NeighborChange and = BackupSeen but is the > order significant? Could I just always send BackupSeen(if needed) and = then NeighborChange(if needed)? You need to process BackupSeen first as you don't even recognize = NeighborChange in Waiting state. BackupSeen signals an end of Waiting = state prior to the wait timer expiring.=20 >=20 >>=20 >>>=20 >>> Follow up questions: >>> 3) At what point should the hello options be saved into the = internal neighbor state? >>>=20 >>> 4) When should prio, DR and BDR be saved? The text mentions saving = these a bit earlier but >>> it is unclear if this should be undone when hello pkg should be = stopped( see OneWayRecived for >>> and example). >>=20 >> This is implementation dependent but you must be able to denote = differences from the previous state. If you want to look at a good open = source reference implementation, go to: http://www.ospf.org/ >=20 > How is the first received Hello seen w.r.t changed prio, DR and BDR? = Either one accepts those first > values as is and consider prio, DR and BDR equal or you consider them = all changed? It doesn't really matter. Either the first received hello packet = includes you as a neighbor from which it has received a hello. In this = case, you have a new bi-directional neighbor and you generate a = NeighborChange event. If the first hello doesn't include you, you don't = generate the NeighborChange event. In either case, you save the values.=20= Hope this helps,=20 Acee=20 >=20 > Thanks for pointer to the reference impl. >=20 > Jocke >=20 From joakim.tjernlund@transmode.se Sun Jul 8 13:35:27 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 59E0321F86EC for ; Sun, 8 Jul 2012 13:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_102=0.6] 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 GR+p0FR3IK7x for ; Sun, 8 Jul 2012 13:35:26 -0700 (PDT) Received: from gw1.transmode.se (gw1.transmode.se [195.58.98.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2321F8692 for ; Sun, 8 Jul 2012 13:35:25 -0700 (PDT) Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id B8C6C258861; Sun, 8 Jul 2012 22:35:45 +0200 (CEST) In-Reply-To: References: X-KeepSent: A947F4D4:9B19794C-C1257A35:0070CF92; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Joakim Tjernlund Date: Sun, 8 Jul 2012 22:35:44 +0200 X-MIMETrack: Serialize by Router on mail1/Transmode(Release 8.5.3FP1|March 07, 2012) at 08/07/2012 22:35:45 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: OSPF List Subject: Re: [OSPF] OSPF Hello questions 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: Sun, 08 Jul 2012 20:35:27 -0000 Acee Lindem wrote on 2012/07/08 22:28:54: > > Hi Joakim, > See inline. > > On Jul 8, 2012, at 3:44 PM, Joakim Tjernlund wrote: > > > Acee Lindem wrote on 2012/07/08 20:40:59: > >> > >> Hi Joakim, > >> > >> On Jul 8, 2012, at 8:30 AM, Joakim Tjernlund wrote: > >> > >>>> From: Joakim Tjernlund > >>>> To: ospf@ietf.org, > >>>> Date: 2012/07/08 13:07 > >>>> Subject: [OSPF] OSPF Hello questions > >>>> Sent by: ospf-bounces@ietf.org > >>>> > >>>> > >>>> In RFC2328, last part of chapter 10.5 it reads: > >>>> > >>>> o Each Hello Packet causes the neighbor state machine to be > >>>> executed with the event HelloReceived. > >>>> > >>>> o Then the list of neighbors contained in the Hello Packet is > >>>> examined. If the router itself appears in this list, the > >>>> neighbor state machine should be executed with the event 2- > >>>> WayReceived. Otherwise, the neighbor state machine should > >>>> be executed with the event 1-WayReceived, and the processing > >>>> of the packet stops. > >>>> > >>>> o Next, if a change in the neighbor's Router Priority field > >>>> was noted, the receiving interface's state machine is > >>>> scheduled with the event NeighborChange. > >>>> > >>>> o If the neighbor is both declaring itself to be Designated > >>>> Router (Hello Packet's Designated Router field = Neighbor IP > >>>> address) and the Backup Designated Router field in the > >>>> packet is equal to 0.0.0.0 and the receiving interface is in > >>>> state Waiting, the receiving interface's state machine is > >>>> scheduled with the event BackupSeen. Otherwise, if the > >>>> neighbor is declaring itself to be Designated Router and it > >>>> had not previously, or the neighbor is not declaring itself > >>>> Designated Router where it had previously, the receiving > >>>> interface's state machine is scheduled with the event > >>>> NeighborChange. > >>>> > >>>> o If the neighbor is declaring itself to be Backup Designated > >>>> Router (Hello Packet's Backup Designated Router field = > >>>> Neighbor IP address) and the receiving interface is in state > >>>> Waiting, the receiving interface's state machine is > >>>> scheduled with the event BackupSeen. Otherwise, if the > >>>> neighbor is declaring itself to be Backup Designated Router > >>>> and it had not previously, or the neighbor is not declaring > >>>> itself Backup Designated Router where it had previously, the > >>>> receiving interface's state machine is scheduled with the > >>>> event NeighborChange. > >>>> > >>>> Some questions: > >>>> 1) Is it important that the above events are generated in this order? Is moving > >>>> HelloReceived futher down allowed? > >> > >> I don't see any advantage to moving it. HelloReceived is a Neighbor FSM event and the other events are Interface FSM events. > > > > ahh, sorry I meant the Router Prio and its NeighborChange. > > > >> > >>>> > >>>> 2) Following this list to the letter it seems that one could generate the same > >>>> event several times. There could be 3 NeighborChange and 2 BackupSeen, is this > >>>> the intentions or is it enough to generate each type at most once? > >> > >> Notice that the events are scheduled and not executed. You only need schedule one of each type. > > > > Yes they are scheduled. Ok, so I only need one of NeighborChange and BackupSeen but is the > > order significant? Could I just always send BackupSeen(if needed) and then NeighborChange(if needed)? > > You need to process BackupSeen first as you don't even recognize NeighborChange in Waiting state. BackupSeen signals an end of Waiting state prior to the wait timer expiring. Ahh, so the RFC is a bit off then as it checks prio first, now it is starting to make some sense. > > > > >> > >>> > >>> Follow up questions: > >>> 3) At what point should the hello options be saved into the internal neighbor state? > >>> > >>> 4) When should prio, DR and BDR be saved? The text mentions saving these a bit earlier but > >>> it is unclear if this should be undone when hello pkg should be stopped( see OneWayRecived for > >>> and example). > >> > >> This is implementation dependent but you must be able to denote differences from the previous state. If you want to look at a good open source reference implementation, go to: http://www.ospf.org/ > > > > How is the first received Hello seen w.r.t changed prio, DR and BDR? Either one accepts those first > > values as is and consider prio, DR and BDR equal or you consider them all changed? > > > It doesn't really matter. Either the first received hello packet includes you as a neighbor from which it has received a hello. In this case, you have a new bi-directional neighbor and you generate a NeighborChange event. If the first hello doesn't include you, you don't generate the NeighborChange event. In either case, you save the values. > > Hope this helps, Yes, it does. Thanks! Jocke From jari.arkko@piuha.net Mon Jul 9 05:48:16 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 C5E9D21F8550 for ; Mon, 9 Jul 2012 05:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 SccHRFGpi4Rh for ; Mon, 9 Jul 2012 05:48:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 550D621F851C for ; Mon, 9 Jul 2012 05:48:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9EF422CC5D; Mon, 9 Jul 2012 15:48:40 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMPx8nxau70Y; Mon, 9 Jul 2012 15:48:40 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 004ED2CC44; Mon, 9 Jul 2012 15:48:39 +0300 (EEST) Message-ID: <4FFAD327.3080300@piuha.net> Date: Mon, 09 Jul 2012 15:48:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Acee Lindem , "Retana, Alvaro" References: <310qeEVIU5616S02.1338500146@web02.cms.usa.net> <24323E1E-1D5B-4CC9-B1DD-F8FA9808DB78@ericsson.com> In-Reply-To: <24323E1E-1D5B-4CC9-B1DD-F8FA9808DB78@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt 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, 09 Jul 2012 12:48:16 -0000 FWIW, I would personally be OK without an instance ID, making it easier to add autoconfigured parts to an existing (and possibly manually configured) network. So I'm fine with option #2. Jari From jari.arkko@piuha.net Mon Jul 9 05:51: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 53EBA21F85D1 for ; Mon, 9 Jul 2012 05:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 iRxJKGhECwdP for ; Mon, 9 Jul 2012 05:51:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0E21F85C4 for ; Mon, 9 Jul 2012 05:51:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E574D2CC5D; Mon, 9 Jul 2012 15:52:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrpbPJHWgGk7; Mon, 9 Jul 2012 15:52:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id E35EF2CC44; Mon, 9 Jul 2012 15:51:59 +0300 (EEST) Message-ID: <4FFAD3EF.8010101@piuha.net> Date: Mon, 09 Jul 2012 15:51:59 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: OSPF List References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> In-Reply-To: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Benjamin Paterson \(bpaterso\)" Subject: [OSPF] new version of the OSPFv3-based prefix assignment draft 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, 09 Jul 2012 12:51:37 -0000 Hi, In addition to the pure OSPF autoconfiguration mechanism (draft-acee) we've worked on another extension that would enable automatic prefix configuration across a network of routers. We've submitted a new version of the latter draft as well. This version adds quite a bit of detail to the algorithm, describes ULA prefix generation, etc. Here's the link: http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02 Comments appreciated. There are a couple of early implementations. Jari From dean.cheng@huawei.com Mon Jul 9 08:14:01 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 B890821F86E2 for ; Mon, 9 Jul 2012 08:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YT6RpBwpl08N for ; Mon, 9 Jul 2012 08:14:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 70E7221F85E4 for ; Mon, 9 Jul 2012 08:14:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW23799; Mon, 09 Jul 2012 11:14:25 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 08:12:31 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 08:12:29 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.147]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 23:12:23 +0800 From: Dean cheng To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst Thread-Index: Ac1WPhHoKi/atuSpQeyIAmKxUfNNkwDIkKzwASEXp8A= Date: Mon, 9 Jul 2012 15:12:22 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.201] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F6851A3E32Dszxeml523mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst 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, 09 Jul 2012 15:14:01 -0000 --_000_DC7880973D477648AC15A3BA66253F6851A3E32Dszxeml523mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've received some comments and plan to post a new revision before 7/16 (the deadline). Please take a look of this draft and send us comments much appreciated. Cheers Dean ________________________________ From: Dean cheng Sent: Tuesday, July 03, 2012 2:16 PM To: 'Acee Lindem'; OSPF List Subject: RE: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-osp= f-ipv4-embedded-ipv6-routing-02.tst We've made some editorial improvements and just posted as a -03 revision. http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-03 Comments welcome. Cheers Dean > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Friday, June 29, 2012 2:28 PM > To: OSPF List > Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf- > ipv4-embedded-ipv6-routing-02.tst > > > Speaking as WG Co-Chair, > > I'd like to WG last call this prior to Vancouver to volunteer to review > it? There hasn't been a lot of discussion after we concluded that the > translation was aligned with work in the BEHAVE WG. > Please take a look and post comments. It is not that long a draft by may > require you to at least scan RFC 6052. > > Thanks, > Acee --_000_DC7880973D477648AC15A3BA66253F6851A3E32Dszxeml523mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve received some comments and= plan to post a new revision

before 7/16 (the deadline). Please tak= e a look of this draft and

send us comments much appreciated.

 

Cheers

Dean

 

From: Dean= cheng
Sent: Tuesday, July 03, 2012= 2:16 PM
To: 'Acee Lindem'; OSPF List
Subject: RE: [OSPF] Routing = for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing= -02.tst

 

We’ve made some editorial improvements and just posted

as a -03 revision.

 

http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-= ipv6-routing-03

 

Comments welcome.

 

Cheers

Dean

 

> -----Original Message-----

> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On = Behalf Of

> Acee Lindem

> Sent: Friday, June 29, 2012 2:28 PM

> To: OSPF List

> Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft= -ietf-ospf-

> ipv4-embedded-ipv6-routing-02.tst

>

>

> Speaking as WG Co-Chair,

>

> I'd like to WG last call this prior to Vancouver to volunteer to review

> it? There hasn't been a lot of discussion after we concluded t= hat the

> translation was aligned with work in the BEHAVE WG.=

> Please take a look and post comments. It is not that long a dr= aft by may

> require you to at least scan RFC 6052.

>

> Thanks,

> Acee

--_000_DC7880973D477648AC15A3BA66253F6851A3E32Dszxeml523mbschi_-- From acee.lindem@ericsson.com Mon Jul 9 08:40:47 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 174FD11E80E1 for ; Mon, 9 Jul 2012 08:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3JMlUYa06dq3 for ; Mon, 9 Jul 2012 08:40:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD4411E80D2 for ; Mon, 9 Jul 2012 08:40:46 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q69Ff2R1009876; Mon, 9 Jul 2012 10:41:08 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.205]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 9 Jul 2012 11:41:07 -0400 From: Acee Lindem To: Dean cheng Date: Mon, 9 Jul 2012 11:41:04 -0400 Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst Thread-Index: Ac1d6UGZ8N2VvsrdTtK8K/K7Qm3MFw== Message-ID: <8C713700-DB78-442F-96C7-A07CEE385752@ericsson.com> References: In-Reply-To: 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-105-616528491"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: OSPF List Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst 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, 09 Jul 2012 15:40:47 -0000 --Apple-Mail-105-616528491 Content-Type: multipart/alternative; boundary=Apple-Mail-104-616528476 --Apple-Mail-104-616528476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed the subject draft and would encourage others to review = it as well. We want to WG last call the -04 version which will be posted = prior to the deadline.=20 Thanks, Acee=20 On Jul 9, 2012, at 11:12 AM, Dean cheng wrote: > We=92ve received some comments and plan to post a new revision > before 7/16 (the deadline). Please take a look of this draft and > send us comments much appreciated. > =20 > Cheers > Dean > =20 > From: Dean cheng=20 > Sent: Tuesday, July 03, 2012 2:16 PM > To: 'Acee Lindem'; OSPF List > Subject: RE: [OSPF] Routing for IPv4-embedded IPv6 Packets - = draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst > =20 > We=92ve made some editorial improvements and just posted > as a -03 revision. > =20 > = http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-03 > =20 > Comments welcome. > =20 > Cheers > Dean > =20 > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of > > Acee Lindem > > Sent: Friday, June 29, 2012 2:28 PM > > To: OSPF List > > Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - = draft-ietf-ospf- > > ipv4-embedded-ipv6-routing-02.tst > > > > > > Speaking as WG Co-Chair, > > > > I'd like to WG last call this prior to Vancouver to volunteer to = review > > it? There hasn't been a lot of discussion after we concluded that = the > > translation was aligned with work in the BEHAVE WG. > > Please take a look and post comments. It is not that long a draft by = may > > require you to at least scan RFC 6052. > > > > Thanks, > > Acee --Apple-Mail-104-616528476 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = have reviewed the subject draft and would encourage others to review it = as well. We want to WG last call the -04 version which will be posted = prior to the = deadline. 
Thanks,
Acee 
On Jul 9, = 2012, at 11:12 AM, Dean cheng wrote:

We=92ve received some comments and = plan to post a new revision

before 7/16 (the deadline). Please = take a look of this draft and

send us comments much = appreciated.

 

Cheers

Dean

 

From: Dean cheng
Sent: Tuesday, July 03, = 2012 2:16 PM
To: 'Acee Lindem'; = OSPF List
Subject: RE: [OSPF] = Routing for IPv4-embedded IPv6 Packets - = draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst=

 

We=92ve made some editorial improvements and just = posted

as a -03 revision.

 

http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-rout= ing-03

 

Comments welcome.

 

Cheers

Dean

 

> -----Original Message-----

> From: ospf-bounces@ietf.org = [mailto:ospf-bounces@ietf.org] On Behalf = Of

> Acee Lindem

> Sent: Friday, June 29, 2012 2:28 = PM

> To: OSPF = List

> Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - = draft-ietf-ospf-

> = ipv4-embedded-ipv6-routing-02.tst

>

>

> Speaking as WG Co-Chair,

>

> I'd like to WG last call this prior to Vancouver to volunteer to = review

> it? There hasn't been a lot of discussion after we = concluded that the

> translation was aligned with work in the BEHAVE = WG.

> Please take a look and post comments. It is not that long a = draft by may

> require you to at least scan RFC = 6052.

>

> Thanks,

> Acee

=

=
= --Apple-Mail-104-616528476-- --Apple-Mail-105-616528491 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwOTE1NDEwNVowIwYJKoZI hvcNAQkEMRYEFHy+X593he1fAKkN7RrFCn3d088SMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgGKPYmdV+9yuo8rB22FON7frgo5MiNSdqhrCAZixwtYrMI3jAWFHIKEMKpwrpBIV ZAdRWLkBopj5vWI/dd6y0XHaelGwbeusgIYCg0GaGBvAIEiuju7ymzfMlTi2uZcFaGIURFPga6D7 sQ8kxMnrKRjYNYuSlsg21xxs0Jx5/9TdAAAAAAAA --Apple-Mail-105-616528491-- From alvaro.retana@hp.com Tue Jul 10 07:49:10 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 E6F5421F86DC for ; Tue, 10 Jul 2012 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.407 X-Spam-Level: X-Spam-Status: No, score=-109.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 81Zkw7BkpqAy for ; Tue, 10 Jul 2012 07:49:10 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4025021F86D7 for ; Tue, 10 Jul 2012 07:49:10 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id C22753817F; Tue, 10 Jul 2012 14:49:37 +0000 (UTC) Received: from G1W4243G.americas.hpqcorp.net (16.193.104.156) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 10 Jul 2012 14:48:41 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.17]) by G1W4243G.americas.hpqcorp.net ([16.193.104.156]) with mapi id 14.02.0283.003; Tue, 10 Jul 2012 14:48:41 +0000 From: "Retana, Alvaro" To: Acee Lindem Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: AQHNVg5HsUaborfKXU2QsMDIg0DSaJcSTL2AgAON5BCAAC4dgIAAD8EQgAAKS4CAAArbEIAMex5w Date: Tue, 10 Jul 2012 14:48:40 +0000 Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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, 10 Jul 2012 14:49:11 -0000 Hi! Before I publish an update I want to make sure that we're covering what you= want covered. I pasted below the relevant sections. Note that the new sections are 3.1 a= nd the second paragraph in Section 5. Thanks! Alvaro. ... 3. Solutions The solution introduced in this document solves two challenges associated with the outlined problem. In the description below, router X is the router announcing itself as a stub. 1) Making other routers prefer routes around router X while performing the Dijkstra calculation. 2) Allowing other routers to reach IP prefixes directly connected to router X. Note that it would be easy to address issue 1) alone by just flushing router X's router-LSA from the domain. However, it does not solve problem 2), since other routers will not be able to use links to router X in Dijkstra (no back link), and because router X will not have links to its neighbors. To address both problems, router X announces its router-LSA to the neighbors with the costs of all non-stub links (links of the types other than 3) set to MaxLinkMetric. The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 3.1. OSPFv3-only Solution OSPFv3 [RFC5340] introduced additional options to provide similar, if not better, control of the forwarding topology; the R-bit and the V6- bit provide a more granular indication of whether a router is active and/or whether it should be used specifically for IPv6 traffic, respectively. It is left to network operators to decide which technique to use in their network. 4. Maximum Link Metric ... 5. Deployment Considerations When using MaxLinkMetric, some inconsistency may be seen if the network is constructed of routers that perform intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have a MaxLinkMetric cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with MaxLinkMetric cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path. On the other hand, clearing the R-bit/V6-bit will consistently result in the router not being used as transit and/or specifically for IPv6 traffic, respectively. > -----Original Message----- > From: Retana, Alvaro > Sent: Monday, July 02, 2012 12:23 PM > To: 'Acee Lindem' > Cc: Shishio Tsuchiya; ospf@ietf.org > Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >=20 > > -----Original Message----- > > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > > Sent: Monday, July 02, 2012 11:29 AM > ... > > > Besides from the reference (see below), what else do you think we > > should include? > > > > > > The point I'm trying to make is: rfc5340 already defines and > > documents the R-bit functionality (and it is the standard!). IMHO, > > there is no need to rehash here what is already defined and explained > > somewhere else...which is why I think the reference is enough. > > > > I don't think you have to describe the mechanism. However, I agree R- > > bit should be on equal ground as the max-metric links. Also, it would > > be good to point out the difference in behavior. With max-metric > links, > > transit traffic is discouraged while with the R-bit, transit traffic > is > > completely suppressed. >=20 > Ok, I'll work on that. >=20 > Alvaro. From acee.lindem@ericsson.com Tue Jul 10 11:30:35 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 A0FB911E80A5 for ; Tue, 10 Jul 2012 11:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 pq0Md-k-Lqxs for ; Tue, 10 Jul 2012 11:30:34 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A149811E809C for ; Tue, 10 Jul 2012 11:30:32 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6AIUtd2014547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jul 2012 13:31:00 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.205]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 10 Jul 2012 14:30:36 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Tue, 10 Jul 2012 14:30:33 -0400 Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: Ac1eyhiLxBTYT2hJTKaFY3V8fYNPSg== Message-ID: <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> In-Reply-To: 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-1-713097429"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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, 10 Jul 2012 18:30:35 -0000 --Apple-Mail-1-713097429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alvaro,=20 I agree with the scope of the changes but I wouldn't mention the V6-bit = since it really doesn't satisfy the stub router requirements. Actually, = the only use case I can imagine for the V6-bit is to snoop the OSPFv3 = topology but not be reachable throughout the OSPFv3 routing domain. I'm = not sure what the original authors envisioned but I suspect they thought = it might help in supporting other address families. Anyway, If you only = consider the R-bit, it both satisfies the stub router requirements and = simplifies the text: OSPFv3 [RFC5340] introduced additional options to provide similar, if not better, control of the forwarding topology; the R-bit provides=20 a more granular indication of whether an OSPFv3 router should be used for transit traffic.=20 =20 On the other hand, clearing the R-bit will consistently result in the router not being used for IPv6 transit traffic.=20 Do you agree? Any opinions from others?=20 Thanks, Acee =20 On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: > Hi! >=20 > Before I publish an update I want to make sure that we're covering = what you want covered. >=20 > I pasted below the relevant sections. Note that the new sections are = 3.1 and the second paragraph in Section 5. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 > ... > 3. Solutions >=20 > The solution introduced in this document solves two challenges > associated with the outlined problem. In the description below, > router X is the router announcing itself as a stub. >=20 > 1) Making other routers prefer routes around router X while > performing the Dijkstra calculation. >=20 > 2) Allowing other routers to reach IP prefixes directly connected = to > router X. >=20 > Note that it would be easy to address issue 1) alone by just = flushing > router X's router-LSA from the domain. However, it does not solve > problem 2), since other routers will not be able to use links to > router X in Dijkstra (no back link), and because router X will not > have links to its neighbors. >=20 > To address both problems, router X announces its router-LSA to the > neighbors with the costs of all non-stub links (links of the types > other than 3) set to MaxLinkMetric. >=20 > The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 > [RFC5340]. >=20 > 3.1. OSPFv3-only Solution >=20 > OSPFv3 [RFC5340] introduced additional options to provide similar, = if > not better, control of the forwarding topology; the R-bit and the = V6- > bit provide a more granular indication of whether a router is active > and/or whether it should be used specifically for IPv6 traffic, > respectively. >=20 > It is left to network operators to decide which technique to use in > their network. >=20 >=20 > 4. Maximum Link Metric >=20 > ... >=20 > 5. Deployment Considerations >=20 > When using MaxLinkMetric, some inconsistency may be seen if the > network is constructed of routers that perform intra-area Dijkstra > calculation as specified in [RFC1247] (discarding link records in > router-LSAs that have a MaxLinkMetric cost value) and routers that > perform it as specified in [RFC1583] and higher (do not treat links > with MaxLinkMetric cost as unreachable). Note that this > inconsistency will not lead to routing loops, because if there are > some alternate paths in the network, both types of routers will = agree > on using them rather than the path through the stub router. If the > path through the stub router is the only one, the routers of the > first type will not use the stub router for transit (which is the > desired behavior), while the routers of the second type will still > use this path. >=20 > On the other hand, clearing the R-bit/V6-bit will consistently = result > in the router not being used as transit and/or specifically for IPv6 > traffic, respectively. >=20 >=20 >> -----Original Message----- >> From: Retana, Alvaro >> Sent: Monday, July 02, 2012 12:23 PM >> To: 'Acee Lindem' >> Cc: Shishio Tsuchiya; ospf@ietf.org >> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>=20 >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Monday, July 02, 2012 11:29 AM >> ... >>>> Besides from the reference (see below), what else do you think we >>> should include? >>>>=20 >>>> The point I'm trying to make is: rfc5340 already defines and >>> documents the R-bit functionality (and it is the standard!). IMHO, >>> there is no need to rehash here what is already defined and = explained >>> somewhere else...which is why I think the reference is enough. >>>=20 >>> I don't think you have to describe the mechanism. However, I agree = R- >>> bit should be on equal ground as the max-metric links. Also, it = would >>> be good to point out the difference in behavior. With max-metric >> links, >>> transit traffic is discouraged while with the R-bit, transit traffic >> is >>> completely suppressed. >>=20 >> Ok, I'll work on that. >>=20 >> Alvaro. >=20 --Apple-Mail-1-713097429 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMDE4MzAzNFowIwYJKoZI hvcNAQkEMRYEFP3JiA0OEeBq8leUXsfyTB2ZJ59YMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgAV/ucwzHZBQsnieRuufv3qnUgfN5XlVbXur4IIInvVo2KpGGjz3uhjKElkV1IiQ LIxEwH/sVDVvQbIdSrbL655NLVPZ9ccf+0nFZb0QO3kuaZLAUvzf2sCrzZ4cY6ZyBgAMs04s2Unc 5PnJMwd1EgorpbtRWF3hzp3Jbwb7oAxuAAAAAAAA --Apple-Mail-1-713097429-- From alvaro.retana@hp.com Tue Jul 10 12:36:47 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 8DC9211E80FB for ; Tue, 10 Jul 2012 12:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.577 X-Spam-Level: X-Spam-Status: No, score=-107.577 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 sdBAfWDGwr9v for ; Tue, 10 Jul 2012 12:36:45 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id D2D2B11E80D9 for ; Tue, 10 Jul 2012 12:36:44 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 5D3A4C5F8; Tue, 10 Jul 2012 19:37:10 +0000 (UTC) Received: from G2W2446.americas.hpqcorp.net ([169.254.7.17]) by G1W3635G.americas.hpqcorp.net ([16.193.48.86]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 19:36:02 +0000 From: "Retana, Alvaro" To: Acee Lindem Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: AQHNVg5HsUaborfKXU2QsMDIg0DSaJcSTL2AgAON5BCAAC4dgIAAD8EQgAAKS4CAAArbEIAMex5wgAA/ToCAABHOkA== Date: Tue, 10 Jul 2012 19:36:02 +0000 Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> In-Reply-To: <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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, 10 Jul 2012 19:36:47 -0000 Acee: Your point is that because the V6-bit only stops IPv6 traffic, and it doesn= 't make the whole router a stub, then we shouldn't mention it here. Sure, = that sounds reasonable. Alvaro. > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Tuesday, July 10, 2012 2:31 PM > To: Retana, Alvaro > Cc: Shishio Tsuchiya; ospf@ietf.org > Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >=20 > Hi Alvaro, > I agree with the scope of the changes but I wouldn't mention the V6-bit > since it really doesn't satisfy the stub router requirements. Actually, > the only use case I can imagine for the V6-bit is to snoop the OSPFv3 > topology but not be reachable throughout the OSPFv3 routing domain. I'm > not sure what the original authors envisioned but I suspect they > thought it might help in supporting other address families. Anyway, If > you only consider the R-bit, it both satisfies the stub router > requirements and simplifies the text: >=20 > OSPFv3 [RFC5340] introduced additional options to provide similar, if > not better, control of the forwarding topology; the R-bit provides > a more granular indication of whether an OSPFv3 router should be > used for transit traffic. >=20 > On the other hand, clearing the R-bit will consistently result > in the router not being used for IPv6 transit traffic. >=20 > Do you agree? Any opinions from others? >=20 > Thanks, > Acee >=20 > On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: >=20 > > Hi! > > > > Before I publish an update I want to make sure that we're covering > what you want covered. > > > > I pasted below the relevant sections. Note that the new sections are > 3.1 and the second paragraph in Section 5. > > > > Thanks! > > > > Alvaro. > > > > > > ... > > 3. Solutions > > > > The solution introduced in this document solves two challenges > > associated with the outlined problem. In the description below, > > router X is the router announcing itself as a stub. > > > > 1) Making other routers prefer routes around router X while > > performing the Dijkstra calculation. > > > > 2) Allowing other routers to reach IP prefixes directly connected > to > > router X. > > > > Note that it would be easy to address issue 1) alone by just > flushing > > router X's router-LSA from the domain. However, it does not solve > > problem 2), since other routers will not be able to use links to > > router X in Dijkstra (no back link), and because router X will not > > have links to its neighbors. > > > > To address both problems, router X announces its router-LSA to the > > neighbors with the costs of all non-stub links (links of the types > > other than 3) set to MaxLinkMetric. > > > > The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 > > [RFC5340]. > > > > 3.1. OSPFv3-only Solution > > > > OSPFv3 [RFC5340] introduced additional options to provide similar, > if > > not better, control of the forwarding topology; the R-bit and the > V6- > > bit provide a more granular indication of whether a router is > active > > and/or whether it should be used specifically for IPv6 traffic, > > respectively. > > > > It is left to network operators to decide which technique to use in > > their network. > > > > > > 4. Maximum Link Metric > > > > ... > > > > 5. Deployment Considerations > > > > When using MaxLinkMetric, some inconsistency may be seen if the > > network is constructed of routers that perform intra-area Dijkstra > > calculation as specified in [RFC1247] (discarding link records in > > router-LSAs that have a MaxLinkMetric cost value) and routers that > > perform it as specified in [RFC1583] and higher (do not treat links > > with MaxLinkMetric cost as unreachable). Note that this > > inconsistency will not lead to routing loops, because if there are > > some alternate paths in the network, both types of routers will > agree > > on using them rather than the path through the stub router. If the > > path through the stub router is the only one, the routers of the > > first type will not use the stub router for transit (which is the > > desired behavior), while the routers of the second type will still > > use this path. > > > > On the other hand, clearing the R-bit/V6-bit will consistently > result > > in the router not being used as transit and/or specifically for > IPv6 > > traffic, respectively. > > > > > >> -----Original Message----- > >> From: Retana, Alvaro > >> Sent: Monday, July 02, 2012 12:23 PM > >> To: 'Acee Lindem' > >> Cc: Shishio Tsuchiya; ospf@ietf.org > >> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt > >> > >>> -----Original Message----- > >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >>> Sent: Monday, July 02, 2012 11:29 AM > >> ... > >>>> Besides from the reference (see below), what else do you think we > >>> should include? > >>>> > >>>> The point I'm trying to make is: rfc5340 already defines and > >>> documents the R-bit functionality (and it is the standard!). IMHO, > >>> there is no need to rehash here what is already defined and > explained > >>> somewhere else...which is why I think the reference is enough. > >>> > >>> I don't think you have to describe the mechanism. However, I agree > R- > >>> bit should be on equal ground as the max-metric links. Also, it > would > >>> be good to point out the difference in behavior. With max-metric > >> links, > >>> transit traffic is discouraged while with the R-bit, transit > traffic > >> is > >>> completely suppressed. > >> > >> Ok, I'll work on that. > >> > >> Alvaro. > > From acee.lindem@ericsson.com Tue Jul 10 12:47:11 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 5A55A11E8135 for ; Tue, 10 Jul 2012 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 SLugF1CupEkF for ; Tue, 10 Jul 2012 12:47:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8094811E8132 for ; Tue, 10 Jul 2012 12:47:10 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6AJlWIK003704; Tue, 10 Jul 2012 14:47:38 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.205]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 10 Jul 2012 15:47:37 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Tue, 10 Jul 2012 15:47:34 -0400 Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: Ac1e1NtGt5zz0bDNQ7ez454vJsWsFw== Message-ID: <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> In-Reply-To: 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-127-717718081"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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, 10 Jul 2012 19:47:11 -0000 --Apple-Mail-127-717718081 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alvaro,=20 On Jul 10, 2012, at 3:36 PM, Retana, Alvaro wrote: > Acee: >=20 > Your point is that because the V6-bit only stops IPv6 traffic, and it = doesn't make the whole router a stub, then we shouldn't mention it here. = Sure, that sounds reasonable. That and, more importantly, one would want an OSPF stub router's local = interfaces (especially loopbacks) to be reachable for I-BGP and targeted = LDP.=20 Thanks, Acee=20 >=20 > Alvaro. >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Tuesday, July 10, 2012 2:31 PM >> To: Retana, Alvaro >> Cc: Shishio Tsuchiya; ospf@ietf.org >> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>=20 >> Hi Alvaro, >> I agree with the scope of the changes but I wouldn't mention the = V6-bit >> since it really doesn't satisfy the stub router requirements. = Actually, >> the only use case I can imagine for the V6-bit is to snoop the OSPFv3 >> topology but not be reachable throughout the OSPFv3 routing domain. = I'm >> not sure what the original authors envisioned but I suspect they >> thought it might help in supporting other address families. Anyway, = If >> you only consider the R-bit, it both satisfies the stub router >> requirements and simplifies the text: >>=20 >> OSPFv3 [RFC5340] introduced additional options to provide similar, = if >> not better, control of the forwarding topology; the R-bit provides >> a more granular indication of whether an OSPFv3 router should be >> used for transit traffic. >>=20 >> On the other hand, clearing the R-bit will consistently result >> in the router not being used for IPv6 transit traffic. >>=20 >> Do you agree? Any opinions from others? >>=20 >> Thanks, >> Acee >>=20 >> On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: >>=20 >>> Hi! >>>=20 >>> Before I publish an update I want to make sure that we're covering >> what you want covered. >>>=20 >>> I pasted below the relevant sections. Note that the new sections = are >> 3.1 and the second paragraph in Section 5. >>>=20 >>> Thanks! >>>=20 >>> Alvaro. >>>=20 >>>=20 >>> ... >>> 3. Solutions >>>=20 >>> The solution introduced in this document solves two challenges >>> associated with the outlined problem. In the description below, >>> router X is the router announcing itself as a stub. >>>=20 >>> 1) Making other routers prefer routes around router X while >>> performing the Dijkstra calculation. >>>=20 >>> 2) Allowing other routers to reach IP prefixes directly connected >> to >>> router X. >>>=20 >>> Note that it would be easy to address issue 1) alone by just >> flushing >>> router X's router-LSA from the domain. However, it does not solve >>> problem 2), since other routers will not be able to use links to >>> router X in Dijkstra (no back link), and because router X will not >>> have links to its neighbors. >>>=20 >>> To address both problems, router X announces its router-LSA to the >>> neighbors with the costs of all non-stub links (links of the types >>> other than 3) set to MaxLinkMetric. >>>=20 >>> The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 >>> [RFC5340]. >>>=20 >>> 3.1. OSPFv3-only Solution >>>=20 >>> OSPFv3 [RFC5340] introduced additional options to provide similar, >> if >>> not better, control of the forwarding topology; the R-bit and the >> V6- >>> bit provide a more granular indication of whether a router is >> active >>> and/or whether it should be used specifically for IPv6 traffic, >>> respectively. >>>=20 >>> It is left to network operators to decide which technique to use in >>> their network. >>>=20 >>>=20 >>> 4. Maximum Link Metric >>>=20 >>> ... >>>=20 >>> 5. Deployment Considerations >>>=20 >>> When using MaxLinkMetric, some inconsistency may be seen if the >>> network is constructed of routers that perform intra-area Dijkstra >>> calculation as specified in [RFC1247] (discarding link records in >>> router-LSAs that have a MaxLinkMetric cost value) and routers that >>> perform it as specified in [RFC1583] and higher (do not treat links >>> with MaxLinkMetric cost as unreachable). Note that this >>> inconsistency will not lead to routing loops, because if there are >>> some alternate paths in the network, both types of routers will >> agree >>> on using them rather than the path through the stub router. If the >>> path through the stub router is the only one, the routers of the >>> first type will not use the stub router for transit (which is the >>> desired behavior), while the routers of the second type will still >>> use this path. >>>=20 >>> On the other hand, clearing the R-bit/V6-bit will consistently >> result >>> in the router not being used as transit and/or specifically for >> IPv6 >>> traffic, respectively. >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Retana, Alvaro >>>> Sent: Monday, July 02, 2012 12:23 PM >>>> To: 'Acee Lindem' >>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>=20 >>>>> -----Original Message----- >>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>> Sent: Monday, July 02, 2012 11:29 AM >>>> ... >>>>>> Besides from the reference (see below), what else do you think we >>>>> should include? >>>>>>=20 >>>>>> The point I'm trying to make is: rfc5340 already defines and >>>>> documents the R-bit functionality (and it is the standard!). = IMHO, >>>>> there is no need to rehash here what is already defined and >> explained >>>>> somewhere else...which is why I think the reference is enough. >>>>>=20 >>>>> I don't think you have to describe the mechanism. However, I agree >> R- >>>>> bit should be on equal ground as the max-metric links. Also, it >> would >>>>> be good to point out the difference in behavior. With max-metric >>>> links, >>>>> transit traffic is discouraged while with the R-bit, transit >> traffic >>>> is >>>>> completely suppressed. >>>>=20 >>>> Ok, I'll work on that. >>>>=20 >>>> Alvaro. >>>=20 >=20 --Apple-Mail-127-717718081 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMDE5NDczNFowIwYJKoZI hvcNAQkEMRYEFMk/onCa/XnGTMp5+51sYdnq4bVDMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgHpmJHTZIqrgIOzqPa9ORBqPOWvkQdTxTCCTrihhFWcmztXlQXBuivZJYhkNx5cz QUO84eUKqVwS/XMoAgx9dmpL/Us0b9pWcSYuhQbofkFu3tdGGp8t/V51N9udlBelYjpG5sBHYPB6 l19NJNjZIgEi2RYWeyKkCuVaxhzMalUbAAAAAAAA --Apple-Mail-127-717718081-- From shtsuchi@cisco.com Wed Jul 11 02:58:27 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 24DF521F852E for ; Wed, 11 Jul 2012 02:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 Q1N5+I-SlJo3 for ; Wed, 11 Jul 2012 02:58:26 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9114E21F8513 for ; Wed, 11 Jul 2012 02:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=7123; q=dns/txt; s=iport; t=1342000735; x=1343210335; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FYLoMNxIAzIaAnBUlN8z4GBJUbrG37XooSfc4nl54PI=; b=JW+7Ha9sTY1GJtCMjr2jYLdB/5QXNwS5H3qIaQTfV6l0kiElK9+bTERC OYizLcOqNWN+e2X5WwNwlmtctsawDXCLSUn57LKtxMSjwqHFjV6BBHLrP 3URTQQ/0oQNRW9Zpdr5xLt3tUDm4pkZJWik/KvXeL/oaB4dvBuXS4PiHW 0=; X-IronPort-AV: E=Sophos;i="4.77,567,1336348800"; d="scan'208";a="14939381" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 11 Jul 2012 09:58:52 +0000 Received: from [10.70.231.72] (tky-vpn-client-231-72.cisco.com [10.70.231.72]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6B9wpBI007038; Wed, 11 Jul 2012 09:58:51 GMT Message-ID: <4FFD4E5A.70201@cisco.com> Date: Wed, 11 Jul 2012 18:58:50 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: acee.lindem@ericsson.com, alvaro.retana@hp.com References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> In-Reply-To: <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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: Wed, 11 Jul 2012 09:58:27 -0000 Alvaro,Acee I think the change is very good. And I have some comments. I agree with Acee's point about applicability of max-mum metric. 1.Max-metric applicability is very large. -After RFC3137 was published,it used on RFC5443 and RFC6138.(LDP-SYNC) -Most of operator are using max-metric to wait for BGP startup. -Some operators using max-metric for traffic control. It might be better if the draft mentions the applicability. Of course I know the motivation is including these descriptions. But it would be more clear. 2.R-bit I thought R-bit and v6 bit are better than maximum-metric on RFC5838 environment. +-->eBGP(v4) R1--RFC5838--R2---+ +-->eBGP(v6) It is easy to control. I would appreciate any comments. Regards, (2012/07/11 4:47), Acee Lindem wrote: > Hi Alvaro, > > On Jul 10, 2012, at 3:36 PM, Retana, Alvaro wrote: > >> Acee: >> >> Your point is that because the V6-bit only stops IPv6 traffic, and it doesn't make the whole router a stub, then we shouldn't mention it here. Sure, that sounds reasonable. > > That and, more importantly, one would want an OSPF stub router's local interfaces (especially loopbacks) to be reachable for I-BGP and targeted LDP. > > Thanks, > Acee > > >> >> Alvaro. >> >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Tuesday, July 10, 2012 2:31 PM >>> To: Retana, Alvaro >>> Cc: Shishio Tsuchiya; ospf@ietf.org >>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>> >>> Hi Alvaro, >>> I agree with the scope of the changes but I wouldn't mention the V6-bit >>> since it really doesn't satisfy the stub router requirements. Actually, >>> the only use case I can imagine for the V6-bit is to snoop the OSPFv3 >>> topology but not be reachable throughout the OSPFv3 routing domain. I'm >>> not sure what the original authors envisioned but I suspect they >>> thought it might help in supporting other address families. Anyway, If >>> you only consider the R-bit, it both satisfies the stub router >>> requirements and simplifies the text: >>> >>> OSPFv3 [RFC5340] introduced additional options to provide similar, if >>> not better, control of the forwarding topology; the R-bit provides >>> a more granular indication of whether an OSPFv3 router should be >>> used for transit traffic. >>> >>> On the other hand, clearing the R-bit will consistently result >>> in the router not being used for IPv6 transit traffic. >>> >>> Do you agree? Any opinions from others? >>> >>> Thanks, >>> Acee >>> >>> On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: >>> >>>> Hi! >>>> >>>> Before I publish an update I want to make sure that we're covering >>> what you want covered. >>>> >>>> I pasted below the relevant sections. Note that the new sections are >>> 3.1 and the second paragraph in Section 5. >>>> >>>> Thanks! >>>> >>>> Alvaro. >>>> >>>> >>>> ... >>>> 3. Solutions >>>> >>>> The solution introduced in this document solves two challenges >>>> associated with the outlined problem. In the description below, >>>> router X is the router announcing itself as a stub. >>>> >>>> 1) Making other routers prefer routes around router X while >>>> performing the Dijkstra calculation. >>>> >>>> 2) Allowing other routers to reach IP prefixes directly connected >>> to >>>> router X. >>>> >>>> Note that it would be easy to address issue 1) alone by just >>> flushing >>>> router X's router-LSA from the domain. However, it does not solve >>>> problem 2), since other routers will not be able to use links to >>>> router X in Dijkstra (no back link), and because router X will not >>>> have links to its neighbors. >>>> >>>> To address both problems, router X announces its router-LSA to the >>>> neighbors with the costs of all non-stub links (links of the types >>>> other than 3) set to MaxLinkMetric. >>>> >>>> The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 >>>> [RFC5340]. >>>> >>>> 3.1. OSPFv3-only Solution >>>> >>>> OSPFv3 [RFC5340] introduced additional options to provide similar, >>> if >>>> not better, control of the forwarding topology; the R-bit and the >>> V6- >>>> bit provide a more granular indication of whether a router is >>> active >>>> and/or whether it should be used specifically for IPv6 traffic, >>>> respectively. >>>> >>>> It is left to network operators to decide which technique to use in >>>> their network. >>>> >>>> >>>> 4. Maximum Link Metric >>>> >>>> ... >>>> >>>> 5. Deployment Considerations >>>> >>>> When using MaxLinkMetric, some inconsistency may be seen if the >>>> network is constructed of routers that perform intra-area Dijkstra >>>> calculation as specified in [RFC1247] (discarding link records in >>>> router-LSAs that have a MaxLinkMetric cost value) and routers that >>>> perform it as specified in [RFC1583] and higher (do not treat links >>>> with MaxLinkMetric cost as unreachable). Note that this >>>> inconsistency will not lead to routing loops, because if there are >>>> some alternate paths in the network, both types of routers will >>> agree >>>> on using them rather than the path through the stub router. If the >>>> path through the stub router is the only one, the routers of the >>>> first type will not use the stub router for transit (which is the >>>> desired behavior), while the routers of the second type will still >>>> use this path. >>>> >>>> On the other hand, clearing the R-bit/V6-bit will consistently >>> result >>>> in the router not being used as transit and/or specifically for >>> IPv6 >>>> traffic, respectively. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Retana, Alvaro >>>>> Sent: Monday, July 02, 2012 12:23 PM >>>>> To: 'Acee Lindem' >>>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>> >>>>>> -----Original Message----- >>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>> Sent: Monday, July 02, 2012 11:29 AM >>>>> ... >>>>>>> Besides from the reference (see below), what else do you think we >>>>>> should include? >>>>>>> >>>>>>> The point I'm trying to make is: rfc5340 already defines and >>>>>> documents the R-bit functionality (and it is the standard!). IMHO, >>>>>> there is no need to rehash here what is already defined and >>> explained >>>>>> somewhere else...which is why I think the reference is enough. >>>>>> >>>>>> I don't think you have to describe the mechanism. However, I agree >>> R- >>>>>> bit should be on equal ground as the max-metric links. Also, it >>> would >>>>>> be good to point out the difference in behavior. With max-metric >>>>> links, >>>>>> transit traffic is discouraged while with the R-bit, transit >>> traffic >>>>> is >>>>>> completely suppressed. >>>>> >>>>> Ok, I'll work on that. >>>>> >>>>> Alvaro. >>>> >> > From acee.lindem@ericsson.com Wed Jul 11 07:00:44 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 ECD4421F865A for ; Wed, 11 Jul 2012 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_92=0.6, 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 hRwhDftUgWsN for ; Wed, 11 Jul 2012 07:00:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AFED721F865C for ; Wed, 11 Jul 2012 07:00:43 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6BE1615012514; Wed, 11 Jul 2012 09:01:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.205]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 11 Jul 2012 10:01:08 -0400 From: Acee Lindem To: Shishio Tsuchiya Date: Wed, 11 Jul 2012 10:01:06 -0400 Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: Ac1fbZ53u/CunJGXS663i+gp3LwtAQ== Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> <4FFD4E5A.70201@cisco.com> In-Reply-To: <4FFD4E5A.70201@cisco.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-14-783329837"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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: Wed, 11 Jul 2012 14:00:45 -0000 --Apple-Mail-14-783329837 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Shishio, On Jul 11, 2012, at 5:58 AM, Shishio Tsuchiya wrote: > Alvaro,Acee > I think the change is very good. > And I have some comments. > I agree with Acee's point about applicability of max-mum metric. > 1.Max-metric applicability is very large. > -After RFC3137 was published,it used on RFC5443 and RFC6138.(LDP-SYNC) Are you asking for a reference to these RFCs for the LDP-IGP = synchronization use case?=20 > -Most of operator are using max-metric to wait for BGP startup. > -Some operators using max-metric for traffic control. > It might be better if the draft mentions the applicability. >=20 > Of course I know the motivation is including these descriptions. > But it would be more clear. >=20 > 2.R-bit > I thought R-bit and v6 bit are better than maximum-metric on RFC5838 = environment. > +-->eBGP(v4) > R1--RFC5838--R2---+ > +-->eBGP(v6) I would agree with respect to the R-bit but RFC 5838 essentially = deprecates the V6-bit for address families other than base IPv6 unicast = address family. It was retained in the default address family for = backward compatibility.=20 Thanks, Acee=20 >=20 > It is easy to control. >=20 > I would appreciate any comments. >=20 > Regards, >=20 >=20 >=20 >=20 >=20 >=20 > (2012/07/11 4:47), Acee Lindem wrote: >> Hi Alvaro, >>=20 >> On Jul 10, 2012, at 3:36 PM, Retana, Alvaro wrote: >>=20 >>> Acee: >>>=20 >>> Your point is that because the V6-bit only stops IPv6 traffic, and = it doesn't make the whole router a stub, then we shouldn't mention it = here. Sure, that sounds reasonable. >>=20 >> That and, more importantly, one would want an OSPF stub router's = local interfaces (especially loopbacks) to be reachable for I-BGP and = targeted LDP. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>>=20 >>> Alvaro. >>>=20 >>>> -----Original Message----- >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>> Sent: Tuesday, July 10, 2012 2:31 PM >>>> To: Retana, Alvaro >>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>=20 >>>> Hi Alvaro, >>>> I agree with the scope of the changes but I wouldn't mention the = V6-bit >>>> since it really doesn't satisfy the stub router requirements. = Actually, >>>> the only use case I can imagine for the V6-bit is to snoop the = OSPFv3 >>>> topology but not be reachable throughout the OSPFv3 routing domain. = I'm >>>> not sure what the original authors envisioned but I suspect they >>>> thought it might help in supporting other address families. Anyway, = If >>>> you only consider the R-bit, it both satisfies the stub router >>>> requirements and simplifies the text: >>>>=20 >>>> OSPFv3 [RFC5340] introduced additional options to provide similar, = if >>>> not better, control of the forwarding topology; the R-bit provides >>>> a more granular indication of whether an OSPFv3 router should be >>>> used for transit traffic. >>>>=20 >>>> On the other hand, clearing the R-bit will consistently result >>>> in the router not being used for IPv6 transit traffic. >>>>=20 >>>> Do you agree? Any opinions from others? >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>> On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: >>>>=20 >>>>> Hi! >>>>>=20 >>>>> Before I publish an update I want to make sure that we're covering >>>> what you want covered. >>>>>=20 >>>>> I pasted below the relevant sections. Note that the new sections = are >>>> 3.1 and the second paragraph in Section 5. >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Alvaro. >>>>>=20 >>>>>=20 >>>>> ... >>>>> 3. Solutions >>>>>=20 >>>>> The solution introduced in this document solves two challenges >>>>> associated with the outlined problem. In the description below, >>>>> router X is the router announcing itself as a stub. >>>>>=20 >>>>> 1) Making other routers prefer routes around router X while >>>>> performing the Dijkstra calculation. >>>>>=20 >>>>> 2) Allowing other routers to reach IP prefixes directly = connected >>>> to >>>>> router X. >>>>>=20 >>>>> Note that it would be easy to address issue 1) alone by just >>>> flushing >>>>> router X's router-LSA from the domain. However, it does not = solve >>>>> problem 2), since other routers will not be able to use links to >>>>> router X in Dijkstra (no back link), and because router X will = not >>>>> have links to its neighbors. >>>>>=20 >>>>> To address both problems, router X announces its router-LSA to = the >>>>> neighbors with the costs of all non-stub links (links of the = types >>>>> other than 3) set to MaxLinkMetric. >>>>>=20 >>>>> The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 >>>>> [RFC5340]. >>>>>=20 >>>>> 3.1. OSPFv3-only Solution >>>>>=20 >>>>> OSPFv3 [RFC5340] introduced additional options to provide = similar, >>>> if >>>>> not better, control of the forwarding topology; the R-bit and the >>>> V6- >>>>> bit provide a more granular indication of whether a router is >>>> active >>>>> and/or whether it should be used specifically for IPv6 traffic, >>>>> respectively. >>>>>=20 >>>>> It is left to network operators to decide which technique to use = in >>>>> their network. >>>>>=20 >>>>>=20 >>>>> 4. Maximum Link Metric >>>>>=20 >>>>> ... >>>>>=20 >>>>> 5. Deployment Considerations >>>>>=20 >>>>> When using MaxLinkMetric, some inconsistency may be seen if the >>>>> network is constructed of routers that perform intra-area = Dijkstra >>>>> calculation as specified in [RFC1247] (discarding link records in >>>>> router-LSAs that have a MaxLinkMetric cost value) and routers = that >>>>> perform it as specified in [RFC1583] and higher (do not treat = links >>>>> with MaxLinkMetric cost as unreachable). Note that this >>>>> inconsistency will not lead to routing loops, because if there = are >>>>> some alternate paths in the network, both types of routers will >>>> agree >>>>> on using them rather than the path through the stub router. If = the >>>>> path through the stub router is the only one, the routers of the >>>>> first type will not use the stub router for transit (which is the >>>>> desired behavior), while the routers of the second type will = still >>>>> use this path. >>>>>=20 >>>>> On the other hand, clearing the R-bit/V6-bit will consistently >>>> result >>>>> in the router not being used as transit and/or specifically for >>>> IPv6 >>>>> traffic, respectively. >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Retana, Alvaro >>>>>> Sent: Monday, July 02, 2012 12:23 PM >>>>>> To: 'Acee Lindem' >>>>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>>> Sent: Monday, July 02, 2012 11:29 AM >>>>>> ... >>>>>>>> Besides from the reference (see below), what else do you think = we >>>>>>> should include? >>>>>>>>=20 >>>>>>>> The point I'm trying to make is: rfc5340 already defines and >>>>>>> documents the R-bit functionality (and it is the standard!). = IMHO, >>>>>>> there is no need to rehash here what is already defined and >>>> explained >>>>>>> somewhere else...which is why I think the reference is enough. >>>>>>>=20 >>>>>>> I don't think you have to describe the mechanism. However, I = agree >>>> R- >>>>>>> bit should be on equal ground as the max-metric links. Also, it >>>> would >>>>>>> be good to point out the difference in behavior. With max-metric >>>>>> links, >>>>>>> transit traffic is discouraged while with the R-bit, transit >>>> traffic >>>>>> is >>>>>>> completely suppressed. >>>>>>=20 >>>>>> Ok, I'll work on that. >>>>>>=20 >>>>>> Alvaro. >>>>>=20 >>>=20 >>=20 >=20 >=20 >=20 --Apple-Mail-14-783329837 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMTE0MDEwNlowIwYJKoZI hvcNAQkEMRYEFEpHNhC4NFZ/i+uCRon4JQ3iCYWmMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgAGX76zPuqOI8ANG85A3YMTL0+HQXvMAxC+bXLNZDkXy9HpyZCN1xyu0+IPK0Smd my6JXT9k87zBrSc61prx7EYZ9QAZ5S/xra+sLRDTc78t+JMKUDslKoRm4xcj69jE4VD9MoVOCOz1 X9/2n/fxUtUj6PQcKki3wlli0e4eF2woAAAAAAAA --Apple-Mail-14-783329837-- From dean.cheng@huawei.com Fri Jul 13 15:25:17 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 2B64B11E8108 for ; Fri, 13 Jul 2012 15:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZR-ffSzcNFkR for ; Fri, 13 Jul 2012 15:25:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7596711E80EC for ; Fri, 13 Jul 2012 15:25:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHZ82891; Fri, 13 Jul 2012 18:25:51 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jul 2012 15:25:34 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jul 2012 15:25:31 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.147]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Sat, 14 Jul 2012 06:25:25 +0800 From: Dean cheng To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst Thread-Index: Ac1d6UGZ8N2VvsrdTtK8K/K7Qm3MFwDWshig Date: Fri, 13 Jul 2012 22:25:25 +0000 Message-ID: References: <8C713700-DB78-442F-96C7-A07CEE385752@ericsson.com> In-Reply-To: <8C713700-DB78-442F-96C7-A07CEE385752@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.59] Content-Type: multipart/mixed; boundary="_004_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst 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 Jul 2012 22:25:17 -0000 --_004_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_ Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_" --_000_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We just uploaded the -04 version of the draft. https://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing In the -04 text, in addition to incorporate Acee's comments, we added a new scenario (many thanks to Alvaro's proposal and joining us authoring this draft), where IPv4-embedded IPv6 routes can also be advertised using OSPFv3 Inter-Area-Prefix-LSAs across an IPv6 network backbone within the same AS by OSPFv3 ABRs (previously only using OSPFv3 AS-External LSAs across an IPv6 transit nertwork in a separate AS by OSPFv3 ASBRs). Comments are welcome! Thanks Dean From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Monday, July 09, 2012 8:41 AM To: Dean cheng Cc: OSPF List Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-osp= f-ipv4-embedded-ipv6-routing-02.tst I have reviewed the subject draft and would encourage others to review it a= s well. We want to WG last call the -04 version which will be posted prior = to the deadline. Thanks, Acee On Jul 9, 2012, at 11:12 AM, Dean cheng wrote: We've received some comments and plan to post a new revision before 7/16 (the deadline). Please take a look of this draft and send us comments much appreciated. Cheers Dean ________________________________ From: Dean cheng Sent: Tuesday, July 03, 2012 2:16 PM To: 'Acee Lindem'; OSPF List Subject: RE: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-osp= f-ipv4-embedded-ipv6-routing-02.tst We've made some editorial improvements and just posted as a -03 revision. http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-03 Comments welcome. Cheers Dean > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bo= unces@ietf.org] On Behalf Of > Acee Lindem > Sent: Friday, June 29, 2012 2:28 PM > To: OSPF List > Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf- > ipv4-embedded-ipv6-routing-02.tst > > > Speaking as WG Co-Chair, > > I'd like to WG last call this prior to Vancouver to volunteer to review > it? There hasn't been a lot of discussion after we concluded that the > translation was aligned with work in the BEHAVE WG. > Please take a look and post comments. It is not that long a draft by may > require you to at least scan RFC 6052. > > Thanks, > Acee --_000_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We just uploaded the -04 = version of the draft.

 <= /p>

https://datatracker.ietf.org/doc/dra= ft-ietf-ospf-ipv4-embedded-ipv6-routing

 <= /p>

In the -04 text, in addit= ion to incorporate Acee's comments, we added

a new scenario (many than= ks to Alvaro's proposal and joining us authoring

this draft), where IPv4-e= mbedded IPv6 routes can also be advertised using

OSPFv3 Inter-Area-Prefix-= LSAs across an IPv6 network backbone within the

same AS by OSPFv3 ABRs (p= reviously only using OSPFv3 AS-External LSAs

across an IPv6 transit ne= rtwork in a separate AS by OSPFv3 ASBRs).

 <= /p>

Comments are welcome!

 <= /p>

Thanks<= /p>

Dean

 <= /p>

 <= /p>

From: Acee Lin= dem [mailto:acee.lindem@ericsson.com]
Sent: Monday, July 09, 2012 8:41 AM
To: Dean cheng
Cc: OSPF List
Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-i= etf-ospf-ipv4-embedded-ipv6-routing-02.tst

 

I have reviewed the subject draft and would encourag= e others to review it as well. We want to WG last call the -04 version whic= h will be posted prior to the deadline. 

Thanks,

Acee 

On Jul 9, 2012, at 11:12 AM, Dean cheng wrote:<= /o:p>



We’ve received some comm= ents and plan to post a new revision

before 7/16 (the deadline). Pl= ease take a look of this draft and

send us comments much apprecia= ted.

 

Cheers

Dean

 

From: Dean che= ng
Sent: Tuesday, July 03, 2012 2:16 PM
To: 'Acee Lindem'; OSPF List
Subject: RE: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-i= etf-ospf-ipv4-embedded-ipv6-routing-02.tst

 

We’ve made some editorial improvements and = just posted

as a -03 revision.

 

http://tools.ietf.org/html/draft-ietf-o= spf-ipv4-embedded-ipv6-routing-03

 

Comments welcome.

 

Cheers

Dean

 

> -----Original Message-----

> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of

> Acee Lindem

> Sent: Friday, June 29, 2012 2:28 PM

> To: OSPF List

> Subject: [OSPF] Routing for IPv4-embedded IP= v6 Packets - draft-ietf-ospf-

> ipv4-embedded-ipv6-routing-02.tst=

>

>

> Speaking as WG Co-Chair,

>

> I'd like to WG last call this prior to Vanco= uver to volunteer to review

> it? There hasn't been a lot of discussion af= ter we concluded that the

> translation was aligned with work in the BEH= AVE WG.

> Please take a look and post comments. It is = not that long a draft by may

> require you to at least scan RFC 6052.<= /o:p>

>

> Thanks,

> Acee

 

--_000_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_-- --_004_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 13 Jul 2012 22:25:21 GMT"; modification-date="Fri, 13 Jul 2012 22:25:21 GMT" Received: from szxeml211-edg.china.huawei.com (172.24.2.182) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 14 Jul 2012 06:07:03 +0800 Received: from szxrg04-in.huawei.com (172.24.2.119) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server id 14.1.323.3; Sat, 14 Jul 2012 06:06:58 +0800 Received: from localhost (localhost [127.0.0.1]) by szxrg04-in.huawei.com (MOS 4.2.3-GA) id AFA68810; Sat, 14 Jul 2012 06:07:03 +0800 (CST) Received: from mail.ietf.org (EHLO mail.ietf.org) ([12.22.58.30]) by szxrg04-in.huawei.com (MOS 4.2.3-GA FastPath queued) with ESMTP id AFA68797; Sat, 14 Jul 2012 06:07:02 +0800 (CST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DCF11E8121; Fri, 13 Jul 2012 15:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D111E8122; Fri, 13 Jul 2012 15:06:10 -0700 (PDT) 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 TKDefKPz5Dv4; Fri, 13 Jul 2012 15:06:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A9D11E8102; Fri, 13 Jul 2012 15:06:09 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" CC: "ospf@ietf.org" Subject: I-D Action: draft-ietf-ospf-ipv4-embedded-ipv6-routing-04.txt Thread-Topic: I-D Action: draft-ietf-ospf-ipv4-embedded-ipv6-routing-04.txt Thread-Index: AQHNYUPWFSA+YLOyJk+t2rkdu+GmlQ== Sender: "i-d-announce-bounces@ietf.org" Date: Fri, 13 Jul 2012 22:06:09 +0000 Message-ID: <20120713220609.28061.72645.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: szxeml211-edg.china.huawei.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Shortest Path First IGP Working Grou= p of the IETF. Title : Routing for IPv4-embedded IPv6 Packets Author(s) : Dean Cheng Mohamed Boucadair Alvaro Retana Filename : draft-ietf-ospf-ipv4-embedded-ipv6-routing-04.txt Pages : 14 Date : 2012-07-13 Abstract: This document describes routing packets destined to IPv4-embedded IPv6 addresses across an IPv6 core using OSPFv3 with a separate routing table. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ipv4-embedded-ipv6-routing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ipv4-embedded-ipv6-rou= ting-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_004_DC7880973D477648AC15A3BA66253F6851A44FDFszxeml523mbschi_-- From shtsuchi@cisco.com Sat Jul 14 05:33:56 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 344A321F84F5 for ; Sat, 14 Jul 2012 05:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_92=0.6, 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 n7b4SyXPN8KL for ; Sat, 14 Jul 2012 05:33:54 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id DB16321F84EB for ; Sat, 14 Jul 2012 05:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=8309; q=dns/txt; s=iport; t=1342269272; x=1343478872; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hA5a4J01B193N4RKa7F8DfUdk7rHWIhcbkv1vfd8yjA=; b=egR13q9CffoxLIdSymvN4CT/jiy9J7QVAT4t0MjQHRLgNhhwZITQghqm Dysnr0F9l/gTHy7kUhfn3nvEE0mv+i9NKFurffYBwync/bxq35BASLK7s SqilfQPh2L0Tkn7/bnuXkO/YJSS/Tp0/rqcQWJELgEB16FK5t1NhUaqYi M=; X-IronPort-AV: E=Sophos;i="4.77,584,1336348800"; d="scan'208";a="15029446" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 14 Jul 2012 12:34:22 +0000 Received: from [10.71.44.85] (tky-shtsuchi-8914.cisco.com [10.71.44.85]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6ECYL0R010595; Sat, 14 Jul 2012 12:34:22 GMT Message-ID: <5001674C.30005@cisco.com> Date: Sat, 14 Jul 2012 21:34:20 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: acee.lindem@ericsson.com References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> <4FFD4E5A.70201@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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: Sat, 14 Jul 2012 12:33:56 -0000 Acee (2012/07/11 23:01), Acee Lindem wrote: > Hi Shishio, > > On Jul 11, 2012, at 5:58 AM, Shishio Tsuchiya wrote: > >> Alvaro,Acee >> I think the change is very good. >> And I have some comments. >> I agree with Acee's point about applicability of max-mum metric. >> 1.Max-metric applicability is very large. >> -After RFC3137 was published,it used on RFC5443 and RFC6138.(LDP-SYNC) > > Are you asking for a reference to these RFCs for the LDP-IGP synchronization use case? Yes,I think it is better. > > >> -Most of operator are using max-metric to wait for BGP startup. >> -Some operators using max-metric for traffic control. >> It might be better if the draft mentions the applicability. >> >> Of course I know the motivation is including these descriptions. >> But it would be more clear. >> >> 2.R-bit >> I thought R-bit and v6 bit are better than maximum-metric on RFC5838 environment. >> +-->eBGP(v4) >> R1--RFC5838--R2---+ >> +-->eBGP(v6) > > I would agree with respect to the R-bit but RFC 5838 essentially deprecates the V6-bit for address families other than base IPv6 unicast address family. It was retained in the default address family for backward compatibility. Um.Thank you for comments. I think we need more time and customer experience of RFC5838 to discuss this topic. Therefore it should not describe about RFC5838 in the draft. Thank you for correction. Regards, -Shishio > > Thanks, > Acee > > >> >> It is easy to control. >> >> I would appreciate any comments. >> >> Regards, >> >> >> >> >> >> >> (2012/07/11 4:47), Acee Lindem wrote: >>> Hi Alvaro, >>> >>> On Jul 10, 2012, at 3:36 PM, Retana, Alvaro wrote: >>> >>>> Acee: >>>> >>>> Your point is that because the V6-bit only stops IPv6 traffic, and it doesn't make the whole router a stub, then we shouldn't mention it here. Sure, that sounds reasonable. >>> >>> That and, more importantly, one would want an OSPF stub router's local interfaces (especially loopbacks) to be reachable for I-BGP and targeted LDP. >>> >>> Thanks, >>> Acee >>> >>> >>>> >>>> Alvaro. >>>> >>>>> -----Original Message----- >>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>> Sent: Tuesday, July 10, 2012 2:31 PM >>>>> To: Retana, Alvaro >>>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>> >>>>> Hi Alvaro, >>>>> I agree with the scope of the changes but I wouldn't mention the V6-bit >>>>> since it really doesn't satisfy the stub router requirements. Actually, >>>>> the only use case I can imagine for the V6-bit is to snoop the OSPFv3 >>>>> topology but not be reachable throughout the OSPFv3 routing domain. I'm >>>>> not sure what the original authors envisioned but I suspect they >>>>> thought it might help in supporting other address families. Anyway, If >>>>> you only consider the R-bit, it both satisfies the stub router >>>>> requirements and simplifies the text: >>>>> >>>>> OSPFv3 [RFC5340] introduced additional options to provide similar, if >>>>> not better, control of the forwarding topology; the R-bit provides >>>>> a more granular indication of whether an OSPFv3 router should be >>>>> used for transit traffic. >>>>> >>>>> On the other hand, clearing the R-bit will consistently result >>>>> in the router not being used for IPv6 transit traffic. >>>>> >>>>> Do you agree? Any opinions from others? >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> On Jul 10, 2012, at 10:48 AM, Retana, Alvaro wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> Before I publish an update I want to make sure that we're covering >>>>> what you want covered. >>>>>> >>>>>> I pasted below the relevant sections. Note that the new sections are >>>>> 3.1 and the second paragraph in Section 5. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Alvaro. >>>>>> >>>>>> >>>>>> ... >>>>>> 3. Solutions >>>>>> >>>>>> The solution introduced in this document solves two challenges >>>>>> associated with the outlined problem. In the description below, >>>>>> router X is the router announcing itself as a stub. >>>>>> >>>>>> 1) Making other routers prefer routes around router X while >>>>>> performing the Dijkstra calculation. >>>>>> >>>>>> 2) Allowing other routers to reach IP prefixes directly connected >>>>> to >>>>>> router X. >>>>>> >>>>>> Note that it would be easy to address issue 1) alone by just >>>>> flushing >>>>>> router X's router-LSA from the domain. However, it does not solve >>>>>> problem 2), since other routers will not be able to use links to >>>>>> router X in Dijkstra (no back link), and because router X will not >>>>>> have links to its neighbors. >>>>>> >>>>>> To address both problems, router X announces its router-LSA to the >>>>>> neighbors with the costs of all non-stub links (links of the types >>>>>> other than 3) set to MaxLinkMetric. >>>>>> >>>>>> The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 >>>>>> [RFC5340]. >>>>>> >>>>>> 3.1. OSPFv3-only Solution >>>>>> >>>>>> OSPFv3 [RFC5340] introduced additional options to provide similar, >>>>> if >>>>>> not better, control of the forwarding topology; the R-bit and the >>>>> V6- >>>>>> bit provide a more granular indication of whether a router is >>>>> active >>>>>> and/or whether it should be used specifically for IPv6 traffic, >>>>>> respectively. >>>>>> >>>>>> It is left to network operators to decide which technique to use in >>>>>> their network. >>>>>> >>>>>> >>>>>> 4. Maximum Link Metric >>>>>> >>>>>> ... >>>>>> >>>>>> 5. Deployment Considerations >>>>>> >>>>>> When using MaxLinkMetric, some inconsistency may be seen if the >>>>>> network is constructed of routers that perform intra-area Dijkstra >>>>>> calculation as specified in [RFC1247] (discarding link records in >>>>>> router-LSAs that have a MaxLinkMetric cost value) and routers that >>>>>> perform it as specified in [RFC1583] and higher (do not treat links >>>>>> with MaxLinkMetric cost as unreachable). Note that this >>>>>> inconsistency will not lead to routing loops, because if there are >>>>>> some alternate paths in the network, both types of routers will >>>>> agree >>>>>> on using them rather than the path through the stub router. If the >>>>>> path through the stub router is the only one, the routers of the >>>>>> first type will not use the stub router for transit (which is the >>>>>> desired behavior), while the routers of the second type will still >>>>>> use this path. >>>>>> >>>>>> On the other hand, clearing the R-bit/V6-bit will consistently >>>>> result >>>>>> in the router not being used as transit and/or specifically for >>>>> IPv6 >>>>>> traffic, respectively. >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Retana, Alvaro >>>>>>> Sent: Monday, July 02, 2012 12:23 PM >>>>>>> To: 'Acee Lindem' >>>>>>> Cc: Shishio Tsuchiya; ospf@ietf.org >>>>>>> Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>>>>> Sent: Monday, July 02, 2012 11:29 AM >>>>>>> ... >>>>>>>>> Besides from the reference (see below), what else do you think we >>>>>>>> should include? >>>>>>>>> >>>>>>>>> The point I'm trying to make is: rfc5340 already defines and >>>>>>>> documents the R-bit functionality (and it is the standard!). IMHO, >>>>>>>> there is no need to rehash here what is already defined and >>>>> explained >>>>>>>> somewhere else...which is why I think the reference is enough. >>>>>>>> >>>>>>>> I don't think you have to describe the mechanism. However, I agree >>>>> R- >>>>>>>> bit should be on equal ground as the max-metric links. Also, it >>>>> would >>>>>>>> be good to point out the difference in behavior. With max-metric >>>>>>> links, >>>>>>>> transit traffic is discouraged while with the R-bit, transit >>>>> traffic >>>>>>> is >>>>>>>> completely suppressed. >>>>>>> >>>>>>> Ok, I'll work on that. >>>>>>> >>>>>>> Alvaro. >>>>>> >>>> >>> >> >> >> > From alvaro.retana@hp.com Sat Jul 14 08:25:29 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 4E49621F84C4 for ; Sat, 14 Jul 2012 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[AWL=-1.513, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 cxsheKwQkJcz for ; Sat, 14 Jul 2012 08:25:28 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7D21F84B5 for ; Sat, 14 Jul 2012 08:25:28 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 651B61C2DB; Sat, 14 Jul 2012 15:26:05 +0000 (UTC) Received: from G2W1813G.americas.hpqcorp.net (16.238.8.212) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sat, 14 Jul 2012 15:17:40 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.58]) by G2W1813G.americas.hpqcorp.net ([fe80::2d8c:5671:edf9:26b0%12]) with mapi id 14.02.0283.003; Sat, 14 Jul 2012 15:17:40 +0000 From: "Retana, Alvaro" To: Shishio Tsuchiya , "acee.lindem@ericsson.com" Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Thread-Index: AQHNVg5HsUaborfKXU2QsMDIg0DSaJcSTL2AgAON5BCAAC4dgIAAD8EQgAAKS4CAAArbEIAMex5wgAA/ToCAABHOkIAAA7cAgADt1wCAAEOxAIAEnsAAgAAqjIA= Date: Sat, 14 Jul 2012 15:17:39 +0000 Message-ID: References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> <4FFD4E5A.70201@cisco.com> <5001674C.30005@cisco.com> In-Reply-To: <5001674C.30005@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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: Sat, 14 Jul 2012 15:25:29 -0000 > -----Original Message----- > From: Shishio Tsuchiya [mailto:shtsuchi@cisco.com] > Sent: Saturday, July 14, 2012 8:34 AM ... > >> 1.Max-metric applicability is very large. > >> -After RFC3137 was published,it used on RFC5443 and RFC6138.(LDP- > SYNC) > > > > Are you asking for a reference to these RFCs for the LDP-IGP > synchronization use case? >=20 > Yes,I think it is better. 6138 points to 5443, which points to 3137 Any now 3137bis, which would be referenced by 3137 (as its successor) would= point to 6138 and 5443... I'm no expert, but isn't that a loop? ;-) Seriously, I think all this pointing around is overkill. Are you trying to propose that we write an applicability section? I'm afra= id that whatever we specifically (i.e. with references) mention will not be= complete because potentially other applications may come up. The "Motivat= ion" section (which I pasted below) already mentions some of the use cases = (at a high level). For example, the LDP sync application fits under grace= ful introduction, as well as waiting for BGP. If you have specific text you want to suggest adding to the motivation (tha= t doesn't make the new RFC become outdated faster), then we would be very g= lad to consider it. Thanks! Alvaro. 1. Motivation In some situations, it may be advantageous to inform routers in a network not to use a specific router as a transit point, but still route to it. Possible situations include the following: o The router is in a critical condition (for example, has very high CPU load or does not have enough memory to store all LSAs or build the routing table). o Graceful introduction and removal of the router to/from the network. o Other (administrative or traffic engineering) reasons. Note that the proposed solution does not remove the router from the topology view of the network (as could be done by just flushing that router's router-LSA), but prevents other routers from using it for transit routing, while still routing packets to the router's own IP addresses, i.e., the router is announced as a stub. It must be emphasized that the proposed solution provides real benefits in networks designed with at least some level of redundancy so that traffic can be routed around the stub router. Otherwise, traffic destined for the networks reachable through such a stub router will be still routed through it. From shtsuchi@cisco.com Sun Jul 15 08:40:49 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 AE4AD21F84B9 for ; Sun, 15 Jul 2012 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 jw9SYpKvqn58 for ; Sun, 15 Jul 2012 08:40:49 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 25AF721F84C8 for ; Sun, 15 Jul 2012 08:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=3808; q=dns/txt; s=iport; t=1342366890; x=1343576490; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9x+rMtIWjnx9GdNlXwBN9OY1YG3vWXtXjwZgedmZQ3g=; b=Lr/uaFDr1iil/XDPPuwQfbhwqenfepfIFXZZT7YFO9U2PYE69icB6XTk Ehtm2KhVsn4sqE6VCN1stEN9Y3u0NHqnxFdgQhRDz1UqJXxTDqj1LfGQN ycvjeA1ZUcNMrc7bwDkAotTfTssTpd8P/aOYYpFYUW/EQm02Q/L7GmzKl M=; X-IronPort-AV: E=Sophos;i="4.77,588,1336348800"; d="scan'208";a="15045556" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 15 Jul 2012 15:41:28 +0000 Received: from [10.71.44.85] (tky-shtsuchi-8914.cisco.com [10.71.44.85]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6FFfQo0027967; Sun, 15 Jul 2012 15:41:27 GMT Message-ID: <5002E4A6.6030906@cisco.com> Date: Mon, 16 Jul 2012 00:41:26 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: alvaro.retana@hp.com References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> <4FEE8683.1010706@cisco.com> <1E092B73-5A5F-4A5E-B228-B52385326ECF@ericsson.com> <606A577C-A46B-4376-9D7D-8E4EF22800BF@ericsson.com> <4FFD4E5A.70201@cisco.com> <5001674C.30005@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-rfc3137bis-01.txt 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: Sun, 15 Jul 2012 15:40:49 -0000 Alvaro (2012/07/15 0:17), Retana, Alvaro wrote: > 6138 points to 5443, which points to 3137 > > Any now 3137bis, which would be referenced by 3137 (as its successor) would point to 6138 and 5443... I'm no expert, but isn't that a loop? ;-) > > Seriously, I think all this pointing around is overkill. > > Are you trying to propose that we write an applicability section? I'm afraid that whatever we specifically (i.e. with references) mention will not be complete because potentially other applications may come up. The "Motivation" section (which I pasted below) already mentions some of the use cases (at a high level). For example, the LDP sync application fits under graceful introduction, as well as waiting for BGP. > > If you have specific text you want to suggest adding to the motivation (that doesn't make the new RFC become outdated faster), then we would be very glad to consider it. Yes,I agree that it should not be redundant. If one sentence adds to the Solution section which describes maximum link metric,how is it? 2. Solution 2.1. Maximum Link Metric The solution introduced in this document solves two challenges associated with the outlined problem. In the description below, router X is the router announcing itself as a stub. 1) Making other routers prefer routes around router X while performing the Dijkstra calculation. 2) Allowing other routers to reach IP prefixes directly connected to router X. Note that it would be easy to address issue 1) alone by just flushing router X's router-LSA from the domain. However, it does not solve problem 2), since other routers will not be able to use links to router X in Dijkstra (no back link), and because router X will not have links to its neighbors. To address both problems, router X announces its router-LSA to the neighbors with the costs of all non-stub links (links of the types other than 3) set to MaxLinkMetric. The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. The solution is already well-using with other protocol, such as "wait for BGP startup", "LDP-Sync [RFC6138] [RFC5443]". or The solution is already implemented in a lot of vendors, it also works together with other protocols, such as "wait for BGP startup", "LDP-Sync [RFC6138] [RFC5443]". 2.2 R-bit (or OSPFv3 only solution) .... Regards, -Shishio > > Thanks! > > Alvaro. > > > > 1. Motivation > > > In some situations, it may be advantageous to inform routers in a > network not to use a specific router as a transit point, but still > route to it. Possible situations include the following: > > o The router is in a critical condition (for example, has very high > CPU load or does not have enough memory to store all LSAs or build > the routing table). > > o Graceful introduction and removal of the router to/from the > network. > > o Other (administrative or traffic engineering) reasons. > > Note that the proposed solution does not remove the router from the > topology view of the network (as could be done by just flushing that > router's router-LSA), but prevents other routers from using it for > transit routing, while still routing packets to the router's own IP > addresses, i.e., the router is announced as a stub. > > It must be emphasized that the proposed solution provides real > benefits in networks designed with at least some level of redundancy > so that traffic can be routed around the stub router. Otherwise, > traffic destined for the networks reachable through such a stub > router will be still routed through it. > > > . > From wwwrun@rfc-editor.org Mon Jul 23 02:21:10 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 1AF7721F866B for ; Mon, 23 Jul 2012 02:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.258 X-Spam-Level: X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 y0i7BbHnzkIE for ; Mon, 23 Jul 2012 02:21:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5393621F869C for ; Mon, 23 Jul 2012 02:21:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7B34162189; Mon, 23 Jul 2012 02:21:02 -0700 (PDT) To: djoyal@nortel.com, pgalecki@airvana.com, spencer.giacalone@gmail.com, fred@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20120723092102.7B34162189@rfc-editor.org> Date: Mon, 23 Jul 2012 02:21:02 -0700 (PDT) Cc: ospf@ietf.org, mikek@muonics.com, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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 Jul 2012 09:21:10 -0000 The following errata report has been submitted for RFC4750, "OSPF Version 2 Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4750&eid=3292 -------------------------------------- Type: Editorial Reported by: Michael Kirkham Section: 5 Original Text ------------- ospfTrapCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement." MODULE -- this module MANDATORY-GROUPS { ospfTrapControlGroup } GROUP ospfTrapControlGroup DESCRIPTION "This group is optional but recommended for all OSPF systems." ::= { ospfTrapCompliances 1 } Corrected Text -------------- ospfTrapCompliance MODULE-COMPLIANCE STATUS obsolete DESCRIPTION "The compliance statement." MODULE -- this module GROUP ospfTrapControlGroup DESCRIPTION "This group is optional but recommended for all OSPF systems." ::= { ospfTrapCompliances 1 } Notes ----- ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and in a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (brackets added to indicate pertinent rule): "5.4.2. Mapping of the GROUP clause The GROUP clause, which need not be present, is repeatedly used to name each object and notification group which is conditionally mandatory for compliance to the MIB module. The GROUP clause can also be used to name unconditionally optional groups. [A group named in a GROUP clause must be absent from the correspondent MANDATORY- GROUPS clause.]" It is listed in both clauses in RFC 1850 as well (which RFC 4750 obsoletes). It is STATUS current in RFC 1850 and STATUS obsolete in 4750; however, obsolete or not, it is not legal according to SMI rules. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4750 (draft-ietf-ospf-mib-update-11) -------------------------------------- Title : OSPF Version 2 Management Information Base Publication Date : December 2006 Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee.lindem@ericsson.com Tue Jul 24 07:50:54 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 C472A21F862B for ; Tue, 24 Jul 2012 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 XjGD6234cVMC for ; Tue, 24 Jul 2012 07:50:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E023021F85C0 for ; Tue, 24 Jul 2012 07:50:53 -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 q6OEolWV019009; Tue, 24 Jul 2012 09:50:49 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Jul 2012 10:50:42 -0400 From: Acee Lindem To: Joan Cucchiara Date: Tue, 24 Jul 2012 10:50:40 -0400 Thread-Topic: [Editorial Errata Reported] RFC4750 (3292) Thread-Index: Ac1pq7KPniDkY9dTRKeP3UKmiB0qlg== Message-ID: <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> References: <20120723092102.7B34162189@rfc-editor.org> In-Reply-To: <20120723092102.7B34162189@rfc-editor.org> 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--237979780"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "mikek@muonics.com" , "pgalecki@airvana.com" , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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, 24 Jul 2012 14:50:54 -0000 --Apple-Mail-9--237979780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joan,=20 If you have a minute could you comment as to: =20 1. Is the subject Errata correct?=20 2. If so, does it have any consequence other than editorial content? = It doesn't appear to me that any MIB tools have complained about it.=20 Thanks, Acee=20 On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC4750, > "OSPF Version 2 Management Information Base". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D3292 >=20 > -------------------------------------- > Type: Editorial > Reported by: Michael Kirkham >=20 > Section: 5 >=20 > Original Text > ------------- > ospfTrapCompliance MODULE-COMPLIANCE > STATUS obsolete > DESCRIPTION > "The compliance statement." > MODULE -- this module > MANDATORY-GROUPS { ospfTrapControlGroup } >=20 > GROUP ospfTrapControlGroup > DESCRIPTION > "This group is optional but recommended for all > OSPF systems." > ::=3D { ospfTrapCompliances 1 } >=20 > Corrected Text > -------------- > ospfTrapCompliance MODULE-COMPLIANCE > STATUS obsolete > DESCRIPTION > "The compliance statement." > MODULE -- this module > GROUP ospfTrapControlGroup > DESCRIPTION > "This group is optional but recommended for all > OSPF systems." > ::=3D { ospfTrapCompliances 1 } >=20 > Notes > ----- > ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and = in a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 = (brackets added to indicate pertinent rule): >=20 > "5.4.2. Mapping of the GROUP clause >=20 > The GROUP clause, which need not be present, is repeatedly used to > name each object and notification group which is conditionally > mandatory for compliance to the MIB module. The GROUP clause can > also be used to name unconditionally optional groups. [A group = named > in a GROUP clause must be absent from the correspondent MANDATORY- > GROUPS clause.]" >=20 > It is listed in both clauses in RFC 1850 as well (which RFC 4750 = obsoletes). It is STATUS current in RFC 1850 and STATUS obsolete in = 4750; however, obsolete or not, it is not legal according to SMI rules. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4750 (draft-ietf-ospf-mib-update-11) > -------------------------------------- > Title : OSPF Version 2 Management Information Base > Publication Date : December 2006 > Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, = Ed., R. Coltun, F. Baker > Category : PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG --Apple-Mail-9--237979780 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcyNDE0NTA0MFowIwYJKoZI hvcNAQkEMRYEFPX7bDI9S7aei5rn3I/FzlzOE7cAMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFQOY8ea62+1SmH6tFc+5zSa6W6K5eSpoTmB6zz0QGwj89v+7irTTczToGRPebQ5 7B0oZlFhiYhB7+QTmuqVqOasQ0SiQCjChDj9O866K2ZA9SmC01OPytIMt7LyCepzvm3BrrN+BloG SmpxQ3qILXx8cepEuynBZ2GFYHQYYPX4AAAAAAAA --Apple-Mail-9--237979780-- From adrian@olddog.co.uk Tue Jul 24 10:59:59 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 63A5521F85F9 for ; Tue, 24 Jul 2012 10:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxM6WawUwuWQ for ; Tue, 24 Jul 2012 10:59:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 745E321F85C2 for ; Tue, 24 Jul 2012 10:59:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6OHxmf0003217; Tue, 24 Jul 2012 18:59:48 +0100 Received: from 950129200 (ns-visitor-nsrp.juniper.net [208.223.208.242]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6OHxiWM003189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 18:59:45 +0100 From: "Adrian Farrel" To: "'Acee Lindem'" , "'Joan Cucchiara'" References: <20120723092102.7B34162189@rfc-editor.org> <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> In-Reply-To: <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> Date: Tue, 24 Jul 2012 18:59:44 +0100 Message-ID: <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtohifqSoeaefplfHQ1YmHfTz8JgJ81K1RluRCtwA= Content-Language: en-gb Cc: mikek@muonics.com, pgalecki@airvana.com, djoyal@nortel.com, ospf@ietf.org Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:59:59 -0000 Hi, This sort of erratum in a MIB module bothers me. The trouble is that it changes the compilable content of the module, if not the key parts. So, the order of process is: - Is the erratum correct? - Is a fix *required* (i.e., is the module unusable without it?) - Can the erratum be held for a revision of the module? - How urgent is such a revision? - Do we have candidates to revise the document? Cheers, Adrian (speaking as an AD who does MIB modules a bit, but not the AD for OSPF) > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: 24 July 2012 15:51 > To: Joan Cucchiara > Cc: djoyal@nortel.com; pgalecki@airvana.com; spencer.giacalone@gmail.com; > fred@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; akr@cisco.com; > mikek@muonics.com; ospf@ietf.org > Subject: Re: [Editorial Errata Reported] RFC4750 (3292) > > Hi Joan, > If you have a minute could you comment as to: > 1. Is the subject Errata correct? > 2. If so, does it have any consequence other than editorial content? It doesn't > appear to me that any MIB tools have complained about it. > > Thanks, > Acee > > On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: > > > > > The following errata report has been submitted for RFC4750, > > "OSPF Version 2 Management Information Base". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4750&eid=3292 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Michael Kirkham > > > > Section: 5 > > > > Original Text > > ------------- > > ospfTrapCompliance MODULE-COMPLIANCE > > STATUS obsolete > > DESCRIPTION > > "The compliance statement." > > MODULE -- this module > > MANDATORY-GROUPS { ospfTrapControlGroup } > > > > GROUP ospfTrapControlGroup > > DESCRIPTION > > "This group is optional but recommended for all > > OSPF systems." > > ::= { ospfTrapCompliances 1 } > > > > Corrected Text > > -------------- > > ospfTrapCompliance MODULE-COMPLIANCE > > STATUS obsolete > > DESCRIPTION > > "The compliance statement." > > MODULE -- this module > > GROUP ospfTrapControlGroup > > DESCRIPTION > > "This group is optional but recommended for all > > OSPF systems." > > ::= { ospfTrapCompliances 1 } > > > > Notes > > ----- > > ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and in > a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (brackets > added to indicate pertinent rule): > > > > "5.4.2. Mapping of the GROUP clause > > > > The GROUP clause, which need not be present, is repeatedly used to > > name each object and notification group which is conditionally > > mandatory for compliance to the MIB module. The GROUP clause can > > also be used to name unconditionally optional groups. [A group named > > in a GROUP clause must be absent from the correspondent MANDATORY- > > GROUPS clause.]" > > > > It is listed in both clauses in RFC 1850 as well (which RFC 4750 obsoletes). It is > STATUS current in RFC 1850 and STATUS obsolete in 4750; however, obsolete or > not, it is not legal according to SMI rules. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4750 (draft-ietf-ospf-mib-update-11) > > -------------------------------------- > > Title : OSPF Version 2 Management Information Base > > Publication Date : December 2006 > > Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. > Baker > > Category : PROPOSED STANDARD > > Source : Open Shortest Path First IGP > > Area : Routing > > Stream : IETF > > Verifying Party : IESG From acee.lindem@ericsson.com Tue Jul 24 11:11:18 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 286B221F85CC for ; Tue, 24 Jul 2012 11:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 0ETVJevUfUtX for ; Tue, 24 Jul 2012 11:11:17 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65921F8593 for ; Tue, 24 Jul 2012 11:11:17 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6OIAQac002684; Tue, 24 Jul 2012 13:11:13 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 24 Jul 2012 14:11:10 -0400 From: Acee Lindem To: "adrian@olddog.co.uk" Date: Tue, 24 Jul 2012 14:11:09 -0400 Thread-Topic: [Editorial Errata Reported] RFC4750 (3292) Thread-Index: Ac1px7Q7Deh1/eNaQTub4zd2jlA+1w== Message-ID: <09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> References: <20120723092102.7B34162189@rfc-editor.org> <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> In-Reply-To: <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> 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-14--225950058"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "mikek@muonics.com" , "pgalecki@airvana.com" , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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, 24 Jul 2012 18:11:18 -0000 --Apple-Mail-14--225950058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adrian, On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: > Hi, >=20 > This sort of erratum in a MIB module bothers me. > The trouble is that it changes the compilable content of the module, = if not the > key parts. >=20 > So, the order of process is: > - Is the erratum correct? > - Is a fix *required* (i.e., is the module unusable without it?) > - Can the erratum be held for a revision of the module? > - How urgent is such a revision? Given that RFC 1850 has been around for over 17 years and there are many = existing implementations, I would suffice it to say that this correction = would not in and of itself warrant a revision.=20 OTOH, there are problems with the OSPFv3 MIB ranges that should be = corrected with a revision.=20 Thanks, Acee > - Do we have candidates to revise the document? >=20 > Cheers, > Adrian (speaking as an AD who does MIB modules a bit, but not the AD = for OSPF) >=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: 24 July 2012 15:51 >> To: Joan Cucchiara >> Cc: djoyal@nortel.com; pgalecki@airvana.com; = spencer.giacalone@gmail.com; >> fred@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = akr@cisco.com; >> mikek@muonics.com; ospf@ietf.org >> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) >>=20 >> Hi Joan, >> If you have a minute could you comment as to: >> 1. Is the subject Errata correct? >> 2. If so, does it have any consequence other than editorial content? = It > doesn't >> appear to me that any MIB tools have complained about it. >>=20 >> Thanks, >> Acee >>=20 >> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >>=20 >>>=20 >>> The following errata report has been submitted for RFC4750, >>> "OSPF Version 2 Management Information Base". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D3292 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Michael Kirkham >>>=20 >>> Section: 5 >>>=20 >>> Original Text >>> ------------- >>> ospfTrapCompliance MODULE-COMPLIANCE >>> STATUS obsolete >>> DESCRIPTION >>> "The compliance statement." >>> MODULE -- this module >>> MANDATORY-GROUPS { ospfTrapControlGroup } >>>=20 >>> GROUP ospfTrapControlGroup >>> DESCRIPTION >>> "This group is optional but recommended for all >>> OSPF systems." >>> ::=3D { ospfTrapCompliances 1 } >>>=20 >>> Corrected Text >>> -------------- >>> ospfTrapCompliance MODULE-COMPLIANCE >>> STATUS obsolete >>> DESCRIPTION >>> "The compliance statement." >>> MODULE -- this module >>> GROUP ospfTrapControlGroup >>> DESCRIPTION >>> "This group is optional but recommended for all >>> OSPF systems." >>> ::=3D { ospfTrapCompliances 1 } >>>=20 >>> Notes >>> ----- >>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause = and in >> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 = (brackets >> added to indicate pertinent rule): >>>=20 >>> "5.4.2. Mapping of the GROUP clause >>>=20 >>> The GROUP clause, which need not be present, is repeatedly used to >>> name each object and notification group which is conditionally >>> mandatory for compliance to the MIB module. The GROUP clause can >>> also be used to name unconditionally optional groups. [A group = named >>> in a GROUP clause must be absent from the correspondent MANDATORY- >>> GROUPS clause.]" >>>=20 >>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 = obsoletes). > It is >> STATUS current in RFC 1850 and STATUS obsolete in 4750; however, = obsolete or >> not, it is not legal according to SMI rules. >>>=20 >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC4750 (draft-ietf-ospf-mib-update-11) >>> -------------------------------------- >>> Title : OSPF Version 2 Management Information Base >>> Publication Date : December 2006 >>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, = Ed., R. > Coltun, F. >> Baker >>> Category : PROPOSED STANDARD >>> Source : Open Shortest Path First IGP >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >=20 >=20 --Apple-Mail-14--225950058 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcyNDE4MTExMFowIwYJKoZI hvcNAQkEMRYEFDyj+FlBNuuwKr016fgxSuaf9wRPMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgAi1q9Wlsn+tFS1bWE4MzJHxLsfIHUx29Q6vZRRquvArqYh8nTD6icDBQF/8LHTV 7ngu0l+YVs2mKrNYZUVeQsIa799/DDTDrKBbOfU2E6+70oPBkC5xTa+kj0rcccDnOnTcTtbqCInH fbA539GZECqKfEf+zCSMR7UWTEieIGKEAAAAAAAA --Apple-Mail-14--225950058-- From fred@cisco.com Tue Jul 24 11:51: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 BBCFF11E8091 for ; Tue, 24 Jul 2012 11:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.104 X-Spam-Level: X-Spam-Status: No, score=-110.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 UpIxYZDZC7J9 for ; Tue, 24 Jul 2012 11:51:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6DE11E8088 for ; Tue, 24 Jul 2012 11:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5392; q=dns/txt; s=iport; t=1343155910; x=1344365510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UJvkErmXT5vRDV3Ng1nll8WbWRk+zk6uYj00xjFdcbE=; b=ksJhb0JMPpBSQktpAt07GVyrIDEumUz3m7F7e1s6UoTr0dGQHNAfoTeJ oegk8zHkoZzQdsEEHlPdsp9ZvvFfp7M8yJANVGU1azsEfsesTGpaHHKXE nK9jYSAiTAhP8NyBWl5ctKVhZGHNqVC1fwiLlrxFP6M6/oWb5b8vZ9WL5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJLuDlCtJXG+/2dsb2JhbAArEAq5eIEHgiABAQEDARIBJz8FBwQCAQgRBAEBAR4JByERFAkIAgQOBSKHXAMGBgspmkuWYQ2JTopjaBCGBGADk3WBVIsKgx2BZoJfbw X-IronPort-AV: E=Sophos;i="4.77,647,1336348800"; d="scan'208";a="101901289" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jul 2012 18:51:49 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6OIpnHO003194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 18:51:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 13:51:48 -0500 From: "Fred Baker (fred)" To: Acee Lindem Thread-Topic: [Editorial Errata Reported] RFC4750 (3292) Thread-Index: AQHNac1hnHxo3J5Hu0SjO6b8YqTJ+Q== Date: Tue, 24 Jul 2012 18:51:27 +0000 Message-ID: References: <20120723092102.7B34162189@rfc-editor.org> <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> <09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> In-Reply-To: <09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.001 x-tm-as-result: No--57.719600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mikek@muonics.com" , "pgalecki@airvana.com" , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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, 24 Jul 2012 18:51:51 -0000 On Jul 24, 2012, at 11:11 AM, Acee Lindem wrote: > Hi Adrian, >=20 > On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: >=20 >> Hi, >>=20 >> This sort of erratum in a MIB module bothers me. >> The trouble is that it changes the compilable content of the module, if = not the >> key parts. >>=20 >> So, the order of process is: >> - Is the erratum correct? >> - Is a fix *required* (i.e., is the module unusable without it?) >> - Can the erratum be held for a revision of the module? >> - How urgent is such a revision? >=20 > Given that RFC 1850 has been around for over 17 years and there are many = existing implementations, I would suffice it to say that this correction wo= uld not in and of itself warrant a revision.=20 > OTOH, there are problems with the OSPFv3 MIB ranges that should be correc= ted with a revision.=20 Can we identify that set of issues? If we can list them along with appropri= ate modifications, the paperwork exercise isn't all that hard (apart from d= ealing with the MIB Doctors). > Thanks, > Acee >=20 >=20 >> - Do we have candidates to revise the document? >>=20 >> Cheers, >> Adrian (speaking as an AD who does MIB modules a bit, but not the AD for= OSPF) >>=20 >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: 24 July 2012 15:51 >>> To: Joan Cucchiara >>> Cc: djoyal@nortel.com; pgalecki@airvana.com; spencer.giacalone@gmail.co= m; >>> fred@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; akr@cisco.com; >>> mikek@muonics.com; ospf@ietf.org >>> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) >>>=20 >>> Hi Joan, >>> If you have a minute could you comment as to: >>> 1. Is the subject Errata correct? >>> 2. If so, does it have any consequence other than editorial content? It >> doesn't >>> appear to me that any MIB tools have complained about it. >>>=20 >>> Thanks, >>> Acee >>>=20 >>> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >>>=20 >>>>=20 >>>> The following errata report has been submitted for RFC4750, >>>> "OSPF Version 2 Management Information Base". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D3292 >>>>=20 >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Michael Kirkham >>>>=20 >>>> Section: 5 >>>>=20 >>>> Original Text >>>> ------------- >>>> ospfTrapCompliance MODULE-COMPLIANCE >>>> STATUS obsolete >>>> DESCRIPTION >>>> "The compliance statement." >>>> MODULE -- this module >>>> MANDATORY-GROUPS { ospfTrapControlGroup } >>>>=20 >>>> GROUP ospfTrapControlGroup >>>> DESCRIPTION >>>> "This group is optional but recommended for all >>>> OSPF systems." >>>> ::=3D { ospfTrapCompliances 1 } >>>>=20 >>>> Corrected Text >>>> -------------- >>>> ospfTrapCompliance MODULE-COMPLIANCE >>>> STATUS obsolete >>>> DESCRIPTION >>>> "The compliance statement." >>>> MODULE -- this module >>>> GROUP ospfTrapControlGroup >>>> DESCRIPTION >>>> "This group is optional but recommended for all >>>> OSPF systems." >>>> ::=3D { ospfTrapCompliances 1 } >>>>=20 >>>> Notes >>>> ----- >>>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and= in >>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (bracket= s >>> added to indicate pertinent rule): >>>>=20 >>>> "5.4.2. Mapping of the GROUP clause >>>>=20 >>>> The GROUP clause, which need not be present, is repeatedly used to >>>> name each object and notification group which is conditionally >>>> mandatory for compliance to the MIB module. The GROUP clause can >>>> also be used to name unconditionally optional groups. [A group named >>>> in a GROUP clause must be absent from the correspondent MANDATORY- >>>> GROUPS clause.]" >>>>=20 >>>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 obsol= etes). >> It is >>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however, obsole= te or >>> not, it is not legal according to SMI rules. >>>>=20 >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>>=20 >>>> -------------------------------------- >>>> RFC4750 (draft-ietf-ospf-mib-update-11) >>>> -------------------------------------- >>>> Title : OSPF Version 2 Management Information Base >>>> Publication Date : December 2006 >>>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed= ., R. >> Coltun, F. >>> Baker >>>> Category : PROPOSED STANDARD >>>> Source : Open Shortest Path First IGP >>>> Area : Routing >>>> Stream : IETF >>>> Verifying Party : IESG >>=20 >>=20 >=20 ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From acee.lindem@ericsson.com Wed Jul 25 06:33:59 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 4513221F85D1 for ; Wed, 25 Jul 2012 06:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 HsO6l2DyNhBk for ; Wed, 25 Jul 2012 06:33:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7721F85CD for ; Wed, 25 Jul 2012 06:33:58 -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 q6PDXls1010025; Wed, 25 Jul 2012 08:33:51 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 25 Jul 2012 09:33:44 -0400 From: Acee Lindem To: "Fred Baker (fred)" Date: Wed, 25 Jul 2012 09:33:42 -0400 Thread-Topic: [Editorial Errata Reported] RFC4750 (3292) Thread-Index: Ac1qahzGA9hzk20LTo+pYOFj+RwCkA== Message-ID: References: <20120723092102.7B34162189@rfc-editor.org> <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> <09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> In-Reply-To: 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-6--156197386"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "mikek@muonics.com" , "pgalecki@airvana.com" , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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: Wed, 25 Jul 2012 13:33:59 -0000 --Apple-Mail-6--156197386 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, On Jul 24, 2012, at 2:51 PM, Fred Baker (fred) wrote: >=20 > On Jul 24, 2012, at 11:11 AM, Acee Lindem wrote: >=20 >> Hi Adrian, >>=20 >> On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: >>=20 >>> Hi, >>>=20 >>> This sort of erratum in a MIB module bothers me. >>> The trouble is that it changes the compilable content of the module, = if not the >>> key parts. >>>=20 >>> So, the order of process is: >>> - Is the erratum correct? >>> - Is a fix *required* (i.e., is the module unusable without it?) >>> - Can the erratum be held for a revision of the module? >>> - How urgent is such a revision? >>=20 >> Given that RFC 1850 has been around for over 17 years and there are = many existing implementations, I would suffice it to say that this = correction would not in and of itself warrant a revision.=20 >> OTOH, there are problems with the OSPFv3 MIB ranges that should be = corrected with a revision.=20 >=20 > Can we identify that set of issues? If we can list them along with = appropriate modifications, the paperwork exercise isn't all that hard = (apart from dealing with the MIB Doctors). At a minimum, we need to fix the fact that ospfv3RestartAge and = ospfv3NbrRestartHelperAge are defined as Ospfv3UpToRefreshIntervalTC = which is Unsigned32 (1..1800). This poses a problem of what to return = when these MIB variables are not applicable since 0 is invalid.=20 We may find some other additions and corrections now that we have some = implementation experience. Speaking as OSPF WG co-chair, we'd be happy = if you would be willing to take on this task.=20 Thanks, Acee=20 >=20 >> Thanks, >> Acee >>=20 >>=20 >>> - Do we have candidates to revise the document? >>>=20 >>> Cheers, >>> Adrian (speaking as an AD who does MIB modules a bit, but not the AD = for OSPF) >>>=20 >>>> -----Original Message----- >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>> Sent: 24 July 2012 15:51 >>>> To: Joan Cucchiara >>>> Cc: djoyal@nortel.com; pgalecki@airvana.com; = spencer.giacalone@gmail.com; >>>> fred@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = akr@cisco.com; >>>> mikek@muonics.com; ospf@ietf.org >>>> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) >>>>=20 >>>> Hi Joan, >>>> If you have a minute could you comment as to: >>>> 1. Is the subject Errata correct? >>>> 2. If so, does it have any consequence other than editorial = content? It >>> doesn't >>>> appear to me that any MIB tools have complained about it. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >>>>=20 >>>>>=20 >>>>> The following errata report has been submitted for RFC4750, >>>>> "OSPF Version 2 Management Information Base". >>>>>=20 >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D3292 >>>>>=20 >>>>> -------------------------------------- >>>>> Type: Editorial >>>>> Reported by: Michael Kirkham >>>>>=20 >>>>> Section: 5 >>>>>=20 >>>>> Original Text >>>>> ------------- >>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>> STATUS obsolete >>>>> DESCRIPTION >>>>> "The compliance statement." >>>>> MODULE -- this module >>>>> MANDATORY-GROUPS { ospfTrapControlGroup } >>>>>=20 >>>>> GROUP ospfTrapControlGroup >>>>> DESCRIPTION >>>>> "This group is optional but recommended for all >>>>> OSPF systems." >>>>> ::=3D { ospfTrapCompliances 1 } >>>>>=20 >>>>> Corrected Text >>>>> -------------- >>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>> STATUS obsolete >>>>> DESCRIPTION >>>>> "The compliance statement." >>>>> MODULE -- this module >>>>> GROUP ospfTrapControlGroup >>>>> DESCRIPTION >>>>> "This group is optional but recommended for all >>>>> OSPF systems." >>>>> ::=3D { ospfTrapCompliances 1 } >>>>>=20 >>>>> Notes >>>>> ----- >>>>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause = and in >>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 = (brackets >>>> added to indicate pertinent rule): >>>>>=20 >>>>> "5.4.2. Mapping of the GROUP clause >>>>>=20 >>>>> The GROUP clause, which need not be present, is repeatedly used to >>>>> name each object and notification group which is conditionally >>>>> mandatory for compliance to the MIB module. The GROUP clause can >>>>> also be used to name unconditionally optional groups. [A group = named >>>>> in a GROUP clause must be absent from the correspondent MANDATORY- >>>>> GROUPS clause.]" >>>>>=20 >>>>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 = obsoletes). >>> It is >>>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however, = obsolete or >>>> not, it is not legal according to SMI rules. >>>>>=20 >>>>> Instructions: >>>>> ------------- >>>>> This errata is currently posted as "Reported". If necessary, = please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>> can log in to change the status and edit the report, if necessary. >>>>>=20 >>>>> -------------------------------------- >>>>> RFC4750 (draft-ietf-ospf-mib-update-11) >>>>> -------------------------------------- >>>>> Title : OSPF Version 2 Management Information Base >>>>> Publication Date : December 2006 >>>>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. = Giacalone, Ed., R. >>> Coltun, F. >>>> Baker >>>>> Category : PROPOSED STANDARD >>>>> Source : Open Shortest Path First IGP >>>>> Area : Routing >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>=20 >>>=20 >>=20 >=20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan >=20 --Apple-Mail-6--156197386 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcyNTEzMzM0M1owIwYJKoZI hvcNAQkEMRYEFFBsmUz7Pg7zk+xMPoizGyYQdGSTMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgAEc5Is1SeH3n1BJTnHLTYQ3Zx9o4HE3R3bX8BjKWLtecCDaOjyTsXhJjqY93S3G 9KlNceLLi9IOAtqyF+JlOKu+WrB76dg6cC8JiHsm6Hd/hUOtu7wYh71vhfkffIq8DAyBN1hgRa/Z O4+sOXGL+b8TMwJBFo2/3tHabSxL2MjdAAAAAAAA --Apple-Mail-6--156197386-- From joyald@avaya.com Wed Jul 25 08:17:57 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 3994E21F860B for ; Wed, 25 Jul 2012 08:17:57 -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 y56IPbF4cs5D for ; Wed, 25 Jul 2012 08:17:56 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB521F84DA for ; Wed, 25 Jul 2012 08:17:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKMNEFDGmAcF/2dsb2JhbAArEAq5Y4EHgiABAQEBAgESKD8MBAIBCA0EBAEBAR4JByERFAkIAQEEAQ0FCAEZh1wDBgYLKZ1Zk3sNiU6KZWgQCoV6YAOTdAGHUYUNhQOCe1Nw X-IronPort-AV: E=Sophos;i="4.77,653,1336363200"; d="scan'208";a="19551007" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Jul 2012 11:12:38 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jul 2012 11:13:37 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 25 Jul 2012 11:17:40 -0400 From: "Joyal, Daniel R (Dan)" To: Acee Lindem , "Fred Baker (fred)" Date: Wed, 25 Jul 2012 11:17:37 -0400 Thread-Topic: [Editorial Errata Reported] RFC4750 (3292) Thread-Index: Ac1qahzGA9hzk20LTo+pYOFj+RwCkAADd/Bg Message-ID: <168240A9D13F2F4480E0A7641A914D9622EABF6085@DC-US1MBEX4.global.avaya.com> References: <20120723092102.7B34162189@rfc-editor.org> <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> <09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> 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" , "mikek@muonics.com" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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: Wed, 25 Jul 2012 15:17:57 -0000 Some relevant e-mail on the topic. http://www.ietf.org/mail-archive/web/ospf/current/msg05876.html -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Wednesday, July 25, 2012 9:34 AM To: Fred Baker (fred) Cc: mikek@muonics.com; pgalecki@airvana.com; djoyal@nortel.com; ospf@ietf.o= rg Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) Hi Fred, On Jul 24, 2012, at 2:51 PM, Fred Baker (fred) wrote: >=20 > On Jul 24, 2012, at 11:11 AM, Acee Lindem wrote: >=20 >> Hi Adrian, >>=20 >> On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: >>=20 >>> Hi, >>>=20 >>> This sort of erratum in a MIB module bothers me. >>> The trouble is that it changes the compilable content of the module,=20 >>> if not the key parts. >>>=20 >>> So, the order of process is: >>> - Is the erratum correct? >>> - Is a fix *required* (i.e., is the module unusable without it?) >>> - Can the erratum be held for a revision of the module? >>> - How urgent is such a revision? >>=20 >> Given that RFC 1850 has been around for over 17 years and there are many= existing implementations, I would suffice it to say that this correction w= ould not in and of itself warrant a revision.=20 >> OTOH, there are problems with the OSPFv3 MIB ranges that should be corre= cted with a revision.=20 >=20 > Can we identify that set of issues? If we can list them along with approp= riate modifications, the paperwork exercise isn't all that hard (apart from= dealing with the MIB Doctors). At a minimum, we need to fix the fact that ospfv3RestartAge and ospfv3NbrRe= startHelperAge are defined as Ospfv3UpToRefreshIntervalTC which is Unsigne= d32 (1..1800). This poses a problem of what to return when these MIB variab= les are not applicable since 0 is invalid.=20 We may find some other additions and corrections now that we have some impl= ementation experience. Speaking as OSPF WG co-chair, we'd be happy if you w= ould be willing to take on this task.=20 Thanks, Acee=20 >=20 >> Thanks, >> Acee >>=20 >>=20 >>> - Do we have candidates to revise the document? >>>=20 >>> Cheers, >>> Adrian (speaking as an AD who does MIB modules a bit, but not the AD=20 >>> for OSPF) >>>=20 >>>> -----Original Message----- >>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>> Sent: 24 July 2012 15:51 >>>> To: Joan Cucchiara >>>> Cc: djoyal@nortel.com; pgalecki@airvana.com;=20 >>>> spencer.giacalone@gmail.com; fred@cisco.com; stbryant@cisco.com;=20 >>>> adrian@olddog.co.uk; akr@cisco.com; mikek@muonics.com;=20 >>>> ospf@ietf.org >>>> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) >>>>=20 >>>> Hi Joan, >>>> If you have a minute could you comment as to: >>>> 1. Is the subject Errata correct? >>>> 2. If so, does it have any consequence other than editorial=20 >>>> content? It >>> doesn't >>>> appear to me that any MIB tools have complained about it. >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >>>>=20 >>>>>=20 >>>>> The following errata report has been submitted for RFC4750, "OSPF=20 >>>>> Version 2 Management Information Base". >>>>>=20 >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D3292 >>>>>=20 >>>>> -------------------------------------- >>>>> Type: Editorial >>>>> Reported by: Michael Kirkham >>>>>=20 >>>>> Section: 5 >>>>>=20 >>>>> Original Text >>>>> ------------- >>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>> STATUS obsolete >>>>> DESCRIPTION >>>>> "The compliance statement." >>>>> MODULE -- this module >>>>> MANDATORY-GROUPS { ospfTrapControlGroup } >>>>>=20 >>>>> GROUP ospfTrapControlGroup >>>>> DESCRIPTION >>>>> "This group is optional but recommended for all >>>>> OSPF systems." >>>>> ::=3D { ospfTrapCompliances 1 } >>>>>=20 >>>>> Corrected Text >>>>> -------------- >>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>> STATUS obsolete >>>>> DESCRIPTION >>>>> "The compliance statement." >>>>> MODULE -- this module >>>>> GROUP ospfTrapControlGroup >>>>> DESCRIPTION >>>>> "This group is optional but recommended for all >>>>> OSPF systems." >>>>> ::=3D { ospfTrapCompliances 1 } >>>>>=20 >>>>> Notes >>>>> ----- >>>>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause=20 >>>>> and in >>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2=20 >>>> (brackets added to indicate pertinent rule): >>>>>=20 >>>>> "5.4.2. Mapping of the GROUP clause >>>>>=20 >>>>> The GROUP clause, which need not be present, is repeatedly used to=20 >>>>> name each object and notification group which is conditionally=20 >>>>> mandatory for compliance to the MIB module. The GROUP clause can=20 >>>>> also be used to name unconditionally optional groups. [A group=20 >>>>> named in a GROUP clause must be absent from the correspondent=20 >>>>> MANDATORY- GROUPS clause.]" >>>>>=20 >>>>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 obso= letes). >>> It is >>>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however,=20 >>>> obsolete or not, it is not legal according to SMI rules. >>>>>=20 >>>>> Instructions: >>>>> ------------- >>>>> This errata is currently posted as "Reported". If necessary,=20 >>>>> please use "Reply All" to discuss whether it should be verified or=20 >>>>> rejected. When a decision is reached, the verifying party (IESG)=20 >>>>> can log in to change the status and edit the report, if necessary. >>>>>=20 >>>>> -------------------------------------- >>>>> RFC4750 (draft-ietf-ospf-mib-update-11) >>>>> -------------------------------------- >>>>> Title : OSPF Version 2 Management Information Base >>>>> Publication Date : December 2006 >>>>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, E= d., R. >>> Coltun, F. >>>> Baker >>>>> Category : PROPOSED STANDARD >>>>> Source : Open Shortest Path First IGP >>>>> Area : Routing >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>=20 >>>=20 >>=20 >=20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan >=20 From fred@cisco.com Wed Jul 25 11:59:02 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 6CB3221F8715 for ; Wed, 25 Jul 2012 11:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ToXI3hsW6-O6 for ; Wed, 25 Jul 2012 11:59:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF6021F870A for ; Wed, 25 Jul 2012 11:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=10081; q=dns/txt; s=iport; t=1343242741; x=1344452341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m7rdGSG7fDQm4B84Yzu6SpNH0uP94GZ8d1EluHPFZoU=; b=U80uuJp+0H4CsEIk3SEoVALUWJDAMhLukWtiqPvUzS+mHqCKy222OhDA OHcuCqz0y9hGfGn831NOTgpYA9DphlL0Zc797Io7LpCfsjzdZr3oHp9oQ Wr6DJieGjCHDNXYXYtwbDHQOyQLzavpy5dDXZGncfpe2qLTLAmylEnLtH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADVBEFCtJXG9/2dsb2JhbAArEAq5TYEHgiABAQEDARIBJzQLBQcEAgEIEQQBAQEeCQchERQJCAIEDgUih1wDBgYLKZsFlm0NiU6KZWgQhgRgA5N1gVSBFIl2gx2BZoJfbw X-IronPort-AV: E=Sophos;i="4.77,654,1336348800"; d="scan'208";a="105274318" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2012 18:59:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6PIx0i7021573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 18:59:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 13:59:00 -0500 From: "Fred Baker (fred)" To: Acee Lindem Thread-Topic: [Editorial Errata Reported] RFC4750 (3292) Thread-Index: AQHNac1hnHxo3J5Hu0SjO6b8YqTJ+Q== Date: Wed, 25 Jul 2012 18:59:34 +0000 Message-ID: References: <20120723092102.7B34162189@rfc-editor.org> <7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com> <050401cd69c6$1d2c8370$57858a50$@olddog.co.uk> <09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.001 x-tm-as-result: No--53.862700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8163E0A263CB0D40A1D4569A18250EF9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mikek@muonics.com" , "pgalecki@airvana.com" , "djoyal@nortel.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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: Wed, 25 Jul 2012 18:59:02 -0000 On Jul 25, 2012, at 6:33 AM, Acee Lindem wrote: > Hi Fred, >=20 > On Jul 24, 2012, at 2:51 PM, Fred Baker (fred) wrote: >=20 >>=20 >> On Jul 24, 2012, at 11:11 AM, Acee Lindem wrote: >>=20 >>> Hi Adrian, >>>=20 >>> On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: >>>=20 >>>> Hi, >>>>=20 >>>> This sort of erratum in a MIB module bothers me. >>>> The trouble is that it changes the compilable content of the module, i= f not the >>>> key parts. >>>>=20 >>>> So, the order of process is: >>>> - Is the erratum correct? >>>> - Is a fix *required* (i.e., is the module unusable without it?) >>>> - Can the erratum be held for a revision of the module? >>>> - How urgent is such a revision? >>>=20 >>> Given that RFC 1850 has been around for over 17 years and there are man= y existing implementations, I would suffice it to say that this correction = would not in and of itself warrant a revision.=20 >>> OTOH, there are problems with the OSPFv3 MIB ranges that should be corr= ected with a revision.=20 >>=20 >> Can we identify that set of issues? If we can list them along with appro= priate modifications, the paperwork exercise isn't all that hard (apart fro= m dealing with the MIB Doctors). >=20 > At a minimum, we need to fix the fact that ospfv3RestartAge and ospfv3Nbr= RestartHelperAge are defined as Ospfv3UpToRefreshIntervalTC which is Unsig= ned32 (1..1800). This poses a problem of what to return when these MIB vari= ables are not applicable since 0 is invalid.=20 > We may find some other additions and corrections now that we have some im= plementation experience. Speaking as OSPF WG co-chair, we'd be happy if you= would be willing to take on this task.=20 If the object is inapplicable, why would it not be treated as if it didn't = exist in the scenario? On a GET, return noSuchObject, and on a GET-NEXT or = GET-BULK, skip it? Both objects are read-only. Do we have an erratum on the= se? If you want to return a magic value such as zero, that's a change to the TC= plus some text to the effect that "zero is only used in" this case. There = are a number of other objects that use the TC; if you don't see a need to c= hange them (and you probably really don't want to be able to configure, to = name one, ospfv3IfRetransInterval to zero), we're better off simply redefin= ing the two objects as Integer32(0..1800) or defining a new TC and changing= the object definitions to that. This suggestion might make the MIB Doctors= crazy; as I understand it, the data on the wire will be Integer32(0..1800)= no matter what, so the TC change is cosmetic. I would assume "there be dra= gons here" until someone from MIB-land tells me otherwise. Spinning a MIB triggers a lot of reviews; it would be good to know who has = implemented this and what their experience has been, from the perspective o= f taking RFC 5643 to Draft Standard (https://tools.ietf.org/html/rfc2026#se= ction-4.1.2) or Internet Standard (RFC 6410). Looking on the web, I found at least two implementations, one of which is r= ead-only and doesn't implement 26 of the objects. ospfv3HostAddressType ospfv3HostAddress ospfv3HostMetric ospfv3HostRowStatus ospfv3HostAreaID ospfv3CfgNbrTable ospfv3ExitOverflowInterval ospfv3ReferenceBandwidth ospfv3RestartSupport ospfv3RestartInterval ospfv3RestartStrictLsaChecking ospfv3RestartStatus ospfv3RestartAge ospfv3RestartExitReason ospfv3NotificationEnable ospfv3StubRouterSupport ospfv3StubRouterAdvertisement ospfv3DiscontinuityTime ospfv3RestartTime ospfv3AreaNssaTranslatorRole ospfv3AreaNssaTranslatorState ospfv3AreaNssaTranslatorStabInterval ospfv3AreaNssaTranslatorEvents ospfv3AreaTEEnabled ospfv3IfMetricValue ospfv3IfDemandNbrProbe As I understand it, going to Draft Standard or Internet Standard (are we on= the 2026 or 6410 model?) means removal/deprecation of anything we can't sh= ow multiple interoperable implementation of. Really? What I found: http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.2/routing/confi= guration/guide/b_routing_cg42crs_chapter_0100.html#concept_0B3C41DB4B9C4BA3= 9FB2B1BDA0A777CD http://www.juniper.net/techpubs/en_US/junos/topics/reference/standards/snmp= -std-mibs-junos-nm.html (search for "5643"). I'm not sure about Quagga's status. Google.com reports mostly that Quagga d= oesn't implement the MIB, but I found a reference at code.google.com to the= effect that Google has developed an open source implementation; the code t= he link takes me to is for GNU Zebra. I think we would need to know who else has implemented it and what they hav= e done with it. And to be honest, I personally would like to hear a little = more "use in anger" before getting all revved up on this. My suggestion: At this particular meeting, while I have a topic I would lik= e to kick around with Jari and others on the zospf-redux model he's working= on, I am scheduled into opsawg at the same time as ospf at IETF 84, and I = don't think the MIB is ready to have a f2f discussion on. It's suggest that= we kick it around on the mailing list with a view to f2f discussion at IET= F 85 or 86. > Thanks, > Acee=20 >=20 >=20 >>=20 >>> Thanks, >>> Acee >>>=20 >>>=20 >>>> - Do we have candidates to revise the document? >>>>=20 >>>> Cheers, >>>> Adrian (speaking as an AD who does MIB modules a bit, but not the AD f= or OSPF) >>>>=20 >>>>> -----Original Message----- >>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>>>> Sent: 24 July 2012 15:51 >>>>> To: Joan Cucchiara >>>>> Cc: djoyal@nortel.com; pgalecki@airvana.com; spencer.giacalone@gmail.= com; >>>>> fred@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; akr@cisco.co= m; >>>>> mikek@muonics.com; ospf@ietf.org >>>>> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) >>>>>=20 >>>>> Hi Joan, >>>>> If you have a minute could you comment as to: >>>>> 1. Is the subject Errata correct? >>>>> 2. If so, does it have any consequence other than editorial content? = It >>>> doesn't >>>>> appear to me that any MIB tools have complained about it. >>>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >>>>>=20 >>>>>>=20 >>>>>> The following errata report has been submitted for RFC4750, >>>>>> "OSPF Version 2 Management Information Base". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4750&eid=3D3292 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Editorial >>>>>> Reported by: Michael Kirkham >>>>>>=20 >>>>>> Section: 5 >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>>> STATUS obsolete >>>>>> DESCRIPTION >>>>>> "The compliance statement." >>>>>> MODULE -- this module >>>>>> MANDATORY-GROUPS { ospfTrapControlGroup } >>>>>>=20 >>>>>> GROUP ospfTrapControlGroup >>>>>> DESCRIPTION >>>>>> "This group is optional but recommended for all >>>>>> OSPF systems." >>>>>> ::=3D { ospfTrapCompliances 1 } >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>>> STATUS obsolete >>>>>> DESCRIPTION >>>>>> "The compliance statement." >>>>>> MODULE -- this module >>>>>> GROUP ospfTrapControlGroup >>>>>> DESCRIPTION >>>>>> "This group is optional but recommended for all >>>>>> OSPF systems." >>>>>> ::=3D { ospfTrapCompliances 1 } >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause a= nd in >>>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (brack= ets >>>>> added to indicate pertinent rule): >>>>>>=20 >>>>>> "5.4.2. Mapping of the GROUP clause >>>>>>=20 >>>>>> The GROUP clause, which need not be present, is repeatedly used to >>>>>> name each object and notification group which is conditionally >>>>>> mandatory for compliance to the MIB module. The GROUP clause can >>>>>> also be used to name unconditionally optional groups. [A group name= d >>>>>> in a GROUP clause must be absent from the correspondent MANDATORY- >>>>>> GROUPS clause.]" >>>>>>=20 >>>>>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 obs= oletes). >>>> It is >>>>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however, obso= lete or >>>>> not, it is not legal according to SMI rules. >>>>>>=20 >>>>>> Instructions: >>>>>> ------------- >>>>>> This errata is currently posted as "Reported". If necessary, please >>>>>> use "Reply All" to discuss whether it should be verified or >>>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>>> can log in to change the status and edit the report, if necessary. >>>>>>=20 >>>>>> -------------------------------------- >>>>>> RFC4750 (draft-ietf-ospf-mib-update-11) >>>>>> -------------------------------------- >>>>>> Title : OSPF Version 2 Management Information Base >>>>>> Publication Date : December 2006 >>>>>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, = Ed., R. >>>> Coltun, F. >>>>> Baker >>>>>> Category : PROPOSED STANDARD >>>>>> Source : Open Shortest Path First IGP >>>>>> Area : Routing >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>=20 >>>>=20 >>>=20 >>=20 >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially.=20 >> - Marshall McLuhan >>=20 >=20 ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From ietfc@btconnect.com Thu Jul 26 10:02:22 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 EA31021F861E for ; Thu, 26 Jul 2012 10:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uiPFvLIGZMIf for ; Thu, 26 Jul 2012 10:02:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2377921F8619 for ; Thu, 26 Jul 2012 10:02:21 -0700 (PDT) Received: from mail115-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jul 2012 17:02:20 +0000 Received: from mail115-am1 (localhost [127.0.0.1]) by mail115-am1-R.bigfish.com (Postfix) with ESMTP id 262511C05DC; Thu, 26 Jul 2012 17:02:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I542M1432I4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1 (MessageSwitch) id 1343322109789089_30349; Thu, 26 Jul 2012 17:01:49 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.240]) by mail115-am1.bigfish.com (Postfix) with ESMTP id 526D6200329; Thu, 26 Jul 2012 17:01:45 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jul 2012 17:01:43 +0000 Received: from DB3PRD0410HT005.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.86.1; Thu, 26 Jul 2012 17:01:41 +0000 Message-ID: <01cf01cd6b4f$bebf2a00$4001a8c0@gateway.2wire.net> From: t.petch To: "Fred Baker (fred)" , Acee Lindem References: <20120723092102.7B34162189@rfc-editor.org><7473805B-BD37-48F4-9A7D-59F4D827128C@ericsson.com><050401cd69c6$1d2c8370$57858a50$@olddog.co.uk><09EDC16F-7FFD-4327-9145-F1D7C3EA21C9@ericsson.com> Date: Thu, 26 Jul 2012 17:57:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.21] X-OriginatorOrg: btconnect.com Cc: pgalecki@airvana.com, ospf@ietf.org, mikek@muonics.com, djoyal@nortel.com Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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, 26 Jul 2012 17:02:23 -0000 Fred RFC2578 s10.2 would allow a SYNTAX to be replaced by a textual convention, but not vice versa. I am trying to see the lurking dragon but have yet to do so. I agree that spinning a MIB module is a lot of work and on the evidence to date, the benefits seem limited. Tom Petch ----- Original Message ----- From: "Fred Baker (fred)" To: "Acee Lindem" Cc: ; ; ; Sent: Wednesday, July 25, 2012 7:59 PM > > On Jul 25, 2012, at 6:33 AM, Acee Lindem wrote: > > On Jul 24, 2012, at 2:51 PM, Fred Baker (fred) wrote: > >> On Jul 24, 2012, at 11:11 AM, Acee Lindem wrote: > >>> On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: > >>> > >>>> This sort of erratum in a MIB module bothers me. > >>>> The trouble is that it changes the compilable content of the module, if not the > >>>> key parts. > >>>> > >>>> So, the order of process is: > >>>> - Is the erratum correct? > >>>> - Is a fix *required* (i.e., is the module unusable without it?) > >>>> - Can the erratum be held for a revision of the module? > >>>> - How urgent is such a revision? > >>> > >>> Given that RFC 1850 has been around for over 17 years and there are many existing implementations, I would suffice it to say that this correction would not in and of itself warrant a revision. > >>> OTOH, there are problems with the OSPFv3 MIB ranges that should be corrected with a revision. > >> > >> Can we identify that set of issues? If we can list them along with appropriate modifications, the paperwork exercise isn't all that hard (apart from dealing with the MIB Doctors). > > > > At a minimum, we need to fix the fact that ospfv3RestartAge and ospfv3NbrRestartHelperAge are defined as Ospfv3UpToRefreshIntervalTC which is Unsigned32 (1..1800). This poses a problem of what to return when these MIB variables are not applicable since 0 is invalid. > > We may find some other additions and corrections now that we have some implementation experience. Speaking as OSPF WG co-chair, we'd be happy if you would be willing to take on this task. > > If the object is inapplicable, why would it not be treated as if it didn't exist in the scenario? On a GET, return noSuchObject, and on a GET-NEXT or GET-BULK, skip it? Both objects are read-only. Do we have an erratum on these? > > If you want to return a magic value such as zero, that's a change to the TC plus some text to the effect that "zero is only used in" this case. There are a number of other objects that use the TC; if you don't see a need to change them (and you probably really don't want to be able to configure, to name one, ospfv3IfRetransInterval to zero), we're better off simply redefining the two objects as Integer32(0..1800) or defining a new TC and changing the object definitions to that. This suggestion might make the MIB Doctors crazy; as I understand it, the data on the wire will be Integer32(0..1800) no matter what, so the TC change is cosmetic. I would assume "there be dragons here" until someone from MIB-land tells me otherwise. > > Spinning a MIB triggers a lot of reviews; it would be good to know who has implemented this and what their experience has been, from the perspective of taking RFC 5643 to Draft Standard (https://tools.ietf.org/html/rfc2026#section-4.1.2) or Internet Standard (RFC 6410). > > Looking on the web, I found at least two implementations, one of which is read-only and doesn't implement 26 of the objects. > > ospfv3HostAddressType > ospfv3HostAddress > ospfv3HostMetric > ospfv3HostRowStatus > ospfv3HostAreaID > ospfv3CfgNbrTable > ospfv3ExitOverflowInterval > ospfv3ReferenceBandwidth > ospfv3RestartSupport > ospfv3RestartInterval > ospfv3RestartStrictLsaChecking > ospfv3RestartStatus > ospfv3RestartAge > ospfv3RestartExitReason > ospfv3NotificationEnable > ospfv3StubRouterSupport > ospfv3StubRouterAdvertisement > ospfv3DiscontinuityTime > ospfv3RestartTime > ospfv3AreaNssaTranslatorRole > ospfv3AreaNssaTranslatorState > ospfv3AreaNssaTranslatorStabInterval > ospfv3AreaNssaTranslatorEvents > ospfv3AreaTEEnabled > ospfv3IfMetricValue > ospfv3IfDemandNbrProbe > > As I understand it, going to Draft Standard or Internet Standard (are we on the 2026 or 6410 model?) means removal/deprecation of anything we can't show multiple interoperable implementation of. Really? > > > What I found: > http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.2/routing/co nfiguration/guide/b_routing_cg42crs_chapter_0100.html#concept_0B3C41DB4B 9C4BA39FB2B1BDA0A777CD > > http://www.juniper.net/techpubs/en_US/junos/topics/reference/standards/s nmp-std-mibs-junos-nm.html (search for "5643"). > > I'm not sure about Quagga's status. Google.com reports mostly that Quagga doesn't implement the MIB, but I found a reference at code.google.com to the effect that Google has developed an open source implementation; the code the link takes me to is for GNU Zebra. > > I think we would need to know who else has implemented it and what they have done with it. And to be honest, I personally would like to hear a little more "use in anger" before getting all revved up on this. > > > My suggestion: At this particular meeting, while I have a topic I would like to kick around with Jari and others on the zospf-redux model he's working on, I am scheduled into opsawg at the same time as ospf at IETF 84, and I don't think the MIB is ready to have a f2f discussion on. It's suggest that we kick it around on the mailing list with a view to f2f discussion at IETF 85 or 86. > > > Thanks, > > Acee > > > > > >> > >>> Thanks, > >>> Acee > >>> > >>> > >>>> - Do we have candidates to revise the document? > >>>> > >>>> Cheers, > >>>> Adrian (speaking as an AD who does MIB modules a bit, but not the AD for OSPF) > >>>> > >>>>> -----Original Message----- > >>>>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] > >>>>> Sent: 24 July 2012 15:51 > >>>>> To: Joan Cucchiara > >>>>> Cc: djoyal@nortel.com; pgalecki@airvana.com; spencer.giacalone@gmail.com; > >>>>> fred@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; akr@cisco.com; > >>>>> mikek@muonics.com; ospf@ietf.org > >>>>> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) > >>>>> > >>>>> Hi Joan, > >>>>> If you have a minute could you comment as to: > >>>>> 1. Is the subject Errata correct? > >>>>> 2. If so, does it have any consequence other than editorial content? It > >>>> doesn't > >>>>> appear to me that any MIB tools have complained about it. > >>>>> > >>>>> Thanks, > >>>>> Acee > >>>>> > >>>>> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: > >>>>> > >>>>>> > >>>>>> The following errata report has been submitted for RFC4750, > >>>>>> "OSPF Version 2 Management Information Base". > >>>>>> > >>>>>> -------------------------------------- > >>>>>> You may review the report below and at: > >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=4750&eid=3292 > >>>>>> > >>>>>> -------------------------------------- > >>>>>> Type: Editorial > >>>>>> Reported by: Michael Kirkham > >>>>>> > >>>>>> Section: 5 > >>>>>> > >>>>>> Original Text > >>>>>> ------------- > >>>>>> ospfTrapCompliance MODULE-COMPLIANCE > >>>>>> STATUS obsolete > >>>>>> DESCRIPTION > >>>>>> "The compliance statement." > >>>>>> MODULE -- this module > >>>>>> MANDATORY-GROUPS { ospfTrapControlGroup } > >>>>>> > >>>>>> GROUP ospfTrapControlGroup > >>>>>> DESCRIPTION > >>>>>> "This group is optional but recommended for all > >>>>>> OSPF systems." > >>>>>> ::= { ospfTrapCompliances 1 } > >>>>>> > >>>>>> Corrected Text > >>>>>> -------------- > >>>>>> ospfTrapCompliance MODULE-COMPLIANCE > >>>>>> STATUS obsolete > >>>>>> DESCRIPTION > >>>>>> "The compliance statement." > >>>>>> MODULE -- this module > >>>>>> GROUP ospfTrapControlGroup > >>>>>> DESCRIPTION > >>>>>> "This group is optional but recommended for all > >>>>>> OSPF systems." > >>>>>> ::= { ospfTrapCompliances 1 } > >>>>>> > >>>>>> Notes > >>>>>> ----- > >>>>>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and in > >>>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (brackets > >>>>> added to indicate pertinent rule): > >>>>>> > >>>>>> "5.4.2. Mapping of the GROUP clause > >>>>>> > >>>>>> The GROUP clause, which need not be present, is repeatedly used to > >>>>>> name each object and notification group which is conditionally > >>>>>> mandatory for compliance to the MIB module. The GROUP clause can > >>>>>> also be used to name unconditionally optional groups. [A group named > >>>>>> in a GROUP clause must be absent from the correspondent MANDATORY- > >>>>>> GROUPS clause.]" > >>>>>> > >>>>>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 obsoletes). > >>>> It is > >>>>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however, obsolete or > >>>>> not, it is not legal according to SMI rules. > >>>>>> > >>>>>> Instructions: > >>>>>> ------------- > >>>>>> This errata is currently posted as "Reported". If necessary, please > >>>>>> use "Reply All" to discuss whether it should be verified or > >>>>>> rejected. When a decision is reached, the verifying party (IESG) > >>>>>> can log in to change the status and edit the report, if necessary. > >>>>>> > >>>>>> -------------------------------------- > >>>>>> RFC4750 (draft-ietf-ospf-mib-update-11) > >>>>>> -------------------------------------- > >>>>>> Title : OSPF Version 2 Management Information Base > >>>>>> Publication Date : December 2006 > >>>>>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. > >>>> Coltun, F. > >>>>> Baker > >>>>>> Category : PROPOSED STANDARD > >>>>>> Source : Open Shortest Path First IGP > >>>>>> Area : Routing > >>>>>> Stream : IETF > >>>>>> Verifying Party : IESG > >>>> From acee.lindem@ericsson.com Mon Jul 30 09:58:11 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 C6D5A11E8152 for ; Mon, 30 Jul 2012 09:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XwJQFlGCm7hi for ; Mon, 30 Jul 2012 09:58:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A811E8150 for ; Mon, 30 Jul 2012 09:58:11 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6UGw8Lu011343 for ; Mon, 30 Jul 2012 11:58:10 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 30 Jul 2012 12:58:06 -0400 From: Acee Lindem To: OSPF List Date: Mon, 30 Jul 2012 12:58:05 -0400 Thread-Topic: Need volunteers for the NomCom Thread-Index: Ac1udH07azMIirSeQr+XjPzqp8vFYg== Message-ID: References: <20120730032233.17770.35790.idtracker@ietfa.amsl.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-5-288065480"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] Fwd: Need volunteers for the NomCom 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, 30 Jul 2012 16:58:11 -0000 --Apple-Mail-5-288065480 Content-Type: multipart/alternative; boundary=Apple-Mail-4-288065465 --Apple-Mail-4-288065465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you are eligible, please consider volunteering.=20 Acee=20 Begin forwarded message: > From: NomCom Chair > Date: July 29, 2012 11:22:33 PM EDT > To: Working Group Chairs > Subject: Need volunteers for the NomCom >=20 > We are currently looking for volunteers to serve on the 2012-2013 = NomCom. > As you know, the success of the NomCom process depends crucially on=20 > having a large pool of volunteers from throughout the IETF community.=20= > In particular, it is valuable for the pool of volunteers to have = strong=20 > representation from all of the technical areas within the IETF.=20 >=20 > I understand that not all IETF participants read the IETF announce = list=20 > frequently. Therefore, if you would be willing to inform active = participants=20 > in your working groups about this year's call for NomCom volunteers, I=20= > would greatly appreciate it.=20 >=20 > The NomCom 2012-2013 Call for Volunteers is open until this Sunday,=20 > August 5. Details can be found at: = https://datatracker.ietf.org/ann/nomcom/49851/ >=20 > Thank you for your help, > - Matt Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org --Apple-Mail-4-288065465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If = you are eligible, please consider = volunteering. 
Acee 

Begin forwarded = message:

From: NomCom Chair <nomcom-chair@ietf.org>
Date: July 29, 2012 11:22:33 PM EDT
To: Working Group = Chairs <wgchairs@ietf.org>
Subject: Need volunteers = for the NomCom

We are currently looking for = volunteers to serve on the 2012-2013 NomCom.
As you know, the success = of the NomCom process depends crucially on
having a large pool of = volunteers from throughout the IETF community.
In particular, it is = valuable for the pool of volunteers to have strong
representation = from all of the technical areas within the IETF.

I understand = that not all IETF participants read the IETF announce list =
frequently. Therefore, if you would be willing to inform active = participants
in your working groups about this year's call for = NomCom volunteers, I
would greatly appreciate it.

The NomCom = 2012-2013 Call for Volunteers is open until this Sunday,
August 5. = Details can be found at: https://datatracke= r.ietf.org/ann/nomcom/49851/

Thank you for your help,
- = Matt Lepinski
 mlepinski.ietf@gmail.com
=  nomcom-chair@ietf.org
<= /blockquote>

= --Apple-Mail-4-288065465-- --Apple-Mail-5-288065480 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDczMDE2NTgwNVowIwYJKoZI hvcNAQkEMRYEFKUgrA8UH4BJpcIH518sUB5KqvvAMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgH5CMXj2ORPlh2dK5GsACeFBnlfieCCpiPnWmb8Tyawr02hvaTkda55fZkhzcyrw EFNx3J/khZ2fxjQl2hwtGo57QJ8he4FM9lKi50wEPAsgFMzT9Nz9WSVXdUmSRucalirT3+nlXWq9 XTRjAQbJbaJ45bUlfAZzzM4wka3DMXXMAAAAAAAA --Apple-Mail-5-288065480--