From acee.lindem@ericsson.com Fri Jun 1 13:56:55 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 BD47221F8A01 for ; Fri, 1 Jun 2012 13:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 vz49-C6fpkYu for ; Fri, 1 Jun 2012 13:56:54 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A38B321F89FF for ; Fri, 1 Jun 2012 13:56:54 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q51Kujvs015124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Jun 2012 15:56:53 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 1 Jun 2012 16:56:44 -0400 From: Acee Lindem To: Michael Barnes Date: Fri, 1 Jun 2012 16:56:42 -0400 Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt Thread-Index: Ac1AOQ0oQBn2xCWuSrOWk49W7eFTKQ== Message-ID: <24323E1E-1D5B-4CC9-B1DD-F8FA9808DB78@ericsson.com> References: <310qeEVIU5616S02.1338500146@web02.cms.usa.net> In-Reply-To: <310qeEVIU5616S02.1338500146@web02.cms.usa.net> 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-59--500250477"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: OSPF List , Jari Arkko 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: Fri, 01 Jun 2012 20:56:55 -0000 --Apple-Mail-59--500250477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi MIchael - I agree. Even if we use the reserved IPv4 instance ID, it = should be documented. Thanks, Acee=20 On May 31, 2012, at 5:35 PM, Michael Barnes wrote: > Hi Acee, >=20 > If you do use a reserved instance ID, then there should be one per = address > family in accordance with RFC5838. This is needed to allow for the = fact that > we use a different instances for each AF. >=20 > Regards, > Michael >=20 > ------ Original Message ------ > Received: Thu, 31 May 2012 02:22:21 PM PDT > From: Acee Lindem > To: "Retana, Alvaro" Cc: OSPF List = , Jari > Arkko > Subject: Re: [OSPF] New Version Notification for > draft-acee-ospf-ospfv3-autoconfig-02.txt >=20 >>=20 >> On May 31, 2012, at 4:13 PM, Retana, Alvaro wrote: >>=20 >>> Acee: >>>=20 >>> OK=85but deciding on what to do on a specific deployment without = manually > configuring the router is not trivial. >>>=20 >>> As far as other parameters, the draft seems to specify fixed values = which > are not specific to a deployment. >>=20 >> That's why interaction between configured and auto-configured routers > doesn't seem like a likely deployment and using a reserved instance ID = seems > reasonable. =20 >>=20 >> Acee=20 >>=20 >>=20 >>=20 >>>=20 >>> BTW, the draft reads =93OSPFv3 interfaces MUST auto-configure the = default > HelloInterval and RouterDeadInterval as specified in [OSPFV3].=94..but = rfc5340 > doesn=92t actually specify a default value, just provides examples: >>>=20 >>> HelloInterval >>> The length of time, in seconds, between Hello packets that the >>> router sends on the interface. This value is advertised in the >>> router's Hello packets. It MUST be the same for all routers >>> attached to a common link. The smaller the HelloInterval, the >>> faster topological changes will be detected. However, more = OSPF >>> routing protocol traffic will ensue. Sample value for a X.25 = PDN: >>> 30 seconds. Sample value for a local area network (LAN): 10 >>> seconds. >>>=20 >>> RouterDeadInterval >>> After ceasing to hear a router's Hello packets, the number of >>> seconds before its neighbors declare the router down. This is >>> also advertised in the router's Hello packets in their >>> RouterDeadInterval field. This should be some multiple of the >>> HelloInterval (e.g., 4). This value again MUST be the same for >>> all routers attached to a common link. >>>=20 >>> Alvaro. >>>=20 >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >>> Sent: Thursday, May 31, 2012 11:44 AM >>> To: Retana, Alvaro >>> Cc: OSPF List; Jari Arkko >>> Subject: Re: New Version Notification for > draft-acee-ospf-ospfv3-autoconfig-02.txt >>>=20 >>>=20 >>> On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote: >>>=20 >>>=20 >>> Hi! >>>=20 >>> My reason for the suggestion was that requiring a special instance = ID > (even if well known) takes away from the auto-* properties by = requiring other > routers to behave in a special way. IOW, the use case of adding an > auto-configuration-capable router to an existing network would not be = possible > w/out additional configuration and/or hacks. >>>=20 >>> I obviously like option #2. J >>>=20 >>> IMHO, option #3 is not good because it still requires the > auto-configuration-capable router to be configured beforehand=85which = is an > oxymoron! >>>=20 >>> This was not the intent of #3 - it was meant to allow an = implementation to > decide dependent on the targeted deployments. Even without the = reserved > instance ID, other parameters (area, hello, dead, etc) in the existing = network > would need to use the auto-configured values.=20 >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Alvaro. >>>=20 >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >>> Sent: Monday, May 28, 2012 4:19 PM >>> To: OSPF List >>> Cc: Jari Arkko; Retana, Alvaro >>> Subject: Fwd: New Version Notification for > draft-acee-ospf-ospfv3-autoconfig-02.txt >>>=20 >>> Speaking as a Draft Author: >>>=20 >>> This version includes additions based on comments received at IETF = 83. > Section 5.1 clarifies the detection of a neighbor with a duplicate = Router-ID > to exclude the case where multiple router interfaces are connected to = the same > link. Section 5.4 was added to mitigate the effects of a duplicate = OSPFv3 > Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID > resolution.=20 >>>=20 >>> Additionally, we received a suggestion from Alvaro Retana to not use = an > reserved OSPFv3 instance ID for auto-configured routers. Rather, allow = OSPFv3 > auto-configured routers to use the default OSPFv3 instance ID and > automatically join an existing non-autoconfigured OSPFv3 routing = domain. I see > three possible alternatives: >>>=20 >>> 1. Reject the suggestion. The alternate OSPFv3 instance ID was = added > specifically to prevent this.=20 >>> 2. Adopt the suggestion and remove the reserved instance ID. The > security considerations now recommend that implementation provide the > capability to configure a single key.=20 >>> 3. Add an applicability statement indicating that an = implementation > MAY use the default OSPFv3 instance if the network where the = implementation is > deployed requires incorporation into an existing OSPFv3 network.=20 >>>=20 >>> Please provide your thoughts on this issue.=20 >>>=20 >>> Thanks, >>> Acee >>>=20 >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>=20 >>>=20 >>> From: "internet-drafts@ietf.org" >>> Date: May 28, 2012 3:41:15 PM EDT >>> To: Acee Lindem >>> Cc: "jari.arkko@piuha.net" >>> Subject: New Version Notification for > draft-acee-ospf-ospfv3-autoconfig-02.txt >>>=20 >>> A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has = been > successfully submitted by Acee Lindem and posted to the IETF = repository. >>>=20 >>> Filename: draft-acee-ospf-ospfv3-autoconfig >>> Revision: 02 >>> Title: OSPFv3 Auto-Configuration >>> Creation date: 2012-05-28 >>> WG ID: Individual Submission >>> Number of pages: 14 >>>=20 >>> Abstract: >>> OSPFv3 is a candidate for deployments in environments where auto- >>> configuration is a requirement. One such environment is the IPv6 >>> home network where users expect to simply plug in a router and have >>> it automatically use OSPFv3 for intra-domain routing. This = document >>> describes the necessary mechanisms for OSPFv3 to be = self-configuring. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>=20 >>=20 >=20 >> ---------------------------------------------=20 >> Attachment: smime.p7s >> MIME Type: application/pkcs7-signature >> --------------------------------------------- >=20 --Apple-Mail-59--500250477 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwMTIwNTY0MlowIwYJKoZI hvcNAQkEMRYEFNhEyNFx9ORqva1fUhCRQKSoKv3SMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgGkMfQdnvzzLFsVSnNGpMU9ClrBR+WjFGCvqhos3zfoUtw/I5FqAXzAGTi1E7SUD 3OJXOuK/VML67AlZ/27fcQFyIDNj36BUigDvrnhpZAF/DSZRPUBVeqh1C6NKRtNd+6M0p1Vb2mbu f6llR81RQx+Q9fQof5qiReu3/OukbtXpAAAAAAAA --Apple-Mail-59--500250477-- From agrawal.ga@gmail.com Tue Jun 5 01:51:36 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 70FAF21F86F7 for ; Tue, 5 Jun 2012 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 7NVbZD3jGVgg for ; Tue, 5 Jun 2012 01:51:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C87D121F86B2 for ; Tue, 5 Jun 2012 01:51:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3373054vbb.31 for ; Tue, 05 Jun 2012 01:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nQZF9OlipAcxsf2OJn8IuBgmCsHvW/5Ufe70Yx1mKac=; b=Ol6oYx7IHb5FcfeVqJYnbB7nE2PePwDE8SAiSK3aPi3vsh3CdhGH149Z2fZuSHqHhn xaTZLl5VxfdRjsu7kBJGvhXuBGmNNSmSzB5KrbBM9FWSW0/JRUj+TubfPM8NS95onaOR 2GXHdws9dU52ej/GhLoRUVH06BAHfdZ+5q9d5WPpaXFzxeRp040o32AAYy0zcwW6V/XA xnp8VOkJxVtW0Bz2MbVpfNaZyofiUiww2NZO7BoNaEJOEJZ5pjNOUBy3BqOoJ7aeXVk4 ypHVCe3sv0AiZ0pWu6bGWA8noxHExTH6Yrkilbkf8PkS7Gw/LT6d5azS3q17LKkfyzW7 xfYQ== MIME-Version: 1.0 Received: by 10.52.17.80 with SMTP id m16mr13172656vdd.71.1338886293326; Tue, 05 Jun 2012 01:51:33 -0700 (PDT) Received: by 10.220.43.75 with HTTP; Tue, 5 Jun 2012 01:51:33 -0700 (PDT) Date: Tue, 5 Jun 2012 01:51:33 -0700 Message-ID: From: Gaurav Agrawal To: ospf@ietf.org Content-Type: multipart/alternative; boundary=bcaec50408f0e8897704c1b5c19f Subject: [OSPF] =?utf-8?q?Functional=E2=80=8Bly_equivalent_AS-Externa?= =?utf-8?q?=E2=80=8Bl/NSSA_LSA_for_OSPFv3?= 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, 05 Jun 2012 08:51:36 -0000 --bcaec50408f0e8897704c1b5c19f Content-Type: text/plain; charset=ISO-8859-1 Hi, I had a question about functionally equivalent AS-External LSA/NSSA LSA for OSPFv3. There is no mention in RFC 5340 or RFC 2740 in this regard. RFC 2328 and RFC 3101 provides details in context of OSPFv2. Can the same logic be extended for OSPFv3 as well? Thanks, Gaurav --bcaec50408f0e8897704c1b5c19f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0=A0=A0 I had a question about functionally equivalent AS-Ex= ternal LSA/NSSA LSA for OSPFv3. There is no mention in RFC 5340 or RFC 2740= in this regard. RFC 2328 and RFC 3101 provides details in context of OSPFv= 2. Can the same logic be extended for OSPFv3 as well?

