From adrian@olddog.co.uk Fri Jul 1 23:42:31 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4293411E80DA; Fri, 1 Jul 2011 23:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MuVwv0x2IbA; Fri, 1 Jul 2011 23:42:30 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB011E80E5; Fri, 1 Jul 2011 23:42:30 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p626gSnN005326; Sat, 2 Jul 2011 07:42:28 +0100 Received: from 950129200 ([93.158.36.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p626gRmk005318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Jul 2011 07:42:27 +0100 From: "Adrian Farrel" To: , , References: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> In-Reply-To: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> Date: Sat, 2 Jul 2011 07:42:24 +0100 Message-ID: <00c901cc3883$3487d490$9d977db0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG0La90cZrfS/4sXGHToQdAKjApppUIqkQQ Content-Language: en-gb Subject: Re: [RTG-DIR] Routing Area Open Meeting in Quebec X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 06:42:31 -0000 There are several possibilities, one of which is that no-one reads any of these mailing lists as often as once a week. I have received precisely two requests for a BFD tutorial and, without belittling the two people concerned, that doesn't represent good reason to hold the tutorial in valuable f2f time. There was also a suggestion that we should get a progress report and some updates from CONEX. Anyone else have any thoughts? Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 24 June 2011 21:13 > To: rtg-chairs@ietf.org; rtg-dir@ietf.org; routing-discussion@ietf.org > Subject: [RTG-DIR] Routing Area Open Meeting in Quebec > > Please let Stewart and me know of any topics you would like to cover in this > meeting. > > Our preference is for routing-related discussions that will benefit from having > the whole area present. > > It has been suggested that there might be a need/desire for a BFD tutorial. We > have a willing presenter, but we don't want to waste anyone's time preaching to > the choir. Who would see this as a good thing? > > Thanks, > Adrian From acee.lindem@ericsson.com Sat Jul 2 04:21:48 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7389A21F88D3; Sat, 2 Jul 2011 04:21:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYnfJv3au6lC; Sat, 2 Jul 2011 04:21:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DCAED21F88D0; Sat, 2 Jul 2011 04:21:47 -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 p62BLkn0012358; Sat, 2 Jul 2011 06:21:47 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.220]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sat, 2 Jul 2011 07:21:40 -0400 From: Acee Lindem To: "adrian@olddog.co.uk" Date: Sat, 2 Jul 2011 07:21:38 -0400 Thread-Topic: [RTG-DIR] Routing Area Open Meeting in Quebec Thread-Index: Acw4qja2yz+JGG9QQvmYfqQA6SHJLQ== Message-ID: <8A9287FC-1607-4782-9ECE-8DFD780E5328@ericsson.com> References: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> <00c901cc3883$3487d490$9d977db0$@olddog.co.uk> In-Reply-To: <00c901cc3883$3487d490$9d977db0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-75-586016755"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Open Meeting in Quebec X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 11:21:48 -0000 --Apple-Mail-75-586016755 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2011, at 2:42 AM, Adrian Farrel wrote: > There are several possibilities, one of which is that no-one reads any = of these > mailing lists as often as once a week. >=20 > I have received precisely two requests for a BFD tutorial and, without > belittling the two people concerned, that doesn't represent good = reason to hold > the tutorial in valuable f2f time. +1 >=20 > There was also a suggestion that we should get a progress report and = some > updates from CONEX. >=20 > Anyone else have any thoughts? >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On = Behalf Of >> Adrian Farrel >> Sent: 24 June 2011 21:13 >> To: rtg-chairs@ietf.org; rtg-dir@ietf.org; = routing-discussion@ietf.org >> Subject: [RTG-DIR] Routing Area Open Meeting in Quebec >>=20 >> Please let Stewart and me know of any topics you would like to cover = in this >> meeting. >>=20 >> Our preference is for routing-related discussions that will benefit = from > having >> the whole area present. >>=20 >> It has been suggested that there might be a need/desire for a BFD = tutorial. We >> have a willing presenter, but we don't want to waste anyone's time = preaching > to >> the choir. Who would see this as a good thing? >>=20 >> Thanks, >> Adrian >=20 --Apple-Mail-75-586016755 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwMjExMjEzOFowIwYJKoZI hvcNAQkEMRYEFH94vFlkNTCmSCjg7Rqb62icYmqxMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFhHcT/qp6HfpvIYNo5DsZ9ZK3L8h48CMlfbqTU9sPoamqteYOzWON7kBK7EJDT8 EAM+vxJY9PsNJ6vQiwzJy82nBy6hY0aq7gJ4UUqGCI+fxe6dQMzKees5eox0GRoHU+lrsjSeuxXe Q4NSnwlid3KPCUfolaS9D9OjlhtjGYCLAAAAAAAA --Apple-Mail-75-586016755-- From julien.meuric@orange-ftgroup.com Sat Jul 2 17:06:29 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6483B21F85B0 for ; Sat, 2 Jul 2011 17:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTWgPy6KjpHb for ; Sat, 2 Jul 2011 17:06:28 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 734FF21F85AF for ; Sat, 2 Jul 2011 17:06:27 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 365A48B8005; Sun, 3 Jul 2011 02:07:12 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2C25C8B8002; Sun, 3 Jul 2011 02:07:12 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 02:06:26 +0200 Received: from [10.193.116.50] ([10.193.116.50]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 02:06:26 +0200 Message-ID: <4E0FB27E.6010907@orange-ftgroup.com> Date: Sun, 03 Jul 2011 02:06:22 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2011 00:06:26.0240 (UTC) FILETIME=[0D048C00:01CC3915] Cc: "rtg-dir@ietf.org" , draft-ietf-roll-of0.all@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [RTG-DIR] RtgDir Review: draft-ietf-roll-of0 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 00:06:29 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-of0-14.txt Reviewer: Julien Meuric Review Date: 2 July 2011 IETF LC End Date: 4 July 2011 Intended Status: Standards Track *Summary:* This document is basically ready for publication, but has nits that should be considered prior to publication. *Comments:* This document is clearly well written and clearly focused, though relying on many concepts defined within RPL. This is the first ROLL document I have reviewed, so it may mean that my review is not sufficiently in-depth. I noted that many terms are capitalized: it seems unusual at the beginning but appears to be helpful so as to identify RPL-related concepts. *Major Issues:* No major issues found. *Minor Issues:* Just a few minor issues, which I could almost have put among the nits. - In section 6.2, stretch_of_rank is defined as "the maximum augmentation" while, as far as I understand the formula at the end of section 4.1, it is rather "the minimum augmentation". - Section 4.1 says "Stretching the step_of_rank is NOT RECOMMENDED" while "an implementation MAY stretch the step_of_rank": using both keywords does not seem consistent. Since stretch_of_rank is part of the document, it looks like "MAY" is correct. The capital letters of "NOT RECOMMENDED" should be removed, or the phrase may be replaced (e.g. "ought to be avoided"). - Section 4.2.1, 3rd bullet: what about multiple interfaces without policy? Section 4.2.2, 1st bullet: is there a reason why policy is no longer mentioned there? If the order of the rules may vary, why not writing, in the document, the list in the same order for the Preferred Parent and the Backup Feasible Successor? (1 -> 4; 2 -> 6; 3 -> 1...) Why different wording between sections? *Nits:* (some may be deferred to the RFC Editor) ---------- Title: - Should not RPL be expanded? - Should not "0" be spelled as "Zero"? ---------- Introduction: - LLN is expanded in the 1st sentence but not at the very 1st occurrence: how strict is the expansion rule? - "Objective Function" is used 5 times and then"OF", without explicit association: it may just be added after the 1st occurrence; - "DIO" is not expanded; - s/selected)./selected./ - I could not parse "This is why it is not specific as to how the link properties are transformed into a rank_increase and leaves that responsibility to the implementation;" (s/is not specific as to/does not specify/?) ---------- Generally, the document would benefit from more consistency when spelling the name: "Objective Function Zero" (once), "Objective Function 0" and "OF0" are used without visible rule. I would suggest: - full letters in the document title, - "Objective Function 0" (or as above) at the beginning and in section titles, - "OF0" in the remaining text. ---------- Section 3: "Low Power and Lossy Network" is used while "LLN" has already been mentioned several times. ---------- Section 4.1: - There 2 references about ETX: I would suggest to keep only one, thus use the other ROLL document only. - "MAC" is not expanded (especially as it is not "Media Access Control" here). - It would be more convenient for the reader if rank_increase, step_of_rank, rank_factor and stretch_of_rank were described as positive integers (or strictly positive integers when applicable). - In the formula, why using aliases for step_of_rank, rank_factor and stretch_of_rank? rank_increase remains the same and is much easier to read. (Issue with the length of the line?) ---------- Section 4.2.1 s/Selection Of The/Selection of the/ (all the more as "OF" is common in the document) ---------- Section 4.2.2 s/Selection Of The/Selection of the/ ---------- Section 5 - s/provide an interface/provides an interface/ - s/Updates: the OF0/Updates: The OF0/ ---------- Section 6.2 s/the maximum/The minimum/ ---------- Section 7.2 - s/when tthat/when that/ - s/Rank, he current/Rank, the current/ - s/be indicated/be indicated./ ---------- Section 9 s/packet resulting/packet, resulting/ ---------- Regards, Julien From lberger@labn.net Sun Jul 3 08:47:25 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7021F8647 for ; Sun, 3 Jul 2011 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.354 X-Spam-Level: X-Spam-Status: No, score=-101.354 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El8OYvgL+XUu for ; Sun, 3 Jul 2011 08:47:24 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 8121821F8646 for ; Sun, 3 Jul 2011 08:47:24 -0700 (PDT) Received: (qmail 28632 invoked by uid 0); 3 Jul 2011 15:47:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 3 Jul 2011 15:47:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=0wgx+ddlpYML36fzmMstco6F5rBpYUy3hM25XiKzsRU7tv1MNcPnHrvLpHTvI0ep16hU1Um3BX6qDtILfz3Fv7zMDFOi4k1we4Xmm86ZN4cCmZum01/+C8LmNyD81LT9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QdOtH-0008Kz-GY; Sun, 03 Jul 2011 09:47:23 -0600 Message-ID: <4E108F0B.5060305@labn.net> Date: Sun, 03 Jul 2011 11:47:23 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 15:47:25 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-linear-protection-07.txt Reviewer: Lou Berger Review Date: 7/3/2011 IETF LC End Date: 2011-07-05 Intended Status: Standards Track Summary: I have some concerns about this document that I think should be resolved before publication. Comments: Overall the document is well written and provides a lot of detail. That said, I see a number of issues. Some of the identified issues may be resolved through discussion (i.e., correction of my misinterpretations!), others will require changes to the text. In terms of readability, the document uses a state machine based approach to define protocol behavior. While definition of state machines is not novel in protocol specifications, I did find it a bit hard to follow the presentation in this document. Particularly from the perspective of verifying that all cases are covered. The state table in Appendix A is certainly helpful, but I would have preferred that it be normative as well as be accompanied by one or more state diagrams. There are also inconsistencies in use of RFC2119 and numbering conventions, which are pointed out below. Line numbers obtained from http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mpls-tp-linear-protection-07.txt will be used in this review. Major Issues: - State synchronization after message loss: The PSC protocol uses a soft-state messaging approach to synchronize state between PSC protocol peers. Two basic implications of soft-state messaging are (a) that peers can and will get of sync during periods of message loss, and (b) each state message must represent the full and *current* state of the message sender. (b) is critical for recovering for one or more lost messages. A key point is that intermediate state changes will not be visible to a peer during periods of prolong PSC message loss. So this all leads to two discussion points: state convergence time and loss of intermediate states. - State convergence time: The current PSC protocol definition, see section 4.1, has messages representing a change being retransmitted 3x fast, then followed by a less frequent "continuous" refresh message (5 second default refresh period). An implication of this approach is that peers may get out of sync for {n * refresh interval} after a period of PSC message loss. To me this seems like a potentially long period of time. A simple change that would improve protocol behavior would be to trigger the 3x fast transmission whenever a peer reports that it has recovered from a reception problem (remote SFc). This approach is already in place for on case (remote NR). For simplicity, perhaps it would be best to require whenever a peer reports any change. (I can provide proposed language if it helps.) Another alternative would be to adopt the changes that were made to RSVP, another soft state protocol, to address operationally observed message loss. (See the reliable message delivery sections of RFC 2961.) But this is probably too major a change at this time. An easily fixed related point: Section 4.1 is missing the formal definition of the sending of refresh messages. (It is presented as informative in section 4.3.3.) Propose adding at line 637 something along the lines of: After the transmission of the three rapid messages, the LER MUST retransmit the most recently transmitted PSC message on a continual basis. - Loss of intermediate states As defined, PSC messages don't represent full sender state as is the norm for soft-state protocols, but rather provide the most recent 'request' (see section 4.2.2.). This means that if there are any states that can only be reached via intermediate states (as opposed to just via the same event type/request), the state machines between sending and receiving peers can get out of sync. I haven't convinced myself that any of these cases exists (state diagrams would make it perfectly clear!), so am not sure this is a blocking issue. I mention it here to ensure all aware of the issue and those more familiar with the protocol (perhaps even working on implementations) can confirm that they too don't see such cases. - Priority of inputs (FS vs SF-P) Per section 4.3.2, FS is lower priority than SF-P. Per lines 397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427 the difference between MS and FS is that an MS triggered switch to the protection path only will occur when the protection path is in normal state (i.e., no SF-P) while FS ignores the state of the protection path. Unless I'm missing something (which is always possible!) this means that FS should be *higher* priority than SF-P. This impacts the handling of the FS input for multiple states in section 4.3.3. and Appendix A. - Relationship to data plane behavior Section 3 briefly talks the "protection switching actions" that an LER may take, and that the "MEP SHOULD initiate a protection switch operation" (lines 417/8). But the document really stops short of defining what actions a local LER should take on particular state changes. It seems to me that required/recommended data-plane behavior should be explicitly (rather than implicitly) identified in section 4.3.3. Minor issues - use of RFC2119 language The following are cases where it looks like RFC2119 language was improperly used or omitted. There are also cases where SHOULD is used, but handling of other cases is not specified: - Section 3, lines 280-282 say that the "logical decomposition" depicted in Figure 1 and described in the remainder of the section is for "for descriptive purposes" and external behavior is defined in Section 4. To me this means that all of section 3 is informative in nature and *not* normative. Is this correct? If it is correct, i.e., the section is informative, then RFC2119 language needs to be removed from the section. Iff it is incorrect, i.e., the section is normative, than the following are problematic: - Line 330, needs to use rfc2119 language to parallel line 332 - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are there cases where it is reasonable for the "SHOULDs" to not be followed? In other words aren't these "MUSTs"? I not, probably should have a bit of text exploring these cases. - Lines 427, 435: this usage of "SHALL" really seems informative in nature, propose: s/SHALL include/includes - Line 370: s/shall/SHALL - Line 479: s/should/MUST - Line 490: if informative (which I think it is): s/should/are if normative: s/should/MUST - Line 503: s/shall/SHALL - Line 521: s/shall/SHALL - Line 579: s/should/MUST Again, these changes presume that this section is normative, if informative, then usage of 2119 language needs to be removed from the section. - Line 612, 617: these are informative/narrative sentences s/MUST/must|will s/SHALL/are - Lines 629, 638: aren't these MUSTs? If not needs some explanatory text. - Line 643 missing "default": s/an/a default - Section 4.3.3: There are a lot of "SHOULDs" in this section. Given this text relates to the synchronization of state between peers, what happens when one peer implements the "SHOULD" and the other peer does not? In order to avoid implementations that are compliant with this document but can't interoperate, either this case needs to be covered or these "SHOULDs" need to be "MUSTs". - Lines 205-206: The meaning of "maintain traffic" is not clear. - Lines 215-217: suggest making it explicit (rather than implied) that 1:1 unidirectional and 1:n are "out of scope of this document" - Lines 225-219: so is support for 1+1 for P2MP in or out of scope? This section really should be explicit on this point. - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your draft excludes [RFC4873], is this intentional? If so, why? - Lines 400-403, 444-446. The definitions for local MS and remote MS are subtly different. 400-403 says "switched from the working path to the protection path". While 444-446 says "switch the traffic to the path that was not being used previously". While I personally prefer this definition, Section 4.3.3 seems to say that 444-446 should read "switch the traffic from the working path to the protection path". - Line 665. No definition is given for the "Reserved" field. A typical definition for such fields is "The Reserved field MUST be set to zero on transmission and MUST be ignored on receipt." - Lines 678-681. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? - Numbering consistency The document is inconsistent with how it indicates field values. Unless there's a sub-structure to a field, e.g., a flags field, values should be listed in decimal not in binary. Impacts lines 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines really refer to bit fields, then the bits need to be defined. - Line 732. Is DNR limited to transmission behavior only? If not, need to change this line. - Lines 742-760. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? If there really is a need for future extensions (per line 755) then a wider field is really needed. - Lines 774-784: How is the absence of faults indicated? Perhaps 0 or 255 should be used for this case? - Lines 820: strictly speaking this field is not part of "TLV information", also receive behavior is not specified (see comment on line 665 above.) - Lines 822-824, The TLV format definition is missing. (I.e. how big are the T & L fields, does L include T&L or not, are there any padding requirements...) - Lines 853, 856, 866: text is informative, should not include RFC2119 language. - Handling of PA:F:L/FS after SFC-P If for some reason the prioritization of FS and SF-P remain as is (see major issue above), the current state machine definitions result in a the FS state being lost when an SF-P is cleared. Consider the case of the following states and inputs (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> WTR--(WTRExp)--> WTR--(remNR)-->N As the operator set FS, shouldn't the state return to PA:F:L not N? - SF-P can mask SF-W Consider the scenario where the protection path fails and then the working path fails. As I read Section 4.3.3 and appendix a, the order of states and inputs (in parentheses) are as follows: N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) This seems wrong. When the protection path SFc is received shouldn't the result be a protection switch / PF:W:L (NR(1,0)? - Remote SF impacts protection switching when using unidirectional protection As I read section 4.3, a remote SF will impact the behavior of the protection bridge of an LER even when 1+1 unidirectional protection is being used. My understanding is that the bridges are supposed to switch autonomously in this mode. Did I miss something? - IANA Considerations, section 5 Don't you want an IANA registry for the TLV types that may be defined in the future per section 4.2.7? Nits: Line 146: s/bandwidth/resources Line 147: s/is/are Line 393: Add (SFc) Line 417: Expand MEP Lines 519-526: These lines duplicate what's immediately following in 3.6.1, suggest dropping them. Line 559: s/is recovering/has recovered Line 592: the terminology SF(1,0) hasn't been defined at this point in the document, need a forward reference. Line 730: s/is recovering/has recovered Line 853: s/The value/Except during a protection switch, the value From Alexander.Vainshtein@ecitele.com Tue Jul 5 01:15:25 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29121F8795 for ; Tue, 5 Jul 2011 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IElPEwISjxh for ; Tue, 5 Jul 2011 01:15:24 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 578DB21F874D for ; Tue, 5 Jul 2011 01:15:23 -0700 (PDT) X-AuditID: 93eaf2e7-b7ba2ae0000011ca-41-4e12c8108d47 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7C.8A.04554.018C21E4; Tue, 5 Jul 2011 11:15:12 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 5 Jul 2011 11:15:19 +0300 From: Alexander Vainshtein To: Lou Berger , "rtg-ads@tools.ietf.org" Date: Tue, 5 Jul 2011 11:15:17 +0300 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Thread-Index: Acw5mIPuSce14W8PR3SzVWcndrPjcQBTrvsA Message-ID: References: <4E108F0B.5060305@labn.net> In-Reply-To: <4E108F0B.5060305@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTb0gTYRzm3Z3zXLt6d7r2uiLGlRaVsWXBKld9igmlpdGHPmTX7W072m5j d0mLyoGVJWnWCHIUakhEWYJYFCaYUppf+iNUlEV/tMjKtDLRD9rdrszoPhzP+3ue5/e8d/x+ FMGM662UIMo4LHJ+Vm8gYwPffmTBLibPfrVlpbNuZIx0Hiv9Qjo/nKsmnbUN/cnrSXd9/ZjO PdRUqnf/6Pmu30xsj4IcThSDMidjmwdLvIvdHBaKOT7C2gSPi3WwtpCf43EAi7KL5UIhLHrY tQbbf0+OIhNEGxb5oEcQvS42tzA/y+lcuSrLwa7NnO/IXmPY6hMkG84KcILfFsCSxHmxTans bCZ8lceOg9DRkn2P2mZEwVO+HKRQCK5ArWW9eg3PRg9fNSrYQDGwFaCPled12iEG0ItoB1BV euhCTVdeJhxpcBsaqbuYcBAwDtBodFSnEiRcgOIDZxKiVFiIor2Pfxu2opsnriVreDmKVZxK NKVhPhofbk7UGbgQ3Ru9m6inwEWorfMVoWKgXG+0uyHRn4AW9LyvRqddG6L62w8IDZvRx3cT SZrejHrLGoGmX4pqW77pNbwEXaz7RGi5JnS/uo/UvOnozqVnZBWwxKdFxKfZ49Ps8Wn2WkBe BmbBH5J3Bbx2xzLMCzL242V8MNAEtJn5cBOM1yxoB5ACrJGuGjblMUlcsRQJtIN0Ssea6Yx7 TB4zc1fQE/Fxkq8ovNePpXaAKIJNo0NtCkd7uMh+HA7+oZzKXz5FWGfwQWU6Rbko227/58Ba 6H7+8yYGepWp24NxCIf/WOdSFItorCaawtiL9+0W/PJfWkelqMlGJdnYqSZLIS4gCV6N7wbZ VMPVtx2AGrmlvBlSDIrYaqELVSlUpb694lQ3dWVKJicnB4BF+fJU2qqqjMpCTfUbUKJ0StRq zqRGKTsyRVmjYHCWJak6fd2hsQnTmy12Q03PxiNVlYMHKlK3Z/RkCpHmHY73uytyTvZh2Hke rnreNtFUWtI1GHNve9lxff/qure3dDkHv24Ya2zJNF03Hk4eLs6e6DKedsdk+cyTbnNR+YX+ 1hFf5uuzN4bmpMm5PwsK7ufeLTvS3DJES/PKRXcJS0o+zrGYCEvcL2Qe/YkNBAAA Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-linear-protection@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 08:15:25 -0000 Lou, and all, I agree with the following comment you've raised: > - Relationship to data plane behavior > > Section 3 briefly talks the "protection switching actions" that > an LER may take, and that the "MEP SHOULD initiate a protection > switch operation" (lines 417/8). But the document really stops > short of defining what actions a local LER should take on > particular state changes. It seems to me that > required/recommended data-plane behavior should be explicitly (rather > than implicitly) identified in section 4.3.3. I would like to bring to your attention a recent email thread "1+1 linear LS= P protection and MPLS-TP data plane: are they compatible?" 0n the MPLS WG ma= iling list: - http://www.ietf.org/mail-archive/web/mpls/current/msg06581.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06582.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06583.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06584.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06585.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06586.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06587.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06588.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06590.html - http://www.ietf.org/mail-archive/web/mpls/current/msg06592.html. This thread was all about implementing the Rx selector for 1+1 protected LSP= s within the constraints on the MPLS and PW data planes set by RFC 3031, 303= 2 and 4447. The original specific issue I've raised in this thread has been eventually r= esolved. But the general problem that IMHO should be addressed by the draft is the di= fference between the MPLS data plane and those of traditional transport netw= orks (SONET/SDH, OTN) regarding the way the client traffic and server path O= AM are separated: - in the case of the latter, the server trail OAM is an integral path of the= server "overhead": it cannot be removed or suppressed - in the case of the former, the OAM is just one more "labeled client" carri= ed by the server: if it is not present, the data plane of the server path co= uld not care less. I believe that this difference deserves careful analysis (either in the draf= t in question or in a more generic document). Regards, Sasha > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Lou Berger > Sent: Sunday, July 03, 2011 6:47 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-linear- > protection@tools.ietf.org > Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection- > 07.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and > IESG review, and sometimes on special request. The purpose of the > review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-mpls-tp-linear-protection-07.txt > Reviewer: Lou Berger > Review Date: 7/3/2011 > IETF LC End Date: 2011-07-05 > Intended Status: Standards Track > > Summary: > > I have some concerns about this document that I think should > be resolved before publication. > > Comments: > > Overall the document is well written and provides a lot of > detail. That said, I see a number of issues. Some of the > identified issues may be resolved through discussion (i.e., > correction of my misinterpretations!), others will require > changes to the text. > > In terms of readability, the document uses a state machine based > approach to define protocol behavior. While definition of state > machines is not novel in protocol specifications, I did find it a > bit hard to follow the presentation in this document. Particularly > from the perspective of verifying that all cases are covered. The > state table in Appendix A is certainly helpful, but I would have > preferred that it be normative as well as be accompanied by one or > more state diagrams. There are also inconsistencies in use of > RFC2119 and numbering conventions, which are pointed out below. > > Line numbers obtained from > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf- > mpls-tp-linear-protection-07.txt > will be used in this review. > > Major Issues: > > - State synchronization after message loss: > > The PSC protocol uses a soft-state messaging approach to > synchronize state between PSC protocol peers. Two basic > implications of soft-state messaging are (a) that peers can and > will get of sync during periods of message loss, and (b) each > state message must represent the full and *current* state of the > message sender. (b) is critical for recovering for one or more > lost messages. A key point is that intermediate state changes > will not be visible to a peer during periods of prolong PSC > message loss. So this all leads to two discussion points: state > convergence time and loss of intermediate states. > > - State convergence time: > > The current PSC protocol definition, see section 4.1, has > messages representing a change being retransmitted 3x fast, then > followed by a less frequent "continuous" refresh message (5 > second default refresh period). An implication of this approach > is that peers may get out of sync for {n * refresh interval} > after a period of PSC message loss. To me this seems like a > potentially long period of time. A simple change that would > improve protocol behavior would be to trigger the 3x fast > transmission whenever a peer reports that it has recovered from > a reception problem (remote SFc). This approach is already in > place for on case (remote NR). For simplicity, perhaps it would > be best to require whenever a peer reports any change. (I can > provide proposed language if it helps.) > > Another alternative would be to adopt the changes that were made > to RSVP, another soft state protocol, to address operationally > observed message loss. (See the reliable message delivery > sections of RFC 2961.) But this is probably too major a change > at this time. > > An easily fixed related point: Section 4.1 is missing the formal > definition of the sending of refresh messages. (It is presented > as informative in section 4.3.3.) Propose adding at line 637 > something along the lines of: > > After the transmission of the three rapid messages, the LER > MUST retransmit the most recently transmitted PSC message on > a continual basis. > > - Loss of intermediate states > > As defined, PSC messages don't represent full sender state as is > the norm for soft-state protocols, but rather provide the most > recent 'request' (see section 4.2.2.). This means that if there > are any states that can only be reached via intermediate states > (as opposed to just via the same event type/request), the state > machines between sending and receiving peers can get out of > sync. I haven't convinced myself that any of these cases exists > (state diagrams would make it perfectly clear!), so am not sure > this is a blocking issue. I mention it here to ensure all aware > of the issue and those more familiar with the protocol (perhaps > even working on implementations) can confirm that they too don't > see such cases. > > - Priority of inputs (FS vs SF-P) > > Per section 4.3.2, FS is lower priority than SF-P. Per lines > 397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427 > the difference between MS and FS is that an MS triggered switch > to the protection path only will occur when the protection path > is in normal state (i.e., no SF-P) while FS ignores the state of > the protection path. Unless I'm missing something (which is > always possible!) this means that FS should be *higher* priority > than SF-P. This impacts the handling of the FS input for > multiple states in section 4.3.3. and Appendix A. > > - Relationship to data plane behavior > > Section 3 briefly talks the "protection switching actions" that > an LER may take, and that the "MEP SHOULD initiate a protection > switch operation" (lines 417/8). But the document really stops > short of defining what actions a local LER should take on > particular state changes. It seems to me that > required/recommended data-plane behavior should be explicitly (rather > than implicitly) identified in section 4.3.3. > > Minor issues > > - use of RFC2119 language > > The following are cases where it looks like RFC2119 language was > improperly used or omitted. There are also cases where SHOULD > is used, but handling of other cases is not specified: > > - Section 3, lines 280-282 say that the "logical decomposition" > depicted in Figure 1 and described in the remainder of the > section is for "for descriptive purposes" and external > behavior is defined in Section 4. To me this means that all > of section 3 is informative in nature and *not* normative. Is > this correct? > > If it is correct, i.e., the section is informative, then > RFC2119 language needs to be removed from the section. > > Iff it is incorrect, i.e., the section is normative, than the > following are problematic: > > - Line 330, needs to use rfc2119 language to parallel line 332 > > - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are > there cases where it is reasonable for the "SHOULDs" to not > be followed? In other words aren't these "MUSTs"? I not, > probably should have a bit of text exploring these cases. > > - Lines 427, 435: this usage of "SHALL" really seems > informative in nature, propose: s/SHALL include/includes > > - Line 370: s/shall/SHALL > > - Line 479: s/should/MUST > > - Line 490: if informative (which I think it is): s/should/are > if normative: s/should/MUST > > - Line 503: s/shall/SHALL > > - Line 521: s/shall/SHALL > > - Line 579: s/should/MUST > > Again, these changes presume that this section is normative, if > informative, then usage of 2119 language needs to be removed > from the section. > > - Line 612, 617: these are informative/narrative sentences > s/MUST/must|will > s/SHALL/are > > - Lines 629, 638: aren't these MUSTs? If not needs some > explanatory text. > > - Line 643 missing "default": s/an/a default > > - Section 4.3.3: There are a lot of "SHOULDs" in this section. > Given this text relates to the synchronization of state between > peers, what happens when one peer implements the "SHOULD" and the > other peer does not? In order to avoid implementations that are > compliant with this document but can't interoperate, either this > case needs to be covered or these "SHOULDs" need to be "MUSTs". > > - Lines 205-206: The meaning of "maintain traffic" is not clear. > > - Lines 215-217: suggest making it explicit (rather than implied) > that 1:1 unidirectional and 1:n are "out of scope of this > document" > > - Lines 225-219: so is support for 1+1 for P2MP in or out of > scope? This section really should be explicit on this point. > > - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and > [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your > draft excludes [RFC4873], is this intentional? If so, why? > > - Lines 400-403, 444-446. The definitions for local MS and remote > MS are subtly different. 400-403 says "switched from the working > path to the protection path". While 444-446 says "switch the > traffic to the path that was not being used previously". While > I personally prefer this definition, Section 4.3.3 seems to say > that 444-446 should read "switch the traffic from the working > path to the protection path". > > - Line 665. No definition is given for the "Reserved" field. A > typical definition for such fields is "The Reserved field MUST > be set to zero on transmission and MUST be ignored on receipt." > > - Lines 678-681. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? > > - Numbering consistency > > The document is inconsistent with how it indicates field values. > Unless there's a sub-structure to a field, e.g., a flags field, > values should be listed in decimal not in binary. Impacts lines > 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines > really refer to bit fields, then the bits need to be defined. > > - Line 732. Is DNR limited to transmission behavior only? If not, > need to change this line. > > - Lines 742-760. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? If there really is a need for future > extensions (per line 755) then a wider field is really needed. > > - Lines 774-784: How is the absence of faults indicated? Perhaps 0 > or 255 should be used for this case? > > - Lines 820: strictly speaking this field is not part of "TLV > information", also receive behavior is not specified (see > comment on line 665 above.) > > - Lines 822-824, The TLV format definition is missing. (I.e. how > big are the T & L fields, does L include T&L or not, are there > any padding requirements...) > > - Lines 853, 856, 866: text is informative, should not include > RFC2119 language. > > - Handling of PA:F:L/FS after SFC-P > > If for some reason the prioritization of FS and SF-P remain as > is (see major issue above), the current state machine > definitions result in a the FS state being lost when an SF-P is > cleared. Consider the case of the following states and inputs > (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> > WTR--(WTRExp)--> WTR--(remNR)-->N > > As the operator set FS, shouldn't the state return to PA:F:L not > N? > > - SF-P can mask SF-W > > Consider the scenario where the protection path fails and then > the working path fails. As I read Section 4.3.3 and appendix a, > the order of states and inputs (in parentheses) are as follows: > N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) > > This seems wrong. When the protection path SFc is received > shouldn't the result be a protection switch / PF:W:L (NR(1,0)? > > - Remote SF impacts protection switching when using unidirectional > protection > > As I read section 4.3, a remote SF will impact the behavior of > the protection bridge of an LER even when 1+1 unidirectional > protection is being used. My understanding is that the bridges > are supposed to switch autonomously in this mode. Did I miss > something? > > - IANA Considerations, section 5 > Don't you want an IANA registry for the TLV types that may be > defined in the future per section 4.2.7? > > Nits: > > Line 146: s/bandwidth/resources > Line 147: s/is/are > Line 393: Add (SFc) > Line 417: Expand MEP > Lines 519-526: These lines duplicate what's immediately following > in 3.6.1, suggest dropping them. > Line 559: s/is recovering/has recovered > Line 592: the terminology SF(1,0) hasn't been defined at this > point in the document, need a forward reference. > Line 730: s/is recovering/has recovered > Line 853: s/The value/Except during a protection switch, the value This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From lberger@labn.net Tue Jul 5 04:07:42 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE7421F8736 for ; Tue, 5 Jul 2011 04:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmEGDfRXHWKF for ; Tue, 5 Jul 2011 04:07:39 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id CFF0821F8761 for ; Tue, 5 Jul 2011 04:07:39 -0700 (PDT) Received: (qmail 17688 invoked by uid 0); 5 Jul 2011 11:07:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 5 Jul 2011 11:07:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=r8bjSmls21t4HrwIYCxyiVdQ3gXmCRU7fWwNkllWwNWqF0MCCNM8cQrhhbwEOFQPQHcVnOIwcbKLTh2Pv3IKRWpCoslaawM4Fr4lzckeUIG31InpbqTa3xIf02S9zpJu; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qe3Tf-0002XU-3u; Tue, 05 Jul 2011 05:07:39 -0600 Message-ID: <4E12F07B.4000509@labn.net> Date: Tue, 05 Jul 2011 07:07:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Alexander Vainshtein References: <4E108F0B.5060305@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-linear-protection@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 11:07:42 -0000 Sasha, I think you may be reading too much into my comment. I was just asking for a (consistent level of) description of bridge behavior... Lou On 7/5/2011 4:15 AM, Alexander Vainshtein wrote: > Lou, and all, > I agree with the following comment you've raised: > >> - Relationship to data plane behavior >> >> Section 3 briefly talks the "protection switching actions" that >> an LER may take, and that the "MEP SHOULD initiate a protection >> switch operation" (lines 417/8). But the document really stops >> short of defining what actions a local LER should take on >> particular state changes. It seems to me that >> required/recommended data-plane behavior should be explicitly (rather >> than implicitly) identified in section 4.3.3. > > > I would like to bring to your attention a recent email thread "1+1 linear LSP protection and MPLS-TP data plane: are they compatible?" 0n the MPLS WG mailing list: > > - http://www.ietf.org/mail-archive/web/mpls/current/msg06581.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06582.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06583.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06584.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06585.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06586.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06587.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06588.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06590.html > - http://www.ietf.org/mail-archive/web/mpls/current/msg06592.html. > > > This thread was all about implementing the Rx selector for 1+1 protected LSPs within the constraints on the MPLS and PW data planes set by RFC 3031, 3032 and 4447. > > The original specific issue I've raised in this thread has been eventually resolved. > > But the general problem that IMHO should be addressed by the draft is the difference between the MPLS data plane and those of traditional transport networks (SONET/SDH, OTN) regarding the way the client traffic and server path OAM are separated: > - in the case of the latter, the server trail OAM is an integral path of the server "overhead": it cannot be removed or suppressed > - in the case of the former, the OAM is just one more "labeled client" carried by the server: if it is not present, the data plane of the server path could not care less. > > I believe that this difference deserves careful analysis (either in the draft in question or in a more generic document). > > Regards, > Sasha > >> -----Original Message----- >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On >> Behalf Of Lou Berger >> Sent: Sunday, July 03, 2011 6:47 PM >> To: rtg-ads@tools.ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-linear- >> protection@tools.ietf.org >> Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection- >> 07.txt >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >> draft. The Routing Directorate seeks to review all routing or >> routing-related drafts as they pass through IETF last call and >> IESG review, and sometimes on special request. The purpose of the >> review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing >> ADs, it would be helpful if you could consider them along with any >> other IETF Last Call comments that you receive, and strive to >> resolve them through discussion or by updating the draft. >> >> Document: draft-ietf-mpls-tp-linear-protection-07.txt >> Reviewer: Lou Berger >> Review Date: 7/3/2011 >> IETF LC End Date: 2011-07-05 >> Intended Status: Standards Track >> >> Summary: >> >> I have some concerns about this document that I think should >> be resolved before publication. >> >> Comments: >> >> Overall the document is well written and provides a lot of >> detail. That said, I see a number of issues. Some of the >> identified issues may be resolved through discussion (i.e., >> correction of my misinterpretations!), others will require >> changes to the text. >> >> In terms of readability, the document uses a state machine based >> approach to define protocol behavior. While definition of state >> machines is not novel in protocol specifications, I did find it a >> bit hard to follow the presentation in this document. Particularly >> from the perspective of verifying that all cases are covered. The >> state table in Appendix A is certainly helpful, but I would have >> preferred that it be normative as well as be accompanied by one or >> more state diagrams. There are also inconsistencies in use of >> RFC2119 and numbering conventions, which are pointed out below. >> >> Line numbers obtained from >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf- >> mpls-tp-linear-protection-07.txt >> will be used in this review. >> >> Major Issues: >> >> - State synchronization after message loss: >> >> The PSC protocol uses a soft-state messaging approach to >> synchronize state between PSC protocol peers. Two basic >> implications of soft-state messaging are (a) that peers can and >> will get of sync during periods of message loss, and (b) each >> state message must represent the full and *current* state of the >> message sender. (b) is critical for recovering for one or more >> lost messages. A key point is that intermediate state changes >> will not be visible to a peer during periods of prolong PSC >> message loss. So this all leads to two discussion points: state >> convergence time and loss of intermediate states. >> >> - State convergence time: >> >> The current PSC protocol definition, see section 4.1, has >> messages representing a change being retransmitted 3x fast, then >> followed by a less frequent "continuous" refresh message (5 >> second default refresh period). An implication of this approach >> is that peers may get out of sync for {n * refresh interval} >> after a period of PSC message loss. To me this seems like a >> potentially long period of time. A simple change that would >> improve protocol behavior would be to trigger the 3x fast >> transmission whenever a peer reports that it has recovered from >> a reception problem (remote SFc). This approach is already in >> place for on case (remote NR). For simplicity, perhaps it would >> be best to require whenever a peer reports any change. (I can >> provide proposed language if it helps.) >> >> Another alternative would be to adopt the changes that were made >> to RSVP, another soft state protocol, to address operationally >> observed message loss. (See the reliable message delivery >> sections of RFC 2961.) But this is probably too major a change >> at this time. >> >> An easily fixed related point: Section 4.1 is missing the formal >> definition of the sending of refresh messages. (It is presented >> as informative in section 4.3.3.) Propose adding at line 637 >> something along the lines of: >> >> After the transmission of the three rapid messages, the LER >> MUST retransmit the most recently transmitted PSC message on >> a continual basis. >> >> - Loss of intermediate states >> >> As defined, PSC messages don't represent full sender state as is >> the norm for soft-state protocols, but rather provide the most >> recent 'request' (see section 4.2.2.). This means that if there >> are any states that can only be reached via intermediate states >> (as opposed to just via the same event type/request), the state >> machines between sending and receiving peers can get out of >> sync. I haven't convinced myself that any of these cases exists >> (state diagrams would make it perfectly clear!), so am not sure >> this is a blocking issue. I mention it here to ensure all aware >> of the issue and those more familiar with the protocol (perhaps >> even working on implementations) can confirm that they too don't >> see such cases. >> >> - Priority of inputs (FS vs SF-P) >> >> Per section 4.3.2, FS is lower priority than SF-P. Per lines >> 397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427 >> the difference between MS and FS is that an MS triggered switch >> to the protection path only will occur when the protection path >> is in normal state (i.e., no SF-P) while FS ignores the state of >> the protection path. Unless I'm missing something (which is >> always possible!) this means that FS should be *higher* priority >> than SF-P. This impacts the handling of the FS input for >> multiple states in section 4.3.3. and Appendix A. >> >> - Relationship to data plane behavior >> >> Section 3 briefly talks the "protection switching actions" that >> an LER may take, and that the "MEP SHOULD initiate a protection >> switch operation" (lines 417/8). But the document really stops >> short of defining what actions a local LER should take on >> particular state changes. It seems to me that >> required/recommended data-plane behavior should be explicitly (rather >> than implicitly) identified in section 4.3.3. >> >> Minor issues >> >> - use of RFC2119 language >> >> The following are cases where it looks like RFC2119 language was >> improperly used or omitted. There are also cases where SHOULD >> is used, but handling of other cases is not specified: >> >> - Section 3, lines 280-282 say that the "logical decomposition" >> depicted in Figure 1 and described in the remainder of the >> section is for "for descriptive purposes" and external >> behavior is defined in Section 4. To me this means that all >> of section 3 is informative in nature and *not* normative. Is >> this correct? >> >> If it is correct, i.e., the section is informative, then >> RFC2119 language needs to be removed from the section. >> >> Iff it is incorrect, i.e., the section is normative, than the >> following are problematic: >> >> - Line 330, needs to use rfc2119 language to parallel line 332 >> >> - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are >> there cases where it is reasonable for the "SHOULDs" to not >> be followed? In other words aren't these "MUSTs"? I not, >> probably should have a bit of text exploring these cases. >> >> - Lines 427, 435: this usage of "SHALL" really seems >> informative in nature, propose: s/SHALL include/includes >> >> - Line 370: s/shall/SHALL >> >> - Line 479: s/should/MUST >> >> - Line 490: if informative (which I think it is): s/should/are >> if normative: s/should/MUST >> >> - Line 503: s/shall/SHALL >> >> - Line 521: s/shall/SHALL >> >> - Line 579: s/should/MUST >> >> Again, these changes presume that this section is normative, if >> informative, then usage of 2119 language needs to be removed >> from the section. >> >> - Line 612, 617: these are informative/narrative sentences >> s/MUST/must|will >> s/SHALL/are >> >> - Lines 629, 638: aren't these MUSTs? If not needs some >> explanatory text. >> >> - Line 643 missing "default": s/an/a default >> >> - Section 4.3.3: There are a lot of "SHOULDs" in this section. >> Given this text relates to the synchronization of state between >> peers, what happens when one peer implements the "SHOULD" and the >> other peer does not? In order to avoid implementations that are >> compliant with this document but can't interoperate, either this >> case needs to be covered or these "SHOULDs" need to be "MUSTs". >> >> - Lines 205-206: The meaning of "maintain traffic" is not clear. >> >> - Lines 215-217: suggest making it explicit (rather than implied) >> that 1:1 unidirectional and 1:n are "out of scope of this >> document" >> >> - Lines 225-219: so is support for 1+1 for P2MP in or out of >> scope? This section really should be explicit on this point. >> >> - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and >> [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your >> draft excludes [RFC4873], is this intentional? If so, why? >> >> - Lines 400-403, 444-446. The definitions for local MS and remote >> MS are subtly different. 400-403 says "switched from the working >> path to the protection path". While 444-446 says "switch the >> traffic to the path that was not being used previously". While >> I personally prefer this definition, Section 4.3.3 seems to say >> that 444-446 should read "switch the traffic from the working >> path to the protection path". >> >> - Line 665. No definition is given for the "Reserved" field. A >> typical definition for such fields is "The Reserved field MUST >> be set to zero on transmission and MUST be ignored on receipt." >> >> - Lines 678-681. Are 2 bits really sufficient for the long term? >> There are 23 unused bits in the header, perhaps you want to give >> one to this field? >> >> - Numbering consistency >> >> The document is inconsistent with how it indicates field values. >> Unless there's a sub-structure to a field, e.g., a flags field, >> values should be listed in decimal not in binary. Impacts lines >> 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines >> really refer to bit fields, then the bits need to be defined. >> >> - Line 732. Is DNR limited to transmission behavior only? If not, >> need to change this line. >> >> - Lines 742-760. Are 2 bits really sufficient for the long term? >> There are 23 unused bits in the header, perhaps you want to give >> one to this field? If there really is a need for future >> extensions (per line 755) then a wider field is really needed. >> >> - Lines 774-784: How is the absence of faults indicated? Perhaps 0 >> or 255 should be used for this case? >> >> - Lines 820: strictly speaking this field is not part of "TLV >> information", also receive behavior is not specified (see >> comment on line 665 above.) >> >> - Lines 822-824, The TLV format definition is missing. (I.e. how >> big are the T & L fields, does L include T&L or not, are there >> any padding requirements...) >> >> - Lines 853, 856, 866: text is informative, should not include >> RFC2119 language. >> >> - Handling of PA:F:L/FS after SFC-P >> >> If for some reason the prioritization of FS and SF-P remain as >> is (see major issue above), the current state machine >> definitions result in a the FS state being lost when an SF-P is >> cleared. Consider the case of the following states and inputs >> (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> >> WTR--(WTRExp)--> WTR--(remNR)-->N >> >> As the operator set FS, shouldn't the state return to PA:F:L not >> N? >> >> - SF-P can mask SF-W >> >> Consider the scenario where the protection path fails and then >> the working path fails. As I read Section 4.3.3 and appendix a, >> the order of states and inputs (in parentheses) are as follows: >> N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) >> >> This seems wrong. When the protection path SFc is received >> shouldn't the result be a protection switch / PF:W:L (NR(1,0)? >> >> - Remote SF impacts protection switching when using unidirectional >> protection >> >> As I read section 4.3, a remote SF will impact the behavior of >> the protection bridge of an LER even when 1+1 unidirectional >> protection is being used. My understanding is that the bridges >> are supposed to switch autonomously in this mode. Did I miss >> something? >> >> - IANA Considerations, section 5 >> Don't you want an IANA registry for the TLV types that may be >> defined in the future per section 4.2.7? >> >> Nits: >> >> Line 146: s/bandwidth/resources >> Line 147: s/is/are >> Line 393: Add (SFc) >> Line 417: Expand MEP >> Lines 519-526: These lines duplicate what's immediately following >> in 3.6.1, suggest dropping them. >> Line 559: s/is recovering/has recovered >> Line 592: the terminology SF(1,0) hasn't been defined at this >> point in the document, need a forward reference. >> Line 730: s/is recovering/has recovered >> Line 853: s/The value/Except during a protection switch, the value > > > > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > > From lberger@labn.net Tue Jul 5 04:33:30 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A321F86A3 for ; Tue, 5 Jul 2011 04:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey6+NkyAcP-R for ; Tue, 5 Jul 2011 04:33:29 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id C8E7421F86A1 for ; Tue, 5 Jul 2011 04:33:29 -0700 (PDT) Received: (qmail 20701 invoked by uid 0); 5 Jul 2011 11:33:29 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 5 Jul 2011 11:33:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dAXk2HqIaJ6PfqnMKm73WOAP7hyodA3IqZ/3vOy2ODDE2NUd7175HePl4gqZQFI7etDD0Es4V7m0o5aVPFbutMVwXvh0425SkCfVHuXz2j64bILMwv2zICSvDS8CrKz9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qe3sf-0000xv-2Q; Tue, 05 Jul 2011 05:33:29 -0600 Message-ID: <4E12F689.1060904@labn.net> Date: Tue, 05 Jul 2011 07:33:29 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" References: <4E108F0B.5060305@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 11:33:30 -0000 Yaacov, Thank you for the quick response to the majority of the topics I raised. I only have a response to a few of your responses. See below. (I've cut out closed points.) On 7/5/2011 5:14 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: > Lou, hi > > First off - I would like to thank you for your very thorough and > complete review of the document and the protocol. critiques are always easier than authoring... > ... > > - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are > there cases where it is reasonable for the "SHOULDs" to not > be followed? In other words aren't these "MUSTs"? I not, > probably should have a bit of text exploring these cases. > [yw>] 358 - will be changed to be informative, 364 - will change to > SHALL, 415 & 418 - will change to informative, 423 - ??, 512, 515, 518 - > will change to informative, 574, 576, & 585 - will change to informative not sure what the '??' means here, are you asking a question? > ... > > - Lines 225-219: so is support for 1+1 for P2MP in or out of > scope? This section really should be explicit on this point. > [yw>] Will add a statement that this is out-of-scope and may be > described in a separate applicability document. okay, but note that this means [RFC5654] 65.C. is not covered by the document. > ... > > - Lines 678-681. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? > [yw>] Will consult regarding this! > ... > > - Lines 742-760. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? If there really is a need for future > extensions (per line 755) then a wider field is really needed. > [yw>] Will consult regarding this! > > - Lines 774-784: How is the absence of faults indicated? Perhaps 0 > or 255 should be used for this case? > [yw>] The current understanding was that this field is ignored when the > Request field is not indicating a fault condition see lines 725 & 733 I did see those, I was suggesting to use an explicit rather than implicit value for such cases. If you leave the values as is, then section 4.2.5 really should say that such cases exists. Perhaps, add something along the lines of "When a fault condition is indicated in the PSC Request field," to the start of line 776. > ... > > - Lines 822-824, The TLV format definition is missing. (I.e. how > big are the T & L fields, does L include T&L or not, are there > any padding requirements...) > [yw>] Will consult regarding this. > ... > > - Handling of PA:F:L/FS after SFC-P > > If for some reason the prioritization of FS and SF-P remain as > is (see major issue above), the current state machine > definitions result in a the FS state being lost when an SF-P is > cleared. Consider the case of the following states and inputs > (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> > WTR--(WTRExp)--> WTR--(remNR)-->N > > As the operator set FS, shouldn't the state return to PA:F:L not > N? > [yw>] What you are suggesting, IMHO, is an optimization. If the FS is > still being asserted, then immediately after going into Normal the FS > would be recognized and cause the domain to reenter PA:F:L. We (i.e. > the authors) made a conscious decision to not describe this optimization > after a rather lengthy discussion when it was brought to our attention > and this was explained to the different commenters at the time. > > - SF-P can mask SF-W > > Consider the scenario where the protection path fails and then > the working path fails. As I read Section 4.3.3 and appendix a, > the order of states and inputs (in parentheses) are as follows: > N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) > > This seems wrong. When the protection path SFc is received > shouldn't the result be a protection switch / PF:W:L (NR(1,0)? > [yw>] Similar to the previous consideration. > Okay, I understand the approach the authors are taking. Although to ensure proper implementation and interoperability, this approach needs to be made explicit in the document, probably somewhere in section 4.3. Furthermore, Section 3 needs to address this in the description of generation and handling of "local requests". > - Remote SF impacts protection switching when using unidirectional > protection > > As I read section 4.3, a remote SF will impact the behavior of > the protection bridge of an LER even when 1+1 unidirectional > protection is being used. My understanding is that the bridges > are supposed to switch autonomously in this mode. Did I miss > something? > > - IANA Considerations, section 5 > Don't you want an IANA registry for the TLV types that may be > defined in the future per section 4.2.7? > You may have missed the prior 2 comments. > ... Thanks again for the quick response. Lou From lberger@labn.net Tue Jul 5 05:50:09 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E1D1F0C38 for ; Tue, 5 Jul 2011 05:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIMCs44voFTh for ; Tue, 5 Jul 2011 05:50:08 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id E3C4D1F0C36 for ; Tue, 5 Jul 2011 05:50:07 -0700 (PDT) Received: (qmail 20820 invoked by uid 0); 5 Jul 2011 12:50:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 5 Jul 2011 12:50:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=WrJelaOFZ8LBbbd3jqjs+cCpJIG+thkV51ft4qEn4u/Jx7/vYt0t8xanOCt3u7DO8hUUJ+ero3H+v5kmMS3TQZTyqjqnH9FHFM0d6lKByLRpQhAA+dhxjUNyLp52zPx3; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qe54p-00053d-DW; Tue, 05 Jul 2011 06:50:07 -0600 Message-ID: <4E130880.2030809@labn.net> Date: Tue, 05 Jul 2011 08:50:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" References: <4E108F0B.5060305@labn.net> <4E12F689.1060904@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 12:50:09 -0000 Yaacov, I'm also not sure which line I was referring to either. There's probably some other "SHOULD" in the document that this applies to... Lou On 7/5/2011 7:40 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: > Lou, hi > > Just a note regarding the "423 ??" - It was just noting that I could not > find any Normative text on line 423. Could be that you meant 427, that > I listed separately that I will remove the normative SHALL! > > I did not miss those last two notes - but I need to consult with others > (possibly the WG chairs) on these. > > BR, > yaacov > > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, July 05, 2011 2:33 PM > To: Weingarten, Yaacov (NSN - IL/Hod HaSharon) > Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; > draft-ietf-mpls-tp-linear-protection@tools.ietf.org > Subject: Re: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt > > Yaacov, > > Thank you for the quick response to the majority of the topics I raised. > > I only have a response to a few of your responses. See below. (I've > cut out closed points.) > > > On 7/5/2011 5:14 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: >> Lou, hi >> >> First off - I would like to thank you for your very thorough and >> complete review of the document and the protocol. > > critiques are always easier than authoring... > >> ... > >> >> - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are >> there cases where it is reasonable for the "SHOULDs" to not >> be followed? In other words aren't these "MUSTs"? I not, >> probably should have a bit of text exploring these cases. >> [yw>] 358 - will be changed to be informative, 364 - will change to >> SHALL, 415 & 418 - will change to informative, 423 - ??, 512, 515, 518 > - >> will change to informative, 574, 576, & 585 - will change to > informative > > not sure what the '??' means here, are you asking a question? > >> ... > >> >> - Lines 225-219: so is support for 1+1 for P2MP in or out of >> scope? This section really should be explicit on this point. >> [yw>] Will add a statement that this is out-of-scope and may be >> described in a separate applicability document. > > okay, but note that this means [RFC5654] 65.C. is not covered by the > document. > >> ... > >> >> - Lines 678-681. Are 2 bits really sufficient for the long term? >> There are 23 unused bits in the header, perhaps you want to give >> one to this field? >> [yw>] Will consult regarding this! > >> ... > >> >> - Lines 742-760. Are 2 bits really sufficient for the long term? >> There are 23 unused bits in the header, perhaps you want to give >> one to this field? If there really is a need for future >> extensions (per line 755) then a wider field is really needed. >> [yw>] Will consult regarding this! > >> >> - Lines 774-784: How is the absence of faults indicated? Perhaps 0 >> or 255 should be used for this case? >> [yw>] The current understanding was that this field is ignored when > the >> Request field is not indicating a fault condition see lines 725 & 733 > > I did see those, I was suggesting to use an explicit rather than > implicit value for such cases. If you leave the values as is, then > section 4.2.5 really should say that such cases exists. Perhaps, add > something along the lines of "When a fault condition is indicated in the > PSC Request field," to the start of line 776. > >> ... > >> >> - Lines 822-824, The TLV format definition is missing. (I.e. how >> big are the T & L fields, does L include T&L or not, are there >> any padding requirements...) >> [yw>] Will consult regarding this. > >> ... > >> >> - Handling of PA:F:L/FS after SFC-P >> >> If for some reason the prioritization of FS and SF-P remain as >> is (see major issue above), the current state machine >> definitions result in a the FS state being lost when an SF-P is >> cleared. Consider the case of the following states and inputs >> (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> >> WTR--(WTRExp)--> WTR--(remNR)-->N >> >> As the operator set FS, shouldn't the state return to PA:F:L not >> N? >> [yw>] What you are suggesting, IMHO, is an optimization. If the FS is >> still being asserted, then immediately after going into Normal the FS >> would be recognized and cause the domain to reenter PA:F:L. We (i.e. >> the authors) made a conscious decision to not describe this > optimization >> after a rather lengthy discussion when it was brought to our attention >> and this was explained to the different commenters at the time. >> >> - SF-P can mask SF-W >> >> Consider the scenario where the protection path fails and then >> the working path fails. As I read Section 4.3.3 and appendix a, >> the order of states and inputs (in parentheses) are as follows: >> N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending > NR(0,0)) >> >> This seems wrong. When the protection path SFc is received >> shouldn't the result be a protection switch / PF:W:L (NR(1,0)? >> [yw>] Similar to the previous consideration. >> > > Okay, I understand the approach the authors are taking. Although to > ensure proper implementation and interoperability, this approach needs > to be made explicit in the document, probably somewhere in section 4.3. > Furthermore, Section 3 needs to address this in the description of > generation and handling of "local requests". > >> - Remote SF impacts protection switching when using unidirectional >> protection >> >> As I read section 4.3, a remote SF will impact the behavior of >> the protection bridge of an LER even when 1+1 unidirectional >> protection is being used. My understanding is that the bridges >> are supposed to switch autonomously in this mode. Did I miss >> something? >> >> - IANA Considerations, section 5 >> Don't you want an IANA registry for the TLV types that may be >> defined in the future per section 4.2.7? >> > > You may have missed the prior 2 comments. > >> ... > > Thanks again for the quick response. > > Lou > > > > From julien.meuric@orange-ftgroup.com Fri Jul 8 09:53:35 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3E721F8BEB for ; Fri, 8 Jul 2011 09:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=3.067, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K80ls+z1Pq2o for ; Fri, 8 Jul 2011 09:53:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89B21F8B82 for ; Fri, 8 Jul 2011 09:53:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 833198B800C; Fri, 8 Jul 2011 18:54:19 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8BF918B8005; Fri, 8 Jul 2011 18:54:18 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 18:53:32 +0200 Received: from [10.193.71.247] ([10.193.71.247]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 18:53:31 +0200 Message-ID: <4E17360B.5010309@orange-ftgroup.com> Date: Fri, 08 Jul 2011 18:53:31 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4E0FB27E.6010907@orange-ftgroup.com> <6A2A459175DABE4BB11DE2026AA50A5D04FAF26F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D04FAF26F@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jul 2011 16:53:31.0479 (UTC) FILETIME=[91550E70:01CC3D8F] Cc: rtg-dir@ietf.org, draft-ietf-roll-of0.all@tools.ietf.org, roll-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-roll-of0 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:53:35 -0000 Hi Pascal. You are welcome. I have checked the release 15 you have pointed me to: - the new definition of Sr addresses my comment; - I am completely fine with lowercasing "may" rather than "NOT RECOMMENDED": I was not aware of the expected level of requirement, but it now avoids any inconsistency in RFC 2119, which was my point; - I do not see any blocking point in section 4.2 (though improvable, obviously ;-) ). Have a good week-end, Julien Le 05/07/2011 15:03, Pascal Thubert (pthubert) a écrit : > Thanks a lot Julien for this very serious review. > > Please see in line >> *Summary:* >> This document is basically ready for publication, but has nits that >> should be considered prior to publication. >> >> *Comments:* >> This document is clearly well written and clearly focused, though >> relying on many concepts defined within RPL. This is the first ROLL >> document I have reviewed, so it may mean that my review is not >> sufficiently in-depth. >> I noted that many terms are capitalized: it seems unusual at the >> beginning but appears to be helpful so as to identify RPL-related > concepts. >> *Major Issues:* >> No major issues found. >> >> *Minor Issues:* >> Just a few minor issues, which I could almost have put among the nits. >> - In section 6.2, stretch_of_rank is defined as "the maximum >> augmentation" while, as far as I understand the formula at the end of >> section 4.1, it is rather "the minimum augmentation". > [Pascal] If the parent set is large enough without stretching, there is > no point doing it. > 4.1 says: > " > Still, an > implementation MAY stretch the step_of_rank with at most a > configurable stretch_of_rank (Section 6.2) of any value between 0 (no > stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3). > " > I do mean it is a maximum and that is consistent with 61. > > I think the confusion comes from the definition of Sr in the formula > " > The step_of_rank Sp that is computed for that link is multiplied by > the rank_factor Rf and then possibly stretched by a stretch_of_rank > Sr. > " > > What about saying: > " > The step_of_rank Sp that is computed for that link is multiplied by > the rank_factor Rf and then stretched by a term Sr that is between 0 > and stretch_of_rank. > " > >> - Section 4.1 says "Stretching the step_of_rank is NOT RECOMMENDED" >> while "an implementation MAY stretch the step_of_rank": using both >> keywords does not seem consistent. Since stretch_of_rank is part of > the >> document, it looks like "MAY" is correct. The capital letters of "NOT >> RECOMMENDED" should be removed, or the phrase may be replaced (e.g. >> "ought to be avoided"). > [Pascal] Adrian suggested "NOT RECOMMENDED" in upper case and I agree > with his point. > I'm unclear why this is in opposition with the "MAY". If it is I'r > rather lowercase the 'MAY' than the "NOT RECOMMENDED". > >> - Section 4.2.1, 3rd bullet: what about multiple interfaces without >> policy? Section 4.2.2, 1st bullet: is there a reason why policy is no >> longer mentioned there? If the order of the rules may vary, why not > [Pascal] It is there implicitly. The policy text explained what we mean > by higher order. The same order plays in both sections. > >> writing, in the document, the list in the same order for the Preferred >> Parent and the Backup Feasible Successor? (1 -> 4; 2 -> 6; 3 -> 1...) >> Why different wording between sections? > [Pascal] I agree with you, 1 of 4.2.2 should really move after the > current 6. You'll note that the selection of the preferred parent cause > the selection of the DODAG version, and once this is done, some options > for the alternate are not available anymore, and that the backup does > not have to be a parent (it can belong to a subsequent version). > > >> *Nits:* (some may be deferred to the RFC Editor) > [Pascal] I'll fix those I can in the post. Some to be discusses with RC > editor unless someone knowledgeable enlightens me first. > > Cheers, > > Pascal > > From ben@niven-jenkins.co.uk Tue Jul 12 14:23:22 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0F421F8B64 for ; Tue, 12 Jul 2011 14:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ-BwueUNsZT for ; Tue, 12 Jul 2011 14:23:17 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA321F8B58 for ; Tue, 12 Jul 2011 14:23:16 -0700 (PDT) Received: from [64.207.45.227] (helo=[10.1.179.80]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QgkQE-00060W-Nw; Tue, 12 Jul 2011 22:23:15 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2011 22:23:09 +0100 Message-Id: <9596E295-64F9-48B4-B5DC-CB8894ADBFD2@niven-jenkins.co.uk> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-mpls-tp-identifiers.all@tools.ietf.org, rtg-dir@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-identifiers-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:23:23 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-mpls-tp-identifiers-06.txt Reviewer: Ben Niven-Jenkins Review Date: 12 July 2011 IETF LC End Date: 11 July 2011 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be = resolved before publication. Comments: In general the document is well written, however it defines the format = for a number of different identifiers some of which are related to = others in various ways and it is difficult from reading the document to = easily get an idea of the "big picture" of how the relationship between = the different identifiers which are defined. For example section 5.1 defines the format for a Tunnel_ID and then goes = on to state "When an MPLS-TP Tunnel is configured, it MUST be assigned a = unique IF_ID at each endpoint. As usual, the IF_ID is composed of the = local Node_ID concatenated with a 32-bit IF_Num." However, the = definition of Tunnel_ID does not contain an IF_ID so it is not obvious = to me from reading the draft what the relationship is between the = Tunnel_ID for a tunnel and the IF_ID for the same tunnel and the = circumstances when Tunnel_ID is the appropriate identifier versus when = IF_ID is the appropriate identifer. Section 7.3 contains a simple diagram and uses it to show how the = identifiers are formed for a Pseudowire Segment Endpoint ID and it may = be useful to have a similar but expanded diagram at the beginning of the = document to show the different types of identifier that are defined, = their scope within a network and how they relate to one another. Please also note that I reviewed this document without reading all the = MPLS-TP related OAM documents and so some of my questions may have been = answered if I had done so (e.g. minor issue 5 below). Minor Issues: Some of the following "Minor Issues" are more questions for my = understanding and suggestions rather than "pure" issues as such but they = are more substantial than nits so I included them here. 1) Section 4 states that "The Node_ID is a unique 32-bit value" and that = "The IF_Num is a 32-bit unsigned integer" Additionally both Tunnel_Num and LSP_Num are declared to be unsigned = integers but no other fields (except IF_Num mentioned above) are.=20 Is that meant to signify that Node_IDs (for example) are signed values = or is it because they are fields with a structured value (e.g. an IPv4 = address?) or some other reason such as it is expected to impact how they = are represented on the wire? 2) The document makes several references to using an "A1/Z9 convention", = while it can be inferred that A1 and Z9 refer to either end of a = connection, is there a definitive reference for this convention as it is = not one I am familiar with and a search using a well known search engine = just returned results that linked this draft? 3) Section 5.2.1 states: Thus the format of an MPLS-TP co-routed bidirectional LSP_ID=20 is: A1-{Node_ID::Tunnel_Num}::Z9- {Node_ID::Tunnel_Num}::LSP_Num Note that the uniqueness of identifiers does not depend on=20 the A1/Z9 sort ordering. Thus the identifier Z9-{Node_ID::Tunnel_Num}::A1- {Node_ID::Tunnel_Num}::LSP_Num is synonymous with the one above. I can see how the A1/Z9 sort ordering can generate different values for = LSP_ID and that as they are both referring to the same LSP they are = synonymous with one another. Is there any requirement for an application = to be able to translate from one possible LSP_ID to another synonymous = LSP_ID for the same LSP? Should there be an explicit mention that = applications MUST treat both forms as identical? 4) Section 5.3 states * Extended Tunnel_ID =3D A1-Node_ID * Tunnel Sender Address =3D A1-Node_ID RFC3209 states: Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier. Which I interpret to mean that the Extended Tunnel_ID and the Tunnel = Sender Address may not be identical (as RFC3209 does not mandate that = Extended Tunnel ID be the same as the Tunnel Sender Address), in which = case which should be used for the Node_ID? [I note that section 5.3 is not normative text but I think it is a = useful example to aid interoperability and therefore being clear on the = mappings is worthwhile] 5) Section 7.1.1 - The format of MPLS-TP Section MEG ID chosen means = that there can only ever be a single MEG per pair of Interfaces on a = section. Is that an architectural constraint that is acceptable or are = there possible use cases where multiple MEGs may need to exist between a = pair of interfaces on a section? E.g. could there be a use case which = requires a MEG to do CV/CC and a separate MEG to do performance = management (or would that be implemented as two MEPs in the same MEG?) 6) In a number of places the document describes two types of identifier = format, one for local scope within an ASN and one for global scope (by = prefixing the local identifier with the Global_ID for the ASN it is = within). What is the reason for the two types having different lengths, rather = than using Global_ID of 0 to signify an identifier with local scope - is = it to save the 4 octets of Global_ID or is there another reason for = having a different length ID for local Vs global scopes? Nits: 1) The Abstract & Introduction both state: This document defines identifiers for MPLS-TP management and OAM functions suitable to IP/MPLS conventions. I'm not really sure what being "suitable to" means, maybe you really = meant "compatible with"? 2) Section 3 also states: ASN 0 is reserved and cannot be assigned. A Global_ID of zero means that no Global_ID is specified. However ASN 0 is assigned to mean that no Global_ID is used, therefore, = consider rewording to something like: ASN 0 is reserved and cannot be assigned to an operator. An = identifier=20 containing a Global_ID of zero means that no Global_ID is specified. 3) Section 5 in the middle of the first paragraph. To keep consistent = with the style of the earlier paragraphs (which I like): s/The Tunnel_ID/The Tunnel Identifier (Tunnel_ID)/ 4) Similarly, Section 5.1 s/Specifically a Tunnel_Num/Specifically a = Tunnel Number (Tunnel_Num)/ 5) Section 5.1 in the 2nd example s/Global_Id/Global_ID/ 6) Section 5.2.1 s/Specifically an LSP_Num/Specifically an LSP Number = (LSP_Num)/=20 7) Section 6 s/SAAI/SAII/ (occurs twice in that section) 8) Section 7.2.2 states Thus a MEP_ID used in end-to-end for a Pseudowire T-PE takes the form AGI::Global_ID::Node_ID::AC_ID I don't know what is meant by "used in end-to-end" Ben From stig@venaas.com Wed Jul 13 15:10:37 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2763321F8B66 for ; Wed, 13 Jul 2011 15:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LUSdFj6kOzM for ; Wed, 13 Jul 2011 15:10:36 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 50A4921F8B50 for ; Wed, 13 Jul 2011 15:10:36 -0700 (PDT) Received: from [128.107.114.65] (dhcp-128-107-114-65.cisco.com [128.107.114.65]) by ufisa.uninett.no (Postfix) with ESMTPSA id 4A67F7FF6; Thu, 14 Jul 2011 00:10:31 +0200 (CEST) Message-ID: <4E1E17D0.10602@venaas.com> Date: Wed, 13 Jul 2011 15:10:24 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org, draft-ietf-mpls-mldp-recurs-fec@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, mpls-chairs@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-mldp-recurs-fec-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 22:10:37 -0000 Hi, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-mldp-recurs-fec-03 Reviewer: Stig Venaas Review Date: July 13, 2011 IETF LC End Date: July 11, 2011 Intended Status: Proposed Standard The document is well written, and I only have two very minor issues. Minor issues/questions: 1. Do the address families in the outer and inner FEC elements need to be the same? It should be pointed out, at least if that is a requirement. 2. Regarding security considerations. It seems that someone can use a series of recursive FECs to basically do source routing? Is this be a concern? 3. In the IANA considerations, why types 6 and 7 here? There aren't that many defined already, are there? Editorial: 4. In section 3.2.1 paragraph 5 or so, it says "though the use of the MVPN". This should be "through". 5. The term "unsegmented" is used, while in the MPVN reference, draft-ietf-l3vpn-2547bis-mcast-10, non-segmented is used. These should match. 6. In the security considerations it says "cause he multipoint LSPs". That is all, Stig From erosen@cisco.com Thu Jul 14 10:42:07 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836DE21F8CA6 for ; Thu, 14 Jul 2011 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9bBi5-yulOW for ; Thu, 14 Jul 2011 10:42:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED82621F8C99 for ; Thu, 14 Jul 2011 10:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=846; q=dns/txt; s=iport; t=1310665327; x=1311874927; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=+GMvhrzqNae6Bxv5IEgjNWTKlwk4mH1f6/bMzFV3/dY=; b=lWTCokrmWkCLrVBcgdPwr1LR9XXFuQc6j5Q9ZBZZLOrbNOjVNS0X1P7i n2dP97wcQsYm7CIK2GuR1VKhE25EYD/2YTcebY8mV44dbGgQDgJ1rk0aS awTC0gJCcIKuguXGM0hPefJvmk09MEE/t/7gWOQ/JKx2hzrJQJG77Mx0h o=; X-IronPort-AV: E=Sophos;i="4.65,530,1304294400"; d="scan'208";a="3011441" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jul 2011 17:42:06 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6EHg6Ur007347; Thu, 14 Jul 2011 17:42:06 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p6EHg4M3013208; Thu, 14 Jul 2011 13:42:05 -0400 To: Stig Venaas In-reply-to: Your message of Wed, 13 Jul 2011 15:10:24 -0700. <4E1E17D0.10602@venaas.com> Date: Thu, 14 Jul 2011 13:42:04 -0400 Message-ID: <13207.1310665324@erosen-linux> From: Eric Rosen X-Mailman-Approved-At: Thu, 14 Jul 2011 11:11:08 -0700 Cc: rtg-dir@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-mldp-recurs-fec@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-mldp-recurs-fec-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:42:07 -0000 Stig, Thanks for your review. > Do the address families in the outer and inner FEC elements need to be the > same? There is no requirement for the address families to be the same. Since no such requirement is stated, I think we're okay. > In the IANA considerations, why types 6 and 7 here? There aren't that many > defined already, are there? All smaller values are requested by other internet-drafts, and some are even deployed. > Regarding security considerations. It seems that someone can use a > series of recursive FECs to basically do source routing? Is this be a > concern? I don't see any security issues here, beyond what is already mentioned in the security considerations section. Do you think there's an issue that needs further discussion? I've incorporated your editorial comments. Eric From pthubert@cisco.com Tue Jul 5 06:03:28 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5421F8726 for ; Tue, 5 Jul 2011 06:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.099 X-Spam-Level: X-Spam-Status: No, score=-12.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTUdgj-KuoRk for ; Tue, 5 Jul 2011 06:03:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5A821F8720 for ; Tue, 5 Jul 2011 06:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3494; q=dns/txt; s=iport; t=1309871007; x=1311080607; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0raMaE1kXHoyTHK99zIYtdk8hez1cjb4UhPCi1jZea0=; b=CkXtisluHziXD9qNCl0O1XI6sQhASOAkvxPyUx8cZNc0o2eODl4W9P+w hTN5h/Ka+tZjXVn38A1PU1Wq9Z+4SIMfOjrYrRULE6wfpB7QD7MR467ze vEkO/IeoRsNSa5q8+iz+j0itJLKQDignYW+nhZGP9V/30GzE4fenXWA7u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPEKE06Q/khR/2dsb2JhbABFBQmnf3eIeqRlnXCDIQuDCgSXN4s3Og X-IronPort-AV: E=Sophos;i="4.65,479,1304294400"; d="scan'208";a="40663971" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 05 Jul 2011 13:03:12 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p65D3Ctw027695; Tue, 5 Jul 2011 13:03:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 15:03:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 15:03:06 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04FAF26F@XMB-AMS-107.cisco.com> In-Reply-To: <4E0FB27E.6010907@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir Review: draft-ietf-roll-of0 Thread-Index: Acw5FRb1Xsp9FhJyQJ21KtNQU2kHwwB+4G2w References: <4E0FB27E.6010907@orange-ftgroup.com> From: "Pascal Thubert (pthubert)" To: "Julien Meuric" , X-OriginalArrivalTime: 05 Jul 2011 13:03:12.0309 (UTC) FILETIME=[E539CE50:01CC3B13] X-Mailman-Approved-At: Thu, 14 Jul 2011 11:11:43 -0700 Cc: rtg-dir@ietf.org, draft-ietf-roll-of0.all@tools.ietf.org, roll-chairs@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-roll-of0 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:03:28 -0000 Thanks a lot Julien for this very serious review.=20 Please see in line >=20 > *Summary:* > This document is basically ready for publication, but has nits that > should be considered prior to publication. >=20 > *Comments:* > This document is clearly well written and clearly focused, though > relying on many concepts defined within RPL. This is the first ROLL > document I have reviewed, so it may mean that my review is not > sufficiently in-depth. > I noted that many terms are capitalized: it seems unusual at the > beginning but appears to be helpful so as to identify RPL-related concepts. >=20 > *Major Issues:* > No major issues found. >=20 > *Minor Issues:* > Just a few minor issues, which I could almost have put among the nits. > - In section 6.2, stretch_of_rank is defined as "the maximum > augmentation" while, as far as I understand the formula at the end of > section 4.1, it is rather "the minimum augmentation". [Pascal] If the parent set is large enough without stretching, there is no point doing it. 4.1 says: " Still, an implementation MAY stretch the step_of_rank with at most a configurable stretch_of_rank (Section 6.2) of any value between 0 (no stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3). " I do mean it is a maximum and that is consistent with 61. I think the confusion comes from the definition of Sr in the formula " The step_of_rank Sp that is computed for that link is multiplied by the rank_factor Rf and then possibly stretched by a stretch_of_rank Sr. " What about saying: " The step_of_rank Sp that is computed for that link is multiplied by the rank_factor Rf and then stretched by a term Sr that is between 0 and stretch_of_rank. " > - Section 4.1 says "Stretching the step_of_rank is NOT RECOMMENDED" > while "an implementation MAY stretch the step_of_rank": using both > keywords does not seem consistent. Since stretch_of_rank is part of the > document, it looks like "MAY" is correct. The capital letters of "NOT > RECOMMENDED" should be removed, or the phrase may be replaced (e.g. > "ought to be avoided"). [Pascal] Adrian suggested "NOT RECOMMENDED" in upper case and I agree with his point. I'm unclear why this is in opposition with the "MAY". If it is I'r rather lowercase the 'MAY' than the "NOT RECOMMENDED". > - Section 4.2.1, 3rd bullet: what about multiple interfaces without > policy? Section 4.2.2, 1st bullet: is there a reason why policy is no > longer mentioned there? If the order of the rules may vary, why not [Pascal] It is there implicitly. The policy text explained what we mean by higher order. The same order plays in both sections. > writing, in the document, the list in the same order for the Preferred > Parent and the Backup Feasible Successor? (1 -> 4; 2 -> 6; 3 -> 1...) > Why different wording between sections? [Pascal] I agree with you, 1 of 4.2.2 should really move after the current 6. You'll note that the selection of the preferred parent cause the selection of the DODAG version, and once this is done, some options for the alternate are not available anymore, and that the backup does not have to be a parent (it can belong to a subsequent version). >=20 > *Nits:* (some may be deferred to the RFC Editor) [Pascal] I'll fix those I can in the post. Some to be discusses with RC editor unless someone knowledgeable enlightens me first. Cheers, Pascal From yaacov.weingarten@nsn.com Tue Jul 5 02:14:16 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8389821F8788 for ; Tue, 5 Jul 2011 02:14:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlKri7rPg0Vk for ; Tue, 5 Jul 2011 02:14:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D0ABD21F86AD for ; Tue, 5 Jul 2011 02:14:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p659E8t3017335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2011 11:14:08 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p659E5oi020595; Tue, 5 Jul 2011 11:14:06 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jul 2011 11:14:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 11:14:01 +0200 Message-ID: In-Reply-To: <4E108F0B.5060305@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Thread-Index: Acw5mIyXYebMZO6WQ8WKEvsxKCWMnABTa8aA References: <4E108F0B.5060305@labn.net> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Lou Berger" , X-OriginalArrivalTime: 05 Jul 2011 09:14:05.0877 (UTC) FILETIME=[E3B6BE50:01CC3AF3] X-Mailman-Approved-At: Thu, 14 Jul 2011 11:11:54 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 09:14:16 -0000 Lou, hi First off - I would like to thank you for your very thorough and complete review of the document and the protocol. At this point, I would like to address some of the "Minor issues" that you pointed out. I think that the Top-level issues that you raise may need a little more time and consideration on the part of the entire group of authors and will be addressed in a separate message. You wrote (first part of message snipped): Minor issues - use of RFC2119 language The following are cases where it looks like RFC2119 language was improperly used or omitted. There are also cases where SHOULD is used, but handling of other cases is not specified: - Section 3, lines 280-282 say that the "logical decomposition" depicted in Figure 1 and described in the remainder of the section is for "for descriptive purposes" and external behavior is defined in Section 4. To me this means that all of section 3 is informative in nature and *not* normative. Is this correct? [yw>] In general Section 3 is meant to be informative in all issues relating to the logical blocks in the decomposition and the actions that they may take in processing the protocol. However, there are additional topics that are mentioned in this section, e.g. use of control-plane recovery, triggers for protection, use of timers, that (IMHO) may include some normative statements. Therefore, I will try to relate to each of your comments below based on this division of the text. If it is correct, i.e., the section is informative, then RFC2119 language needs to be removed from the section. Iff it is incorrect, i.e., the section is normative, than the following are problematic: - Line 330, needs to use rfc2119 language to parallel line 332 [yw>] Will correct the sentence to read - "The commands Forced Switch, Manual Switch, Clear, and Lockout of Protection (..) MUST be supported." - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are there cases where it is reasonable for the "SHOULDs" to not be followed? In other words aren't these "MUSTs"? I not, probably should have a bit of text exploring these cases. [yw>] 358 - will be changed to be informative, 364 - will change to SHALL, 415 & 418 - will change to informative, 423 - ??, 512, 515, 518 - will change to informative, 574, 576, & 585 - will change to informative - Lines 427, 435: this usage of "SHALL" really seems informative in nature, propose: s/SHALL include/includes [yw>] OK - Line 370: s/shall/SHALL [yw>] Think it is informative (based on the general assessment of Section 3) - Line 479: s/should/MUST [yw>] Same as above (370) - Line 490: if informative (which I think it is): s/should/are if normative: s/should/MUST [yw>] will change to "are" - Line 503: s/shall/SHALL [yw>] OK - Line 521: s/shall/SHALL [yw>] Same as above (370) - Line 579: s/should/MUST [yw>] Same as above (370) Again, these changes presume that this section is normative, if informative, then usage of 2119 language needs to be removed from the section. [yw>] Will remove the 2119 language from - 351, 358, 367, 427, 435, 463, 475, 478, 562 - Line 612, 617: these are informative/narrative sentences s/MUST/must|will s/SHALL/are [yw>] OK - Lines 629, 638: aren't these MUSTs? If not needs some explanatory text. [yw>] OK - Line 643 missing "default": s/an/a default [yw>] OK - Section 4.3.3: There are a lot of "SHOULDs" in this section. Given this text relates to the synchronization of state between peers, what happens when one peer implements the "SHOULD" and the other peer does not? In order to avoid implementations that are compliant with this document but can't interoperate, either this case needs to be covered or these "SHOULDs" need to be "MUSTs". [yw>] Will change to SHALL/MUST - Lines 205-206: The meaning of "maintain traffic" is not clear. [yw>] Will correct to read "...when there is a need to verify that the traffic continues to be transported on a bi-directional LSP that is co-routed." - Lines 215-217: suggest making it explicit (rather than implied) that 1:1 unidirectional and 1:n are "out of scope of this document" [yw>] Will add the following text to the end of the statement - "and are out of scope for this document" - Lines 225-219: so is support for 1+1 for P2MP in or out of scope? This section really should be explicit on this point. [yw>] Will add a statement that this is out-of-scope and may be described in a separate applicability document. - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your draft excludes [RFC4873], is this intentional? If so, why? [yw>] Not intentional - will add the reference - Lines 400-403, 444-446. The definitions for local MS and remote MS are subtly different. 400-403 says "switched from the working path to the protection path". While 444-446 says "switch the traffic to the path that was not being used previously". While I personally prefer this definition, Section 4.3.3 seems to say that 444-446 should read "switch the traffic from the working path to the protection path". [yw>] Will correct lines 444-446 to align with 400-403 - Line 665. No definition is given for the "Reserved" field. A typical definition for such fields is "The Reserved field MUST be set to zero on transmission and MUST be ignored on receipt." [yw>] Will change the Reserved fields to Reserved1 & Reserved2 and add the description appropriately. - Lines 678-681. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? [yw>] Will consult regarding this! - Numbering consistency The document is inconsistent with how it indicates field values. Unless there's a sub-structure to a field, e.g., a flags field, values should be listed in decimal not in binary. Impacts lines 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines really refer to bit fields, then the bits need to be defined. [yw>] Will use the decimal values - Line 732. Is DNR limited to transmission behavior only? If not, need to change this line. [yw>] Will change "...is requesting that the protection domain continues to transmit data over the protection path," to read "...is requesting that the protection domain continues to transport the data as if it is in a protecting state," - Lines 742-760. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? If there really is a need for future extensions (per line 755) then a wider field is really needed. [yw>] Will consult regarding this! - Lines 774-784: How is the absence of faults indicated? Perhaps 0 or 255 should be used for this case? [yw>] The current understanding was that this field is ignored when the Request field is not indicating a fault condition see lines 725 & 733 - Lines 820: strictly speaking this field is not part of "TLV information", also receive behavior is not specified (see comment on line 665 above.) [yw>] See reply to line 665 above - Lines 822-824, The TLV format definition is missing. (I.e. how big are the T & L fields, does L include T&L or not, are there any padding requirements...) [yw>] Will consult regarding this. - Lines 853, 856, 866: text is informative, should not include RFC2119 language. [yw>] OK - Handling of PA:F:L/FS after SFC-P If for some reason the prioritization of FS and SF-P remain as is (see major issue above), the current state machine definitions result in a the FS state being lost when an SF-P is cleared. Consider the case of the following states and inputs (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> WTR--(WTRExp)--> WTR--(remNR)-->N As the operator set FS, shouldn't the state return to PA:F:L not N? [yw>] What you are suggesting, IMHO, is an optimization. If the FS is still being asserted, then immediately after going into Normal the FS would be recognized and cause the domain to reenter PA:F:L. We (i.e. the authors) made a conscious decision to not describe this optimization after a rather lengthy discussion when it was brought to our attention and this was explained to the different commenters at the time. - SF-P can mask SF-W Consider the scenario where the protection path fails and then the working path fails. As I read Section 4.3.3 and appendix a, the order of states and inputs (in parentheses) are as follows: N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) This seems wrong. When the protection path SFc is received shouldn't the result be a protection switch / PF:W:L (NR(1,0)? [yw>] Similar to the previous consideration. - Remote SF impacts protection switching when using unidirectional protection As I read section 4.3, a remote SF will impact the behavior of the protection bridge of an LER even when 1+1 unidirectional protection is being used. My understanding is that the bridges are supposed to switch autonomously in this mode. Did I miss something? - IANA Considerations, section 5 Don't you want an IANA registry for the TLV types that may be defined in the future per section 4.2.7? Nits: Line 146: s/bandwidth/resources [yw>] OK Line 147: s/is/are [yw>] OK Line 393: Add (SFc) [yw>] OK Line 417: Expand MEP [yw>] Changed to LER, this is the only appearance of MEP in the document and therefore the expansion seems extraneous. Lines 519-526: These lines duplicate what's immediately following in 3.6.1, suggest dropping them. [yw>] OK Line 559: s/is recovering/has recovered [yw>] OK Line 592: the terminology SF(1,0) hasn't been defined at this point in the document, need a forward reference. [yw>] Changed the text to read "PSC messages that indicate a SF condition on the working path and that the protection path is not being used to transport protected traffic (as described in the next section)." Line 730: s/is recovering/has recovered [yw>] OK Line 853: s/The value/Except during a protection switch, the value [yw>] OK From yaacov.weingarten@nsn.com Tue Jul 5 04:40:36 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AD421F8703 for ; Tue, 5 Jul 2011 04:40:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0Slj4ruOGG9 for ; Tue, 5 Jul 2011 04:40:35 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3A21F86B9 for ; Tue, 5 Jul 2011 04:40:34 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p65BeWCU025163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2011 13:40:33 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p65BeVcS006405; Tue, 5 Jul 2011 13:40:32 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jul 2011 13:40:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 13:40:18 +0200 Message-ID: In-Reply-To: <4E12F689.1060904@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Thread-Index: Acw7B19GcoU3bxnkTx215HrHZZJHRQAAFqAw References: <4E108F0B.5060305@labn.net> <4E12F689.1060904@labn.net> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Lou Berger" X-OriginalArrivalTime: 05 Jul 2011 11:40:25.0331 (UTC) FILETIME=[54AD1C30:01CC3B08] X-Mailman-Approved-At: Thu, 14 Jul 2011 11:11:54 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 11:40:36 -0000 Lou, hi Just a note regarding the "423 ??" - It was just noting that I could not find any Normative text on line 423. Could be that you meant 427, that I listed separately that I will remove the normative SHALL! I did not miss those last two notes - but I need to consult with others (possibly the WG chairs) on these. BR, yaacov -----Original Message----- From: ext Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, July 05, 2011 2:33 PM To: Weingarten, Yaacov (NSN - IL/Hod HaSharon) Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: Re: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Yaacov, Thank you for the quick response to the majority of the topics I raised. I only have a response to a few of your responses. See below. (I've cut out closed points.) On 7/5/2011 5:14 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: > Lou, hi >=20 > First off - I would like to thank you for your very thorough and > complete review of the document and the protocol. critiques are always easier than authoring... > ... >=20 > - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585. Are > there cases where it is reasonable for the "SHOULDs" to not > be followed? In other words aren't these "MUSTs"? I not, > probably should have a bit of text exploring these cases. > [yw>] 358 - will be changed to be informative, 364 - will change to > SHALL, 415 & 418 - will change to informative, 423 - ??, 512, 515, 518 - > will change to informative, 574, 576, & 585 - will change to informative not sure what the '??' means here, are you asking a question? > ... >=20 > - Lines 225-219: so is support for 1+1 for P2MP in or out of > scope? This section really should be explicit on this point. > [yw>] Will add a statement that this is out-of-scope and may be > described in a separate applicability document. okay, but note that this means [RFC5654] 65.C. is not covered by the document. > ... >=20 > - Lines 678-681. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? > [yw>] Will consult regarding this! > ... >=20 > - Lines 742-760. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? If there really is a need for future > extensions (per line 755) then a wider field is really needed. > [yw>] Will consult regarding this! >=20 > - Lines 774-784: How is the absence of faults indicated? Perhaps 0 > or 255 should be used for this case? > [yw>] The current understanding was that this field is ignored when the > Request field is not indicating a fault condition see lines 725 & 733 I did see those, I was suggesting to use an explicit rather than implicit value for such cases. If you leave the values as is, then section 4.2.5 really should say that such cases exists. Perhaps, add something along the lines of "When a fault condition is indicated in the PSC Request field," to the start of line 776. > ... >=20 > - Lines 822-824, The TLV format definition is missing. (I.e. how > big are the T & L fields, does L include T&L or not, are there > any padding requirements...) > [yw>] Will consult regarding this. > ... >=20 > - Handling of PA:F:L/FS after SFC-P >=20 > If for some reason the prioritization of FS and SF-P remain as > is (see major issue above), the current state machine > definitions result in a the FS state being lost when an SF-P is > cleared. Consider the case of the following states and inputs > (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> > WTR--(WTRExp)--> WTR--(remNR)-->N >=20 > As the operator set FS, shouldn't the state return to PA:F:L not > N? > [yw>] What you are suggesting, IMHO, is an optimization. If the FS is > still being asserted, then immediately after going into Normal the FS > would be recognized and cause the domain to reenter PA:F:L. We (i.e. > the authors) made a conscious decision to not describe this optimization > after a rather lengthy discussion when it was brought to our attention > and this was explained to the different commenters at the time. >=20 > - SF-P can mask SF-W >=20 > Consider the scenario where the protection path fails and then > the working path fails. As I read Section 4.3.3 and appendix a, > the order of states and inputs (in parentheses) are as follows: > N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) >=20 > This seems wrong. When the protection path SFc is received > shouldn't the result be a protection switch / PF:W:L (NR(1,0)? > [yw>] Similar to the previous consideration. >=20 Okay, I understand the approach the authors are taking. Although to ensure proper implementation and interoperability, this approach needs to be made explicit in the document, probably somewhere in section 4.3. Furthermore, Section 3 needs to address this in the description of generation and handling of "local requests". > - Remote SF impacts protection switching when using unidirectional > protection >=20 > As I read section 4.3, a remote SF will impact the behavior of > the protection bridge of an LER even when 1+1 unidirectional > protection is being used. My understanding is that the bridges > are supposed to switch autonomously in this mode. Did I miss > something? >=20 > - IANA Considerations, section 5 > Don't you want an IANA registry for the TLV types that may be > defined in the future per section 4.2.7? >=20 You may have missed the prior 2 comments. > ... Thanks again for the quick response. Lou From hejia@huawei.com Mon Jul 18 06:48:58 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A821F8B17 for ; Mon, 18 Jul 2011 06:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=4.364, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIMw8KcjmNhu for ; Mon, 18 Jul 2011 06:48:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E56B321F8B35 for ; Mon, 18 Jul 2011 06:48:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOJ009VX7PF9C@szxga03-in.huawei.com> for rtg-dir@ietf.org; Mon, 18 Jul 2011 21:48:52 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOJ00GUT7PFM7@szxga03-in.huawei.com> for rtg-dir@ietf.org; Mon, 18 Jul 2011 21:48:51 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACI38564; Mon, 18 Jul 2011 21:48:50 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Jul 2011 21:48:49 +0800 Received: from hejia (10.70.77.159) by smtpscn.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Jul 2011 21:48:50 +0800 Date: Mon, 18 Jul 2011 21:48:50 +0800 From: Hejia In-reply-to: <068.1bef47dd6a8b02a4731afa7a3b8d9f3b@tools.ietf.org> X-Originating-IP: [10.70.77.159] To: rtg-ads@tools.ietf.org Message-id: <037f01cc4551$6ca10060$45e30120$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acw9Me+iupmNY3YxRxux3joqwpPDWwIHDP1A X-CFilter-Loop: Reflected References: <059.8b5c96ff07fc4f81e3a93fb268f5b00d@tools.ietf.org> <068.1bef47dd6a8b02a4731afa7a3b8d9f3b@tools.ietf.org> Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-cc-cv-rdi.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-cc-cv-rdi-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:48:58 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-cc-cv-rdi-05 Reviewer: Jia He Review Date: July 17, 2011 IETF LC End Date: Intended Status: Standards Track Summary: I have some concerns about this document that I think should be resolved before publication. Major Issues: A detailed description of how CC and CV functions are interleaved is missing. For example, if a MEP detects mis-connectivity defect via CV packets, will it drive the BFD state change? How to? - How does CV function contribute to the BFD state machine? How to deal with the impact on the state machine which might be caused by the possible different defect detection time applied to CV and CC functions? Section 3.7.5 only describes CC state machine. IMHO, a CC and CV interleaved BFD state machine should be defined instead. - How will it communicate the state change with the peer MEP? Section 3.6 sets the following rule "All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored. " Does it mean the BFD state change caused by mis-connectivity (detected by CV packet) should be communicated via CC packet in the backward direction to the peer MEP instead of CV packet itself? But the diagnostic code is read from CC and CV packets respectively? Minor Issues Some of the following "Minor Issues" are more questions/clarifications for my understanding and suggestion rather than "pure" issues. 1) Abstract, in the middle of the second paragraph, states "Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. " "Integrity of routing" is used ambiguously here. To my understanding, CV verifies that the source and sink of an LSP is correctly connected but does not contribute to the check of routing. IMHO, "routing" involves more than the connectivity between source and sink of an LSP. What about the following change? "Connectivity verification monitors the integrity of the connectivity of the label switched path between sink and source for any mis-connectivity issues. " 2) Abstract, at the end, states "This document specifies methods ... using Bidirectional Forwarding Detection. " However, the extensions of BFD is also specified in this document. To be accurate, how about appending the sentence with "and its extensions" at the end? 3) Section 3.2(CC,CV, and RDI overview), at the end, only describes the RDI function communicated via BFD CC message (diagnostic code "1" or "5"). Although the indication of mis-connectivity defect is described at the end of Section 3.7.3 (Defect entry consequent action) requiring a new diagnostic code to be assigned by IANA, to keep integrality, it is better to add the similar description in Section 3.2. 4) Section 3.4 and Section 3.5 use "MPLS BFD CC (or proactive CV) Message format" as the title, which might cause confusion since the whole document is talking about MPLS-TP CC/CV/RDI functions. To eliminate ambiguity, what about using "MPLS-TP CC Message format" and "MPLS-TP proactive CV Message format" instead? 5) The titles of Figure 2 and Figure 3 use "MPLS CC Message" and "MPLS CV Message" respectively. To be aligned with the other part of this document, it is proposed to change MPLS to MPLS-TP in the titles. 6) Section 3.7 states "For LSPs, SPMEs and sections this is GAL/G-ACh encapsulated BFD using the code points specified in section 3.1. For PWs, this is G-ACh encapsulated BFD using the code points specified in section 3.1. " Since the usage of GAL in PW is currently under discussion (draft-ietf-pwe3-mpls-tp-gal-in-pw-01, draft-nadeau-pwe3-vccv-2-02) , is it possible to leave this issue open? 7) Section 3.7.2 Defect entry criteria What is the relationship among these defect entry criteria? Does it reflect the order of priority? If yes, it is better to express this in the document explicitly. Besides, in the middle of this section, it states 4. Receipt of a session discriminator that is in the local database but does not have the expected label (mis-connectivity defect). What does the "expected label" indicate? The encapsulation of a LSP or a PW, etc.? Shouldn't it be checked at the first beginning? 8) Sections 3.5.1 ~ 3.5.3, Section/LSP/PW source MEP-ID Does it cover SPME? Any difference? 9) Is MEG ID used in this document? Section 4 lists "The MEG/MEP ID for the MEPs at either end of the LSP" as one of these configuration considerations. Nits: 1) continuity check/Continuity Check, connectivity verification/Connectivity Verification, remote defect indication/Remote Defect Indication The above are differently written (sometimes initials in capitals, sometimes not) throughout the document. Please check through the whole document and make alignment. 2) Section 1, typo Both pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [12][12]..., [12] duplicates As described in [13][13]..., [13] duplicates 3) Section 2, to keep alignment with the terminology definition of GAL in RFC5586 s/GAL Generalized Alert Label/GAL G-ACh Label/ 4) Section 3.3, Figure 1 According to the description of Figure 1, it illustrates the G-ACh encoding for BFD CC-CV-RDI functionality rather than Connectivity Verification only. To keep aligned, it is proposed to change the title of Figure 1 to "ACH Indication of MPLS-TP Continuity Check, Connectivity Verification and Remote Defect Indication" 5) Section 3.5.3, s/MPLS_TP/MPLS-TP/ 6) Section 3.7.5, s/LKI/LKR/ That's all. B.R. Jia From adrian@olddog.co.uk Mon Jul 18 11:54:54 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FAA21F8591; Mon, 18 Jul 2011 11:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIBNxBu32Xex; Mon, 18 Jul 2011 11:54:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9921F8585; Mon, 18 Jul 2011 11:54:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6IIspa5027107; Mon, 18 Jul 2011 19:54:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6IIsooT027094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2011 19:54:51 +0100 From: "Adrian Farrel" To: , , Date: Mon, 18 Jul 2011 19:54:51 +0100 Message-ID: <00bd01cc457c$2d038b50$870aa1f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxFfBOOv9vhGj6YQZmKegN61+gidw== Content-Language: en-gb Subject: [RTG-DIR] Routing AD Office hours X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:54:54 -0000 Sunday 24th 2pm to 4pm Room 304 B Adrian and Stewart From swallow@cisco.com Wed Jul 20 12:06:53 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B021F8451 for ; Wed, 20 Jul 2011 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p18G8BbhXqV for ; Wed, 20 Jul 2011 12:06:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86221F8419 for ; Wed, 20 Jul 2011 12:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=9670; q=dns/txt; s=iport; t=1311188810; x=1312398410; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=FeAcL0vhrabX3lcu0iDxlPploNh2w4kiPvkhI5UFYzk=; b=e7xOZZ8ZX0TjZv6sbTDicSwxbmyBSzXfj1rb+4cYi9nvFXc5CKJvc6+s SV8CSamLeVD22Vy2PUR06F+xou5TDdPIXaXVmql2M9rBUqPFleqelHTWJ BQ4kExTTWsvaA7HwVJtyCJNgl/uAnK1ObrYWtRobF5VsL3U82Adcu7uA0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHUmJ06tJXG+/2dsb2JhbABTp2d3iHyhEZ4rhj0Ekm6FEItp X-IronPort-AV: E=Sophos;i="4.67,236,1309737600"; d="scan'208";a="4843567" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 20 Jul 2011 19:06:49 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6KJ6mm2014200; Wed, 20 Jul 2011 19:06:49 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 14:06:49 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Jul 2011 19:06:49 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 20 Jul 2011 15:06:47 -0400 From: George Swallow To: Ben Niven-Jenkins , Message-ID: Thread-Topic: RtgDir review: draft-ietf-mpls-tp-identifiers-06.txt Thread-Index: AcxHECv9qzq08MUGXUqkiCUxjgeQPg== In-Reply-To: <9596E295-64F9-48B4-B5DC-CB8894ADBFD2@niven-jenkins.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jul 2011 19:06:49.0799 (UTC) FILETIME=[2DA8D570:01CC4710] Cc: draft-ietf-mpls-tp-identifiers.all@tools.ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-identifiers-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:06:53 -0000 Ben - See inline: On 7/12/11 5:23 PM, "Ben Niven-Jenkins" wrote: > > Document: draft-ietf-mpls-tp-identifiers-06.txt > Reviewer: Ben Niven-Jenkins > Review Date: 12 July 2011 > IETF LC End Date: 11 July 2011 > Intended Status: Standards Track > > Summary: > I have some minor concerns about this document that I think should be resolved > before publication. > > Comments: > In general the document is well written, however it defines the format for a > number of different identifiers some of which are related to others in various > ways and it is difficult from reading the document to easily get an idea of > the "big picture" of how the relationship between the different identifiers > which are defined. I would like to avoid becoming another framework document, so I am a bit reticent to do that. I also don't want to overly constrain implementations. See below. > For example section 5.1 defines the format for a Tunnel_ID and then goes on to > state "When an MPLS-TP Tunnel is configured, it MUST be assigned a unique > IF_ID at each endpoint. As usual, the IF_ID is composed of the local Node_ID > concatenated with a 32-bit IF_Num." However, the definition of Tunnel_ID does > not contain an IF_ID so it is not obvious to me from reading the draft what > the relationship is between the Tunnel_ID for a tunnel and the IF_ID for the > same tunnel and the circumstances when Tunnel_ID is the appropriate identifier > versus when IF_ID is the appropriate identifer. I will remove this text. It is one example where I have an implementation in mind, but now that you've caused me to think about it, there are other possibilities here. > Section 7.3 contains a simple diagram and uses it to show how the identifiers > are formed for a Pseudowire Segment Endpoint ID and it may be useful to have a > similar but expanded diagram at the beginning of the document to show the > different types of identifier that are defined, their scope within a network > and how they relate to one another. > > Please also note that I reviewed this document without reading all the MPLS-TP > related OAM documents and so some of my questions may have been answered if I > had done so (e.g. minor issue 5 below). > > Minor Issues: > Some of the following "Minor Issues" are more questions for my understanding > and suggestions rather than "pure" issues as such but they are more > substantial than nits so I included them here. > > 1) Section 4 states that "The Node_ID is a unique 32-bit value" and that "The > IF_Num is a 32-bit unsigned integer" > > Additionally both Tunnel_Num and LSP_Num are declared to be unsigned integers > but no other fields (except IF_Num mentioned above) are. > > Is that meant to signify that Node_IDs (for example) are signed values or is > it because they are fields with a structured value (e.g. an IPv4 address?) or > some other reason such as it is expected to impact how they are represented on > the wire? Would it satisfy you if I just say that they are all unsigned integers? > 2) The document makes several references to using an "A1/Z9 convention", while > it can be inferred that A1 and Z9 refer to either end of a connection, is > there a definitive reference for this convention as it is not one I am > familiar with and a search using a well known search engine just returned > results that linked this draft? Apparently there is an A/Z convention used by the ITU. I used A1 Z9 because then most (now all, since the ICC got moved out) of the fields are numbers (make that unsigned integers ;-). > 3) Section 5.2.1 states: > Thus the format of an MPLS-TP co-routed bidirectional LSP_ID > is: > > A1-{Node_ID::Tunnel_Num}::Z9- > {Node_ID::Tunnel_Num}::LSP_Num > > Note that the uniqueness of identifiers does not depend on > the A1/Z9 sort ordering. Thus the identifier > > Z9-{Node_ID::Tunnel_Num}::A1- > {Node_ID::Tunnel_Num}::LSP_Num > > is synonymous with the one above. > > I can see how the A1/Z9 sort ordering can generate different values for LSP_ID > and that as they are both referring to the same LSP they are synonymous with > one another. Is there any requirement for an application to be able to > translate from one possible LSP_ID to another synonymous LSP_ID for the same > LSP? Should there be an explicit mention that applications MUST treat both > forms as identical? In general I do not see a need to translate, but in a few case there will be. But not all implementations of MPLS-TP may have those cases. For example, the on demand cv draft uses a source/destination format for the LSP-ID. This is done from the sender-of-the-ping's point of view. It was done this way to ensure that when you get to a node you are tracing in the correct direction. But MPLS-TP in a *pure* transport environment will most likely not use on demand cv. I can also see it being useful to be able to list out the tunnels and lsps sourced a particular node in order of their destinations with those appearing first in the order. But again something that is not necessary. > 4) Section 5.3 states > * Extended Tunnel_ID = A1-Node_ID > * Tunnel Sender Address = A1-Node_ID > > RFC3209 states: > Extended Tunnel ID > > A 32-bit identifier used in the SESSION that remains constant > over the life of the tunnel. Normally set to all zeros. > Ingress nodes that wish to narrow the scope of a SESSION to the > ingress-egress pair may place their IPv4 address here as a > globally unique identifier. > > Which I interpret to mean that the Extended Tunnel_ID and the Tunnel Sender > Address may not be identical (as RFC3209 does not mandate that Extended Tunnel > ID be the same as the Tunnel Sender Address), in which case which should be > used for the Node_ID? > > [I note that section 5.3 is not normative text but I think it is a useful > example to aid interoperability and therefore being clear on the mappings is > worthwhile] I'll add some text: "RFC 3209 allows some flexibility in how the Extended Tunnel ID is chosen and a direct mapping is not mandated. One convention that is often used, however, is to populate this field with the same value as the Tunnel Sender Address. The examples below follow that convention. Note that these are only examples." > 5) Section 7.1.1 - The format of MPLS-TP Section MEG ID chosen means that > there can only ever be a single MEG per pair of Interfaces on a section. Is > that an architectural constraint that is acceptable or are there possible use > cases where multiple MEGs may need to exist between a pair of interfaces on a > section? E.g. could there be a use case which requires a MEG to do CV/CC and a > separate MEG to do performance management (or would that be implemented as two > MEPs in the same MEG?) >From a management point of view you are just looking at two parameters of the same MEG, no? The messages are separated via ACH, so I don't see the issue. > 6) In a number of places the document describes two types of identifier > format, one for local scope within an ASN and one for global scope (by > prefixing the local identifier with the Global_ID for the ASN it is within). > > What is the reason for the two types having different lengths, rather than > using Global_ID of 0 to signify an identifier with local scope - is it to save > the 4 octets of Global_ID or is there another reason for having a different > length ID for local Vs global scopes? I think the only place where this has any significance is in CV where if you keep the check value in very high speed RAM you want to keep the state per session small as possible. I debated this several times with myself, my co-authors and others. This is where the consensus came out. > Nits: > > 1) The Abstract & Introduction both state: > > This document > defines identifiers for MPLS-TP management and OAM functions suitable > to IP/MPLS conventions. > > I'm not really sure what being "suitable to" means, maybe you really meant > "compatible with"? Ok. > 2) Section 3 also states: > ASN 0 is reserved and cannot be assigned. A Global_ID of zero means > that no Global_ID is specified. > > However ASN 0 is assigned to mean that no Global_ID is used, therefore, > consider rewording to something like: > > ASN 0 is reserved and cannot be assigned to an operator. An identifier > containing a Global_ID of zero means that no Global_ID is specified. Good. > > 3) Section 5 in the middle of the first paragraph. To keep consistent with the > style of the earlier paragraphs (which I like): > > s/The Tunnel_ID/The Tunnel Identifier (Tunnel_ID)/ Ok. > 4) Similarly, Section 5.1 s/Specifically a Tunnel_Num/Specifically a Tunnel > Number (Tunnel_Num)/ Ok. > 5) Section 5.1 in the 2nd example s/Global_Id/Global_ID/ Ok. > 6) Section 5.2.1 s/Specifically an LSP_Num/Specifically an LSP Number > (LSP_Num)/ Ok. > 7) Section 6 s/SAAI/SAII/ (occurs twice in that section) Hum, must be my slight dyslexia. > 8) Section 7.2.2 states > Thus a MEP_ID > used in end-to-end for a Pseudowire T-PE takes the form > > AGI::Global_ID::Node_ID::AC_ID > > I don't know what is meant by "used in end-to-end" This is cruft left from when we were calling S-Pes MEPs. Will delete. ...George > Ben > From ben@niven-jenkins.co.uk Fri Jul 22 11:14:04 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0BD21F8B58 for ; Fri, 22 Jul 2011 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL3pkDfFvtcG for ; Fri, 22 Jul 2011 11:14:03 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 67DFB21F8B57 for ; Fri, 22 Jul 2011 11:14:03 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QkKEZ-0007wh-UF; Fri, 22 Jul 2011 19:14:00 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Fri, 22 Jul 2011 19:13:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70273C34-4D5B-4D7A-90CB-A57D0865F2B3@niven-jenkins.co.uk> References: To: George Swallow X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-mpls-tp-identifiers.all@tools.ietf.org, rtg-dir@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-identifiers-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:14:04 -0000 George, Please see inline. On 20 Jul 2011, at 20:06, George Swallow wrote: > On 7/12/11 5:23 PM, "Ben Niven-Jenkins" = wrote: >=20 > >=20 >>=20 >> Document: draft-ietf-mpls-tp-identifiers-06.txt >> Reviewer: Ben Niven-Jenkins >> Review Date: 12 July 2011 >> IETF LC End Date: 11 July 2011 >> Intended Status: Standards Track >>=20 >> Summary: >> I have some minor concerns about this document that I think should be = resolved >> before publication. >>=20 >> Comments: >> In general the document is well written, however it defines the = format for a >> number of different identifiers some of which are related to others = in various >> ways and it is difficult from reading the document to easily get an = idea of >> the "big picture" of how the relationship between the different = identifiers >> which are defined. >=20 > I would like to avoid becoming another framework document, so I am a = bit > reticent to do that. I also don't want to overly constrain = implementations. > See below. OK I have no problem with not having such extra material, readers will = just have to work their brain a bit harder. >> For example section 5.1 defines the format for a Tunnel_ID and then = goes on to >> state "When an MPLS-TP Tunnel is configured, it MUST be assigned a = unique >> IF_ID at each endpoint. As usual, the IF_ID is composed of the local = Node_ID >> concatenated with a 32-bit IF_Num." However, the definition of = Tunnel_ID does >> not contain an IF_ID so it is not obvious to me from reading the = draft what >> the relationship is between the Tunnel_ID for a tunnel and the IF_ID = for the >> same tunnel and the circumstances when Tunnel_ID is the appropriate = identifier >> versus when IF_ID is the appropriate identifer. >=20 > I will remove this text. It is one example where I have an = implementation > in mind, but now that you've caused me to think about it, there are = other > possibilities here. >=20 >> Section 7.3 contains a simple diagram and uses it to show how the = identifiers >> are formed for a Pseudowire Segment Endpoint ID and it may be useful = to have a >> similar but expanded diagram at the beginning of the document to show = the >> different types of identifier that are defined, their scope within a = network >> and how they relate to one another. >>=20 >> Please also note that I reviewed this document without reading all = the MPLS-TP >> related OAM documents and so some of my questions may have been = answered if I >> had done so (e.g. minor issue 5 below). >>=20 >> Minor Issues: >> Some of the following "Minor Issues" are more questions for my = understanding >> and suggestions rather than "pure" issues as such but they are more >> substantial than nits so I included them here. >>=20 >> 1) Section 4 states that "The Node_ID is a unique 32-bit value" and = that "The >> IF_Num is a 32-bit unsigned integer" >>=20 >> Additionally both Tunnel_Num and LSP_Num are declared to be unsigned = integers >> but no other fields (except IF_Num mentioned above) are. >>=20 >> Is that meant to signify that Node_IDs (for example) are signed = values or is >> it because they are fields with a structured value (e.g. an IPv4 = address?) or >> some other reason such as it is expected to impact how they are = represented on >> the wire? >=20 > Would it satisfy you if I just say that they are all unsigned = integers? I think if you are going to declare the type of some you should declare = the type of them all. Alternatively if there is no real significance to = them being unsigned integers I'm happy with the document just referring = to them as "32-bit values". >> 2) The document makes several references to using an "A1/Z9 = convention", while >> it can be inferred that A1 and Z9 refer to either end of a = connection, is >> there a definitive reference for this convention as it is not one I = am >> familiar with and a search using a well known search engine just = returned >> results that linked this draft? >=20 > Apparently there is an A/Z convention used by the ITU. I used A1 Z9 = because > then most (now all, since the ICC got moved out) of the fields are = numbers > (make that unsigned integers ;-). OK, it does sound like the sort of thing ITU would have a convention for = but I wasn't familiar with it. Rereading the document I can see that = section 1.3 does in fact introduce the A/Z concept which is probably = sufficient if there isn't an easy document to reference because it is = more of a convention that a definition as such. >> 3) Section 5.2.1 states: >> Thus the format of an MPLS-TP co-routed bidirectional LSP_ID >> is: >>=20 >> A1-{Node_ID::Tunnel_Num}::Z9- >> {Node_ID::Tunnel_Num}::LSP_Num >>=20 >> Note that the uniqueness of identifiers does not depend on >> the A1/Z9 sort ordering. Thus the identifier >>=20 >> Z9-{Node_ID::Tunnel_Num}::A1- >> {Node_ID::Tunnel_Num}::LSP_Num >>=20 >> is synonymous with the one above. >>=20 >> I can see how the A1/Z9 sort ordering can generate different values = for LSP_ID >> and that as they are both referring to the same LSP they are = synonymous with >> one another. Is there any requirement for an application to be able = to >> translate from one possible LSP_ID to another synonymous LSP_ID for = the same >> LSP? Should there be an explicit mention that applications MUST treat = both >> forms as identical? >=20 > In general I do not see a need to translate, but in a few case there = will > be. But not all implementations of MPLS-TP may have those cases. >=20 > For example, the on demand cv draft uses a source/destination format = for the > LSP-ID. This is done from the sender-of-the-ping's point of view. It = was > done this way to ensure that when you get to a node you are tracing in = the > correct direction. But MPLS-TP in a *pure* transport environment will = most > likely not use on demand cv. >=20 > I can also see it being useful to be able to list out the tunnels and = lsps > sourced a particular node in order of their destinations with those > appearing first in the order. But again something that is not = necessary. OK. >> 4) Section 5.3 states >> * Extended Tunnel_ID =3D A1-Node_ID >> * Tunnel Sender Address =3D A1-Node_ID >>=20 >> RFC3209 states: >> Extended Tunnel ID >>=20 >> A 32-bit identifier used in the SESSION that remains constant >> over the life of the tunnel. Normally set to all zeros. >> Ingress nodes that wish to narrow the scope of a SESSION to = the >> ingress-egress pair may place their IPv4 address here as a >> globally unique identifier. >>=20 >> Which I interpret to mean that the Extended Tunnel_ID and the Tunnel = Sender >> Address may not be identical (as RFC3209 does not mandate that = Extended Tunnel >> ID be the same as the Tunnel Sender Address), in which case which = should be >> used for the Node_ID? >>=20 >> [I note that section 5.3 is not normative text but I think it is a = useful >> example to aid interoperability and therefore being clear on the = mappings is >> worthwhile] >=20 > I'll add some text: >=20 > "RFC 3209 allows some flexibility in how the Extended Tunnel ID > is chosen and a direct mapping is not mandated. One > convention that is often used, however, is to populate this > field with the same value as the Tunnel Sender Address. The > examples below follow that convention. Note that these are > only examples." Great, thanks. >> 5) Section 7.1.1 - The format of MPLS-TP Section MEG ID chosen means = that >> there can only ever be a single MEG per pair of Interfaces on a = section. Is >> that an architectural constraint that is acceptable or are there = possible use >> cases where multiple MEGs may need to exist between a pair of = interfaces on a >> section? E.g. could there be a use case which requires a MEG to do = CV/CC and a >> separate MEG to do performance management (or would that be = implemented as two >> MEPs in the same MEG?) >=20 > =46rom a management point of view you are just looking at two = parameters of > the same MEG, no? The messages are separated via ACH, so I don't see = the > issue. Fine, I wasn't sure myself whether it was actually an issue but I = thought I'd raise it because it could be an unintentional limitation. If = you're happy it isn't, I'm fine with that. >> 6) In a number of places the document describes two types of = identifier >> format, one for local scope within an ASN and one for global scope = (by >> prefixing the local identifier with the Global_ID for the ASN it is = within). >>=20 >> What is the reason for the two types having different lengths, rather = than >> using Global_ID of 0 to signify an identifier with local scope - is = it to save >> the 4 octets of Global_ID or is there another reason for having a = different >> length ID for local Vs global scopes? >=20 > I think the only place where this has any significance is in CV where = if you > keep the check value in very high speed RAM you want to keep the state = per > session small as possible. I debated this several times with myself, = my > co-authors and others. This is where the consensus came out. OK, I'm fine with that too. Thanks Ben >> Nits: >>=20 >> 1) The Abstract & Introduction both state: >>=20 >> This document >> defines identifiers for MPLS-TP management and OAM functions = suitable >> to IP/MPLS conventions. >>=20 >> I'm not really sure what being "suitable to" means, maybe you really = meant >> "compatible with"? >=20 > Ok. >=20 >> 2) Section 3 also states: >> ASN 0 is reserved and cannot be assigned. A Global_ID of zero = means >> that no Global_ID is specified. >>=20 >> However ASN 0 is assigned to mean that no Global_ID is used, = therefore, >> consider rewording to something like: >>=20 >> ASN 0 is reserved and cannot be assigned to an operator. An = identifier >> containing a Global_ID of zero means that no Global_ID is = specified. >=20 > Good. >=20 >>=20 >> 3) Section 5 in the middle of the first paragraph. To keep consistent = with the >> style of the earlier paragraphs (which I like): >>=20 >> s/The Tunnel_ID/The Tunnel Identifier (Tunnel_ID)/ >=20 > Ok. >=20 >> 4) Similarly, Section 5.1 s/Specifically a Tunnel_Num/Specifically a = Tunnel >> Number (Tunnel_Num)/ >=20 > Ok. >=20 >> 5) Section 5.1 in the 2nd example s/Global_Id/Global_ID/ >=20 > Ok. >=20 >> 6) Section 5.2.1 s/Specifically an LSP_Num/Specifically an LSP Number >> (LSP_Num)/=20 >=20 > Ok. >=20 >> 7) Section 6 s/SAAI/SAII/ (occurs twice in that section) >=20 > Hum, must be my slight dyslexia. >=20 >> 8) Section 7.2.2 states >> Thus a MEP_ID >> used in end-to-end for a Pseudowire T-PE takes the form >>=20 >> AGI::Global_ID::Node_ID::AC_ID >>=20 >> I don't know what is meant by "used in end-to-end" >=20 > This is cruft left from when we were calling S-Pes MEPs. Will delete. >=20 > ...George >=20 >> Ben >>=20 >=20 From eric.gray@ericsson.com Mon Jul 25 09:08:45 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B365E21F850B for ; Mon, 25 Jul 2011 09:08:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckloaGYfub9k for ; Mon, 25 Jul 2011 09:08:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2F21F8513 for ; Mon, 25 Jul 2011 07:12:55 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6PEClPU027818; Mon, 25 Jul 2011 09:12:51 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Jul 2011 10:12:44 -0400 From: Eric Gray To: "rtg-ads@tools.ietf.org" , "shiomoto.kohei@lab.ntt.co.jp" , "adrian@olddog.co.uk" Date: Mon, 25 Jul 2011 10:12:43 -0400 Thread-Topic: draft-shiomoto-ccamp-switch-programming-05 Thread-Index: AcxK1OuRaPwIk7BhT9SgweclKXpUWA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "huawei.danli@huawei.com" , "dbrungard@att.com" Subject: [RTG-DIR] draft-shiomoto-ccamp-switch-programming-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:08:45 -0000 RtgDir review: http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-progr= amming-05 Boiler-plate opening: I have been selected as the Routing Directorate reviewer for this=20 draft. The Routing Directorate seeks to review all routing or=20 routing-related drafts as they pass through IETF last call and=20 IESG review. The purpose of the review is to provide assistance to=20 the Routing ADs. For more information about the Routing Directorate,=20 please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing=20 ADs, it would be helpful if you could consider them along with any=20 other IETF Last Call comments that you receive, and strive to=20 resolve them through discussion or by updating the draft. Document: draft-shiomoto-ccamp-switch-programming Reviewer: Eric Gray Intended Status: Informational Summary: This document is ready for publication, assuming that was the intent of this review (it was reviewed as an individual draft, rather than a work group draft, hence this is not clear). Major Issues: No major issues found. Minor Issues: No minor issues found.= From lberger@labn.net Tue Jul 26 13:40:10 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3488711E811B for ; Tue, 26 Jul 2011 13:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.012 X-Spam-Level: X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4doNxWP767sU for ; Tue, 26 Jul 2011 13:40:08 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 78F4E11E80AF for ; Tue, 26 Jul 2011 13:40:08 -0700 (PDT) Received: (qmail 29987 invoked by uid 0); 26 Jul 2011 20:40:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 26 Jul 2011 20:40:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=sVe02mvRTrlWdQ0LPCvzCBqGP05k1fBhGnXGMcKtlkI=; b=ww/Fhlln22FfvM2s5v/lOwLb2k62rJb+lF3dyWTA9qyADkJHH5NHSjLdGzmED7+XrPhtbQhhG/tlXbgYLpjPl9/ZMAbGcbVeeP37G1Q/CmCMl43mLcMzUv3T2p8QKNvw; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QloQA-0007jz-RJ; Tue, 26 Jul 2011 14:40:07 -0600 Message-ID: <4E2F2626.8010603@labn.net> Date: Tue, 26 Jul 2011 16:40:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" References: <4E108F0B.5060305@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:40:10 -0000 Yaacov, Authors, Thank you for taking the time to provide a detailed response. Yaacov and I had a brief discussion on this mail and I tried to capture the high points below. I expect that Yaacov will run the details to ground. On 7/20/2011 8:29 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: > Note: Resent with the promised attachment!! > Lou, hi > > I wanted to get back to you on the issues that were not addressed in our > previous exchanges and verify that we can get closer to resolution of > the issues, based on answers from some of the other authors and Ads - > see my proposed resolutions below - > > Would appreciate your reply - so that we can close the actions prior to > Quebec. > > Thanx and Best Regards, > yaacov > > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Sunday, July 03, 2011 6:47 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; > draft-ietf-mpls-tp-linear-protection@tools.ietf.org > Subject: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and > IESG review, and sometimes on special request. The purpose of the > review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-mpls-tp-linear-protection-07.txt > Reviewer: Lou Berger > Review Date: 7/3/2011 > IETF LC End Date: 2011-07-05 > Intended Status: Standards Track > > Summary: > > I have some concerns about this document that I think should > be resolved before publication. > > Comments: > > Overall the document is well written and provides a lot of > detail. That said, I see a number of issues. Some of the > identified issues may be resolved through discussion (i.e., > correction of my misinterpretations!), others will require > changes to the text. > > In terms of readability, the document uses a state machine based > approach to define protocol behavior. While definition of state > machines is not novel in protocol specifications, I did find it a > bit hard to follow the presentation in this document. Particularly > from the perspective of verifying that all cases are covered. The > state table in Appendix A is certainly helpful, but I would have > preferred that it be normative as well as be accompanied by one or > more state diagrams. There are also inconsistencies in use of > RFC2119 and numbering conventions, which are pointed out below. > > Line numbers obtained from > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mpl > s-tp-linear-protection-07.txt > will be used in this review. > > Major Issues: > > - State synchronization after message loss: > > The PSC protocol uses a soft-state messaging approach to > synchronize state between PSC protocol peers. Two basic > implications of soft-state messaging are (a) that peers can and > will get of sync during periods of message loss, and (b) each > state message must represent the full and *current* state of the > message sender. (b) is critical for recovering for one or more > lost messages. A key point is that intermediate state changes > will not be visible to a peer during periods of prolong PSC > message loss. So this all leads to two discussion points: state > convergence time and loss of intermediate states. > > - State convergence time: > > The current PSC protocol definition, see section 4.1, has > messages representing a change being retransmitted 3x fast, then > followed by a less frequent "continuous" refresh message (5 > second default refresh period). An implication of this approach > is that peers may get out of sync for {n * refresh interval} > after a period of PSC message loss. To me this seems like a > potentially long period of time. A simple change that would > improve protocol behavior would be to trigger the 3x fast > transmission whenever a peer reports that it has recovered from > a reception problem (remote SFc). This approach is already in > place for on case (remote NR). For simplicity, perhaps it would > be best to require whenever a peer reports any change. (I can > provide proposed language if it helps.) > > Another alternative would be to adopt the changes that were made > to RSVP, another soft state protocol, to address operationally > observed message loss. (See the reliable message delivery > sections of RFC 2961.) But this is probably too major a change > at this time. > > [yw>] After discussion amongst the authors and AD, we suggest to add the > following statement to Section 4.1 (after the paragraph that explains > the general behavior): > "An implementation that is concerned about the potential for end points > to become > out of sync as a result of lost messages MAY choose to send messages > more > frequently at every state change. Such behavior is consistent with the > protocol > specified here and will be handled correctly by the receiver." [Comment from before discussion] So the result is out of sync in some cases and not in others, for some implementations? This seems like it will result in, at least, operational confusion and, more likely, slower than expected protection processing. IMO requiring 3x on all state changes is simpler and less likely to result in out of sync states for extended periods of time {n * slow refresh interval}. Note, I'm not suggesting the full fix that was made to RSVP, just the wider use of a mechanisms that is already defined. I'm not sure why you'd want this to be a MAY. Is it to deal with existing implementations? If so, I suggest to at least make it a SHOULD and drop the reference to motivation. [From conversation] Yaakov will discuss with co-authors to make this a MUST. > > An easily fixed related point: Section 4.1 is missing the formal > definition of the sending of refresh messages. (It is presented > as informative in section 4.3.3.) Propose adding at line 637 > something along the lines of: > > After the transmission of the three rapid messages, the LER > MUST retransmit the most recently transmitted PSC message on > a continual basis. > [yw>] Will add this statement. > > - Loss of intermediate states > > As defined, PSC messages don't represent full sender state as is > the norm for soft-state protocols, but rather provide the most > recent 'request' (see section 4.2.2.). This means that if there > are any states that can only be reached via intermediate states > (as opposed to just via the same event type/request), the state > machines between sending and receiving peers can get out of > sync. I haven't convinced myself that any of these cases exists > (state diagrams would make it perfectly clear!), so am not sure > this is a blocking issue. I mention it here to ensure all aware > of the issue and those more familiar with the protocol (perhaps > even working on implementations) can confirm that they too don't > see such cases. > > [yw>] After some involved discussion amongst the authors it was shown > (in a spreadsheet supplied by Eric Osborne, attached) that there are no > "catastrophic" scenarios of loss of synchronization between the two > end-points. Certainly there are no cases of unnecessary duplication of > data packets (1+1 always duplicates the packets, but the receiving end > point must only select one of these). The only border case for 1:1 > protection is one where one LER may be sending data on W while the other > LER may be sending the data on P. When considering the cases that Eric > points out, I think that they can be characterized to be in two > situations that are both readily, aligned: > 1. The cases of a one-sided identification (either an Operator command > to one LER, or a unidirectional fault) of a trigger, that will be > aligned when the far-end point reacts to the remote message. > 2. The cases where one LER is in a Protection state and the other LER > receives a Lockout of Protection command - this will be aligned when the > protecting side receives the remote LO message. > This is a side-effect of using a single phased protocol. And in order > to make this more clear in the document, I suggest that we add a > statement to Section 4.3.1 (at the end of the second paragraph stating: > "As a side-effect of using a single-phased protocol, there will be a > short period during state transitions of one-sided triggers (e.g. > operator commands, or unidirectional SF) when one LER may be > transporting/selecting the data from one transport path while the other > end point is transporting/selecting from the other transport path. This > should become coordinated once the remote message is received and the > far-end LER performs the protection switching operation." > Will this clarify the problem? [from discussion] The point of my comment was to raise this as a potential issue with those who are more knowledgeable with the protocol. Your assurance that you have considered this possibility and there are no issues is all I was looking for. No text change is requested/needed. So point should be closed. > > - Priority of inputs (FS vs SF-P) > > Per section 4.3.2, FS is lower priority than SF-P. Per lines > 397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427 > the difference between MS and FS is that an MS triggered switch > to the protection path only will occur when the protection path > is in normal state (i.e., no SF-P) while FS ignores the state of > the protection path. Unless I'm missing something (which is > always possible!) this means that FS should be *higher* priority > than SF-P. This impacts the handling of the FS input for > multiple states in section 4.3.3. and Appendix A. > [yw>] Other authors reminded me of the difference between data-plane > linear protection and control-plane protection that directly affects > this issue - Since the PSC messages are being transmitted over the > protection path in the data-plane, then if there is a SF-P condition, > these messages cannot be transmitted, so that if there is a FS at this > point - there would be no way to notify the far-end LER! Therefore, we > are "forced" to up the priority of the SF-P to be higher than that of > the FS! [from discussion] We agreed that there is a difference between FS and MS and in the case of an SF-P this difference is lost. I proposed that (a) the priority of FS be raised above SF-P in this document and (b) you add a note (perhaps in section 4.3.3) that when FS is issued when the protection path is in a failed/errored state that it is possible that the remote side will not act see the FS until the fault clears. Yaacov will discuss with authors. > > - Relationship to data plane behavior > > Section 3 briefly talks the "protection switching actions" that > an LER may take, and that the "MEP SHOULD initiate a protection > switch operation" (lines 417/8). But the document really stops > short of defining what actions a local LER should take on > particular state changes. It seems to me that > required/recommended data-plane behavior should be explicitly (rather > than implicitly) identified in section 4.3.3. > > [yw>] Not sure what your concern was here. To my understanding the data > plane behavior of the LER consists of the following possible actions - > 1. Transmit a PSC message indicating the current state (Req + FPath + > Path) of the LER, 2. Decide where the data should be transported, i.e. > either on the Working or the Protection path, and 3. Decide from which > path to select the data. These actions are described in Sections > 4.3.3.x, i.e. the PSC message is indicated in the bullets that explain > the reaction to the input, the actions of where to transport (and > select) the data is stated in the opening paragraph of each state, where > (in some form or other) it states "When the LER is in this state, data > is transported on ...". > There was thought (amongst the authors) that the following statement in > Section 3.2 was causing the concerns: " These remote messages indicate > the status of the transport path from the viewpoint of the far-end LER, > and may indicate if the local MEP SHOULD initiate a protection switch > operation." And therefore we will change this to state: " Remote > messages indicate the status of the transport path from the viewpoint of > the far-end LER. These messages may drive state changes on the local > MEP, as defined later in this document." > Will this be acceptable? > [from discussion] Agreed to use SHALL in the existing language related to data plane in section 4.3.3.x. May also add a general comment stating that data plane state is described per PSC state and not per transition/event. > Minor issues > > - use of RFC2119 language > > [yw>] These were addressed in the previous exchanges > > - Line 612, 617: these are informative/narrative sentences > s/MUST/must|will > s/SHALL/are > [yw>] addressed previously > > - Lines 629, 638: aren't these MUSTs? If not needs some > explanatory text. > [yw>] addressed previously > > - Line 643 missing "default": s/an/a default > [yw>] addressed previously > > - Section 4.3.3: There are a lot of "SHOULDs" in this section. > Given this text relates to the synchronization of state between > peers, what happens when one peer implements the "SHOULD" and the > other peer does not? In order to avoid implementations that are > compliant with this document but can't interoperate, either this > case needs to be covered or these "SHOULDs" need to be "MUSTs". > [yw>] addressed previously > > - Lines 205-206: The meaning of "maintain traffic" is not clear. > [yw>] addressed previously > > - Lines 215-217: suggest making it explicit (rather than implied) > that 1:1 unidirectional and 1:n are "out of scope of this > document" > [yw>] addressed previously > > - Lines 225-219: so is support for 1+1 for P2MP in or out of > scope? This section really should be explicit on this point. > [yw>] addressed previously > > - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and > [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your > draft excludes [RFC4873], is this intentional? If so, why? > [yw>] addressed previously > > - Lines 400-403, 444-446. The definitions for local MS and remote > MS are subtly different. 400-403 says "switched from the working > path to the protection path". While 444-446 says "switch the > traffic to the path that was not being used previously". While > I personally prefer this definition, Section 4.3.3 seems to say > that 444-446 should read "switch the traffic from the working > path to the protection path". > [yw>] addressed previously > > - Line 665. No definition is given for the "Reserved" field. A > typical definition for such fields is "The Reserved field MUST > be set to zero on transmission and MUST be ignored on receipt." > [yw>] addressed previously > > - Lines 678-681. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? > [yw>] After consultation - it seems that the feeling amongst the authors > is to remain with only two bits as this would be rather disruptive for > "early adoptions" of the standard that is already implemented and > waiting for release. fair enough. I can understand not making changes that aren't absolutely required. > > - Numbering consistency > > The document is inconsistent with how it indicates field values. > Unless there's a sub-structure to a field, e.g., a flags field, > values should be listed in decimal not in binary. Impacts lines > 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines > really refer to bit fields, then the bits need to be defined. > [yw>] addressed previously > > - Line 732. Is DNR limited to transmission behavior only? If not, > need to change this line. > [yw>] addressed previously > > - Lines 742-760. Are 2 bits really sufficient for the long term? > There are 23 unused bits in the header, perhaps you want to give > one to this field? If there really is a need for future > extensions (per line 755) then a wider field is really needed. > [yw>] While there was less reluctance to widen this field, we were still > advised not to include changes that might involve going back to the WG. > In addition, it is not clear to me that there is a need for additional > bits for this field. fair enough. I can understand not making changes that aren't absolutely required. > > - Lines 774-784: How is the absence of faults indicated? Perhaps 0 > or 255 should be used for this case? > [yw>] addressed previously > > - Lines 820: strictly speaking this field is not part of "TLV > information", also receive behavior is not specified (see > comment on line 665 above.) > [yw>] addressed previously > > - Lines 822-824, The TLV format definition is missing. (I.e. how > big are the T & L fields, does L include T&L or not, are there > any padding requirements...) > [yw>] Since this document does not describe any TLV fields, just a > placeholder for future ones - do not feel that there is a need to > specify this information at this point, but rather leave it to the > documents that may define specific TLVs. In answer to another point > that you raise will request that IANA administer a registry of the > future TLVs. > > - Lines 853, 856, 866: text is informative, should not include > RFC2119 language. > [yw>] addressed previously > > - Handling of PA:F:L/FS after SFC-P > > If for some reason the prioritization of FS and SF-P remain as > is (see major issue above), the current state machine > definitions result in a the FS state being lost when an SF-P is > cleared. Consider the case of the following states and inputs > (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> > WTR--(WTRExp)--> WTR--(remNR)-->N > > As the operator set FS, shouldn't the state return to PA:F:L not > N? > > - SF-P can mask SF-W > > Consider the scenario where the protection path fails and then > the working path fails. As I read Section 4.3.3 and appendix a, > the order of states and inputs (in parentheses) are as follows: > N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) > > This seems wrong. When the protection path SFc is received > shouldn't the result be a protection switch / PF:W:L (NR(1,0)? > [yw>] These were addressed previously Have the following outstanding comment: >> [yw>] Similar to the previous consideration. >> > > Okay, I understand the approach the authors are taking. Although to > ensure proper implementation and interoperability, this approach needs > to be made explicit in the document, probably somewhere in section 4.3. > Furthermore, Section 3 needs to address this in the description of > generation and handling of "local requests". [post discussion] This issue is still open. Yaacov to consider how to address in draft. > - Remote SF impacts protection switching when using unidirectional > protection > > As I read section 4.3, a remote SF will impact the behavior of > the protection bridge of an LER even when 1+1 unidirectional > protection is being used. My understanding is that the bridges > are supposed to switch autonomously in this mode. Did I miss > something? > > [yw>] Will add statements as follows to clarify 1+1 unidirectional > protection: > 1. In Section 3.2 (Remote requests) at the end of the first paragraph: > "When using 1+1 Unidirectional protection, an LER that receives a remote > request SHALL NOT perform any protection switching action, i.e. will > continue to select traffic from the working path and transport traffic > on both paths." > 2. At the end of the last paragraph of Section 4.3.1 stating: "For 1+1 > unidirectional protection, the state of the selector will only be > switched in reaction to a local message. When receiving a remote > message, a LER that is configured for 1+1 unidirectional protection, > will transfer to the new remote state, however it will continue to > select data according to latest known local state." > Will this clarify the protection actions for this protection scheme? > > - IANA Considerations, section 5 > Don't you want an IANA registry for the TLV types that may be > defined in the future per section 4.2.7? > [yw>] Have added the request for an additional registry for the TLV > types. > > Nits: > > [yw>] all addressed previously > That's it. Much thanks! Lou From jmh@joelhalpern.com Fri Jul 29 05:53:43 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FE921F8BB9 for ; Fri, 29 Jul 2011 05:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1atNIbcWupmX for ; Fri, 29 Jul 2011 05:53:43 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id A521821F8B99 for ; Fri, 29 Jul 2011 05:53:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 95C5C325C172; Fri, 29 Jul 2011 05:53:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1B75A325C1F0; Fri, 29 Jul 2011 05:53:41 -0700 (PDT) Message-ID: <4E32AD55.9060300@joelhalpern.com> Date: Fri, 29 Jul 2011 08:53:41 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , draft-simpson-isis-ppp-unique.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [RTG-DIR] RtgDir review: draft-simpson-isis-ppp-unique-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 12:53:43 -0000 Hello Bill, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-simpson-isis-ppp-unique-01.txt Reviewer: Joel M. Halpern Review Date: 29-July-2011 IETF LC End Date: N/A Intended Status: Independent, Experimental Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Major Issues: The modification to the IS-IS message exchange behavior which is section 3 of this document should be removed. It is not necessary for the primary goal that the document states it is concerned with. Existing practice already recognizes that collision can occur, and provides for what responses should be taken. More importantly, the specification provided does not actually solve the problem it claims to solve. 1) It claims to handle System-ID collision, but in fact describes only the case of detecting a collision with a neighbor. 2) The text does not describe how to actually detect collision, since return of ones own LSAs is valid and expected behavior under various circumstances. 3) It then replaces the collision problem with a proxy "failing to resolve participation in an area within 10 seconds", which is not itself well defined. And which is NOT the same as a System-ID collision. In fact, a System-ID collision does not cause a result that can reasonably be mapped to "failure to resolve participation in an area" Minor Issues, which still need attention: In defining the construction of the system I-D this draft specifies that the "locally-assigned" and "broadcast/multicast" bits are to be set in the system I-D. As far as I know, the first of these is correct. The second one, setting the group bit in the OUI, seems to be an inappropriate use of that bit, in the hope that no one else will have made the same abuse. Given that existing behavior allows a system to specify its system-ID in a local fashion, that dimension of the spec does not violate the existing documents. However, the description in the document would lead the reader to conclude that there were no existing solutions to the problem of an IS-IS participant without a usable MAC address. While one might well dislike the existing practice of manual configuration, it does exist and does address the problem. This document should recognize that. Re-summarizing: If section 3 is removed, and the lesser issues are addressed, this would appear to be an acceptable experimental independent submission. From yaacov.weingarten@nsn.com Wed Jul 20 05:16:35 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5635021F867F for ; Wed, 20 Jul 2011 05:16:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41M3OG2hk0tC for ; Wed, 20 Jul 2011 05:16:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82C21F8582 for ; Wed, 20 Jul 2011 05:16:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p6KCGSdB016983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 14:16:30 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6KCGPii014847; Wed, 20 Jul 2011 14:16:25 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jul 2011 14:16:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BsKg BtGe FfLU Gh/d JLsO NCbQ Saw2 Si/U dl8H hjZG kIr/ la6w pyCb rBvN sVwm uf8C; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAG0AcABsAHMALQB0AHAALQBsAGkAbgBlAGEAcgAtAHAAcgBvAHQAZQBjAHQAaQBvAG4AQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBsAGIAZQByAGcAZQByAEAAbABhAGIAbgAuAG4AZQB0ADsAcgB0AGcALQBhAGQAcwBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AHIAdABnAC0AZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {58C3482A-8EBB-42FA-B358-91C0DCBAFE7C}; eQBhAGEAYwBvAHYALgB3AGUAaQBuAGcAYQByAHQAZQBuAEAAbgBzAG4ALgBjAG8AbQA=; Wed, 20 Jul 2011 12:15:43 GMT; UgBFADoAIABSAHQAZwBEAGkAcgAgAHIAZQB2AGkAZQB3ADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBwAGwAcwAtAHQAcAAtAGwAaQBuAGUAYQByAC0AcAByAG8AdABlAGMAdABpAG8AbgAtADAANwAuAHQAeAB0AA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {58C3482A-8EBB-42FA-B358-91C0DCBAFE7C} Content-class: urn:content-classes:message Date: Wed, 20 Jul 2011 14:15:42 +0200 Message-ID: In-Reply-To: <4E108F0B.5060305@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Thread-Index: Acw5mIyXYebMZO6WQ8WKEvsxKCWMnAMbHmrA X-Priority: 1 Priority: Urgent Importance: high References: <4E108F0B.5060305@labn.net> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Lou Berger" , X-OriginalArrivalTime: 20 Jul 2011 12:16:24.0908 (UTC) FILETIME=[D814A8C0:01CC46D6] X-Mailman-Approved-At: Fri, 29 Jul 2011 10:29:42 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:16:35 -0000 Lou, hi I wanted to get back to you on the issues that were not addressed in our previous exchanges and verify that we can get closer to resolution of the issues, based on answers from some of the other authors and Ads - see my proposed resolutions below -=20 Would appreciate your reply - so that we can close the actions prior to Quebec. Thanx and Best Regards, yaacov -----Original Message----- From: ext Lou Berger [mailto:lberger@labn.net]=20 Sent: Sunday, July 03, 2011 6:47 PM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-linear-protection-07.txt Reviewer: Lou Berger Review Date: 7/3/2011 IETF LC End Date: 2011-07-05 Intended Status: Standards Track Summary: I have some concerns about this document that I think should be resolved before publication. Comments: Overall the document is well written and provides a lot of detail. That said, I see a number of issues. Some of the identified issues may be resolved through discussion (i.e., correction of my misinterpretations!), others will require changes to the text. In terms of readability, the document uses a state machine based approach to define protocol behavior. While definition of state machines is not novel in protocol specifications, I did find it a bit hard to follow the presentation in this document. Particularly from the perspective of verifying that all cases are covered. The state table in Appendix A is certainly helpful, but I would have preferred that it be normative as well as be accompanied by one or more state diagrams. There are also inconsistencies in use of RFC2119 and numbering conventions, which are pointed out below. Line numbers obtained from http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-mp= l s-tp-linear-protection-07.txt will be used in this review. Major Issues: - State synchronization after message loss: The PSC protocol uses a soft-state messaging approach to synchronize state between PSC protocol peers. Two basic implications of soft-state messaging are (a) that peers can and will get of sync during periods of message loss, and (b) each state message must represent the full and *current* state of the message sender. (b) is critical for recovering for one or more lost messages. A key point is that intermediate state changes will not be visible to a peer during periods of prolong PSC message loss. So this all leads to two discussion points: state convergence time and loss of intermediate states. - State convergence time: The current PSC protocol definition, see section 4.1, has messages representing a change being retransmitted 3x fast, then followed by a less frequent "continuous" refresh message (5 second default refresh period). An implication of this approach is that peers may get out of sync for {n * refresh interval} after a period of PSC message loss. To me this seems like a potentially long period of time. A simple change that would improve protocol behavior would be to trigger the 3x fast transmission whenever a peer reports that it has recovered from a reception problem (remote SFc). This approach is already in place for on case (remote NR). For simplicity, perhaps it would be best to require whenever a peer reports any change. (I can provide proposed language if it helps.) Another alternative would be to adopt the changes that were made to RSVP, another soft state protocol, to address operationally observed message loss. (See the reliable message delivery sections of RFC 2961.) But this is probably too major a change at this time. [yw>] After discussion amongst the authors and AD, we suggest to add the following statement to Section 4.1 (after the paragraph that explains the general behavior): "An implementation that is concerned about the potential for end points to become out of sync as a result of lost messages MAY choose to send messages more frequently at every state change. Such behavior is consistent with the protocol specified here and will be handled correctly by the receiver." An easily fixed related point: Section 4.1 is missing the formal definition of the sending of refresh messages. (It is presented as informative in section 4.3.3.) Propose adding at line 637 something along the lines of: After the transmission of the three rapid messages, the LER MUST retransmit the most recently transmitted PSC message on a continual basis. [yw>] Will add this statement. - Loss of intermediate states As defined, PSC messages don't represent full sender state as is the norm for soft-state protocols, but rather provide the most recent 'request' (see section 4.2.2.). This means that if there are any states that can only be reached via intermediate states (as opposed to just via the same event type/request), the state machines between sending and receiving peers can get out of sync. I haven't convinced myself that any of these cases exists (state diagrams would make it perfectly clear!), so am not sure this is a blocking issue. I mention it here to ensure all aware of the issue and those more familiar with the protocol (perhaps even working on implementations) can confirm that they too don't see such cases. [yw>] After some involved discussion amongst the authors it was shown (in a spreadsheet supplied by Eric Osborne, attached) that there are no "catastrophic" scenarios of loss of synchronization between the two end-points. Certainly there are no cases of unnecessary duplication of data packets (1+1 always duplicates the packets, but the receiving end point must only select one of these). The only border case for 1:1 protection is one where one LER may be sending data on W while the other LER may be sending the data on P. When considering the cases that Eric points out, I think that they can be characterized to be in two situations that are both readily, aligned: 1. The cases of a one-sided identification (either an Operator command to one LER, or a unidirectional fault) of a trigger, that will be aligned when the far-end point reacts to the remote message. 2. The cases where one LER is in a Protection state and the other LER receives a Lockout of Protection command - this will be aligned when the protecting side receives the remote LO message. This is a side-effect of using a single phased protocol. And in order to make this more clear in the document, I suggest that we add a statement to Section 4.3.1 (at the end of the second paragraph stating: "As a side-effect of using a single-phased protocol, there will be a short period during state transitions of one-sided triggers (e.g. operator commands, or unidirectional SF) when one LER may be transporting/selecting the data from one transport path while the other end point is transporting/selecting from the other transport path. This should become coordinated once the remote message is received and the far-end LER performs the protection switching operation." Will this clarify the problem? - Priority of inputs (FS vs SF-P) Per section 4.3.2, FS is lower priority than SF-P. Per lines 397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427 the difference between MS and FS is that an MS triggered switch to the protection path only will occur when the protection path is in normal state (i.e., no SF-P) while FS ignores the state of the protection path. Unless I'm missing something (which is always possible!) this means that FS should be *higher* priority than SF-P. This impacts the handling of the FS input for multiple states in section 4.3.3. and Appendix A. [yw>] Other authors reminded me of the difference between data-plane linear protection and control-plane protection that directly affects this issue - Since the PSC messages are being transmitted over the protection path in the data-plane, then if there is a SF-P condition, these messages cannot be transmitted, so that if there is a FS at this point - there would be no way to notify the far-end LER! Therefore, we are "forced" to up the priority of the SF-P to be higher than that of the FS! - Relationship to data plane behavior Section 3 briefly talks the "protection switching actions" that an LER may take, and that the "MEP SHOULD initiate a protection switch operation" (lines 417/8). But the document really stops short of defining what actions a local LER should take on particular state changes. It seems to me that required/recommended data-plane behavior should be explicitly (rather than implicitly) identified in section 4.3.3. [yw>] Not sure what your concern was here. To my understanding the data plane behavior of the LER consists of the following possible actions - 1. Transmit a PSC message indicating the current state (Req + FPath + Path) of the LER, 2. Decide where the data should be transported, i.e. either on the Working or the Protection path, and 3. Decide from which path to select the data. These actions are described in Sections 4.3.3.x, i.e. the PSC message is indicated in the bullets that explain the reaction to the input, the actions of where to transport (and select) the data is stated in the opening paragraph of each state, where (in some form or other) it states "When the LER is in this state, data is transported on ...". There was thought (amongst the authors) that the following statement in Section 3.2 was causing the concerns: " These remote messages indicate the status of the transport path from the viewpoint of the far-end LER, and may indicate if the local MEP SHOULD initiate a protection switch operation." And therefore we will change this to state: " Remote messages indicate the status of the transport path from the viewpoint of the far-end LER. These messages may drive state changes on the local MEP, as defined later in this document." Will this be acceptable? Minor issues - use of RFC2119 language [yw>] These were addressed in the previous exchanges - Line 612, 617: these are informative/narrative sentences s/MUST/must|will s/SHALL/are [yw>] addressed previously - Lines 629, 638: aren't these MUSTs? If not needs some explanatory text. [yw>] addressed previously - Line 643 missing "default": s/an/a default [yw>] addressed previously - Section 4.3.3: There are a lot of "SHOULDs" in this section. Given this text relates to the synchronization of state between peers, what happens when one peer implements the "SHOULD" and the other peer does not? In order to avoid implementations that are compliant with this document but can't interoperate, either this case needs to be covered or these "SHOULDs" need to be "MUSTs". [yw>] addressed previously - Lines 205-206: The meaning of "maintain traffic" is not clear. [yw>] addressed previously - Lines 215-217: suggest making it explicit (rather than implied) that 1:1 unidirectional and 1:n are "out of scope of this document" [yw>] addressed previously - Lines 225-219: so is support for 1+1 for P2MP in or out of scope? This section really should be explicit on this point. [yw>] addressed previously - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your draft excludes [RFC4873], is this intentional? If so, why? [yw>] addressed previously - Lines 400-403, 444-446. The definitions for local MS and remote MS are subtly different. 400-403 says "switched from the working path to the protection path". While 444-446 says "switch the traffic to the path that was not being used previously". While I personally prefer this definition, Section 4.3.3 seems to say that 444-446 should read "switch the traffic from the working path to the protection path". [yw>] addressed previously - Line 665. No definition is given for the "Reserved" field. A typical definition for such fields is "The Reserved field MUST be set to zero on transmission and MUST be ignored on receipt." [yw>] addressed previously - Lines 678-681. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? [yw>] After consultation - it seems that the feeling amongst the authors is to remain with only two bits as this would be rather disruptive for "early adoptions" of the standard that is already implemented and waiting for release. - Numbering consistency The document is inconsistent with how it indicates field values. Unless there's a sub-structure to a field, e.g., a flags field, values should be listed in decimal not in binary. Impacts lines 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines really refer to bit fields, then the bits need to be defined. [yw>] addressed previously - Line 732. Is DNR limited to transmission behavior only? If not, need to change this line. [yw>] addressed previously - Lines 742-760. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? If there really is a need for future extensions (per line 755) then a wider field is really needed. [yw>] While there was less reluctance to widen this field, we were still advised not to include changes that might involve going back to the WG. In addition, it is not clear to me that there is a need for additional bits for this field. - Lines 774-784: How is the absence of faults indicated? Perhaps 0 or 255 should be used for this case? [yw>] addressed previously - Lines 820: strictly speaking this field is not part of "TLV information", also receive behavior is not specified (see comment on line 665 above.) [yw>] addressed previously - Lines 822-824, The TLV format definition is missing. (I.e. how big are the T & L fields, does L include T&L or not, are there any padding requirements...) [yw>] Since this document does not describe any TLV fields, just a placeholder for future ones - do not feel that there is a need to specify this information at this point, but rather leave it to the documents that may define specific TLVs. In answer to another point that you raise will request that IANA administer a registry of the future TLVs. - Lines 853, 856, 866: text is informative, should not include RFC2119 language. [yw>] addressed previously - Handling of PA:F:L/FS after SFC-P If for some reason the prioritization of FS and SF-P remain as is (see major issue above), the current state machine definitions result in a the FS state being lost when an SF-P is cleared. Consider the case of the following states and inputs (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> WTR--(WTRExp)--> WTR--(remNR)-->N As the operator set FS, shouldn't the state return to PA:F:L not N? - SF-P can mask SF-W Consider the scenario where the protection path fails and then the working path fails. As I read Section 4.3.3 and appendix a, the order of states and inputs (in parentheses) are as follows: N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) This seems wrong. When the protection path SFc is received shouldn't the result be a protection switch / PF:W:L (NR(1,0)? [yw>] These were addressed previously - Remote SF impacts protection switching when using unidirectional protection As I read section 4.3, a remote SF will impact the behavior of the protection bridge of an LER even when 1+1 unidirectional protection is being used. My understanding is that the bridges are supposed to switch autonomously in this mode. Did I miss something? [yw>] Will add statements as follows to clarify 1+1 unidirectional protection: 1. In Section 3.2 (Remote requests) at the end of the first paragraph: "When using 1+1 Unidirectional protection, an LER that receives a remote request SHALL NOT perform any protection switching action, i.e. will continue to select traffic from the working path and transport traffic on both paths." 2. At the end of the last paragraph of Section 4.3.1 stating: "For 1+1 unidirectional protection, the state of the selector will only be switched in reaction to a local message. When receiving a remote message, a LER that is configured for 1+1 unidirectional protection, will transfer to the new remote state, however it will continue to select data according to latest known local state." Will this clarify the protection actions for this protection scheme? - IANA Considerations, section 5 Don't you want an IANA registry for the TLV types that may be defined in the future per section 4.2.7? [yw>] Have added the request for an additional registry for the TLV types. Nits: [yw>] all addressed previously From yaacov.weingarten@nsn.com Wed Jul 20 05:30:05 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D718921F875C for ; Wed, 20 Jul 2011 05:30:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq+yV7koyH1s for ; Wed, 20 Jul 2011 05:30:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8143A21F8757 for ; Wed, 20 Jul 2011 05:30:03 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p6KCU1nu013701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 14:30:02 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6KCU1Z7028488; Wed, 20 Jul 2011 14:30:01 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 14:29:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: D2JT EAyr HAiC JdHV KDF0 M2k6 R9KW Su8b TK/q YIAI hEZW lqms nJKI plho p2kl q2By; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAG0AcABsAHMALQB0AHAALQBsAGkAbgBlAGEAcgAtAHAAcgBvAHQAZQBjAHQAaQBvAG4AQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBsAGIAZQByAGcAZQByAEAAbABhAGIAbgAuAG4AZQB0ADsAcgB0AGcALQBhAGQAcwBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AHIAdABnAC0AZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {92EFEE9A-AF45-4857-90EB-90DBBC33B5C5}; eQBhAGEAYwBvAHYALgB3AGUAaQBuAGcAYQByAHQAZQBuAEAAbgBzAG4ALgBjAG8AbQA=; Wed, 20 Jul 2011 12:29:25 GMT; UgBFADoAIABSAHQAZwBEAGkAcgAgAHIAZQB2AGkAZQB3ADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBwAGwAcwAtAHQAcAAtAGwAaQBuAGUAYQByAC0AcAByAG8AdABlAGMAdABpAG8AbgAtADAANwAuAHQAeAB0AA== MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC46D8.BA555A14" x-cr-puzzleid: {92EFEE9A-AF45-4857-90EB-90DBBC33B5C5} Content-class: urn:content-classes:message Date: Wed, 20 Jul 2011 14:29:25 +0200 Message-ID: In-Reply-To: <4E108F0B.5060305@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Thread-Index: Acw5mIyXYebMZO6WQ8WKEvsxKCWMnAMbHmrA X-Priority: 1 Priority: Urgent Importance: high References: <4E108F0B.5060305@labn.net> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Lou Berger" , X-OriginalArrivalTime: 20 Jul 2011 12:29:54.0094 (UTC) FILETIME=[BA64A4E0:01CC46D8] X-Mailman-Approved-At: Fri, 29 Jul 2011 10:29:42 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:30:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC46D8.BA555A14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note: Resent with the promised attachment!! Lou, hi I wanted to get back to you on the issues that were not addressed in our previous exchanges and verify that we can get closer to resolution of the issues, based on answers from some of the other authors and Ads - see my proposed resolutions below -=20 Would appreciate your reply - so that we can close the actions prior to Quebec. Thanx and Best Regards, yaacov -----Original Message----- From: ext Lou Berger [mailto:lberger@labn.net]=20 Sent: Sunday, July 03, 2011 6:47 PM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-linear-protection@tools.ietf.org Subject: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-linear-protection-07.txt Reviewer: Lou Berger Review Date: 7/3/2011 IETF LC End Date: 2011-07-05 Intended Status: Standards Track Summary: I have some concerns about this document that I think should be resolved before publication. Comments: Overall the document is well written and provides a lot of detail. That said, I see a number of issues. Some of the identified issues may be resolved through discussion (i.e., correction of my misinterpretations!), others will require changes to the text. In terms of readability, the document uses a state machine based approach to define protocol behavior. While definition of state machines is not novel in protocol specifications, I did find it a bit hard to follow the presentation in this document. Particularly from the perspective of verifying that all cases are covered. The state table in Appendix A is certainly helpful, but I would have preferred that it be normative as well as be accompanied by one or more state diagrams. There are also inconsistencies in use of RFC2119 and numbering conventions, which are pointed out below. Line numbers obtained from http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-mp= l s-tp-linear-protection-07.txt will be used in this review. Major Issues: - State synchronization after message loss: The PSC protocol uses a soft-state messaging approach to synchronize state between PSC protocol peers. Two basic implications of soft-state messaging are (a) that peers can and will get of sync during periods of message loss, and (b) each state message must represent the full and *current* state of the message sender. (b) is critical for recovering for one or more lost messages. A key point is that intermediate state changes will not be visible to a peer during periods of prolong PSC message loss. So this all leads to two discussion points: state convergence time and loss of intermediate states. - State convergence time: The current PSC protocol definition, see section 4.1, has messages representing a change being retransmitted 3x fast, then followed by a less frequent "continuous" refresh message (5 second default refresh period). An implication of this approach is that peers may get out of sync for {n * refresh interval} after a period of PSC message loss. To me this seems like a potentially long period of time. A simple change that would improve protocol behavior would be to trigger the 3x fast transmission whenever a peer reports that it has recovered from a reception problem (remote SFc). This approach is already in place for on case (remote NR). For simplicity, perhaps it would be best to require whenever a peer reports any change. (I can provide proposed language if it helps.) Another alternative would be to adopt the changes that were made to RSVP, another soft state protocol, to address operationally observed message loss. (See the reliable message delivery sections of RFC 2961.) But this is probably too major a change at this time. [yw>] After discussion amongst the authors and AD, we suggest to add the following statement to Section 4.1 (after the paragraph that explains the general behavior): "An implementation that is concerned about the potential for end points to become out of sync as a result of lost messages MAY choose to send messages more frequently at every state change. Such behavior is consistent with the protocol specified here and will be handled correctly by the receiver." An easily fixed related point: Section 4.1 is missing the formal definition of the sending of refresh messages. (It is presented as informative in section 4.3.3.) Propose adding at line 637 something along the lines of: After the transmission of the three rapid messages, the LER MUST retransmit the most recently transmitted PSC message on a continual basis. [yw>] Will add this statement. - Loss of intermediate states As defined, PSC messages don't represent full sender state as is the norm for soft-state protocols, but rather provide the most recent 'request' (see section 4.2.2.). This means that if there are any states that can only be reached via intermediate states (as opposed to just via the same event type/request), the state machines between sending and receiving peers can get out of sync. I haven't convinced myself that any of these cases exists (state diagrams would make it perfectly clear!), so am not sure this is a blocking issue. I mention it here to ensure all aware of the issue and those more familiar with the protocol (perhaps even working on implementations) can confirm that they too don't see such cases. [yw>] After some involved discussion amongst the authors it was shown (in a spreadsheet supplied by Eric Osborne, attached) that there are no "catastrophic" scenarios of loss of synchronization between the two end-points. Certainly there are no cases of unnecessary duplication of data packets (1+1 always duplicates the packets, but the receiving end point must only select one of these). The only border case for 1:1 protection is one where one LER may be sending data on W while the other LER may be sending the data on P. When considering the cases that Eric points out, I think that they can be characterized to be in two situations that are both readily, aligned: 1. The cases of a one-sided identification (either an Operator command to one LER, or a unidirectional fault) of a trigger, that will be aligned when the far-end point reacts to the remote message. 2. The cases where one LER is in a Protection state and the other LER receives a Lockout of Protection command - this will be aligned when the protecting side receives the remote LO message. This is a side-effect of using a single phased protocol. And in order to make this more clear in the document, I suggest that we add a statement to Section 4.3.1 (at the end of the second paragraph stating: "As a side-effect of using a single-phased protocol, there will be a short period during state transitions of one-sided triggers (e.g. operator commands, or unidirectional SF) when one LER may be transporting/selecting the data from one transport path while the other end point is transporting/selecting from the other transport path. This should become coordinated once the remote message is received and the far-end LER performs the protection switching operation." Will this clarify the problem? - Priority of inputs (FS vs SF-P) Per section 4.3.2, FS is lower priority than SF-P. Per lines 397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427 the difference between MS and FS is that an MS triggered switch to the protection path only will occur when the protection path is in normal state (i.e., no SF-P) while FS ignores the state of the protection path. Unless I'm missing something (which is always possible!) this means that FS should be *higher* priority than SF-P. This impacts the handling of the FS input for multiple states in section 4.3.3. and Appendix A. [yw>] Other authors reminded me of the difference between data-plane linear protection and control-plane protection that directly affects this issue - Since the PSC messages are being transmitted over the protection path in the data-plane, then if there is a SF-P condition, these messages cannot be transmitted, so that if there is a FS at this point - there would be no way to notify the far-end LER! Therefore, we are "forced" to up the priority of the SF-P to be higher than that of the FS! - Relationship to data plane behavior Section 3 briefly talks the "protection switching actions" that an LER may take, and that the "MEP SHOULD initiate a protection switch operation" (lines 417/8). But the document really stops short of defining what actions a local LER should take on particular state changes. It seems to me that required/recommended data-plane behavior should be explicitly (rather than implicitly) identified in section 4.3.3. [yw>] Not sure what your concern was here. To my understanding the data plane behavior of the LER consists of the following possible actions - 1. Transmit a PSC message indicating the current state (Req + FPath + Path) of the LER, 2. Decide where the data should be transported, i.e. either on the Working or the Protection path, and 3. Decide from which path to select the data. These actions are described in Sections 4.3.3.x, i.e. the PSC message is indicated in the bullets that explain the reaction to the input, the actions of where to transport (and select) the data is stated in the opening paragraph of each state, where (in some form or other) it states "When the LER is in this state, data is transported on ...". There was thought (amongst the authors) that the following statement in Section 3.2 was causing the concerns: " These remote messages indicate the status of the transport path from the viewpoint of the far-end LER, and may indicate if the local MEP SHOULD initiate a protection switch operation." And therefore we will change this to state: " Remote messages indicate the status of the transport path from the viewpoint of the far-end LER. These messages may drive state changes on the local MEP, as defined later in this document." Will this be acceptable? Minor issues - use of RFC2119 language [yw>] These were addressed in the previous exchanges - Line 612, 617: these are informative/narrative sentences s/MUST/must|will s/SHALL/are [yw>] addressed previously - Lines 629, 638: aren't these MUSTs? If not needs some explanatory text. [yw>] addressed previously - Line 643 missing "default": s/an/a default [yw>] addressed previously - Section 4.3.3: There are a lot of "SHOULDs" in this section. Given this text relates to the synchronization of state between peers, what happens when one peer implements the "SHOULD" and the other peer does not? In order to avoid implementations that are compliant with this document but can't interoperate, either this case needs to be covered or these "SHOULDs" need to be "MUSTs". [yw>] addressed previously - Lines 205-206: The meaning of "maintain traffic" is not clear. [yw>] addressed previously - Lines 215-217: suggest making it explicit (rather than implied) that 1:1 unidirectional and 1:n are "out of scope of this document" [yw>] addressed previously - Lines 225-219: so is support for 1+1 for P2MP in or out of scope? This section really should be explicit on this point. [yw>] addressed previously - Lines 353 and 354. draft-ietf-ccamp-mpls-tp-cp-framework and [SurvivFwk] allow for the use of [RFC4872] or [RFC4873]. Your draft excludes [RFC4873], is this intentional? If so, why? [yw>] addressed previously - Lines 400-403, 444-446. The definitions for local MS and remote MS are subtly different. 400-403 says "switched from the working path to the protection path". While 444-446 says "switch the traffic to the path that was not being used previously". While I personally prefer this definition, Section 4.3.3 seems to say that 444-446 should read "switch the traffic from the working path to the protection path". [yw>] addressed previously - Line 665. No definition is given for the "Reserved" field. A typical definition for such fields is "The Reserved field MUST be set to zero on transmission and MUST be ignored on receipt." [yw>] addressed previously - Lines 678-681. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? [yw>] After consultation - it seems that the feeling amongst the authors is to remain with only two bits as this would be rather disruptive for "early adoptions" of the standard that is already implemented and waiting for release. - Numbering consistency The document is inconsistent with how it indicates field values. Unless there's a sub-structure to a field, e.g., a flags field, values should be listed in decimal not in binary. Impacts lines 688, 692, 699, 708, 716, 723, 729, 737, 750-755. If these lines really refer to bit fields, then the bits need to be defined. [yw>] addressed previously - Line 732. Is DNR limited to transmission behavior only? If not, need to change this line. [yw>] addressed previously - Lines 742-760. Are 2 bits really sufficient for the long term? There are 23 unused bits in the header, perhaps you want to give one to this field? If there really is a need for future extensions (per line 755) then a wider field is really needed. [yw>] While there was less reluctance to widen this field, we were still advised not to include changes that might involve going back to the WG. In addition, it is not clear to me that there is a need for additional bits for this field. - Lines 774-784: How is the absence of faults indicated? Perhaps 0 or 255 should be used for this case? [yw>] addressed previously - Lines 820: strictly speaking this field is not part of "TLV information", also receive behavior is not specified (see comment on line 665 above.) [yw>] addressed previously - Lines 822-824, The TLV format definition is missing. (I.e. how big are the T & L fields, does L include T&L or not, are there any padding requirements...) [yw>] Since this document does not describe any TLV fields, just a placeholder for future ones - do not feel that there is a need to specify this information at this point, but rather leave it to the documents that may define specific TLVs. In answer to another point that you raise will request that IANA administer a registry of the future TLVs. - Lines 853, 856, 866: text is informative, should not include RFC2119 language. [yw>] addressed previously - Handling of PA:F:L/FS after SFC-P If for some reason the prioritization of FS and SF-P remain as is (see major issue above), the current state machine definitions result in a the FS state being lost when an SF-P is cleared. Consider the case of the following states and inputs (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)--> WTR--(WTRExp)--> WTR--(remNR)-->N As the operator set FS, shouldn't the state return to PA:F:L not N? - SF-P can mask SF-W Consider the scenario where the protection path fails and then the working path fails. As I read Section 4.3.3 and appendix a, the order of states and inputs (in parentheses) are as follows: N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0)) This seems wrong. When the protection path SFc is received shouldn't the result be a protection switch / PF:W:L (NR(1,0)? [yw>] These were addressed previously - Remote SF impacts protection switching when using unidirectional protection As I read section 4.3, a remote SF will impact the behavior of the protection bridge of an LER even when 1+1 unidirectional protection is being used. My understanding is that the bridges are supposed to switch autonomously in this mode. Did I miss something? [yw>] Will add statements as follows to clarify 1+1 unidirectional protection: 1. In Section 3.2 (Remote requests) at the end of the first paragraph: "When using 1+1 Unidirectional protection, an LER that receives a remote request SHALL NOT perform any protection switching action, i.e. will continue to select traffic from the working path and transport traffic on both paths." 2. At the end of the last paragraph of Section 4.3.1 stating: "For 1+1 unidirectional protection, the state of the selector will only be switched in reaction to a local message. When receiving a remote message, a LER that is configured for 1+1 unidirectional protection, will transfer to the new remote state, however it will continue to select data according to latest known local state." Will this clarify the protection actions for this protection scheme? - IANA Considerations, section 5 Don't you want an IANA registry for the TLV types that may be defined in the future per section 4.2.7? [yw>] Have added the request for an additional registry for the TLV types. Nits: [yw>] all addressed previously ------_=_NextPart_001_01CC46D8.BA555A14 Content-Type: application/octet-stream; name="tpFsmOnesided.xlsx" Content-Transfer-Encoding: base64 Content-Description: tpFsmOnesided.xlsx Content-Disposition: attachment; filename="tpFsmOnesided.xlsx" UEsDBBQABgAIAAAAIQDfiMhbiwEAAIAGAAATANoBW0NvbnRlbnRfVHlwZXNdLnhtbCCi1gEooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAMxVy07DMBC8I/EPka8ocVskhFDTHigcoRLlA4y9bawmtuV1X3/PJiEVoJCqSg9c GlXRzszO7k7G032RR1vwqK1J2TAZsAiMtEqbVcreF8/xPYswCKNEbg2k7ADIppPrq/Hi4AAjqjaY siwE98A5ygwKgYl1YOjN0vpCBPrrV9wJuRYr4KPB4I5LawKYEIcSg03GryTAawXRXPjwIgri4fuc B0KD+neYEB6LHuvCkjtlwrlcSxFIOd8a9Ys1tsullqCs3BTElVRgNyUK/5MQwyEH7E2FzoNQmAGE Ik9q0IZ5BkuxyUP0tCcHatM95Hhea19mJlRZtY+ZdtjB0O1dtyc769cf1q4v7UrpTlIIbRrdbUtA 05t765DTrHsLgNJyBSp2BAk+aDh61sZNC1j2Xo0RefUY9dbwczWO+F0etOi4/Sc6+l/lCT9armXb MweofubFjvKtIwikLcrQwEs32OCemDdmwoN6C55UXjyOvmN36TjenrQezl+4JqPK6paL49X3Y/IJ AAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAM4BX3JlbHMvLnJlbHMgosoBKKAAAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMks9O wzAMxu9IvEPk++puSAihpbtMSLshVB7AJO4ftY2jJED39oQDgkpj29H2588/W97u5mlUHxxiL07D uihBsTNie9dqeK2fVg+gYiJnaRTHGo4cYVfd3mxfeKSUm2LX+6iyi4saupT8I2I0HU8UC/HscqWR MFHKYWjRkxmoZdyU5T2Gvx5QLTzVwWoIB3sHqj76PPmytzRNb3gv5n1il06MQJ4TO8t25UNmC6nP 26iaQstJgxXznNMRyfsiYwOeJtpcT/T/tjhxIkuJ0Ejg8zzfinNA6+uBLp9oqfi9zjzip4ThTWT4 YcHFD1RfAAAA//8DAFBLAwQUAAYACAAAACEA3gn9KAIBAADUAwAAGgAIAXhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJPPasMwDMbv g72D0X1xkm5llDq9jEGvW/cAJlHi0MQ2lvYnbz+TQ7pAyS6hF4Mk/H0/0Kf94afvxBcGap1VkCUp CLSlq1rbKPg4vT48gyDWttKds6hgQIJDcX+3f8NOc/xEpvUkooolBYbZ76Sk0mCvKXEebZzULvSa Yxka6XV51g3KPE23MvzVgGKmKY6VgnCsNiBOg4/O/2u7um5LfHHlZ4+Wr1jIbxfOZBA5iurQICuY WiTHySaJxCCvw+Q3hsmXYLIbw2RLMNs1YcjogNU7h5hCuqxq1l6CeVoVhocuhn4KDI31kv3jmvYc Twkv7mMpx3fah5zdYvELAAD//wMAUEsDBBQABgAIAAAAIQDgMJ9XXgEAAHECAAAPAAAAeGwvd29y a2Jvb2sueG1sjFLJTsMwFLwj8Q+W7zRbE6BqUgkBoheERKFnE780Vh07sh3S/j3PrrpIcOD0tslk ZpL5YtdJ8g3GCq1KmkxiSkDVmgu1KenH6vnmjhLrmOJMagUl3YOli+r6aj5qs/3SekuQQNmSts71 syiydQsdsxPdg8JLo03HHI5mE9neAOO2BXCdjNI4LqKOCUUPDDPzHw7dNKKGR10PHSh3IDEgmUP5 thW9pdW8ERI+D44I6/tX1qHunaREMuueuHDASzrFUY9wXuSUmKF/GIT01zwuaFSdTL4ZwqFhg3Qr tHdkx7zSaZoGpI/iU8Bozw/5kezWQnE9eihGuz9OBQ5juKwFdy2es+weJRx2LyA2rcNlUkxjryO6 oA8B4mtCJSq4e/ehJvilfF2iAezNTGBjljzxDL/Q6QUa+xM6/ROdXaCxP6GzoC6Qo6SayRqj8iWI SPPbNA+I499S/QAAAP//AwBQSwMEFAAGAAgAAAAhAOmmJbiCBgAAUxsAABMAAAB4bC90aGVtZS90 aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6 YZcBu+0wbCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56 iMQ+H9M4aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCEx zE24iLCCVxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue 1jRCzmWXCXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda 69dbV3Zy+gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FK ZbFEDcg+1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w4 2y2FbwB8o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa 0ryQ9AVNVNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/ nn7z8vEX5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQz hnElJyNxvhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0u Sg1wQ/MqWHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq 2HWP+oJLPlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8Tqe KRyVkRziiBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNz XkTu8Gk3xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpkJ7Uso 1E79jWj8d8WYUajGNgbeFeO2tw1bU1lK7J4owatw/8HCu4Nn8T6BWF/eeN7V3Xd113vr6+6qXD5r tV0UWKi9unmwfbHpkqOVTfKEMjZQc0ZuStMnS9gsxn0Y1OvMAZHkh6YkhMe0uDu4QGCzBgmuPqIq HIQ4gR675mkigUxJBxIlXMLZzgyX0tZ46NOVPRk29JnB1gOJ1R4f2+F1PZwdDXIyZssJzPkzY7Su CZyV2fqVlCio/TrMalqoM3OrGdFMqXO45SqDD5dVg8HcmtCFIOhdwMpNOKJr1nA2wYyMtd3tBpy5 xXjhIl0kQzwmqY+03ss+qhknZbFiLgMgdkp8pM95p1itwK2lyb4Bt7M4qciuvoJd5r038VIWwQsv 6bw9kY4sLiYni9FR22s11hoe8nHS9iZwrIXHKAGvS934YRbA3ZCvhA37U5PZZPnCm61MMTcJanBT Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEK2Eh/DSnWNyAY/jUpwI6ua8lkQnxVdHZhRNvO vqallM8UEYNwfIRGbCYOMLhfhyroM6YSbidMRdAvcJWmrW2m3OKcJl3xAsvg7DhmSYjTcqtTNMtk Czd5nMtg3grigW6lshvlzq+KSfkLUqUYxv8zVfR+AtcF62PtAR9ucgVGOl/bHhcq5FCFkpD6fQGN g6kdEC1wHQvTEFRwn2z+C3Ko/9ucszRMWsOpTx3QAAkK+5EKBSH7UJZM9J1CrJbuXZYkSwmZiCqI KxMr9ogcEjbUNbCp93YPhRDqppqkZcDgTsaf+55m0CjQTU4x35waku+9Ngf+6c7HJjMo5dZh09Bk 9s9FLNlV7XqzPNt7i4roiUWbVc+yApgVtoJWmvavKcI5t1pbsZY0XmtkwoEXlzWGwbwhSuDSB+k/ sP9R4TP7cUJvqEN+ALUVwbcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTpq2Ttlq2WV9wp5vzPWFs LdlZ/H1OY+fNmcvOycWLNHZqYcfWdmylqcGzJ1MUhibZQcY4xnzVKn544qP74OgduOKfMSVNMMFn JYGh9RyYPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAvKsJMdYAAAC4AQAAIwAAAHhsL3dv cmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJDLagMxDEX3hf6D0T7WTBahlHiyCYVsQ/oB wtY86PiB5abJ39eh0HYg0E13ki46Omi7u/hZnTnLFIOBVjegONjopjAYeD29rJ5ASaHgaI6BDVxZ YNc9PmyPPFOpSzJOSVSlBDEwlpKeEcWO7El0TBxq0sfsqdQ2D5jIvtHAuG6aDebfDOgWTHVwBvLB rUGdrqle/psd+36yvI/23XMod06gjf4WSWVSHrgY0Pp72OrqCnhfo/1PjbOf95k+6o8XIu5rJviT t7rWNydc/Lv7BAAA//8DAFBLAwQUAAYACAAAACEAuEpLLRMBAAC3AQAAGAAAAHhsL3dvcmtzaGVl dHMvc2hlZXQyLnhtbIxQwUrEMBC9C/5DmLtNV1mVpe0iLIseBBH1nm0nbdgkE5JZV//etGUXwYu3 eXlvXua9av3lrPjEmAz5GhZFCQJ9S53xfQ3vb9urexCJle+UJY81fGOCdXN5UR0p7tOAyCI7+FTD wBxWUqZ2QKdSQQF9ZjRFpzjD2MsUIqpuWnJWXpflrXTKeJgdVvE/HqS1aXFD7cGh59kkolWc70+D CQmaqjOZGwOJiLqGhwXIppq+/TB4TL9mMabYEe1H4qmroRyl8o92O6V4iaJDrQ6WX+n4iKYfOFe2 PLtvFKu8HlSPzyr2xidhUWdNWdyBiLN+mpnC9LoEsSNmcic05IIwF1EWNyA0EZ/AeNa58uYHAAD/ /wMAUEsDBBQABgAIAAAAIQC4SkstEwEAALcBAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDMueG1s jFDBSsQwEL0L/kOYu01XWZWl7SIsix4EEfWebSdt2CQTkllX/960ZRfBi7d5eW9e5r1q/eWs+MSY DPkaFkUJAn1LnfF9De9v26t7EImV75QljzV8Y4J1c3lRHSnu04DIIjv4VMPAHFZSpnZAp1JBAX1m NEWnOMPYyxQiqm5aclZel+WtdMp4mB1W8T8epLVpcUPtwaHn2SSiVZzvT4MJCZqqM5kbA4mIuoaH Bcimmr79MHhMv2YxptgR7UfiqauhHKXyj3Y7pXiJokOtDpZf6fiIph84V7Y8u28Uq7weVI/PKvbG J2FRZ01Z3IGIs36amcL0ugSxI2ZyJzTkgjAXURY3IDQRn8B41rny5gcAAP//AwBQSwMEFAAGAAgA AAAhAOgQxbMDBgAALBcAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWyUWNuO2zYQfS/QfxD0 XtuyrLVNrDew7gHSIkh6eVZs2hZiW66k3U369T0UZUnksKv0ZbU+c4acCzkc8vHdt8vZeuFllRfX je1MZrbFr7tin1+PG/uP3+NfVrZV1dl1n52LK9/Y33llv3v6+afH16L8Wp04ry2McK029qmub2w6 rXYnfsmqSXHjV0gORXnJavwsj9PqVvJs3yhdztP5bPYwvWT51ZYjsPJHxigOh3zHw2L3fOHXWg5S 8nNWw/7qlN8q++lxn0MmHLJKftjYW4elc9eePj02U/+Z89dq8L9VZ18+8zPf1XyPCNjWP0Vx+bzL zvB2jXB0P38TrpwlKLz/UhRfxWDvoTbDtLfsyq1vn2/nvMY4cxe6dXH7wA91wM/QizF2tqvzF/4R zI0N4af8eKobyxoDhMmSITW2HoL/t3TCU2lissEQilrqLDs98T88n3auD/+/hyFukvSxtPb8kD2f 60/Fa8qFafCjmXdXnMHFX+uSY5nMbeuSfWu+r/m+Pm1sz5vMV57jPcxh8u65qovLX1LiiOk7TbfV xLfVdNcTZzEb01u0evjeZ1xMFnNvuXJGZoQ9ja34/q8ZH1o9fFu9xWziLWfu2ISIfTMhvvcJH37E RWy0Rg/fu4vOZOV5i4fV0hjUqcxKk9kwq7Onx7J4tbCLsM4qrA/sSYetsDB3AtwKtEkZsip2ycvT 8nH6guWwaxk+GJ1spsqCocxRZeFQNldl0VDmqjKxH7r5FqosGco8VZYOZQ+dbArvuxBghRpCINCN 3ZQChY3VaGAD7czTwuELDTWYjuZdYKBojoSUMtdyElHKuvO4yWtMGY5mbWKgaDlMKWX+H6HFFqTB 8gUqAiI2u1hugQSaWDdAqAORDsQ6kOhAOgCUBGJ/UJtE9ewSqPnrC41mp3SMlRrXQDIQl47haIs0 lBQY1VP6oDVeR5KChddTtBTHBopmS2KgaMsgpZR5v9yUYKGi0WD5AlUSKIFBAiUgzwOR4khnxDqQ 6EA6ABSbxIFFSxbQLmxaYfGFxtsJHGWEkjFM8VzbOpGkDPM315ZSbKBoxiYGilYuUgOlX25KrERH RmLlC1TJnw6EEugTGulArAOJDqQDQLFpbbJpC7TLn+avLzTezt8oIxxlRJKhZFjbW7GkKBnW9lZC Ka62TlIDpV8nSqgc9IWG/DWwkkCChASJWqRPakyQhCDpEFFtw9FKbds6wxO3X5VNhfOFcCST45Rw nBKNU+KWMsy3q+/FljNMuKstztTE6f1WQ4aBaMh8R8BqOnUkJJyIIHGL9AlOCJIOEdU2BILatnWG 8ekPiTadQuftjSn036aE45RonBKPU5KWMvTI1VxKW46S8f6cViMmOgxaXB3ZeAzaG4KEBIkIEhMk aZE+v+kQUW0TRzyxbYsbWl9le7fabMq2YLh/tfoXCP2xbI5SovFR4nFKMk5JO4q41Q5bfkf0FiQ8 fgOrG1E2IX0yQ8KJCBITJCFIOkQU2/D8cLfNZe79ShYIuDsgnb5QSV15Z5c3uwsvj1w8ClTWrni+ QskTTw4dLF86UpehRUZgNNz3GPo7igceC0x46LHQhEceQ9NHx4k9ht6P4onH0AJSPPUYOkGK+y7D RYLigctwn6B46DJcKygeuQy3C4rHLsMlg+KJy3DXMOCOw0S9pZJ0ydALUdxfMx+nKxUEaxYYBeGa iXOdakRrJo53KojXTJzyVJCsYa1JkK6ZOPOphr9kaBwpHixZYMLDJUMbSfnRkqGbpHi8ZGgqKZ4s GXpLiqOZQPxMAQ8gCYwStA6IoEkHHQNCaJKgUUAMTRLUF8TKtDi3DtuaNHxoiCpDvUFphc0mSQiJ qDpUB4UUNpskqJ+w2SRB2UTiTRI0MvDGbDX2Go4aakHgYLcZJTjVYbVJB4c5rDZJcIbDapMERzes NklwYMPqRjLtKhneH2/Zkf+alcf8WllnPKvi2XWCa1MpXyqb//Gm2qA4sL4UNV4h779OeHnmuLTO Jqi5h6Ko7z8QgDM/ZrvvYZm94tXbKlm+39jl+33zcjnt3rmf/gUAAP//AwBQSwMEFAAGAAgAAAAh AHuDqmBkAgAAhwQAABsAAAB4bC9kcmF3aW5ncy92bWxEcmF3aW5nMS52bWyMVMtu2zAQvBfoPxDM wZcotpjmUVoSEKTIrQ3QFugxoEXaYkJxBXEty/n6LiU5doqiqGCZ5D6GO7MLZX3tGL0+yC7n29bL UFamViGpbdlCgDUmJdSyqx3/+GGKhH9FwnptSyPH5ZjT/0eO6UvjeEH3ZCBDpRrj1B62yDppesy5 0RYHd/RbXavmnYdphSrnKZ8PEPN3GEXWjZC4bwyzOudP/YKeJxQLwVkJ0OpgX03ORXq9WJwP/5wR RkM3xxgqizUKq5zX5270t2OsG5feTMXRTdjCi2HPYH3AvSPU2qJpx8oYlRKB2KZV2hqPA1V4yTnG C0vw3pQY68x5S7sDnxMCb2xOmYR0Ia44GxPP3tEbi5g1ECxa8FKtArgtmmUkVat2Y33izBpl+vm2 weVkQWjkpRAXV2TaWY2VvLwRFzfxWBm7qVCKT7cXIp4jzmtivTa9TJedDXZlncW9rKzWxi/rAMmu VU0yVCIxZs/Y2jpXgoM252drekw6qEzN9cFgDZoUUFuEN11jAvWKMsQxZWh3FJV01LBj4AclJ+CV U+UL6boK5bY11PdJz7cu/KG4B2+OfUIavBX0bBIw0tA2NoVUTJRDGcubxXljLNO2OwTGPPLbjZdR 11mRzck7xGXzTk6w47mX9y6OwRcaX/a4eib0n0PzvwFOI8WyXn6FzvyyWN0b58LIOZp/0ND+xXzn ywrasTCWnjNBM80EbVJaL+l3Te8tHbN5L0+DCfKOOD2Q0sWDcsEMAQfLSLSX32FXCBFdcXew3tNQ 1b4Y7NM+umLYkWKMjhoMU0+60Nen+A0AAP//AwBQSwMEFAAGAAgAAAAhAFnWmFnPAQAAMAkAABQA AAB4bC9zaGFyZWRTdHJpbmdzLnhtbKyWXU/CMBSG70n4Dye9MJowNtSo0W3Gj+xKkQCG67pVtoS1 uFMI/Hs78APLZqnCBWE9p0/Pec/bBf96kU9gzgrMBA9Ip+0RYDwWScbHAXkeRs4FAZSUJ3QiOAvI kiG5DpsNH1GC2ssxIKmU00vXxThlOcW2mDKuIq+iyKlUj8XYxWnBaIIpYzKfuMeed+bmNOMEYjHj MiBnpwRmPHubsbv1wsk5CX3MQl+G3b7vytB3y6f1yv320mi4lfU40PcNIn0l2sp5eNJzKDiOczCW V83GHF70qIo5zUb5rUduABlPEB4Hh51W5wiUhpBQSUFw6LWajduPeLf/IzSq4wyi/XCif9bDhWRY V2S3f+i1vCMQBax+an2PykCvBTSORVF6bLJcKZEIhiBTBkhz1tbht0KmgFmickpJQc1fnaKhe/qu T/2rs38ZwKrGOpoyWsXZG7Tq4+pwJnPY0UwWsaOZjLIbTR9etYB/1ceOZtLHjmbSx4728LS+OZuv idGGr/ZL2212n1fIVJv9ra+bd3WXGzL8/yjdkJVXsK4+k4OsYCYDWcFMM9oJpmtT2W6dNqZ2rGCm dnaC6e1UVqi3s/j64CssvqOu+scTvgMAAP//AwBQSwMEFAAGAAgAAAAhAIPoYPwDAwAA0AgAAA0A AAB4bC9zdHlsZXMueG1s1FZLb9swDL4P2H8QdE/tuEmbFHGKJamBAV1RoBmwq2zLjgBZ8iS5czrs v4+SH3HfxdAedokpiqS+jyKpLM7rgqNbqjSTIsTjIx8jKhKZMpGH+Ps2Gs0w0oaIlHApaIj3VOPz 5edPC232nN7sKDUIQggd4p0x5Znn6WRHC6KPZEkF7GRSFcTAUuWeLhUlqbZOBfcC3z/xCsIEXi4y KYxGiayECfGkVSwX+g7dEg64xthbLhLJpUIGwgMQpxGkoI3FmnAWK2bNMlIwvm/UgVU4RK1dwYRU VunZI5uDnz5H5XGIo2i+9gGn9Xjvw+Y2aMOJiZTWNA3x7AGtLdnJgljDR6zuEYjBokvW+8R14TWc yzjvb+bY3gwolouSGEOViGCBWnm7L+FeBJSJxes1dq9Y54rsx8H07Q5acpZaFPnaVUN7S1G0Pl1f uDADZD0KBwbIxFKlUOtdoY0hUKNaLjjNDMBWLN/Zr5El/MbSGFmAkDKSS0E4iF7n0QoQNqGc39h+ +JH1sQOIXWdIVEVUmK9wtdBZtuQ6ERLXik28ZgHxn3Mag3/rFGA0dEKkLPn+qipiqiLXbu40p105 xof1F85yUVDbZgDImVwraWhi3ADwXQqHfBp2A2In/0QM1dmrDG2Gnk5L741+VgD2WtGM1XYGNAwG pOyVwihoOKKdVOwOkm5nSAKkqcLolyLlltaQANdrXp09n/O3IHI5/L8Q2Cp+ifYLpdZc44cn/kMQ dLQ9W99Q0YPGvde2ffkjO/JDvCIpbisQcMUV44YJW83BqW2Xh+ZXtgV55wElNPB40F8AIa0PM8Pt GhLDw2qnSQ8KYqQ0IxU3234zxAf5G01ZVcBUaK2u2a00LkSID/KlHW1j95RB+V9qeP3giyrFQvz7 YnU631xEwWjmr2ajyTGdjubT1WY0naxXm0009wN//Qc42af+rB5PHj33BUuU1DIzRwlMTJllLKGP H/y5N++efAhypjlYqZZsC/7moAvxYNHAd/MJYEMFdyQ83f8VWf4FAAD//wMAUEsDBBQABgAIAAAA IQDbPaoo9AEAAG8DAAAQAAAAeGwvY29tbWVudHMxLnhtbKxSTYvbMBC9B/IfBp264EZJSpdtiJPD dgOlHwmblO51Yo9tUVkyGsWb3V/fcZykLPRYEEJvNPPek2bmy2NtoaXAxrtUTUZjBeQynxtXpurn bvX+TgFHdDla7yhVL8RquRgO5pmva3KRQQgcp6qKsZlpzVlFNfLIN+TkpvChxigwlJqbQJhzRRRr q6fj8a2u0Ti1mOMhVj7w5bB4CCaDNe99cDTX/e3icpC0s/Y3w/EKIFCRqvvpBwV9wZc8VWMhj3SU rCBrI9teL+b8Ci3aVH1SAjJvfQDjcjqSVNxNumBYeRf7pB1WvsYuWGBt7EsfnXYBfWKMb+zO5lrU dCd3VvzPat1/z7jBTJohH8oUWlLSkK1xGUGsDIOsyWySwO4JvBPHJP0FJpezYAI2pUM7Anh8ggMT Q2n9Hi1Y3JOFE3UCpgATAbOMGunxc4WxwyUJCFRiyC2x0BWw3Xx/EFlyUJuyir0DtBaeffgN66/L 4WA4+NXV494fIqw2yUZSWcYiq5YAa3Ek1s7+fjy+Gyfjm6RjBC/bxfjpYnIjrreVP9gc9gSFkdrS tKL9rycgd5ItjToH9ySWPn/UtzNAyLwrTHl1kQD3nBW2JMTCl+GhewxhsIbCX1V3+ssKGxnv0bXV up8xfZ5L6f+bCb0gXvwBAAD//wMAUEsDBBQABgAIAAAAIQBiqp0ObwEAAIcCAAARAAgBZG9jUHJv cHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEkl1PwjAYhe9N /A9NrzRxtGMEtdlG4gfBBNAEjB93tX2Bxa1d2srHv7cbMCGaeNme8z49503j3rrI0RKMzbRKcNii GIESWmZqnuDnaT+4wsg6riTPtYIEb8DiXnp6EouSCW3gyegSjMvAIk9SlokywQvnSkaIFQsouG15 h/LiTJuCO380c1Jy8cnnQNqUdkkBjkvuOKmAQdkQ8Q4pRYMsv0xeA6QgkEMBylkStkLy43VgCvvn QK0cOIvMbUrfaRf3kC3FVmzca5s1xtVq1VpFdQyfPySvo+GkrhpkqtqVAJzGUjBhgDtt0nuTCfRo P7RREJMDoVpizq0b+X3PMpA3m/QF/Oa5caAu0BvnQi/R2XgyRgF6GJKBlmjAJwtutDqPye9p/2pd cvs0SORjs23JvfIS3d5N+zht0zAMaDeI6DTssE7IaPe9Cnc0X9XYXhS7iP8SL4M2ndJrRiMWRQfE PSCtcx9/nfQbAAD//wMAUEsDBBQABgAIAAAAIQDQZNZ6owEAAFoDAAAQAAgBZG9jUHJvcHMvYXBw LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTTWvcMBCG74X+B6Fzs/Ju SimLrFA2LSm0dMGb9KzI47WILQnNxKz76yvbOOvtxyU6zcw7vDyakeTNqW1YBxGtdzlfrzLOwBlf WnfM+f3hy9VHzpC0K3XjHeS8B+Q36u0buY8+QCQLyJKFw5zXRGErBJoaWo2rJLukVD62mlIaj8JX lTVw681zC47EJss+CDgRuBLKq/BiyCfHbUevNS29Gfjw4dCHBKzkpxAaazSlW6rv1kSPviL2+WSg kWIpykRXgHmOlnqVSbFMZWF0A7tkrCrdIEhxLsg70MPQ9tpGVLKjbQeGfGRof6WxbTh71AgDTs47 Ha12lLCGtikZ4yYgRfXTxyesAQilSA1TcQyXvcvYvlfXY0MKLhsHgwkkCZeIB0sN4I9qryP9g/h6 STwyTLwTTjHwrZd8L6SjtPm/NJEubzUOKvH9QbTzbdCuVzuLxrOiR4IW37GvzqykmEX5zbonvA8H f6sJ5r1cFmVR6whlWuWsnwvyLq0kNoPJrtbuCOXc87cwvKKH6auo9WaVpTM+nrkmxflTqN8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAN+IyFuLAQAAgAYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAACWAwAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA3gn9KAIBAADUAwAAGgAAAAAAAAAAAAAAAACCBgAA eGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHNQSwECLQAUAAYACAAAACEA4DCfV14BAABxAgAADwAA AAAAAAAAAAAAAADECAAAeGwvd29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhAOmmJbiCBgAAUxsA ABMAAAAAAAAAAAAAAAAATwoAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAvKsJ MdYAAAC4AQAAIwAAAAAAAAAAAAAAAAACEQAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1s LnJlbHNQSwECLQAUAAYACAAAACEAuEpLLRMBAAC3AQAAGAAAAAAAAAAAAAAAAAAZEgAAeGwvd29y a3NoZWV0cy9zaGVldDIueG1sUEsBAi0AFAAGAAgAAAAhALhKSy0TAQAAtwEAABgAAAAAAAAAAAAA AAAAYhMAAHhsL3dvcmtzaGVldHMvc2hlZXQzLnhtbFBLAQItABQABgAIAAAAIQDoEMWzAwYAACwX AAAYAAAAAAAAAAAAAAAAAKsUAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAA ACEAe4OqYGQCAACHBAAAGwAAAAAAAAAAAAAAAADkGgAAeGwvZHJhd2luZ3Mvdm1sRHJhd2luZzEu dm1sUEsBAi0AFAAGAAgAAAAhAFnWmFnPAQAAMAkAABQAAAAAAAAAAAAAAAAAgR0AAHhsL3NoYXJl ZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAIPoYPwDAwAA0AgAAA0AAAAAAAAAAAAAAAAAgh8A AHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEA2z2qKPQBAABvAwAAEAAAAAAAAAAAAAAAAACw IgAAeGwvY29tbWVudHMxLnhtbFBLAQItABQABgAIAAAAIQBiqp0ObwEAAIcCAAARAAAAAAAAAAAA AAAAANIkAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQDQZNZ6owEAAFoDAAAQAAAA AAAAAAAAAAAAAHgnAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAPAA8A5AMAAFEqAAAAAA== ------_=_NextPart_001_01CC46D8.BA555A14-- From william.allen.simpson@gmail.com Fri Jul 29 09:18:59 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C304721F8B14 for ; Fri, 29 Jul 2011 09:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_REALLY=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nlAjqnrj4CZ for ; Fri, 29 Jul 2011 09:18:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0F4921F8764 for ; Fri, 29 Jul 2011 09:18:52 -0700 (PDT) Received: by iye7 with SMTP id 7so5054779iye.31 for ; Fri, 29 Jul 2011 09:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5Fui9NozgsisAbdGNpgkuGVlNK5HNEULMjKoehmQ7tc=; b=dQRUBQg/9ftRayOI2zaoTS3E3vVdxL9p5tg4y5d1YzMzcrxvp8yWnf0+pQQUhinqkW sC3Q6uo2a+C7BAX3w/e3GS5pEg9RFQbsYyjKjDRQajsfyiTDuhVql9eia6aCu7kmjjvJ ROX5t2nevho02GSf2v4tzmE1mfxnLyohQPJgU= Received: by 10.231.112.93 with SMTP id v29mr971189ibp.133.1311956332395; Fri, 29 Jul 2011 09:18:52 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id q4sm1430744ibb.32.2011.07.29.09.18.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 09:18:50 -0700 (PDT) Message-ID: <4E32DD68.2030606@gmail.com> Date: Fri, 29 Jul 2011 12:18:48 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E32AD55.9060300@joelhalpern.com> In-Reply-To: <4E32AD55.9060300@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Jul 2011 10:29:42 -0700 Cc: "rtg-dir@ietf.org" , draft-simpson-isis-ppp-unique.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-simpson-isis-ppp-unique-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 16:18:59 -0000 Thanks. It's about (beyond) time! This was sent to the Routing ADs in April, and entered the IESG TimeOut (30 days) in May (expired June 22nd). While I appreciate that Joel took the time to read this, and do a bit of writeup, it would also help had he had a lot more implementation and operational experience. He makes a number of egregious mistakes. Sadly, this response is longer than the original internet-draft. It's just about the shortest and simplest draft I've ever written. I'd prefer not to clutter it with minutiae. On 7/29/11 8:53 AM, Joel M. Halpern wrote (and it would have been nicer with folded lines, so I didn't have to fold them manually): > Major Issues: > The modification to the IS-IS message exchange behavior which is section 3 of this document should be removed. It is not necessary for the primary goal that the document states it is concerned with. This is not true. The "primary goal" is clearly indicated by the title and abstract: "Generation of Unique IS-IS System Identifiers" "When no unique MAC is available, this document specifies automatic generation of identifiers." "Additionally, the extension automatically resolves conflicts between System Identifiers." Section 3 is intimately concerned with such generation, as it detects they are "unique". Without section 3, conflicts will not be automatically resolved. Any protocol specification that does not handle conflict resolution is incomplete, and demonstrates poor error recovery. The only mention in ISO10589 merely says: If the ID is chosen from the ISO 8802 48-bit address space (represented as a sequence of 6 octets as specified in ISO/IEC 10039), the ID is known to be globally unique. This is well known to be false, as mentioned in my document! ... drastically reduces the possibility of duplicate NSAP addresses, which are illegal, difficult to diagnose, and often extremely difficult to isolate. While we don't use NSAPs, this is also true of System Identifiers! The existing ISO10589 document does not autonomously resolve conflicts, resulting in the need for this document. > Existing practice already recognizes that collision can > occur, and provides for what responses should be taken. Please point to the exact document(s) and section(s) that specifies where "collisions can occur", automatically resolves the conflict, or details any response what-so-ever. As shown above, the ISO document blithely assumes that IEEE addresses are unique. They are not. They never have been (going back to thicknet cables). Problems have been made worse by multimedia bridges and huge multi-thousand device cable network nodes. As I mentioned on the PPP list, last summer it took me a very long time to diagnose a conflict between D-Link devices over a Comcast network. The political campaign had no way to know why their stuff didn't work (worked intermittently). It was an irritating mess. There's no reason that non-technical staff should have to know any of this! I have high hopes that TRILL will fix these problems. This document was written with PPP and TRILL in mind. It may help other groups, too, but that is not my principle concern. > More importantly, the specification provided does not actually solve the problem it claims to solve. > 1) It claims to handle System-ID collision, but in fact describes only the case of detecting a collision with a neighbor. Joel is r-e-a-l-l-y stretching on this item. Semantic silliness. Detecting a collision with a neighbor is the only case that matters. Obviously, there is no desire nor intent to generate unique identifiers for nodes that are on the other side of the world or entirely disconnected from the 'net. I suppose this objection could be handled by expanding the title: Generation of Unique IS-IS System Identifiers within a routing area, where the routing area is limited to adjacent nodes or bridged nodes Not! > 2) The text does not describe how to actually detect collision, since return of ones own LSAs is valid and expected behavior under various circumstances. This comment assumes that "ones own LSAs" will not be recognized. If that were the case, then multiple interfaces per node would fail on the same link, across different bridge's links, and across L1 and L2 areas. Perhaps Joel could refresh his memory on the meaning of "neighbor". (Speaking as the original author of "Neighbor Discovery".) Also, I refer him to the many uses of "neighbor" in ISO10589, RFC-3277, RFC-5305, RFC-6213, etc. They all manage to use the term without an explicit definition, because we all know what the word means in a networking context. > 3) It then replaces the collision problem with a proxy "failing to resolve participation in an area within 10 seconds", which is not itself well defined. And which is NOT the same as a System-ID collision. In fact, a System-ID collision does not cause a > result that can reasonably be mapped to "failure to resolve participation in an area" > At this point, I call bullshit! The paragraph reads in its entirety: After detecting a conflicting System Identifier in a neighbor, or receiving 3 or more IS-IS Hellos and failing to resolve participation in an area within 10 seconds, an implementation conforming with this specification MUST generate a replacement System Identifier using one of the techniques specified above. In fact, the two clauses taken together are exactly the test needed. There is a "tell me 3 times" and a timeout. Indeed, the lack of them both is often an indicator of poor protocol design. Instead of detailing all possible current (which are already in many other documents) and _future_ error conditions, the test relies on the one thing that all IS devices *MUST* follow: 3 Hellos in 10 seconds. In my first (private) draft, I'd used 30 seconds, to cover all ES devices. But early reviewers indicated that was not necessary. > Minor Issues, which still need attention: > In defining the construction of the system I-D this draft specifies that the "locally-assigned" and "broadcast/multicast" bits are to be set in the system I-D. As far as I know, the first of these is correct. The second one, setting the group bit in the > OUI, seems to be an inappropriate use of that bit, in the hope that no one else will have made the same abuse. > Currently, there are a number of ISIS devices that have manual assignment, but do not set the locally-defined bit. This existing behavior is wrong. This specification mandates correct behavior. Thanks for noticing. The usual IETF method of assigning unique OUIs that are not sources or destinations on the network use the "group" bit in addition to the locally-defined bit. It's a practice that *I* started circa 1992, so I'm fairly familiar with it. I know it's impossible to keep up with all the RFCs. But I'd kinda expected that Joel would know about techniques we've used for 20 years.... > Given that existing behavior allows a system to specify its system-ID in a local fashion, that dimension of the spec does not violate the existing documents. However, the description in the document would lead the reader to conclude that there were no > existing solutions to the problem of an IS-IS participant without a usable MAC address. While one might well dislike the existing practice of manual configuration, it does exist and does address the problem. This document should recognize that. > The "Configurable System Identifier" section is devoted to manual configuration. Did Joel actually read the entire document? However, manual configuration does not address the problem of detecting conflicts nor ensuring uniqueness. That is also mentioned in the Security Considerations. Did Joel actually read the entire document? > Re-summarizing: If section 3 is removed, and the lesser issues are addressed, this would appear to be an acceptable experimental independent submission. > From william.allen.simpson@gmail.com Fri Jul 29 09:23:15 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534215E800A for ; Fri, 29 Jul 2011 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4VRUAuYn4ee for ; Fri, 29 Jul 2011 09:23:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3921721F884E for ; Fri, 29 Jul 2011 09:23:07 -0700 (PDT) Received: by gxk19 with SMTP id 19so3182766gxk.31 for ; Fri, 29 Jul 2011 09:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=c9P6DzychB0SdtRKC8VZmNSHakN5rfQL74NqrBQxbdo=; b=iZZzRYEZWl//qOdfzHKr2T7SENbceF3ro5Is7SYkftsnsHAGFCz5FB+Ra4DcmcI13Q J5t8Urk/GU5p5GdOyOXp5GNGaqpdEooZPObns4eIYa0/H29/vR2wnInw/zQ5yNI6ADtq 01nHqmOBpU6wWj/ZFktRKhfbcJbG8BeKTEqQY= Received: by 10.43.51.73 with SMTP id vh9mr1136880icb.256.1311956586313; Fri, 29 Jul 2011 09:23:06 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id er13sm1429814ibb.53.2011.07.29.09.23.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 09:23:05 -0700 (PDT) Message-ID: <4E32DE67.9040202@gmail.com> Date: Fri, 29 Jul 2011 12:23:03 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E32AD55.9060300@joelhalpern.com> <4E32DD68.2030606@gmail.com> In-Reply-To: <4E32DD68.2030606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Jul 2011 10:29:42 -0700 Cc: "rtg-dir@ietf.org" , draft-simpson-isis-ppp-unique.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-simpson-isis-ppp-unique-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 16:23:15 -0000 On 7/29/11 12:18 PM, William Allen Simpson wrote: > Perhaps Joel could refresh his memory on the meaning of "neighbor". (Speaking > as the original author of "Neighbor Discovery".) Also, I refer him to the > many uses of "neighbor" in ISO10589, RFC-3277, RFC-5305, RFC-6213, etc. They > all manage to use the term without an explicit definition, because we all know > what the word means in a networking context. > Correction. I missed ISO10589 section 3.6.2: neighbour: An adjacent system reachable by traversal of a single subnetwork by a PDU. Radia was really thorough as always.... :-)