=A0

Thanks,

Gaurav

--bcaec50408f0e8897704c1b5c19f-- From acee.lindem@ericsson.com Tue Jun 5 09:56: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 0B9F021F864A for ; Tue, 5 Jun 2012 09:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 SJ4BgcwS8X50 for ; Tue, 5 Jun 2012 09:55:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 29BCF21F8630 for ; Tue, 5 Jun 2012 09:55:59 -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 q55GtohC009088; Tue, 5 Jun 2012 11:55:56 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 5 Jun 2012 12:55:47 -0400 From: Acee Lindem To: Gaurav Agrawal Date: Tue, 5 Jun 2012 12:55:44 -0400 Thread-Topic: =?utf-8?B?W09TUEZdIEZ1bmN0aW9uYWzigItseSBlcXVpdmFsZW50IEFTLUV4dGVybmE=?= =?utf-8?B?4oCLbC9OU1NBIExTQSBmb3IgT1NQRnYz?= Thread-Index: Ac1DPA4Zc2hlw2bbTXCft4xN+l8b7g== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] =?utf-8?q?Functional=E2=80=8Bly_equivalent_AS-Externa?= =?utf-8?q?=E2=80=8Bl/NSSA_LSA_for_OSPFv3?= 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, 05 Jun 2012 16:56:01 -0000 SGkgR2F1cmF2LA0KWWVzIC0geW91IGNhbiBhc3N1bWUgdGhlIHNhbWUgTlNTQSBsb2dpYy4gRnJv bSB0aGUgUkZDIDUzNDAgQWJzdHJhY3Q6DQoNCiAgIEFsbCBvZiBPU1BGIGZvciBJUHY0J3Mgb3B0 aW9uYWwgY2FwYWJpbGl0aWVzLCBpbmNsdWRpbmcgZGVtYW5kDQogICBjaXJjdWl0IHN1cHBvcnQg YW5kIE5vdC1Tby1TdHViYnkgQXJlYXMgKE5TU0FzKSwgYXJlIGFsc28gc3VwcG9ydGVkDQogICBp biBPU1BGIGZvciBJUHY2Lg0KDQoNClRoZSBOU1NBLUxTQSBkZXNjcmlwdGlvbiB3YXMgbWlzc2lu ZyBmcm9tIFJGQyAyNzQwIGFuZCBhZGRlZCB0byBSRkMgNTM0MC4gQWxzbyBmcm9tIFJGQyA1MzQw Og0KDQoNCjMuMy4gIE5TU0EgU3BlY2lmaWNhdGlvbg0KDQogICBUaGlzIHByb3RvY29sIGZlYXR1 cmUgd2FzIG9ubHkgcGFydGlhbGx5IHNwZWNpZmllZCBpbiBSRkMgMjc0MC4gIFRoZQ0KICAgbGV2 ZWwgb2Ygc3BlY2lmaWNhdGlvbiB3YXMgaW5zdWZmaWNpZW50IHRvIGltcGxlbWVudCB0aGUgZnVu Y3Rpb24uDQogICBUaGlzIGRvY3VtZW50IGluY2x1ZGVzIGFuIE5TU0Egc3BlY2lmaWNhdGlvbiB1 bmlxdWUgdG8gT1NQRnYzLiAgVGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjb3VwbGVkIHdpdGggW05T U0FdIHByb3ZpZGUgc3VmZmljaWVudCBzcGVjaWZpY2F0aW9uDQogICBmb3IgaW1wbGVtZW50YXRp b24uICBSZWZlciB0byBTZWN0aW9uIDQuOC41LCBBcHBlbmRpeCBBLjQuMywNCiAgIEFwcGVuZGl4 IEEuNC44LCBhbmQgW05TU0FdLg0KDQoNClRoYW5rcywNCkFjZWUNCg0KT24gSnVuIDUsIDIwMTIs IGF0IDQ6NTEgQU0sIEdhdXJhdiBBZ3Jhd2FsIHdyb3RlOg0KDQoNCkhpLA0KDQogICAgSSBoYWQg YSBxdWVzdGlvbiBhYm91dCBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCBBUy1FeHRlcm5hbCBMU0Ev TlNTQSBMU0EgZm9yIE9TUEZ2My4gVGhlcmUgaXMgbm8gbWVudGlvbiBpbiBSRkMgNTM0MCBvciBS RkMgMjc0MCBpbiB0aGlzIHJlZ2FyZC4gUkZDIDIzMjggYW5kIFJGQyAzMTAxIHByb3ZpZGVzIGRl dGFpbHMgaW4gY29udGV4dCBvZiBPU1BGdjIuIENhbiB0aGUgc2FtZSBsb2dpYyBiZSBleHRlbmRl ZCBmb3IgT1NQRnYzIGFzIHdlbGw/DQoNCg0KDQpUaGFua3MsDQoNCkdhdXJhdg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1NQRiBtYWlsaW5nIGxp c3QNCk9TUEZAaWV0Zi5vcmc8bWFpbHRvOk9TUEZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCg0K From agrawal.ga@gmail.com Tue Jun 5 10:26:20 2012 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5F021F8740 for ; Tue, 5 Jun 2012 10:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 BbroNpG2pHqe for ; Tue, 5 Jun 2012 10:26:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13121F873C for ; Tue, 5 Jun 2012 10:26:19 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7630512pbc.31 for ; Tue, 05 Jun 2012 10:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UY0X7sa9jZ/wmP5muUdVjXmD3lJu6oaTipCm7kYDiWY=; b=plHWGTQhyZhd3jYErykcS82/5I5wCwks3aw4MWknnl0Fyu4fZf6AznTOueZzjNDHrh XGSvUNWmkESeSt7WMYs/76zDoY9y0t/peGSDAFyi5LcW1VWXr1rizCjfEttzfa7i1ntI H38o1c0pd9Iaq6Xuw4xFmBW9X2457yZrvbttxT8RsJF5Kd7qR2I6wXb6a1g7l+GufnZ+ D8EUOxKr2sRW/78FjX/FUzrindSPzn/Q9jdyOv94RSRO8viJUbw5OdG1d6DmhEEIZg+H he0Y9HJRnbty/ENoPNzcAUzcKL0BP4fZ2pQx4rlXvisx68yl0Avhj+8Xwzb5W9eG6dtA bJvQ== MIME-Version: 1.0 Received: by 10.68.217.166 with SMTP id oz6mr4385198pbc.136.1338917178945; Tue, 05 Jun 2012 10:26:18 -0700 (PDT) Received: by 10.68.237.231 with HTTP; Tue, 5 Jun 2012 10:26:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 10:26:18 -0700 Message-ID: From: Gaurav Agrawal To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7b2ed997d5b09c04c1bcf27a Cc: "ospf@ietf.org" Subject: Re: [OSPF] =?utf-8?q?Functional=E2=80=8Bly_equivalent_AS-Externa?= =?utf-8?q?=E2=80=8Bl/NSSA_LSA_for_OSPFv3?= 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, 05 Jun 2012 17:26:20 -0000 --047d7b2ed997d5b09c04c1bcf27a Content-Type: text/plain; charset=ISO-8859-1 Hi Acee, I was not referring to NSSA capabilities. I was referring to Functionally equivalent LSAs, which applies to AS-external LSAs as well. There is no mention or reference in OSPFv3 RFC: It is defined for OSPFv2 in section 12.4.4.1 RFC 2328, RTA and RTB would originate the same set of AS- external-LSAs. These LSAs, if they specify the same metric, would be functionally equivalent since they would specify the same destination and forwarding address (RTX). This leads to a clear duplication of effort. If only one of RTA or RTB originated the set of AS-external-LSAs, the routing would remain the same, and the size of the link state database would decrease. However, it must be unambiguously defined as to which router originates the LSAs (otherwise neither may, or the identity of the originator may oscillate). The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1. Thanks, Gaurav On Tue, Jun 5, 2012 at 9:55 AM, Acee Lindem wrote: > Hi Gaurav, > Yes - you can assume the same NSSA logic. From the RFC 5340 Abstract: > > All of OSPF for IPv4's optional capabilities, including demand > circuit support and Not-So-Stubby Areas (NSSAs), are also supported > in OSPF for IPv6. > > > The NSSA-LSA description was missing from RFC 2740 and added to RFC 5340. > Also from RFC 5340: > > > 3.3. NSSA Specification > > This protocol feature was only partially specified in RFC 2740. The > level of specification was insufficient to implement the function. > This document includes an NSSA specification unique to OSPFv3. This > specification coupled with [NSSA] provide sufficient specification > for implementation. Refer to Section 4.8.5, Appendix A.4.3, > Appendix A.4.8, and [NSSA]. > > > Thanks, > Acee > > On Jun 5, 2012, at 4:51 AM, Gaurav Agrawal wrote: > > > Hi, > > I had a question about functionally equivalent AS-External LSA/NSSA LSA > for OSPFv3. There is no mention in RFC 5340 or RFC 2740 in this regard. RFC > 2328 and RFC 3101 provides details in context of OSPFv2. Can the same logic > be extended for OSPFv3 as well? > > > > Thanks, > > Gaurav > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --047d7b2ed997d5b09c04c1bcf27a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Acee,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I was not refe= rring to NSSA capabilities. I was referring to Functionally equivalent LSAs= , which applies to AS-external LSAs as well. There is no mention or referen= ce in OSPFv3 RFC:
=A0
It is defined for OSPFv2 in section 12.4.4.1 RFC 2328, <= /div>
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 RTA and RTB would originate the same set of AS-
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 external-LSAs.=A0 These LSAs, if= they specify the same
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 metric, would be = functionally equivalent since they
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 would specify the same destination and forwarding
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 address (RTX).=A0= This leads to a clear duplication of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 effort.=A0 If onl= y one of RTA or RTB originated the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 set of AS-external-LSAs, the routing would remain
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the same, and the= size of the link state database
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 would decrease.=A0 However, it must be unambiguously
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 defined as to whi= ch router originates the LSAs
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 (otherwise neither may, or the identity of the
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 originator may oscillate).= =A0 The following rule is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 thereby established: if two routers, both reachable
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 from one another,= originate functionally equivalent
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 AS-external-LSAs (i.e., same destination, cost and=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 non-zero forward= ing address), then the LSA
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 originated by the router having the highest OSPF
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Router ID is used= .=A0 The router having the lower OSPF
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Router ID can then flush its LSA.=A0 Flushing an L= SA
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is discusse= d in Section 14.1.
=A0
Thanks,
Gaurav

On Tu= e, Jun 5, 2012 at 9:55 AM, Acee Lindem <acee.lindem@ericsson.com> wrote:
Hi Gaurav,
Yes - you can assume the same NSSA logic. From the RFC 5340 Abstract:

=A0 All of OSPF for IPv4's optional capabilities, including demand
=A0 circuit support and Not-So-Stubby Areas (NSSAs), are also supported =A0 in OSPF for IPv6.


The NSSA-LSA description was missing from RFC 2740 and added to RFC 5340. A= lso from RFC 5340:


3.3. =A0NSSA Specification

=A0 This protocol feature was only partially specified in RFC 2740. =A0The=
=A0 level of specification was insufficient to implement the function.
=A0 This document includes an NSSA specification unique to OSPFv3. =A0This=
=A0 specification coupled with [NSSA] provide sufficient specification
=A0 for implementation. =A0Refer to Section 4.8.5, Appendix A.4.3,
=A0 Appendix A.4.8, and [NSSA].


Thanks,
Acee

On Jun 5, 2012, at 4:51 AM, Gaurav Agrawal wrote:


Hi,

=A0 =A0I had a question about functionally equivalent AS-External LSA/NSSA= LSA for OSPFv3. There is no mention in RFC 5340 or RFC 2740 in this regard= . RFC 2328 and RFC 3101 provides details in context of OSPFv2. Can the same= logic be extended for OSPFv3 as well?



Thanks,

Gaurav

_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
ht= tps://www.ietf.org/mailman/listinfo/ospf


--047d7b2ed997d5b09c04c1bcf27a-- From acee.lindem@ericsson.com Tue Jun 5 11:44: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 20A6921F8714 for ; Tue, 5 Jun 2012 11:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 cogIhU24rIEP for ; Tue, 5 Jun 2012 11:44:09 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4268621F875B for ; Tue, 5 Jun 2012 11:44:09 -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 q55IhX7r001946; Tue, 5 Jun 2012 13:43:52 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 5 Jun 2012 14:43:35 -0400 From: Acee Lindem To: Gaurav Agrawal Date: Tue, 5 Jun 2012 14:43:32 -0400 Thread-Topic: =?utf-8?B?W09TUEZdIEZ1bmN0aW9uYWzigItseSBlcXVpdmFsZW50IEFTLUV4dGVybmE=?= =?utf-8?B?4oCLbC9OU1NBIExTQSBmb3IgT1NQRnYz?= Thread-Index: Ac1DSxzNdMeH2Z/dR8aXnVv2Bgyf6w== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] =?utf-8?q?Functional=E2=80=8Bly_equivalent_AS-Externa?= =?utf-8?q?=E2=80=8Bl/NSSA_LSA_for_OSPFv3?= 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, 05 Jun 2012 18:44:10 -0000 SGkgR2F1cmF2LA0KSSdkIGxpa2UgdG8gc2F5IHRoaXMgaXMgbm90IGFwcGxpY2FibGUgdG8gT1NQ RnYzIHNpbmNlIGl0IGlzIG9uZSBvZiB0aG9zZSBvcHRpbWl6YXRpb25zIHRoYXQgSSB0aGluayBp cyBtb3JlIHBhaW4gYW5kIGNvbXBsZXhpdHkgdGhhbiBpdCBpcyB3b3J0aCAobm90IHRvIG1lbnRp b24gdGhlIHBvdGVudGlhbCBjb252ZXJnZW5jZSBkZWxheSBpZiBvbmUgQVNCUiBiZWNvbWVzIHVu cmVhY2hhYmxlKS4gSG93ZXZlciwgdGhlIGludGVudCBpcyBkZWZpbml0ZWx5IHRoYXQgdGhpcyBi ZWhhdmlvciBpcyBjYXJyaWVkIG92ZXIgdG8gT1NQRnYzLg0KVGhhbmtzLA0KQWNlZQ0KT24gSnVu IDUsIDIwMTIsIGF0IDE6MjYgUE0sIEdhdXJhdiBBZ3Jhd2FsIHdyb3RlOg0KDQpIaSBBY2VlLA0K ICAgICAgICAgICAgIEkgd2FzIG5vdCByZWZlcnJpbmcgdG8gTlNTQSBjYXBhYmlsaXRpZXMuIEkg d2FzIHJlZmVycmluZyB0byBGdW5jdGlvbmFsbHkgZXF1aXZhbGVudCBMU0FzLCB3aGljaCBhcHBs aWVzIHRvIEFTLWV4dGVybmFsIExTQXMgYXMgd2VsbC4gVGhlcmUgaXMgbm8gbWVudGlvbiBvciBy ZWZlcmVuY2UgaW4gT1NQRnYzIFJGQzoNCg0KSXQgaXMgZGVmaW5lZCBmb3IgT1NQRnYyIGluIHNl Y3Rpb24gMTIuNC40LjEgUkZDIDIzMjgsDQoNCiAgICAgICAgICAgICAgICAgICAgUlRBIGFuZCBS VEIgd291bGQgb3JpZ2luYXRlIHRoZSBzYW1lIHNldCBvZiBBUy0NCiAgICAgICAgICAgICAgICAg ICAgZXh0ZXJuYWwtTFNBcy4gIFRoZXNlIExTQXMsIGlmIHRoZXkgc3BlY2lmeSB0aGUgc2FtZQ0K ICAgICAgICAgICAgICAgICAgICBtZXRyaWMsIHdvdWxkIGJlIGZ1bmN0aW9uYWxseSBlcXVpdmFs ZW50IHNpbmNlIHRoZXkNCiAgICAgICAgICAgICAgICAgICAgd291bGQgc3BlY2lmeSB0aGUgc2Ft ZSBkZXN0aW5hdGlvbiBhbmQgZm9yd2FyZGluZw0KICAgICAgICAgICAgICAgICAgICBhZGRyZXNz IChSVFgpLiAgVGhpcyBsZWFkcyB0byBhIGNsZWFyIGR1cGxpY2F0aW9uIG9mDQogICAgICAgICAg ICAgICAgICAgIGVmZm9ydC4gIElmIG9ubHkgb25lIG9mIFJUQSBvciBSVEIgb3JpZ2luYXRlZCB0 aGUNCiAgICAgICAgICAgICAgICAgICAgc2V0IG9mIEFTLWV4dGVybmFsLUxTQXMsIHRoZSByb3V0 aW5nIHdvdWxkIHJlbWFpbg0KICAgICAgICAgICAgICAgICAgICB0aGUgc2FtZSwgYW5kIHRoZSBz aXplIG9mIHRoZSBsaW5rIHN0YXRlIGRhdGFiYXNlDQogICAgICAgICAgICAgICAgICAgIHdvdWxk IGRlY3JlYXNlLiAgSG93ZXZlciwgaXQgbXVzdCBiZSB1bmFtYmlndW91c2x5DQogICAgICAgICAg ICAgICAgICAgIGRlZmluZWQgYXMgdG8gd2hpY2ggcm91dGVyIG9yaWdpbmF0ZXMgdGhlIExTQXMN CiAgICAgICAgICAgICAgICAgICAgKG90aGVyd2lzZSBuZWl0aGVyIG1heSwgb3IgdGhlIGlkZW50 aXR5IG9mIHRoZQ0KICAgICAgICAgICAgICAgICAgICBvcmlnaW5hdG9yIG1heSBvc2NpbGxhdGUp LiAgVGhlIGZvbGxvd2luZyBydWxlIGlzDQogICAgICAgICAgICAgICAgICAgIHRoZXJlYnkgZXN0 YWJsaXNoZWQ6IGlmIHR3byByb3V0ZXJzLCBib3RoIHJlYWNoYWJsZQ0KICAgICAgICAgICAgICAg ICAgICBmcm9tIG9uZSBhbm90aGVyLCBvcmlnaW5hdGUgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQN CiAgICAgICAgICAgICAgICAgICAgQVMtZXh0ZXJuYWwtTFNBcyAoaS5lLiwgc2FtZSBkZXN0aW5h dGlvbiwgY29zdCBhbmQNCiAgICAgICAgICAgICAgICAgICAgbm9uLXplcm8gZm9yd2FyZGluZyBh ZGRyZXNzKSwgdGhlbiB0aGUgTFNBDQogICAgICAgICAgICAgICAgICAgIG9yaWdpbmF0ZWQgYnkg dGhlIHJvdXRlciBoYXZpbmcgdGhlIGhpZ2hlc3QgT1NQRg0KICAgICAgICAgICAgICAgICAgICBS b3V0ZXIgSUQgaXMgdXNlZC4gIFRoZSByb3V0ZXIgaGF2aW5nIHRoZSBsb3dlciBPU1BGDQogICAg ICAgICAgICAgICAgICAgIFJvdXRlciBJRCBjYW4gdGhlbiBmbHVzaCBpdHMgTFNBLiAgRmx1c2hp bmcgYW4gTFNBDQogICAgICAgICAgICAgICAgICAgIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDE0 LjEuDQoNClRoYW5rcywNCkdhdXJhdg0KDQpPbiBUdWUsIEp1biA1LCAyMDEyIGF0IDk6NTUgQU0s IEFjZWUgTGluZGVtIDxhY2VlLmxpbmRlbUBlcmljc3Nvbi5jb208bWFpbHRvOmFjZWUubGluZGVt QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgR2F1cmF2LA0KWWVzIC0geW91IGNhbiBhc3N1bWUg dGhlIHNhbWUgTlNTQSBsb2dpYy4gRnJvbSB0aGUgUkZDIDUzNDAgQWJzdHJhY3Q6DQoNCiAgQWxs IG9mIE9TUEYgZm9yIElQdjQncyBvcHRpb25hbCBjYXBhYmlsaXRpZXMsIGluY2x1ZGluZyBkZW1h bmQNCiAgY2lyY3VpdCBzdXBwb3J0IGFuZCBOb3QtU28tU3R1YmJ5IEFyZWFzIChOU1NBcyksIGFy ZSBhbHNvIHN1cHBvcnRlZA0KICBpbiBPU1BGIGZvciBJUHY2Lg0KDQoNClRoZSBOU1NBLUxTQSBk ZXNjcmlwdGlvbiB3YXMgbWlzc2luZyBmcm9tIFJGQyAyNzQwIGFuZCBhZGRlZCB0byBSRkMgNTM0 MC4gQWxzbyBmcm9tIFJGQyA1MzQwOg0KDQoNCjMuMy4gIE5TU0EgU3BlY2lmaWNhdGlvbg0KDQog IFRoaXMgcHJvdG9jb2wgZmVhdHVyZSB3YXMgb25seSBwYXJ0aWFsbHkgc3BlY2lmaWVkIGluIFJG QyAyNzQwLiAgVGhlDQogIGxldmVsIG9mIHNwZWNpZmljYXRpb24gd2FzIGluc3VmZmljaWVudCB0 byBpbXBsZW1lbnQgdGhlIGZ1bmN0aW9uLg0KICBUaGlzIGRvY3VtZW50IGluY2x1ZGVzIGFuIE5T U0Egc3BlY2lmaWNhdGlvbiB1bmlxdWUgdG8gT1NQRnYzLiAgVGhpcw0KICBzcGVjaWZpY2F0aW9u IGNvdXBsZWQgd2l0aCBbTlNTQV0gcHJvdmlkZSBzdWZmaWNpZW50IHNwZWNpZmljYXRpb24NCiAg Zm9yIGltcGxlbWVudGF0aW9uLiAgUmVmZXIgdG8gU2VjdGlvbiA0LjguNSwgQXBwZW5kaXggQS40 LjMsDQogIEFwcGVuZGl4IEEuNC44LCBhbmQgW05TU0FdLg0KDQoNClRoYW5rcywNCkFjZWUNCg0K T24gSnVuIDUsIDIwMTIsIGF0IDQ6NTEgQU0sIEdhdXJhdiBBZ3Jhd2FsIHdyb3RlOg0KDQoNCkhp LA0KDQogICBJIGhhZCBhIHF1ZXN0aW9uIGFib3V0IGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IEFT LUV4dGVybmFsIExTQS9OU1NBIExTQSBmb3IgT1NQRnYzLiBUaGVyZSBpcyBubyBtZW50aW9uIGlu IFJGQyA1MzQwIG9yIFJGQyAyNzQwIGluIHRoaXMgcmVnYXJkLiBSRkMgMjMyOCBhbmQgUkZDIDMx MDEgcHJvdmlkZXMgZGV0YWlscyBpbiBjb250ZXh0IG9mIE9TUEZ2Mi4gQ2FuIHRoZSBzYW1lIGxv Z2ljIGJlIGV4dGVuZGVkIGZvciBPU1BGdjMgYXMgd2VsbD8NCg0KDQoNClRoYW5rcywNCg0KR2F1 cmF2DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP U1BGIG1haWxpbmcgbGlzdA0KT1NQRkBpZXRmLm9yZzxtYWlsdG86T1NQRkBpZXRmLm9yZz48bWFp bHRvOk9TUEZAaWV0Zi5vcmc8bWFpbHRvOk9TUEZAaWV0Zi5vcmc+Pg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQoNCg0KDQo= From acee.lindem@ericsson.com Thu Jun 21 08:21: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 127D721F8669; Thu, 21 Jun 2012 08:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpSR89XtEbo8; Thu, 21 Jun 2012 08:21:48 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B002221F8656; Thu, 21 Jun 2012 08:21:47 -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 q5LFLj6s015933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jun 2012 10:21:46 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.118]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 21 Jun 2012 11:21:45 -0400 From: Acee Lindem To: Stewart Bryant Date: Thu, 21 Jun 2012 11:21:43 -0400 Thread-Topic: Request for publication - Hiding Transit-only Networks in OSPF Thread-Index: Ac1PwZFQCfHihXAZQKOAzy8vIDLVBw== Message-ID: <5A3356DC-C9F4-4EC3-B0EA-C54DF287A4DA@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-14--939833188"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: OSPF List , IETF Secretariat Subject: [OSPF] Request for publication - Hiding Transit-only Networks in OSPF 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, 21 Jun 2012 15:21:49 -0000 --Apple-Mail-14--939833188 Content-Type: multipart/mixed; boundary=Apple-Mail-13--939833202 --Apple-Mail-13--939833202 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The OSPF WG requests that the subject document be published as a = proposed standard.=20 The document shepherd writeup is attached.=20 Thanks, Acee Lindem --Apple-Mail-13--939833202 Content-Disposition: attachment; filename=ospf-wg-prefix-hiding-writeup.txt Content-Type: text/plain; name="ospf-wg-prefix-hiding-writeup.txt" Content-Transfer-Encoding: 7bit (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft mechanisms to prevent the advertisements of prefixes associated with transit-only network. In OSPFv2, the protocol encoding for the Network-LSA is modified. In OSFPv3, prefix advertisement suppression can be accomplished without any protocol encoding changes. Working Group Summary The function is fairly straight-forward and the only discussion was related to OSPFv3 whether the DR should suppress advertisement of all prefixes on the link or whether it should be based on the individual link-LSA advertisements. After some discussion, we decided on the latter. Document Quality The document has gone through several WG review cycles and revisions. There is at least one implementation and another under development. Personnel Acee Lindem is the document shepherd and Stewart Bryant is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was presented in Bejing and went through several WG reviews. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. Yes - Defensive patent. https://datatracker.ietf.org/ipr/1423/ (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? These is consensus behind the draft and many believe it is useful. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. All idnits errors and warnings have been resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary. Yes. Updates RFC 2328 and RFC 5340. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document doesn't require any IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not Applicable. --Apple-Mail-13--939833202 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail-13--939833202-- --Apple-Mail-14--939833188 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMTE1MjE0M1owIwYJKoZI hvcNAQkEMRYEFN5hOtRlSFP/F9UllVJFw+MAve0LMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDXNuXcrYxUl2lK4Uf74WfL/q49bAMw2tsP9iLPls2gzsXct5L0XSQaAqQTahJu0 /lG3DRkTz/Qbofv1WvFj//u50RCIecsXm6VsLpwhlkHxL/hLm4BDCbu5wjjocRbKbtkwsZ0QEp14 ZEfxrHrDlDwFUlYWDdJemAItxBQqKiDnAAAAAAAA --Apple-Mail-14--939833188-- From iesg-secretary@ietf.org Fri Jun 22 06:48:24 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 D869A21F8633; Fri, 22 Jun 2012 06:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 z491TJ2jQi+g; Fri, 22 Jun 2012 06:48:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D88221F8504; Fri, 22 Jun 2012 06:48:24 -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.21 Message-ID: <20120622134824.20929.49150.idtracker@ietfa.amsl.com> Date: Fri, 22 Jun 2012 06:48:24 -0700 Cc: ospf@ietf.org Subject: [OSPF] Last Call: (Hiding Transit-only Networks in OSPF) 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: Fri, 22 Jun 2012 13:48:25 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Hiding Transit-only Networks in OSPF' 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-06. 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 A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and minimize remote attack vulnerability. This document updates RFC 2328 and RFC 5340. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-hiding/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-hiding/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1798/ From acee.lindem@ericsson.com Fri Jun 22 13:12:21 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 1D01E11E8087; Fri, 22 Jun 2012 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7EUTaCWyKvJ; Fri, 22 Jun 2012 13:12:20 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB821F8625; Fri, 22 Jun 2012 13:12:19 -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 q5MKCA6C028323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jun 2012 15:12:12 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.118]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 22 Jun 2012 16:12:11 -0400 From: Acee Lindem To: Stewart Bryant Date: Fri, 22 Jun 2012 16:11:58 -0400 Thread-Topic: [OSPF] Publication request for OSPF Hybrid Broadcast and P2MP Interface Type - draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt Thread-Index: Ac1Qs05GuScNT5IXSIeTtm70V4GdAQ== Message-ID: <02BB2ACB-C319-4BBD-A2EE-982E608E4D7A@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-15--836017437"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Jeffrey \(Zhaohui\) Zhang" , OSPF List , IETF Secretariat Subject: [OSPF] Publication request for OSPF Hybrid Broadcast and P2MP Interface Type - draft-ietf-ospf-hybrid-bcast-and-p2mp-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: Fri, 22 Jun 2012 20:12:21 -0000 --Apple-Mail-15--836017437 Content-Type: multipart/mixed; boundary=Apple-Mail-14--836017454 --Apple-Mail-14--836017454 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Stewart, Please publish draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt as a = Standards Track RFC. I'm resending this with the IETF Secretary copied = since I didn't see the expected notifications.=20 Thanks, Acee=20 --Apple-Mail-14--836017454 Content-Disposition: attachment; filename=ospf-wg-hybrid-interface-writeup.txt Content-Type: text/plain; name="ospf-wg-hybrid-interface-writeup.txt" Content-Transfer-Encoding: quoted-printable (1) What type of RFC is being requested (BCP, Proposed Standard,=0D=0D Internet Standard, Informational, Experimental, or Historic)? Why=0D=0D is this the proper type of RFC? Is this type of RFC indicated in the=0D=0D= title page header?=0D=0D =0D=0D Proposed Standard =0D=0D =0D=0D (2) The IESG approval announcement includes a Document Announcement=0D=0D= Write-Up. Please provide such a Document Announcement Write-Up. Recent=0D= =0D examples can be found in the "Action" announcements for approved=0D=0D documents. The approval announcement contains the following sections:=0D=0D= =0D=0D Technical Summary =0D=0D =0D=0D This draft extends OSPFv2 with an additional interface type that=0D=0D= has the property of supporting the adjacency reduction and flooding = =0D=0D optimizations of broadcast networks while still allowing separate =0D= =0D costs to be specified for each neighbor. =0D=0D =0D=0D Working Group Summary =0D=0D =0D=0D The only discussion worth noting was was how this document was =0D=0D= positioned against the previously published MANET documents. We =0D=0D= agreed that the MANET mechanisms could be used to accomplish the=0D=0D= same goal but that the simplicity of this draft warrents =0D=0D standardization by the working group. =0D=0D =0D=0D Document Quality =0D=0D =0D=0D The document has gone through several WG review cycles and =0D=0D revisions. There is at least one implementation of the initial=0D=0D= revision. =0D=0D =0D=0D Personnel=0D=0D =0D=0D Acee Lindem is the document shepherd and Stewart Bryant is the =0D=0D= responsible AD. =0D=0D =0D=0D =0D=0D (3) Briefly describe the review of this document that was performed by=0D= =0D the Document Shepherd. If this version of the document is not ready=0D=0D= for publication, please explain why the document is being forwarded to=0D= =0D the IESG.=0D=0D =0D=0D The document was presented at two IETFs and went through several WG=0D= =0D reviews. =0D=0D =0D=0D (4) Does the document Shepherd have any concerns about the depth or=0D=0D= breadth of the reviews that have been performed? =0D=0D =0D=0D No. =0D=0D =0D=0D (5) Do portions of the document need review from a particular or from=0D=0D= broader perspective, e.g., security, operational complexity, AAA, DNS,=0D= =0D DHCP, XML, or internationalization? If so, describe the review that=0D=0D= took place.=0D=0D =0D=0D No.=0D=0D =0D=0D (6) Describe any specific concerns or issues that the Document Shepherd=0D= =0D has with this document that the Responsible Area Director and/or the=0D=0D= IESG should be aware of? For example, perhaps he or she is uncomfortable=0D= =0D with certain parts of the document, or has concerns whether there really=0D= =0D is a need for it. In any event, if the interested community has=0D=0D discussed those issues and has indicated that it still wishes to advance=0D= =0D the document, detail those concerns here.=0D=0D =0D=0D None. =0D=0D =0D=0D (7) Has each author confirmed that any and all appropriate IPR=0D=0D disclosures required for full conformance with the provisions of BCP 78=0D= =0D and BCP 79 have already been filed. If not, explain why.=0D=0D =0D=0D Yes. =0D=0D =0D=0D (8) Has an IPR disclosure been filed that references this document?=0D=0D= If so, summarize any discussion and conclusion regarding the IPR=0D=0D disclosures.=0D=0D =0D=0D Yes - Defensive patent. https://datatracker.ietf.org/ipr/1529/ =0D=0D =0D=0D (9) How solid is the consensus of the interested community behind this=0D= =0D document? Does it represent the strong concurrence of a few individuals,=0D= =0D with others being silent, or does the interested community as a whole=0D=0D= understand and agree with it? =0D=0D =0D=0D These is consensus behind the draft with the only questions=0D=0D coming authors of OSPF MANET experimental RFCs that may be=0D=0D used to accomplish the same end of getting the unequal costs=0D=0D and exploit multicast flooding. We resolved these questions=0D=0D by agreeing to also accept draft describing how these OSPF=0D=0D MANET extensions could be used. =0D=0D =0D=0D (10) Has anyone threatened an appeal or otherwise indicated extreme =0D=0D= discontent? If so, please summarise the areas of conflict in separate=0D=0D= email messages to the Responsible Area Director. (It should be in a=0D=0D= separate email because this questionnaire is publicly available.) =0D=0D =0D=0D No. =0D=0D =0D=0D (11) Identify any ID nits the Document Shepherd has found in this=0D=0D document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts=0D= =0D Checklist). Boilerplate checks are not enough; this check needs to be=0D=0D= thorough.=0D=0D =0D=0D All idnits errors and warnings have been resolved.=0D=0D =0D=0D (12) Describe how the document meets any required formal review=0D=0D criteria, such as the MIB Doctor, media type, and URI type reviews.=0D=0D= =0D=0D Not applicable. =0D=0D =0D=0D (13) Have all references within this document been identified as=0D=0D either normative or informative?=0D=0D =0D=0D Yes.=0D=0D =0D=0D (14) Are there normative references to documents that are not ready for=0D= =0D advancement or are otherwise in an unclear state? If such normative=0D=0D= references exist, what is the plan for their completion?=0D=0D =0D=0D No. =0D=0D =0D=0D (15) Are there downward normative references references (see RFC 3967)?=0D= =0D If so, list these downward references to support the Area Director in=0D=0D= the Last Call procedure.=0D=0D =0D=0D No. =0D=0D =0D=0D (16) Will publication of this document change the status of any existing=0D= =0D RFCs? Are those RFCs listed on the title page header, listed in the=0D=0D= abstract, and discussed in the introduction? If the RFCs are not listed=0D= =0D in the Abstract and Introduction, explain why, and point to the part of=0D= =0D the document where the relationship of this document to the other RFCs=0D= =0D is discussed. If this information is not in the document, explain why=0D=0D= the interested community considers it unnecessary.=0D=0D =0D=0D Yes. Updates RFC 2328 and RFC 5340. =0D=0D =0D=0D (17) Describe the Document Shepherd's review of the IANA considerations=0D= =0D section, especially with regard to its consistency with the body of the=0D= =0D document. Confirm that all protocol extensions that the document makes=0D= =0D are associated with the appropriate reservations in IANA registries.=0D=0D= Confirm that any referenced IANA registries have been clearly=0D=0D identified. Confirm that newly created IANA registries include a=0D=0D detailed specification of the initial contents for the registry, that=0D=0D= allocations procedures for future registrations are defined, and a=0D=0D reasonable name for the new registry has been suggested (see RFC 5226).=0D= =0D =0D=0D This document doesn't require any IANA actions. The one added code=0D= =0D point for the new interface type is not part of the protocol - only=0D= =0D the reference implementation used to describer protocol behavior. =0D= =0D =0D=0D (18) List any new IANA registries that require Expert Review for future=0D= =0D allocations. Provide any public guidance that the IESG would find=0D=0D useful in selecting the IANA Experts for these new registries.=0D=0D =0D=0D None. =0D=0D =0D=0D (19) Describe reviews and automated checks performed by to validate=0D=0D= sections of the document written in a formal language, such as XML code,=0D= =0D BNF rules, MIB definitions, etc.=0D=0D =0D=0D Not Applicable. =0D=0D =0D=0D =0D=0D --Apple-Mail-14--836017454 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-14--836017454-- --Apple-Mail-15--836017437 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMjIwMTE1OVowIwYJKoZI hvcNAQkEMRYEFMUbaHIsTx0ITdzv1SSyUUhGq4JJMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFa5DxAeNu+OL8WINbnivT8K24BwH1X9nCfIWdgvxjcy5uWZI3vAtnp2ttODOhae tHSjHbeCgkg0b5YrkIbqa301wBdfYfSWD3jrYRsOwYo8llUMVmALA+AgbaRIBA3blh/N327jP/iO uZkobB62HFNB6+7+ZieGOt65hU/rEUJfAAAAAAAA --Apple-Mail-15--836017437-- From equinox@diac24.net Sat Jun 23 06:57:48 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 73FB021F844F for ; Sat, 23 Jun 2012 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 dZieF+Mm0DMw for ; Sat, 23 Jun 2012 06:57:48 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3221F844D for ; Sat, 23 Jun 2012 06:57:46 -0700 (PDT) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2:21b:fcff:fe4c:9e6f]) by spaceboyz.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SiQqL-0001Xc-LG for ospf@ietf.org; Sat, 23 Jun 2012 15:57:41 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.77) (envelope-from ) id 1SiQQu-00Fm08-Mw for ospf@ietf.org; Sat, 23 Jun 2012 15:31:24 +0200 Date: Sat, 23 Jun 2012 15:31:24 +0200 From: David Lamparter To: ospf@ietf.org Message-ID: <20120623133124.GA3653120@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Subject: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing 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, 23 Jun 2012 13:57:48 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, out of a rather funny misunderstanding of RFC 5309, I've ended up with half an implementation of OSPF running in ignorance of the IP subnet mask on a broadcast network. After cleaning up the misunderstanding and taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which I expected to contain a note about this, but no such thing. The general idea would be to operate a broadcast medium with a /32 subnet mask, possibly unnumbered, and allowing adjacencies with just about anything that sends a Hello (and passes auth). The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P (the last would amount to RFC 5309 with the detail that the peer address is not known up front.) (For OSPFv3, this is obviously not interesting since with link-local addresses, there is no notion of similar same-subnet restrictions.) I haven't found anything on this - is this mode of operation already described somewhere? Cheers, David --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iF4EAREIAAYFAk/lxSwACgkQCy20tTec6eP0qQD9EJFShPc+Yz2XsVmpR7BeX0j1 VM7Eo0xKcjv0o3D0fU0A/2D4T0FDvxMzQE8l1O12xJD6911qRZXDKdu5S6f/YFOj =EcOc -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From acee.lindem@ericsson.com Sat Jun 23 10:17:46 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 3A0A721F84CD for ; Sat, 23 Jun 2012 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5df+R+DWtdG for ; Sat, 23 Jun 2012 10:17:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A351E21F84B6 for ; Sat, 23 Jun 2012 10:17:45 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5NHHhsA031205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Jun 2012 12:17:44 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.230]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 23 Jun 2012 13:17:42 -0400 From: Acee Lindem To: David Lamparter Date: Sat, 23 Jun 2012 13:17:40 -0400 Thread-Topic: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing Thread-Index: Ac1RZBlxx8hfH6Z9Tri+HGH75JJ3bA== Message-ID: <1405F13B-CF1A-4CCB-A782-C7FBDD553880@ericsson.com> References: <20120623133124.GA3653120@jupiter.n2.diac24.net> In-Reply-To: <20120623133124.GA3653120@jupiter.n2.diac24.net> 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--760075328"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing 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, 23 Jun 2012 17:17:46 -0000 --Apple-Mail-1--760075328 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii David, Nobody has ever suggested this - why do think it useful? Thanks, Acee On Jun 23, 2012, at 9:31 AM, David Lamparter wrote: > Hi, > > > out of a rather funny misunderstanding of RFC 5309, I've ended up with > half an implementation of OSPF running in ignorance of the IP subnet > mask on a broadcast network. After cleaning up the misunderstanding and > taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which > I expected to contain a note about this, but no such thing. > > The general idea would be to operate a broadcast medium with a /32 > subnet mask, possibly unnumbered, and allowing adjacencies with just > about anything that sends a Hello (and passes auth). > > The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P > (the last would amount to RFC 5309 with the detail that the peer address > is not known up front.) > > (For OSPFv3, this is obviously not interesting since with link-local > addresses, there is no notion of similar same-subnet restrictions.) > > I haven't found anything on this - is this mode of operation already > described somewhere? > > > Cheers, > > David > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-1--760075328 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMzE3MTc0MVowIwYJKoZI hvcNAQkEMRYEFCwwO1IgCXe6bJNfLm5rh/kmUDFWMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFBwOmd5HEu+lbE6FIFKNTiTNC11dVVfdXSruc7SPoxTm6R3/miSYCIei94uGenC +2bQwmj3Oxa/dng6M0uqOvrCTm2X1a8Opbm4VAkZq/CBoXKFFFlhxoA+6wOs1/T+ghpbz6KRnx7B wGDf14tp5nYav+cVxfX5tSdTHXSxJzAUAAAAAAAA --Apple-Mail-1--760075328-- From acee.lindem@ericsson.com Sat Jun 23 10:24:24 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 CBA4E21F84FA for ; Sat, 23 Jun 2012 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufumq+82XxSx for ; Sat, 23 Jun 2012 10:24:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 302AB21F84EC for ; Sat, 23 Jun 2012 10:24:24 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5NHONPZ031379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Jun 2012 12:24:23 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.230]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 23 Jun 2012 13:24:22 -0400 From: Acee Lindem To: David Lamparter Date: Sat, 23 Jun 2012 13:24:20 -0400 Thread-Topic: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing (Corrrected) Thread-Index: Ac1RZQem4+hK4Q25TYGZ7C4nxRqumg== Message-ID: References: <20120623133124.GA3653120@jupiter.n2.diac24.net> In-Reply-To: <20120623133124.GA3653120@jupiter.n2.diac24.net> 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--759675683"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing (Corrrected) 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, 23 Jun 2012 17:24:25 -0000 --Apple-Mail-5--759675683 Content-Type: multipart/mixed; boundary=Apple-Mail-4--759675703 --Apple-Mail-4--759675703 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii David, Nobody has ever suggested this - why do you think it useful? Thanks, Acee On Jun 23, 2012, at 9:31 AM, David Lamparter wrote: > Hi, > > > out of a rather funny misunderstanding of RFC 5309, I've ended up with > half an implementation of OSPF running in ignorance of the IP subnet > mask on a broadcast network. After cleaning up the misunderstanding and > taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which > I expected to contain a note about this, but no such thing. > > The general idea would be to operate a broadcast medium with a /32 > subnet mask, possibly unnumbered, and allowing adjacencies with just > about anything that sends a Hello (and passes auth). > > The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P > (the last would amount to RFC 5309 with the detail that the peer address > is not known up front.) > > (For OSPFv3, this is obviously not interesting since with link-local > addresses, there is no notion of similar same-subnet restrictions.) > > I haven't found anything on this - is this mode of operation already > described somewhere? > > > Cheers, > > David > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-4--759675703 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMzE3MTc0MVowIwYJKoZI hvcNAQkEMRYEFCwwO1IgCXe6bJNfLm5rh/kmUDFWMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFBwOmd5HEu+lbE6FIFKNTiTNC11dVVfdXSruc7SPoxTm6R3/miSYCIei94uGenC +2bQwmj3Oxa/dng6M0uqOvrCTm2X1a8Opbm4VAkZq/CBoXKFFFlhxoA+6wOs1/T+ghpbz6KRnx7B wGDf14tp5nYav+cVxfX5tSdTHXSxJzAUAAAAAAAA --Apple-Mail-4--759675703 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-4--759675703-- --Apple-Mail-5--759675683 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyMzE3MjQyMVowIwYJKoZI hvcNAQkEMRYEFIiuWTMh3epAdF9VIZbofKpdOzNtMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgE5nhI3OGm80moJBe9SKL0J9qBV0Zm+vhSNqPDzS7JmLB6lhfkFdRuhowfYETjz9 Lsgl+0BrAygOgKFDB75sOKJ1wPK2FZD8kduJn3lqSuUv+1Tnk7d9DXP5wo1fiZzbT67Cl7ff8LlW QnjH9HPseKNNGCGmUOSJhwrRkRECcWjiAAAAAAAA --Apple-Mail-5--759675683-- From equinox@diac24.net Sat Jun 23 14:00: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 6F08D21F855F for ; Sat, 23 Jun 2012 14:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Uc8AGFB+tJgh for ; Sat, 23 Jun 2012 14:00:38 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id C203421F8555 for ; Sat, 23 Jun 2012 14:00:38 -0700 (PDT) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2:21b:fcff:fe4c:9e6f]) by spaceboyz.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SiXRa-0005zi-Sb; Sat, 23 Jun 2012 23:00:35 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.77) (envelope-from ) id 1SiXRa-00GKIr-A0; Sat, 23 Jun 2012 23:00:34 +0200 Date: Sat, 23 Jun 2012 23:00:34 +0200 From: David Lamparter To: Acee Lindem Message-ID: <20120623210034.GB3653120@jupiter.n2.diac24.net> References: <20120623133124.GA3653120@jupiter.n2.diac24.net> <1405F13B-CF1A-4CCB-A782-C7FBDD553880@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1405F13B-CF1A-4CCB-A782-C7FBDD553880@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing 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, 23 Jun 2012 21:00:39 -0000 On Sat, Jun 23, 2012 at 01:17:40PM -0400, Acee Lindem wrote: > Nobody has ever suggested this - why do think it useful? Oops - context: Unnumbered operation on broadcast media, and on that principle reduction of both IPv4 address consumption and configuration complexity. -David > On Jun 23, 2012, at 9:31 AM, David Lamparter wrote: > > out of a rather funny misunderstanding of RFC 5309, I've ended up with > > half an implementation of OSPF running in ignorance of the IP subnet > > mask on a broadcast network. After cleaning up the misunderstanding and > > taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which > > I expected to contain a note about this, but no such thing. > > > > The general idea would be to operate a broadcast medium with a /32 > > subnet mask, possibly unnumbered, and allowing adjacencies with just > > about anything that sends a Hello (and passes auth). > > > > The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P > > (the last would amount to RFC 5309 with the detail that the peer address > > is not known up front.) > > > > (For OSPFv3, this is obviously not interesting since with link-local > > addresses, there is no notion of similar same-subnet restrictions.) > > > > I haven't found anything on this - is this mode of operation already > > described somewhere? From asmirnov@cisco.com Mon Jun 25 03:01:21 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 8C6F121F850B for ; Mon, 25 Jun 2012 03:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hu7klwgVyXD for ; Mon, 25 Jun 2012 03:01:17 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2899721F84FE for ; Mon, 25 Jun 2012 03:01:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5P9mbbB015259; Mon, 25 Jun 2012 11:48:37 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5P9ma2N013480; Mon, 25 Jun 2012 11:48:37 +0200 (CEST) Message-ID: <4FE833F4.8090808@cisco.com> Date: Mon, 25 Jun 2012 11:48:36 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 MIME-Version: 1.0 To: David Lamparter References: <20120623133124.GA3653120@jupiter.n2.diac24.net> <1405F13B-CF1A-4CCB-A782-C7FBDD553880@ericsson.com> <20120623210034.GB3653120@jupiter.n2.diac24.net> In-Reply-To: <20120623210034.GB3653120@jupiter.n2.diac24.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing 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, 25 Jun 2012 10:01:21 -0000 Hi David, problem of unnumbered IP on broadcast interfaces has little to do with OSPF. There are certain checks and assumptions built into IPv4 architecture which prevent this (say, how ARP requests are accepted and validated; check concept of proxy ARP). So before you solve this problem in OSPF you should be messing with IPv4 basics and legacies of earlier days. At this point in time this is not interesting. As for /32 mask on broadcast interface see draft-ietf-ospf-prefix-hiding-04. Anton On 06/23/2012 11:00 PM, David Lamparter wrote: > On Sat, Jun 23, 2012 at 01:17:40PM -0400, Acee Lindem wrote: >> Nobody has ever suggested this - why do think it useful? > > Oops - context: Unnumbered operation on broadcast media, and on that > principle reduction of both IPv4 address consumption and configuration > complexity. > > -David > > >> On Jun 23, 2012, at 9:31 AM, David Lamparter wrote: >>> out of a rather funny misunderstanding of RFC 5309, I've ended up with >>> half an implementation of OSPF running in ignorance of the IP subnet >>> mask on a broadcast network. After cleaning up the misunderstanding and >>> taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which >>> I expected to contain a note about this, but no such thing. >>> >>> The general idea would be to operate a broadcast medium with a /32 >>> subnet mask, possibly unnumbered, and allowing adjacencies with just >>> about anything that sends a Hello (and passes auth). >>> >>> The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P >>> (the last would amount to RFC 5309 with the detail that the peer address >>> is not known up front.) >>> >>> (For OSPFv3, this is obviously not interesting since with link-local >>> addresses, there is no notion of similar same-subnet restrictions.) >>> >>> I haven't found anything on this - is this mode of operation already >>> described somewhere? > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From acee.lindem@ericsson.com Mon Jun 25 06:42: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 40A9A21F84D8 for ; Mon, 25 Jun 2012 06:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 umkD2r2DLl65 for ; Mon, 25 Jun 2012 06:42:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C716621F84C8 for ; Mon, 25 Jun 2012 06:42:01 -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 q5PDfxiF004559; Mon, 25 Jun 2012 08:42:00 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 25 Jun 2012 09:41:54 -0400 From: Acee Lindem To: Anton Smirnov Date: Mon, 25 Jun 2012 09:41:51 -0400 Thread-Topic: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing Thread-Index: Ac1S2EfppAufOWdKRoWbXLW8W3NsYQ== Message-ID: <44964C2F-168B-4F3D-932C-DA9DEA3AEA95@ericsson.com> References: <20120623133124.GA3653120@jupiter.n2.diac24.net> <1405F13B-CF1A-4CCB-A782-C7FBDD553880@ericsson.com> <20120623210034.GB3653120@jupiter.n2.diac24.net> <4FE833F4.8090808@cisco.com> In-Reply-To: <4FE833F4.8090808@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-11--600224627"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing 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, 25 Jun 2012 13:42:11 -0000 --Apple-Mail-11--600224627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Anton, David,=20 I agree with Anton. One could possibly make it work for P2MP - however, = this is more than simply an OSPF problem.=20 Acee=20 On Jun 25, 2012, at 5:48 AM, Anton Smirnov wrote: > Hi David, > problem of unnumbered IP on broadcast interfaces has little to do=20= > with OSPF. There are certain checks and assumptions built into IPv4=20 > architecture which prevent this (say, how ARP requests are accepted = and=20 > validated; check concept of proxy ARP). So before you solve this = problem=20 > in OSPF you should be messing with IPv4 basics and legacies of earlier=20= > days. At this point in time this is not interesting. > As for /32 mask on broadcast interface see=20 > draft-ietf-ospf-prefix-hiding-04. >=20 > Anton >=20 >=20 > On 06/23/2012 11:00 PM, David Lamparter wrote: >> On Sat, Jun 23, 2012 at 01:17:40PM -0400, Acee Lindem wrote: >>> Nobody has ever suggested this - why do think it useful? >>=20 >> Oops - context: Unnumbered operation on broadcast media, and on that >> principle reduction of both IPv4 address consumption and = configuration >> complexity. >>=20 >> -David >>=20 >>=20 >>> On Jun 23, 2012, at 9:31 AM, David Lamparter wrote: >>>> out of a rather funny misunderstanding of RFC 5309, I've ended up = with >>>> half an implementation of OSPF running in ignorance of the IP = subnet >>>> mask on a broadcast network. After cleaning up the = misunderstanding and >>>> taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, = which >>>> I expected to contain a note about this, but no such thing. >>>>=20 >>>> The general idea would be to operate a broadcast medium with a /32 >>>> subnet mask, possibly unnumbered, and allowing adjacencies with = just >>>> about anything that sends a Hello (and passes auth). >>>>=20 >>>> The link can operate as regular broadcast, hybrid-bcast-p2mp, or = P-t-P >>>> (the last would amount to RFC 5309 with the detail that the peer = address >>>> is not known up front.) >>>>=20 >>>> (For OSPFv3, this is obviously not interesting since with = link-local >>>> addresses, there is no notion of similar same-subnet restrictions.) >>>>=20 >>>> I haven't found anything on this - is this mode of operation = already >>>> described somewhere? >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-11--600224627 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyNTEzNDE1MlowIwYJKoZI hvcNAQkEMRYEFJcVZifFMRWgtXljRa2+k8FjINI3MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgCl5JnBnKJmgmOS4Vt5JOV68YaK4qcMA2RyIOoQgdhwzVH3ne7wR2lYjUAQVN2cI /ssmoV5JEauQn0aZxSy4nx+f7ib5Aa4fGHJSv9xV8quZHoHDmixsS2rek5fvKT5TpzJQJAAEJL9n Skfe7Xw9y8loa49VLo0RToad09tFo2oXAAAAAAAA --Apple-Mail-11--600224627-- From equinox@diac24.net Mon Jun 25 09:02: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 54F8311E8086 for ; Mon, 25 Jun 2012 09:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 4SiSY0KZLR6B for ; Mon, 25 Jun 2012 09:02:55 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FCE11E807F for ; Mon, 25 Jun 2012 09:02:54 -0700 (PDT) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2:21b:fcff:fe4c:9e6f]) by spaceboyz.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SjBkU-0005mx-DM; Mon, 25 Jun 2012 18:02:46 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.77) (envelope-from ) id 1SjBkT-001tzJ-QE; Mon, 25 Jun 2012 18:02:45 +0200 Date: Mon, 25 Jun 2012 18:02:45 +0200 From: David Lamparter To: Acee Lindem Message-ID: <20120625160245.GA328646@jupiter.n2.diac24.net> References: <20120623133124.GA3653120@jupiter.n2.diac24.net> <1405F13B-CF1A-4CCB-A782-C7FBDD553880@ericsson.com> <20120623210034.GB3653120@jupiter.n2.diac24.net> <4FE833F4.8090808@cisco.com> <44964C2F-168B-4F3D-932C-DA9DEA3AEA95@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44964C2F-168B-4F3D-932C-DA9DEA3AEA95@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFv2 operation on broadcast media with "slacked"/"discontinuous" IP addressing 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, 25 Jun 2012 16:02:56 -0000 Hi Acee & Anton, [citation reordered] > On Jun 25, 2012, at 5:48 AM, Anton Smirnov wrote: > > problem of unnumbered IP on broadcast interfaces has little to do > > with OSPF. There are certain checks and assumptions built into IPv4 > > architecture which prevent this (say, how ARP requests are accepted and > > validated; check concept of proxy ARP). So before you solve this problem > > in OSPF you should be messing with IPv4 basics and legacies of earlier > > days. At this point in time this is not interesting. On Mon, Jun 25, 2012 at 09:41:51AM -0400, Acee Lindem wrote: > I agree with Anton. One could possibly make it work for P2MP - > however, this is more than simply an OSPF problem. I agree that the behaviour on the ARP level may need proper specification, but the desired behaviour is the very default behaviour on Linux. I therefore would disagree on dismissing this as not interesting. Also, note that RFC 5309 already places most of the relevant requirements in section 4.3 and 4.4. Indeed I'm proposing something as simple as the extension of RFC 5309 to networks with more than 2 routers, in either broadcast, nbma, or the new hybrid mode. (p2mp could arguably be done as-is with creative interpretation of RFC 5309) A considerable pool of knowledge regarding this topic exists at the various MANET mesh routing workgroups; I would not consider the basic IPv4 and ARP architecture a major obstacle, maybe not even a minor one. Sample unnumbered Ethernet Linux session: (note: no kernel patches have been applied, no knobs have been tuned) tmp0 # ip link set eth0 up tmp0 # ip addr add 10.0.0.1/32 dev eth0 tmp0 # ip addr list eth0 97: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether ba:6a:90:38:5d:16 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/32 scope global eth0 tmp0 # ip route add 192.168.23.45 dev eth0 tmp0 # ip route list 192.168.23.45 dev eth0 scope link tmp0 # tcpdump -es 0 -nvvli eth0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:36:33.379242 de:82:f4:80:e1:f9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 192.168.23.45, length 28 17:36:33.379288 ba:6a:90:38:5d:16 > de:82:f4:80:e1:f9, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.1 is-at ba:6a:90:38:5d:16, length 28 17:36:33.379301 de:82:f4:80:e1:f9 > ba:6a:90:38:5d:16, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.23.45 > 10.0.0.1: ICMP echo request, id 52688, seq 1, length 64 17:36:33.379365 ba:6a:90:38:5d:16 > de:82:f4:80:e1:f9, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 54708, offset 0, flags [none], proto ICMP (1), length 84) 10.0.0.1 > 192.168.23.45: ICMP echo reply, id 52688, seq 1, length 64 [...] tmp1 # ip link set eth0 up tmp1 # ip addr add 192.168.23.45/32 dev eth0 tmp1 # ip route add 10.0.0.1 dev eth0 tmp1 # ping -c 2 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_req=1 ttl=64 time=0.194 ms 64 bytes from 10.0.0.1: icmp_req=2 ttl=64 time=0.100 ms --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.100/0.147/0.194/0.047 ms tmp1 # ip neigh list 10.0.0.1 dev eth0 lladdr ba:6a:90:38:5d:16 REACHABLE > > As for /32 mask on broadcast interface see > > draft-ietf-ospf-prefix-hiding-04. Hm, this is only remotely related, though it may make things more complicated with this special treatment of /32 masks on network LSAs. -David > On 06/23/2012 11:00 PM, David Lamparter wrote: > >> On Sat, Jun 23, 2012 at 01:17:40PM -0400, Acee Lindem wrote: > >>> Nobody has ever suggested this - why do think it useful? > >> > >> Oops - context: Unnumbered operation on broadcast media, and on that > >> principle reduction of both IPv4 address consumption and configuration > >> complexity. > >> > >> -David > >> > >> > >>> On Jun 23, 2012, at 9:31 AM, David Lamparter wrote: > >>>> out of a rather funny misunderstanding of RFC 5309, I've ended up with > >>>> half an implementation of OSPF running in ignorance of the IP subnet > >>>> mask on a broadcast network. After cleaning up the misunderstanding and > >>>> taking a step back, I found draft-ietf-ospf-hybrid-bcast-and-p2mp, which > >>>> I expected to contain a note about this, but no such thing. > >>>> > >>>> The general idea would be to operate a broadcast medium with a /32 > >>>> subnet mask, possibly unnumbered, and allowing adjacencies with just > >>>> about anything that sends a Hello (and passes auth). > >>>> > >>>> The link can operate as regular broadcast, hybrid-bcast-p2mp, or P-t-P > >>>> (the last would amount to RFC 5309 with the detail that the peer address > >>>> is not known up front.) > >>>> > >>>> (For OSPFv3, this is obviously not interesting since with link-local > >>>> addresses, there is no notion of similar same-subnet restrictions.) > >>>> > >>>> I haven't found anything on this - is this mode of operation already > >>>> described somewhere? From acee.lindem@ericsson.com Fri Jun 29 14:28:21 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 876EF21F8650 for ; Fri, 29 Jun 2012 14:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 X51CXpxcc3s5 for ; Fri, 29 Jun 2012 14:28:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EBDE821F856D for ; Fri, 29 Jun 2012 14:28:20 -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 q5TLRweI006206 for ; Fri, 29 Jun 2012 16:28:20 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 29 Jun 2012 17:28:05 -0400 From: Acee Lindem To: OSPF List Date: Fri, 29 Jun 2012 17:28:04 -0400 Thread-Topic: Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.tst Thread-Index: Ac1WPhHoKi/atuSpQeyIAmKxUfNNkw== Message-ID: <614F31FC-7699-435F-8218-38DC10C64BFB@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-14--226651696"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [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, 29 Jun 2012 21:28:21 -0000 --Apple-Mail-14--226651696 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.=20 Thanks, Acee =20= --Apple-Mail-14--226651696 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyOTIxMjgwNVowIwYJKoZI hvcNAQkEMRYEFNBQV/al14A0VVa0nVUtU2vJqM4dMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEtbf/hinw30NsbqU5i9C/y5Jnx8waEhwnf10CwhVMuC8EWheOtIoWuDiAfgp895 O/p847uv7eiJ9vRS90oUkv1BD3setBsAQSCnh7+A9NwM0ad4KIBLRzjvVO/pOKepm3LCOqE+03if s6Po1aWniMDmfb8rkdhkl2bJ/NP1ihGmAAAAAAAA --Apple-Mail-14--226651696-- From acee.lindem@ericsson.com Fri Jun 29 14:33:21 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 E79E021F8592 for ; Fri, 29 Jun 2012 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1, 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 L3sdJsWBUPZ9 for ; Fri, 29 Jun 2012 14:33:21 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 616E321F8550 for ; Fri, 29 Jun 2012 14:33:21 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5TLXGhc000383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Jun 2012 16:33:20 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.236]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 29 Jun 2012 17:33:15 -0400 From: Acee Lindem To: OSPF List Date: Fri, 29 Jun 2012 17:33:14 -0400 Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.txt (Reply to this one - Was multitasking on the first try ;^) Thread-Index: Ac1WPsrDxT3hkSl8RYGDrSkDfHSwjw== Message-ID: <357E4337-5F2E-4493-84F7-EBD25DE68C51@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-16--226341555"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.txt (Reply to this one - Was multitasking on the first try ; ^) 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, 29 Jun 2012 21:33:22 -0000 --Apple-Mail-16--226341555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as WG Co-Chair, I'd like to WG last call this draft prior to the Vancouver IETF and I'm = looking for volunteers to review it. There hasn't been a lot of = discussion after we concluded that the IPv4<->IPv6 translations were = 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.=20 Thanks,=20 Acee= --Apple-Mail-16--226341555 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYyOTIxMzMxNVowIwYJKoZI hvcNAQkEMRYEFI400t7PPZgUvvOpZCd7yeh5YQ9CMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgBxn3poOnXD6YruDID9cGBCNdJ5gP8838C2/uDJYn6DH5PEw2d2hq7onjz2I6neQ U5CUIXivqlDzbsvGBC6PXnIrVPwJzQoFZShFiv/WZ6ffYEACMr+B9C2XYY9if8KEQWNx3ibvefx8 FxZShsdxLUuo3UWWiAe8Fnf2/Z3fbPg+AAAAAAAA --Apple-Mail-16--226341555-- From michael_barnes@usa.net Fri Jun 29 17:51:26 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 D32EA11E808D for ; Fri, 29 Jun 2012 17:51:26 -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 kTN3mPg7t7Ap for ; Fri, 29 Jun 2012 17:51:26 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by ietfa.amsl.com (Postfix) with ESMTP id D100211E80AD for ; Fri, 29 Jun 2012 17:51:25 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id C2D102AC8ED; Sat, 30 Jun 2012 00:51:24 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.82F) with ESMTP id 405qFdazV5120M01; Sat, 30 Jun 2012 00:51:21 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from imap03.cms.usa.net [165.212.11.3] by cmsout01.mbox.net via smtad (C8.MAIN.3.72B) with ESMTP id XID470qFdazV1646X01; Sat, 30 Jun 2012 00:51:21 -0000 X-USANET-Source: 165.212.11.3 IN michael_barnes@usa.net imap03.cms.usa.net X-USANET-MsgId: XID470qFdazV1646X01 Received: from web03.cms.usa.net [165.212.8.203] by imap03.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.82G) with ESMTP id 406qFdazV8688M23; Sat, 30 Jun 2012 00:51:20 -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); Sat, 30 Jun 2012 00:51:20 -0000 Date: Fri, 29 Jun 2012 17:51:20 -0700 From: "Michael Barnes" To: , X-Mailer: USANET web-mailer (C8.MAIN.3.83I) Mime-Version: 1.0 Message-ID: <908qFdaYu2288S03.1341017480@web03.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID406qFdazV8688X23 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: Sat, 30 Jun 2012 00:51:27 -0000 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 corres= pond > 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 th= e > 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 prefi= xes. But I think that is not the right thing to do. Rather the ABR should be a= ble to advertise inter-area prefixes of any length, but only for prefixes loc= al to it (e.g. configured on its own interfaces). I think a common case for hav= ing 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 correspondi= ng 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 an= d if > not followed, may result in AS-External LSAs that are not usable. Anywa= y, > 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 se= t 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 t= o the FA" is not acceptable. Either the ASBR should be able to determine absolu= tely that there is an alternate path to the FA or it should not use that FA. T= his is not trivial in the intra-area case, and I don't think it is possible i= n the inter-area case. Therefor my opinion is that an ASBR should only advertis= e 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 direct= ly > interface routes as Inter-area routes(with 128 prefix length). This wil= l > ensure the other router cannot use it as a transit to reach the FA, sin= ce > the network is not visible at all. > = > Case 2 : = > There is another ABR in the area. In this case, since the other ABR rou= ter > 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 advertis= e 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 Barne= s' > 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 SP= F all > > router would add the Router with R-Bit clear as Stub node. Hence ther= e is > no > > chance where this router being used as transit for forwarding address= =2E = > = > 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 rout= er in > that area. > = > > @Mike : we shall not consider this router to give up the ABR/ASBR sta= tus. > 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 t= o > 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 vali= d > > Forwarding address can be derived, the LSA should be originated. = > > All other sources MUST NOT be originated by the Router with R-Bit Cle= ar. = > = > 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 t= he > > 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 t= o > > 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 shtsuchi@cisco.com Fri Jun 29 21:54: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 790BE21F8663 for ; Fri, 29 Jun 2012 21:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_61=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 PWk-LjHeZT4o for ; Fri, 29 Jun 2012 21:54:52 -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 31C1521F866B for ; Fri, 29 Jun 2012 21:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2588; q=dns/txt; s=iport; t=1341032091; x=1342241691; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0s1OiRcpLyZs1PdK5lMLcp8vvvlhMjo9m1DQdE8j70g=; b=Mr8DEnthfifwiScmVZZKXrWKy/vAsuD5vYhJqwaB/AjFIIVKupSXQOE9 ivWtu2HMzrNUnnxfRhh7orF87vZAYbYZ65vpnTq+rHxm0vKH/Jp7L1JZ+ aSMJbuWo2PcYjFYK4nWw730TddegIrAjt1zyLL3mC3QaA7kf5HEMbDRpK o=; X-IronPort-AV: E=Sophos;i="4.77,501,1336348800"; d="scan'208";a="14622841" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 30 Jun 2012 04:54:32 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5U4sT0O012844; Sat, 30 Jun 2012 10:24:32 +0530 Message-ID: <4FEE8683.1010706@cisco.com> Date: Sat, 30 Jun 2012 13:54:27 +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: ospf@ietf.org, alvaro.retana@hp.com References: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> In-Reply-To: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120629154505.32213.79435.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [OSPF] Fwd: 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, 30 Jun 2012 04:54:55 -0000 Alvaro,WG Thanks for your update. I read it,I have comments. It is better than 00,because the document includes description of R-bit. 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." -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? I would appreciate any comments. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-ietf-ospf-rfc3137bis-01.txt Date: Fri, 29 Jun 2012 08:45:05 -0700 From: Reply-To: To: CC: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF Stub Router Advertisement Author(s) : Alvaro Retana Liem Nguyen Alex Zinin Russ White Danny McPherson Filename : draft-ietf-ospf-rfc3137bis-01.txt Pages : 7 Date : 2012-06-29 Abstract: This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router. However, OSPF does not specify a standard way to accomplish this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc3137bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ospf-rfc3137bis-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-rfc3137bis-01 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 .