From dimitri.papadimitriou@alcatel-lucent.com Sat Sep 1 12:47:21 2012 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 2018611E8112 for ; Sat, 1 Sep 2012 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.308 X-Spam-Level: X-Spam-Status: No, score=-8.308 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8, SARE_UNSUB22=0.948] 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 XUxOQTDc-sym for ; Sat, 1 Sep 2012 12:47:20 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 538BF11E80F1 for ; Sat, 1 Sep 2012 12:47:19 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q81JlGD0031131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 Sep 2012 21:47:17 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 1 Sep 2012 21:47:16 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Date: Sat, 1 Sep 2012 21:47:16 +0200 Thread-Topic: [RTG-DIR] Routing directorate Gathering / Social Atlanta Thread-Index: Ac2GwYnzZWh0ab4zQS6gVAVjtgkFTABDJyYw Message-ID: References: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> In-Reply-To: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [RTG-DIR] Routing directorate Gathering / Social Atlanta 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, 01 Sep 2012 19:47:21 -0000 Good idea. IMHO, Wed. after the admin.plenary is the most=20 appropriate timing. Q: Do you know any original place nearby the IETF venue ? Thanks, -dimitri. > -----Original Message----- > From: rtg-dir-bounces@ietf.org=20 > [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, August 30, 2012 17:10 > To: rtg-dir@ietf.org > Subject: [RTG-DIR] Routing directorate Gathering / Social Atlanta >=20 > Hi, >=20 > Stewart and I think it would be both nice and useful for the=20 > Routing Directorate > (and their saintly secretaries) to all meet up in Atlanta. After some > discussion, we think that dinner would be more social than=20 > business, and that > seems entirely appropriate. No evening at an IETF ever works=20 > well for everyone, > but we would like to suggest Wednesday after the=20 > Administrative Plenary. This > will conflict with the WG chairs' beer evening, and we will=20 > understand if some > of you want to run off early or skip the directorate dinner=20 > completely. >=20 > Not taking reservations yet, but can you let us have opinions=20 > on whether you > think meeting over dinner would insufferable or not, and=20 > whether Wednesday is > particularly bad (not for you personally, because no evening=20 > will work for > everyone, but for the wider world). >=20 > Thanks > Adrian and Stewart >=20 >=20 >=20 > = From adrian@olddog.co.uk Sat Sep 1 13:26:25 2012 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 8FABF21F873A for ; Sat, 1 Sep 2012 13:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 gUdoYoWVQKPp for ; Sat, 1 Sep 2012 13:26:25 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id BC27021F8739 for ; Sat, 1 Sep 2012 13:26:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q81KQKCM005230; Sat, 1 Sep 2012 21:26:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q81KQIDD005222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Sep 2012 21:26:19 +0100 From: "Adrian Farrel" To: "'Papadimitriou, Dimitri \(Dimitri\)'" , References: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> In-Reply-To: Date: Sat, 1 Sep 2012 21:26:18 +0100 Message-ID: <24aa01cd8880$0be682e0$23b388a0$@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: AQHOIuHxF0XZ1ISMYt4ZDt/6eHUfWQCeq9IYl2/EncA= Content-Language: en-gb Subject: Re: [RTG-DIR] Routing directorate Gathering / Social Atlanta 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, 01 Sep 2012 20:26:25 -0000 > Q: Do you know any original place nearby the IETF venue ? I thought maybe we could all rent cars and drive to South Carolina. I am sure we will find something. And who knows, it might even be safe getting there and back from the hotel. A From acee.lindem@ericsson.com Sat Sep 1 13:36:17 2012 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 D6FCD1F041A for ; Sat, 1 Sep 2012 13:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 Qx+PFeajNt7Q for ; Sat, 1 Sep 2012 13:36:17 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 292FD1F0419 for ; Sat, 1 Sep 2012 13:36:17 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q81KaFdv022690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Sep 2012 15:36:15 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.166]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 1 Sep 2012 16:36:14 -0400 From: Acee Lindem To: "adrian@olddog.co.uk" Date: Sat, 1 Sep 2012 16:36:12 -0400 Thread-Topic: [RTG-DIR] Routing directorate Gathering / Social Atlanta Thread-Index: Ac2IgW3Z1A0km7eRRnOlNFJO8jbuiQ== Message-ID: References: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> <24aa01cd8880$0be682e0$23b388a0$@olddog.co.uk> In-Reply-To: <24aa01cd8880$0be682e0$23b388a0$@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-24-1004868875"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "Papadimitriou, Dimitri \(Dimitri\)" Subject: Re: [RTG-DIR] Routing directorate Gathering / Social Atlanta 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, 01 Sep 2012 20:36:18 -0000 --Apple-Mail-24-1004868875 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm in for Wednesday night - as Lou and Deborah will attest, I'm an = omnivore and will eat practically anything.=20 There is a beer place close but I could see the WG chairs picking the = same place: http://maxlagers.com/ I'd avoid the >$100 a head restaurant on top of the Hilton. I'm sure = we'll find something.=20 Acee=20 =20 On Sep 1, 2012, at 4:26 PM, Adrian Farrel wrote: >> Q: Do you know any original place nearby the IETF venue ? >=20 > I thought maybe we could all rent cars and drive to South Carolina. >=20 > I am sure we will find something. And who knows, it might even be safe = getting > there and back from the hotel. >=20 > A >=20 --Apple-Mail-24-1004868875 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkwMTIwMzYxM1owIwYJKoZI hvcNAQkEMRYEFCnHC2Gx+J7WrMvKNewf32QT3f4IMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgFfKMHSCZhGk65Jpp1oaXdkWlWub1mo9ssmRYf62DKPWf+kLxb35ED+FyRcC6+vD N/6KQwY7RtSSkykCF/q/y2ltqxCIhr7pxhO0fJndaEeH6SyKssii/dDShsMnb1xcofKceFEx5XJs 6wAKaEXSAem8TlF5F5HFUs35DTbG8fdGAAAAAAAA --Apple-Mail-24-1004868875-- From russ@riw.us Sun Sep 2 17:28:21 2012 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 BB4FC21F849A for ; Sun, 2 Sep 2012 17:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0J-rCpBlIlo for ; Sun, 2 Sep 2012 17:28:21 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2039C21F847A for ; Sun, 2 Sep 2012 17:28:21 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T8KWa-00005P-1v; Sun, 02 Sep 2012 17:28:20 -0700 Message-ID: <5043F9A9.1070400@riw.us> Date: Sun, 02 Sep 2012 20:28:25 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner X-Mailman-Approved-At: Mon, 03 Sep 2012 04:14:55 -0700 Cc: rtg-dir@ietf.org, draft-ietf-6man-lineid-08.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-6man-lineid-08.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, 03 Sep 2012 00:28: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, 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-6man-lineid-08.txt Reviewer: Russ White Review Date: 3 September 2012 IETF LC End Date: Intended Status: Standards Track Summary: No issues found. This document is ready for publication. Comments: This draft is well organized, laying out the problem space, the solution, and the limitations of the solution in fair order. The draft is also well written and easily readable. Major Issues: None found. Minor Issues: None found. Nits: None found. Russ From jdrake@juniper.net Mon Sep 3 07:08:12 2012 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 5C03A21F8546 for ; Mon, 3 Sep 2012 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.323 X-Spam-Level: X-Spam-Status: No, score=-5.323 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB22=0.948] 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 DTNEYPhIvJWh for ; Mon, 3 Sep 2012 07:08:11 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9126A21F846B for ; Mon, 3 Sep 2012 07:08:11 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUES5yP/w/O2EStAVtmgo+HijX7wKEetT@postini.com; Mon, 03 Sep 2012 07:08:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 3 Sep 2012 07:06:43 -0700 From: John E Drake To: "adrian@olddog.co.uk" , Ross Callon , "rtg-dir@ietf.org" Date: Mon, 3 Sep 2012 07:06:41 -0700 Thread-Topic: [RTG-DIR] Routing directorate Gathering / Social Atlanta Thread-Index: AQHOIuHxF0XZ1ISMYt4ZDt/6eHUfWQIyMOPOAepIeeSXUJFK8IAF/70w Message-ID: <5E893DB832F57341992548CDBB333163A632A5743C@EMBX01-HQ.jnpr.net> References: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A63288F653@EMBX01-HQ.jnpr.net> <21cc01cd86dd$799429e0$6cbc7da0$@olddog.co.uk> In-Reply-To: <21cc01cd86dd$799429e0$6cbc7da0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RTG-DIR] Routing directorate Gathering / Social Atlanta 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, 03 Sep 2012 14:08:12 -0000 I was hoping for No and Yes. Yours irrespectively, John > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, August 30, 2012 11:30 AM > To: Ross Callon; John E Drake; rtg-dir@ietf.org > Subject: RE: [RTG-DIR] Routing directorate Gathering / Social Atlanta >=20 > I can safely give you two answers. Yes and No. >=20 > Adrian >=20 > > -----Original Message----- > > From: Ross Callon [mailto:rcallon@juniper.net] > > Sent: 30 August 2012 18:21 > > To: John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org > > Subject: RE: [RTG-DIR] Routing directorate Gathering / Social Atlanta > > > > The real question: Will Adrian and Stewart be paying?? ;-) > > > > Ross > > > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > Behalf Of John E Drake > > Sent: Thursday, August 30, 2012 11:15 AM > > To: adrian@olddog.co.uk; rtg-dir@ietf.org > > Subject: Re: [RTG-DIR] Routing directorate Gathering / Social Atlanta > > > > Um, will you and Stewart be attending? > > > > Yours irrespectively, > > > > John > > > > > -----Original Message----- > > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > > Behalf Of Adrian Farrel > > > Sent: Thursday, August 30, 2012 8:10 AM > > > To: rtg-dir@ietf.org > > > Subject: [RTG-DIR] Routing directorate Gathering / Social Atlanta > > > > > > Hi, > > > > > > Stewart and I think it would be both nice and useful for the > Routing > > > Directorate (and their saintly secretaries) to all meet up in > Atlanta. > > > After some discussion, we think that dinner would be more social > > > than business, and that seems entirely appropriate. No evening at > an > > > IETF ever works well for everyone, but we would like to suggest > > > Wednesday after the Administrative Plenary. This will conflict with > > > the WG chairs' beer evening, and we will understand if some of you > > > want to run off early or skip the directorate dinner completely. > > > > > > Not taking reservations yet, but can you let us have opinions on > > > whether you think meeting over dinner would insufferable or not, > and > > > whether Wednesday is particularly bad (not for you personally, > > > because no evening will work for everyone, but for the wider > world). > > > > > > Thanks > > > Adrian and Stewart > > > > > > From lberger@labn.net Tue Sep 4 08:24:51 2012 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 419161F0417 for ; Tue, 4 Sep 2012 08:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 PjNw1wS9xQ-x for ; Tue, 4 Sep 2012 08:24:49 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 200121F040A for ; Tue, 4 Sep 2012 08:24:48 -0700 (PDT) Received: (qmail 24670 invoked by uid 0); 4 Sep 2012 15:24:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 4 Sep 2012 15:24:47 -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=muWjkdhXmlNXmRwF4z4HhJkmQvOGQH0yUKp2LsfnpOU=; b=LclDC9cYGXK3+3Yn4MkU1xM3cyAoIuuaoDLvuIsbsBOUoeoeECtscrcJm1tA8G2VGJrp7I9b70ayyd/jxn+APc/wuIt1bWzxicRjq8aimOn0ocdyJqoLw63JNFQ5yTz9; Received: from box313.bluehost.com ([69.89.31.113]:60130 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T8uze-0002Of-TR; Tue, 04 Sep 2012 09:24:47 -0600 Message-ID: <50461D40.1010607@labn.net> Date: Tue, 04 Sep 2012 11:24:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, PAPADIMITRIOU Dimitri References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> In-Reply-To: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> X-Enigmail-Version: 1.4.4 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-ccamp-assoc-ext.all@tools.ietf.org Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 04 Sep 2012 15:24:51 -0000 Adrian, Much Thanks. (BTW is there a reason not to include the WG in this, or such, discussions?) Dimitri, Please see below for inline responses. On 8/31/2012 1:02 PM, Adrian Farrel wrote: > Here is Dimitri's Routing Dir review. Many thanks for the review. > > Lou, you can address this and the other comments and post a new revision. > > Adrian > >> -----Original Message----- >> From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou@alcatel- >> lucent.com] >> Sent: 31 August 2012 13:23 >> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; sbryant@cisco.com; >> huawei.danli@huawei.com >> Subject: Review of draft-ietf-ccamp-assoc-ext-04 >> >> Hi All, >> >> Here below the review of this document. >> >> Technical comments: >> >> - Example 3: isn't this extension also not updating RFC 2205 ? Yes. This is stated in the header, abstract and section 3. >> >> - The statement "In order to support the more general usage of the >> ASSOCIATION object," is actually not correct RFC 4872 doesn't prevent support > of >> other usage of the ASSOCIATION object. It has just documented its usage in the >> GMPLS recovery context. I'm not sure how these two statements (the document text and your last sentence) are mutually inconsistent. I see no text change based on this comment. >> >> - Section 3.1, "Cross-session association based on Path state is defined in >> [RFC4872]." the latter defines cross-LSP association within the same session > (not >> cross-session association) but nothing prevents extending usage to cross- >> Session. >> I see no text change requested based on this comment. >> - Section 3.1.2 the statement "the definition SHOULD allow for association > based >> on identical ASSOCIATION objects" is not clear, does it that the information >> elements part of the object shall be identical ? I see no difference between the current text (object equivalence) and object information element equivalence. I don't believe there's a case where you can have one without the other. Please correct me if you think I'm mistaken. >> >> - Section 3.1.2 "The Association ID field MUST be set to a value that uniquely >> identifies the sessions to be associated within the context of the Association >> Source field." >> this statement is not compatible with e.g. RFC 4873 and 4872 where > Association >> ID are set to LSP ID and not sessions while it is stated in 3.1 " Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" so it does not impact to RFC 4873 and 4872 implementations. As stated in the draft and quoted by you: > This section > does not >> modify processing required to support [RFC4872] and [RFC4873], and which is >> reviewed in Section 3 of [RFC6689]. " 2) I also think "not compatible" is an overstatement, but I guess that it isn't really a critical point to discuss as the referenced text doesn't relate to [RFC4872] and [RFC4873]. >> and in RFC 4873/Section 3.2 "The >> ASSOCIATION object is used to associate different LSPs with each other." >> I see no text change requested based on this comment. >> - Section 3.1.2 "An association is deemed to exist when the same values are >> carried in all fields of the ASSOCIATION objects being compared." this > introduces >> an additional level of indirection. To associate A to B A can simply refer to > an >> identifier of B (and vice versa), A doesn't need to have an additional ID > (e.g. C) >> that is also associated to B. Generalization would consist here in introducing > an >> ext.association ID common to A, B, and C. In other terms, generalizing the > notion >> of association doesn't require the introduction of an additional level of >> indirection. I really have no idea what this comment means. There is no indirection stated or implied by the text. It means test for simple equivalence, i.e., (ASSOCIATION object of A) = (ASSOCIATION object of B) and that's it. There's no (session) ID referencing. Can you restate your concern? >> >> - Section 3.2.2 I understand triggers for Resv-initiated associations aren't >> documented but how to prevent a sender willing to demote receiver-driven >> associations ? Can you clarify this question? Are you asking: - how a Path sender can prevent a receiver initiated association? (it can't) - how a Resv sender removes an association? (it just removes the object, no different from a path message) - something else? >> >> - Section 3.1.2 and 3.2.2 no error processing is being documented I think this is a fair point. The only case I think that can/should be addressed is unknown types. (As is usual, per RFC2205, errors in formats to not trigger any specific message response.) Sections 3.1 and 3.2 only discuss identification of associations, so I propose adding a section 3.3.2. How about something like: 3.3.2. Unknown Association Types A node that receives an ASSOCIATION object with an unknown ASSOCIATION type MUST forward all received ASSOCIATION objects as defined above. The node MAY also identify associations per the defined processing, e.g., to make this information available via a management interface. >> whereas mis- >> match in association should be considered as a generic error. This isn't a detectable error case as it is impossible for a node to know if two association objects are intentionally or unintentionally different. >> >> - Section 3.3 states "Since the admission control function is outside the > scope of >> RSVP,..." are you sure ? Yes. Per RFC2205: HOST ROUTER _____________________________ ____________________________ | _______ | | | | | | _______ | | _______ | | |Appli- | | | |RSVP | | | | | | cation| | RSVP <---------------------------> RSVP <----------> | | <--> | | | _______ | | | | | | |process| _____ | ||Routing| |process| _____ | | |_._____| | -->Polcy|| || <--> -->Polcy|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | |data | | |_____|| ||__.____| | | |_____|| |===|===========|==|==========| |===|==========|==|==========| | | --------| | _____ | | | --------| | _____ | | | | | ---->Admis|| | | | | ---->Admis|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | | | | | |_____|| | | | | ||_____|| | |Class-| | Packet | | | |Class-| | Packet | | | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | |______| |________| |data | |______| |________| |data | | | | |_____________________________| |____________________________| Figure 1: RSVP in Hosts and Routers an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". >> admission control is an intrinsic function associated > to RFC >> 2205 (there are errors documented for admission control failures). I think you >> mean that the inner working of the mechanisms used by nodes to determine if >> they have sufficient available resources to support incoming requests. I think this is the same as what is stated. we can add "implementation specifics ", i.e., " Since the implementation specifics of the admission control function is outside the scope " if it helps. >> >> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >> ASSOCIATION object. As defined, these objects each contain an Association >> Source field and a 16-bit Association ID field. The combination of the > Association >> Source and the Association ID uniquely identifies the association." but in the >> context RFC 4872 this association is defined in the context of the same tunnel >> end-point How about we clarify: "*As described above,* the combination of the Association Source and the Association ID uniquely identifies the association." > (and actually the same for RFC 4873 which relies on MBB as defined > in >> RFC 3209) I don't believe this statement is correct, but again this is really a discussion beyond this draft. >> >> - Section 4: How is the following use case "There are scenarios where this > number >> is insufficient. (For example where the association identification is best > known >> and identified by a fairly centralized entity, which therefore may be involved > in a >> large number of associations.)" related to those proposed in the introduction. > ? As I read it, it enables practical third party (e.g., management entity) creation and management of association IDs. But, I'll defer to my coauthors on this. >> >> - Section 4: I don't question the requirement stated in "Per [RFC6370], > MPLS-TP >> LSPs can be identified based on an operator unique global identifier. The >> [RFC6370] defined "global identifier", or Global_ID, is based on [RFC5003] and >> includes the operator's Autonomous System Number (ASN)." the question is why >> the information is best encoded as part of the ASSOCIATION object ? isn't this > an >> LSP ATTRIBUTE or a Session Name ? It's the solution the WG agreed to. Other options are of course possible. >> >> - Section 4.2: states "It is important to note that Section 4 defines > association >> identification based on ASSOCIATION object matching, and that such matching > is >> based on the comparison of all fields in a ASSOCIATION object (unless type- >> specific comparison rules are defined). This applies equally to ASSOCIATION >> objects and Extended ASSOCIATION objects." any association is based on a form >> of matching, point here is that the matching and the identification of the > initiation >> of the matching information are distinct information entities (difference > between >> WHO and WHAT). I suggest to make a clearer distinction and specify setting and >> processing accordingly. I'm not seeing the issue. Can you perhaps propose some text? >> >> - Section 4.2: shouldn't "error processing" being documented ? Here too, I think the only error processing is as discussed above. Shout if you think otherwise. >> Example include >> admission control where receiving node rejects the incoming Path msg if the >> originating Global_ID/Ext.ASSOCIATION object isn't included, Interesting, but this is a type specific error. To me this sounds like a new admission control error that should be defined as part of the type-specific definition. >> unauthorized >> Global ID ? Again interesting, but this is a new policy (and policy error) that wasn't proposed or discussed in the WG. I think this would be a fine addition, but is beyond the current document discussion. It could always be added if proposed. >> etc. but also mismatches between Association source and Global >> Association source ? How would such a thing be detected, by checking BGP state? I guess we could add a new error code, but again I think we're going beyond the intent of the document/WG. >> >> - Section 4.1 and 4.2: the former states "The [RFC6370] defined global > identifier, >> or Global_ID, is based on [RFC5003] and includes the operator's Autonomous >> System Number (ASN)." while the latter "the use of the Global_ID is not > related >> to the use of the ASN in protocols such as BGP." which one applies ? I'll drop the note. This is better aligned with the field definition which has been updated based on comments of other reviewers. The current definition is: This field contains a value that is a unique global identifier or the special value zero (0). When non-zero and not overridden by local policy, the Global_ID as defined in [RFC6370] SHALL be used. The special value of zero indicates that no global identifier is present. Use of the special value of zero SHOULD be limited to entities contained within a single operator. >> >> - Section 5 Documenting means to prevent/mitigate mis-association(s) and >> possible impact on security would be advisable. If this is felt to be > "application" or >> "type" specific a recommendation should be stated that the security mechanisms >> have to be documented as part of these documents. Why is there any additional risk than what " was previously defined in [RFC4872] and [RFC4873]."? (as is already stated in the draft.) >> >> >> Editorials: >> >> - Introduction: "This document expands the possible usage of the ASSOCIATION >> object to >> non-GMPLS and non-recovery contexts." Suggested to state the actual the >> scope includes RSVP (instead of what it is not) I'll add: The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. >> >> - Introduction: s/different ports/different destination (dst) ports >> sure. >> - Section 2 would better refer to a "Generalization" rather than a > "modification" >> I'd be okay with this, but I think modification makes is less likely to be misinterpreted so will leave as is. >> - Section 3 states "As defined by [RFC4872] and reviewed in [RFC6689],..." but > an >> information RFC doesn't review at best "documents" certain usage. This >> statement is repeated at multiple places. Why can't it review? This is what the abstract of RFC6689 says it does. >> >> - Section 3 mentions "Object usage in both Path and Resv messages is > discussed. >> The usage applies equally to >> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions >> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having such statement in the >> introduction would desirable. Fair enough. Thank you for the review! Lou >> >> >> ----- >> Homepage: >> >> > > > > > From adrian@olddog.co.uk Tue Sep 4 13:38:11 2012 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 BFC6611E80A4 for ; Tue, 4 Sep 2012 13:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhSoiqN3gVdu for ; Tue, 4 Sep 2012 13:38:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1443721F8496 for ; Tue, 4 Sep 2012 13:38:10 -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 q84Kc9ud006878 for ; Tue, 4 Sep 2012 21:38:09 +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 q84Kc8Zh006872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Sep 2012 21:38:09 +0100 From: "Adrian Farrel" To: Date: Tue, 4 Sep 2012 21:38:08 +0100 Message-ID: <029f01cd8add$31b62ac0$95228040$@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: Ac2K3S3YqpFtAiLCSGKUuZODHvFqpA== Content-Language: en-gb Subject: [RTG-DIR] Recipients of Routing Directorate Reviews 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: Tue, 04 Sep 2012 20:38:11 -0000 Hi, The current Routing Directorate charter includes a template for review that suggests recipients...

Routing Directorate Review Template

To:

  • rtg-ads@tools.ietf.org

    • Cc:

  • rtg-dir@ietf.org;
  • draft-name.all@tools.ietf.org;

    • Subject:

  • RtgDir review: draft-name-version.txt
    • It seems reasonable to expose the reviews and subsequent discussions to the WG. Would anyone object to us adding ...
  • wg-mailing-list
    • to the cc list? I can see two problems with this... 1. A little research is needed to work out the WG mailing list name because they are not all perfectly intuitive. I don't think this is beyond your capabilities to handle. 2. Not all reviewers will be members of the WG lists and signing up is both a pain and risks a DoS on your inbox. However, all lists have moderators and they should be able to admit your messages for the short exchange that will follow. Thoughts? Adrian From dimitri.papadimitriou@alcatel-lucent.com Tue Sep 4 13:52:16 2012 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 6D2AF21E803F for ; Tue, 4 Sep 2012 13:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 6sU-5SRawivf for ; Tue, 4 Sep 2012 13:52:14 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3926C11E80A4 for ; Tue, 4 Sep 2012 13:52:14 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q84Kq9sA002274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Sep 2012 22:52:11 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 4 Sep 2012 22:52:10 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lou Berger , "adrian@olddog.co.uk" Date: Tue, 4 Sep 2012 22:52:09 +0200 Thread-Topic: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 Thread-Index: Ac2KsXE7mX2qeEYITiS+siCMWl7IygAAdWYg Message-ID: References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> In-Reply-To: <50461D40.1010607@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "rtg-dir@ietf.org" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 04 Sep 2012 20:52:16 -0000 Hi Lou, See inline: > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, September 04, 2012 17:25 > To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) > Cc: rtg-dir@ietf.org; draft-ietf-ccamp-assoc-ext.all@tools.ietf.org > Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > > Adrian, > Much Thanks. (BTW is there a reason not to include the > WG in this, or > such, discussions?) > > Dimitri, > Please see below for inline responses. > > On 8/31/2012 1:02 PM, Adrian Farrel wrote: > > Here is Dimitri's Routing Dir review. Many thanks for the review. > > > > Lou, you can address this and the other comments and post a > new revision. > > > > Adrian > > > >> -----Original Message----- > >> From: Papadimitriou, Dimitri (Dimitri) > [mailto:dimitri.papadimitriou@alcatel- > >> lucent.com] > >> Sent: 31 August 2012 13:23 > >> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; sbryant@cisco.com; > >> huawei.danli@huawei.com > >> Subject: Review of draft-ietf-ccamp-assoc-ext-04 > >> > >> Hi All, > >> > >> Here below the review of this document. > >> > >> Technical comments: > >> > >> - Example 3: isn't this extension also not updating RFC 2205 ? > > Yes. This is stated in the header, abstract and section 3. I thought to include this in the introduction since other updated RFC are i= ndicated. > >> - The statement "In order to support the more general usage of the > >> ASSOCIATION object," is actually not correct RFC 4872 > doesn't prevent support > > of > >> other usage of the ASSOCIATION object. It has just > documented its usage in the > >> GMPLS recovery context. > > I'm not sure how these two statements (the document text and your last > sentence) are mutually inconsistent. I see no text change > based on this comment. I meant: "In order to document the more general usage of the ASSOCIATION ob= ject, ..." > >> - Section 3.1, "Cross-session association based on Path > state is defined in > >> [RFC4872]." the latter defines cross-LSP association > within the same session > > (not > >> cross-session association) but nothing prevents extending > usage to cross- > >> Session. > >> > > I see no text change requested based on this comment. I meant: "Cross-LSP association based on Path state is defined in [RFC4872]= ; here we document cross-session association..." > >> - Section 3.1.2 the statement "the definition SHOULD allow > for association > > based > >> on identical ASSOCIATION objects" is not clear, does it > that the information > >> elements part of the object shall be identical ? > > I see no difference between the current text (object equivalence) and > object information element equivalence. I don't believe > there's a case > where you can have one without the other. Please correct me if you > think I'm mistaken. If the association ID are defined such that: - the Association ID of Session 1 or LSP 1 points to the Session ID or LSP = ID of LSP 2 - the Association ID of Session 2 or LSP 2 points to the Session ID or LSP = ID of LSP 1 Other elements aren't necessarily identical. The setting of the association= source is application type specific. Another case (if I am correctly understanding the related text), is related= to the MPLS-TP section. The association object of two non-associated sessi= on can have the value fields in the ext.association object. > >> - Section 3.1.2 "The Association ID field MUST be set to a > value that uniquely > >> identifies the sessions to be associated within the > context of the Association > >> Source field." > >> this statement is not compatible with e.g. RFC 4873 and > 4872 where > > Association > >> ID are set to LSP ID and not sessions while it is stated in 3.1 " > > Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" Yes and section 3.1.2 indicates "These procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state." don't you think this induces confusion ? > so it does not impact to RFC 4873 and 4872 implementations. As stated > in the draft and quoted by you: > > > This section > > does not > >> modify processing required to support [RFC4872] and > [RFC4873], and which is > >> reviewed in Section 3 of [RFC6689]. " The point I am raising is that Section 3.1 reads as there no "additions" wh= ereas once reaching Section 3.1.2 one understands that the statement no mod= ifications meant actually extensions. Section 3.1 states "This section does not modify processing required to support [RFC4872] and [RFC4873], and which is reviewed in Section 3 of [RFC6689]. " Section 3.1.2 states " These procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state." Hence, Section 3.1.2 should be rephrased as "This section is based on the processing rules described in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689]. These procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state." Section 3.1.2 should be rephrased as "This section generalizes the processing rules described in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689], for application to MPLS LSPs and non-LSP session state. For GMPLS LSP rules are extended for applications not related to the recovery and resource sharing." > 2) I also think "not compatible" is an overstatement, but I guess that > it isn't really a critical point to discuss as the referenced text > doesn't relate to [RFC4872] and [RFC4873]. The proposed phrasing would resolve it. > >> and in RFC 4873/Section 3.2 "The > >> ASSOCIATION object is used to associate different LSPs > with each other." > > I see no text change requested based on this comment. Ditto. > >> - Section 3.1.2 "An association is deemed to exist when > the same values are > >> carried in all fields of the ASSOCIATION objects being > compared." this > > introduces > >> an additional level of indirection. To associate A to B A > can simply refer to > > an > >> identifier of B (and vice versa), A doesn't need to have > an additional ID > > (e.g. C) > >> that is also associated to B. Generalization would consist > here in introducing > > an > >> ext.association ID common to A, B, and C. In other terms, > generalizing the > > notion > >> of association doesn't require the introduction of an > additional level of > >> indirection. > > I really have no idea what this comment means. There is no > indirection stated or implied by the text. It is the result of what the text implies and it is specifically related to= the "Association ID". Implicitly the document mandates than this identifie= r can't take any value of existing fields identifying tunnels/LSPs. > It means test for simple equivalence, > i.e., (ASSOCIATION object of A) =3D (ASSOCIATION object of B) and that's > it. There's no (session) ID referencing. Can you restate > your concern? My concern is this an equivalence between objects not an assocation of sess= ions. > >> - Section 3.2.2 I understand triggers for Resv-initiated > associations aren't > >> documented but how to prevent a sender willing to demote > receiver-driven > >> associations ? > > Can you clarify this question? Let me put first in context. Generalization includes Rcv driven association= s but only additions are documented. > Are you asking: > - how a Path sender can prevent a receiver initiated association? (it > can't) > > - how a Resv sender removes an association? (it just removes > the object, no different from a path message) The corresponding processing is to be documented. Because one can also demo= te an association by having each LSP/session pointing to itself while keepi= ng the object in the Path/Resv message. > - something else? > > >> - Section 3.1.2 and 3.2.2 no error processing is being documented > > I think this is a fair point. The only case I think that > can/should be > addressed is unknown types. (As is usual, per RFC2205, errors in > formats to not trigger any specific message response.) > Sections 3.1 and > 3.2 only discuss identification of associations, so I propose adding a > section 3.3.2. How about something like: > > 3.3.2. Unknown Association Types > > A node that receives an ASSOCIATION object with an unknown > ASSOCIATION type MUST forward all received ASSOCIATION objects > as defined above. The node MAY also identify associations per > the defined processing, e.g., to make this information available > via a management interface. OK. Wouldn't you document PathErr/ResvErr and Notify ? > >> whereas mis- > >> match in association should be considered as a generic error. > > This isn't a detectable error case as it is impossible for a node to > know if two association objects are intentionally or unintentionally > different. Earlier, in the text it is mentioned that processing implies checking all P= ath/Resv state. We have to understand that putting in place a generic proce= ssing (outside a specific ASSOCIATION Type) renders > >> - Section 3.3 states "Since the admission control function > is outside the > > scope of > >> RSVP,..." are you sure ? > > Yes. Per RFC2205: Yes I know the figuere whose terms mixes functions, protocol processes, etc= . but this goes beyond the review of this document ;-) > HOST ROUTER > > _____________________________ ____________________________ > | _______ | | | > | | | _______ | | _______ | > | |Appli- | | | |RSVP | | | | > | | cation| | RSVP <---------------------------> RSVP <----------> > | | <--> | | | _______ | | | > | | | |process| _____ | ||Routing| |process| _____ | > | |_._____| | -->Polcy|| || <--> -->Polcy|| > | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| > | |data | | |_____|| ||__.____| | | |_____|| > |=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D|=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D| |=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D|=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D| > | | --------| | _____ | | | --------| | _____ | > | | | | ---->Admis|| | | | | ---->Admis|| > | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| > | | | | | |_____|| | | | | ||_____|| > | |Class-| | Packet | | | |Class-| | Packet | | > | | ifier|=3D=3D>Schedulr|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D> ifier|=3D=3D>Schedulr|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> > | |______| |________| |data | |______| |________| |data > | | | | > |_____________________________| |____________________________| > > > Figure 1: RSVP in Hosts and Routers > > an RSVP QoS request is passed to two local > decision modules, "admission control" and "policy control". > > >> admission control is an intrinsic function associated > > to RFC > >> 2205 (there are errors documented for admission control > failures). I think you > >> mean that the inner working of the mechanisms used by > nodes to determine if > >> they have sufficient available resources to support > incoming requests. > > I think this is the same as what is stated. What you mean is: the inner-working or implementation of admission control = for QoS requests is outside scope of RFC 2205. > we can add "implementation specifics ", i.e., " Since the > implementation > specifics of the admission control function is outside the > scope " if it helps. Yes it does because the term "outside scope" has different meanings dependi= ng on context. > >> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION > object and the IPv6 > >> ASSOCIATION object. As defined, these objects each contain > an Association > >> Source field and a 16-bit Association ID field. The > combination of the > > Association > >> Source and the Association ID uniquely identifies the > association." but in the > >> context RFC 4872 this association is defined in the > context of the same tunnel > >> end-point > > How about we clarify: "*As described above,* the > combination of the Association Source and the Association ID > uniquely identifies the association." It would be better to state "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION obj= ect in the context of a given session. As defined, these objects each conta= in an Association Source field and a 16-bit Association ID field. The combi= nation of the Association Source and the Association ID uniquely identifies= the association. This doesn't prevent that Association Types MAY further s= pecify the context for which this association is defined." > > (and actually the same for RFC 4873 which relies on MBB as defined > > in > >> RFC 3209) > > I don't believe this statement is correct, but again this is really a > discussion beyond this draft. The statement here above is also to applicable to RFC 4873. > >> - Section 4: How is the following use case "There are > scenarios where this > > number > >> is insufficient. (For example where the association > identification is best > > known > >> and identified by a fairly centralized entity, which > therefore may be involved > > in a > >> large number of associations.)" related to those proposed > in the introduction. > > ? > > As I read it, it enables practical third party (e.g., > management entity) > creation and management of association IDs. But, I'll defer to my > coauthors on this. OK. Please let me know the result(s) of the discussion. > >> - Section 4: I don't question the requirement stated in > "Per [RFC6370], > > MPLS-TP > >> LSPs can be identified based on an operator unique global > identifier. The > >> [RFC6370] defined "global identifier", or Global_ID, is > based on [RFC5003] and > >> includes the operator's Autonomous System Number (ASN)." > the question is why > >> the information is best encoded as part of the ASSOCIATION > object ? isn't this > > an > >> LSP ATTRIBUTE or a Session Name ? > > It's the solution the WG agreed to. Other options are of > course possible. My comment is specific because it triggers the question on how many objects= will we end up in spreading identification information (it would be intere= sting to document the why this was felt the most suited object as it is not= a natural choice); more general comment is what defines the "acceptable" u= se/extension of association. > >> - Section 4.2: states "It is important to note that > Section 4 defines > > association > >> identification based on ASSOCIATION object matching, and > that such matching > > is > >> based on the comparison of all fields in a ASSOCIATION > object (unless type- > >> specific comparison rules are defined). This applies > equally to ASSOCIATION > >> objects and Extended ASSOCIATION objects." any association > is based on a form > >> of matching, point here is that the matching and the > identification of the > > initiation > >> of the matching information are distinct information > entities (difference > > between > >> WHO and WHAT). I suggest to make a clearer distinction and > specify setting and > >> processing accordingly. > > I'm not seeing the issue. Can you perhaps propose some text? Here is the proposed text "It is important to note that Section 4 defines association identification based on ASSOCIATION object matching, and that such matching is based on the comparison of the fields as determined by the ASSOCIATION Type of the ASSOCIATION object. This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects." > >> - Section 4.2: shouldn't "error processing" being documented ? > > Here too, I think the only error processing is as discussed above. > Shout if you think otherwise. > > >> Example include > >> admission control where receiving node rejects the > incoming Path msg if the > >> originating Global_ID/Ext.ASSOCIATION object isn't included, > > Interesting, but this is a type specific error. To me this > sounds like > a new admission control error that should be defined as part of the > type-specific definition. Admission control failures are part of the error codes defined in RFC 2205. > >> unauthorized > >> Global ID ? > > Again interesting, but this is a new policy (and policy error) that > wasn't proposed or discussed in the WG. I think this would be a fine > addition, but is beyond the current document discussion. It > could always be added if proposed. I defer this point to the AD. > >> etc. but also mismatches between Association source and Global > >> Association source ? > > How would such a thing be detected, by checking BGP state? I guess we > could add a new error code, but again I think we're going beyond the > intent of the document/WG. Same here. > >> - Section 4.1 and 4.2: the former states "The [RFC6370] > defined global > > identifier, > >> or Global_ID, is based on [RFC5003] and includes the > operator's Autonomous > >> System Number (ASN)." while the latter "the use of the > Global_ID is not > > related > >> to the use of the ASN in protocols such as BGP." which one > applies ? > > I'll drop the note. This is better aligned with the field definition > which has been updated based on comments of other reviewers. > > The current definition is: > > This field contains a value that is a unique global identifier or > the special value zero (0). When non-zero and not overridden by > local policy, the Global_ID as defined in [RFC6370] SHALL be used. > The special value of zero indicates that no global identifier is > present. Use of the special value of zero SHOULD be limited to > entities contained within a single operator. OK > >> - Section 5 Documenting means to prevent/mitigate > mis-association(s) and > >> possible impact on security would be advisable. If this is > felt to be > > "application" or > >> "type" specific a recommendation should be stated that the > security mechanisms > >> have to be documented as part of these documents. > > Why is there any additional risk than what " was previously defined in > [RFC4872] and [RFC4873]."? (as is already stated in the draft.) I try to prevent that any further use/documents would state "no additional = risk compared to RFC 4872 and RFC 4873" or equivalent but the application i= s running for voice calls over the Internet which is a totally different ap= plication than G/MPLS Recovery/Resource Sharing. > >> Editorials: > >> > >> - Introduction: "This document expands the possible usage > of the ASSOCIATION > >> object to > >> non-GMPLS and non-recovery contexts." Suggested to state > the actual the > >> scope includes RSVP (instead of what it is not) > > I'll add: > The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS > LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], > [RFC3175] and [RFC4860]. OK. > >> - Introduction: s/different ports/different destination (dst) ports > >> > > sure. > > >> - Section 2 would better refer to a "Generalization" rather than a > > "modification" > >> > > I'd be okay with this, but I think modification makes is less > likely to be misinterpreted so will leave as is. The term modification implies a change in existing processing (even if the = intention is different) and actually as the applicability is now possible t= o RSVP and MPLS-TE. > >> - Section 3 states "As defined by [RFC4872] and reviewed > in [RFC6689],..." but > > an > >> information RFC doesn't review at best "documents" > certain usage. This > >> statement is repeated at multiple places. > > Why can't it review? This is what the abstract of RFC6689 > says it does. It was overstated in RFC 6689. > >> - Section 3 mentions "Object usage in both Path and Resv > messages is > > discussed. > >> The usage applies equally to > >> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP > RSVP sessions > >> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having > such statement in the > >> introduction would desirable. > > Fair enough. > > Thank you for the review! OK. Thanks, -d. > Lou > > >> > >> > >> ----- > >> Homepage: > >> > >> > > > > > > > > > > > From thomas@thomasclausen.org Tue Sep 4 14:04:15 2012 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 1038711E80B8 for ; Tue, 4 Sep 2012 14:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 7kjvdv7K9a+2 for ; Tue, 4 Sep 2012 14:04:14 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A3A7C11E809A for ; Tue, 4 Sep 2012 14:04:14 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 406375582AE for ; Tue, 4 Sep 2012 14:04:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5F2381C0400; Tue, 4 Sep 2012 14:04:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.6.136] (ip-64-134-96-189.public.wayport.net [64.134.96.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C3ADA1C0749; Tue, 4 Sep 2012 14:04:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Thomas Heide Clausen In-Reply-To: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> Date: Tue, 4 Sep 2012 17:03:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1486) Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 04 Sep 2012 21:04:15 -0000 Excellent idea.=20 Would be good to convince gen-art, sec-dir and other*-dir to do the = same. Thomas On Sep 4, 2012, at 16:38 , "Adrian Farrel" wrote: > Hi, >=20 > The current Routing Directorate charter includes a template for review = that > suggests recipients... >=20 >=20 >

    Routing Directorate Review Template

    >=20 >

    To: >

  • rtg-ads@tools.ietf.org
    • >

    Cc: >

  • rtg-dir@ietf.org;
    • >
  • draft-name.all@tools.ietf.org;
    • >

    Subject: >

  • RtgDir review: draft-name-version.txt
    • >=20 >=20 > It seems reasonable to expose the reviews and subsequent discussions = to the WG. > Would anyone object to us adding ... >=20 >
  • wg-mailing-list
    • >=20 > to the cc list? >=20 > I can see two problems with this... >=20 > 1. A little research is needed to work out the WG mailing list name = because they > are not all perfectly intuitive. I don't think this is beyond your = capabilities > to handle. >=20 > 2. Not all reviewers will be members of the WG lists and signing up is = both a > pain and risks a DoS on your inbox. However, all lists have moderators = and they > should be able to admit your messages for the short exchange that will = follow. >=20 > Thoughts? >=20 > Adrian >=20 >=20 >=20 >=20 From lberger@labn.net Tue Sep 4 14:53:34 2012 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 CECE621E8098 for ; Tue, 4 Sep 2012 14:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 V39GSaPfRErR for ; Tue, 4 Sep 2012 14:53:33 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 1A67721E80A1 for ; Tue, 4 Sep 2012 14:53:33 -0700 (PDT) Received: (qmail 15274 invoked by uid 0); 4 Sep 2012 21:53:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 4 Sep 2012 21:53:31 -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=z0vC1OBWCSdRFlzUfYjWxtJqpY3pjCCNW02EBbulcqo=; b=qZjCL/OdYx45ByZNUS8UoADxjjdVinWUJ3qdVjgNMImvB2akIsRu4JWnK41C4zRnRrn/Ta4U6ymsiHjFicDsJJ3wdwOlqID/Q+i4QLWwr5wOho8CNXxmUK2J34EoTh9q; Received: from box313.bluehost.com ([69.89.31.113]:45656 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T913r-0000Sk-8H; Tue, 04 Sep 2012 15:53:31 -0600 Message-ID: <5046785D.6050700@labn.net> Date: Tue, 04 Sep 2012 17:53:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Papadimitriou, Dimitri (Dimitri)" References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.4 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: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 04 Sep 2012 21:53:35 -0000 Dimitri, See below. On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: > Hi Lou, > > See inline: > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, September 04, 2012 17:25 >> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) >> Cc: rtg-dir@ietf.org; draft-ietf-ccamp-assoc-ext.all@tools.ietf.org >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >> >> Adrian, >> Much Thanks. (BTW is there a reason not to include the >> WG in this, or >> such, discussions?) >> >> Dimitri, >> Please see below for inline responses. >> >> On 8/31/2012 1:02 PM, Adrian Farrel wrote: >>> Here is Dimitri's Routing Dir review. Many thanks for the review. >>> >>> Lou, you can address this and the other comments and post a >> new revision. >>> >>> Adrian >>> >>>> -----Original Message----- >>>> From: Papadimitriou, Dimitri (Dimitri) >> [mailto:dimitri.papadimitriou@alcatel- >>>> lucent.com] >>>> Sent: 31 August 2012 13:23 >>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; sbryant@cisco.com; >>>> huawei.danli@huawei.com >>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 >>>> >>>> Hi All, >>>> >>>> Here below the review of this document. >>>> >>>> Technical comments: >>>> >>>> - Example 3: isn't this extension also not updating RFC 2205 ? >> >> Yes. This is stated in the header, abstract and section 3. > > I thought to include this in the introduction since other updated RFC are indicated. > Agreed. Text has been added. >>>> - The statement "In order to support the more general usage of the >>>> ASSOCIATION object," is actually not correct RFC 4872 >> doesn't prevent support >>> of >>>> other usage of the ASSOCIATION object. It has just >> documented its usage in the >>>> GMPLS recovery context. >> >> I'm not sure how these two statements (the document text and your last >> sentence) are mutually inconsistent. I see no text change >> based on this comment. > > I meant: "In order to document the more general usage of the ASSOCIATION object, ..." > While I don't mind the change in this part of the sentience, the result is a bit odd "In order to document the more general usage of the ASSOCIATION object, this document ..." So will leave as is. >>>> - Section 3.1, "Cross-session association based on Path >> state is defined in >>>> [RFC4872]." the latter defines cross-LSP association >> within the same session >>> (not >>>> cross-session association) but nothing prevents extending >> usage to cross- >>>> Session. >>>> >> >> I see no text change requested based on this comment. > > I meant: "Cross-LSP association based on Path state is defined in > [RFC4872]; here we document cross-session association..." I'll change two instances of "Cross-session association" to "Cross-LSP association". > >>>> - Section 3.1.2 the statement "the definition SHOULD allow >> for association >>> based >>>> on identical ASSOCIATION objects" is not clear, does it >> that the information >>>> elements part of the object shall be identical ? >> >> I see no difference between the current text (object equivalence) and >> object information element equivalence. I don't believe >> there's a case >> where you can have one without the other. Please correct me if you >> think I'm mistaken. > > If the association ID are defined such that: > > - the Association ID of Session 1 or LSP 1 points to the Session ID or LSP ID of LSP 2 > > - the Association ID of Session 2 or LSP 2 points to the Session ID or LSP ID of LSP 1 Association based on matching Association ID to Session ID is not part of this draft. > > Other elements aren't necessarily identical. They must be identical in the context of this draft and the absence of type-specific processing rules. > The setting of the association source is application type specific. Even if true, I don't see how this impacts the text of the draft. > > Another case (if I am correctly understanding the related text), is > related to the MPLS-TP section. The association object of two > non-associated session can have the value fields in the > ext.association object. This is a true statement, but unless the contents of the whole object are identical, there's no association. > >>>> - Section 3.1.2 "The Association ID field MUST be set to a >> value that uniquely >>>> identifies the sessions to be associated within the >> context of the Association >>>> Source field." >>>> this statement is not compatible with e.g. RFC 4873 and >> 4872 where >>> Association >>>> ID are set to LSP ID and not sessions while it is stated in 3.1 " >> >> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" > > Yes and section 3.1.2 indicates "These procedures > apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state." > > don't you think this induces confusion ? > Perhaps, but this is why the 3.1 states: This section does not modify processing required to support [RFC4872] and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. >> so it does not impact to RFC 4873 and 4872 implementations. As stated >> in the draft and quoted by you: >> >>> This section >>> does not >>>> modify processing required to support [RFC4872] and >> [RFC4873], and which is >>>> reviewed in Section 3 of [RFC6689]. " > > The point I am raising is that Section 3.1 reads as there no > "additions" whereas once reaching Section 3.1.2 one understands that > the statement no modifications meant actually extensions. > > Section 3.1 states "This section does not modify processing required to > support [RFC4872] and [RFC4873], and which is reviewed in Section 3 > of [RFC6689]. " > > Section 3.1.2 states " These procedures > apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state." > > Hence, > > Section 3.1.2 should be rephrased as > > "This section is based on the processing rules described in [RFC4872] > and [RFC4873], and which is reviewed in [RFC6689]. These procedures > apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state." > > Section 3.1.2 should be rephrased as > > "This section generalizes the processing rules described in [RFC4872] > and [RFC4873], and which is reviewed in [RFC6689], for application > to MPLS LSPs and non-LSP session state. For GMPLS LSP rules are > extended for applications not related to the recovery and resource > sharing." I've revised the text to read: This section is based on, and extends, the processing rules described in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689]. This section applies equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. Note, as previously stated, this section does not modify processing required to support [RFC4872] and [RFC4873]. > >> 2) I also think "not compatible" is an overstatement, but I guess that >> it isn't really a critical point to discuss as the referenced text >> doesn't relate to [RFC4872] and [RFC4873]. > > The proposed phrasing would resolve it. > >>>> and in RFC 4873/Section 3.2 "The >>>> ASSOCIATION object is used to associate different LSPs >> with each other." >> >> I see no text change requested based on this comment. > > Ditto. > >>>> - Section 3.1.2 "An association is deemed to exist when >> the same values are >>>> carried in all fields of the ASSOCIATION objects being >> compared." this >>> introduces >>>> an additional level of indirection. To associate A to B A >> can simply refer to >>> an >>>> identifier of B (and vice versa), A doesn't need to have >> an additional ID >>> (e.g. C) >>>> that is also associated to B. Generalization would consist >> here in introducing >>> an >>>> ext.association ID common to A, B, and C. In other terms, >> generalizing the >>> notion >>>> of association doesn't require the introduction of an >> additional level of >>>> indirection. >> >> I really have no idea what this comment means. There is no >> indirection stated or implied by the text. > > It is the result of what the text implies and it is specifically > related to the "Association ID". Implicitly the document mandates > than this identifier can't take any value of existing fields > identifying tunnels/LSPs. Not at all. As long as the IDs as consistently set across association objects, an association will be made. Furthermore, type specific processing can be defined that allows implicit mapping such as you defined in 4872. > >> It means test for simple equivalence, >> i.e., (ASSOCIATION object of A) = (ASSOCIATION object of B) and that's >> it. There's no (session) ID referencing. Can you restate >> your concern? > > My concern is this an equivalence between objects not an assocation of sessions. > Per this document, equivalence between objects identifies an assocation of sessions. This document does not generalize the session ID to association ID matching that was part of 4872. >>>> - Section 3.2.2 I understand triggers for Resv-initiated >> associations aren't >>>> documented but how to prevent a sender willing to demote >> receiver-driven >>>> associations ? >> >> Can you clarify this question? > > Let me put first in context. Generalization includes Rcv driven > associations but only additions are documented. > >> Are you asking: >> - how a Path sender can prevent a receiver initiated association? (it >> can't) >> >> - how a Resv sender removes an association? (it just removes >> the object, no different from a path message) > > The corresponding processing is to be documented. Because one can > also demote an association by having each LSP/session pointing to > itself while keeping the object in the Path/Resv message. This sounds like the implicit matching rules in 4872. Such session ID to association ID matching is not part of this document. > >> - something else? >> >>>> - Section 3.1.2 and 3.2.2 no error processing is being documented >> >> I think this is a fair point. The only case I think that >> can/should be >> addressed is unknown types. (As is usual, per RFC2205, errors in >> formats to not trigger any specific message response.) >> Sections 3.1 and >> 3.2 only discuss identification of associations, so I propose adding a >> section 3.3.2. How about something like: >> >> 3.3.2. Unknown Association Types >> >> A node that receives an ASSOCIATION object with an unknown >> ASSOCIATION type MUST forward all received ASSOCIATION objects >> as defined above. The node MAY also identify associations per >> the defined processing, e.g., to make this information available >> via a management interface. > > OK. Wouldn't you document PathErr/ResvErr and Notify ? IMO Not for an unknown type. > >>>> whereas mis- >>>> match in association should be considered as a generic error. >> >> This isn't a detectable error case as it is impossible for a node to >> know if two association objects are intentionally or unintentionally >> different. > > Earlier, in the text it is mentioned that processing implies checking > all Path/Resv state. We have to understand that putting in place a > generic processing (outside a specific ASSOCIATION Type) renders I think this sentence got truncated... > >>>> - Section 3.3 states "Since the admission control function >> is outside the >>> scope of >>>> RSVP,..." are you sure ? >> >> Yes. Per RFC2205: > > Yes I know the figuere whose terms mixes functions, protocol > processes, etc. but this goes beyond the review of this document ;-) > >> HOST ROUTER >> >> _____________________________ ____________________________ >> | _______ | | | >> | | | _______ | | _______ | >> | |Appli- | | | |RSVP | | | | >> | | cation| | RSVP <---------------------------> RSVP <----------> >> | | <--> | | | _______ | | | >> | | | |process| _____ | ||Routing| |process| _____ | >> | |_._____| | -->Polcy|| || <--> -->Polcy|| >> | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| >> | |data | | |_____|| ||__.____| | | |_____|| >> |===|===========|==|==========| |===|==========|==|==========| >> | | --------| | _____ | | | --------| | _____ | >> | | | | ---->Admis|| | | | | ---->Admis|| >> | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| >> | | | | | |_____|| | | | | ||_____|| >> | |Class-| | Packet | | | |Class-| | Packet | | >> | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> >> | |______| |________| |data | |______| |________| |data >> | | | | >> |_____________________________| |____________________________| >> >> >> Figure 1: RSVP in Hosts and Routers >> >> an RSVP QoS request is passed to two local >> decision modules, "admission control" and "policy control". >> >>>> admission control is an intrinsic function associated >>> to RFC >>>> 2205 (there are errors documented for admission control >> failures). I think you >>>> mean that the inner working of the mechanisms used by >> nodes to determine if >>>> they have sufficient available resources to support >> incoming requests. >> >> I think this is the same as what is stated. > > What you mean is: the inner-working or implementation of admission > control for QoS requests is outside scope of RFC 2205. > >> we can add "implementation specifics ", i.e., " Since the >> implementation >> specifics of the admission control function is outside the >> scope " if it helps. > > Yes it does because the term "outside scope" has different meanings depending on context. > done. >>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION >> object and the IPv6 >>>> ASSOCIATION object. As defined, these objects each contain >> an Association >>>> Source field and a 16-bit Association ID field. The >> combination of the >>> Association >>>> Source and the Association ID uniquely identifies the >> association." but in the >>>> context RFC 4872 this association is defined in the >> context of the same tunnel >>>> end-point >> >> How about we clarify: "*As described above,* the >> combination of the Association Source and the Association ID >> uniquely identifies the association." > > It would be better to state > > "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > ASSOCIATION object in the context of a given session. As defined, > these objects each contain an Association Source field and a 16-bit > Association ID field. The combination of the Association Source and > the Association ID uniquely identifies the association. This doesn't > prevent that Association Types MAY further specify the context for > which this association is defined." It now reads: [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION object. As defined, these objects each contain an Association Source field and a 16-bit Association ID field. As described above, the contents of the object uniquely identifies an association. Because the Association ID field is a 16-bit field, an association source can allocate up to 65536 different associations and no more. > >>> (and actually the same for RFC 4873 which relies on MBB as defined >>> in >>>> RFC 3209) >> >> I don't believe this statement is correct, but again this is really a >> discussion beyond this draft. > > The statement here above is also to applicable to RFC 4873. > >>>> - Section 4: How is the following use case "There are >> scenarios where this >>> number >>>> is insufficient. (For example where the association >> identification is best >>> known >>>> and identified by a fairly centralized entity, which >> therefore may be involved >>> in a >>>> large number of associations.)" related to those proposed >> in the introduction. >>> ? >> >> As I read it, it enables practical third party (e.g., >> management entity) >> creation and management of association IDs. But, I'll defer to my >> coauthors on this. > > OK. Please let me know the result(s) of the discussion. > >>>> - Section 4: I don't question the requirement stated in >> "Per [RFC6370], >>> MPLS-TP >>>> LSPs can be identified based on an operator unique global >> identifier. The >>>> [RFC6370] defined "global identifier", or Global_ID, is >> based on [RFC5003] and >>>> includes the operator's Autonomous System Number (ASN)." >> the question is why >>>> the information is best encoded as part of the ASSOCIATION >> object ? isn't this >>> an >>>> LSP ATTRIBUTE or a Session Name ? >> >> It's the solution the WG agreed to. Other options are of >> course possible. > > My comment is specific because it triggers the question on how many > objects will we end up in spreading identification information (it > would be interesting to document the why this was felt the most > suited object as it is not a natural choice); more general comment is > what defines the "acceptable" use/extension of association. I think the last comment is a reasonable discussion to have. Not sure it belongs in, or gates the discussion. > >>>> - Section 4.2: states "It is important to note that >> Section 4 defines >>> association >>>> identification based on ASSOCIATION object matching, and >> that such matching >>> is >>>> based on the comparison of all fields in a ASSOCIATION >> object (unless type- >>>> specific comparison rules are defined). This applies >> equally to ASSOCIATION >>>> objects and Extended ASSOCIATION objects." any association >> is based on a form >>>> of matching, point here is that the matching and the >> identification of the >>> initiation >>>> of the matching information are distinct information >> entities (difference >>> between >>>> WHO and WHAT). I suggest to make a clearer distinction and >> specify setting and >>>> processing accordingly. >> >> I'm not seeing the issue. Can you perhaps propose some text? > > Here is the proposed text > > "It is important to note that Section 4 defines association > identification based on ASSOCIATION object matching, and > that such matching is based on the comparison of the fields > as determined by the ASSOCIATION Type of the ASSOCIATION > object. This applies equally to ASSOCIATION objects and > Extended ASSOCIATION objects." > Here's the revised text. Identification of association is not modified by this section. It is important to note that Section 4 defines association identification based on ASSOCIATION object matching, and that such matching, in the absence of type-specific comparison rules, is based on the comparison of all fields in an ASSOCIATION object. This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects. >>>> - Section 4.2: shouldn't "error processing" being documented ? >> >> Here too, I think the only error processing is as discussed above. >> Shout if you think otherwise. >> >>>> Example include >>>> admission control where receiving node rejects the >> incoming Path msg if the >>>> originating Global_ID/Ext.ASSOCIATION object isn't included, >> >> Interesting, but this is a type specific error. To me this >> sounds like >> a new admission control error that should be defined as part of the >> type-specific definition. > > Admission control failures are part of the error codes defined in RFC 2205. exactly! > >>>> unauthorized >>>> Global ID ? >> >> Again interesting, but this is a new policy (and policy error) that >> wasn't proposed or discussed in the WG. I think this would be a fine >> addition, but is beyond the current document discussion. It >> could always be added if proposed. > > I defer this point to the AD. WFM. > >>>> etc. but also mismatches between Association source and Global >>>> Association source ? >> >> How would such a thing be detected, by checking BGP state? I guess we >> could add a new error code, but again I think we're going beyond the >> intent of the document/WG. > > Same here. > >>>> - Section 4.1 and 4.2: the former states "The [RFC6370] >> defined global >>> identifier, >>>> or Global_ID, is based on [RFC5003] and includes the >> operator's Autonomous >>>> System Number (ASN)." while the latter "the use of the >> Global_ID is not >>> related >>>> to the use of the ASN in protocols such as BGP." which one >> applies ? >> >> I'll drop the note. This is better aligned with the field definition >> which has been updated based on comments of other reviewers. >> >> The current definition is: >> >> This field contains a value that is a unique global identifier or >> the special value zero (0). When non-zero and not overridden by >> local policy, the Global_ID as defined in [RFC6370] SHALL be used. >> The special value of zero indicates that no global identifier is >> present. Use of the special value of zero SHOULD be limited to >> entities contained within a single operator. > > OK > >>>> - Section 5 Documenting means to prevent/mitigate >> mis-association(s) and >>>> possible impact on security would be advisable. If this is >> felt to be >>> "application" or >>>> "type" specific a recommendation should be stated that the >> security mechanisms >>>> have to be documented as part of these documents. >> >> Why is there any additional risk than what " was previously defined in >> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) > > I try to prevent that any further use/documents would state "no > additional risk compared to RFC 4872 and RFC 4873" or equivalent but > the application is running for voice calls over the Internet which is > a totally different application than G/MPLS Recovery/Resource > Sharing. Fair enough, but what additional issues do you foresee that should be covered? > >>>> Editorials: >>>> >>>> - Introduction: "This document expands the possible usage >> of the ASSOCIATION >>>> object to >>>> non-GMPLS and non-recovery contexts." Suggested to state >> the actual the >>>> scope includes RSVP (instead of what it is not) >> >> I'll add: >> The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS >> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], >> [RFC3175] and [RFC4860]. > > OK. > >>>> - Introduction: s/different ports/different destination (dst) ports >>>> >> >> sure. >> >>>> - Section 2 would better refer to a "Generalization" rather than a >>> "modification" >>>> >> >> I'd be okay with this, but I think modification makes is less >> likely to be misinterpreted so will leave as is. > > The term modification implies a change in existing processing (even > if the intention is different) and actually as the applicability is > now possible to RSVP and MPLS-TE. This isn't a major point for me, so will change it. (In 5 places.) > >>>> - Section 3 states "As defined by [RFC4872] and reviewed >> in [RFC6689],..." but >>> an >>>> information RFC doesn't review at best "documents" >> certain usage. This >>>> statement is repeated at multiple places. >> >> Why can't it review? This is what the abstract of RFC6689 >> says it does. > > It was overstated in RFC 6689. This document doesn't change 6689. > >>>> - Section 3 mentions "Object usage in both Path and Resv >> messages is >>> discussed. >>>> The usage applies equally to >>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP >> RSVP sessions >>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having >> such statement in the >>>> introduction would desirable. >> >> Fair enough. >> >> Thank you for the review! > > OK. > > Thanks, > -d. Thanks, Lou >> Lou >> >>>> >>>> >>>> ----- >>>> Homepage: >>>> >>>> >>> >>> >>> >>> >>> >> > > > > From lberger@labn.net Tue Sep 4 16:27:55 2012 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 DE6E821E8084 for ; Tue, 4 Sep 2012 16:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 JlysHZU44dXd for ; Tue, 4 Sep 2012 16:27:54 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 4709621E8082 for ; Tue, 4 Sep 2012 16:27:54 -0700 (PDT) Received: (qmail 4683 invoked by uid 0); 4 Sep 2012 21:57:02 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 4 Sep 2012 21:57:02 -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=hkfEuWfnB3LhxAoVXJQHsz8Zmrga7hxg+PVsD96oxLA=; b=RlfsuqoVxaFc8+WUIzxmPCMlWOvOyqMOmtkMBmBI4U+IFQEy86Kfzdue1PDJj6H6cq/U2eZwe/4vgY0fOMQhFIfjZfbH762XF4WV7ZZEXGA/dAef26ZX9pPJ/Xj2agnT; Received: from box313.bluehost.com ([69.89.31.113]:46058 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T917G-0001ZZ-DA; Tue, 04 Sep 2012 15:57:02 -0600 Message-ID: <50467930.60701@labn.net> Date: Tue, 04 Sep 2012 17:57:04 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> In-Reply-To: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> X-Enigmail-Version: 1.4.4 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 Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 04 Sep 2012 23:27:55 -0000 I think this is a good idea. I think any substantive review, and related discussion, should be of interest to the WG that produced the draft. Lou On 9/4/2012 4:38 PM, Adrian Farrel wrote: > Hi, > > The current Routing Directorate charter includes a template for review that > suggests recipients... > > >

    Routing Directorate Review Template

    > >

    To: >

  • rtg-ads@tools.ietf.org
    • >

    Cc: >

  • rtg-dir@ietf.org;
    • >
  • draft-name.all@tools.ietf.org;
    • >

    Subject: >

  • RtgDir review: draft-name-version.txt
    • > > > It seems reasonable to expose the reviews and subsequent discussions to the WG. > Would anyone object to us adding ... > >
  • wg-mailing-list
    • > > to the cc list? > > I can see two problems with this... > > 1. A little research is needed to work out the WG mailing list name because they > are not all perfectly intuitive. I don't think this is beyond your capabilities > to handle. > > 2. Not all reviewers will be members of the WG lists and signing up is both a > pain and risks a DoS on your inbox. However, all lists have moderators and they > should be able to admit your messages for the short exchange that will follow. > > Thoughts? > > Adrian > > > > > > > > From acee.lindem@ericsson.com Tue Sep 4 16:30:44 2012 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 AE39A21E8088 for ; Tue, 4 Sep 2012 16:30:43 -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 1fa1PQhNWAhq for ; Tue, 4 Sep 2012 16:30:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3E521E8082 for ; Tue, 4 Sep 2012 16:30:43 -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 q84NXe0a003430; Tue, 4 Sep 2012 18:33:42 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.166]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 4 Sep 2012 19:30:34 -0400 From: Acee Lindem To: Lou Berger Date: Tue, 4 Sep 2012 19:30:33 -0400 Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: Ac2K9UhE0dKN9NgSRIyN6P07nq9cfw== Message-ID: <64AD74D7-5EEC-415A-B007-382FF682ACCC@ericsson.com> References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> <50467930.60701@labn.net> In-Reply-To: <50467930.60701@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-39--872953320"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 04 Sep 2012 23:30:44 -0000 --Apple-Mail-39--872953320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1=20 On Sep 4, 2012, at 5:57 PM, Lou Berger wrote: > I think this is a good idea. I think any substantive review, and > related discussion, should be of interest to the WG that produced the = draft. >=20 > Lou >=20 > On 9/4/2012 4:38 PM, Adrian Farrel wrote: >> Hi, >>=20 >> The current Routing Directorate charter includes a template for = review that >> suggests recipients... >>=20 >>=20 >>

    Routing Directorate Review Template

    >>=20 >>

    To: >>

  • rtg-ads@tools.ietf.org
    • >>

    Cc: >>

  • rtg-dir@ietf.org;
    • >>
  • draft-name.all@tools.ietf.org;
    • >>

    Subject: >>

  • RtgDir review: draft-name-version.txt
    • >>=20 >>=20 >> It seems reasonable to expose the reviews and subsequent discussions = to the WG. >> Would anyone object to us adding ... >>=20 >>
  • wg-mailing-list
    • >>=20 >> to the cc list? >>=20 >> I can see two problems with this... >>=20 >> 1. A little research is needed to work out the WG mailing list name = because they >> are not all perfectly intuitive. I don't think this is beyond your = capabilities >> to handle. >>=20 >> 2. Not all reviewers will be members of the WG lists and signing up = is both a >> pain and risks a DoS on your inbox. However, all lists have = moderators and they >> should be able to admit your messages for the short exchange that = will follow. >>=20 >> Thoughts? >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 --Apple-Mail-39--872953320 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkwNDIzMzAzNFowIwYJKoZI hvcNAQkEMRYEFFCEu12y/PomBKWO/YynL6Qbo8TSMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgHFIivGzNmdm9KHXHO+JJCtKWpEKaLWevc25jhG4MJEXv76T0bhBV/XKK7lFCrYn fwoqcAUXKsgFZhwTPLM7d4afJU/ps2/9KtDORIMa6HVwKVE+32NMqWDyNyRCw7HLSo1tkY3DHgmX pQwwIErXuQJPDP2BtrSw0SZ5nLo5BCPdAAAAAAAA --Apple-Mail-39--872953320-- From rcallon@juniper.net Tue Sep 4 19:31:19 2012 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 79C3B11E80A5 for ; Tue, 4 Sep 2012 19:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 JLV-Yn8BNuyi for ; Tue, 4 Sep 2012 19:31:19 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2539611E808D for ; Tue, 4 Sep 2012 19:31:16 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUEa5cmzCH1e3RKVNbMbGoTMtDXNYC3ym@postini.com; Tue, 04 Sep 2012 19:31:19 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 19:27:01 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 4 Sep 2012 22:27:01 -0400 From: Ross Callon To: Acee Lindem , Lou Berger Date: Tue, 4 Sep 2012 22:26:15 -0400 Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: Ac2K9UhE0dKN9NgSRIyN6P07nq9cfwAGHa9w Message-ID: References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> <50467930.60701@labn.net> <64AD74D7-5EEC-415A-B007-382FF682ACCC@ericsson.com> In-Reply-To: <64AD74D7-5EEC-415A-B007-382FF682ACCC@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 05 Sep 2012 02:31:19 -0000 +1 -----Original Message----- From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf = Of Acee Lindem Sent: Tuesday, September 04, 2012 7:31 PM To: Lou Berger Cc: adrian@olddog.co.uk; rtg-dir@ietf.org Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews +1=20 On Sep 4, 2012, at 5:57 PM, Lou Berger wrote: > I think this is a good idea. I think any substantive review, and > related discussion, should be of interest to the WG that produced the dra= ft. >=20 > Lou >=20 > On 9/4/2012 4:38 PM, Adrian Farrel wrote: >> Hi, >>=20 >> The current Routing Directorate charter includes a template for review t= hat >> suggests recipients... >>=20 >>=20 >>

    Routing Directorate Review Template

    >>=20 >>

    To: >>

  • rtg-ads@tools.ietf.org
    • >>

    Cc: >>

  • rtg-dir@ietf.org;
    • >>
  • draft-name.all@tools.ietf.org;
    • >>

    Subject: >>

  • RtgDir review: draft-name-version.txt
    • >>=20 >>=20 >> It seems reasonable to expose the reviews and subsequent discussions to = the WG. >> Would anyone object to us adding ... >>=20 >>
  • wg-mailing-list
    • >>=20 >> to the cc list? >>=20 >> I can see two problems with this... >>=20 >> 1. A little research is needed to work out the WG mailing list name beca= use they >> are not all perfectly intuitive. I don't think this is beyond your capab= ilities >> to handle. >>=20 >> 2. Not all reviewers will be members of the WG lists and signing up is b= oth a >> pain and risks a DoS on your inbox. However, all lists have moderators a= nd they >> should be able to admit your messages for the short exchange that will f= ollow. >>=20 >> Thoughts? >>=20 >> Adrian >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From loa@pi.nu Tue Sep 4 23:05:01 2012 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 715C621F84D2 for ; Tue, 4 Sep 2012 23:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 9nkoxFKre5Na for ; Tue, 4 Sep 2012 23:05:00 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2730F21F84CD for ; Tue, 4 Sep 2012 23:04:59 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id D175C2A8003 for ; Wed, 5 Sep 2012 08:04:57 +0200 (CEST) Message-ID: <5046EB8A.8090501@pi.nu> Date: Wed, 05 Sep 2012 08:04:58 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: rtg-dir@ietf.org References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> <50467930.60701@labn.net> <64AD74D7-5EEC-415A-B007-382FF682ACCC@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 05 Sep 2012 06:05:01 -0000 +1 I think the second problem that Adrian lists is really two problems. - to send the comments to the wg list; the list admins can handle this or you could ask someone to forward your comments to the list - to participating in (even be aware of) a discussion that follow from comments you send to a wg mailing list you are not subscribed to. I guess that the authors will be interested in an acknowledgement that your comments has been correctly addressed and that you will be pinged if you don't respond. Also considering the "Reply All" culture we live this might be a very minor problem. /Loa On 2012-09-05 04:26, Ross Callon wrote: > +1 > > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Acee Lindem > Sent: Tuesday, September 04, 2012 7:31 PM > To: Lou Berger > Cc: adrian@olddog.co.uk; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews > > +1 > On Sep 4, 2012, at 5:57 PM, Lou Berger wrote: > >> I think this is a good idea. I think any substantive review, and >> related discussion, should be of interest to the WG that produced the draft. >> >> Lou >> >> On 9/4/2012 4:38 PM, Adrian Farrel wrote: >>> Hi, >>> >>> The current Routing Directorate charter includes a template for review that >>> suggests recipients... >>> >>> >>>

    Routing Directorate Review Template

    >>> >>>

    To: >>>

  • rtg-ads@tools.ietf.org
    • >>>

    Cc: >>>

  • rtg-dir@ietf.org;
    • >>>
  • draft-name.all@tools.ietf.org;
    • >>>

    Subject: >>>

  • RtgDir review: draft-name-version.txt
    • >>> >>> >>> It seems reasonable to expose the reviews and subsequent discussions to the WG. >>> Would anyone object to us adding ... >>> >>>
  • wg-mailing-list
    • >>> >>> to the cc list? >>> >>> I can see two problems with this... >>> >>> 1. A little research is needed to work out the WG mailing list name because they >>> are not all perfectly intuitive. I don't think this is beyond your capabilities >>> to handle. >>> >>> 2. Not all reviewers will be members of the WG lists and signing up is both a >>> pain and risks a DoS on your inbox. However, all lists have moderators and they >>> should be able to admit your messages for the short exchange that will follow. >>> >>> Thoughts? >>> >>> Adrian >>> >>> >>> >>> >>> >>> >>> >>> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From dimitri.papadimitriou@alcatel-lucent.com Wed Sep 5 00:43:10 2012 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 3B41721F84F5 for ; Wed, 5 Sep 2012 00:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 f3ntH0xqJhwk for ; Wed, 5 Sep 2012 00:43:08 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 984C321F855A for ; Wed, 5 Sep 2012 00:43:07 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q857h2MM023566 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 09:43:03 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 5 Sep 2012 09:43:02 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lou Berger Date: Wed, 5 Sep 2012 09:43:00 +0200 Thread-Topic: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 Thread-Index: Ac2K578McOIY7NR/R3O7XuETEMnEjwAAJV+w Message-ID: References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> In-Reply-To: <5046785D.6050700@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 07:43:10 -0000 Lou, see below, > -----Original Message----- > From: rtg-dir-bounces@ietf.org > [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, September 04, 2012 23:54 > To: Papadimitriou, Dimitri (Dimitri) > Cc: adrian@olddog.co.uk; > draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > > Dimitri, > See below. > > On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: > > Hi Lou, > > > > See inline: > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Tuesday, September 04, 2012 17:25 > >> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) > >> Cc: rtg-dir@ietf.org; draft-ietf-ccamp-assoc-ext.all@tools.ietf.org > >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > >> > >> Adrian, > >> Much Thanks. (BTW is there a reason not to include the > >> WG in this, or > >> such, discussions?) > >> > >> Dimitri, > >> Please see below for inline responses. > >> > >> On 8/31/2012 1:02 PM, Adrian Farrel wrote: > >>> Here is Dimitri's Routing Dir review. Many thanks for the review. > >>> > >>> Lou, you can address this and the other comments and post a > >> new revision. > >>> > >>> Adrian > >>> > >>>> -----Original Message----- > >>>> From: Papadimitriou, Dimitri (Dimitri) > >> [mailto:dimitri.papadimitriou@alcatel- > >>>> lucent.com] > >>>> Sent: 31 August 2012 13:23 > >>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; sbryant@cisco.com; > >>>> huawei.danli@huawei.com > >>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 > >>>> > >>>> Hi All, > >>>> > >>>> Here below the review of this document. > >>>> > >>>> Technical comments: > >>>> > >>>> - Example 3: isn't this extension also not updating RFC 2205 ? > >> > >> Yes. This is stated in the header, abstract and section 3. > > > > I thought to include this in the introduction since other > updated RFC are indicated. > > > > Agreed. Text has been added. OK. > >>>> - The statement "In order to support the more general > usage of the > >>>> ASSOCIATION object," is actually not correct RFC 4872 > >> doesn't prevent support > >>> of > >>>> other usage of the ASSOCIATION object. It has just > >> documented its usage in the > >>>> GMPLS recovery context. > >> > >> I'm not sure how these two statements (the document text > and your last > >> sentence) are mutually inconsistent. I see no text change > >> based on this comment. > > > > I meant: "In order to document the more general usage of > the ASSOCIATION object, ..." > > > > While I don't mind the change in this part of the sentience, > the result > is a bit odd "In order to document the more general usage of the > ASSOCIATION object, this document ..." So will leave as is. "In order to document the more general usage of the ASSOCIATION object, thi= s specification ..." > >>>> - Section 3.1, "Cross-session association based on Path > >> state is defined in > >>>> [RFC4872]." the latter defines cross-LSP association > >> within the same session > >>> (not > >>>> cross-session association) but nothing prevents extending > >> usage to cross- > >>>> Session. > >>>> > >> > >> I see no text change requested based on this comment. > > > > I meant: "Cross-LSP association based on Path state is defined in > > [RFC4872]; here we document cross-session association..." > > I'll change two instances of "Cross-session association" to "Cross-LSP > association". OK. > >>>> - Section 3.1.2 the statement "the definition SHOULD allow > >> for association > >>> based > >>>> on identical ASSOCIATION objects" is not clear, does it > >> that the information > >>>> elements part of the object shall be identical ? > >> > >> I see no difference between the current text (object > equivalence) and > >> object information element equivalence. I don't believe > >> there's a case > >> where you can have one without the other. Please correct me if you > >> think I'm mistaken. > > > > If the association ID are defined such that: > > > > - the Association ID of Session 1 or LSP 1 points to the > Session ID or LSP ID of LSP 2 > > > > - the Association ID of Session 2 or LSP 2 points to the > Session ID or LSP ID of LSP 1 > > Association based on matching Association ID to Session ID is not part > of this draft. if the session ID isn't used - which is possible - documenting the ID setti= ng to ensure unicity (per association) is to be documented the definition o= nly states concerning value setting "A value assigned by the the node that originated the association. When combined with the other fields carried in the object, this value uniquely identifies an association." > > Other elements aren't necessarily identical. > > They must be identical in the context of this draft and the absence of > type-specific processing rules. > > > The setting of the association source is application type specific. > > Even if true, I don't see how this impacts the text of the draft. Because a full match (incl.association source) wouldn't apply anymore. I th= ink the point goes to the question does extension include association betwe= en sessions that uses two different source addresses that can be two interf= ace address ? > > Another case (if I am correctly understanding the related text), is > > related to the MPLS-TP section. The association object of two > > non-associated session can have the value fields in the > > ext.association object. > > This is a true statement, but unless the contents of the whole object > are identical, there's no association. In GMPLS you will have association source setting being identical for many = tunnels/LSPs (many controllers will set their local IP address as source) w= hile actually these LSPs aren't. I don't think there is any indication that= prevents this to happen ? > >>>> - Section 3.1.2 "The Association ID field MUST be set to a > >> value that uniquely > >>>> identifies the sessions to be associated within the > >> context of the Association > >>>> Source field." > >>>> this statement is not compatible with e.g. RFC 4873 and > >> 4872 where > >>> Association > >>>> ID are set to LSP ID and not sessions while it is stated in 3.1 " > >> > >> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" > > > > Yes and section 3.1.2 indicates "These procedures > > apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > session state." > > > > don't you think this induces confusion ? > > Perhaps, but this is why the 3.1 states: > This section does not modify processing required to support > [RFC4872] > and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. This being said the Code point for RFC 4873 isn't changed but points to thi= s document. Any reason since there is no processing change ? > >> so it does not impact to RFC 4873 and 4872 > implementations. As stated > >> in the draft and quoted by you: > >> > >>> This section > >>> does not > >>>> modify processing required to support [RFC4872] and > >> [RFC4873], and which is > >>>> reviewed in Section 3 of [RFC6689]. " > > > > The point I am raising is that Section 3.1 reads as there no > > "additions" whereas once reaching Section 3.1.2 one understands that > > the statement no modifications meant actually extensions. > > > > Section 3.1 states "This section does not modify processing > required to > > support [RFC4872] and [RFC4873], and which is reviewed > in Section 3 > > of [RFC6689]. " > > > > Section 3.1.2 states " These procedures > > apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > session state." > > > > Hence, > > > > Section 3.1.2 should be rephrased as > > > > "This section is based on the processing rules described > in [RFC4872] > > and [RFC4873], and which is reviewed in [RFC6689]. > These procedures > > apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > session state." > > > > Section 3.1.2 should be rephrased as > > > > "This section generalizes the processing rules described > in [RFC4872] > > and [RFC4873], and which is reviewed in [RFC6689], for > application > > to MPLS LSPs and non-LSP session state. For GMPLS LSP rules are > > extended for applications not related to the recovery > and resource > > sharing." > > I've revised the text to read: > > This section is based on, and extends, the processing rules > described in [RFC4872] and [RFC4873], and which is reviewed in > [RFC6689]. This section applies equally to GMPLS LSPs, MPLS LSPs > and non-LSP session state. Note, as previously stated, this > section does not modify processing required to support [RFC4872] > and [RFC4873]. OK. > >> 2) I also think "not compatible" is an overstatement, but > I guess that > >> it isn't really a critical point to discuss as the referenced text > >> doesn't relate to [RFC4872] and [RFC4873]. > > > > The proposed phrasing would resolve it. > > > >>>> and in RFC 4873/Section 3.2 "The > >>>> ASSOCIATION object is used to associate different LSPs > >> with each other." > >> > >> I see no text change requested based on this comment. > > > > Ditto. > > > >>>> - Section 3.1.2 "An association is deemed to exist when > >> the same values are > >>>> carried in all fields of the ASSOCIATION objects being > >> compared." this > >>> introduces > >>>> an additional level of indirection. To associate A to B A > >> can simply refer to > >>> an > >>>> identifier of B (and vice versa), A doesn't need to have > >> an additional ID > >>> (e.g. C) > >>>> that is also associated to B. Generalization would consist > >> here in introducing > >>> an > >>>> ext.association ID common to A, B, and C. In other terms, > >> generalizing the > >>> notion > >>>> of association doesn't require the introduction of an > >> additional level of > >>>> indirection. > >> > >> I really have no idea what this comment means. There is no > >> indirection stated or implied by the text. > > > > It is the result of what the text implies and it is specifically > > related to the "Association ID". Implicitly the document mandates > > than this identifier can't take any value of existing fields > > identifying tunnels/LSPs. > > Not at all. As long as the IDs as consistently set across association > objects, an association will be made. Furthermore, type specific > processing can be defined that allows implicit mapping such as you > defined in 4872. The first item to check is the Association Type to distinguish between matc= hing processes. The statement "In the absence of Association Type-specific = rules for identifying association,.." was probably intended to state (to re= move the confusion of the statement "identifying assocation"): "If the ASSOCIATION type does not refer to Association Type-specific rules = for the processing of the ASSOCIATION object (in which case the Association= Type-specific rules SHALL be applied), ..." > >> It means test for simple equivalence, > >> i.e., (ASSOCIATION object of A) =3D (ASSOCIATION object of > B) and that's > >> it. There's no (session) ID referencing. Can you restate > >> your concern? > > > > My concern is this an equivalence between objects not an > assocation of sessions. > > > > Per this document, equivalence between objects identifies an > assocation > of sessions. This document does not generalize the session ID to > association ID matching that was part of 4872. The above text would clarify the point. > >>>> - Section 3.2.2 I understand triggers for Resv-initiated > >> associations aren't > >>>> documented but how to prevent a sender willing to demote > >> receiver-driven > >>>> associations ? > >> > >> Can you clarify this question? > > > > Let me put first in context. Generalization includes Rcv driven > > associations but only additions are documented. > > > >> Are you asking: > >> - how a Path sender can prevent a receiver initiated > association? (it > >> can't) > >> > >> - how a Resv sender removes an association? (it just removes > >> the object, no different from a path message) > > > > The corresponding processing is to be documented. Because one can > > also demote an association by having each LSP/session pointing to > > itself while keeping the object in the Path/Resv message. > > This sounds like the implicit matching rules in 4872. Such session ID > to association ID matching is not part of this document. I hear you but as the ASSOCIATION ID value setting doesn't state it can't b= e done, you can get the same result. You could even assume that changing ID to an unused but value would lead to= the same result (as matching wouldn't give a positive result the ASSOCIATI= ON would also be removed since it can't be found anymore). > >> - something else? > >> > >>>> - Section 3.1.2 and 3.2.2 no error processing is being documented > >> > >> I think this is a fair point. The only case I think that > >> can/should be > >> addressed is unknown types. (As is usual, per RFC2205, errors in > >> formats to not trigger any specific message response.) > >> Sections 3.1 and > >> 3.2 only discuss identification of associations, so I > propose adding a > >> section 3.3.2. How about something like: > >> > >> 3.3.2. Unknown Association Types > >> > >> A node that receives an ASSOCIATION object with an unknown > >> ASSOCIATION type MUST forward all received ASSOCIATION objects > >> as defined above. The node MAY also identify associations per > >> the defined processing, e.g., to make this information available > >> via a management interface. > > > > OK. Wouldn't you document PathErr/ResvErr and Notify ? > > IMO Not for an unknown type. I don't understand the answer. > >>>> whereas mis- > >>>> match in association should be considered as a generic error. > >> > >> This isn't a detectable error case as it is impossible for > a node to > >> know if two association objects are intentionally or > unintentionally > >> different. > > > > Earlier, in the text it is mentioned that processing > implies checking > > all Path/Resv state. We have to understand that putting in place a > > generic processing (outside a specific ASSOCIATION Type) renders > > I think this sentence got truncated... ... safeguard rule advisable. > >>>> - Section 3.3 states "Since the admission control function > >> is outside the > >>> scope of > >>>> RSVP,..." are you sure ? > >> > >> Yes. Per RFC2205: > > > > Yes I know the figuere whose terms mixes functions, protocol > > processes, etc. but this goes beyond the review of this document ;-) > > > > >> HOST ROUTER > >> > >> _____________________________ ____________________________ > >> | _______ | | | > >> | | | _______ | | _______ | > >> | |Appli- | | | |RSVP | | | | > >> | | cation| | RSVP <---------------------------> RSVP > <----------> > >> | | <--> | | | _______ | | | > >> | | | |process| _____ | ||Routing| |process| _____ | > >> | |_._____| | -->Polcy|| || <--> -->Polcy|| > >> | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| > >> | |data | | |_____|| ||__.____| | | |_____|| > >> |=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D|=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D| |=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D|=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D| > >> | | --------| | _____ | | | --------| | _____ | > >> | | | | ---->Admis|| | | | | ---->Admis|| > >> | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| > >> | | | | | |_____|| | | | | ||_____|| > >> | |Class-| | Packet | | | |Class-| | Packet | | > >> | | ifier|=3D=3D>Schedulr|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D> > ifier|=3D=3D>Schedulr|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> > >> | |______| |________| |data | |______| |________| > |data > >> | | | | > >> |_____________________________| |____________________________| > >> > >> > >> Figure 1: RSVP in Hosts and Routers > >> > >> an RSVP QoS request is passed to two local > >> decision modules, "admission control" and "policy control". > >> > >>>> admission control is an intrinsic function associated > >>> to RFC > >>>> 2205 (there are errors documented for admission control > >> failures). I think you > >>>> mean that the inner working of the mechanisms used by > >> nodes to determine if > >>>> they have sufficient available resources to support > >> incoming requests. > >> > >> I think this is the same as what is stated. > > > > What you mean is: the inner-working or implementation of admission > > control for QoS requests is outside scope of RFC 2205. > > > >> we can add "implementation specifics ", i.e., " Since the > >> implementation > >> specifics of the admission control function is outside the > >> scope " if it helps. > > > > Yes it does because the term "outside scope" has different > meanings depending on context. > > > > done. > > >>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION > >> object and the IPv6 > >>>> ASSOCIATION object. As defined, these objects each contain > >> an Association > >>>> Source field and a 16-bit Association ID field. The > >> combination of the > >>> Association > >>>> Source and the Association ID uniquely identifies the > >> association." but in the > >>>> context RFC 4872 this association is defined in the > >> context of the same tunnel > >>>> end-point > >> > >> How about we clarify: "*As described above,* the > >> combination of the Association Source and the Association ID > >> uniquely identifies the association." > > > > It would be better to state > > > > "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > > ASSOCIATION object in the context of a given session. As defined, > > these objects each contain an Association Source field and a 16-bit > > Association ID field. The combination of the Association Source and > > the Association ID uniquely identifies the association. This doesn't > > prevent that Association Types MAY further specify the context for > > which this association is defined." > > It now reads: > > [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > ASSOCIATION object. As defined, these objects each contain an > Association Source field and a 16-bit Association ID field. As > described above, the contents of the object uniquely identifies > an association. Because the Association ID field is a 16-bit > field, an association source can allocate up to 65536 different > associations and no more. OK > >>> (and actually the same for RFC 4873 which relies on MBB as defined > >>> in > >>>> RFC 3209) > >> > >> I don't believe this statement is correct, but again this > is really a > >> discussion beyond this draft. > > > > The statement here above is also to applicable to RFC 4873. > > > >>>> - Section 4: How is the following use case "There are > >> scenarios where this > >>> number > >>>> is insufficient. (For example where the association > >> identification is best > >>> known > >>>> and identified by a fairly centralized entity, which > >> therefore may be involved > >>> in a > >>>> large number of associations.)" related to those proposed > >> in the introduction. > >>> ? > >> > >> As I read it, it enables practical third party (e.g., > >> management entity) > >> creation and management of association IDs. But, I'll defer to my > >> coauthors on this. > > > > OK. Please let me know the result(s) of the discussion. > > > >>>> - Section 4: I don't question the requirement stated in > >> "Per [RFC6370], > >>> MPLS-TP > >>>> LSPs can be identified based on an operator unique global > >> identifier. The > >>>> [RFC6370] defined "global identifier", or Global_ID, is > >> based on [RFC5003] and > >>>> includes the operator's Autonomous System Number (ASN)." > >> the question is why > >>>> the information is best encoded as part of the ASSOCIATION > >> object ? isn't this > >>> an > >>>> LSP ATTRIBUTE or a Session Name ? > >> > >> It's the solution the WG agreed to. Other options are of > >> course possible. > > > > My comment is specific because it triggers the question on how many > > objects will we end up in spreading identification information (it > > would be interesting to document the why this was felt the most > > suited object as it is not a natural choice); more general > comment is > > what defines the "acceptable" use/extension of association. > > I think the last comment is a reasonable discussion to have. Not sure > it belongs in, or gates the discussion. The LSP attributes RFC included this info for instance. This has prevented = lots of problems in use of the object because the content of most objects c= ould have been added to the LSP attribute RFC (cf. Sect.8 "8. Summary of A= ttribute Bit Allocation" and Sect.10 "Guidance for Key Application Scenario= s"). > >>>> - Section 4.2: states "It is important to note that > >> Section 4 defines > >>> association > >>>> identification based on ASSOCIATION object matching, and > >> that such matching > >>> is > >>>> based on the comparison of all fields in a ASSOCIATION > >> object (unless type- > >>>> specific comparison rules are defined). This applies > >> equally to ASSOCIATION > >>>> objects and Extended ASSOCIATION objects." any association > >> is based on a form > >>>> of matching, point here is that the matching and the > >> identification of the > >>> initiation > >>>> of the matching information are distinct information > >> entities (difference > >>> between > >>>> WHO and WHAT). I suggest to make a clearer distinction and > >> specify setting and > >>>> processing accordingly. > >> > >> I'm not seeing the issue. Can you perhaps propose some text? > > > > Here is the proposed text > > > > "It is important to note that Section 4 defines association > > identification based on ASSOCIATION object matching, and > > that such matching is based on the comparison of the fields > > as determined by the ASSOCIATION Type of the ASSOCIATION > > object. This applies equally to ASSOCIATION objects and > > Extended ASSOCIATION objects." > > Here's the revised text. > Identification of association is not modified by this section. It > is important to note that Section 4 defines association > identification based on ASSOCIATION object matching, and that such > matching, in the absence of type-specific comparison rules, is > based on the comparison of all fields in an ASSOCIATION object. > This applies equally to ASSOCIATION objects and Extended > ASSOCIATION objects. I would write (look at the text just above where you state "As defined, the= se objects each contain an Association Source field and a 16-bit Associatio= n ID field. As described above, the contents of the object uniquely identi= fies an association." ... there is a need to distinguish between identifyin= g the ASSOCIATION object vs matching ASSOCIATION objects). This would "The procedure to perform ASSOCIATION object matching as defined in S= ection 4 is not modified by this section. It is important to note that Sect= ion 4 defines ASSOCIATION object matching if the ASSOCIATION type does not = refer to Association Type-specific rules for the processing of the ASSOCIAT= ION object (in which case the Association Type-specific rules SHALL be appl= ied); otherwise, ASSOCIATION object matching applies by comparing all field= s in an ASSOCIATION object. This procedure applies equally to ASSOCIATION o= bjects and Extended ASSOCIATION objects." > >>>> - Section 4.2: shouldn't "error processing" being documented ? > >> > >> Here too, I think the only error processing is as discussed above. > >> Shout if you think otherwise. > >> > >>>> Example include > >>>> admission control where receiving node rejects the > >> incoming Path msg if the > >>>> originating Global_ID/Ext.ASSOCIATION object isn't included, > >> > >> Interesting, but this is a type specific error. To me this > >> sounds like > >> a new admission control error that should be defined as part of the > >> type-specific definition. > > > > Admission control failures are part of the error codes > defined in RFC 2205. > > exactly! > > >>>> unauthorized > >>>> Global ID ? > >> > >> Again interesting, but this is a new policy (and policy error) that > >> wasn't proposed or discussed in the WG. I think this > would be a fine > >> addition, but is beyond the current document discussion. It > >> could always be added if proposed. > > > > I defer this point to the AD. > > WFM. > > > > >>>> etc. but also mismatches between Association source and Global > >>>> Association source ? > >> > >> How would such a thing be detected, by checking BGP state? > I guess we > >> could add a new error code, but again I think we're going > beyond the > >> intent of the document/WG. > > > > Same here. > > > >>>> - Section 4.1 and 4.2: the former states "The [RFC6370] > >> defined global > >>> identifier, > >>>> or Global_ID, is based on [RFC5003] and includes the > >> operator's Autonomous > >>>> System Number (ASN)." while the latter "the use of the > >> Global_ID is not > >>> related > >>>> to the use of the ASN in protocols such as BGP." which one > >> applies ? > >> > >> I'll drop the note. This is better aligned with the field > definition > >> which has been updated based on comments of other reviewers. > >> > >> The current definition is: > >> > >> This field contains a value that is a unique global > identifier or > >> the special value zero (0). When non-zero and not > overridden by > >> local policy, the Global_ID as defined in [RFC6370] > SHALL be used. > >> The special value of zero indicates that no global > identifier is > >> present. Use of the special value of zero SHOULD be limited to > >> entities contained within a single operator. > > > > OK > > > >>>> - Section 5 Documenting means to prevent/mitigate > >> mis-association(s) and > >>>> possible impact on security would be advisable. If this is > >> felt to be > >>> "application" or > >>>> "type" specific a recommendation should be stated that the > >> security mechanisms > >>>> have to be documented as part of these documents. > >> > >> Why is there any additional risk than what " was > previously defined in > >> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) > > > > I try to prevent that any further use/documents would state "no > > additional risk compared to RFC 4872 and RFC 4873" or equivalent but > > the application is running for voice calls over the > Internet which is > > a totally different application than G/MPLS Recovery/Resource > > Sharing. > > Fair enough, but what additional issues do you foresee that should be > covered? Nodes associating sessions, etc. should have the mean to verify the initiat= or of the association. > >>>> Editorials: > >>>> > >>>> - Introduction: "This document expands the possible usage > >> of the ASSOCIATION > >>>> object to > >>>> non-GMPLS and non-recovery contexts." Suggested to state > >> the actual the > >>>> scope includes RSVP (instead of what it is not) > >> > >> I'll add: > >> The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS > >> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], > >> [RFC3175] and [RFC4860]. > > > > OK. > > > >>>> - Introduction: s/different ports/different destination > (dst) ports > >>>> > >> > >> sure. > >> > >>>> - Section 2 would better refer to a "Generalization" > rather than a > >>> "modification" > >>>> > >> > >> I'd be okay with this, but I think modification makes is less > >> likely to be misinterpreted so will leave as is. > > > > The term modification implies a change in existing processing (even > > if the intention is different) and actually as the applicability is > > now possible to RSVP and MPLS-TE. > > This isn't a major point for me, so will change it. (In 5 places.) OK (actually the doc. generalizes the use of the object whereas 4873 for in= st documents type-specific/specialized use of the object) > >>>> - Section 3 states "As defined by [RFC4872] and reviewed > >> in [RFC6689],..." but > >>> an > >>>> information RFC doesn't review at best "documents" > >> certain usage. This > >>>> statement is repeated at multiple places. > >> > >> Why can't it review? This is what the abstract of RFC6689 > >> says it does. > > > > It was overstated in RFC 6689. > > This document doesn't change 6689. OK. > >>>> - Section 3 mentions "Object usage in both Path and Resv > >> messages is > >>> discussed. > >>>> The usage applies equally to > >>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP > >> RSVP sessions > >>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having > >> such statement in the > >>>> introduction would desirable. > >> > >> Fair enough. > >> > >> Thank you for the review! > > > > OK. > > > > Thanks, > > -d. > > Thanks, > Lou Thanks, -d. > >> Lou > >> > >>>> > >>>> > >>>> ----- > >>>> Homepage: > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > > > > > > > > > From Alexander.Vainshtein@ecitele.com Wed Sep 5 01:08:00 2012 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 5436921F8699 for ; Wed, 5 Sep 2012 01:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 Yobg5MfTeOsL for ; Wed, 5 Sep 2012 01:07:59 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 48C3021F8697 for ; Wed, 5 Sep 2012 01:07:59 -0700 (PDT) Received: from [85.158.143.35:24084] by server-3.bemta-4.messagelabs.com id 6F/34-08232-D5807405; Wed, 05 Sep 2012 08:07:57 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1346832305!6260101!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 32438 invoked from network); 5 Sep 2012 08:05:05 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-4.tower-21.messagelabs.com with SMTP; 5 Sep 2012 08:05:05 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-b8-504702b1169d Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 13.7D.06426.1B207405; Wed, 5 Sep 2012 10:43:45 +0300 (IDT) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 5 Sep 2012 11:01:16 +0300 Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::3d43:17d7:650c:68d8%12]) with mapi id 14.01.0379.000; Wed, 5 Sep 2012 11:01:16 +0300 From: Alexander Vainshtein To: "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: Ac2K3S3YqpFtAiLCSGKUuZODHvFqpP//48kAgAAaH4CAADEXgIAAPRwA//+tRfA= Date: Wed, 5 Sep 2012 08:01:16 +0000 Message-ID: References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> <50467930.60701@labn.net> <64AD74D7-5EEC-415A-B007-382FF682ACCC@ericsson.com> <5046EB8A.8090501@pi.nu> In-Reply-To: <5046EB8A.8090501@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTeWwMURzHvZntdro6TEdrnzoyGVeKlV1Hs46lEve5CUIINXae3YnZmTUz xErEIkgaoVLSWMpKt6rqSBCVaCKaEipYCSEocVaXulYd/UPNGKr++/7e7/t9n9+beY/A6Y/W XEKQNKRInMhabZaS5OekYy8+zes8/b2P+2fZQdwdO/EqvQCbHo//wKZHS7dbvdiSCBjPSZKs cRpieKT6PKxXEdZxvjDLCLyHdbFMSOR8KIgkzcNyoRCSeHaCbby+KEgMknwyL0h+Dztj/jyH 2z16jMPFThjU3zVynG1BQFAZ5AhygsgEkapyfsToK8aEEo94ZpWsMFoAMcqKEjyQ2lGLh470 Wn++8Y01AlrpIpBBQGoUvFpcazV1T5h4clrXNoKmLgF47f4nzCxqAEwVV/4p6gFsOXYr3YhY KQ88U934O55N5cE3Fc9/a5zqC5ti5bihe1AF8GSr6c+mJsGtm3fomtD1XBg7KxrSQg2Aietz DAdJeWHy1CFgopoB3PbjKWZ4MqiBsGrvDMMD9EG/NZzATJIdPnx5GDMPQMF47W3c1Dmw+cXP NFP3g1uq7qab/mEwdvHznymHwqNH3uImNwte3//SYmiacsCGa0VYMYDRTohop3i0UzzaKR4D luMgRxBD2sqg3+kajnyChkQ03CcHzwDzvjRdAG2HB9QBigBsJtll1lQvncatU8PBOtCLwNgc cqF1mpfutlLmwwFODRQqa0Wk1gFI4Gw2+ah6ipcmeS68ASny35Zb/4B78NyuPtn471rhSKfz v4K1k5WRRfNoyq9fwNUIhZDyN9qHIFhIdk3XiVkK8qP1qwRR+9fGiAyDnKmTvxhTkWqIC6qC 3+w3AAfREr3VCGiLJEso106+NkyUYQqslTr2MR7Kpvb29iSw62fuQbYarkz9knbslNQhmA6Z 8mGyAdEfSkcrNwIunytrU2/vi2d9/FaYyHtRkGjrMid/UlP0zs6JIy70vF9ujzzuftF2pbnk fc3S+ks3JeLZ8TX59V9rdr97sKw0NbO6YtDgcHj2orsrVm8pWLxv8qikvMtZlXp0oKJla8v7 vNSa/MSNwUVxcRzv7L184PcN3dMqsejGsUK5G5Tdq4t5u7EWNcC5huCKyv0CZPqy5AMEAAA= Cc: Loa Andersson Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 05 Sep 2012 08:08:00 -0000 +1 Regards, Sasha > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: Wednesday, September 05, 2012 9:05 AM > To: rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews > > +1 > > I think the second problem that Adrian lists is really two problems. > > - to send the comments to the wg list; the list admins can handle this > or you could ask someone to forward your comments to the list > - to participating in (even be aware of) a discussion that follow from > comments you send to a wg mailing list you are not subscribed to. I > guess that the authors will be interested in an acknowledgement that > your comments has been correctly addressed and that you will be > pinged if you don't respond. Also considering the "Reply All" culture > we live this might be a very minor problem. > > /Loa > > On 2012-09-05 04:26, Ross Callon wrote: > > +1 > > > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Acee Lindem > > Sent: Tuesday, September 04, 2012 7:31 PM > > To: Lou Berger > > Cc: adrian@olddog.co.uk; rtg-dir@ietf.org > > Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews > > > > +1 > > On Sep 4, 2012, at 5:57 PM, Lou Berger wrote: > > > >> I think this is a good idea. I think any substantive review, and > >> related discussion, should be of interest to the WG that produced the > draft. > >> > >> Lou > >> > >> On 9/4/2012 4:38 PM, Adrian Farrel wrote: > >>> Hi, > >>> > >>> The current Routing Directorate charter includes a template for review > that > >>> suggests recipients... > >>> > >>> > >>>

    Routing Directorate Review Template

    > >>> > >>>

    To: > >>>

  • rtg-ads@tools.ietf.org
    • > >>>

    Cc: > >>>

  • rtg-dir@ietf.org;
    • > >>>
  • draft-name.all@tools.ietf.org;
    • > >>>

    Subject: > >>>

  • RtgDir review: draft-name-version.txt
    • > >>> > >>> > >>> It seems reasonable to expose the reviews and subsequent discussions > to the WG. > >>> Would anyone object to us adding ... > >>> > >>>
  • wg-mailing-list
    • > >>> > >>> to the cc list? > >>> > >>> I can see two problems with this... > >>> > >>> 1. A little research is needed to work out the WG mailing list name > because they > >>> are not all perfectly intuitive. I don't think this is beyond your cap= abilities > >>> to handle. > >>> > >>> 2. Not all reviewers will be members of the WG lists and signing up is > both a > >>> pain and risks a DoS on your inbox. However, all lists have moderators > and they > >>> should be able to admit your messages for the short exchange that will > follow. > >>> > >>> Thoughts? > >>> > >>> Adrian > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 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 thomas.morin@orange.com Wed Sep 5 03:11:24 2012 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 0E0B121F86A4 for ; Wed, 5 Sep 2012 03:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 Z2yAyDc7kVAH for ; Wed, 5 Sep 2012 03:11:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21021F869D for ; Wed, 5 Sep 2012 03:11:23 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2F0A12646D0 for ; Wed, 5 Sep 2012 12:11:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1541C238071 for ; Wed, 5 Sep 2012 12:11:22 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 12:11:21 +0200 From: To: "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: Ac2K3S3YqpFtAiLCSGKUuZODHvFqpP//9I0AgAAaHoCAADEXgIAAPRwAgABFHwA= Date: Wed, 5 Sep 2012 10:11:20 +0000 Message-ID: <10549_1346839882_5047254A_10549_4342_1_50472586.3040906@orange.com> References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> <50467930.60701@labn.net> <64AD74D7-5EEC-415A-B007-382FF682ACCC@ericsson.com> <5046EB8A.8090501@pi.nu> In-Reply-To: <5046EB8A.8090501@pi.nu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-ID: <8476BB3AC269A4469AF408B5272ADF37@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.5.90324 Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 05 Sep 2012 10:11:24 -0000 SSBhZ3JlZSB0aGlzIGlzIGEgZ29vZCBpZGVhLCBhbmQgdGhhdCB0aGUgcG90ZW50aWFsIHByb2Js ZW1zIGFyZSBsaWtlbHkgDQp0byBwcm92ZSBtaW5vci4NCg0KLVRob21hcw0KDQpMb2EgQW5kZXJz c29uIDoNCj4gKzENCj4NCj4gSSB0aGluayB0aGUgc2Vjb25kIHByb2JsZW0gdGhhdCBBZHJpYW4g bGlzdHMgaXMgcmVhbGx5IHR3byBwcm9ibGVtcy4NCj4NCj4gLSB0byBzZW5kIHRoZSBjb21tZW50 cyB0byB0aGUgd2cgbGlzdDsgdGhlIGxpc3QgYWRtaW5zIGNhbiBoYW5kbGUgdGhpcw0KPiAgIG9y IHlvdSBjb3VsZCBhc2sgc29tZW9uZSB0byBmb3J3YXJkIHlvdXIgY29tbWVudHMgdG8gdGhlIGxp c3QNCj4gLSB0byBwYXJ0aWNpcGF0aW5nIGluIChldmVuIGJlIGF3YXJlIG9mKSBhIGRpc2N1c3Np b24gdGhhdCBmb2xsb3cgZnJvbQ0KPiAgIGNvbW1lbnRzIHlvdSBzZW5kIHRvIGEgd2cgbWFpbGlu ZyBsaXN0IHlvdSBhcmUgbm90IHN1YnNjcmliZWQgdG8uIEkNCj4gICBndWVzcyB0aGF0IHRoZSBh dXRob3JzIHdpbGwgYmUgaW50ZXJlc3RlZCBpbiBhbiBhY2tub3dsZWRnZW1lbnQgdGhhdA0KPiAg IHlvdXIgY29tbWVudHMgaGFzIGJlZW4gY29ycmVjdGx5IGFkZHJlc3NlZCBhbmQgdGhhdCB5b3Ug d2lsbCBiZQ0KPiAgIHBpbmdlZCBpZiB5b3UgZG9uJ3QgcmVzcG9uZC4gQWxzbyBjb25zaWRlcmlu ZyB0aGUgIlJlcGx5IEFsbCIgY3VsdHVyZQ0KPiAgIHdlIGxpdmUgdGhpcyBtaWdodCBiZSBhIHZl cnkgbWlub3IgcHJvYmxlbS4NCj4NCj4gL0xvYQ0KPg0KPiBPbiAyMDEyLTA5LTA1IDA0OjI2LCBS b3NzIENhbGxvbiB3cm90ZToNCj4+ICsxDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IHJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1kaXItYm91 bmNlc0BpZXRmLm9yZ10gT24gDQo+PiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0NCj4+IFNlbnQ6IFR1 ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiA3OjMxIFBNDQo+PiBUbzogTG91IEJlcmdlcg0KPj4g Q2M6IGFkcmlhbkBvbGRkb2cuY28udWs7IHJ0Zy1kaXJAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJl OiBbUlRHLURJUl0gUmVjaXBpZW50cyBvZiBSb3V0aW5nIERpcmVjdG9yYXRlIFJldmlld3MNCj4+ DQo+PiArMQ0KPj4gT24gU2VwIDQsIDIwMTIsIGF0IDU6NTcgUE0sIExvdSBCZXJnZXIgd3JvdGU6 DQo+Pg0KPj4+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYS4gIEkgdGhpbmsgYW55IHN1YnN0 YW50aXZlIHJldmlldywgYW5kDQo+Pj4gcmVsYXRlZCBkaXNjdXNzaW9uLCBzaG91bGQgYmUgb2Yg aW50ZXJlc3QgdG8gdGhlIFdHIHRoYXQgcHJvZHVjZWQgDQo+Pj4gdGhlIGRyYWZ0Lg0KPj4+DQo+ Pj4gTG91DQo+Pj4NCj4+PiBPbiA5LzQvMjAxMiA0OjM4IFBNLCBBZHJpYW4gRmFycmVsIHdyb3Rl Og0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gVGhlIGN1cnJlbnQgUm91dGluZyBEaXJlY3RvcmF0ZSBj aGFydGVyIGluY2x1ZGVzIGEgdGVtcGxhdGUgZm9yIA0KPj4+PiByZXZpZXcgdGhhdA0KPj4+PiBz dWdnZXN0cyByZWNpcGllbnRzLi4uDQo+Pj4+DQo+Pj4+DQo+Pj4+IDxIMz5Sb3V0aW5nIERpcmVj dG9yYXRlIFJldmlldyBUZW1wbGF0ZTwvSDM+DQo+Pj4+DQo+Pj4+IDxQPlRvOg0KPj4+PiAgIDxM ST5ydGctYWRzQHRvb2xzLmlldGYub3JnPC9MST4NCj4+Pj4gPFA+Q2M6DQo+Pj4+ICAgPExJPnJ0 Zy1kaXJAaWV0Zi5vcmc7PC9MST4NCj4+Pj4gICA8TEk+ZHJhZnQtbmFtZS5hbGxAdG9vbHMuaWV0 Zi5vcmc7PC9MST4NCj4+Pj4gPFA+U3ViamVjdDoNCj4+Pj4gICA8TEk+UnRnRGlyIHJldmlldzog ZHJhZnQtbmFtZS12ZXJzaW9uLnR4dDwvTEk+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEl0IHNlZW1zIHJl YXNvbmFibGUgdG8gZXhwb3NlIHRoZSByZXZpZXdzIGFuZCBzdWJzZXF1ZW50IA0KPj4+PiBkaXNj dXNzaW9ucyB0byB0aGUgV0cuDQo+Pj4+IFdvdWxkIGFueW9uZSBvYmplY3QgdG8gdXMgYWRkaW5n IC4uLg0KPj4+Pg0KPj4+PiA8TEk+d2ctbWFpbGluZy1saXN0PC9MST4NCj4+Pj4NCj4+Pj4gdG8g dGhlIGNjIGxpc3Q/DQo+Pj4+DQo+Pj4+IEkgY2FuIHNlZSB0d28gcHJvYmxlbXMgd2l0aCB0aGlz Li4uDQo+Pj4+DQo+Pj4+IDEuIEEgbGl0dGxlIHJlc2VhcmNoIGlzIG5lZWRlZCB0byB3b3JrIG91 dCB0aGUgV0cgbWFpbGluZyBsaXN0IG5hbWUgDQo+Pj4+IGJlY2F1c2UgdGhleQ0KPj4+PiBhcmUg bm90IGFsbCBwZXJmZWN0bHkgaW50dWl0aXZlLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYmV5b25k IHlvdXIgDQo+Pj4+IGNhcGFiaWxpdGllcw0KPj4+PiB0byBoYW5kbGUuDQo+Pj4+DQo+Pj4+IDIu IE5vdCBhbGwgcmV2aWV3ZXJzIHdpbGwgYmUgbWVtYmVycyBvZiB0aGUgV0cgbGlzdHMgYW5kIHNp Z25pbmcgdXAgDQo+Pj4+IGlzIGJvdGggYQ0KPj4+PiBwYWluIGFuZCByaXNrcyBhIERvUyBvbiB5 b3VyIGluYm94LiBIb3dldmVyLCBhbGwgbGlzdHMgaGF2ZSANCj4+Pj4gbW9kZXJhdG9ycyBhbmQg dGhleQ0KPj4+PiBzaG91bGQgYmUgYWJsZSB0byBhZG1pdCB5b3VyIG1lc3NhZ2VzIGZvciB0aGUg c2hvcnQgZXhjaGFuZ2UgdGhhdCANCj4+Pj4gd2lsbCBmb2xsb3cuDQo+Pj4+DQo+Pj4+IFRob3Vn aHRzPw0KPj4+Pg0KPj4+PiBBZHJpYW4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+DQo+DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBU ZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4KVGhhbmsgeW91LgoK From nabil.n.bitar@verizon.com Wed Sep 5 04:32:52 2012 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 83D7E21F8653 for ; Wed, 5 Sep 2012 04:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 bPObXlQc5TsZ for ; Wed, 5 Sep 2012 04:32:51 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 986CB21F85EF for ; Wed, 5 Sep 2012 04:32:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 05 Sep 2012 11:32:50 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="324988616" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi03.verizon.com with ESMTP; 05 Sep 2012 11:32:50 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.182]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Wed, 5 Sep 2012 07:32:50 -0400 To: "thomas.morin@orange.com" , "rtg-dir@ietf.org" Date: Wed, 5 Sep 2012 07:32:47 -0400 Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: Ac2LWi5lBT9ixVAVRpmGtlbGZl+bfw== Message-ID: In-Reply-To: <10549_1346839882_5047254A_10549_4342_1_50472586.3040906@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 05 Sep 2012 11:32:52 -0000 Hi, Agreed with below. It will be good for a WG to know if there are any changes are made to a WG doc and potentially why. The only risk could be re-opening discussions already had but that should be controllable. The alternative would be to explicitly have in the process notification to the WG of changes made to the doc as a result of the discussions that the reviewers/Ads had agreed on and allow chance to have a review by the WG scoped to these changes. Thanks, Nabil On 9/5/12 6:11 AM, "thomas.morin@orange.com" wrote: >I agree this is a good idea, and that the potential problems are likely >to prove minor. > >-Thomas > >Loa Andersson : >> +1 >> >> I think the second problem that Adrian lists is really two problems. >> >> - to send the comments to the wg list; the list admins can handle this >> or you could ask someone to forward your comments to the list >> - to participating in (even be aware of) a discussion that follow from >> comments you send to a wg mailing list you are not subscribed to. I >> guess that the authors will be interested in an acknowledgement that >> your comments has been correctly addressed and that you will be >> pinged if you don't respond. Also considering the "Reply All" culture >> we live this might be a very minor problem. >> >> /Loa >> >> On 2012-09-05 04:26, Ross Callon wrote: >>> +1 >>> >>> -----Original Message----- >>> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On >>> Behalf Of Acee Lindem >>> Sent: Tuesday, September 04, 2012 7:31 PM >>> To: Lou Berger >>> Cc: adrian@olddog.co.uk; rtg-dir@ietf.org >>> Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews >>> >>> +1 >>> On Sep 4, 2012, at 5:57 PM, Lou Berger wrote: >>> >>>> I think this is a good idea. I think any substantive review, and >>>> related discussion, should be of interest to the WG that produced >>>> the draft. >>>> >>>> Lou >>>> >>>> On 9/4/2012 4:38 PM, Adrian Farrel wrote: >>>>> Hi, >>>>> >>>>> The current Routing Directorate charter includes a template for >>>>> review that >>>>> suggests recipients... >>>>> >>>>> >>>>>

    Routing Directorate Review Template

    >>>>> >>>>>

    To: >>>>>

  • rtg-ads@tools.ietf.org
    • >>>>>

    Cc: >>>>>

  • rtg-dir@ietf.org;
    • >>>>>
  • draft-name.all@tools.ietf.org;
    • >>>>>

    Subject: >>>>>

  • RtgDir review: draft-name-version.txt
    • >>>>> >>>>> >>>>> It seems reasonable to expose the reviews and subsequent >>>>> discussions to the WG. >>>>> Would anyone object to us adding ... >>>>> >>>>>
  • wg-mailing-list
    • >>>>> >>>>> to the cc list? >>>>> >>>>> I can see two problems with this... >>>>> >>>>> 1. A little research is needed to work out the WG mailing list name >>>>> because they >>>>> are not all perfectly intuitive. I don't think this is beyond your >>>>> capabilities >>>>> to handle. >>>>> >>>>> 2. Not all reviewers will be members of the WG lists and signing up >>>>> is both a >>>>> pain and risks a DoS on your inbox. However, all lists have >>>>> moderators and they >>>>> should be able to admit your messages for the short exchange that >>>>> will follow. >>>>> >>>>> Thoughts? >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >France Telecom - Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. > From lberger@labn.net Wed Sep 5 05:36:26 2012 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 650A021F8673 for ; Wed, 5 Sep 2012 05:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 ff5rgj7yD9yL for ; Wed, 5 Sep 2012 05:36:24 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 04CB821F8672 for ; Wed, 5 Sep 2012 05:36:23 -0700 (PDT) Received: (qmail 8008 invoked by uid 0); 5 Sep 2012 12:36:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 5 Sep 2012 12:36:22 -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=a201vVpgy1Dfyn1J2G+TocWPhyEOJTP5QBctt4n82kc=; b=uALZt92gOjSWFFbVTskiC6lH3j6BbavjSSE9xVZ+AoySg8rveYxs3onbHXNBwf5Fh3GVkgqZ2HRdh9C6WfQv298jNvvo5aL21OTeAdu3BIYQDzDRt9r/6wQ4Au8uxMoR; Received: from box313.bluehost.com ([69.89.31.113]:34111 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T9EqD-0007D0-EA; Wed, 05 Sep 2012 06:36:21 -0600 Message-ID: <50474748.1030303@labn.net> Date: Wed, 05 Sep 2012 08:36:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Papadimitriou, Dimitri (Dimitri)" References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.4 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: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 12:36:26 -0000 Hi Dimiri, Responses in line... On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:> Lou, > > see below, > >> -----Original Message----- >> From: rtg-dir-bounces@ietf.org >> [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: Tuesday, September 04, 2012 23:54 >> To: Papadimitriou, Dimitri (Dimitri) >> Cc: adrian@olddog.co.uk; >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >> >> Dimitri, >> See below. >> >> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: >>> Hi Lou, >>> >>> See inline: >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Tuesday, September 04, 2012 17:25 >>>> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) >>>> Cc: rtg-dir@ietf.org; draft-ietf-ccamp-assoc-ext.all@tools.ietf.org >>>> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >>>> >>>> Adrian, >>>> Much Thanks. (BTW is there a reason not to include the >>>> WG in this, or >>>> such, discussions?) >>>> >>>> Dimitri, >>>> Please see below for inline responses. >>>> >>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote: >>>>> Here is Dimitri's Routing Dir review. Many thanks for the review. >>>>> >>>>> Lou, you can address this and the other comments and post a >>>> new revision. >>>>> >>>>> Adrian >>>>> >>>>>> -----Original Message----- >>>>>> From: Papadimitriou, Dimitri (Dimitri) >>>> [mailto:dimitri.papadimitriou@alcatel- >>>>>> lucent.com] >>>>>> Sent: 31 August 2012 13:23 >>>>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; sbryant@cisco.com; >>>>>> huawei.danli@huawei.com >>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Here below the review of this document. >>>>>> >>>>>> Technical comments: >>>>>> >>>>>> - Example 3: isn't this extension also not updating RFC 2205 ? >>>> >>>> Yes. This is stated in the header, abstract and section 3. >>> >>> I thought to include this in the introduction since other >> updated RFC are indicated. >>> >> >> Agreed. Text has been added. > > OK. > >>>>>> - The statement "In order to support the more general >> usage of the >>>>>> ASSOCIATION object," is actually not correct RFC 4872 >>>> doesn't prevent support >>>>> of >>>>>> other usage of the ASSOCIATION object. It has just >>>> documented its usage in the >>>>>> GMPLS recovery context. >>>> >>>> I'm not sure how these two statements (the document text >> and your last >>>> sentence) are mutually inconsistent. I see no text change >>>> based on this comment. >>> >>> I meant: "In order to document the more general usage of >> the ASSOCIATION object, ..." >>> >> >> While I don't mind the change in this part of the sentience, >> the result >> is a bit odd "In order to document the more general usage of the >> ASSOCIATION object, this document ..." So will leave as is. > > "In order to document the more general usage of the ASSOCIATION object, this specification ..." I think we're in the noise here... > >>>>>> - Section 3.1, "Cross-session association based on Path >>>> state is defined in >>>>>> [RFC4872]." the latter defines cross-LSP association >>>> within the same session >>>>> (not >>>>>> cross-session association) but nothing prevents extending >>>> usage to cross- >>>>>> Session. >>>>>> >>>> >>>> I see no text change requested based on this comment. >>> >>> I meant: "Cross-LSP association based on Path state is defined in >>> [RFC4872]; here we document cross-session association..." >> >> I'll change two instances of "Cross-session association" to "Cross-LSP >> association". > > OK. > >>>>>> - Section 3.1.2 the statement "the definition SHOULD allow >>>> for association >>>>> based >>>>>> on identical ASSOCIATION objects" is not clear, does it >>>> that the information >>>>>> elements part of the object shall be identical ? >>>> >>>> I see no difference between the current text (object >> equivalence) and >>>> object information element equivalence. I don't believe >>>> there's a case >>>> where you can have one without the other. Please correct me if you >>>> think I'm mistaken. >>> >>> If the association ID are defined such that: >>> >>> - the Association ID of Session 1 or LSP 1 points to the >> Session ID or LSP ID of LSP 2 >>> >>> - the Association ID of Session 2 or LSP 2 points to the >> Session ID or LSP ID of LSP 1 >> >> Association based on matching Association ID to Session ID is not part >> of this draft. > > if the session ID isn't used - which is possible - documenting the ID > setting to ensure unicity (per association) is to be documented the > definition only states concerning value setting > > "A value assigned by the the node that originated the association. > When combined with the other fields carried in the object, this > value uniquely identifies an association." Actually, the document provides additional guidance in the procedures section: The Association ID field MUST be set to a value that uniquely identifies the sessions to be associated within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node originating the association. > >>> Other elements aren't necessarily identical. >> >> They must be identical in the context of this draft and the absence of >> type-specific processing rules. >> >>> The setting of the association source is application type specific. >> >> Even if true, I don't see how this impacts the text of the draft. > > Because a full match (incl.association source) wouldn't apply > anymore. I think the point goes to the question does extension > include association between sessions that uses two different source > addresses that can be two interface address ? sure. As documented, there is no mention of other fields to check as part of association identification. > >>> Another case (if I am correctly understanding the related text), is >>> related to the MPLS-TP section. The association object of two >>> non-associated session can have the value fields in the >>> ext.association object. >> >> This is a true statement, but unless the contents of the whole object >> are identical, there's no association. > > In GMPLS you will have association source setting being identical for > many tunnels/LSPs (many controllers will set their local IP address > as source) while actually these LSPs aren't. I don't think there is > any indication that prevents this to happen ? Correct and this is intentional. All that is required for association is a simple match of objects. If two nodes use the same source address without coordinating IDs there may be collisions, but there's no way to know if this is intentional or an error when processing the path/resv messages. > >>>>>> - Section 3.1.2 "The Association ID field MUST be set to a >>>> value that uniquely >>>>>> identifies the sessions to be associated within the >>>> context of the Association >>>>>> Source field." >>>>>> this statement is not compatible with e.g. RFC 4873 and >>>> 4872 where >>>>> Association >>>>>> ID are set to LSP ID and not sessions while it is stated in 3.1 " >>>> >>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" >>> >>> Yes and section 3.1.2 indicates "These procedures >>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >> session state." >>> >>> don't you think this induces confusion ? >> >> Perhaps, but this is why the 3.1 states: >> This section does not modify processing required to support >> [RFC4872] >> and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. > > This being said the Code point for RFC 4873 isn't changed but points > to this document. Any reason since there is no processing change ? I assume you're referring to the Resource Sharing type. This is updated as the same type is now usable for non-recovery LSPs. > >>>> so it does not impact to RFC 4873 and 4872 >> implementations. As stated >>>> in the draft and quoted by you: >>>> >>>>> This section >>>>> does not >>>>>> modify processing required to support [RFC4872] and >>>> [RFC4873], and which is >>>>>> reviewed in Section 3 of [RFC6689]. " >>> >>> The point I am raising is that Section 3.1 reads as there no >>> "additions" whereas once reaching Section 3.1.2 one understands that >>> the statement no modifications meant actually extensions. >>> >>> Section 3.1 states "This section does not modify processing >> required to >>> support [RFC4872] and [RFC4873], and which is reviewed >> in Section 3 >>> of [RFC6689]. " >>> >>> Section 3.1.2 states " These procedures >>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >> session state." >>> >>> Hence, >>> >>> Section 3.1.2 should be rephrased as >>> >>> "This section is based on the processing rules described >> in [RFC4872] >>> and [RFC4873], and which is reviewed in [RFC6689]. >> These procedures >>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >> session state." >>> >>> Section 3.1.2 should be rephrased as >>> >>> "This section generalizes the processing rules described >> in [RFC4872] >>> and [RFC4873], and which is reviewed in [RFC6689], for >> application >>> to MPLS LSPs and non-LSP session state. For GMPLS LSP rules are >>> extended for applications not related to the recovery >> and resource >>> sharing." >> >> I've revised the text to read: >> >> This section is based on, and extends, the processing rules >> described in [RFC4872] and [RFC4873], and which is reviewed in >> [RFC6689]. This section applies equally to GMPLS LSPs, MPLS LSPs >> and non-LSP session state. Note, as previously stated, this >> section does not modify processing required to support [RFC4872] >> and [RFC4873]. > > OK. > >>>> 2) I also think "not compatible" is an overstatement, but >> I guess that >>>> it isn't really a critical point to discuss as the referenced text >>>> doesn't relate to [RFC4872] and [RFC4873]. >>> >>> The proposed phrasing would resolve it. >>> >>>>>> and in RFC 4873/Section 3.2 "The >>>>>> ASSOCIATION object is used to associate different LSPs >>>> with each other." >>>> >>>> I see no text change requested based on this comment. >>> >>> Ditto. >>> >>>>>> - Section 3.1.2 "An association is deemed to exist when >>>> the same values are >>>>>> carried in all fields of the ASSOCIATION objects being >>>> compared." this >>>>> introduces >>>>>> an additional level of indirection. To associate A to B A >>>> can simply refer to >>>>> an >>>>>> identifier of B (and vice versa), A doesn't need to have >>>> an additional ID >>>>> (e.g. C) >>>>>> that is also associated to B. Generalization would consist >>>> here in introducing >>>>> an >>>>>> ext.association ID common to A, B, and C. In other terms, >>>> generalizing the >>>>> notion >>>>>> of association doesn't require the introduction of an >>>> additional level of >>>>>> indirection. >>>> >>>> I really have no idea what this comment means. There is no >>>> indirection stated or implied by the text. >>> >>> It is the result of what the text implies and it is specifically >>> related to the "Association ID". Implicitly the document mandates >>> than this identifier can't take any value of existing fields >>> identifying tunnels/LSPs. >> >> Not at all. As long as the IDs as consistently set across association >> objects, an association will be made. Furthermore, type specific >> processing can be defined that allows implicit mapping such as you >> defined in 4872. > > The first item to check is the Association Type to distinguish > between matching processes. The statement "In the absence of > Association Type-specific rules for identifying association,.." was > probably intended to state (to remove the confusion of the statement > "identifying assocation"): > > "If the ASSOCIATION type does not refer to Association Type-specific > rules for the processing of the ASSOCIATION object (in which case the > Association Type-specific rules SHALL be applied), ..." IMO this should be left to the definition of the Association Type-specific rules, i.e., is beyond the scope of this document. > >>>> It means test for simple equivalence, >>>> i.e., (ASSOCIATION object of A) = (ASSOCIATION object of >> B) and that's >>>> it. There's no (session) ID referencing. Can you restate >>>> your concern? >>> >>> My concern is this an equivalence between objects not an >> assocation of sessions. >>> >> >> Per this document, equivalence between objects identifies an >> assocation >> of sessions. This document does not generalize the session ID to >> association ID matching that was part of 4872. > > The above text would clarify the point. The following has been added to the second to last paragraph of Section 1. When using the procedures defined below, association is identified based on simple ASSOCIATION object matching. Some of the other matching mechanisms defined in RFC 4872, e.g., matching based on Session IDs, are not generalized. > >>>>>> - Section 3.2.2 I understand triggers for Resv-initiated >>>> associations aren't >>>>>> documented but how to prevent a sender willing to demote >>>> receiver-driven >>>>>> associations ? >>>> >>>> Can you clarify this question? >>> >>> Let me put first in context. Generalization includes Rcv driven >>> associations but only additions are documented. >>> >>>> Are you asking: >>>> - how a Path sender can prevent a receiver initiated >> association? (it >>>> can't) >>>> >>>> - how a Resv sender removes an association? (it just removes >>>> the object, no different from a path message) >>> >>> The corresponding processing is to be documented. Because one can >>> also demote an association by having each LSP/session pointing to >>> itself while keeping the object in the Path/Resv message. >> >> This sounds like the implicit matching rules in 4872. Such session ID >> to association ID matching is not part of this document. > > I hear you but as the ASSOCIATION ID value setting doesn't state it > can't be done, you can get the same result. Sure, and this would be perfectly fine way for an implementation to select its IDs for certain possible applications, but this is a local implementation choice in the general case, or type-specific processing which is outside the scope of this document. > You could even assume that changing ID to an unused but value would > lead to the same result (as matching wouldn't give a positive result > the ASSOCIATION would also be removed since it can't be found > anymore). > >>>> - something else? >>>> >>>>>> - Section 3.1.2 and 3.2.2 no error processing is being documented >>>> >>>> I think this is a fair point. The only case I think that >>>> can/should be >>>> addressed is unknown types. (As is usual, per RFC2205, errors in >>>> formats to not trigger any specific message response.) >>>> Sections 3.1 and >>>> 3.2 only discuss identification of associations, so I >> propose adding a >>>> section 3.3.2. How about something like: >>>> >>>> 3.3.2. Unknown Association Types >>>> >>>> A node that receives an ASSOCIATION object with an unknown >>>> ASSOCIATION type MUST forward all received ASSOCIATION objects >>>> as defined above. The node MAY also identify associations per >>>> the defined processing, e.g., to make this information available >>>> via a management interface. >>> >>> OK. Wouldn't you document PathErr/ResvErr and Notify ? >> >> IMO Not for an unknown type. > > I don't understand the answer. I don't think unknown type should result in a PathErr/ResvErr at a transit/egress/ingress node. > >>>>>> whereas mis- >>>>>> match in association should be considered as a generic error. >>>> >>>> This isn't a detectable error case as it is impossible for >> a node to >>>> know if two association objects are intentionally or >> unintentionally >>>> different. >>> >>> Earlier, in the text it is mentioned that processing >> implies checking >>> all Path/Resv state. We have to understand that putting in place a >>> generic processing (outside a specific ASSOCIATION Type) renders >> >> I think this sentence got truncated... > > ... safeguard rule advisable. > >>>>>> - Section 3.3 states "Since the admission control function >>>> is outside the >>>>> scope of >>>>>> RSVP,..." are you sure ? >>>> >>>> Yes. Per RFC2205: >>> >>> Yes I know the figuere whose terms mixes functions, protocol >>> processes, etc. but this goes beyond the review of this document ;-) >> >>> >>>> HOST ROUTER >>>> >>>> _____________________________ ____________________________ >>>> | _______ | | | >>>> | | | _______ | | _______ | >>>> | |Appli- | | | |RSVP | | | | >>>> | | cation| | RSVP <---------------------------> RSVP >> <----------> >>>> | | <--> | | | _______ | | | >>>> | | | |process| _____ | ||Routing| |process| _____ | >>>> | |_._____| | -->Polcy|| || <--> -->Polcy|| >>>> | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| >>>> | |data | | |_____|| ||__.____| | | |_____|| >>>> |===|===========|==|==========| |===|==========|==|==========| >>>> | | --------| | _____ | | | --------| | _____ | >>>> | | | | ---->Admis|| | | | | ---->Admis|| >>>> | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| >>>> | | | | | |_____|| | | | | ||_____|| >>>> | |Class-| | Packet | | | |Class-| | Packet | | >>>> | | ifier|==>Schedulr|================> >> ifier|==>Schedulr|===========> >>>> | |______| |________| |data | |______| |________| >> |data >>>> | | | | >>>> |_____________________________| |____________________________| >>>> >>>> >>>> Figure 1: RSVP in Hosts and Routers >>>> >>>> an RSVP QoS request is passed to two local >>>> decision modules, "admission control" and "policy control". >>>> >>>>>> admission control is an intrinsic function associated >>>>> to RFC >>>>>> 2205 (there are errors documented for admission control >>>> failures). I think you >>>>>> mean that the inner working of the mechanisms used by >>>> nodes to determine if >>>>>> they have sufficient available resources to support >>>> incoming requests. >>>> >>>> I think this is the same as what is stated. >>> >>> What you mean is: the inner-working or implementation of admission >>> control for QoS requests is outside scope of RFC 2205. >>> >>>> we can add "implementation specifics ", i.e., " Since the >>>> implementation >>>> specifics of the admission control function is outside the >>>> scope " if it helps. >>> >>> Yes it does because the term "outside scope" has different >> meanings depending on context. >>> >> >> done. >> >>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION >>>> object and the IPv6 >>>>>> ASSOCIATION object. As defined, these objects each contain >>>> an Association >>>>>> Source field and a 16-bit Association ID field. The >>>> combination of the >>>>> Association >>>>>> Source and the Association ID uniquely identifies the >>>> association." but in the >>>>>> context RFC 4872 this association is defined in the >>>> context of the same tunnel >>>>>> end-point >>>> >>>> How about we clarify: "*As described above,* the >>>> combination of the Association Source and the Association ID >>>> uniquely identifies the association." >>> >>> It would be better to state >>> >>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >>> ASSOCIATION object in the context of a given session. As defined, >>> these objects each contain an Association Source field and a 16-bit >>> Association ID field. The combination of the Association Source and >>> the Association ID uniquely identifies the association. This doesn't >>> prevent that Association Types MAY further specify the context for >>> which this association is defined." >> >> It now reads: >> >> [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >> ASSOCIATION object. As defined, these objects each contain an >> Association Source field and a 16-bit Association ID field. As >> described above, the contents of the object uniquely identifies >> an association. Because the Association ID field is a 16-bit >> field, an association source can allocate up to 65536 different >> associations and no more. > > OK > >>>>> (and actually the same for RFC 4873 which relies on MBB as defined >>>>> in >>>>>> RFC 3209) >>>> >>>> I don't believe this statement is correct, but again this >> is really a >>>> discussion beyond this draft. >>> >>> The statement here above is also to applicable to RFC 4873. >>> >>>>>> - Section 4: How is the following use case "There are >>>> scenarios where this >>>>> number >>>>>> is insufficient. (For example where the association >>>> identification is best >>>>> known >>>>>> and identified by a fairly centralized entity, which >>>> therefore may be involved >>>>> in a >>>>>> large number of associations.)" related to those proposed >>>> in the introduction. >>>>> ? >>>> >>>> As I read it, it enables practical third party (e.g., >>>> management entity) >>>> creation and management of association IDs. But, I'll defer to my >>>> coauthors on this. >>> >>> OK. Please let me know the result(s) of the discussion. >>> >>>>>> - Section 4: I don't question the requirement stated in >>>> "Per [RFC6370], >>>>> MPLS-TP >>>>>> LSPs can be identified based on an operator unique global >>>> identifier. The >>>>>> [RFC6370] defined "global identifier", or Global_ID, is >>>> based on [RFC5003] and >>>>>> includes the operator's Autonomous System Number (ASN)." >>>> the question is why >>>>>> the information is best encoded as part of the ASSOCIATION >>>> object ? isn't this >>>>> an >>>>>> LSP ATTRIBUTE or a Session Name ? >>>> >>>> It's the solution the WG agreed to. Other options are of >>>> course possible. >>> >>> My comment is specific because it triggers the question on how many >>> objects will we end up in spreading identification information (it >>> would be interesting to document the why this was felt the most >>> suited object as it is not a natural choice); more general >> comment is >>> what defines the "acceptable" use/extension of association. >> >> I think the last comment is a reasonable discussion to have. Not sure >> it belongs in, or gates the discussion. > > The LSP attributes RFC included this info for instance. This has > prevented lots of problems in use of the object because the content > of most objects could have been added to the LSP attribute RFC (cf. > Sect.8 "8. Summary of Attribute Bit Allocation" and Sect.10 > "Guidance for Key Application Scenarios"). Do you have some suggestions/text in mind? > >>>>>> - Section 4.2: states "It is important to note that >>>> Section 4 defines >>>>> association >>>>>> identification based on ASSOCIATION object matching, and >>>> that such matching >>>>> is >>>>>> based on the comparison of all fields in a ASSOCIATION >>>> object (unless type- >>>>>> specific comparison rules are defined). This applies >>>> equally to ASSOCIATION >>>>>> objects and Extended ASSOCIATION objects." any association >>>> is based on a form >>>>>> of matching, point here is that the matching and the >>>> identification of the >>>>> initiation >>>>>> of the matching information are distinct information >>>> entities (difference >>>>> between >>>>>> WHO and WHAT). I suggest to make a clearer distinction and >>>> specify setting and >>>>>> processing accordingly. >>>> >>>> I'm not seeing the issue. Can you perhaps propose some text? >>> >>> Here is the proposed text >>> >>> "It is important to note that Section 4 defines association >>> identification based on ASSOCIATION object matching, and >>> that such matching is based on the comparison of the fields >>> as determined by the ASSOCIATION Type of the ASSOCIATION >>> object. This applies equally to ASSOCIATION objects and >>> Extended ASSOCIATION objects." >> >> Here's the revised text. >> Identification of association is not modified by this section. It >> is important to note that Section 4 defines association >> identification based on ASSOCIATION object matching, and that such >> matching, in the absence of type-specific comparison rules, is >> based on the comparison of all fields in an ASSOCIATION object. >> This applies equally to ASSOCIATION objects and Extended >> ASSOCIATION objects. > > I would write (look at the text just above where you state "As > defined, these objects each contain an Association Source field and a > 16-bit Association ID field. As described above, the contents of the > object uniquely identifies an association." ... there is a need to > distinguish between identifying the ASSOCIATION object vs matching > ASSOCIATION objects). sure. But you need to be sure you're noting the difference between the word "association" and the thing "ASSOCIATION object". > This would > > "The procedure to perform ASSOCIATION object matching as defined in > Section 4 is not modified by this section. It is important to note > that Section 4 defines ASSOCIATION object matching if the ASSOCIATION > type does not refer to Association Type-specific rules for the > processing of the ASSOCIATION object (in which case the Association > Type-specific rules SHALL be applied); otherwise, ASSOCIATION object > matching applies by comparing all fields in an ASSOCIATION object. > This procedure applies equally to ASSOCIATION objects and Extended > ASSOCIATION objects." one more time, revised text now reads: The procedures related to association identification are not modified by this section. It is important to note that Section 4 defines the identification of associations based on ASSOCIATION object matching and that such matching, in the absence of type-specific comparison rules, is based on the comparison of all fields in an ASSOCIATION object. This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects. > > >>>>>> - Section 4.2: shouldn't "error processing" being documented ? >>>> >>>> Here too, I think the only error processing is as discussed above. >>>> Shout if you think otherwise. >>>> >>>>>> Example include >>>>>> admission control where receiving node rejects the >>>> incoming Path msg if the >>>>>> originating Global_ID/Ext.ASSOCIATION object isn't included, >>>> >>>> Interesting, but this is a type specific error. To me this >>>> sounds like >>>> a new admission control error that should be defined as part of the >>>> type-specific definition. >>> >>> Admission control failures are part of the error codes >> defined in RFC 2205. >> >> exactly! >> >>>>>> unauthorized >>>>>> Global ID ? >>>> >>>> Again interesting, but this is a new policy (and policy error) that >>>> wasn't proposed or discussed in the WG. I think this >> would be a fine >>>> addition, but is beyond the current document discussion. It >>>> could always be added if proposed. >>> >>> I defer this point to the AD. >> >> WFM. >> >>> >>>>>> etc. but also mismatches between Association source and Global >>>>>> Association source ? >>>> >>>> How would such a thing be detected, by checking BGP state? >> I guess we >>>> could add a new error code, but again I think we're going >> beyond the >>>> intent of the document/WG. >>> >>> Same here. >>> >>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370] >>>> defined global >>>>> identifier, >>>>>> or Global_ID, is based on [RFC5003] and includes the >>>> operator's Autonomous >>>>>> System Number (ASN)." while the latter "the use of the >>>> Global_ID is not >>>>> related >>>>>> to the use of the ASN in protocols such as BGP." which one >>>> applies ? >>>> >>>> I'll drop the note. This is better aligned with the field >> definition >>>> which has been updated based on comments of other reviewers. >>>> >>>> The current definition is: >>>> >>>> This field contains a value that is a unique global >> identifier or >>>> the special value zero (0). When non-zero and not >> overridden by >>>> local policy, the Global_ID as defined in [RFC6370] >> SHALL be used. >>>> The special value of zero indicates that no global >> identifier is >>>> present. Use of the special value of zero SHOULD be limited to >>>> entities contained within a single operator. >>> >>> OK >>> >>>>>> - Section 5 Documenting means to prevent/mitigate >>>> mis-association(s) and >>>>>> possible impact on security would be advisable. If this is >>>> felt to be >>>>> "application" or >>>>>> "type" specific a recommendation should be stated that the >>>> security mechanisms >>>>>> have to be documented as part of these documents. >>>> >>>> Why is there any additional risk than what " was >> previously defined in >>>> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) >>> >>> I try to prevent that any further use/documents would state "no >>> additional risk compared to RFC 4872 and RFC 4873" or equivalent but >>> the application is running for voice calls over the >> Internet which is >>> a totally different application than G/MPLS Recovery/Resource >>> Sharing. >> >> Fair enough, but what additional issues do you foresee that should be >> covered? > > Nodes associating sessions, etc. should have the mean to verify the initiator of the association. This is true for every object in RSVP! I have no objection to object signing, ala SIDR, but this is well beyond the scope of this document and certainly isn't introduced in this document. > >>>>>> Editorials: >>>>>> >>>>>> - Introduction: "This document expands the possible usage >>>> of the ASSOCIATION >>>>>> object to >>>>>> non-GMPLS and non-recovery contexts." Suggested to state >>>> the actual the >>>>>> scope includes RSVP (instead of what it is not) >>>> >>>> I'll add: >>>> The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS >>>> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], >>>> [RFC3175] and [RFC4860]. >>> >>> OK. >>> >>>>>> - Introduction: s/different ports/different destination >> (dst) ports >>>>>> >>>> >>>> sure. >>>> >>>>>> - Section 2 would better refer to a "Generalization" >> rather than a >>>>> "modification" >>>>>> >>>> >>>> I'd be okay with this, but I think modification makes is less >>>> likely to be misinterpreted so will leave as is. >>> >>> The term modification implies a change in existing processing (even >>> if the intention is different) and actually as the applicability is >>> now possible to RSVP and MPLS-TE. >> >> This isn't a major point for me, so will change it. (In 5 places.) > > OK (actually the doc. generalizes the use of the object whereas 4873 for inst documents type-specific/specialized use of the object) > >>>>>> - Section 3 states "As defined by [RFC4872] and reviewed >>>> in [RFC6689],..." but >>>>> an >>>>>> information RFC doesn't review at best "documents" >>>> certain usage. This >>>>>> statement is repeated at multiple places. >>>> >>>> Why can't it review? This is what the abstract of RFC6689 >>>> says it does. >>> >>> It was overstated in RFC 6689. >> >> This document doesn't change 6689. > > OK. > >>>>>> - Section 3 mentions "Object usage in both Path and Resv >>>> messages is >>>>> discussed. >>>>>> The usage applies equally to >>>>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP >>>> RSVP sessions >>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having >>>> such statement in the >>>>>> introduction would desirable. >>>> >>>> Fair enough. >>>> >>>> Thank you for the review! >>> >>> OK. >>> >>> Thanks, >>> -d. >> >> Thanks, >> Lou > > Thanks, > -d. Thanks again. Lou PS I'll submit a revised version of the draft at some point today to document all changes to date. From dimitri.papadimitriou@alcatel-lucent.com Wed Sep 5 09:10:36 2012 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 E504B21F86B7 for ; Wed, 5 Sep 2012 09:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.629 X-Spam-Level: X-Spam-Status: No, score=-7.629 tagged_above=-999 required=5 tests=[AWL=1.380, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 E+fvOJQAdcc6 for ; Wed, 5 Sep 2012 09:10:33 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6D21F86B5 for ; Wed, 5 Sep 2012 09:10:33 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q85GARe3005091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 18:10:28 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 5 Sep 2012 18:10:27 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lou Berger Date: Wed, 5 Sep 2012 18:08:29 +0200 Thread-Topic: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 Thread-Index: Ac2LYxR96WTECZscRwaZTVSlIuHYWgAAKWSA Message-ID: References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> <50474748.1030303@labn.net> In-Reply-To: <50474748.1030303@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 16:10:36 -0000 Hi Lou, > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, September 05, 2012 14:36 > To: Papadimitriou, Dimitri (Dimitri) > Cc: adrian@olddog.co.uk; > draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > > Hi Dimiri, > Responses in line... > > On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:> Lou, > > > > see below, > > > >> -----Original Message----- > >> From: rtg-dir-bounces@ietf.org > >> [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger > >> Sent: Tuesday, September 04, 2012 23:54 > >> To: Papadimitriou, Dimitri (Dimitri) > >> Cc: adrian@olddog.co.uk; > >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > >> > >> Dimitri, > >> See below. > >> > >> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: > >>> Hi Lou, > >>> > >>> See inline: > >>> > >>>> -----Original Message----- > >>>> From: Lou Berger [mailto:lberger@labn.net] > >>>> Sent: Tuesday, September 04, 2012 17:25 > >>>> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) > >>>> Cc: rtg-dir@ietf.org; > draft-ietf-ccamp-assoc-ext.all@tools.ietf.org > >>>> Subject: Re: [RTG-DIR] FW: Review of > draft-ietf-ccamp-assoc-ext-04 > >>>> > >>>> Adrian, > >>>> Much Thanks. (BTW is there a reason not to include the > >>>> WG in this, or > >>>> such, discussions?) > >>>> > >>>> Dimitri, > >>>> Please see below for inline responses. > >>>> > >>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote: > >>>>> Here is Dimitri's Routing Dir review. Many thanks for > the review. > >>>>> > >>>>> Lou, you can address this and the other comments and post a > >>>> new revision. > >>>>> > >>>>> Adrian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Papadimitriou, Dimitri (Dimitri) > >>>> [mailto:dimitri.papadimitriou@alcatel- > >>>>>> lucent.com] > >>>>>> Sent: 31 August 2012 13:23 > >>>>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; > sbryant@cisco.com; > >>>>>> huawei.danli@huawei.com > >>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 > >>>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> Here below the review of this document. > >>>>>> > >>>>>> Technical comments: > >>>>>> > >>>>>> - Example 3: isn't this extension also not updating RFC 2205 ? > >>>> > >>>> Yes. This is stated in the header, abstract and section 3. > >>> > >>> I thought to include this in the introduction since other > >> updated RFC are indicated. > >>> > >> > >> Agreed. Text has been added. > > > > OK. > > > >>>>>> - The statement "In order to support the more general > >> usage of the > >>>>>> ASSOCIATION object," is actually not correct RFC 4872 > >>>> doesn't prevent support > >>>>> of > >>>>>> other usage of the ASSOCIATION object. It has just > >>>> documented its usage in the > >>>>>> GMPLS recovery context. > >>>> > >>>> I'm not sure how these two statements (the document text > >> and your last > >>>> sentence) are mutually inconsistent. I see no text change > >>>> based on this comment. > >>> > >>> I meant: "In order to document the more general usage of > >> the ASSOCIATION object, ..." > >>> > >> > >> While I don't mind the change in this part of the sentience, > >> the result > >> is a bit odd "In order to document the more general usage of the > >> ASSOCIATION object, this document ..." So will leave as is. > > > > "In order to document the more general usage of the ASSOCIATION > object, this specification ..." > > I think we're in the noise here... > > >>>>>> - Section 3.1, "Cross-session association based on Path > >>>> state is defined in > >>>>>> [RFC4872]." the latter defines cross-LSP association > >>>> within the same session > >>>>> (not > >>>>>> cross-session association) but nothing prevents extending > >>>> usage to cross- > >>>>>> Session. > >>>>>> > >>>> > >>>> I see no text change requested based on this comment. > >>> > >>> I meant: "Cross-LSP association based on Path state is defined in > >>> [RFC4872]; here we document cross-session association..." > >> > >> I'll change two instances of "Cross-session association" > to "Cross-LSP > >> association". > > > > OK. > > > >>>>>> - Section 3.1.2 the statement "the definition SHOULD allow > >>>> for association > >>>>> based > >>>>>> on identical ASSOCIATION objects" is not clear, does it > >>>> that the information > >>>>>> elements part of the object shall be identical ? > >>>> > >>>> I see no difference between the current text (object > >> equivalence) and > >>>> object information element equivalence. I don't believe > >>>> there's a case > >>>> where you can have one without the other. Please > correct me if you > >>>> think I'm mistaken. > >>> > >>> If the association ID are defined such that: > >>> > >>> - the Association ID of Session 1 or LSP 1 points to the > >> Session ID or LSP ID of LSP 2 > >>> > >>> - the Association ID of Session 2 or LSP 2 points to the > >> Session ID or LSP ID of LSP 1 > >> > >> Association based on matching Association ID to Session ID > is not part > >> of this draft. > > > > if the session ID isn't used - which is possible - > documenting the ID > > setting to ensure unicity (per association) is to be documented the > > definition only states concerning value setting > > > > "A value assigned by the the node that originated the association. > > When combined with the other fields carried in the > object, this > > value uniquely identifies an association." > > Actually, the document provides additional guidance in the procedures > section: > > The Association ID field MUST be set to a value that uniquely > identifies the sessions to be associated within the context of the > Association Source field. The Association Source field MUST be > set to a unique address assigned to the node originating the > association. The initial statement should be part of the definition in the form "The Association ID value space is unique per ?" I write "?" because is it = per node, per RSVP process, per Association source ? The processing should in my opinion state (or equivalent): "The Association ID field MUST be set to a unique value that uniquely identifies the association between sessions that are associated within the context of the Association Source field." > >>> Other elements aren't necessarily identical. > >> > >> They must be identical in the context of this draft and > the absence of > >> type-specific processing rules. > >> > >>> The setting of the association source is application type > specific. > >> > >> Even if true, I don't see how this impacts the text of the draft. > > > > Because a full match (incl.association source) wouldn't apply > > anymore. I think the point goes to the question does extension > > include association between sessions that uses two different source > > addresses that can be two interface address ? > > sure. As documented, there is no mention of other fields to check as > part of association identification. I don't get it. If the matching operation implies that all fields shall be = identical including the association source how do you proceed ? > >>> Another case (if I am correctly understanding the related > text), is > >>> related to the MPLS-TP section. The association object of two > >>> non-associated session can have the value fields in the > >>> ext.association object. > >> > >> This is a true statement, but unless the contents of the > whole object > >> are identical, there's no association. > > > > In GMPLS you will have association source setting being > identical for > > many tunnels/LSPs (many controllers will set their local IP address > > as source) while actually these LSPs aren't. I don't think there is > > any indication that prevents this to happen ? > > Correct and this is intentional. All that is required for > association is > a simple match of objects. If two nodes use the same source address > without coordinating IDs there may be collisions, but there's > no way to > know if this is intentional or an error when processing the path/resv > messages. OK. As such this corroborates my initial remark where the association objec= t was actually the most suited place to put this information. > >>>>>> - Section 3.1.2 "The Association ID field MUST be set to a > >>>> value that uniquely > >>>>>> identifies the sessions to be associated within the > >>>> context of the Association > >>>>>> Source field." > >>>>>> this statement is not compatible with e.g. RFC 4873 and > >>>> 4872 where > >>>>> Association > >>>>>> ID are set to LSP ID and not sessions while it is > stated in 3.1 " > >>>> > >>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" > >>> > >>> Yes and section 3.1.2 indicates "These procedures > >>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >> session state." > >>> > >>> don't you think this induces confusion ? > >> > >> Perhaps, but this is why the 3.1 states: > >> This section does not modify processing required to support > >> [RFC4872] > >> and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. > > > > This being said the Code point for RFC 4873 isn't changed but points > > to this document. Any reason since there is no processing change ? > > I assume you're referring to the Resource Sharing type. This > is updated as the same type is now usable for non-recovery LSPs. OK. > >>>> so it does not impact to RFC 4873 and 4872 > >> implementations. As stated > >>>> in the draft and quoted by you: > >>>> > >>>>> This section > >>>>> does not > >>>>>> modify processing required to support [RFC4872] and > >>>> [RFC4873], and which is > >>>>>> reviewed in Section 3 of [RFC6689]. " > >>> > >>> The point I am raising is that Section 3.1 reads as there no > >>> "additions" whereas once reaching Section 3.1.2 one > understands that > >>> the statement no modifications meant actually extensions. > >>> > >>> Section 3.1 states "This section does not modify processing > >> required to > >>> support [RFC4872] and [RFC4873], and which is reviewed > >> in Section 3 > >>> of [RFC6689]. " > >>> > >>> Section 3.1.2 states " These procedures > >>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >> session state." > >>> > >>> Hence, > >>> > >>> Section 3.1.2 should be rephrased as > >>> > >>> "This section is based on the processing rules described > >> in [RFC4872] > >>> and [RFC4873], and which is reviewed in [RFC6689]. > >> These procedures > >>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >> session state." > >>> > >>> Section 3.1.2 should be rephrased as > >>> > >>> "This section generalizes the processing rules described > >> in [RFC4872] > >>> and [RFC4873], and which is reviewed in [RFC6689], for > >> application > >>> to MPLS LSPs and non-LSP session state. For GMPLS LSP rules are > >>> extended for applications not related to the recovery > >> and resource > >>> sharing." > >> > >> I've revised the text to read: > >> > >> This section is based on, and extends, the processing rules > >> described in [RFC4872] and [RFC4873], and which is reviewed in > >> [RFC6689]. This section applies equally to GMPLS > LSPs, MPLS LSPs > >> and non-LSP session state. Note, as previously stated, this > >> section does not modify processing required to support > [RFC4872] > >> and [RFC4873]. > > > > OK. > > > >>>> 2) I also think "not compatible" is an overstatement, but > >> I guess that > >>>> it isn't really a critical point to discuss as the > referenced text > >>>> doesn't relate to [RFC4872] and [RFC4873]. > >>> > >>> The proposed phrasing would resolve it. > >>> > >>>>>> and in RFC 4873/Section 3.2 "The > >>>>>> ASSOCIATION object is used to associate different LSPs > >>>> with each other." > >>>> > >>>> I see no text change requested based on this comment. > >>> > >>> Ditto. > >>> > >>>>>> - Section 3.1.2 "An association is deemed to exist when > >>>> the same values are > >>>>>> carried in all fields of the ASSOCIATION objects being > >>>> compared." this > >>>>> introduces > >>>>>> an additional level of indirection. To associate A to B A > >>>> can simply refer to > >>>>> an > >>>>>> identifier of B (and vice versa), A doesn't need to have > >>>> an additional ID > >>>>> (e.g. C) > >>>>>> that is also associated to B. Generalization would consist > >>>> here in introducing > >>>>> an > >>>>>> ext.association ID common to A, B, and C. In other terms, > >>>> generalizing the > >>>>> notion > >>>>>> of association doesn't require the introduction of an > >>>> additional level of > >>>>>> indirection. > >>>> > >>>> I really have no idea what this comment means. There is no > >>>> indirection stated or implied by the text. > >>> > >>> It is the result of what the text implies and it is specifically > >>> related to the "Association ID". Implicitly the document mandates > >>> than this identifier can't take any value of existing fields > >>> identifying tunnels/LSPs. > >> > >> Not at all. As long as the IDs as consistently set across > association > >> objects, an association will be made. Furthermore, type specific > >> processing can be defined that allows implicit mapping such as you > >> defined in 4872. > > > > The first item to check is the Association Type to distinguish > > between matching processes. The statement "In the absence of > > Association Type-specific rules for identifying association,.." was > > probably intended to state (to remove the confusion of the statement > > "identifying assocation"): > > > > "If the ASSOCIATION type does not refer to Association Type-specific > > rules for the processing of the ASSOCIATION object (in > which case the > > Association Type-specific rules SHALL be applied), ..." > > IMO this should be left to the definition of the Association > Type-specific rules, i.e., is beyond the scope of this document. OK. > >>>> It means test for simple equivalence, > >>>> i.e., (ASSOCIATION object of A) =3D (ASSOCIATION object of > >> B) and that's > >>>> it. There's no (session) ID referencing. Can you restate > >>>> your concern? > >>> > >>> My concern is this an equivalence between objects not an > >> assocation of sessions. > >>> > >> > >> Per this document, equivalence between objects identifies an > >> assocation > >> of sessions. This document does not generalize the session ID to > >> association ID matching that was part of 4872. > > > > The above text would clarify the point. > > The following has been added to the second to last paragraph > of Section 1. > > When using the procedures defined below, association is identified > based on simple ASSOCIATION object matching. Some of the other > matching mechanisms defined in RFC 4872, e.g., matching based on > Session IDs, are not generalized. I would write: When using the procedures defined in this document, association is id= entified based on ASSOCIATION object matching. Some of the other matching mechanisms defined in RFC 4872, e.g., matching based on Session IDs, are not generalized in this document. Association type-specific processing is outside the scope of this document. > >>>>>> - Section 3.2.2 I understand triggers for Resv-initiated > >>>> associations aren't > >>>>>> documented but how to prevent a sender willing to demote > >>>> receiver-driven > >>>>>> associations ? > >>>> > >>>> Can you clarify this question? > >>> > >>> Let me put first in context. Generalization includes Rcv driven > >>> associations but only additions are documented. > >>> > >>>> Are you asking: > >>>> - how a Path sender can prevent a receiver initiated > >> association? (it > >>>> can't) > >>>> > >>>> - how a Resv sender removes an association? (it just removes > >>>> the object, no different from a path message) > >>> > >>> The corresponding processing is to be documented. Because one can > >>> also demote an association by having each LSP/session pointing to > >>> itself while keeping the object in the Path/Resv message. > >> > >> This sounds like the implicit matching rules in 4872. > Such session ID > >> to association ID matching is not part of this document. > > > > I hear you but as the ASSOCIATION ID value setting doesn't state it > > can't be done, you can get the same result. > > Sure, and this would be perfectly fine way for an implementation to > select its IDs for certain possible applications, but this is a local > implementation choice in the general case, or type-specific processing > which is outside the scope of this document. OK. > > You could even assume that changing ID to an unused but value would > > lead to the same result (as matching wouldn't give a positive result > > the ASSOCIATION would also be removed since it can't be found > > anymore). > > > > > >>>> - something else? > >>>> > >>>>>> - Section 3.1.2 and 3.2.2 no error processing is being > documented > >>>> > >>>> I think this is a fair point. The only case I think that > >>>> can/should be > >>>> addressed is unknown types. (As is usual, per RFC2205, errors in > >>>> formats to not trigger any specific message response.) > >>>> Sections 3.1 and > >>>> 3.2 only discuss identification of associations, so I > >> propose adding a > >>>> section 3.3.2. How about something like: > >>>> > >>>> 3.3.2. Unknown Association Types > >>>> > >>>> A node that receives an ASSOCIATION object with an unknown > >>>> ASSOCIATION type MUST forward all received ASSOCIATION objects > >>>> as defined above. The node MAY also identify associations per > >>>> the defined processing, e.g., to make this information > available > >>>> via a management interface. > >>> > >>> OK. Wouldn't you document PathErr/ResvErr and Notify ? > >> > >> IMO Not for an unknown type. > > > > I don't understand the answer. > > I don't think unknown type should result in a PathErr/ResvErr at a > transit/egress/ingress node. The question why do you use "unknown" type and not Error Code =3D 01: "Admission Control Failure" (see [RFC2205]) o "Admission Control Failure/Session Admission Failure" (6) > >>>>>> whereas mis- > >>>>>> match in association should be considered as a generic error. > >>>> > >>>> This isn't a detectable error case as it is impossible for > >> a node to > >>>> know if two association objects are intentionally or > >> unintentionally > >>>> different. > >>> > >>> Earlier, in the text it is mentioned that processing > >> implies checking > >>> all Path/Resv state. We have to understand that putting in place a > >>> generic processing (outside a specific ASSOCIATION Type) renders > >> > >> I think this sentence got truncated... > > > > ... safeguard rule advisable. > > > >>>>>> - Section 3.3 states "Since the admission control function > >>>> is outside the > >>>>> scope of > >>>>>> RSVP,..." are you sure ? > >>>> > >>>> Yes. Per RFC2205: > >>> > >>> Yes I know the figuere whose terms mixes functions, protocol > >>> processes, etc. but this goes beyond the review of this > document ;-) > >> [snip figure] > >>>> an RSVP QoS request is passed to two local > >>>> decision modules, "admission control" and "policy control". > >>>> > >>>>>> admission control is an intrinsic function associated > >>>>> to RFC > >>>>>> 2205 (there are errors documented for admission control > >>>> failures). I think you > >>>>>> mean that the inner working of the mechanisms used by > >>>> nodes to determine if > >>>>>> they have sufficient available resources to support > >>>> incoming requests. > >>>> > >>>> I think this is the same as what is stated. > >>> > >>> What you mean is: the inner-working or implementation of admission > >>> control for QoS requests is outside scope of RFC 2205. > >>> > >>>> we can add "implementation specifics ", i.e., " Since the > >>>> implementation > >>>> specifics of the admission control function is outside the > >>>> scope " if it helps. > >>> > >>> Yes it does because the term "outside scope" has different > >> meanings depending on context. > >>> > >> > >> done. > >> > >>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION > >>>> object and the IPv6 > >>>>>> ASSOCIATION object. As defined, these objects each contain > >>>> an Association > >>>>>> Source field and a 16-bit Association ID field. The > >>>> combination of the > >>>>> Association > >>>>>> Source and the Association ID uniquely identifies the > >>>> association." but in the > >>>>>> context RFC 4872 this association is defined in the > >>>> context of the same tunnel > >>>>>> end-point > >>>> > >>>> How about we clarify: "*As described above,* the > >>>> combination of the Association Source and the Association ID > >>>> uniquely identifies the association." > >>> > >>> It would be better to state > >>> > >>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > >>> ASSOCIATION object in the context of a given session. As defined, > >>> these objects each contain an Association Source field > and a 16-bit > >>> Association ID field. The combination of the Association > Source and > >>> the Association ID uniquely identifies the association. > This doesn't > >>> prevent that Association Types MAY further specify the context for > >>> which this association is defined." > >> > >> It now reads: > >> > >> [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > >> ASSOCIATION object. As defined, these objects each contain an > >> Association Source field and a 16-bit Association ID field. As > >> described above, the contents of the object uniquely identifies > >> an association. Because the Association ID field is a 16-bit > >> field, an association source can allocate up to 65536 different > >> associations and no more. > > > > OK > > > >>>>> (and actually the same for RFC 4873 which relies on MBB > as defined > >>>>> in > >>>>>> RFC 3209) > >>>> > >>>> I don't believe this statement is correct, but again this > >> is really a > >>>> discussion beyond this draft. > >>> > >>> The statement here above is also to applicable to RFC 4873. > >>> > >>>>>> - Section 4: How is the following use case "There are > >>>> scenarios where this > >>>>> number > >>>>>> is insufficient. (For example where the association > >>>> identification is best > >>>>> known > >>>>>> and identified by a fairly centralized entity, which > >>>> therefore may be involved > >>>>> in a > >>>>>> large number of associations.)" related to those proposed > >>>> in the introduction. > >>>>> ? > >>>> > >>>> As I read it, it enables practical third party (e.g., > >>>> management entity) > >>>> creation and management of association IDs. But, I'll > defer to my > >>>> coauthors on this. > >>> > >>> OK. Please let me know the result(s) of the discussion. > >>> > >>>>>> - Section 4: I don't question the requirement stated in > >>>> "Per [RFC6370], > >>>>> MPLS-TP > >>>>>> LSPs can be identified based on an operator unique global > >>>> identifier. The > >>>>>> [RFC6370] defined "global identifier", or Global_ID, is > >>>> based on [RFC5003] and > >>>>>> includes the operator's Autonomous System Number (ASN)." > >>>> the question is why > >>>>>> the information is best encoded as part of the ASSOCIATION > >>>> object ? isn't this > >>>>> an > >>>>>> LSP ATTRIBUTE or a Session Name ? > >>>> > >>>> It's the solution the WG agreed to. Other options are of > >>>> course possible. > >>> > >>> My comment is specific because it triggers the question > on how many > >>> objects will we end up in spreading identification information (it > >>> would be interesting to document the why this was felt the most > >>> suited object as it is not a natural choice); more general > >> comment is > >>> what defines the "acceptable" use/extension of association. > >> > >> I think the last comment is a reasonable discussion to > have. Not sure > >> it belongs in, or gates the discussion. > > > > The LSP attributes RFC included this info for instance. This has > > prevented lots of problems in use of the object because the content > > of most objects could have been added to the LSP attribute RFC (cf. > > Sect.8 "8. Summary of Attribute Bit Allocation" and Sect.10 > > "Guidance for Key Application Scenarios"). > > Do you have some suggestions/text in mind? I will propose a Section for this. Can be done as part of this e-mail. > >>>>>> - Section 4.2: states "It is important to note that > >>>> Section 4 defines > >>>>> association > >>>>>> identification based on ASSOCIATION object matching, and > >>>> that such matching > >>>>> is > >>>>>> based on the comparison of all fields in a ASSOCIATION > >>>> object (unless type- > >>>>>> specific comparison rules are defined). This applies > >>>> equally to ASSOCIATION > >>>>>> objects and Extended ASSOCIATION objects." any association > >>>> is based on a form > >>>>>> of matching, point here is that the matching and the > >>>> identification of the > >>>>> initiation > >>>>>> of the matching information are distinct information > >>>> entities (difference > >>>>> between > >>>>>> WHO and WHAT). I suggest to make a clearer distinction and > >>>> specify setting and > >>>>>> processing accordingly. > >>>> > >>>> I'm not seeing the issue. Can you perhaps propose some text? > >>> > >>> Here is the proposed text > >>> > >>> "It is important to note that Section 4 defines association > >>> identification based on ASSOCIATION object matching, and > >>> that such matching is based on the comparison of the fields > >>> as determined by the ASSOCIATION Type of the ASSOCIATION > >>> object. This applies equally to ASSOCIATION objects and > >>> Extended ASSOCIATION objects." > >> > >> Here's the revised text. > >> Identification of association is not modified by this > section. It > >> is important to note that Section 4 defines association > >> identification based on ASSOCIATION object matching, > and that such > >> matching, in the absence of type-specific comparison rules, is > >> based on the comparison of all fields in an ASSOCIATION object. > >> This applies equally to ASSOCIATION objects and Extended > >> ASSOCIATION objects. > > > > I would write (look at the text just above where you state "As > > defined, these objects each contain an Association Source > field and a > > 16-bit Association ID field. As described above, the > contents of the > > object uniquely identifies an association." ... there is a need to > > distinguish between identifying the ASSOCIATION object vs matching > > ASSOCIATION objects). > > sure. But you need to be sure you're noting the difference between the > word "association" and the thing "ASSOCIATION object". I am. > > This would > > > > "The procedure to perform ASSOCIATION object matching as defined in > > Section 4 is not modified by this section. It is important to note > > that Section 4 defines ASSOCIATION object matching if the > ASSOCIATION > > type does not refer to Association Type-specific rules for the > > processing of the ASSOCIATION object (in which case the Association > > Type-specific rules SHALL be applied); otherwise, ASSOCIATION object > > matching applies by comparing all fields in an ASSOCIATION object. > > This procedure applies equally to ASSOCIATION objects and Extended > > ASSOCIATION objects." > > one more time, revised text now reads: > The procedures related to association identification are not > modified by this section. It is important to note that Section 4 > defines the identification of associations based on ASSOCIATION > object matching and that such matching, in the absence of > type-specific comparison rules, is based on the comparison of all > fields in an ASSOCIATION object. This applies equally to > ASSOCIATION objects and Extended ASSOCIATION objects. I would state "in the absence of type-specific comparison rules (for the Ty= pe value of the object being processed), is based on the comparison of all = fields in an ASSOCIATION object." because absence of rules is a generic statement. > >>>>>> - Section 4.2: shouldn't "error processing" being documented ? > >>>> > >>>> Here too, I think the only error processing is as > discussed above. > >>>> Shout if you think otherwise. > >>>> > >>>>>> Example include > >>>>>> admission control where receiving node rejects the > >>>> incoming Path msg if the > >>>>>> originating Global_ID/Ext.ASSOCIATION object isn't included, > >>>> > >>>> Interesting, but this is a type specific error. To me this > >>>> sounds like > >>>> a new admission control error that should be defined as > part of the > >>>> type-specific definition. > >>> > >>> Admission control failures are part of the error codes > >> defined in RFC 2205. > >> > >> exactly! > >> > >>>>>> unauthorized > >>>>>> Global ID ? > >>>> > >>>> Again interesting, but this is a new policy (and policy > error) that > >>>> wasn't proposed or discussed in the WG. I think this > >> would be a fine > >>>> addition, but is beyond the current document discussion. It > >>>> could always be added if proposed. > >>> > >>> I defer this point to the AD. > >> > >> WFM. > >> > >>> > >>>>>> etc. but also mismatches between Association source and Global > >>>>>> Association source ? > >>>> > >>>> How would such a thing be detected, by checking BGP state? > >> I guess we > >>>> could add a new error code, but again I think we're going > >> beyond the > >>>> intent of the document/WG. > >>> > >>> Same here. > >>> > >>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370] > >>>> defined global > >>>>> identifier, > >>>>>> or Global_ID, is based on [RFC5003] and includes the > >>>> operator's Autonomous > >>>>>> System Number (ASN)." while the latter "the use of the > >>>> Global_ID is not > >>>>> related > >>>>>> to the use of the ASN in protocols such as BGP." which one > >>>> applies ? > >>>> > >>>> I'll drop the note. This is better aligned with the field > >> definition > >>>> which has been updated based on comments of other reviewers. > >>>> > >>>> The current definition is: > >>>> > >>>> This field contains a value that is a unique global > >> identifier or > >>>> the special value zero (0). When non-zero and not > >> overridden by > >>>> local policy, the Global_ID as defined in [RFC6370] > >> SHALL be used. > >>>> The special value of zero indicates that no global > >> identifier is > >>>> present. Use of the special value of zero SHOULD be > limited to > >>>> entities contained within a single operator. > >>> > >>> OK > >>> > >>>>>> - Section 5 Documenting means to prevent/mitigate > >>>> mis-association(s) and > >>>>>> possible impact on security would be advisable. If this is > >>>> felt to be > >>>>> "application" or > >>>>>> "type" specific a recommendation should be stated that the > >>>> security mechanisms > >>>>>> have to be documented as part of these documents. > >>>> > >>>> Why is there any additional risk than what " was > >> previously defined in > >>>> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) > >>> > >>> I try to prevent that any further use/documents would state "no > >>> additional risk compared to RFC 4872 and RFC 4873" or > equivalent but > >>> the application is running for voice calls over the > >> Internet which is > >>> a totally different application than G/MPLS Recovery/Resource > >>> Sharing. > >> > >> Fair enough, but what additional issues do you foresee > that should be > >> covered? > > > > Nodes associating sessions, etc. should have the mean to verify the > initiator of the association. > > This is true for every object in RSVP! I have no objection to object > signing, ala SIDR, but this is well beyond the scope of this document > and certainly isn't introduced in this document. We have to bring this point the Security directorate and ask them for guida= nce (there could be a short term and a long term approach). I understand th= e corresponding generic mechanism to perform such verification isn't to be = documented here but it has to be mentioned. We loose track of all these sec= urity holes... hackers don't. OK for the rest. We are nearly done. Thanks, -dimitri. > >>>>>> Editorials: > >>>>>> > >>>>>> - Introduction: "This document expands the possible usage > >>>> of the ASSOCIATION > >>>>>> object to > >>>>>> non-GMPLS and non-recovery contexts." Suggested to state > >>>> the actual the > >>>>>> scope includes RSVP (instead of what it is not) > >>>> > >>>> I'll add: > >>>> The expanded usage applies equally to GMPLS LSPs > [RFC3473], MPLS > >>>> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], > >>>> [RFC3175] and [RFC4860]. > >>> > >>> OK. > >>> > >>>>>> - Introduction: s/different ports/different destination > >> (dst) ports > >>>>>> > >>>> > >>>> sure. > >>>> > >>>>>> - Section 2 would better refer to a "Generalization" > >> rather than a > >>>>> "modification" > >>>>>> > >>>> > >>>> I'd be okay with this, but I think modification makes is less > >>>> likely to be misinterpreted so will leave as is. > >>> > >>> The term modification implies a change in existing > processing (even > >>> if the intention is different) and actually as the > applicability is > >>> now possible to RSVP and MPLS-TE. > >> > >> This isn't a major point for me, so will change it. (In 5 places.) > > > > OK (actually the doc. generalizes the use of the object whereas 4873 > for inst documents type-specific/specialized use of the object) > > > >>>>>> - Section 3 states "As defined by [RFC4872] and reviewed > >>>> in [RFC6689],..." but > >>>>> an > >>>>>> information RFC doesn't review at best "documents" > >>>> certain usage. This > >>>>>> statement is repeated at multiple places. > >>>> > >>>> Why can't it review? This is what the abstract of RFC6689 > >>>> says it does. > >>> > >>> It was overstated in RFC 6689. > >> > >> This document doesn't change 6689. > > > > OK. > > > >>>>>> - Section 3 mentions "Object usage in both Path and Resv > >>>> messages is > >>>>> discussed. > >>>>>> The usage applies equally to > >>>>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP > >>>> RSVP sessions > >>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having > >>>> such statement in the > >>>>>> introduction would desirable. > >>>> > >>>> Fair enough. > >>>> > >>>> Thank you for the review! > >>> > >>> OK. > >>> > >>> Thanks, > >>> -d. > >> > >> Thanks, > >> Lou > > > > Thanks, > > -d. > > Thanks again. > > Lou > > PS I'll submit a revised version of the draft at some point today to > document all changes to date. > > From dimitri.papadimitriou@alcatel-lucent.com Wed Sep 5 09:13:29 2012 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 480C921F86C2 for ; Wed, 5 Sep 2012 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.709 X-Spam-Level: X-Spam-Status: No, score=-8.709 tagged_above=-999 required=5 tests=[AWL=1.540, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 fiK2nx889cm4 for ; Wed, 5 Sep 2012 09:13:28 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 41BBB21F86BE for ; Wed, 5 Sep 2012 09:13:28 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q85GDOf7017246 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 18:13:25 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 5 Sep 2012 18:13:24 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "Bitar, Nabil N" , "thomas.morin@orange.com" , "rtg-dir@ietf.org" Date: Wed, 5 Sep 2012 18:13:23 +0200 Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: Ac2LWi5lBT9ixVAVRpmGtlbGZl+bfwAB/2Gg Message-ID: References: <10549_1346839882_5047254A_10549_4342_1_50472586.3040906@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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, 05 Sep 2012 16:13:29 -0000 I agree with the suggestion of Adrian. Concerning the point that Nabil brings=20 "The only risk could be re-opening discussions already had but that should = be controllable." -> My answer would be we (as document writer) sometime forget to document t= he reasoning/the why on certain protocol engineering/design choices in part= icular those that may not be directly perceptible if one wouldn't be in the= inner-circles. =3D> Thus the question is not about control but writing practices. > -----Original Message----- > From: rtg-dir-bounces@ietf.org=20 > [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Bitar, Nabil N > Sent: Wednesday, September 05, 2012 13:33 > To: thomas.morin@orange.com; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews >=20 > Hi, > Agreed with below. It will be good for a WG to know if there are any > changes are made to a WG doc and potentially why. The only=20 > risk could be > re-opening discussions already had but that should be=20 > controllable. The > alternative would be to explicitly have in the process=20 > notification to the > WG of changes made to the doc as a result of the discussions that the > reviewers/Ads had agreed on and allow chance to have a review=20 > by the WG > scoped to these changes. >=20 > Thanks, > Nabil >=20 > On 9/5/12 6:11 AM, "thomas.morin@orange.com" > wrote: >=20 > >I agree this is a good idea, and that the potential problems=20 > are likely > >to prove minor. > > > >-Thomas > > > >Loa Andersson : > >> +1 > >> > >> I think the second problem that Adrian lists is really two=20 > problems. > >> > >> - to send the comments to the wg list; the list admins can=20 > handle this > >> or you could ask someone to forward your comments to the list > >> - to participating in (even be aware of) a discussion that=20 > follow from > >> comments you send to a wg mailing list you are not=20 > subscribed to. I > >> guess that the authors will be interested in an=20 > acknowledgement that > >> your comments has been correctly addressed and that you will be > >> pinged if you don't respond. Also considering the "Reply=20 > All" culture > >> we live this might be a very minor problem. > >> > >> /Loa > >> > >> On 2012-09-05 04:26, Ross Callon wrote: > >>> +1 > >>> > >>> -----Original Message----- > >>> From: rtg-dir-bounces@ietf.org=20 > [mailto:rtg-dir-bounces@ietf.org] On > >>> Behalf Of Acee Lindem > >>> Sent: Tuesday, September 04, 2012 7:31 PM > >>> To: Lou Berger > >>> Cc: adrian@olddog.co.uk; rtg-dir@ietf.org > >>> Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews > >>> > >>> +1 > >>> On Sep 4, 2012, at 5:57 PM, Lou Berger wrote: > >>> > >>>> I think this is a good idea. I think any substantive review, and > >>>> related discussion, should be of interest to the WG that produced > >>>> the draft. > >>>> > >>>> Lou > >>>> > >>>> On 9/4/2012 4:38 PM, Adrian Farrel wrote: > >>>>> Hi, > >>>>> > >>>>> The current Routing Directorate charter includes a template for > >>>>> review that > >>>>> suggests recipients... > >>>>> > >>>>> > >>>>>

    Routing Directorate Review Template

    > >>>>> > >>>>>

    To: > >>>>>

  • rtg-ads@tools.ietf.org
    • > >>>>>

    Cc: > >>>>>

  • rtg-dir@ietf.org;
    • > >>>>>
  • draft-name.all@tools.ietf.org;
    • > >>>>>

    Subject: > >>>>>

  • RtgDir review: draft-name-version.txt
    • > >>>>> > >>>>> > >>>>> It seems reasonable to expose the reviews and subsequent > >>>>> discussions to the WG. > >>>>> Would anyone object to us adding ... > >>>>> > >>>>>
  • wg-mailing-list
    • > >>>>> > >>>>> to the cc list? > >>>>> > >>>>> I can see two problems with this... > >>>>> > >>>>> 1. A little research is needed to work out the WG=20 > mailing list name > >>>>> because they > >>>>> are not all perfectly intuitive. I don't think this is=20 > beyond your > >>>>> capabilities > >>>>> to handle. > >>>>> > >>>>> 2. Not all reviewers will be members of the WG lists=20 > and signing up > >>>>> is both a > >>>>> pain and risks a DoS on your inbox. However, all lists have > >>>>> moderators and they > >>>>> should be able to admit your messages for the short=20 > exchange that > >>>>> will follow. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Adrian > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >> > >_____________________________________________________________ > _____________ > >_______________________________________________ > > > >Ce message et ses pieces jointes peuvent contenir des informations > >confidentielles ou privilegiees et ne doivent donc > >pas etre diffuses, exploites ou copies sans autorisation. Si=20 > vous avez > >recu ce message par erreur, veuillez le signaler > >a l'expediteur et le detruire ainsi que les pieces jointes.=20 > Les messages > >electroniques etant susceptibles d'alteration, > >France Telecom - Orange decline toute responsabilite si ce=20 > message a ete > >altere, deforme ou falsifie. Merci. > > > >This message and its attachments may contain confidential or=20 > privileged > >information that may be protected by law; > >they should not be distributed, used or copied without authorisation. > >If you have received this email in error, please notify the=20 > sender and > >delete this message and its attachments. > >As emails may be altered, France Telecom - Orange is not liable for > >messages that have been modified, changed or falsified. > >Thank you. > > >=20 > = From lberger@labn.net Wed Sep 5 11:36:35 2012 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 8675921F8685 for ; Wed, 5 Sep 2012 11:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.541 X-Spam-Level: X-Spam-Status: No, score=-99.541 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, 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 IRfClv4HZ42g for ; Wed, 5 Sep 2012 11:36:33 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 395F321F8674 for ; Wed, 5 Sep 2012 11:36:33 -0700 (PDT) Received: (qmail 24155 invoked by uid 0); 5 Sep 2012 17:15:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 5 Sep 2012 17:15:22 -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=EErmldPrIh7lSmSyp7Ufo8oVb26UYVoutid5CTuQ7tE=; b=bah1u4y+mveLZxeQ3cUJipX0SjJvOMVTsX74HXxec4Dr0neHMNIYfwXXrMD9GpmJCM+z9zstNYT3J9W28P2k20URvN/K//BgmAk6ZOL4FZ8y8WXWpf8/96zmLjhVLaAU; Received: from box313.bluehost.com ([69.89.31.113]:33951 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T9JCD-0004uw-Po; Wed, 05 Sep 2012 11:15:22 -0600 Message-ID: <504788AC.3090802@labn.net> Date: Wed, 05 Sep 2012 13:15:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Papadimitriou, Dimitri (Dimitri)" References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> <50474748.1030303@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.4 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: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 18:36:35 -0000 Dimitri (BTW sorry about the dropping the t in my last message) See below. On 9/5/2012 12:08 PM, Papadimitriou, Dimitri (Dimitri) wrote: > Hi Lou, > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, September 05, 2012 14:36 >> To: Papadimitriou, Dimitri (Dimitri) >> Cc: adrian@olddog.co.uk; >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >> >> Hi Dimiri, >> Responses in line... >> >> On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:> Lou, >>> >>> see below, >>> >>>> -----Original Message----- >>>> From: rtg-dir-bounces@ietf.org >>>> [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger >>>> Sent: Tuesday, September 04, 2012 23:54 >>>> To: Papadimitriou, Dimitri (Dimitri) >>>> Cc: adrian@olddog.co.uk; >>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org >>>> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >>>> >>>> Dimitri, >>>> See below. >>>> >>>> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: >>>>> Hi Lou, >>>>> >>>>> See inline: >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Tuesday, September 04, 2012 17:25 >>>>>> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) >>>>>> Cc: rtg-dir@ietf.org; >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org >>>>>> Subject: Re: [RTG-DIR] FW: Review of >> draft-ietf-ccamp-assoc-ext-04 >>>>>> >>>>>> Adrian, >>>>>> Much Thanks. (BTW is there a reason not to include the >>>>>> WG in this, or >>>>>> such, discussions?) >>>>>> >>>>>> Dimitri, >>>>>> Please see below for inline responses. >>>>>> >>>>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote: >>>>>>> Here is Dimitri's Routing Dir review. Many thanks for >> the review. >>>>>>> >>>>>>> Lou, you can address this and the other comments and post a >>>>>> new revision. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Papadimitriou, Dimitri (Dimitri) >>>>>> [mailto:dimitri.papadimitriou@alcatel- >>>>>>>> lucent.com] >>>>>>>> Sent: 31 August 2012 13:23 >>>>>>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; >> sbryant@cisco.com; >>>>>>>> huawei.danli@huawei.com >>>>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Here below the review of this document. >>>>>>>> >>>>>>>> Technical comments: >>>>>>>> >>>>>>>> - Example 3: isn't this extension also not updating RFC 2205 ? >>>>>> >>>>>> Yes. This is stated in the header, abstract and section 3. >>>>> >>>>> I thought to include this in the introduction since other >>>> updated RFC are indicated. >>>>> >>>> >>>> Agreed. Text has been added. >>> >>> OK. >>> >>>>>>>> - The statement "In order to support the more general >>>> usage of the >>>>>>>> ASSOCIATION object," is actually not correct RFC 4872 >>>>>> doesn't prevent support >>>>>>> of >>>>>>>> other usage of the ASSOCIATION object. It has just >>>>>> documented its usage in the >>>>>>>> GMPLS recovery context. >>>>>> >>>>>> I'm not sure how these two statements (the document text >>>> and your last >>>>>> sentence) are mutually inconsistent. I see no text change >>>>>> based on this comment. >>>>> >>>>> I meant: "In order to document the more general usage of >>>> the ASSOCIATION object, ..." >>>>> >>>> >>>> While I don't mind the change in this part of the sentience, >>>> the result >>>> is a bit odd "In order to document the more general usage of the >>>> ASSOCIATION object, this document ..." So will leave as is. >>> >>> "In order to document the more general usage of the ASSOCIATION >> object, this specification ..." >> >> I think we're in the noise here... >> >>>>>>>> - Section 3.1, "Cross-session association based on Path >>>>>> state is defined in >>>>>>>> [RFC4872]." the latter defines cross-LSP association >>>>>> within the same session >>>>>>> (not >>>>>>>> cross-session association) but nothing prevents extending >>>>>> usage to cross- >>>>>>>> Session. >>>>>>>> >>>>>> >>>>>> I see no text change requested based on this comment. >>>>> >>>>> I meant: "Cross-LSP association based on Path state is defined in >>>>> [RFC4872]; here we document cross-session association..." >>>> >>>> I'll change two instances of "Cross-session association" >> to "Cross-LSP >>>> association". >>> >>> OK. >>> >>>>>>>> - Section 3.1.2 the statement "the definition SHOULD allow >>>>>> for association >>>>>>> based >>>>>>>> on identical ASSOCIATION objects" is not clear, does it >>>>>> that the information >>>>>>>> elements part of the object shall be identical ? >>>>>> >>>>>> I see no difference between the current text (object >>>> equivalence) and >>>>>> object information element equivalence. I don't believe >>>>>> there's a case >>>>>> where you can have one without the other. Please >> correct me if you >>>>>> think I'm mistaken. >>>>> >>>>> If the association ID are defined such that: >>>>> >>>>> - the Association ID of Session 1 or LSP 1 points to the >>>> Session ID or LSP ID of LSP 2 >>>>> >>>>> - the Association ID of Session 2 or LSP 2 points to the >>>> Session ID or LSP ID of LSP 1 >>>> >>>> Association based on matching Association ID to Session ID >> is not part >>>> of this draft. >>> >>> if the session ID isn't used - which is possible - >> documenting the ID >>> setting to ensure unicity (per association) is to be documented the >>> definition only states concerning value setting >>> >>> "A value assigned by the the node that originated the association. >>> When combined with the other fields carried in the >> object, this >>> value uniquely identifies an association." >> >> Actually, the document provides additional guidance in the procedures >> section: >> >> The Association ID field MUST be set to a value that uniquely >> identifies the sessions to be associated within the context of the >> Association Source field. The Association Source field MUST be >> set to a unique address assigned to the node originating the >> association. > > The initial statement should be part of the definition in the form > > "The Association ID value space is unique per ?" I write "?" because is it per node, per RSVP process, per Association source ? > > The processing should in my opinion state (or equivalent): > > "The Association ID field MUST be set to a unique value that uniquely > identifies the association between sessions that are associated within > the context of the Association Source field." I frankly don't see any difference in the wording. > >>>>> Other elements aren't necessarily identical. >>>> >>>> They must be identical in the context of this draft and >> the absence of >>>> type-specific processing rules. >>>> >>>>> The setting of the association source is application type >> specific. >>>> >>>> Even if true, I don't see how this impacts the text of the draft. >>> >>> Because a full match (incl.association source) wouldn't apply >>> anymore. I think the point goes to the question does extension >>> include association between sessions that uses two different source >>> addresses that can be two interface address ? >> >> sure. As documented, there is no mention of other fields to check as >> part of association identification. > > I don't get it. If the matching operation implies that all fields > shall be identical including the association source how do you > proceed ? Simple. If the objects are identical, there's an association identified. If not, there's no association. > >>>>> Another case (if I am correctly understanding the related >> text), is >>>>> related to the MPLS-TP section. The association object of two >>>>> non-associated session can have the value fields in the >>>>> ext.association object. >>>> >>>> This is a true statement, but unless the contents of the >> whole object >>>> are identical, there's no association. >>> >>> In GMPLS you will have association source setting being >> identical for >>> many tunnels/LSPs (many controllers will set their local IP address >>> as source) while actually these LSPs aren't. I don't think there is >>> any indication that prevents this to happen ? >> >> Correct and this is intentional. All that is required for >> association is >> a simple match of objects. If two nodes use the same source address >> without coordinating IDs there may be collisions, but there's >> no way to >> know if this is intentional or an error when processing the path/resv >> messages. > > OK. As such this corroborates my initial remark where the association > object was actually the most suited place to put this information. Great. (I think.) > >>>>>>>> - Section 3.1.2 "The Association ID field MUST be set to a >>>>>> value that uniquely >>>>>>>> identifies the sessions to be associated within the >>>>>> context of the Association >>>>>>>> Source field." >>>>>>>> this statement is not compatible with e.g. RFC 4873 and >>>>>> 4872 where >>>>>>> Association >>>>>>>> ID are set to LSP ID and not sessions while it is >> stated in 3.1 " >>>>>> >>>>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" >>>>> >>>>> Yes and section 3.1.2 indicates "These procedures >>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >>>> session state." >>>>> >>>>> don't you think this induces confusion ? >>>> >>>> Perhaps, but this is why the 3.1 states: >>>> This section does not modify processing required to support >>>> [RFC4872] >>>> and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. >>> >>> This being said the Code point for RFC 4873 isn't changed but points >>> to this document. Any reason since there is no processing change ? >> >> I assume you're referring to the Resource Sharing type. This >> is updated as the same type is now usable for non-recovery LSPs. > > OK. > >>>>>> so it does not impact to RFC 4873 and 4872 >>>> implementations. As stated >>>>>> in the draft and quoted by you: >>>>>> >>>>>>> This section >>>>>>> does not >>>>>>>> modify processing required to support [RFC4872] and >>>>>> [RFC4873], and which is >>>>>>>> reviewed in Section 3 of [RFC6689]. " >>>>> >>>>> The point I am raising is that Section 3.1 reads as there no >>>>> "additions" whereas once reaching Section 3.1.2 one >> understands that >>>>> the statement no modifications meant actually extensions. >>>>> >>>>> Section 3.1 states "This section does not modify processing >>>> required to >>>>> support [RFC4872] and [RFC4873], and which is reviewed >>>> in Section 3 >>>>> of [RFC6689]. " >>>>> >>>>> Section 3.1.2 states " These procedures >>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >>>> session state." >>>>> >>>>> Hence, >>>>> >>>>> Section 3.1.2 should be rephrased as >>>>> >>>>> "This section is based on the processing rules described >>>> in [RFC4872] >>>>> and [RFC4873], and which is reviewed in [RFC6689]. >>>> These procedures >>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >>>> session state." >>>>> >>>>> Section 3.1.2 should be rephrased as >>>>> >>>>> "This section generalizes the processing rules described >>>> in [RFC4872] >>>>> and [RFC4873], and which is reviewed in [RFC6689], for >>>> application >>>>> to MPLS LSPs and non-LSP session state. For GMPLS LSP rules are >>>>> extended for applications not related to the recovery >>>> and resource >>>>> sharing." >>>> >>>> I've revised the text to read: >>>> >>>> This section is based on, and extends, the processing rules >>>> described in [RFC4872] and [RFC4873], and which is reviewed in >>>> [RFC6689]. This section applies equally to GMPLS >> LSPs, MPLS LSPs >>>> and non-LSP session state. Note, as previously stated, this >>>> section does not modify processing required to support >> [RFC4872] >>>> and [RFC4873]. >>> >>> OK. >>> >>>>>> 2) I also think "not compatible" is an overstatement, but >>>> I guess that >>>>>> it isn't really a critical point to discuss as the >> referenced text >>>>>> doesn't relate to [RFC4872] and [RFC4873]. >>>>> >>>>> The proposed phrasing would resolve it. >>>>> >>>>>>>> and in RFC 4873/Section 3.2 "The >>>>>>>> ASSOCIATION object is used to associate different LSPs >>>>>> with each other." >>>>>> >>>>>> I see no text change requested based on this comment. >>>>> >>>>> Ditto. >>>>> >>>>>>>> - Section 3.1.2 "An association is deemed to exist when >>>>>> the same values are >>>>>>>> carried in all fields of the ASSOCIATION objects being >>>>>> compared." this >>>>>>> introduces >>>>>>>> an additional level of indirection. To associate A to B A >>>>>> can simply refer to >>>>>>> an >>>>>>>> identifier of B (and vice versa), A doesn't need to have >>>>>> an additional ID >>>>>>> (e.g. C) >>>>>>>> that is also associated to B. Generalization would consist >>>>>> here in introducing >>>>>>> an >>>>>>>> ext.association ID common to A, B, and C. In other terms, >>>>>> generalizing the >>>>>>> notion >>>>>>>> of association doesn't require the introduction of an >>>>>> additional level of >>>>>>>> indirection. >>>>>> >>>>>> I really have no idea what this comment means. There is no >>>>>> indirection stated or implied by the text. >>>>> >>>>> It is the result of what the text implies and it is specifically >>>>> related to the "Association ID". Implicitly the document mandates >>>>> than this identifier can't take any value of existing fields >>>>> identifying tunnels/LSPs. >>>> >>>> Not at all. As long as the IDs as consistently set across >> association >>>> objects, an association will be made. Furthermore, type specific >>>> processing can be defined that allows implicit mapping such as you >>>> defined in 4872. >>> >>> The first item to check is the Association Type to distinguish >>> between matching processes. The statement "In the absence of >>> Association Type-specific rules for identifying association,.." was >>> probably intended to state (to remove the confusion of the statement >>> "identifying assocation"): >>> >>> "If the ASSOCIATION type does not refer to Association Type-specific >>> rules for the processing of the ASSOCIATION object (in >> which case the >>> Association Type-specific rules SHALL be applied), ..." >> >> IMO this should be left to the definition of the Association >> Type-specific rules, i.e., is beyond the scope of this document. > > OK. > >>>>>> It means test for simple equivalence, >>>>>> i.e., (ASSOCIATION object of A) = (ASSOCIATION object of >>>> B) and that's >>>>>> it. There's no (session) ID referencing. Can you restate >>>>>> your concern? >>>>> >>>>> My concern is this an equivalence between objects not an >>>> assocation of sessions. >>>>> >>>> >>>> Per this document, equivalence between objects identifies an >>>> assocation >>>> of sessions. This document does not generalize the session ID to >>>> association ID matching that was part of 4872. >>> >>> The above text would clarify the point. >> >> The following has been added to the second to last paragraph >> of Section 1. >> >> When using the procedures defined below, association is identified >> based on simple ASSOCIATION object matching. Some of the other >> matching mechanisms defined in RFC 4872, e.g., matching based on >> Session IDs, are not generalized. > > I would write: > > When using the procedures defined in this document, association is identified > based on ASSOCIATION object matching. Some of the other > matching mechanisms defined in RFC 4872, e.g., matching based on > Session IDs, are not generalized in this document. Association > type-specific processing is outside the scope of this document. > understood, I'll modify the paragraph. (subject to style differences.) >>>>>>>> - Section 3.2.2 I understand triggers for Resv-initiated >>>>>> associations aren't >>>>>>>> documented but how to prevent a sender willing to demote >>>>>> receiver-driven >>>>>>>> associations ? >>>>>> >>>>>> Can you clarify this question? >>>>> >>>>> Let me put first in context. Generalization includes Rcv driven >>>>> associations but only additions are documented. >>>>> >>>>>> Are you asking: >>>>>> - how a Path sender can prevent a receiver initiated >>>> association? (it >>>>>> can't) >>>>>> >>>>>> - how a Resv sender removes an association? (it just removes >>>>>> the object, no different from a path message) >>>>> >>>>> The corresponding processing is to be documented. Because one can >>>>> also demote an association by having each LSP/session pointing to >>>>> itself while keeping the object in the Path/Resv message. >>>> >>>> This sounds like the implicit matching rules in 4872. >> Such session ID >>>> to association ID matching is not part of this document. >>> >>> I hear you but as the ASSOCIATION ID value setting doesn't state it >>> can't be done, you can get the same result. >> >> Sure, and this would be perfectly fine way for an implementation to >> select its IDs for certain possible applications, but this is a local >> implementation choice in the general case, or type-specific processing >> which is outside the scope of this document. > > OK. > >>> You could even assume that changing ID to an unused but value would >>> lead to the same result (as matching wouldn't give a positive result >>> the ASSOCIATION would also be removed since it can't be found >>> anymore). >> >> >>> >>>>>> - something else? >>>>>> >>>>>>>> - Section 3.1.2 and 3.2.2 no error processing is being >> documented >>>>>> >>>>>> I think this is a fair point. The only case I think that >>>>>> can/should be >>>>>> addressed is unknown types. (As is usual, per RFC2205, errors in >>>>>> formats to not trigger any specific message response.) >>>>>> Sections 3.1 and >>>>>> 3.2 only discuss identification of associations, so I >>>> propose adding a >>>>>> section 3.3.2. How about something like: >>>>>> >>>>>> 3.3.2. Unknown Association Types >>>>>> >>>>>> A node that receives an ASSOCIATION object with an unknown >>>>>> ASSOCIATION type MUST forward all received ASSOCIATION objects >>>>>> as defined above. The node MAY also identify associations per >>>>>> the defined processing, e.g., to make this information >> available >>>>>> via a management interface. >>>>> >>>>> OK. Wouldn't you document PathErr/ResvErr and Notify ? >>>> >>>> IMO Not for an unknown type. >>> >>> I don't understand the answer. >> >> I don't think unknown type should result in a PathErr/ResvErr at a >> transit/egress/ingress node. > > The question why do you use "unknown" type and not > > Error Code = 01: "Admission Control Failure" (see [RFC2205]) > > o "Admission Control Failure/Session Admission Failure" (6) Because I don't think lack of support of a type should result in an error in the general case. (for example would you generate an error on transit nodes for associations that are only relevant to end-points, or vice versa?) > >>>>>>>> whereas mis- >>>>>>>> match in association should be considered as a generic error. >>>>>> >>>>>> This isn't a detectable error case as it is impossible for >>>> a node to >>>>>> know if two association objects are intentionally or >>>> unintentionally >>>>>> different. >>>>> >>>>> Earlier, in the text it is mentioned that processing >>>> implies checking >>>>> all Path/Resv state. We have to understand that putting in place a >>>>> generic processing (outside a specific ASSOCIATION Type) renders >>>> >>>> I think this sentence got truncated... >>> >>> ... safeguard rule advisable. >>> >>>>>>>> - Section 3.3 states "Since the admission control function >>>>>> is outside the >>>>>>> scope of >>>>>>>> RSVP,..." are you sure ? >>>>>> >>>>>> Yes. Per RFC2205: >>>>> >>>>> Yes I know the figuere whose terms mixes functions, protocol >>>>> processes, etc. but this goes beyond the review of this >> document ;-) >>>> > [snip figure] >>>>>> an RSVP QoS request is passed to two local >>>>>> decision modules, "admission control" and "policy control". >>>>>> >>>>>>>> admission control is an intrinsic function associated >>>>>>> to RFC >>>>>>>> 2205 (there are errors documented for admission control >>>>>> failures). I think you >>>>>>>> mean that the inner working of the mechanisms used by >>>>>> nodes to determine if >>>>>>>> they have sufficient available resources to support >>>>>> incoming requests. >>>>>> >>>>>> I think this is the same as what is stated. >>>>> >>>>> What you mean is: the inner-working or implementation of admission >>>>> control for QoS requests is outside scope of RFC 2205. >>>>> >>>>>> we can add "implementation specifics ", i.e., " Since the >>>>>> implementation >>>>>> specifics of the admission control function is outside the >>>>>> scope " if it helps. >>>>> >>>>> Yes it does because the term "outside scope" has different >>>> meanings depending on context. >>>>> >>>> >>>> done. >>>> >>>>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION >>>>>> object and the IPv6 >>>>>>>> ASSOCIATION object. As defined, these objects each contain >>>>>> an Association >>>>>>>> Source field and a 16-bit Association ID field. The >>>>>> combination of the >>>>>>> Association >>>>>>>> Source and the Association ID uniquely identifies the >>>>>> association." but in the >>>>>>>> context RFC 4872 this association is defined in the >>>>>> context of the same tunnel >>>>>>>> end-point >>>>>> >>>>>> How about we clarify: "*As described above,* the >>>>>> combination of the Association Source and the Association ID >>>>>> uniquely identifies the association." >>>>> >>>>> It would be better to state >>>>> >>>>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >>>>> ASSOCIATION object in the context of a given session. As defined, >>>>> these objects each contain an Association Source field >> and a 16-bit >>>>> Association ID field. The combination of the Association >> Source and >>>>> the Association ID uniquely identifies the association. >> This doesn't >>>>> prevent that Association Types MAY further specify the context for >>>>> which this association is defined." >>>> >>>> It now reads: >>>> >>>> [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >>>> ASSOCIATION object. As defined, these objects each contain an >>>> Association Source field and a 16-bit Association ID field. As >>>> described above, the contents of the object uniquely identifies >>>> an association. Because the Association ID field is a 16-bit >>>> field, an association source can allocate up to 65536 different >>>> associations and no more. >>> >>> OK >>> >>>>>>> (and actually the same for RFC 4873 which relies on MBB >> as defined >>>>>>> in >>>>>>>> RFC 3209) >>>>>> >>>>>> I don't believe this statement is correct, but again this >>>> is really a >>>>>> discussion beyond this draft. >>>>> >>>>> The statement here above is also to applicable to RFC 4873. >>>>> >>>>>>>> - Section 4: How is the following use case "There are >>>>>> scenarios where this >>>>>>> number >>>>>>>> is insufficient. (For example where the association >>>>>> identification is best >>>>>>> known >>>>>>>> and identified by a fairly centralized entity, which >>>>>> therefore may be involved >>>>>>> in a >>>>>>>> large number of associations.)" related to those proposed >>>>>> in the introduction. >>>>>>> ? >>>>>> >>>>>> As I read it, it enables practical third party (e.g., >>>>>> management entity) >>>>>> creation and management of association IDs. But, I'll >> defer to my >>>>>> coauthors on this. >>>>> >>>>> OK. Please let me know the result(s) of the discussion. >>>>> >>>>>>>> - Section 4: I don't question the requirement stated in >>>>>> "Per [RFC6370], >>>>>>> MPLS-TP >>>>>>>> LSPs can be identified based on an operator unique global >>>>>> identifier. The >>>>>>>> [RFC6370] defined "global identifier", or Global_ID, is >>>>>> based on [RFC5003] and >>>>>>>> includes the operator's Autonomous System Number (ASN)." >>>>>> the question is why >>>>>>>> the information is best encoded as part of the ASSOCIATION >>>>>> object ? isn't this >>>>>>> an >>>>>>>> LSP ATTRIBUTE or a Session Name ? >>>>>> >>>>>> It's the solution the WG agreed to. Other options are of >>>>>> course possible. >>>>> >>>>> My comment is specific because it triggers the question >> on how many >>>>> objects will we end up in spreading identification information (it >>>>> would be interesting to document the why this was felt the most >>>>> suited object as it is not a natural choice); more general >>>> comment is >>>>> what defines the "acceptable" use/extension of association. >>>> >>>> I think the last comment is a reasonable discussion to >> have. Not sure >>>> it belongs in, or gates the discussion. >>> >>> The LSP attributes RFC included this info for instance. This has >>> prevented lots of problems in use of the object because the content >>> of most objects could have been added to the LSP attribute RFC (cf. >>> Sect.8 "8. Summary of Attribute Bit Allocation" and Sect.10 >>> "Guidance for Key Application Scenarios"). >> >> Do you have some suggestions/text in mind? > > I will propose a Section for this. Can be done as part of this e-mail. > >>>>>>>> - Section 4.2: states "It is important to note that >>>>>> Section 4 defines >>>>>>> association >>>>>>>> identification based on ASSOCIATION object matching, and >>>>>> that such matching >>>>>>> is >>>>>>>> based on the comparison of all fields in a ASSOCIATION >>>>>> object (unless type- >>>>>>>> specific comparison rules are defined). This applies >>>>>> equally to ASSOCIATION >>>>>>>> objects and Extended ASSOCIATION objects." any association >>>>>> is based on a form >>>>>>>> of matching, point here is that the matching and the >>>>>> identification of the >>>>>>> initiation >>>>>>>> of the matching information are distinct information >>>>>> entities (difference >>>>>>> between >>>>>>>> WHO and WHAT). I suggest to make a clearer distinction and >>>>>> specify setting and >>>>>>>> processing accordingly. >>>>>> >>>>>> I'm not seeing the issue. Can you perhaps propose some text? >>>>> >>>>> Here is the proposed text >>>>> >>>>> "It is important to note that Section 4 defines association >>>>> identification based on ASSOCIATION object matching, and >>>>> that such matching is based on the comparison of the fields >>>>> as determined by the ASSOCIATION Type of the ASSOCIATION >>>>> object. This applies equally to ASSOCIATION objects and >>>>> Extended ASSOCIATION objects." >>>> >>>> Here's the revised text. >>>> Identification of association is not modified by this >> section. It >>>> is important to note that Section 4 defines association >>>> identification based on ASSOCIATION object matching, >> and that such >>>> matching, in the absence of type-specific comparison rules, is >>>> based on the comparison of all fields in an ASSOCIATION object. >>>> This applies equally to ASSOCIATION objects and Extended >>>> ASSOCIATION objects. >>> >>> I would write (look at the text just above where you state "As >>> defined, these objects each contain an Association Source >> field and a >>> 16-bit Association ID field. As described above, the >> contents of the >>> object uniquely identifies an association." ... there is a need to >>> distinguish between identifying the ASSOCIATION object vs matching >>> ASSOCIATION objects). >> >> sure. But you need to be sure you're noting the difference between the >> word "association" and the thing "ASSOCIATION object". > > I am. > >>> This would >>> >>> "The procedure to perform ASSOCIATION object matching as defined in >>> Section 4 is not modified by this section. It is important to note >>> that Section 4 defines ASSOCIATION object matching if the >> ASSOCIATION >>> type does not refer to Association Type-specific rules for the >>> processing of the ASSOCIATION object (in which case the Association >>> Type-specific rules SHALL be applied); otherwise, ASSOCIATION object >>> matching applies by comparing all fields in an ASSOCIATION object. >>> This procedure applies equally to ASSOCIATION objects and Extended >>> ASSOCIATION objects." >> >> one more time, revised text now reads: >> The procedures related to association identification are not >> modified by this section. It is important to note that Section 4 >> defines the identification of associations based on ASSOCIATION >> object matching and that such matching, in the absence of >> type-specific comparison rules, is based on the comparison of all >> fields in an ASSOCIATION object. This applies equally to >> ASSOCIATION objects and Extended ASSOCIATION objects. > > I would state "in the absence of type-specific comparison rules (for > the Type value of the object being processed), is based on the > comparison of all fields in an ASSOCIATION object." > > because absence of rules is a generic statement. Again, I don't see the difference in meaning -- I think we're in the domain of style here. > >>>>>>>> - Section 4.2: shouldn't "error processing" being documented ? >>>>>> >>>>>> Here too, I think the only error processing is as >> discussed above. >>>>>> Shout if you think otherwise. >>>>>> >>>>>>>> Example include >>>>>>>> admission control where receiving node rejects the >>>>>> incoming Path msg if the >>>>>>>> originating Global_ID/Ext.ASSOCIATION object isn't included, >>>>>> >>>>>> Interesting, but this is a type specific error. To me this >>>>>> sounds like >>>>>> a new admission control error that should be defined as >> part of the >>>>>> type-specific definition. >>>>> >>>>> Admission control failures are part of the error codes >>>> defined in RFC 2205. >>>> >>>> exactly! >>>> >>>>>>>> unauthorized >>>>>>>> Global ID ? >>>>>> >>>>>> Again interesting, but this is a new policy (and policy >> error) that >>>>>> wasn't proposed or discussed in the WG. I think this >>>> would be a fine >>>>>> addition, but is beyond the current document discussion. It >>>>>> could always be added if proposed. >>>>> >>>>> I defer this point to the AD. >>>> >>>> WFM. >>>> >>>>> >>>>>>>> etc. but also mismatches between Association source and Global >>>>>>>> Association source ? >>>>>> >>>>>> How would such a thing be detected, by checking BGP state? >>>> I guess we >>>>>> could add a new error code, but again I think we're going >>>> beyond the >>>>>> intent of the document/WG. >>>>> >>>>> Same here. >>>>> >>>>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370] >>>>>> defined global >>>>>>> identifier, >>>>>>>> or Global_ID, is based on [RFC5003] and includes the >>>>>> operator's Autonomous >>>>>>>> System Number (ASN)." while the latter "the use of the >>>>>> Global_ID is not >>>>>>> related >>>>>>>> to the use of the ASN in protocols such as BGP." which one >>>>>> applies ? >>>>>> >>>>>> I'll drop the note. This is better aligned with the field >>>> definition >>>>>> which has been updated based on comments of other reviewers. >>>>>> >>>>>> The current definition is: >>>>>> >>>>>> This field contains a value that is a unique global >>>> identifier or >>>>>> the special value zero (0). When non-zero and not >>>> overridden by >>>>>> local policy, the Global_ID as defined in [RFC6370] >>>> SHALL be used. >>>>>> The special value of zero indicates that no global >>>> identifier is >>>>>> present. Use of the special value of zero SHOULD be >> limited to >>>>>> entities contained within a single operator. >>>>> >>>>> OK >>>>> >>>>>>>> - Section 5 Documenting means to prevent/mitigate >>>>>> mis-association(s) and >>>>>>>> possible impact on security would be advisable. If this is >>>>>> felt to be >>>>>>> "application" or >>>>>>>> "type" specific a recommendation should be stated that the >>>>>> security mechanisms >>>>>>>> have to be documented as part of these documents. >>>>>> >>>>>> Why is there any additional risk than what " was >>>> previously defined in >>>>>> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) >>>>> >>>>> I try to prevent that any further use/documents would state "no >>>>> additional risk compared to RFC 4872 and RFC 4873" or >> equivalent but >>>>> the application is running for voice calls over the >>>> Internet which is >>>>> a totally different application than G/MPLS Recovery/Resource >>>>> Sharing. >>>> >>>> Fair enough, but what additional issues do you foresee >> that should be >>>> covered? >>> >>> Nodes associating sessions, etc. should have the mean to verify the >> initiator of the association. >> >> This is true for every object in RSVP! I have no objection to object >> signing, ala SIDR, but this is well beyond the scope of this document >> and certainly isn't introduced in this document. > > We have to bring this point the Security directorate and ask them for > guidance (there could be a short term and a long term approach). I > understand the corresponding generic mechanism to perform such > verification isn't to be documented here but it has to be mentioned. > We loose track of all these security holes... hackers don't. RSVP's chain of trust is called out in RFC5920, which is reference by this draft. I certainly have no issue with a general discussion on RSVP's chain of trust model, but the scope of this conversation is beyond (and should be scoped) to this draft. Thanks, Lou > > OK for the rest. We are nearly done. > > Thanks, > -dimitri. >>>>>>>> Editorials: >>>>>>>> >>>>>>>> - Introduction: "This document expands the possible usage >>>>>> of the ASSOCIATION >>>>>>>> object to >>>>>>>> non-GMPLS and non-recovery contexts." Suggested to state >>>>>> the actual the >>>>>>>> scope includes RSVP (instead of what it is not) >>>>>> >>>>>> I'll add: >>>>>> The expanded usage applies equally to GMPLS LSPs >> [RFC3473], MPLS >>>>>> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], >>>>>> [RFC3175] and [RFC4860]. >>>>> >>>>> OK. >>>>> >>>>>>>> - Introduction: s/different ports/different destination >>>> (dst) ports >>>>>>>> >>>>>> >>>>>> sure. >>>>>> >>>>>>>> - Section 2 would better refer to a "Generalization" >>>> rather than a >>>>>>> "modification" >>>>>>>> >>>>>> >>>>>> I'd be okay with this, but I think modification makes is less >>>>>> likely to be misinterpreted so will leave as is. >>>>> >>>>> The term modification implies a change in existing >> processing (even >>>>> if the intention is different) and actually as the >> applicability is >>>>> now possible to RSVP and MPLS-TE. >>>> >>>> This isn't a major point for me, so will change it. (In 5 places.) >>> >>> OK (actually the doc. generalizes the use of the object whereas 4873 >> for inst documents type-specific/specialized use of the object) >>> >>>>>>>> - Section 3 states "As defined by [RFC4872] and reviewed >>>>>> in [RFC6689],..." but >>>>>>> an >>>>>>>> information RFC doesn't review at best "documents" >>>>>> certain usage. This >>>>>>>> statement is repeated at multiple places. >>>>>> >>>>>> Why can't it review? This is what the abstract of RFC6689 >>>>>> says it does. >>>>> >>>>> It was overstated in RFC 6689. >>>> >>>> This document doesn't change 6689. >>> >>> OK. >>> >>>>>>>> - Section 3 mentions "Object usage in both Path and Resv >>>>>> messages is >>>>>>> discussed. >>>>>>>> The usage applies equally to >>>>>>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP >>>>>> RSVP sessions >>>>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having >>>>>> such statement in the >>>>>>>> introduction would desirable. >>>>>> >>>>>> Fair enough. >>>>>> >>>>>> Thank you for the review! >>>>> >>>>> OK. >>>>> >>>>> Thanks, >>>>> -d. >>>> >>>> Thanks, >>>> Lou >>> >>> Thanks, >>> -d. >> >> Thanks again. >> >> Lou >> >> PS I'll submit a revised version of the draft at some point today to >> document all changes to date. >> >> > > > > From dimitri.papadimitriou@alcatel-lucent.com Wed Sep 5 13:51:03 2012 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 680D221F863C for ; Wed, 5 Sep 2012 13:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.474 X-Spam-Level: X-Spam-Status: No, score=-8.474 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 FIu4XajKegRh for ; Wed, 5 Sep 2012 13:51:00 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3898D21F851A for ; Wed, 5 Sep 2012 13:51:00 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q85Kon9f002741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 22:50:56 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 5 Sep 2012 22:50:51 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lou Berger Date: Wed, 5 Sep 2012 22:50:50 +0200 Thread-Topic: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 Thread-Index: Ac2LlV4KoHtMc5/yQcux0+rs707HwAADbZfQ Message-ID: References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> <50474748.1030303@labn.net> <504788AC.3090802@labn.net> In-Reply-To: <504788AC.3090802@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 20:51:03 -0000 Lou, > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, September 05, 2012 19:15 > To: Papadimitriou, Dimitri (Dimitri) > Cc: adrian@olddog.co.uk; > draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > > Dimitri (BTW sorry about the dropping the t in my last message) > > See below. > > On 9/5/2012 12:08 PM, Papadimitriou, Dimitri (Dimitri) wrote: > > Hi Lou, > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Wednesday, September 05, 2012 14:36 > >> To: Papadimitriou, Dimitri (Dimitri) > >> Cc: adrian@olddog.co.uk; > >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > >> > >> Hi Dimiri, > >> Responses in line... > >> > >> On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:> Lou, > >>> > >>> see below, > >>> > >>>> -----Original Message----- > >>>> From: rtg-dir-bounces@ietf.org > >>>> [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger > >>>> Sent: Tuesday, September 04, 2012 23:54 > >>>> To: Papadimitriou, Dimitri (Dimitri) > >>>> Cc: adrian@olddog.co.uk; > >>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > >>>> Subject: Re: [RTG-DIR] FW: Review of > draft-ietf-ccamp-assoc-ext-04 > >>>> > >>>> Dimitri, > >>>> See below. > >>>> > >>>> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: > >>>>> Hi Lou, > >>>>> > >>>>> See inline: > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>>> Sent: Tuesday, September 04, 2012 17:25 > >>>>>> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) > >>>>>> Cc: rtg-dir@ietf.org; > >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org > >>>>>> Subject: Re: [RTG-DIR] FW: Review of > >> draft-ietf-ccamp-assoc-ext-04 > >>>>>> > >>>>>> Adrian, > >>>>>> Much Thanks. (BTW is there a reason not to include the > >>>>>> WG in this, or > >>>>>> such, discussions?) > >>>>>> > >>>>>> Dimitri, > >>>>>> Please see below for inline responses. > >>>>>> > >>>>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote: > >>>>>>> Here is Dimitri's Routing Dir review. Many thanks for > >> the review. > >>>>>>> > >>>>>>> Lou, you can address this and the other comments and post a > >>>>>> new revision. > >>>>>>> > >>>>>>> Adrian > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Papadimitriou, Dimitri (Dimitri) > >>>>>> [mailto:dimitri.papadimitriou@alcatel- > >>>>>>>> lucent.com] > >>>>>>>> Sent: 31 August 2012 13:23 > >>>>>>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; > >> sbryant@cisco.com; > >>>>>>>> huawei.danli@huawei.com > >>>>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 > >>>>>>>> > >>>>>>>> Hi All, > >>>>>>>> > >>>>>>>> Here below the review of this document. > >>>>>>>> > >>>>>>>> Technical comments: > >>>>>>>> > >>>>>>>> - Example 3: isn't this extension also not updating > RFC 2205 ? > >>>>>> > >>>>>> Yes. This is stated in the header, abstract and section 3. > >>>>> > >>>>> I thought to include this in the introduction since other > >>>> updated RFC are indicated. > >>>>> > >>>> > >>>> Agreed. Text has been added. > >>> > >>> OK. > >>> > >>>>>>>> - The statement "In order to support the more general > >>>> usage of the > >>>>>>>> ASSOCIATION object," is actually not correct RFC 4872 > >>>>>> doesn't prevent support > >>>>>>> of > >>>>>>>> other usage of the ASSOCIATION object. It has just > >>>>>> documented its usage in the > >>>>>>>> GMPLS recovery context. > >>>>>> > >>>>>> I'm not sure how these two statements (the document text > >>>> and your last > >>>>>> sentence) are mutually inconsistent. I see no text change > >>>>>> based on this comment. > >>>>> > >>>>> I meant: "In order to document the more general usage of > >>>> the ASSOCIATION object, ..." > >>>>> > >>>> > >>>> While I don't mind the change in this part of the sentience, > >>>> the result > >>>> is a bit odd "In order to document the more general usage of the > >>>> ASSOCIATION object, this document ..." So will leave as is. > >>> > >>> "In order to document the more general usage of the ASSOCIATION > >> object, this specification ..." > >> > >> I think we're in the noise here... > >> > >>>>>>>> - Section 3.1, "Cross-session association based on Path > >>>>>> state is defined in > >>>>>>>> [RFC4872]." the latter defines cross-LSP association > >>>>>> within the same session > >>>>>>> (not > >>>>>>>> cross-session association) but nothing prevents extending > >>>>>> usage to cross- > >>>>>>>> Session. > >>>>>>>> > >>>>>> > >>>>>> I see no text change requested based on this comment. > >>>>> > >>>>> I meant: "Cross-LSP association based on Path state is > defined in > >>>>> [RFC4872]; here we document cross-session association..." > >>>> > >>>> I'll change two instances of "Cross-session association" > >> to "Cross-LSP > >>>> association". > >>> > >>> OK. > >>> > >>>>>>>> - Section 3.1.2 the statement "the definition SHOULD allow > >>>>>> for association > >>>>>>> based > >>>>>>>> on identical ASSOCIATION objects" is not clear, does it > >>>>>> that the information > >>>>>>>> elements part of the object shall be identical ? > >>>>>> > >>>>>> I see no difference between the current text (object > >>>> equivalence) and > >>>>>> object information element equivalence. I don't believe > >>>>>> there's a case > >>>>>> where you can have one without the other. Please > >> correct me if you > >>>>>> think I'm mistaken. > >>>>> > >>>>> If the association ID are defined such that: > >>>>> > >>>>> - the Association ID of Session 1 or LSP 1 points to the > >>>> Session ID or LSP ID of LSP 2 > >>>>> > >>>>> - the Association ID of Session 2 or LSP 2 points to the > >>>> Session ID or LSP ID of LSP 1 > >>>> > >>>> Association based on matching Association ID to Session ID > >> is not part > >>>> of this draft. > >>> > >>> if the session ID isn't used - which is possible - > >> documenting the ID > >>> setting to ensure unicity (per association) is to be > documented the > >>> definition only states concerning value setting > >>> > >>> "A value assigned by the the node that originated the association. > >>> When combined with the other fields carried in the > >> object, this > >>> value uniquely identifies an association." > >> > >> Actually, the document provides additional guidance in the > procedures > >> section: > >> > >> The Association ID field MUST be set to a value that uniquely > >> identifies the sessions to be associated within the > context of the > >> Association Source field. The Association Source field MUST be > >> set to a unique address assigned to the node originating the > >> association. > > > > The initial statement should be part of the definition in the form > > > > "The Association ID value space is unique per ?" I write > "?" because is it per node, per RSVP process, per Association source ? what about the above one concerning the unicity ? > > The processing should in my opinion state (or equivalent): > > > > "The Association ID field MUST be set to a unique value > that uniquely > > identifies the association between sessions that are > associated within > > the context of the Association Source field." > > I frankly don't see any difference in the wording. "uniquely identify the sessions to be associated" vs "uniquely identify the association" is clearly different. > >>>>> Other elements aren't necessarily identical. > >>>> > >>>> They must be identical in the context of this draft and > >> the absence of > >>>> type-specific processing rules. > >>>> > >>>>> The setting of the association source is application type > >> specific. > >>>> > >>>> Even if true, I don't see how this impacts the text of the draft. > >>> > >>> Because a full match (incl.association source) wouldn't apply > >>> anymore. I think the point goes to the question does extension > >>> include association between sessions that uses two > different source > >>> addresses that can be two interface address ? > >> > >> sure. As documented, there is no mention of other fields > to check as > >> part of association identification. > > > > I don't get it. If the matching operation implies that all fields > > shall be identical including the association source how do you > > proceed ? > > Simple. If the objects are identical, there's an association > identified. If not, there's no association. This is not the question. If the association are set per source interface h= ow this mechanism shall be used ? The point I am raising here is this precl= uded by design and it is a common case which likely to happen with the exam= ples you have highlighted in the introduction. > >>>>> Another case (if I am correctly understanding the related > >> text), is > >>>>> related to the MPLS-TP section. The association object of two > >>>>> non-associated session can have the value fields in the > >>>>> ext.association object. > >>>> > >>>> This is a true statement, but unless the contents of the > >> whole object > >>>> are identical, there's no association. > >>> > >>> In GMPLS you will have association source setting being > >> identical for > >>> many tunnels/LSPs (many controllers will set their local > IP address > >>> as source) while actually these LSPs aren't. I don't > think there is > >>> any indication that prevents this to happen ? > >> > >> Correct and this is intentional. All that is required for > >> association is > >> a simple match of objects. If two nodes use the same > source address > >> without coordinating IDs there may be collisions, but there's > >> no way to > >> know if this is intentional or an error when processing > the path/resv > >> messages. > > > > OK. As such this corroborates my initial remark where the > association > > object was actually the most suited place to put this information. > > Great. (I think.) I meant was *not* (sorry for the confusion). > >>>>>>>> - Section 3.1.2 "The Association ID field MUST be set to a > >>>>>> value that uniquely > >>>>>>>> identifies the sessions to be associated within the > >>>>>> context of the Association > >>>>>>>> Source field." > >>>>>>>> this statement is not compatible with e.g. RFC 4873 and > >>>>>> 4872 where > >>>>>>> Association > >>>>>>>> ID are set to LSP ID and not sessions while it is > >> stated in 3.1 " > >>>>>> > >>>>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" > >>>>> > >>>>> Yes and section 3.1.2 indicates "These procedures > >>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >>>> session state." > >>>>> > >>>>> don't you think this induces confusion ? > >>>> > >>>> Perhaps, but this is why the 3.1 states: > >>>> This section does not modify processing required to support > >>>> [RFC4872] > >>>> and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. > >>> > >>> This being said the Code point for RFC 4873 isn't changed > but points > >>> to this document. Any reason since there is no processing change ? > >> > >> I assume you're referring to the Resource Sharing type. This > >> is updated as the same type is now usable for non-recovery LSPs. > > > > OK. > > > >>>>>> so it does not impact to RFC 4873 and 4872 > >>>> implementations. As stated > >>>>>> in the draft and quoted by you: > >>>>>> > >>>>>>> This section > >>>>>>> does not > >>>>>>>> modify processing required to support [RFC4872] and > >>>>>> [RFC4873], and which is > >>>>>>>> reviewed in Section 3 of [RFC6689]. " > >>>>> > >>>>> The point I am raising is that Section 3.1 reads as there no > >>>>> "additions" whereas once reaching Section 3.1.2 one > >> understands that > >>>>> the statement no modifications meant actually extensions. > >>>>> > >>>>> Section 3.1 states "This section does not modify processing > >>>> required to > >>>>> support [RFC4872] and [RFC4873], and which is reviewed > >>>> in Section 3 > >>>>> of [RFC6689]. " > >>>>> > >>>>> Section 3.1.2 states " These procedures > >>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >>>> session state." > >>>>> > >>>>> Hence, > >>>>> > >>>>> Section 3.1.2 should be rephrased as > >>>>> > >>>>> "This section is based on the processing rules described > >>>> in [RFC4872] > >>>>> and [RFC4873], and which is reviewed in [RFC6689]. > >>>> These procedures > >>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >>>> session state." > >>>>> > >>>>> Section 3.1.2 should be rephrased as > >>>>> > >>>>> "This section generalizes the processing rules described > >>>> in [RFC4872] > >>>>> and [RFC4873], and which is reviewed in [RFC6689], for > >>>> application > >>>>> to MPLS LSPs and non-LSP session state. For GMPLS > LSP rules are > >>>>> extended for applications not related to the recovery > >>>> and resource > >>>>> sharing." > >>>> > >>>> I've revised the text to read: > >>>> > >>>> This section is based on, and extends, the processing rules > >>>> described in [RFC4872] and [RFC4873], and which is > reviewed in > >>>> [RFC6689]. This section applies equally to GMPLS > >> LSPs, MPLS LSPs > >>>> and non-LSP session state. Note, as previously stated, this > >>>> section does not modify processing required to support > >> [RFC4872] > >>>> and [RFC4873]. > >>> > >>> OK. > >>> > >>>>>> 2) I also think "not compatible" is an overstatement, but > >>>> I guess that > >>>>>> it isn't really a critical point to discuss as the > >> referenced text > >>>>>> doesn't relate to [RFC4872] and [RFC4873]. > >>>>> > >>>>> The proposed phrasing would resolve it. > >>>>> > >>>>>>>> and in RFC 4873/Section 3.2 "The > >>>>>>>> ASSOCIATION object is used to associate different LSPs > >>>>>> with each other." > >>>>>> > >>>>>> I see no text change requested based on this comment. > >>>>> > >>>>> Ditto. > >>>>> > >>>>>>>> - Section 3.1.2 "An association is deemed to exist when > >>>>>> the same values are > >>>>>>>> carried in all fields of the ASSOCIATION objects being > >>>>>> compared." this > >>>>>>> introduces > >>>>>>>> an additional level of indirection. To associate A to B A > >>>>>> can simply refer to > >>>>>>> an > >>>>>>>> identifier of B (and vice versa), A doesn't need to have > >>>>>> an additional ID > >>>>>>> (e.g. C) > >>>>>>>> that is also associated to B. Generalization would consist > >>>>>> here in introducing > >>>>>>> an > >>>>>>>> ext.association ID common to A, B, and C. In other terms, > >>>>>> generalizing the > >>>>>>> notion > >>>>>>>> of association doesn't require the introduction of an > >>>>>> additional level of > >>>>>>>> indirection. > >>>>>> > >>>>>> I really have no idea what this comment means. There is no > >>>>>> indirection stated or implied by the text. > >>>>> > >>>>> It is the result of what the text implies and it is specifically > >>>>> related to the "Association ID". Implicitly the > document mandates > >>>>> than this identifier can't take any value of existing fields > >>>>> identifying tunnels/LSPs. > >>>> > >>>> Not at all. As long as the IDs as consistently set across > >> association > >>>> objects, an association will be made. Furthermore, type specific > >>>> processing can be defined that allows implicit mapping > such as you > >>>> defined in 4872. > >>> > >>> The first item to check is the Association Type to distinguish > >>> between matching processes. The statement "In the absence of > >>> Association Type-specific rules for identifying > association,.." was > >>> probably intended to state (to remove the confusion of > the statement > >>> "identifying assocation"): > >>> > >>> "If the ASSOCIATION type does not refer to Association > Type-specific > >>> rules for the processing of the ASSOCIATION object (in > >> which case the > >>> Association Type-specific rules SHALL be applied), ..." > >> > >> IMO this should be left to the definition of the Association > >> Type-specific rules, i.e., is beyond the scope of this document. > > > > OK. > > > >>>>>> It means test for simple equivalence, > >>>>>> i.e., (ASSOCIATION object of A) =3D (ASSOCIATION object of > >>>> B) and that's > >>>>>> it. There's no (session) ID referencing. Can you restate > >>>>>> your concern? > >>>>> > >>>>> My concern is this an equivalence between objects not an > >>>> assocation of sessions. > >>>>> > >>>> > >>>> Per this document, equivalence between objects identifies an > >>>> assocation > >>>> of sessions. This document does not generalize the session ID to > >>>> association ID matching that was part of 4872. > >>> > >>> The above text would clarify the point. > >> > >> The following has been added to the second to last paragraph > >> of Section 1. > >> > >> When using the procedures defined below, association > is identified > >> based on simple ASSOCIATION object matching. Some of the other > >> matching mechanisms defined in RFC 4872, e.g., > matching based on > >> Session IDs, are not generalized. > > > > I would write: > > > > When using the procedures defined in this document, > association is identified > > based on ASSOCIATION object matching. Some of the other > > matching mechanisms defined in RFC 4872, e.g., > matching based on > > Session IDs, are not generalized in this document. Association > > type-specific processing is outside the scope of this > document. > > > > understood, I'll modify the paragraph. (subject to style differences.) > > >>>>>>>> - Section 3.2.2 I understand triggers for Resv-initiated > >>>>>> associations aren't > >>>>>>>> documented but how to prevent a sender willing to demote > >>>>>> receiver-driven > >>>>>>>> associations ? > >>>>>> > >>>>>> Can you clarify this question? > >>>>> > >>>>> Let me put first in context. Generalization includes Rcv driven > >>>>> associations but only additions are documented. > >>>>> > >>>>>> Are you asking: > >>>>>> - how a Path sender can prevent a receiver initiated > >>>> association? (it > >>>>>> can't) > >>>>>> > >>>>>> - how a Resv sender removes an association? (it just removes > >>>>>> the object, no different from a path message) > >>>>> > >>>>> The corresponding processing is to be documented. > Because one can > >>>>> also demote an association by having each LSP/session > pointing to > >>>>> itself while keeping the object in the Path/Resv message. > >>>> > >>>> This sounds like the implicit matching rules in 4872. > >> Such session ID > >>>> to association ID matching is not part of this document. > >>> > >>> I hear you but as the ASSOCIATION ID value setting > doesn't state it > >>> can't be done, you can get the same result. > >> > >> Sure, and this would be perfectly fine way for an implementation to > >> select its IDs for certain possible applications, but this > is a local > >> implementation choice in the general case, or > type-specific processing > >> which is outside the scope of this document. > > > > OK. > > > >>> You could even assume that changing ID to an unused but > value would > >>> lead to the same result (as matching wouldn't give a > positive result > >>> the ASSOCIATION would also be removed since it can't be found > >>> anymore). > >> > >> > >>> > >>>>>> - something else? > >>>>>> > >>>>>>>> - Section 3.1.2 and 3.2.2 no error processing is being > >> documented > >>>>>> > >>>>>> I think this is a fair point. The only case I think that > >>>>>> can/should be > >>>>>> addressed is unknown types. (As is usual, per > RFC2205, errors in > >>>>>> formats to not trigger any specific message response.) > >>>>>> Sections 3.1 and > >>>>>> 3.2 only discuss identification of associations, so I > >>>> propose adding a > >>>>>> section 3.3.2. How about something like: > >>>>>> > >>>>>> 3.3.2. Unknown Association Types > >>>>>> > >>>>>> A node that receives an ASSOCIATION object with an unknown > >>>>>> ASSOCIATION type MUST forward all received > ASSOCIATION objects > >>>>>> as defined above. The node MAY also identify > associations per > >>>>>> the defined processing, e.g., to make this information > >> available > >>>>>> via a management interface. > >>>>> > >>>>> OK. Wouldn't you document PathErr/ResvErr and Notify ? > >>>> > >>>> IMO Not for an unknown type. > >>> > >>> I don't understand the answer. > >> > >> I don't think unknown type should result in a PathErr/ResvErr at a > >> transit/egress/ingress node. > > > > The question why do you use "unknown" type and not > > > > Error Code =3D 01: "Admission Control Failure" (see [RFC2205]) > > > > o "Admission Control Failure/Session Admission Failure" (6) > > Because I don't think lack of support of a type should result in an > error in the general case. (for example would you generate an error on > transit nodes for associations that are only relevant to > end-points, or vice versa?) How would you then allow that session to cross the network ? Thus it depend= s on policy on what operator wants to apply at ingress (not up to the proto= col to decide/enforce a policy). > >>>>>>>> whereas mis- > >>>>>>>> match in association should be considered as a generic error. > >>>>>> > >>>>>> This isn't a detectable error case as it is impossible for > >>>> a node to > >>>>>> know if two association objects are intentionally or > >>>> unintentionally > >>>>>> different. > >>>>> > >>>>> Earlier, in the text it is mentioned that processing > >>>> implies checking > >>>>> all Path/Resv state. We have to understand that putting > in place a > >>>>> generic processing (outside a specific ASSOCIATION Type) renders > >>>> > >>>> I think this sentence got truncated... > >>> > >>> ... safeguard rule advisable. > >>> > >>>>>>>> - Section 3.3 states "Since the admission control function > >>>>>> is outside the > >>>>>>> scope of > >>>>>>>> RSVP,..." are you sure ? > >>>>>> > >>>>>> Yes. Per RFC2205: > >>>>> > >>>>> Yes I know the figuere whose terms mixes functions, protocol > >>>>> processes, etc. but this goes beyond the review of this > >> document ;-) > >>>> > > [snip figure] > >>>>>> an RSVP QoS request is passed to two local > >>>>>> decision modules, "admission control" and "policy control". > >>>>>> > >>>>>>>> admission control is an intrinsic function associated > >>>>>>> to RFC > >>>>>>>> 2205 (there are errors documented for admission control > >>>>>> failures). I think you > >>>>>>>> mean that the inner working of the mechanisms used by > >>>>>> nodes to determine if > >>>>>>>> they have sufficient available resources to support > >>>>>> incoming requests. > >>>>>> > >>>>>> I think this is the same as what is stated. > >>>>> > >>>>> What you mean is: the inner-working or implementation > of admission > >>>>> control for QoS requests is outside scope of RFC 2205. > >>>>> > >>>>>> we can add "implementation specifics ", i.e., " Since the > >>>>>> implementation > >>>>>> specifics of the admission control function is outside the > >>>>>> scope " if it helps. > >>>>> > >>>>> Yes it does because the term "outside scope" has different > >>>> meanings depending on context. > >>>>> > >>>> > >>>> done. > >>>> > >>>>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION > >>>>>> object and the IPv6 > >>>>>>>> ASSOCIATION object. As defined, these objects each contain > >>>>>> an Association > >>>>>>>> Source field and a 16-bit Association ID field. The > >>>>>> combination of the > >>>>>>> Association > >>>>>>>> Source and the Association ID uniquely identifies the > >>>>>> association." but in the > >>>>>>>> context RFC 4872 this association is defined in the > >>>>>> context of the same tunnel > >>>>>>>> end-point > >>>>>> > >>>>>> How about we clarify: "*As described above,* the > >>>>>> combination of the Association Source and the Association ID > >>>>>> uniquely identifies the association." > >>>>> > >>>>> It would be better to state > >>>>> > >>>>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > >>>>> ASSOCIATION object in the context of a given session. > As defined, > >>>>> these objects each contain an Association Source field > >> and a 16-bit > >>>>> Association ID field. The combination of the Association > >> Source and > >>>>> the Association ID uniquely identifies the association. > >> This doesn't > >>>>> prevent that Association Types MAY further specify the > context for > >>>>> which this association is defined." > >>>> > >>>> It now reads: > >>>> > >>>> [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > >>>> ASSOCIATION object. As defined, these objects each > contain an > >>>> Association Source field and a 16-bit Association ID > field. As > >>>> described above, the contents of the object uniquely > identifies > >>>> an association. Because the Association ID field is a 16-bit > >>>> field, an association source can allocate up to > 65536 different > >>>> associations and no more. > >>> > >>> OK > >>> > >>>>>>> (and actually the same for RFC 4873 which relies on MBB > >> as defined > >>>>>>> in > >>>>>>>> RFC 3209) > >>>>>> > >>>>>> I don't believe this statement is correct, but again this > >>>> is really a > >>>>>> discussion beyond this draft. > >>>>> > >>>>> The statement here above is also to applicable to RFC 4873. > >>>>> > >>>>>>>> - Section 4: How is the following use case "There are > >>>>>> scenarios where this > >>>>>>> number > >>>>>>>> is insufficient. (For example where the association > >>>>>> identification is best > >>>>>>> known > >>>>>>>> and identified by a fairly centralized entity, which > >>>>>> therefore may be involved > >>>>>>> in a > >>>>>>>> large number of associations.)" related to those proposed > >>>>>> in the introduction. > >>>>>>> ? > >>>>>> > >>>>>> As I read it, it enables practical third party (e.g., > >>>>>> management entity) > >>>>>> creation and management of association IDs. But, I'll > >> defer to my > >>>>>> coauthors on this. > >>>>> > >>>>> OK. Please let me know the result(s) of the discussion. > >>>>> > >>>>>>>> - Section 4: I don't question the requirement stated in > >>>>>> "Per [RFC6370], > >>>>>>> MPLS-TP > >>>>>>>> LSPs can be identified based on an operator unique global > >>>>>> identifier. The > >>>>>>>> [RFC6370] defined "global identifier", or Global_ID, is > >>>>>> based on [RFC5003] and > >>>>>>>> includes the operator's Autonomous System Number (ASN)." > >>>>>> the question is why > >>>>>>>> the information is best encoded as part of the ASSOCIATION > >>>>>> object ? isn't this > >>>>>>> an > >>>>>>>> LSP ATTRIBUTE or a Session Name ? > >>>>>> > >>>>>> It's the solution the WG agreed to. Other options are of > >>>>>> course possible. > >>>>> > >>>>> My comment is specific because it triggers the question > >> on how many > >>>>> objects will we end up in spreading identification > information (it > >>>>> would be interesting to document the why this was felt the most > >>>>> suited object as it is not a natural choice); more general > >>>> comment is > >>>>> what defines the "acceptable" use/extension of association. > >>>> > >>>> I think the last comment is a reasonable discussion to > >> have. Not sure > >>>> it belongs in, or gates the discussion. > >>> > >>> The LSP attributes RFC included this info for instance. This has > >>> prevented lots of problems in use of the object because > the content > >>> of most objects could have been added to the LSP > attribute RFC (cf. > >>> Sect.8 "8. Summary of Attribute Bit Allocation" and Sect.10 > >>> "Guidance for Key Application Scenarios"). > >> > >> Do you have some suggestions/text in mind? > > > > I will propose a Section for this. Can be done as part of > this e-mail. Can you put a placeholder in the document. Putting the full text would make= this thread unreadable. > >>>>>>>> - Section 4.2: states "It is important to note that > >>>>>> Section 4 defines > >>>>>>> association > >>>>>>>> identification based on ASSOCIATION object matching, and > >>>>>> that such matching > >>>>>>> is > >>>>>>>> based on the comparison of all fields in a ASSOCIATION > >>>>>> object (unless type- > >>>>>>>> specific comparison rules are defined). This applies > >>>>>> equally to ASSOCIATION > >>>>>>>> objects and Extended ASSOCIATION objects." any association > >>>>>> is based on a form > >>>>>>>> of matching, point here is that the matching and the > >>>>>> identification of the > >>>>>>> initiation > >>>>>>>> of the matching information are distinct information > >>>>>> entities (difference > >>>>>>> between > >>>>>>>> WHO and WHAT). I suggest to make a clearer distinction and > >>>>>> specify setting and > >>>>>>>> processing accordingly. > >>>>>> > >>>>>> I'm not seeing the issue. Can you perhaps propose some text? > >>>>> > >>>>> Here is the proposed text > >>>>> > >>>>> "It is important to note that Section 4 defines association > >>>>> identification based on ASSOCIATION object matching, and > >>>>> that such matching is based on the comparison of the fields > >>>>> as determined by the ASSOCIATION Type of the ASSOCIATION > >>>>> object. This applies equally to ASSOCIATION objects and > >>>>> Extended ASSOCIATION objects." > >>>> > >>>> Here's the revised text. > >>>> Identification of association is not modified by this > >> section. It > >>>> is important to note that Section 4 defines association > >>>> identification based on ASSOCIATION object matching, > >> and that such > >>>> matching, in the absence of type-specific comparison > rules, is > >>>> based on the comparison of all fields in an > ASSOCIATION object. > >>>> This applies equally to ASSOCIATION objects and Extended > >>>> ASSOCIATION objects. > >>> > >>> I would write (look at the text just above where you state "As > >>> defined, these objects each contain an Association Source > >> field and a > >>> 16-bit Association ID field. As described above, the > >> contents of the > >>> object uniquely identifies an association." ... there is a need to > >>> distinguish between identifying the ASSOCIATION object vs matching > >>> ASSOCIATION objects). > >> > >> sure. But you need to be sure you're noting the difference > between the > >> word "association" and the thing "ASSOCIATION object". > > > > I am. > > > >>> This would > >>> > >>> "The procedure to perform ASSOCIATION object matching as > defined in > >>> Section 4 is not modified by this section. It is important to note > >>> that Section 4 defines ASSOCIATION object matching if the > >> ASSOCIATION > >>> type does not refer to Association Type-specific rules for the > >>> processing of the ASSOCIATION object (in which case the > Association > >>> Type-specific rules SHALL be applied); otherwise, > ASSOCIATION object > >>> matching applies by comparing all fields in an ASSOCIATION object. > >>> This procedure applies equally to ASSOCIATION objects and Extended > >>> ASSOCIATION objects." > >> > >> one more time, revised text now reads: > >> The procedures related to association identification are not > >> modified by this section. It is important to note > that Section 4 > >> defines the identification of associations based on ASSOCIATION > >> object matching and that such matching, in the absence of > >> type-specific comparison rules, is based on the > comparison of all > >> fields in an ASSOCIATION object. This applies equally to > >> ASSOCIATION objects and Extended ASSOCIATION objects. > > > > I would state "in the absence of type-specific comparison rules (for > > the Type value of the object being processed), is based on the > > comparison of all fields in an ASSOCIATION object." > > > > because absence of rules is a generic statement. > > Again, I don't see the difference in meaning -- I think we're in the > domain of style here. The problem with your statement is: there is no (absence) type-specific rul= e then apply full matching Mine it is either the one or the other. > >>>>>>>> - Section 4.2: shouldn't "error processing" being > documented ? > >>>>>> > >>>>>> Here too, I think the only error processing is as > >> discussed above. > >>>>>> Shout if you think otherwise. > >>>>>> > >>>>>>>> Example include > >>>>>>>> admission control where receiving node rejects the > >>>>>> incoming Path msg if the > >>>>>>>> originating Global_ID/Ext.ASSOCIATION object isn't included, > >>>>>> > >>>>>> Interesting, but this is a type specific error. To me this > >>>>>> sounds like > >>>>>> a new admission control error that should be defined as > >> part of the > >>>>>> type-specific definition. > >>>>> > >>>>> Admission control failures are part of the error codes > >>>> defined in RFC 2205. > >>>> > >>>> exactly! > >>>> > >>>>>>>> unauthorized > >>>>>>>> Global ID ? > >>>>>> > >>>>>> Again interesting, but this is a new policy (and policy > >> error) that > >>>>>> wasn't proposed or discussed in the WG. I think this > >>>> would be a fine > >>>>>> addition, but is beyond the current document discussion. It > >>>>>> could always be added if proposed. > >>>>> > >>>>> I defer this point to the AD. > >>>> > >>>> WFM. > >>>> > >>>>> > >>>>>>>> etc. but also mismatches between Association source > and Global > >>>>>>>> Association source ? > >>>>>> > >>>>>> How would such a thing be detected, by checking BGP state? > >>>> I guess we > >>>>>> could add a new error code, but again I think we're going > >>>> beyond the > >>>>>> intent of the document/WG. > >>>>> > >>>>> Same here. > >>>>> > >>>>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370] > >>>>>> defined global > >>>>>>> identifier, > >>>>>>>> or Global_ID, is based on [RFC5003] and includes the > >>>>>> operator's Autonomous > >>>>>>>> System Number (ASN)." while the latter "the use of the > >>>>>> Global_ID is not > >>>>>>> related > >>>>>>>> to the use of the ASN in protocols such as BGP." which one > >>>>>> applies ? > >>>>>> > >>>>>> I'll drop the note. This is better aligned with the field > >>>> definition > >>>>>> which has been updated based on comments of other reviewers. > >>>>>> > >>>>>> The current definition is: > >>>>>> > >>>>>> This field contains a value that is a unique global > >>>> identifier or > >>>>>> the special value zero (0). When non-zero and not > >>>> overridden by > >>>>>> local policy, the Global_ID as defined in [RFC6370] > >>>> SHALL be used. > >>>>>> The special value of zero indicates that no global > >>>> identifier is > >>>>>> present. Use of the special value of zero SHOULD be > >> limited to > >>>>>> entities contained within a single operator. > >>>>> > >>>>> OK > >>>>> > >>>>>>>> - Section 5 Documenting means to prevent/mitigate > >>>>>> mis-association(s) and > >>>>>>>> possible impact on security would be advisable. If this is > >>>>>> felt to be > >>>>>>> "application" or > >>>>>>>> "type" specific a recommendation should be stated that the > >>>>>> security mechanisms > >>>>>>>> have to be documented as part of these documents. > >>>>>> > >>>>>> Why is there any additional risk than what " was > >>>> previously defined in > >>>>>> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) > >>>>> > >>>>> I try to prevent that any further use/documents would state "no > >>>>> additional risk compared to RFC 4872 and RFC 4873" or > >> equivalent but > >>>>> the application is running for voice calls over the > >>>> Internet which is > >>>>> a totally different application than G/MPLS Recovery/Resource > >>>>> Sharing. > >>>> > >>>> Fair enough, but what additional issues do you foresee > >> that should be > >>>> covered? > >>> > >>> Nodes associating sessions, etc. should have the mean to > verify the > >> initiator of the association. > >> > >> This is true for every object in RSVP! I have no > objection to object > >> signing, ala SIDR, but this is well beyond the scope of > this document > >> and certainly isn't introduced in this document. > > > > We have to bring this point the Security directorate and > ask them for > > guidance (there could be a short term and a long term approach). I > > understand the corresponding generic mechanism to perform such > > verification isn't to be documented here but it has to be mentioned. > > We loose track of all these security holes... hackers don't. > > RSVP's chain of trust is called out in RFC5920, which is reference by > this draft. I certainly have no issue with a general discussion on > RSVP's chain of trust model, but the scope of this conversation is > beyond (and should be scoped) to this draft. Can you point which section of that RFC you are referring to that would hel= p the reader. I am asking because I didn't find any that speaks about ASSOCIATION object. > Thanks, > Lou > > > > > OK for the rest. We are nearly done. > > > > Thanks, > > -dimitri. > >>>>>>>> Editorials: > >>>>>>>> > >>>>>>>> - Introduction: "This document expands the possible usage > >>>>>> of the ASSOCIATION > >>>>>>>> object to > >>>>>>>> non-GMPLS and non-recovery contexts." Suggested to state > >>>>>> the actual the > >>>>>>>> scope includes RSVP (instead of what it is not) > >>>>>> > >>>>>> I'll add: > >>>>>> The expanded usage applies equally to GMPLS LSPs > >> [RFC3473], MPLS > >>>>>> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], > [RFC2207], > >>>>>> [RFC3175] and [RFC4860]. > >>>>> > >>>>> OK. > >>>>> > >>>>>>>> - Introduction: s/different ports/different destination > >>>> (dst) ports > >>>>>>>> > >>>>>> > >>>>>> sure. > >>>>>> > >>>>>>>> - Section 2 would better refer to a "Generalization" > >>>> rather than a > >>>>>>> "modification" > >>>>>>>> > >>>>>> > >>>>>> I'd be okay with this, but I think modification makes is less > >>>>>> likely to be misinterpreted so will leave as is. > >>>>> > >>>>> The term modification implies a change in existing > >> processing (even > >>>>> if the intention is different) and actually as the > >> applicability is > >>>>> now possible to RSVP and MPLS-TE. > >>>> > >>>> This isn't a major point for me, so will change it. (In > 5 places.) > >>> > >>> OK (actually the doc. generalizes the use of the object > whereas 4873 > >> for inst documents type-specific/specialized use of the object) > >>> > >>>>>>>> - Section 3 states "As defined by [RFC4872] and reviewed > >>>>>> in [RFC6689],..." but > >>>>>>> an > >>>>>>>> information RFC doesn't review at best "documents" > >>>>>> certain usage. This > >>>>>>>> statement is repeated at multiple places. > >>>>>> > >>>>>> Why can't it review? This is what the abstract of RFC6689 > >>>>>> says it does. > >>>>> > >>>>> It was overstated in RFC 6689. > >>>> > >>>> This document doesn't change 6689. > >>> > >>> OK. > >>> > >>>>>>>> - Section 3 mentions "Object usage in both Path and Resv > >>>>>> messages is > >>>>>>> discussed. > >>>>>>>> The usage applies equally to > >>>>>>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP > >>>>>> RSVP sessions > >>>>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having > >>>>>> such statement in the > >>>>>>>> introduction would desirable. > >>>>>> > >>>>>> Fair enough. > >>>>>> > >>>>>> Thank you for the review! > >>>>> > >>>>> OK. > >>>>> > >>>>> Thanks, > >>>>> -d. > >>>> > >>>> Thanks, > >>>> Lou > >>> > >>> Thanks, > >>> -d. > >> > >> Thanks again. > >> > >> Lou > >> > >> PS I'll submit a revised version of the draft at some > point today to > >> document all changes to date. > >> > >> > > > > > > > > > From lberger@labn.net Wed Sep 5 14:31:24 2012 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 EEF2C21F86F6 for ; Wed, 5 Sep 2012 14:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.472 X-Spam-Level: X-Spam-Status: No, score=-99.472 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, 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 SQinAh9c+L6y for ; Wed, 5 Sep 2012 14:31:22 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 7354021F86EB for ; Wed, 5 Sep 2012 14:31:22 -0700 (PDT) Received: (qmail 3875 invoked by uid 0); 5 Sep 2012 21:31:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 5 Sep 2012 21:31:20 -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=dQtwz88q6O73eH7n0gj2YcbuJHN37WId7LIzkH/Lstc=; b=V5j7jrMvMXIeJoNiWrpUn8RnyZei6m/TyT/QOw55Rgk49wXsjhLj1Mza06UiIDzldd7ri2JbkD0/EPUY7p01TKdyIn3QY6HkPeluYQAJW4FwzU/IkV/xKeKDRfcGdt5l; Received: from box313.bluehost.com ([69.89.31.113]:59210 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T9NBv-0004C4-M9; Wed, 05 Sep 2012 15:31:20 -0600 Message-ID: <5047C4AB.10907@labn.net> Date: Wed, 05 Sep 2012 17:31:23 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Papadimitriou, Dimitri (Dimitri)" References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> <50474748.1030303@labn.net> <504788AC.3090802@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.4 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: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 21:31:25 -0000 See below. On 9/5/2012 4:50 PM, Papadimitriou, Dimitri (Dimitri) wrote: > > Lou, > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, September 05, 2012 19:15 >> To: Papadimitriou, Dimitri (Dimitri) >> Cc: adrian@olddog.co.uk; >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >> >> Dimitri (BTW sorry about the dropping the t in my last message) >> >> See below. >> >> On 9/5/2012 12:08 PM, Papadimitriou, Dimitri (Dimitri) wrote: >>> Hi Lou, >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, September 05, 2012 14:36 >>>> To: Papadimitriou, Dimitri (Dimitri) >>>> Cc: adrian@olddog.co.uk; >>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org >>>> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 >>>> >>>> Hi Dimiri, >>>> Responses in line... >>>> >>>> On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:> Lou, >>>>> >>>>> see below, >>>>> >>>>>> -----Original Message----- >>>>>> From: rtg-dir-bounces@ietf.org >>>>>> [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger >>>>>> Sent: Tuesday, September 04, 2012 23:54 >>>>>> To: Papadimitriou, Dimitri (Dimitri) >>>>>> Cc: adrian@olddog.co.uk; >>>>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org >>>>>> Subject: Re: [RTG-DIR] FW: Review of >> draft-ietf-ccamp-assoc-ext-04 >>>>>> >>>>>> Dimitri, >>>>>> See below. >>>>>> >>>>>> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: >>>>>>> Hi Lou, >>>>>>> >>>>>>> See inline: >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>> Sent: Tuesday, September 04, 2012 17:25 >>>>>>>> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) >>>>>>>> Cc: rtg-dir@ietf.org; >>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org >>>>>>>> Subject: Re: [RTG-DIR] FW: Review of >>>> draft-ietf-ccamp-assoc-ext-04 >>>>>>>> >>>>>>>> Adrian, >>>>>>>> Much Thanks. (BTW is there a reason not to include the >>>>>>>> WG in this, or >>>>>>>> such, discussions?) >>>>>>>> >>>>>>>> Dimitri, >>>>>>>> Please see below for inline responses. >>>>>>>> >>>>>>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote: >>>>>>>>> Here is Dimitri's Routing Dir review. Many thanks for >>>> the review. >>>>>>>>> >>>>>>>>> Lou, you can address this and the other comments and post a >>>>>>>> new revision. >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Papadimitriou, Dimitri (Dimitri) >>>>>>>> [mailto:dimitri.papadimitriou@alcatel- >>>>>>>>>> lucent.com] >>>>>>>>>> Sent: 31 August 2012 13:23 >>>>>>>>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; >>>> sbryant@cisco.com; >>>>>>>>>> huawei.danli@huawei.com >>>>>>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Here below the review of this document. >>>>>>>>>> >>>>>>>>>> Technical comments: >>>>>>>>>> >>>>>>>>>> - Example 3: isn't this extension also not updating >> RFC 2205 ? >>>>>>>> >>>>>>>> Yes. This is stated in the header, abstract and section 3. >>>>>>> >>>>>>> I thought to include this in the introduction since other >>>>>> updated RFC are indicated. >>>>>>> >>>>>> >>>>>> Agreed. Text has been added. >>>>> >>>>> OK. >>>>> >>>>>>>>>> - The statement "In order to support the more general >>>>>> usage of the >>>>>>>>>> ASSOCIATION object," is actually not correct RFC 4872 >>>>>>>> doesn't prevent support >>>>>>>>> of >>>>>>>>>> other usage of the ASSOCIATION object. It has just >>>>>>>> documented its usage in the >>>>>>>>>> GMPLS recovery context. >>>>>>>> >>>>>>>> I'm not sure how these two statements (the document text >>>>>> and your last >>>>>>>> sentence) are mutually inconsistent. I see no text change >>>>>>>> based on this comment. >>>>>>> >>>>>>> I meant: "In order to document the more general usage of >>>>>> the ASSOCIATION object, ..." >>>>>>> >>>>>> >>>>>> While I don't mind the change in this part of the sentience, >>>>>> the result >>>>>> is a bit odd "In order to document the more general usage of the >>>>>> ASSOCIATION object, this document ..." So will leave as is. >>>>> >>>>> "In order to document the more general usage of the ASSOCIATION >>>> object, this specification ..." >>>> >>>> I think we're in the noise here... >>>> >>>>>>>>>> - Section 3.1, "Cross-session association based on Path >>>>>>>> state is defined in >>>>>>>>>> [RFC4872]." the latter defines cross-LSP association >>>>>>>> within the same session >>>>>>>>> (not >>>>>>>>>> cross-session association) but nothing prevents extending >>>>>>>> usage to cross- >>>>>>>>>> Session. >>>>>>>>>> >>>>>>>> >>>>>>>> I see no text change requested based on this comment. >>>>>>> >>>>>>> I meant: "Cross-LSP association based on Path state is >> defined in >>>>>>> [RFC4872]; here we document cross-session association..." >>>>>> >>>>>> I'll change two instances of "Cross-session association" >>>> to "Cross-LSP >>>>>> association". >>>>> >>>>> OK. >>>>> >>>>>>>>>> - Section 3.1.2 the statement "the definition SHOULD allow >>>>>>>> for association >>>>>>>>> based >>>>>>>>>> on identical ASSOCIATION objects" is not clear, does it >>>>>>>> that the information >>>>>>>>>> elements part of the object shall be identical ? >>>>>>>> >>>>>>>> I see no difference between the current text (object >>>>>> equivalence) and >>>>>>>> object information element equivalence. I don't believe >>>>>>>> there's a case >>>>>>>> where you can have one without the other. Please >>>> correct me if you >>>>>>>> think I'm mistaken. >>>>>>> >>>>>>> If the association ID are defined such that: >>>>>>> >>>>>>> - the Association ID of Session 1 or LSP 1 points to the >>>>>> Session ID or LSP ID of LSP 2 >>>>>>> >>>>>>> - the Association ID of Session 2 or LSP 2 points to the >>>>>> Session ID or LSP ID of LSP 1 >>>>>> >>>>>> Association based on matching Association ID to Session ID >>>> is not part >>>>>> of this draft. >>>>> >>>>> if the session ID isn't used - which is possible - >>>> documenting the ID >>>>> setting to ensure unicity (per association) is to be >> documented the >>>>> definition only states concerning value setting >>>>> >>>>> "A value assigned by the the node that originated the association. >>>>> When combined with the other fields carried in the >>>> object, this >>>>> value uniquely identifies an association." >>>> >>>> Actually, the document provides additional guidance in the >> procedures >>>> section: >>>> >>>> The Association ID field MUST be set to a value that uniquely >>>> identifies the sessions to be associated within the >> context of the >>>> Association Source field. The Association Source field MUST be >>>> set to a unique address assigned to the node originating the >>>> association. >>> >>> The initial statement should be part of the definition in the form >>> >>> "The Association ID value space is unique per ?" I write >> "?" because is it per node, per RSVP process, per Association source ? > > > what about the above one concerning the unicity ? unique as scoped by the Association Source field. As stated: When combined with the other fields carried in the object, this value uniquely identifies an association. and The Association ID field MUST be set to a value that uniquely identifies the sessions to be associated within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node originating the association. I think this is sufficiently unambiguous to ensure interoperable implementations. > > >>> The processing should in my opinion state (or equivalent): >>> >>> "The Association ID field MUST be set to a unique value >> that uniquely >>> identifies the association between sessions that are >> associated within >>> the context of the Association Source field." >> >> I frankly don't see any difference in the wording. > > > "uniquely identify the sessions to be associated" > > vs > > "uniquely identify the association" > > is clearly different. The association of what? --> Sessions. So I'm at a loss to see the difference. In the interest of moving forward I'll use "association being identified" (in 3 places.) > > >>>>>>> Other elements aren't necessarily identical. >>>>>> >>>>>> They must be identical in the context of this draft and >>>> the absence of >>>>>> type-specific processing rules. >>>>>> >>>>>>> The setting of the association source is application type >>>> specific. >>>>>> >>>>>> Even if true, I don't see how this impacts the text of the draft. >>>>> >>>>> Because a full match (incl.association source) wouldn't apply >>>>> anymore. I think the point goes to the question does extension >>>>> include association between sessions that uses two >> different source >>>>> addresses that can be two interface address ? >>>> >>>> sure. As documented, there is no mention of other fields >> to check as >>>> part of association identification. >>> >>> I don't get it. If the matching operation implies that all fields >>> shall be identical including the association source how do you >>> proceed ? >> >> Simple. If the objects are identical, there's an association >> identified. If not, there's no association. > > > This is not the question. If the association are set per source > interface how this mechanism shall be used ? Huh, where is this stated or even implied in the document. It only says: The Association Source field MUST be set to a unique address assigned to the node originating the association. This can be any address associated with any node. E.g., a loop back or even management station address. > The point I am raising > here is this precluded by design and it is a common case which likely > to happen with the examples you have highlighted in the > introduction. You're right. If the implementation uses different association sources to try to identify a single association it won't work. But this is just a broken implementation. The document already repeats the concept of using the same address / object contents in so many places I don't think it needs to be stated yet again. I'll submit the changes we have so far, and if you still think there's a need for a text change, please propose it as I'm at a loss. > > >>>>>>> Another case (if I am correctly understanding the related >>>> text), is >>>>>>> related to the MPLS-TP section. The association object of two >>>>>>> non-associated session can have the value fields in the >>>>>>> ext.association object. >>>>>> >>>>>> This is a true statement, but unless the contents of the >>>> whole object >>>>>> are identical, there's no association. >>>>> >>>>> In GMPLS you will have association source setting being >>>> identical for >>>>> many tunnels/LSPs (many controllers will set their local >> IP address >>>>> as source) while actually these LSPs aren't. I don't >> think there is >>>>> any indication that prevents this to happen ? >>>> >>>> Correct and this is intentional. All that is required for >>>> association is >>>> a simple match of objects. If two nodes use the same >> source address >>>> without coordinating IDs there may be collisions, but there's >>>> no way to >>>> know if this is intentional or an error when processing >> the path/resv >>>> messages. >>> >>> OK. As such this corroborates my initial remark where the >> association >>> object was actually the most suited place to put this information. >> >> Great. (I think.) > > > I meant was *not* (sorry for the confusion). > > >>>>>>>>>> - Section 3.1.2 "The Association ID field MUST be set to a >>>>>>>> value that uniquely >>>>>>>>>> identifies the sessions to be associated within the >>>>>>>> context of the Association >>>>>>>>>> Source field." >>>>>>>>>> this statement is not compatible with e.g. RFC 4873 and >>>>>>>> 4872 where >>>>>>>>> Association >>>>>>>>>> ID are set to LSP ID and not sessions while it is >>>> stated in 3.1 " >>>>>>>> >>>>>>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" >>>>>>> >>>>>>> Yes and section 3.1.2 indicates "These procedures >>>>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >>>>>> session state." >>>>>>> >>>>>>> don't you think this induces confusion ? >>>>>> >>>>>> Perhaps, but this is why the 3.1 states: >>>>>> This section does not modify processing required to support >>>>>> [RFC4872] >>>>>> and [RFC4873]. I'll repeat the sentence at the start of 3.1.2. >>>>> >>>>> This being said the Code point for RFC 4873 isn't changed >> but points >>>>> to this document. Any reason since there is no processing change ? >>>> >>>> I assume you're referring to the Resource Sharing type. This >>>> is updated as the same type is now usable for non-recovery LSPs. >>> >>> OK. >>> >>>>>>>> so it does not impact to RFC 4873 and 4872 >>>>>> implementations. As stated >>>>>>>> in the draft and quoted by you: >>>>>>>> >>>>>>>>> This section >>>>>>>>> does not >>>>>>>>>> modify processing required to support [RFC4872] and >>>>>>>> [RFC4873], and which is >>>>>>>>>> reviewed in Section 3 of [RFC6689]. " >>>>>>> >>>>>>> The point I am raising is that Section 3.1 reads as there no >>>>>>> "additions" whereas once reaching Section 3.1.2 one >>>> understands that >>>>>>> the statement no modifications meant actually extensions. >>>>>>> >>>>>>> Section 3.1 states "This section does not modify processing >>>>>> required to >>>>>>> support [RFC4872] and [RFC4873], and which is reviewed >>>>>> in Section 3 >>>>>>> of [RFC6689]. " >>>>>>> >>>>>>> Section 3.1.2 states " These procedures >>>>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >>>>>> session state." >>>>>>> >>>>>>> Hence, >>>>>>> >>>>>>> Section 3.1.2 should be rephrased as >>>>>>> >>>>>>> "This section is based on the processing rules described >>>>>> in [RFC4872] >>>>>>> and [RFC4873], and which is reviewed in [RFC6689]. >>>>>> These procedures >>>>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP >>>>>> session state." >>>>>>> >>>>>>> Section 3.1.2 should be rephrased as >>>>>>> >>>>>>> "This section generalizes the processing rules described >>>>>> in [RFC4872] >>>>>>> and [RFC4873], and which is reviewed in [RFC6689], for >>>>>> application >>>>>>> to MPLS LSPs and non-LSP session state. For GMPLS >> LSP rules are >>>>>>> extended for applications not related to the recovery >>>>>> and resource >>>>>>> sharing." >>>>>> >>>>>> I've revised the text to read: >>>>>> >>>>>> This section is based on, and extends, the processing rules >>>>>> described in [RFC4872] and [RFC4873], and which is >> reviewed in >>>>>> [RFC6689]. This section applies equally to GMPLS >>>> LSPs, MPLS LSPs >>>>>> and non-LSP session state. Note, as previously stated, this >>>>>> section does not modify processing required to support >>>> [RFC4872] >>>>>> and [RFC4873]. >>>>> >>>>> OK. >>>>> >>>>>>>> 2) I also think "not compatible" is an overstatement, but >>>>>> I guess that >>>>>>>> it isn't really a critical point to discuss as the >>>> referenced text >>>>>>>> doesn't relate to [RFC4872] and [RFC4873]. >>>>>>> >>>>>>> The proposed phrasing would resolve it. >>>>>>> >>>>>>>>>> and in RFC 4873/Section 3.2 "The >>>>>>>>>> ASSOCIATION object is used to associate different LSPs >>>>>>>> with each other." >>>>>>>> >>>>>>>> I see no text change requested based on this comment. >>>>>>> >>>>>>> Ditto. >>>>>>> >>>>>>>>>> - Section 3.1.2 "An association is deemed to exist when >>>>>>>> the same values are >>>>>>>>>> carried in all fields of the ASSOCIATION objects being >>>>>>>> compared." this >>>>>>>>> introduces >>>>>>>>>> an additional level of indirection. To associate A to B A >>>>>>>> can simply refer to >>>>>>>>> an >>>>>>>>>> identifier of B (and vice versa), A doesn't need to have >>>>>>>> an additional ID >>>>>>>>> (e.g. C) >>>>>>>>>> that is also associated to B. Generalization would consist >>>>>>>> here in introducing >>>>>>>>> an >>>>>>>>>> ext.association ID common to A, B, and C. In other terms, >>>>>>>> generalizing the >>>>>>>>> notion >>>>>>>>>> of association doesn't require the introduction of an >>>>>>>> additional level of >>>>>>>>>> indirection. >>>>>>>> >>>>>>>> I really have no idea what this comment means. There is no >>>>>>>> indirection stated or implied by the text. >>>>>>> >>>>>>> It is the result of what the text implies and it is specifically >>>>>>> related to the "Association ID". Implicitly the >> document mandates >>>>>>> than this identifier can't take any value of existing fields >>>>>>> identifying tunnels/LSPs. >>>>>> >>>>>> Not at all. As long as the IDs as consistently set across >>>> association >>>>>> objects, an association will be made. Furthermore, type specific >>>>>> processing can be defined that allows implicit mapping >> such as you >>>>>> defined in 4872. >>>>> >>>>> The first item to check is the Association Type to distinguish >>>>> between matching processes. The statement "In the absence of >>>>> Association Type-specific rules for identifying >> association,.." was >>>>> probably intended to state (to remove the confusion of >> the statement >>>>> "identifying assocation"): >>>>> >>>>> "If the ASSOCIATION type does not refer to Association >> Type-specific >>>>> rules for the processing of the ASSOCIATION object (in >>>> which case the >>>>> Association Type-specific rules SHALL be applied), ..." >>>> >>>> IMO this should be left to the definition of the Association >>>> Type-specific rules, i.e., is beyond the scope of this document. >>> >>> OK. >>> >>>>>>>> It means test for simple equivalence, >>>>>>>> i.e., (ASSOCIATION object of A) = (ASSOCIATION object of >>>>>> B) and that's >>>>>>>> it. There's no (session) ID referencing. Can you restate >>>>>>>> your concern? >>>>>>> >>>>>>> My concern is this an equivalence between objects not an >>>>>> assocation of sessions. >>>>>>> >>>>>> >>>>>> Per this document, equivalence between objects identifies an >>>>>> assocation >>>>>> of sessions. This document does not generalize the session ID to >>>>>> association ID matching that was part of 4872. >>>>> >>>>> The above text would clarify the point. >>>> >>>> The following has been added to the second to last paragraph >>>> of Section 1. >>>> >>>> When using the procedures defined below, association >> is identified >>>> based on simple ASSOCIATION object matching. Some of the other >>>> matching mechanisms defined in RFC 4872, e.g., >> matching based on >>>> Session IDs, are not generalized. >>> >>> I would write: >>> >>> When using the procedures defined in this document, >> association is identified >>> based on ASSOCIATION object matching. Some of the other >>> matching mechanisms defined in RFC 4872, e.g., >> matching based on >>> Session IDs, are not generalized in this document. Association >>> type-specific processing is outside the scope of this >> document. >>> >> >> understood, I'll modify the paragraph. (subject to style differences.) >> >>>>>>>>>> - Section 3.2.2 I understand triggers for Resv-initiated >>>>>>>> associations aren't >>>>>>>>>> documented but how to prevent a sender willing to demote >>>>>>>> receiver-driven >>>>>>>>>> associations ? >>>>>>>> >>>>>>>> Can you clarify this question? >>>>>>> >>>>>>> Let me put first in context. Generalization includes Rcv driven >>>>>>> associations but only additions are documented. >>>>>>> >>>>>>>> Are you asking: >>>>>>>> - how a Path sender can prevent a receiver initiated >>>>>> association? (it >>>>>>>> can't) >>>>>>>> >>>>>>>> - how a Resv sender removes an association? (it just removes >>>>>>>> the object, no different from a path message) >>>>>>> >>>>>>> The corresponding processing is to be documented. >> Because one can >>>>>>> also demote an association by having each LSP/session >> pointing to >>>>>>> itself while keeping the object in the Path/Resv message. >>>>>> >>>>>> This sounds like the implicit matching rules in 4872. >>>> Such session ID >>>>>> to association ID matching is not part of this document. >>>>> >>>>> I hear you but as the ASSOCIATION ID value setting >> doesn't state it >>>>> can't be done, you can get the same result. >>>> >>>> Sure, and this would be perfectly fine way for an implementation to >>>> select its IDs for certain possible applications, but this >> is a local >>>> implementation choice in the general case, or >> type-specific processing >>>> which is outside the scope of this document. >>> >>> OK. >>> >>>>> You could even assume that changing ID to an unused but >> value would >>>>> lead to the same result (as matching wouldn't give a >> positive result >>>>> the ASSOCIATION would also be removed since it can't be found >>>>> anymore). >>>> >>>> >>>>> >>>>>>>> - something else? >>>>>>>> >>>>>>>>>> - Section 3.1.2 and 3.2.2 no error processing is being >>>> documented >>>>>>>> >>>>>>>> I think this is a fair point. The only case I think that >>>>>>>> can/should be >>>>>>>> addressed is unknown types. (As is usual, per >> RFC2205, errors in >>>>>>>> formats to not trigger any specific message response.) >>>>>>>> Sections 3.1 and >>>>>>>> 3.2 only discuss identification of associations, so I >>>>>> propose adding a >>>>>>>> section 3.3.2. How about something like: >>>>>>>> >>>>>>>> 3.3.2. Unknown Association Types >>>>>>>> >>>>>>>> A node that receives an ASSOCIATION object with an unknown >>>>>>>> ASSOCIATION type MUST forward all received >> ASSOCIATION objects >>>>>>>> as defined above. The node MAY also identify >> associations per >>>>>>>> the defined processing, e.g., to make this information >>>> available >>>>>>>> via a management interface. >>>>>>> >>>>>>> OK. Wouldn't you document PathErr/ResvErr and Notify ? >>>>>> >>>>>> IMO Not for an unknown type. >>>>> >>>>> I don't understand the answer. >>>> >>>> I don't think unknown type should result in a PathErr/ResvErr at a >>>> transit/egress/ingress node. >>> >>> The question why do you use "unknown" type and not >>> >>> Error Code = 01: "Admission Control Failure" (see [RFC2205]) >>> >>> o "Admission Control Failure/Session Admission Failure" (6) >> >> Because I don't think lack of support of a type should result in an >> error in the general case. (for example would you generate an error on >> transit nodes for associations that are only relevant to >> end-points, or vice versa?) > > > How would you then allow that session to cross the network ? Thus it > depends on policy on what operator wants to apply at ingress (not up > to the protocol to decide/enforce a policy). So what you're really asking for is a compatibility section that says how to deal with the case with inconsistent support of an association type. Well, sure we can add something. Now that said, it really should have been done along with the original object definition. > > >>>>>>>>>> whereas mis- >>>>>>>>>> match in association should be considered as a generic error. >>>>>>>> >>>>>>>> This isn't a detectable error case as it is impossible for >>>>>> a node to >>>>>>>> know if two association objects are intentionally or >>>>>> unintentionally >>>>>>>> different. >>>>>>> >>>>>>> Earlier, in the text it is mentioned that processing >>>>>> implies checking >>>>>>> all Path/Resv state. We have to understand that putting >> in place a >>>>>>> generic processing (outside a specific ASSOCIATION Type) renders >>>>>> >>>>>> I think this sentence got truncated... >>>>> >>>>> ... safeguard rule advisable. >>>>> >>>>>>>>>> - Section 3.3 states "Since the admission control function >>>>>>>> is outside the >>>>>>>>> scope of >>>>>>>>>> RSVP,..." are you sure ? >>>>>>>> >>>>>>>> Yes. Per RFC2205: >>>>>>> >>>>>>> Yes I know the figuere whose terms mixes functions, protocol >>>>>>> processes, etc. but this goes beyond the review of this >>>> document ;-) >>>>>> >>> [snip figure] >>>>>>>> an RSVP QoS request is passed to two local >>>>>>>> decision modules, "admission control" and "policy control". >>>>>>>> >>>>>>>>>> admission control is an intrinsic function associated >>>>>>>>> to RFC >>>>>>>>>> 2205 (there are errors documented for admission control >>>>>>>> failures). I think you >>>>>>>>>> mean that the inner working of the mechanisms used by >>>>>>>> nodes to determine if >>>>>>>>>> they have sufficient available resources to support >>>>>>>> incoming requests. >>>>>>>> >>>>>>>> I think this is the same as what is stated. >>>>>>> >>>>>>> What you mean is: the inner-working or implementation >> of admission >>>>>>> control for QoS requests is outside scope of RFC 2205. >>>>>>> >>>>>>>> we can add "implementation specifics ", i.e., " Since the >>>>>>>> implementation >>>>>>>> specifics of the admission control function is outside the >>>>>>>> scope " if it helps. >>>>>>> >>>>>>> Yes it does because the term "outside scope" has different >>>>>> meanings depending on context. >>>>>>> >>>>>> >>>>>> done. >>>>>> >>>>>>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION >>>>>>>> object and the IPv6 >>>>>>>>>> ASSOCIATION object. As defined, these objects each contain >>>>>>>> an Association >>>>>>>>>> Source field and a 16-bit Association ID field. The >>>>>>>> combination of the >>>>>>>>> Association >>>>>>>>>> Source and the Association ID uniquely identifies the >>>>>>>> association." but in the >>>>>>>>>> context RFC 4872 this association is defined in the >>>>>>>> context of the same tunnel >>>>>>>>>> end-point >>>>>>>> >>>>>>>> How about we clarify: "*As described above,* the >>>>>>>> combination of the Association Source and the Association ID >>>>>>>> uniquely identifies the association." >>>>>>> >>>>>>> It would be better to state >>>>>>> >>>>>>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >>>>>>> ASSOCIATION object in the context of a given session. >> As defined, >>>>>>> these objects each contain an Association Source field >>>> and a 16-bit >>>>>>> Association ID field. The combination of the Association >>>> Source and >>>>>>> the Association ID uniquely identifies the association. >>>> This doesn't >>>>>>> prevent that Association Types MAY further specify the >> context for >>>>>>> which this association is defined." >>>>>> >>>>>> It now reads: >>>>>> >>>>>> [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 >>>>>> ASSOCIATION object. As defined, these objects each >> contain an >>>>>> Association Source field and a 16-bit Association ID >> field. As >>>>>> described above, the contents of the object uniquely >> identifies >>>>>> an association. Because the Association ID field is a 16-bit >>>>>> field, an association source can allocate up to >> 65536 different >>>>>> associations and no more. >>>>> >>>>> OK >>>>> >>>>>>>>> (and actually the same for RFC 4873 which relies on MBB >>>> as defined >>>>>>>>> in >>>>>>>>>> RFC 3209) >>>>>>>> >>>>>>>> I don't believe this statement is correct, but again this >>>>>> is really a >>>>>>>> discussion beyond this draft. >>>>>>> >>>>>>> The statement here above is also to applicable to RFC 4873. >>>>>>> >>>>>>>>>> - Section 4: How is the following use case "There are >>>>>>>> scenarios where this >>>>>>>>> number >>>>>>>>>> is insufficient. (For example where the association >>>>>>>> identification is best >>>>>>>>> known >>>>>>>>>> and identified by a fairly centralized entity, which >>>>>>>> therefore may be involved >>>>>>>>> in a >>>>>>>>>> large number of associations.)" related to those proposed >>>>>>>> in the introduction. >>>>>>>>> ? >>>>>>>> >>>>>>>> As I read it, it enables practical third party (e.g., >>>>>>>> management entity) >>>>>>>> creation and management of association IDs. But, I'll >>>> defer to my >>>>>>>> coauthors on this. >>>>>>> >>>>>>> OK. Please let me know the result(s) of the discussion. >>>>>>> >>>>>>>>>> - Section 4: I don't question the requirement stated in >>>>>>>> "Per [RFC6370], >>>>>>>>> MPLS-TP >>>>>>>>>> LSPs can be identified based on an operator unique global >>>>>>>> identifier. The >>>>>>>>>> [RFC6370] defined "global identifier", or Global_ID, is >>>>>>>> based on [RFC5003] and >>>>>>>>>> includes the operator's Autonomous System Number (ASN)." >>>>>>>> the question is why >>>>>>>>>> the information is best encoded as part of the ASSOCIATION >>>>>>>> object ? isn't this >>>>>>>>> an >>>>>>>>>> LSP ATTRIBUTE or a Session Name ? >>>>>>>> >>>>>>>> It's the solution the WG agreed to. Other options are of >>>>>>>> course possible. >>>>>>> >>>>>>> My comment is specific because it triggers the question >>>> on how many >>>>>>> objects will we end up in spreading identification >> information (it >>>>>>> would be interesting to document the why this was felt the most >>>>>>> suited object as it is not a natural choice); more general >>>>>> comment is >>>>>>> what defines the "acceptable" use/extension of association. >>>>>> >>>>>> I think the last comment is a reasonable discussion to >>>> have. Not sure >>>>>> it belongs in, or gates the discussion. >>>>> >>>>> The LSP attributes RFC included this info for instance. This has >>>>> prevented lots of problems in use of the object because >> the content >>>>> of most objects could have been added to the LSP >> attribute RFC (cf. >>>>> Sect.8 "8. Summary of Attribute Bit Allocation" and Sect.10 >>>>> "Guidance for Key Application Scenarios"). >>>> >>>> Do you have some suggestions/text in mind? >>> >>> I will propose a Section for this. Can be done as part of >> this e-mail. > > > Can you put a placeholder in the document. Putting the full text would make this thread unreadable. > Please send it in a response to the publication notification of the next version. Please also include the CCAMP WG as they will need to review the text. > > >>>>>>>>>> - Section 4.2: states "It is important to note that >>>>>>>> Section 4 defines >>>>>>>>> association >>>>>>>>>> identification based on ASSOCIATION object matching, and >>>>>>>> that such matching >>>>>>>>> is >>>>>>>>>> based on the comparison of all fields in a ASSOCIATION >>>>>>>> object (unless type- >>>>>>>>>> specific comparison rules are defined). This applies >>>>>>>> equally to ASSOCIATION >>>>>>>>>> objects and Extended ASSOCIATION objects." any association >>>>>>>> is based on a form >>>>>>>>>> of matching, point here is that the matching and the >>>>>>>> identification of the >>>>>>>>> initiation >>>>>>>>>> of the matching information are distinct information >>>>>>>> entities (difference >>>>>>>>> between >>>>>>>>>> WHO and WHAT). I suggest to make a clearer distinction and >>>>>>>> specify setting and >>>>>>>>>> processing accordingly. >>>>>>>> >>>>>>>> I'm not seeing the issue. Can you perhaps propose some text? >>>>>>> >>>>>>> Here is the proposed text >>>>>>> >>>>>>> "It is important to note that Section 4 defines association >>>>>>> identification based on ASSOCIATION object matching, and >>>>>>> that such matching is based on the comparison of the fields >>>>>>> as determined by the ASSOCIATION Type of the ASSOCIATION >>>>>>> object. This applies equally to ASSOCIATION objects and >>>>>>> Extended ASSOCIATION objects." >>>>>> >>>>>> Here's the revised text. >>>>>> Identification of association is not modified by this >>>> section. It >>>>>> is important to note that Section 4 defines association >>>>>> identification based on ASSOCIATION object matching, >>>> and that such >>>>>> matching, in the absence of type-specific comparison >> rules, is >>>>>> based on the comparison of all fields in an >> ASSOCIATION object. >>>>>> This applies equally to ASSOCIATION objects and Extended >>>>>> ASSOCIATION objects. >>>>> >>>>> I would write (look at the text just above where you state "As >>>>> defined, these objects each contain an Association Source >>>> field and a >>>>> 16-bit Association ID field. As described above, the >>>> contents of the >>>>> object uniquely identifies an association." ... there is a need to >>>>> distinguish between identifying the ASSOCIATION object vs matching >>>>> ASSOCIATION objects). >>>> >>>> sure. But you need to be sure you're noting the difference >> between the >>>> word "association" and the thing "ASSOCIATION object". >>> >>> I am. >>> >>>>> This would >>>>> >>>>> "The procedure to perform ASSOCIATION object matching as >> defined in >>>>> Section 4 is not modified by this section. It is important to note >>>>> that Section 4 defines ASSOCIATION object matching if the >>>> ASSOCIATION >>>>> type does not refer to Association Type-specific rules for the >>>>> processing of the ASSOCIATION object (in which case the >> Association >>>>> Type-specific rules SHALL be applied); otherwise, >> ASSOCIATION object >>>>> matching applies by comparing all fields in an ASSOCIATION object. >>>>> This procedure applies equally to ASSOCIATION objects and Extended >>>>> ASSOCIATION objects." >>>> >>>> one more time, revised text now reads: >>>> The procedures related to association identification are not >>>> modified by this section. It is important to note >> that Section 4 >>>> defines the identification of associations based on ASSOCIATION >>>> object matching and that such matching, in the absence of >>>> type-specific comparison rules, is based on the >> comparison of all >>>> fields in an ASSOCIATION object. This applies equally to >>>> ASSOCIATION objects and Extended ASSOCIATION objects. >>> >>> I would state "in the absence of type-specific comparison rules (for >>> the Type value of the object being processed), is based on the >>> comparison of all fields in an ASSOCIATION object." >>> >>> because absence of rules is a generic statement. >> >> Again, I don't see the difference in meaning -- I think we're in the >> domain of style here. > > > The problem with your statement is: there is no (absence) > type-specific rule then apply full matching > > Mine it is either the one or the other. This is informative text (at this point). I also think it says the same thing. > > >>>>>>>>>> - Section 4.2: shouldn't "error processing" being >> documented ? >>>>>>>> >>>>>>>> Here too, I think the only error processing is as >>>> discussed above. >>>>>>>> Shout if you think otherwise. >>>>>>>> >>>>>>>>>> Example include >>>>>>>>>> admission control where receiving node rejects the >>>>>>>> incoming Path msg if the >>>>>>>>>> originating Global_ID/Ext.ASSOCIATION object isn't included, >>>>>>>> >>>>>>>> Interesting, but this is a type specific error. To me this >>>>>>>> sounds like >>>>>>>> a new admission control error that should be defined as >>>> part of the >>>>>>>> type-specific definition. >>>>>>> >>>>>>> Admission control failures are part of the error codes >>>>>> defined in RFC 2205. >>>>>> >>>>>> exactly! >>>>>> >>>>>>>>>> unauthorized >>>>>>>>>> Global ID ? >>>>>>>> >>>>>>>> Again interesting, but this is a new policy (and policy >>>> error) that >>>>>>>> wasn't proposed or discussed in the WG. I think this >>>>>> would be a fine >>>>>>>> addition, but is beyond the current document discussion. It >>>>>>>> could always be added if proposed. >>>>>>> >>>>>>> I defer this point to the AD. >>>>>> >>>>>> WFM. >>>>>> >>>>>>> >>>>>>>>>> etc. but also mismatches between Association source >> and Global >>>>>>>>>> Association source ? >>>>>>>> >>>>>>>> How would such a thing be detected, by checking BGP state? >>>>>> I guess we >>>>>>>> could add a new error code, but again I think we're going >>>>>> beyond the >>>>>>>> intent of the document/WG. >>>>>>> >>>>>>> Same here. >>>>>>> >>>>>>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370] >>>>>>>> defined global >>>>>>>>> identifier, >>>>>>>>>> or Global_ID, is based on [RFC5003] and includes the >>>>>>>> operator's Autonomous >>>>>>>>>> System Number (ASN)." while the latter "the use of the >>>>>>>> Global_ID is not >>>>>>>>> related >>>>>>>>>> to the use of the ASN in protocols such as BGP." which one >>>>>>>> applies ? >>>>>>>> >>>>>>>> I'll drop the note. This is better aligned with the field >>>>>> definition >>>>>>>> which has been updated based on comments of other reviewers. >>>>>>>> >>>>>>>> The current definition is: >>>>>>>> >>>>>>>> This field contains a value that is a unique global >>>>>> identifier or >>>>>>>> the special value zero (0). When non-zero and not >>>>>> overridden by >>>>>>>> local policy, the Global_ID as defined in [RFC6370] >>>>>> SHALL be used. >>>>>>>> The special value of zero indicates that no global >>>>>> identifier is >>>>>>>> present. Use of the special value of zero SHOULD be >>>> limited to >>>>>>>> entities contained within a single operator. >>>>>>> >>>>>>> OK >>>>>>> >>>>>>>>>> - Section 5 Documenting means to prevent/mitigate >>>>>>>> mis-association(s) and >>>>>>>>>> possible impact on security would be advisable. If this is >>>>>>>> felt to be >>>>>>>>> "application" or >>>>>>>>>> "type" specific a recommendation should be stated that the >>>>>>>> security mechanisms >>>>>>>>>> have to be documented as part of these documents. >>>>>>>> >>>>>>>> Why is there any additional risk than what " was >>>>>> previously defined in >>>>>>>> [RFC4872] and [RFC4873]."? (as is already stated in the draft.) >>>>>>> >>>>>>> I try to prevent that any further use/documents would state "no >>>>>>> additional risk compared to RFC 4872 and RFC 4873" or >>>> equivalent but >>>>>>> the application is running for voice calls over the >>>>>> Internet which is >>>>>>> a totally different application than G/MPLS Recovery/Resource >>>>>>> Sharing. >>>>>> >>>>>> Fair enough, but what additional issues do you foresee >>>> that should be >>>>>> covered? >>>>> >>>>> Nodes associating sessions, etc. should have the mean to >> verify the >>>> initiator of the association. >>>> >>>> This is true for every object in RSVP! I have no >> objection to object >>>> signing, ala SIDR, but this is well beyond the scope of >> this document >>>> and certainly isn't introduced in this document. >>> >>> We have to bring this point the Security directorate and >> ask them for >>> guidance (there could be a short term and a long term approach). I >>> understand the corresponding generic mechanism to perform such >>> verification isn't to be documented here but it has to be mentioned. >>> We loose track of all these security holes... hackers don't. >> >> RSVP's chain of trust is called out in RFC5920, which is reference by >> this draft. I certainly have no issue with a general discussion on >> RSVP's chain of trust model, but the scope of this conversation is >> beyond (and should be scoped) to this draft. > > > Can you point which section of that RFC you are referring to that would help the reader. > > I am asking because I didn't find any that speaks about ASSOCIATION object. Again, the association object is defined in [RFC4872] not this document. I'll add a reference to "chain of trust model". Lou PS I'll submit the draft in a couple of minutes. > > >> Thanks, >> Lou >> >>> >>> OK for the rest. We are nearly done. >>> >>> Thanks, >>> -dimitri. >>>>>>>>>> Editorials: >>>>>>>>>> >>>>>>>>>> - Introduction: "This document expands the possible usage >>>>>>>> of the ASSOCIATION >>>>>>>>>> object to >>>>>>>>>> non-GMPLS and non-recovery contexts." Suggested to state >>>>>>>> the actual the >>>>>>>>>> scope includes RSVP (instead of what it is not) >>>>>>>> >>>>>>>> I'll add: >>>>>>>> The expanded usage applies equally to GMPLS LSPs >>>> [RFC3473], MPLS >>>>>>>> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], >> [RFC2207], >>>>>>>> [RFC3175] and [RFC4860]. >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>>>>> - Introduction: s/different ports/different destination >>>>>> (dst) ports >>>>>>>>>> >>>>>>>> >>>>>>>> sure. >>>>>>>> >>>>>>>>>> - Section 2 would better refer to a "Generalization" >>>>>> rather than a >>>>>>>>> "modification" >>>>>>>>>> >>>>>>>> >>>>>>>> I'd be okay with this, but I think modification makes is less >>>>>>>> likely to be misinterpreted so will leave as is. >>>>>>> >>>>>>> The term modification implies a change in existing >>>> processing (even >>>>>>> if the intention is different) and actually as the >>>> applicability is >>>>>>> now possible to RSVP and MPLS-TE. >>>>>> >>>>>> This isn't a major point for me, so will change it. (In >> 5 places.) >>>>> >>>>> OK (actually the doc. generalizes the use of the object >> whereas 4873 >>>> for inst documents type-specific/specialized use of the object) >>>>> >>>>>>>>>> - Section 3 states "As defined by [RFC4872] and reviewed >>>>>>>> in [RFC6689],..." but >>>>>>>>> an >>>>>>>>>> information RFC doesn't review at best "documents" >>>>>>>> certain usage. This >>>>>>>>>> statement is repeated at multiple places. >>>>>>>> >>>>>>>> Why can't it review? This is what the abstract of RFC6689 >>>>>>>> says it does. >>>>>>> >>>>>>> It was overstated in RFC 6689. >>>>>> >>>>>> This document doesn't change 6689. >>>>> >>>>> OK. >>>>> >>>>>>>>>> - Section 3 mentions "Object usage in both Path and Resv >>>>>>>> messages is >>>>>>>>> discussed. >>>>>>>>>> The usage applies equally to >>>>>>>>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP >>>>>>>> RSVP sessions >>>>>>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having >>>>>>>> such statement in the >>>>>>>>>> introduction would desirable. >>>>>>>> >>>>>>>> Fair enough. >>>>>>>> >>>>>>>> Thank you for the review! >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>> Thanks, >>>>>>> -d. >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>> >>>>> Thanks, >>>>> -d. >>>> >>>> Thanks again. >>>> >>>> Lou >>>> >>>> PS I'll submit a revised version of the draft at some >> point today to >>>> document all changes to date. >>>> >>>> >>> >>> >>> >>> >> > > > > From dimitri.papadimitriou@alcatel-lucent.com Wed Sep 5 14:39:49 2012 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 86C3121F86D4 for ; Wed, 5 Sep 2012 14:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.581 X-Spam-Level: X-Spam-Status: No, score=-8.581 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 Nv82uI8xATdI for ; Wed, 5 Sep 2012 14:39:46 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 182E621F86EB for ; Wed, 5 Sep 2012 14:39:45 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q85Ldhvw031134 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 23:39:44 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 5 Sep 2012 23:39:44 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lou Berger Date: Wed, 5 Sep 2012 23:39:42 +0200 Thread-Topic: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 Thread-Index: Ac2Lrc7Gc0cH7Ho4QuKv1Oe559P8VQAAJsRQ Message-ID: References: <23a801cd879a$6ca18350$45e489f0$@olddog.co.uk> <50461D40.1010607@labn.net> <5046785D.6050700@labn.net> <50474748.1030303@labn.net> <504788AC.3090802@labn.net> <5047C4AB.10907@labn.net> In-Reply-To: <5047C4AB.10907@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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "adrian@olddog.co.uk" , "draft-ietf-ccamp-assoc-ext.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 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, 05 Sep 2012 21:39:49 -0000 Lou, Concerning the remark "Now that said, it really should have been done along with the original obj= ect definition." it is in RFC 4872, but it deals with LSP admission failure (because "type-s= pecific"), as you cover a larger scope I just ask why it is not extended. T= ext extracted from RFC 4872: 4) Error Code/Sub-code values The following Error code/sub-code values are defined in this document: Error Code =3D 01: "Admission Control Failure" (see [RFC2205]) o "Admission Control Failure/LSP Admission Failure" (4) o "Admission Control Failure/Bad Association Type" (5) Thanks, -d. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, September 05, 2012 23:31 > To: Papadimitriou, Dimitri (Dimitri) > Cc: adrian@olddog.co.uk; > draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > > See below. > > On 9/5/2012 4:50 PM, Papadimitriou, Dimitri (Dimitri) wrote: > > > > Lou, > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Wednesday, September 05, 2012 19:15 > >> To: Papadimitriou, Dimitri (Dimitri) > >> Cc: adrian@olddog.co.uk; > >> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04 > >> > >> Dimitri (BTW sorry about the dropping the t in my last message) > >> > >> See below. > >> > >> On 9/5/2012 12:08 PM, Papadimitriou, Dimitri (Dimitri) wrote: > >>> Hi Lou, > >>> > >>>> -----Original Message----- > >>>> From: Lou Berger [mailto:lberger@labn.net] > >>>> Sent: Wednesday, September 05, 2012 14:36 > >>>> To: Papadimitriou, Dimitri (Dimitri) > >>>> Cc: adrian@olddog.co.uk; > >>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > >>>> Subject: Re: [RTG-DIR] FW: Review of > draft-ietf-ccamp-assoc-ext-04 > >>>> > >>>> Hi Dimiri, > >>>> Responses in line... > >>>> > >>>> On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) > wrote:> Lou, > >>>>> > >>>>> see below, > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: rtg-dir-bounces@ietf.org > >>>>>> [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger > >>>>>> Sent: Tuesday, September 04, 2012 23:54 > >>>>>> To: Papadimitriou, Dimitri (Dimitri) > >>>>>> Cc: adrian@olddog.co.uk; > >>>>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org; rtg-dir@ietf.org > >>>>>> Subject: Re: [RTG-DIR] FW: Review of > >> draft-ietf-ccamp-assoc-ext-04 > >>>>>> > >>>>>> Dimitri, > >>>>>> See below. > >>>>>> > >>>>>> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote: > >>>>>>> Hi Lou, > >>>>>>> > >>>>>>> See inline: > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>>>>> Sent: Tuesday, September 04, 2012 17:25 > >>>>>>>> To: adrian@olddog.co.uk; Papadimitriou, Dimitri (Dimitri) > >>>>>>>> Cc: rtg-dir@ietf.org; > >>>> draft-ietf-ccamp-assoc-ext.all@tools.ietf.org > >>>>>>>> Subject: Re: [RTG-DIR] FW: Review of > >>>> draft-ietf-ccamp-assoc-ext-04 > >>>>>>>> > >>>>>>>> Adrian, > >>>>>>>> Much Thanks. (BTW is there a reason not to include the > >>>>>>>> WG in this, or > >>>>>>>> such, discussions?) > >>>>>>>> > >>>>>>>> Dimitri, > >>>>>>>> Please see below for inline responses. > >>>>>>>> > >>>>>>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote: > >>>>>>>>> Here is Dimitri's Routing Dir review. Many thanks for > >>>> the review. > >>>>>>>>> > >>>>>>>>> Lou, you can address this and the other comments and post a > >>>>>>>> new revision. > >>>>>>>>> > >>>>>>>>> Adrian > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Papadimitriou, Dimitri (Dimitri) > >>>>>>>> [mailto:dimitri.papadimitriou@alcatel- > >>>>>>>>>> lucent.com] > >>>>>>>>>> Sent: 31 August 2012 13:23 > >>>>>>>>>> To: BRUNGARD, DEBORAH A; adrian@olddog.co.uk; > >>>> sbryant@cisco.com; > >>>>>>>>>> huawei.danli@huawei.com > >>>>>>>>>> Subject: Review of draft-ietf-ccamp-assoc-ext-04 > >>>>>>>>>> > >>>>>>>>>> Hi All, > >>>>>>>>>> > >>>>>>>>>> Here below the review of this document. > >>>>>>>>>> > >>>>>>>>>> Technical comments: > >>>>>>>>>> > >>>>>>>>>> - Example 3: isn't this extension also not updating > >> RFC 2205 ? > >>>>>>>> > >>>>>>>> Yes. This is stated in the header, abstract and section 3. > >>>>>>> > >>>>>>> I thought to include this in the introduction since other > >>>>>> updated RFC are indicated. > >>>>>>> > >>>>>> > >>>>>> Agreed. Text has been added. > >>>>> > >>>>> OK. > >>>>> > >>>>>>>>>> - The statement "In order to support the more general > >>>>>> usage of the > >>>>>>>>>> ASSOCIATION object," is actually not correct RFC 4872 > >>>>>>>> doesn't prevent support > >>>>>>>>> of > >>>>>>>>>> other usage of the ASSOCIATION object. It has just > >>>>>>>> documented its usage in the > >>>>>>>>>> GMPLS recovery context. > >>>>>>>> > >>>>>>>> I'm not sure how these two statements (the document text > >>>>>> and your last > >>>>>>>> sentence) are mutually inconsistent. I see no text change > >>>>>>>> based on this comment. > >>>>>>> > >>>>>>> I meant: "In order to document the more general usage of > >>>>>> the ASSOCIATION object, ..." > >>>>>>> > >>>>>> > >>>>>> While I don't mind the change in this part of the sentience, > >>>>>> the result > >>>>>> is a bit odd "In order to document the more general > usage of the > >>>>>> ASSOCIATION object, this document ..." So will leave as is. > >>>>> > >>>>> "In order to document the more general usage of the ASSOCIATION > >>>> object, this specification ..." > >>>> > >>>> I think we're in the noise here... > >>>> > >>>>>>>>>> - Section 3.1, "Cross-session association based on Path > >>>>>>>> state is defined in > >>>>>>>>>> [RFC4872]." the latter defines cross-LSP association > >>>>>>>> within the same session > >>>>>>>>> (not > >>>>>>>>>> cross-session association) but nothing prevents extending > >>>>>>>> usage to cross- > >>>>>>>>>> Session. > >>>>>>>>>> > >>>>>>>> > >>>>>>>> I see no text change requested based on this comment. > >>>>>>> > >>>>>>> I meant: "Cross-LSP association based on Path state is > >> defined in > >>>>>>> [RFC4872]; here we document cross-session association..." > >>>>>> > >>>>>> I'll change two instances of "Cross-session association" > >>>> to "Cross-LSP > >>>>>> association". > >>>>> > >>>>> OK. > >>>>> > >>>>>>>>>> - Section 3.1.2 the statement "the definition SHOULD allow > >>>>>>>> for association > >>>>>>>>> based > >>>>>>>>>> on identical ASSOCIATION objects" is not clear, does it > >>>>>>>> that the information > >>>>>>>>>> elements part of the object shall be identical ? > >>>>>>>> > >>>>>>>> I see no difference between the current text (object > >>>>>> equivalence) and > >>>>>>>> object information element equivalence. I don't believe > >>>>>>>> there's a case > >>>>>>>> where you can have one without the other. Please > >>>> correct me if you > >>>>>>>> think I'm mistaken. > >>>>>>> > >>>>>>> If the association ID are defined such that: > >>>>>>> > >>>>>>> - the Association ID of Session 1 or LSP 1 points to the > >>>>>> Session ID or LSP ID of LSP 2 > >>>>>>> > >>>>>>> - the Association ID of Session 2 or LSP 2 points to the > >>>>>> Session ID or LSP ID of LSP 1 > >>>>>> > >>>>>> Association based on matching Association ID to Session ID > >>>> is not part > >>>>>> of this draft. > >>>>> > >>>>> if the session ID isn't used - which is possible - > >>>> documenting the ID > >>>>> setting to ensure unicity (per association) is to be > >> documented the > >>>>> definition only states concerning value setting > >>>>> > >>>>> "A value assigned by the the node that originated the > association. > >>>>> When combined with the other fields carried in the > >>>> object, this > >>>>> value uniquely identifies an association." > >>>> > >>>> Actually, the document provides additional guidance in the > >> procedures > >>>> section: > >>>> > >>>> The Association ID field MUST be set to a value that uniquely > >>>> identifies the sessions to be associated within the > >> context of the > >>>> Association Source field. The Association Source > field MUST be > >>>> set to a unique address assigned to the node originating the > >>>> association. > >>> > >>> The initial statement should be part of the definition in the form > >>> > >>> "The Association ID value space is unique per ?" I write > >> "?" because is it per node, per RSVP process, per > Association source ? > > > > > > what about the above one concerning the unicity ? > > unique as scoped by the Association Source field. As stated: > > When combined with the other fields carried in the object, this > value uniquely identifies an association. > > and > The Association ID field MUST be set to a value that > uniquely identifies the sessions to be associated within > the context > of the Association Source field. The Association Source field MUST > be set to a unique address assigned to the node originating the > association. > > I think this is sufficiently unambiguous to ensure interoperable > implementations. > > > > > > >>> The processing should in my opinion state (or equivalent): > >>> > >>> "The Association ID field MUST be set to a unique value > >> that uniquely > >>> identifies the association between sessions that are > >> associated within > >>> the context of the Association Source field." > >> > >> I frankly don't see any difference in the wording. > > > > > > "uniquely identify the sessions to be associated" > > > > vs > > > > "uniquely identify the association" > > > > is clearly different. > > The association of what? --> Sessions. > > So I'm at a loss to see the difference. > > In the interest of moving forward I'll use "association being > identified" (in 3 places.) > > > > > > >>>>>>> Other elements aren't necessarily identical. > >>>>>> > >>>>>> They must be identical in the context of this draft and > >>>> the absence of > >>>>>> type-specific processing rules. > >>>>>> > >>>>>>> The setting of the association source is application type > >>>> specific. > >>>>>> > >>>>>> Even if true, I don't see how this impacts the text of > the draft. > >>>>> > >>>>> Because a full match (incl.association source) wouldn't apply > >>>>> anymore. I think the point goes to the question does extension > >>>>> include association between sessions that uses two > >> different source > >>>>> addresses that can be two interface address ? > >>>> > >>>> sure. As documented, there is no mention of other fields > >> to check as > >>>> part of association identification. > >>> > >>> I don't get it. If the matching operation implies that all fields > >>> shall be identical including the association source how do you > >>> proceed ? > >> > >> Simple. If the objects are identical, there's an association > >> identified. If not, there's no association. > > > > > > This is not the question. If the association are set per source > > interface how this mechanism shall be used ? > > Huh, where is this stated or even implied in the document. > It only says: > > The Association Source field MUST be set to a unique address > assigned to the node originating the association. > > This can be any address associated with any node. E.g., a loop back or > even management station address. > > > > The point I am raising > > here is this precluded by design and it is a common case > which likely > > to happen with the examples you have highlighted in the > > introduction. > > You're right. If the implementation uses different > association sources > to try to identify a single association it won't work. But > this is just > a broken implementation. The document already repeats the concept of > using the same address / object contents in so many places I > don't think > it needs to be stated yet again. > > I'll submit the changes we have so far, and if you still > think there's a > need for a text change, please propose it as I'm at a loss. > > > > > > >>>>>>> Another case (if I am correctly understanding the related > >>>> text), is > >>>>>>> related to the MPLS-TP section. The association object of two > >>>>>>> non-associated session can have the value fields in the > >>>>>>> ext.association object. > >>>>>> > >>>>>> This is a true statement, but unless the contents of the > >>>> whole object > >>>>>> are identical, there's no association. > >>>>> > >>>>> In GMPLS you will have association source setting being > >>>> identical for > >>>>> many tunnels/LSPs (many controllers will set their local > >> IP address > >>>>> as source) while actually these LSPs aren't. I don't > >> think there is > >>>>> any indication that prevents this to happen ? > >>>> > >>>> Correct and this is intentional. All that is required for > >>>> association is > >>>> a simple match of objects. If two nodes use the same > >> source address > >>>> without coordinating IDs there may be collisions, but there's > >>>> no way to > >>>> know if this is intentional or an error when processing > >> the path/resv > >>>> messages. > >>> > >>> OK. As such this corroborates my initial remark where the > >> association > >>> object was actually the most suited place to put this information. > >> > >> Great. (I think.) > > > > > > I meant was *not* (sorry for the confusion). > > > > > >>>>>>>>>> - Section 3.1.2 "The Association ID field MUST be set to a > >>>>>>>> value that uniquely > >>>>>>>>>> identifies the sessions to be associated within the > >>>>>>>> context of the Association > >>>>>>>>>> Source field." > >>>>>>>>>> this statement is not compatible with e.g. RFC 4873 and > >>>>>>>> 4872 where > >>>>>>>>> Association > >>>>>>>>>> ID are set to LSP ID and not sessions while it is > >>>> stated in 3.1 " > >>>>>>>> > >>>>>>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage" > >>>>>>> > >>>>>>> Yes and section 3.1.2 indicates "These procedures > >>>>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >>>>>> session state." > >>>>>>> > >>>>>>> don't you think this induces confusion ? > >>>>>> > >>>>>> Perhaps, but this is why the 3.1 states: > >>>>>> This section does not modify processing required to support > >>>>>> [RFC4872] > >>>>>> and [RFC4873]. I'll repeat the sentence at the > start of 3.1.2. > >>>>> > >>>>> This being said the Code point for RFC 4873 isn't changed > >> but points > >>>>> to this document. Any reason since there is no > processing change ? > >>>> > >>>> I assume you're referring to the Resource Sharing type. This > >>>> is updated as the same type is now usable for non-recovery LSPs. > >>> > >>> OK. > >>> > >>>>>>>> so it does not impact to RFC 4873 and 4872 > >>>>>> implementations. As stated > >>>>>>>> in the draft and quoted by you: > >>>>>>>> > >>>>>>>>> This section > >>>>>>>>> does not > >>>>>>>>>> modify processing required to support [RFC4872] and > >>>>>>>> [RFC4873], and which is > >>>>>>>>>> reviewed in Section 3 of [RFC6689]. " > >>>>>>> > >>>>>>> The point I am raising is that Section 3.1 reads as there no > >>>>>>> "additions" whereas once reaching Section 3.1.2 one > >>>> understands that > >>>>>>> the statement no modifications meant actually extensions. > >>>>>>> > >>>>>>> Section 3.1 states "This section does not modify processing > >>>>>> required to > >>>>>>> support [RFC4872] and [RFC4873], and which is reviewed > >>>>>> in Section 3 > >>>>>>> of [RFC6689]. " > >>>>>>> > >>>>>>> Section 3.1.2 states " These procedures > >>>>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >>>>>> session state." > >>>>>>> > >>>>>>> Hence, > >>>>>>> > >>>>>>> Section 3.1.2 should be rephrased as > >>>>>>> > >>>>>>> "This section is based on the processing rules described > >>>>>> in [RFC4872] > >>>>>>> and [RFC4873], and which is reviewed in [RFC6689]. > >>>>>> These procedures > >>>>>>> apply equally to GMPLS LSPs, MPLS LSPs and non-LSP > >>>>>> session state." > >>>>>>> > >>>>>>> Section 3.1.2 should be rephrased as > >>>>>>> > >>>>>>> "This section generalizes the processing rules described > >>>>>> in [RFC4872] > >>>>>>> and [RFC4873], and which is reviewed in [RFC6689], for > >>>>>> application > >>>>>>> to MPLS LSPs and non-LSP session state. For GMPLS > >> LSP rules are > >>>>>>> extended for applications not related to the recovery > >>>>>> and resource > >>>>>>> sharing." > >>>>>> > >>>>>> I've revised the text to read: > >>>>>> > >>>>>> This section is based on, and extends, the processing rules > >>>>>> described in [RFC4872] and [RFC4873], and which is > >> reviewed in > >>>>>> [RFC6689]. This section applies equally to GMPLS > >>>> LSPs, MPLS LSPs > >>>>>> and non-LSP session state. Note, as previously > stated, this > >>>>>> section does not modify processing required to support > >>>> [RFC4872] > >>>>>> and [RFC4873]. > >>>>> > >>>>> OK. > >>>>> > >>>>>>>> 2) I also think "not compatible" is an overstatement, but > >>>>>> I guess that > >>>>>>>> it isn't really a critical point to discuss as the > >>>> referenced text > >>>>>>>> doesn't relate to [RFC4872] and [RFC4873]. > >>>>>>> > >>>>>>> The proposed phrasing would resolve it. > >>>>>>> > >>>>>>>>>> and in RFC 4873/Section 3.2 "The > >>>>>>>>>> ASSOCIATION object is used to associate different LSPs > >>>>>>>> with each other." > >>>>>>>> > >>>>>>>> I see no text change requested based on this comment. > >>>>>>> > >>>>>>> Ditto. > >>>>>>> > >>>>>>>>>> - Section 3.1.2 "An association is deemed to exist when > >>>>>>>> the same values are > >>>>>>>>>> carried in all fields of the ASSOCIATION objects being > >>>>>>>> compared." this > >>>>>>>>> introduces > >>>>>>>>>> an additional level of indirection. To associate A to B A > >>>>>>>> can simply refer to > >>>>>>>>> an > >>>>>>>>>> identifier of B (and vice versa), A doesn't need to have > >>>>>>>> an additional ID > >>>>>>>>> (e.g. C) > >>>>>>>>>> that is also associated to B. Generalization would consist > >>>>>>>> here in introducing > >>>>>>>>> an > >>>>>>>>>> ext.association ID common to A, B, and C. In other terms, > >>>>>>>> generalizing the > >>>>>>>>> notion > >>>>>>>>>> of association doesn't require the introduction of an > >>>>>>>> additional level of > >>>>>>>>>> indirection. > >>>>>>>> > >>>>>>>> I really have no idea what this comment means. There is no > >>>>>>>> indirection stated or implied by the text. > >>>>>>> > >>>>>>> It is the result of what the text implies and it is > specifically > >>>>>>> related to the "Association ID". Implicitly the > >> document mandates > >>>>>>> than this identifier can't take any value of existing fields > >>>>>>> identifying tunnels/LSPs. > >>>>>> > >>>>>> Not at all. As long as the IDs as consistently set across > >>>> association > >>>>>> objects, an association will be made. Furthermore, > type specific > >>>>>> processing can be defined that allows implicit mapping > >> such as you > >>>>>> defined in 4872. > >>>>> > >>>>> The first item to check is the Association Type to distinguish > >>>>> between matching processes. The statement "In the absence of > >>>>> Association Type-specific rules for identifying > >> association,.." was > >>>>> probably intended to state (to remove the confusion of > >> the statement > >>>>> "identifying assocation"): > >>>>> > >>>>> "If the ASSOCIATION type does not refer to Association > >> Type-specific > >>>>> rules for the processing of the ASSOCIATION object (in > >>>> which case the > >>>>> Association Type-specific rules SHALL be applied), ..." > >>>> > >>>> IMO this should be left to the definition of the Association > >>>> Type-specific rules, i.e., is beyond the scope of this document. > >>> > >>> OK. > >>> > >>>>>>>> It means test for simple equivalence, > >>>>>>>> i.e., (ASSOCIATION object of A) =3D (ASSOCIATION object of > >>>>>> B) and that's > >>>>>>>> it. There's no (session) ID referencing. Can you restate > >>>>>>>> your concern? > >>>>>>> > >>>>>>> My concern is this an equivalence between objects not an > >>>>>> assocation of sessions. > >>>>>>> > >>>>>> > >>>>>> Per this document, equivalence between objects identifies an > >>>>>> assocation > >>>>>> of sessions. This document does not generalize the > session ID to > >>>>>> association ID matching that was part of 4872. > >>>>> > >>>>> The above text would clarify the point. > >>>> > >>>> The following has been added to the second to last paragraph > >>>> of Section 1. > >>>> > >>>> When using the procedures defined below, association > >> is identified > >>>> based on simple ASSOCIATION object matching. Some > of the other > >>>> matching mechanisms defined in RFC 4872, e.g., > >> matching based on > >>>> Session IDs, are not generalized. > >>> > >>> I would write: > >>> > >>> When using the procedures defined in this document, > >> association is identified > >>> based on ASSOCIATION object matching. Some of the other > >>> matching mechanisms defined in RFC 4872, e.g., > >> matching based on > >>> Session IDs, are not generalized in this document. > Association > >>> type-specific processing is outside the scope of this > >> document. > >>> > >> > >> understood, I'll modify the paragraph. (subject to style > differences.) > >> > >>>>>>>>>> - Section 3.2.2 I understand triggers for Resv-initiated > >>>>>>>> associations aren't > >>>>>>>>>> documented but how to prevent a sender willing to demote > >>>>>>>> receiver-driven > >>>>>>>>>> associations ? > >>>>>>>> > >>>>>>>> Can you clarify this question? > >>>>>>> > >>>>>>> Let me put first in context. Generalization includes > Rcv driven > >>>>>>> associations but only additions are documented. > >>>>>>> > >>>>>>>> Are you asking: > >>>>>>>> - how a Path sender can prevent a receiver initiated > >>>>>> association? (it > >>>>>>>> can't) > >>>>>>>> > >>>>>>>> - how a Resv sender removes an association? (it just removes > >>>>>>>> the object, no different from a path message) > >>>>>>> > >>>>>>> The corresponding processing is to be documented. > >> Because one can > >>>>>>> also demote an association by having each LSP/session > >> pointing to > >>>>>>> itself while keeping the object in the Path/Resv message. > >>>>>> > >>>>>> This sounds like the implicit matching rules in 4872. > >>>> Such session ID > >>>>>> to association ID matching is not part of this document. > >>>>> > >>>>> I hear you but as the ASSOCIATION ID value setting > >> doesn't state it > >>>>> can't be done, you can get the same result. > >>>> > >>>> Sure, and this would be perfectly fine way for an > implementation to > >>>> select its IDs for certain possible applications, but this > >> is a local > >>>> implementation choice in the general case, or > >> type-specific processing > >>>> which is outside the scope of this document. > >>> > >>> OK. > >>> > >>>>> You could even assume that changing ID to an unused but > >> value would > >>>>> lead to the same result (as matching wouldn't give a > >> positive result > >>>>> the ASSOCIATION would also be removed since it can't be found > >>>>> anymore). > >>>> > >>>> > >>>>> > >>>>>>>> - something else? > >>>>>>>> > >>>>>>>>>> - Section 3.1.2 and 3.2.2 no error processing is being > >>>> documented > >>>>>>>> > >>>>>>>> I think this is a fair point. The only case I think that > >>>>>>>> can/should be > >>>>>>>> addressed is unknown types. (As is usual, per > >> RFC2205, errors in > >>>>>>>> formats to not trigger any specific message response.) > >>>>>>>> Sections 3.1 and > >>>>>>>> 3.2 only discuss identification of associations, so I > >>>>>> propose adding a > >>>>>>>> section 3.3.2. How about something like: > >>>>>>>> > >>>>>>>> 3.3.2. Unknown Association Types > >>>>>>>> > >>>>>>>> A node that receives an ASSOCIATION object with an unknown > >>>>>>>> ASSOCIATION type MUST forward all received > >> ASSOCIATION objects > >>>>>>>> as defined above. The node MAY also identify > >> associations per > >>>>>>>> the defined processing, e.g., to make this information > >>>> available > >>>>>>>> via a management interface. > >>>>>>> > >>>>>>> OK. Wouldn't you document PathErr/ResvErr and Notify ? > >>>>>> > >>>>>> IMO Not for an unknown type. > >>>>> > >>>>> I don't understand the answer. > >>>> > >>>> I don't think unknown type should result in a > PathErr/ResvErr at a > >>>> transit/egress/ingress node. > >>> > >>> The question why do you use "unknown" type and not > >>> > >>> Error Code =3D 01: "Admission Control Failure" (see [RFC2205]) > >>> > >>> o "Admission Control Failure/Session Admission Failure" (6) > >> > >> Because I don't think lack of support of a type should result in an > >> error in the general case. (for example would you generate > an error on > >> transit nodes for associations that are only relevant to > >> end-points, or vice versa?) > > > > > > How would you then allow that session to cross the network ? Thus it > > depends on policy on what operator wants to apply at ingress (not up > > to the protocol to decide/enforce a policy). > > So what you're really asking for is a compatibility section that says > how to deal with the case with inconsistent support of an association > type. Well, sure we can add something. Now that said, it > really should > have been done along with the original object definition. > > > > > > >>>>>>>>>> whereas mis- > >>>>>>>>>> match in association should be considered as a > generic error. > >>>>>>>> > >>>>>>>> This isn't a detectable error case as it is impossible for > >>>>>> a node to > >>>>>>>> know if two association objects are intentionally or > >>>>>> unintentionally > >>>>>>>> different. > >>>>>>> > >>>>>>> Earlier, in the text it is mentioned that processing > >>>>>> implies checking > >>>>>>> all Path/Resv state. We have to understand that putting > >> in place a > >>>>>>> generic processing (outside a specific ASSOCIATION > Type) renders > >>>>>> > >>>>>> I think this sentence got truncated... > >>>>> > >>>>> ... safeguard rule advisable. > >>>>> > >>>>>>>>>> - Section 3.3 states "Since the admission control function > >>>>>>>> is outside the > >>>>>>>>> scope of > >>>>>>>>>> RSVP,..." are you sure ? > >>>>>>>> > >>>>>>>> Yes. Per RFC2205: > >>>>>>> > >>>>>>> Yes I know the figuere whose terms mixes functions, protocol > >>>>>>> processes, etc. but this goes beyond the review of this > >>>> document ;-) > >>>>>> > >>> [snip figure] > >>>>>>>> an RSVP QoS request is passed to two local > >>>>>>>> decision modules, "admission control" and "policy > control". > >>>>>>>> > >>>>>>>>>> admission control is an intrinsic function associated > >>>>>>>>> to RFC > >>>>>>>>>> 2205 (there are errors documented for admission control > >>>>>>>> failures). I think you > >>>>>>>>>> mean that the inner working of the mechanisms used by > >>>>>>>> nodes to determine if > >>>>>>>>>> they have sufficient available resources to support > >>>>>>>> incoming requests. > >>>>>>>> > >>>>>>>> I think this is the same as what is stated. > >>>>>>> > >>>>>>> What you mean is: the inner-working or implementation > >> of admission > >>>>>>> control for QoS requests is outside scope of RFC 2205. > >>>>>>> > >>>>>>>> we can add "implementation specifics ", i.e., " Since the > >>>>>>>> implementation > >>>>>>>> specifics of the admission control function is outside the > >>>>>>>> scope " if it helps. > >>>>>>> > >>>>>>> Yes it does because the term "outside scope" has different > >>>>>> meanings depending on context. > >>>>>>> > >>>>>> > >>>>>> done. > >>>>>> > >>>>>>>>>> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION > >>>>>>>> object and the IPv6 > >>>>>>>>>> ASSOCIATION object. As defined, these objects each contain > >>>>>>>> an Association > >>>>>>>>>> Source field and a 16-bit Association ID field. The > >>>>>>>> combination of the > >>>>>>>>> Association > >>>>>>>>>> Source and the Association ID uniquely identifies the > >>>>>>>> association." but in the > >>>>>>>>>> context RFC 4872 this association is defined in the > >>>>>>>> context of the same tunnel > >>>>>>>>>> end-point > >>>>>>>> > >>>>>>>> How about we clarify: "*As described above,* the > >>>>>>>> combination of the Association Source and the Association ID > >>>>>>>> uniquely identifies the association." > >>>>>>> > >>>>>>> It would be better to state > >>>>>>> > >>>>>>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > >>>>>>> ASSOCIATION object in the context of a given session. > >> As defined, > >>>>>>> these objects each contain an Association Source field > >>>> and a 16-bit > >>>>>>> Association ID field. The combination of the Association > >>>> Source and > >>>>>>> the Association ID uniquely identifies the association. > >>>> This doesn't > >>>>>>> prevent that Association Types MAY further specify the > >> context for > >>>>>>> which this association is defined." > >>>>>> > >>>>>> It now reads: > >>>>>> > >>>>>> [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 > >>>>>> ASSOCIATION object. As defined, these objects each > >> contain an > >>>>>> Association Source field and a 16-bit Association ID > >> field. As > >>>>>> described above, the contents of the object uniquely > >> identifies > >>>>>> an association. Because the Association ID field > is a 16-bit > >>>>>> field, an association source can allocate up to > >> 65536 different > >>>>>> associations and no more. > >>>>> > >>>>> OK > >>>>> > >>>>>>>>> (and actually the same for RFC 4873 which relies on MBB > >>>> as defined > >>>>>>>>> in > >>>>>>>>>> RFC 3209) > >>>>>>>> > >>>>>>>> I don't believe this statement is correct, but again this > >>>>>> is really a > >>>>>>>> discussion beyond this draft. > >>>>>>> > >>>>>>> The statement here above is also to applicable to RFC 4873. > >>>>>>> > >>>>>>>>>> - Section 4: How is the following use case "There are > >>>>>>>> scenarios where this > >>>>>>>>> number > >>>>>>>>>> is insufficient. (For example where the association > >>>>>>>> identification is best > >>>>>>>>> known > >>>>>>>>>> and identified by a fairly centralized entity, which > >>>>>>>> therefore may be involved > >>>>>>>>> in a > >>>>>>>>>> large number of associations.)" related to those proposed > >>>>>>>> in the introduction. > >>>>>>>>> ? > >>>>>>>> > >>>>>>>> As I read it, it enables practical third party (e.g., > >>>>>>>> management entity) > >>>>>>>> creation and management of association IDs. But, I'll > >>>> defer to my > >>>>>>>> coauthors on this. > >>>>>>> > >>>>>>> OK. Please let me know the result(s) of the discussion. > >>>>>>> > >>>>>>>>>> - Section 4: I don't question the requirement stated in > >>>>>>>> "Per [RFC6370], > >>>>>>>>> MPLS-TP > >>>>>>>>>> LSPs can be identified based on an operator unique global > >>>>>>>> identifier. The > >>>>>>>>>> [RFC6370] defined "global identifier", or Global_ID, is > >>>>>>>> based on [RFC5003] and > >>>>>>>>>> includes the operator's Autonomous System Number (ASN)." > >>>>>>>> the question is why > >>>>>>>>>> the information is best encoded as part of the ASSOCIATION > >>>>>>>> object ? isn't this > >>>>>>>>> an > >>>>>>>>>> LSP ATTRIBUTE or a Session Name ? > >>>>>>>> > >>>>>>>> It's the solution the WG agreed to. Other options are of > >>>>>>>> course possible. > >>>>>>> > >>>>>>> My comment is specific because it triggers the question > >>>> on how many > >>>>>>> objects will we end up in spreading identification > >> information (it > >>>>>>> would be interesting to document the why this was > felt the most > >>>>>>> suited object as it is not a natural choice); more general > >>>>>> comment is > >>>>>>> what defines the "acceptable" use/extension of association. > >>>>>> > >>>>>> I think the last comment is a reasonable discussion to > >>>> have. Not sure > >>>>>> it belongs in, or gates the discussion. > >>>>> > >>>>> The LSP attributes RFC included this info for instance. This has > >>>>> prevented lots of problems in use of the object because > >> the content > >>>>> of most objects could have been added to the LSP > >> attribute RFC (cf. > >>>>> Sect.8 "8. Summary of Attribute Bit Allocation" and Sect.10 > >>>>> "Guidance for Key Application Scenarios"). > >>>> > >>>> Do you have some suggestions/text in mind? > >>> > >>> I will propose a Section for this. Can be done as part of > >> this e-mail. > > > > > > Can you put a placeholder in the document. Putting the full > text would make this thread unreadable. > > > > Please send it in a response to the publication notification > of the next > version. Please also include the CCAMP WG as they will need to review > the text. > > > > > > >>>>>>>>>> - Section 4.2: states "It is important to note that > >>>>>>>> Section 4 defines > >>>>>>>>> association > >>>>>>>>>> identification based on ASSOCIATION object matching, and > >>>>>>>> that such matching > >>>>>>>>> is > >>>>>>>>>> based on the comparison of all fields in a ASSOCIATION > >>>>>>>> object (unless type- > >>>>>>>>>> specific comparison rules are defined). This applies > >>>>>>>> equally to ASSOCIATION > >>>>>>>>>> objects and Extended ASSOCIATION objects." any association > >>>>>>>> is based on a form > >>>>>>>>>> of matching, point here is that the matching and the > >>>>>>>> identification of the > >>>>>>>>> initiation > >>>>>>>>>> of the matching information are distinct information > >>>>>>>> entities (difference > >>>>>>>>> between > >>>>>>>>>> WHO and WHAT). I suggest to make a clearer distinction and > >>>>>>>> specify setting and > >>>>>>>>>> processing accordingly. > >>>>>>>> > >>>>>>>> I'm not seeing the issue. Can you perhaps propose some text? > >>>>>>> > >>>>>>> Here is the proposed text > >>>>>>> > >>>>>>> "It is important to note that Section 4 defines association > >>>>>>> identification based on ASSOCIATION object matching, and > >>>>>>> that such matching is based on the comparison of the fields > >>>>>>> as determined by the ASSOCIATION Type of the ASSOCIATION > >>>>>>> object. This applies equally to ASSOCIATION objects and > >>>>>>> Extended ASSOCIATION objects." > >>>>>> > >>>>>> Here's the revised text. > >>>>>> Identification of association is not modified by this > >>>> section. It > >>>>>> is important to note that Section 4 defines association > >>>>>> identification based on ASSOCIATION object matching, > >>>> and that such > >>>>>> matching, in the absence of type-specific comparison > >> rules, is > >>>>>> based on the comparison of all fields in an > >> ASSOCIATION object. > >>>>>> This applies equally to ASSOCIATION objects and Extended > >>>>>> ASSOCIATION objects. > >>>>> > >>>>> I would write (look at the text just above where you state "As > >>>>> defined, these objects each contain an Association Source > >>>> field and a > >>>>> 16-bit Association ID field. As described above, the > >>>> contents of the > >>>>> object uniquely identifies an association." ... there > is a need to > >>>>> distinguish between identifying the ASSOCIATION object > vs matching > >>>>> ASSOCIATION objects). > >>>> > >>>> sure. But you need to be sure you're noting the difference > >> between the > >>>> word "association" and the thing "ASSOCIATION object". > >>> > >>> I am. > >>> > >>>>> This would > >>>>> > >>>>> "The procedure to perform ASSOCIATION object matching as > >> defined in > >>>>> Section 4 is not modified by this section. It is > important to note > >>>>> that Section 4 defines ASSOCIATION object matching if the > >>>> ASSOCIATION > >>>>> type does not refer to Association Type-specific rules for the > >>>>> processing of the ASSOCIATION object (in which case the > >> Association > >>>>> Type-specific rules SHALL be applied); otherwise, > >> ASSOCIATION object > >>>>> matching applies by comparing all fields in an > ASSOCIATION object. > >>>>> This procedure applies equally to ASSOCIATION objects > and Extended > >>>>> ASSOCIATION objects." > >>>> > >>>> one more time, revised text now reads: > >>>> The procedures related to association identification are not > >>>> modified by this section. It is important to note > >> that Section 4 > >>>> defines the identification of associations based on > ASSOCIATION > >>>> object matching and that such matching, in the absence of > >>>> type-specific comparison rules, is based on the > >> comparison of all > >>>> fields in an ASSOCIATION object. This applies equally to > >>>> ASSOCIATION objects and Extended ASSOCIATION objects. > >>> > >>> I would state "in the absence of type-specific comparison > rules (for > >>> the Type value of the object being processed), is based on the > >>> comparison of all fields in an ASSOCIATION object." > >>> > >>> because absence of rules is a generic statement. > >> > >> Again, I don't see the difference in meaning -- I think > we're in the > >> domain of style here. > > > > > > The problem with your statement is: there is no (absence) > > type-specific rule then apply full matching > > > > Mine it is either the one or the other. > > This is informative text (at this point). I also think it > says the same > thing. > > > > > > >>>>>>>>>> - Section 4.2: shouldn't "error processing" being > >> documented ? > >>>>>>>> > >>>>>>>> Here too, I think the only error processing is as > >>>> discussed above. > >>>>>>>> Shout if you think otherwise. > >>>>>>>> > >>>>>>>>>> Example include > >>>>>>>>>> admission control where receiving node rejects the > >>>>>>>> incoming Path msg if the > >>>>>>>>>> originating Global_ID/Ext.ASSOCIATION object isn't > included, > >>>>>>>> > >>>>>>>> Interesting, but this is a type specific error. To me this > >>>>>>>> sounds like > >>>>>>>> a new admission control error that should be defined as > >>>> part of the > >>>>>>>> type-specific definition. > >>>>>>> > >>>>>>> Admission control failures are part of the error codes > >>>>>> defined in RFC 2205. > >>>>>> > >>>>>> exactly! > >>>>>> > >>>>>>>>>> unauthorized > >>>>>>>>>> Global ID ? > >>>>>>>> > >>>>>>>> Again interesting, but this is a new policy (and policy > >>>> error) that > >>>>>>>> wasn't proposed or discussed in the WG. I think this > >>>>>> would be a fine > >>>>>>>> addition, but is beyond the current document discussion. It > >>>>>>>> could always be added if proposed. > >>>>>>> > >>>>>>> I defer this point to the AD. > >>>>>> > >>>>>> WFM. > >>>>>> > >>>>>>> > >>>>>>>>>> etc. but also mismatches between Association source > >> and Global > >>>>>>>>>> Association source ? > >>>>>>>> > >>>>>>>> How would such a thing be detected, by checking BGP state? > >>>>>> I guess we > >>>>>>>> could add a new error code, but again I think we're going > >>>>>> beyond the > >>>>>>>> intent of the document/WG. > >>>>>>> > >>>>>>> Same here. > >>>>>>> > >>>>>>>>>> - Section 4.1 and 4.2: the former states "The [RFC6370] > >>>>>>>> defined global > >>>>>>>>> identifier, > >>>>>>>>>> or Global_ID, is based on [RFC5003] and includes the > >>>>>>>> operator's Autonomous > >>>>>>>>>> System Number (ASN)." while the latter "the use of the > >>>>>>>> Global_ID is not > >>>>>>>>> related > >>>>>>>>>> to the use of the ASN in protocols such as BGP." which one > >>>>>>>> applies ? > >>>>>>>> > >>>>>>>> I'll drop the note. This is better aligned with the field > >>>>>> definition > >>>>>>>> which has been updated based on comments of other reviewers. > >>>>>>>> > >>>>>>>> The current definition is: > >>>>>>>> > >>>>>>>> This field contains a value that is a unique global > >>>>>> identifier or > >>>>>>>> the special value zero (0). When non-zero and not > >>>>>> overridden by > >>>>>>>> local policy, the Global_ID as defined in [RFC6370] > >>>>>> SHALL be used. > >>>>>>>> The special value of zero indicates that no global > >>>>>> identifier is > >>>>>>>> present. Use of the special value of zero SHOULD be > >>>> limited to > >>>>>>>> entities contained within a single operator. > >>>>>>> > >>>>>>> OK > >>>>>>> > >>>>>>>>>> - Section 5 Documenting means to prevent/mitigate > >>>>>>>> mis-association(s) and > >>>>>>>>>> possible impact on security would be advisable. If this is > >>>>>>>> felt to be > >>>>>>>>> "application" or > >>>>>>>>>> "type" specific a recommendation should be stated that the > >>>>>>>> security mechanisms > >>>>>>>>>> have to be documented as part of these documents. > >>>>>>>> > >>>>>>>> Why is there any additional risk than what " was > >>>>>> previously defined in > >>>>>>>> [RFC4872] and [RFC4873]."? (as is already stated in > the draft.) > >>>>>>> > >>>>>>> I try to prevent that any further use/documents would > state "no > >>>>>>> additional risk compared to RFC 4872 and RFC 4873" or > >>>> equivalent but > >>>>>>> the application is running for voice calls over the > >>>>>> Internet which is > >>>>>>> a totally different application than G/MPLS Recovery/Resource > >>>>>>> Sharing. > >>>>>> > >>>>>> Fair enough, but what additional issues do you foresee > >>>> that should be > >>>>>> covered? > >>>>> > >>>>> Nodes associating sessions, etc. should have the mean to > >> verify the > >>>> initiator of the association. > >>>> > >>>> This is true for every object in RSVP! I have no > >> objection to object > >>>> signing, ala SIDR, but this is well beyond the scope of > >> this document > >>>> and certainly isn't introduced in this document. > >>> > >>> We have to bring this point the Security directorate and > >> ask them for > >>> guidance (there could be a short term and a long term approach). I > >>> understand the corresponding generic mechanism to perform such > >>> verification isn't to be documented here but it has to be > mentioned. > >>> We loose track of all these security holes... hackers don't. > >> > >> RSVP's chain of trust is called out in RFC5920, which is > reference by > >> this draft. I certainly have no issue with a general discussion on > >> RSVP's chain of trust model, but the scope of this conversation is > >> beyond (and should be scoped) to this draft. > > > > > > Can you point which section of that RFC you are referring > to that would help the reader. > > > > I am asking because I didn't find any that speaks about > ASSOCIATION object. > > Again, the association object is defined in [RFC4872] not > this document. > I'll add a reference to "chain of trust model". > > Lou > > PS I'll submit the draft in a couple of minutes. > > > > > > >> Thanks, > >> Lou > >> > >>> > >>> OK for the rest. We are nearly done. > >>> > >>> Thanks, > >>> -dimitri. > >>>>>>>>>> Editorials: > >>>>>>>>>> > >>>>>>>>>> - Introduction: "This document expands the possible usage > >>>>>>>> of the ASSOCIATION > >>>>>>>>>> object to > >>>>>>>>>> non-GMPLS and non-recovery contexts." Suggested to state > >>>>>>>> the actual the > >>>>>>>>>> scope includes RSVP (instead of what it is not) > >>>>>>>> > >>>>>>>> I'll add: > >>>>>>>> The expanded usage applies equally to GMPLS LSPs > >>>> [RFC3473], MPLS > >>>>>>>> LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], > >> [RFC2207], > >>>>>>>> [RFC3175] and [RFC4860]. > >>>>>>> > >>>>>>> OK. > >>>>>>> > >>>>>>>>>> - Introduction: s/different ports/different destination > >>>>>> (dst) ports > >>>>>>>>>> > >>>>>>>> > >>>>>>>> sure. > >>>>>>>> > >>>>>>>>>> - Section 2 would better refer to a "Generalization" > >>>>>> rather than a > >>>>>>>>> "modification" > >>>>>>>>>> > >>>>>>>> > >>>>>>>> I'd be okay with this, but I think modification makes is less > >>>>>>>> likely to be misinterpreted so will leave as is. > >>>>>>> > >>>>>>> The term modification implies a change in existing > >>>> processing (even > >>>>>>> if the intention is different) and actually as the > >>>> applicability is > >>>>>>> now possible to RSVP and MPLS-TE. > >>>>>> > >>>>>> This isn't a major point for me, so will change it. (In > >> 5 places.) > >>>>> > >>>>> OK (actually the doc. generalizes the use of the object > >> whereas 4873 > >>>> for inst documents type-specific/specialized use of the object) > >>>>> > >>>>>>>>>> - Section 3 states "As defined by [RFC4872] and reviewed > >>>>>>>> in [RFC6689],..." but > >>>>>>>>> an > >>>>>>>>>> information RFC doesn't review at best "documents" > >>>>>>>> certain usage. This > >>>>>>>>>> statement is repeated at multiple places. > >>>>>>>> > >>>>>>>> Why can't it review? This is what the abstract of RFC6689 > >>>>>>>> says it does. > >>>>>>> > >>>>>>> It was overstated in RFC 6689. > >>>>>> > >>>>>> This document doesn't change 6689. > >>>>> > >>>>> OK. > >>>>> > >>>>>>>>>> - Section 3 mentions "Object usage in both Path and Resv > >>>>>>>> messages is > >>>>>>>>> discussed. > >>>>>>>>>> The usage applies equally to > >>>>>>>>>> GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP > >>>>>>>> RSVP sessions > >>>>>>>>>> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having > >>>>>>>> such statement in the > >>>>>>>>>> introduction would desirable. > >>>>>>>> > >>>>>>>> Fair enough. > >>>>>>>> > >>>>>>>> Thank you for the review! > >>>>>>> > >>>>>>> OK. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> -d. > >>>>>> > >>>>>> Thanks, > >>>>>> Lou > >>>>> > >>>>> Thanks, > >>>>> -d. > >>>> > >>>> Thanks again. > >>>> > >>>> Lou > >>>> > >>>> PS I'll submit a revised version of the draft at some > >> point today to > >>>> document all changes to date. > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > > > > > > > > > From adrian@olddog.co.uk Thu Sep 6 06:25:19 2012 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 F356B21F855E for ; Thu, 6 Sep 2012 06:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 wPc99To+YYJG for ; Thu, 6 Sep 2012 06:25:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DAFBD21F8522 for ; Thu, 6 Sep 2012 06:25:17 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q86DPGZ0000313 for ; Thu, 6 Sep 2012 14:25:16 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q86DPFTq000303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Sep 2012 14:25:16 +0100 From: "Adrian Farrel" To: References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> In-Reply-To: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> Date: Thu, 6 Sep 2012 14:25:14 +0100 Message-ID: <007201cd8c33$0d5f42e0$281dc8a0$@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: AQCU0KaXJKHmM9mNAaVFVLZokpLSBZnuxDfw Content-Language: en-gb Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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: Thu, 06 Sep 2012 13:25:19 -0000 Well, I didn't give much time for a response here, but I think this is a slam-dunk (whatever one of those is - perhaps one of the cousins could explain). I will add text to the Directorate charter encouraging reviews to be copied to the WG "unless there is a good reason why not, for example if they contain particularly sensitive information or opinions". Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 04 September 2012 21:38 > To: rtg-dir@ietf.org > Subject: [RTG-DIR] Recipients of Routing Directorate Reviews > > Hi, > > The current Routing Directorate charter includes a template for review that > suggests recipients... > > >

    Routing Directorate Review Template

    > >

    To: >

  • rtg-ads@tools.ietf.org
    • >

    Cc: >

  • rtg-dir@ietf.org;
    • >
  • draft-name.all@tools.ietf.org;
    • >

    Subject: >

  • RtgDir review: draft-name-version.txt
    • > > > It seems reasonable to expose the reviews and subsequent discussions to the > WG. > Would anyone object to us adding ... > >
  • wg-mailing-list
    • > > to the cc list? > > I can see two problems with this... > > 1. A little research is needed to work out the WG mailing list name because they > are not all perfectly intuitive. I don't think this is beyond your capabilities > to handle. > > 2. Not all reviewers will be members of the WG lists and signing up is both a > pain and risks a DoS on your inbox. However, all lists have moderators and they > should be able to admit your messages for the short exchange that will follow. > > Thoughts? > > Adrian > > From jdrake@juniper.net Thu Sep 6 07:54:28 2012 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 9D84421F86B3 for ; Thu, 6 Sep 2012 07:54:28 -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 hC5U71R4PBup for ; Thu, 6 Sep 2012 07:54:28 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1820921F869F for ; Thu, 6 Sep 2012 07:54:28 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUEi5Isi81ncWjN9+ORNh5ff7BEKJIjfK@postini.com; Thu, 06 Sep 2012 07:54:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::3c95:ce07:f642:ecd2%10]) with mapi; Thu, 6 Sep 2012 07:51:39 -0700 From: John E Drake To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Date: Thu, 6 Sep 2012 07:51:38 -0700 Thread-Topic: [RTG-DIR] Recipients of Routing Directorate Reviews Thread-Index: AQCU0KaXJKHmM9mNAaVFVLZokpLSBZnuxDfwgAAYpnA= Message-ID: <5E893DB832F57341992548CDBB333163A632DA3FFC@EMBX01-HQ.jnpr.net> References: <029f01cd8add$31b62ac0$95228040$@olddog.co.uk> <007201cd8c33$0d5f42e0$281dc8a0$@olddog.co.uk> In-Reply-To: <007201cd8c33$0d5f42e0$281dc8a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews 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: Thu, 06 Sep 2012 14:54:28 -0000 Lead-pipe cinch? Yours irrespectively, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Adrian Farrel > Sent: Thursday, September 06, 2012 6:25 AM > To: rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Recipients of Routing Directorate Reviews >=20 > Well, I didn't give much time for a response here, but I think this is > a slam-dunk (whatever one of those is - perhaps one of the cousins > could explain). >=20 > I will add text to the Directorate charter encouraging reviews to be > copied to the WG "unless there is a good reason why not, for example if > they contain particularly sensitive information or opinions". >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > > Behalf Of Adrian Farrel > > Sent: 04 September 2012 21:38 > > To: rtg-dir@ietf.org > > Subject: [RTG-DIR] Recipients of Routing Directorate Reviews > > > > Hi, > > > > The current Routing Directorate charter includes a template for > review > > that suggests recipients... > > > > > >

    Routing Directorate Review Template

    > > > >

    To: > >

  • rtg-ads@tools.ietf.org
    • > >

    Cc: > >

  • rtg-dir@ietf.org;
    • > >
  • draft-name.all@tools.ietf.org;
    • > >

    Subject: > >

  • RtgDir review: draft-name-version.txt
    • > > > > > > It seems reasonable to expose the reviews and subsequent discussions > > to the WG. > > Would anyone object to us adding ... > > > >
  • wg-mailing-list
    • > > > > to the cc list? > > > > I can see two problems with this... > > > > 1. A little research is needed to work out the WG mailing list name > > because > they > > are not all perfectly intuitive. I don't think this is beyond your > capabilities > > to handle. > > > > 2. Not all reviewers will be members of the WG lists and signing up > is > > both a pain and risks a DoS on your inbox. However, all lists have > > moderators and > they > > should be able to admit your messages for the short exchange that > will follow. > > > > Thoughts? > > > > Adrian > > > > >=20 From rcallon@juniper.net Thu Sep 6 21:39:50 2012 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 E58CC21E8050; Thu, 6 Sep 2012 21:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, 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 Gl0f59Z19b6l; Thu, 6 Sep 2012 21:39:47 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 58CCB21E805A; Thu, 6 Sep 2012 21:39:42 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUEl6jaaYFLWdch9PDcJsUoNPavmhgufE@postini.com; Thu, 06 Sep 2012 21:39:46 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 6 Sep 2012 21:36:22 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 7 Sep 2012 00:36:22 -0400 From: Ross Callon To: "rtg-ads@tools.ietf.org" , "sprevidi@cisco.com" , "ginsberg@cisco.com" , "imc.shand@googlemail.com" , "akr@cisco.com" , "wardd@cisco.com" Date: Fri, 7 Sep 2012 00:36:21 -0400 Thread-Topic: RtgDir review: draft-ietf-isis-mi-06 Thread-Index: Ac2MslRxcto44tp8Q/yaJe8oW/uI8Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EBFFDF95EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Ross Callon , "rtg-dir@ietf.org" , "isis-wg@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06 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, 07 Sep 2012 04:39:51 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C7EBFFDF95EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-isis-mi-06 Reviewer: Ross Callon Review Date: September 6, 2012 Intended Status: Standards Track Summary: I have minor concerns about this document that I think should be resolved b= efore publication. Comments: On the most part the document is well written and very readable, and is nea= rly ready for publication. I have one minor issue which should be resolved = prior to publication, a question, and a few nits. Major Issues: None Minor Issues: I found the manner in which this document supports multi-topology routing w= ithin an single instance to be confusing and probably underspecified. The r= elationship with RFC 5120 is part of this issue. The text in section 1 was = not particularly helpful and I had to read all of both documents to figure = out what the relationship is - and am still not sure that I got it right. Considering the following paragraphs from section 1: A given instance MAY support multiple topologies. Each topology is associated with a unique LSDB and a topology specific IS-IS Update Process. This differs from [RFC5120= ] where a single LSDB/single IS-IS Update Process is used in support of all topologies. MI-IS-IS might be used to support topology specific routing. When used for this purpose it is an alternative to [RFC5120]. The second of these two paragraphs seems straightforward to understand: If = you want to support multiple topologies, one option is to use a separate in= dependent instance for each topology. This use case is explicitly described= in section 3.1 and is intuitively straightforward. The first of these two paragraphs is not clear. There is more description i= n sections 2.5, 3.2, 3.3, and 4 which help significantly. However, section = 3 is "Usage Guidelines", and as such does not seem to be the right place to= include a rigorous description of how flooding is to occur when multiple t= opologies are supported with a single instance (nor does it seem to contain= a rigorous description). This document does not claim to obsolete RFC 5120. Thus for the standard in= stance (#0) it would seem that the same approach defined in 5120 needs to b= e used without any change, at least for interoperability with older impleme= ntations that support 5120 and do not support this draft. This would seem t= o contradict the first paragraph above -- or at least require slightly diff= erent wording of this paragraph. The document should clearly state whether = the standard instance (#0) uses the method in RFC 5120 for support of multi= ple topologies (which seems likely, for example since the IID-TLV's are not= carried in the standard instance). I think that this document should say up front (section 1) that it defines = a new method for supporting multiple topologies, which can be done either w= ithin multiple instances or within a single instance -- it might also menti= on in section 1 that for backward compatibility the approach in RFC 5120 i= s used in IID zero. It looks to me that section 2.5 could be enhanced to cl= arify operation when multiple topologies are supported within a single inst= ance. It should clearly state whether any one LSP contains only information= specific to a particular IID and ITID (this is my interpretation of the fi= rst sentence of 2.5). I also infer from the first sentence of 2.5 that eac= h LSP contains information for a single IID and a single ITID, encoded usin= g the TLV defined in section 2.1, and the LSP is flooded only among routers= that support that IID/ITID combination. Thus if I am reading this correctl= y then when occurring in an LSP the IID TLV MUST contain only one ITID valu= e (although I also expect that some physical links may want to be shared by= multiple topologies, and whether they have to be separately listed in mult= iple LSPs, one per topology, or if they could be described in a single LSP = that is associated with multiple ITID's). I think that this needs to be mad= e clearer. Also a question: Section 2.6.1 describes the use of two new dedicated layer= 2 multicast addresses: An MI-RTR will use two new (TBD) dedicated layer 2 multicast addresses (one for each level) when sending IS-IS PDUs for any non-zero IID. I am wondering whether or not this should be mentioned in the IANA section = (it is not currently). This seems like something that someone needs to get = assigned, but it is not obvious to me whether the IANA is involved in this. Nits: >> Last sentence of section 2.1: A PDU without an IID-TLV is assumed to belong to the standard instance (#0). I don't think that "is assumed" is quite the right terminology. A PDU witho= ut an IID-TLV by definition does belong to the standard instance (#0). Thus= , how about: A PDU without an IID-TLV belongs to the standard instance (#0). >> section 2.6.1, first bullet item (describing PDUs that MUST be discarded= ): o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV Elsewhere it says that the IID-TLV with a value of zero MUST NOT be include= d except as specified in this document. As such this comment is very minor:= However, wouldn't it be more precise and/or more flexible for future exten= sions to reword this bullet item as: o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV with a non-zero IID --_000_DF7F294AF4153D498141CBEFADB17704C7EBFFDF95EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
    I have been selected a= s 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 assis= tance to the Routing ADs. For more information about the Routing Directorat= e, please see http://www.ie= tf.org/iesg/directorate/routing.html
    Although these comment= s 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 r= eceive, and strive to resolve them through discussion or by updating the draft.
    Document: draft-ietf-i= sis-mi-06
    Reviewer: Ross Callon
    Review Date: September 6, 2012
    Intended Status: Standards Track
    Summary:
    I have minor concerns = about this document that I think should be resolved before publication.
    Comments:
    On the most part the d= ocument is well written and very readable, and is nearly ready for publicat= ion. I have one minor issue which should be resolved prior to publication, = a question, and a few nits.
    Major Issues:&n= bsp; None
    Minor Issues:
    I found the manner in wh= ich this document supports multi-topology routing within an single instance= to be confusing and probably underspecified. The relationship with RFC 512= 0 is part of this issue. The text in section 1 was not particularly helpful and I had to read all of both docume= nts to figure out what the relationship is – and am still not sure th= at I got it right.
     
    Considering the followin= g paragraphs from section 1:
     
       A given = instance MAY support multiple topologies.  Each topology is
       associat= ed with a unique LSDB and a topology specific IS-IS Update
       Process.=   This differs from [RFC5120] where a single LSDB/single=
       IS-IS Up= date Process is used in support of all topologies.
     
      MI-IS-IS migh= t be used to support topology specific routing.  When
       used for= this purpose it is an alternative to [RFC5120].
     
    The second of these two = paragraphs seems straightforward to understand: If you want to support mult= iple topologies, one option is to use a separate independent instance for e= ach topology. This use case is explicitly described in section 3.1 and is intuitively straightforward.
     
    The first of these two p= aragraphs is not clear. There is more description in sections 2.5, 3.2, 3.3= , and 4 which help significantly. However, section 3 is “Usage Guidel= ines”, and as such does not seem to be the right place to include a rigorous description of how flooding is to occur w= hen multiple topologies are supported with a single instance (nor does it s= eem to contain a rigorous description).
     
    This document does not c= laim to obsolete RFC 5120. Thus for the standard instance (#0) it would see= m that the same approach defined in 5120 needs to be used without any chang= e, at least for interoperability with older implementations that support 5120 and do not support this draft. This= would seem to contradict the first paragraph above -- or at least require = slightly different wording of this paragraph. The document should clearly s= tate whether the standard instance (#0) uses the method in RFC 5120 for support of multiple topologies (which = seems likely, for example since the IID-TLV’s are not carried in the = standard instance).
     
    I think that this docume= nt should say up front (section 1) that it defines a new method for support= ing multiple topologies, which can be done either within multiple instances= or within a single instance -- it might also mention in section 1 that for backward compatibility the approach in&n= bsp; RFC 5120 is used in IID zero. It looks to me that section 2.5 could be= enhanced to clarify operation when multiple topologies are supported withi= n a single instance. It should clearly state whether any one LSP contains only information specific to a particula= r IID and ITID (this is my interpretation of the first sentence of 2.5).&nb= sp; I also infer from the first sentence of 2.5 that each LSP contains info= rmation for a single IID and a single ITID, encoded using the TLV defined in section 2.1, and the LSP is flooded = only among routers that support that IID/ITID combination. Thus if I am rea= ding this correctly then when occurring in an LSP the IID TLV MUST contain = only one ITID value (although I also expect that some physical links may want to be shared by multiple topo= logies, and whether they have to be separately listed in multiple LSPs, one= per topology, or if they could be described in a single LSP that is associ= ated with multiple ITID’s). I think that this needs to be made clearer.
     
    Also a question: Section= 2.6.1 describes the use of two new dedicated layer 2 multicast addresses:<= /font>
     
       An MI-RT= R will use two new (TBD) dedicated layer
       2 multic= ast addresses (one for each level) when sending IS-IS PDUs
       for any = non-zero IID.
     
    I am wondering whether o= r not this should be mentioned in the IANA section (it is not currently). T= his seems like something that someone needs to get assigned, but it is not = obvious to me whether the IANA is involved in this.
     
    Nits:
    >> Last sentence o= f section 2.1:
     
       A PDU wi= thout an IID-TLV is assumed to belong to the standard
       instance= (#0).
     
    I don’t think that= “is assumed” is quite the right terminology. A PDU without an = IID-TLV by definition does belong to the standard instance (#0). Thus, how = about:
     
       A PDU wi= thout an IID-TLV belongs to the standard instance (#0).
     
    >> section 2.6.1, = first bullet item (describing PDUs that MUST be discarded):
     
      o  The de= stination multicast address is AllL1IS or AllL2IS and the
       &nb= sp;  PDU contains an IID-TLV
     
    Elsewhere it says that t= he IID-TLV with a value of zero MUST NOT be included except as specified in= this document. As such this comment is very minor: However, wouldn’t= it be more precise and/or more flexible for future extensions to reword this  bullet item as:
     
       o  = The destination multicast address is AllL1IS or AllL2IS and the
       &nb= sp;  PDU contains an IID-TLV with a non-zero IID
     
     
     
     
     --_000_DF7F294AF4153D498141CBEFADB17704C7EBFFDF95EMBX01WFjnprn_-- From ginsberg@cisco.com Sun Sep 9 21:59:19 2012 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 A6AAD21F84F5; Sun, 9 Sep 2012 21:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 DpGHnb2ev5Ls; Sun, 9 Sep 2012 21:59:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EE3B021F84EF; Sun, 9 Sep 2012 21:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52172; q=dns/txt; s=iport; t=1347253143; x=1348462743; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MOPbWFHVNO7tBZu3bPEoXhxxXqmix6pESKa26JT9Wdc=; b=Br/a1qkjZGQzEaL9lZMXq48DRgXgz+tpGSTqR5zOkUB0m5Nr/jhXI4+M cX2ATVrEGDg6yNoOQDlPrLmzolS/CjrwJ46DZv1rqYbvYvUPrTAIagAP2 Z6Mly0nAVRADmmQoouXcqS6PGLjwfOi/31JBPGkU9hAzoyWakbBO+TL8/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE5yTVCtJV2Y/2dsb2JhbABFgkuwJgGIXoEHgiABAQEDARIBBxM6CwcQAgEIDgMDAQEBCxYBBgcyFAkIAQEEAQ0FCAEZh1wDCQYLmm2VRw2JU4owY4VWYAOWcY0igWeCZg X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208,217";a="119854607" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 10 Sep 2012 04:59:01 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8A4x0Hv019205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Sep 2012 04:59:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.253]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Sun, 9 Sep 2012 23:58:59 -0500 From: "Les Ginsberg (ginsberg)" To: Ross Callon , "rtg-ads@tools.ietf.org" , "Stefano Previdi (sprevidi)" , "imc.shand@googlemail.com" , "Abhay Roy (akr)" , "David Ward (wardd)" Thread-Topic: RtgDir review: draft-ietf-isis-mi-06 Thread-Index: Ac2MslRxcto44tp8Q/yaJe8oW/uI8QCVPvBg Date: Mon, 10 Sep 2012 04:58:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.88] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.001 x-tm-as-result: No--55.276300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F117CA1AExmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "isis-wg@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06 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, 10 Sep 2012 04:59:20 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F117CA1AExmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross - Thank you for the review. I will respond inline to each of your points below - however I want to pref= ace my responses by saying that it concerns me that the document is not cle= ar to you as regards multi-topology routing support and the relationship to= RFC 5120. We tried in a number of ways to be clear about this (as I will p= oint out below) - but given that you still are confused on some points it s= eems that we did not succeed. I therefore believe the text requires revisio= n - though at this moment I am not certain as to what changes will resolve = all the ambiguities that presented themselves to you. I hope you will work = with us in trying to find better wording. I'll do my best to indicate below= where I think rewording may help and where your help may be needed as I do= n't know what rewording will resolve the issues you raise. Please see LES: inline. From: Ross Callon [mailto:rcallon@juniper.net] Sent: Thursday, September 06, 2012 9:36 PM To: rtg-ads@tools.ietf.org; Stefano Previdi (sprevidi); Les Ginsberg (ginsb= erg); imc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd) Cc: isis-wg@ietf.org; rtg-dir@ietf.org; Ross Callon Subject: RtgDir review: draft-ietf-isis-mi-06 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-isis-mi-06 Reviewer: Ross Callon Review Date: September 6, 2012 Intended Status: Standards Track Summary: I have minor concerns about this document that I think should be resolved b= efore publication. Comments: On the most part the document is well written and very readable, and is nea= rly ready for publication. I have one minor issue which should be resolved = prior to publication, a question, and a few nits. Major Issues: None Minor Issues: I found the manner in which this document supports multi-topology routing w= ithin an single instance to be confusing and probably underspecified. The r= elationship with RFC 5120 is part of this issue. The text in section 1 was = not particularly helpful and I had to read all of both documents to figure = out what the relationship is - and am still not sure that I got it right. Considering the following paragraphs from section 1: A given instance MAY support multiple topologies. Each topology is associated with a unique LSDB and a topology specific IS-IS Update Process. This differs from [RFC5120= ] where a single LSDB/single IS-IS Update Process is used in support of all topologies. MI-IS-IS might be used to support topology specific routing. When used for this purpose it is an alternative to [RFC5120]. The second of these two paragraphs seems straightforward to understand: If = you want to support multiple topologies, one option is to use a separate in= dependent instance for each topology. This use case is explicitly described= in section 3.1 and is intuitively straightforward. LES: It is possible to create separate instances (i.e. unique IID values) o= n a per topology basis. In such a case each topology will have a 1-1 relati= onship with the instance, will have a unique IID value, will have instance= specific adjacencies, and an instance specific LSDB. However, it is also p= ossible to support multiple topologies within a single non-zero instance. I= n this case a set of topologies share an instance specific adjacency (based= on IID value) but do NOT share the LSDB. The LSDB is scoped by the IID/IT= ID pair. This is the concept the first paragraph you quote above is introdu= cing. Section 2 (third paragraph) goes on to state: "MI-RTRs support the exchange of topology specific Link State PDUs for the IID/ITID pairs that each neighbor supports. A unique IS-IS Update process [see IS-IS] operates for each IID/ITID pair." I am not sure how to be more clear about this. The first of these two paragraphs is not clear. There is more description i= n sections 2.5, 3.2, 3.3, and 4 which help significantly. However, section = 3 is "Usage Guidelines", and as such does not seem to be the right place to= include a rigorous description of how flooding is to occur when multiple t= opologies are supported with a single instance (nor does it seem to contain= a rigorous description). LES: Section 2 is intended to be the normative specification. Section 2.5 s= pecifically is the normative specification of how the Update process opera= tes. Section 3 is intended to clarify through discussion of some example use cas= es. Which is why the second paragraph of Section 3 states: "The following sub-sections provide some guidelines for usage of instances and topologies within each instance. While this represents examples based on the intent of the authors, implementors are not constrained by the examples." I believe Section 2 to be complete - and Section 3 could be omitted entirel= y without loss of completeness. However, it was the consensus of the author= s that Section 3 was needed to clarify how the protocol extensions might be= used by way of examples. I am not sure how to be more clear about this. This document does not claim to obsolete RFC 5120. LES: This is correct. RFC 5120 is not changed in any way by this document -= nor do we propose that RFC 5120 should no longer be used/supported. Thus for the standard instance (#0) it would seem that the same approach de= fined in 5120 needs to be used without any change, at least for interoperab= ility with older implementations that support 5120 and do not support this = draft. This would seem to contradict the first paragraph above -- or at lea= st require slightly different wording of this paragraph. The document shoul= d clearly state whether the standard instance (#0) uses the method in RFC 5= 120 for support of multiple topologies (which seems likely, for example sin= ce the IID-TLV's are not carried in the standard instance). LES: The standard instance is not changed in any way by this document. Inde= ed, it is not possible to do so without introducing backwards compatibility= issues - which we have been careful to avoid. See Section 2.6. But I will = try to make this more clear in the Introduction. I think that this document should say up front (section 1) that it defines = a new method for supporting multiple topologies, which can be done either w= ithin multiple instances or within a single instance -- it might also menti= on in section 1 that for backward compatibility the approach in RFC 5120 i= s used in IID zero. LES: This is NOT the intent of the document. The draft defines two new prot= ocol capabilities: 1)Overcoming the existing limitation that one and only one instance of the = protocol can be run on a given circuit. 2)Within a given non-zero(sic) instance support a topology specific update = process. The first of these two points is clearly stated in the Introduction. The se= cond point I think is less clear - I will reword the introduction to make t= hat point clearer. But it is decidedly NOT our intent to suggest that RFC 5120 should be repla= ced. It looks to me that section 2.5 could be enhanced to clarify operation when= multiple topologies are supported within a single instance. It should clea= rly state whether any one LSP contains only information specific to a parti= cular IID and ITID (this is my interpretation of the first sentence of 2.5)= . I also infer from the first sentence of 2.5 that each LSP contains informat= ion for a single IID and a single ITID, encoded using the TLV defined in se= ction 2.1, and the LSP is flooded only among routers that support that IID/= ITID combination. Thus if I am reading this correctly then when occurring i= n an LSP the IID TLV MUST contain only one ITID value (although I also expe= ct that some physical links may want to be shared by multiple topologies, a= nd whether they have to be separately listed in multiple LSPs, one per topo= logy, or if they could be described in a single LSP that is associated with= multiple ITID's). I think that this needs to be made clearer. LES: Section 2 states " MI-RTRs support the exchange of topology specific Link State PDUs for the IID/ITID pairs that each neighbor supports. A unique IS-IS Update process [see IS-IS] operates for each IID/ITID pair." Section 2.1 states: "When the IID is non-zero and the TLV appears in an SNP or LSP, exactly one ITID MUST be present indicating the topology with which the PDU is associated." Although this seems unambiguous to me and has language that specifically ad= dresses the points you raise, your confusion suggests we need some rewordin= g - but I am not sure how to be more clear. Also a question: Section 2.6.1 describes the use of two new dedicated layer= 2 multicast addresses: An MI-RTR will use two new (TBD) dedicated layer 2 multicast addresses (one for each level) when sending IS-IS PDUs for any non-zero IID. I am wondering whether or not this should be mentioned in the IANA section = (it is not currently). This seems like something that someone needs to get = assigned, but it is not obvious to me whether the IANA is involved in this. LES: Yes - this issue came up during the IANA review. Our intention is to o= btain the addresses from the IANA managed address space specified in RFC 53= 42. IANA has asked that we update the IANA section to reflect this - which = we intend to do. Nits: >> Last sentence of section 2.1: A PDU without an IID-TLV is assumed to belong to the standard instance (#0). I don't think that "is assumed" is quite the right terminology. A PDU witho= ut an IID-TLV by definition does belong to the standard instance (#0). Thus= , how about: A PDU without an IID-TLV belongs to the standard instance (#0). LES: OK >> section 2.6.1, first bullet item (describing PDUs that MUST be discarded= ): o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV Elsewhere it says that the IID-TLV with a value of zero MUST NOT be include= d except as specified in this document. As such this comment is very minor:= However, wouldn't it be more precise and/or more flexible for future exten= sions to reword this bullet item as: o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV with a non-zero IID LES: No. The only exception to the rule that an instance #0 PDU NOT contain= the IID-TLV is in the case of P2P IIHs as described in Section 2.6.2. As S= ection 2.6.1 is talking about operation on a broadcast circuit we are inten= tionally saying there MUST NOT be an IID-TLV at all (even w IID value #0) i= n such a PDU. I will however make this more clear - especially in the context of P2P oper= ation over broadcast media (RFC 5309). Les --_000_F3ADE4747C9E124B89F0ED2180CC814F117CA1AExmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Ross –

     <= /p>

    Thank you for the review.=

     <= /p>

    I will respond inline to = each of your points below – however I want to preface my responses by= saying that it concerns me that the document is not clear to you as regards multi-topology routing support and the relationship to RFC = 5120. We tried in a number of ways to be clear about this (as I will point = out below) – but given that you still are confused on some points it = seems that we did not succeed. I therefore believe the text requires revision – though at this moment I am not = certain as to what changes will resolve all the ambiguities that presented = themselves to you. I hope you will work with us in trying to find better wo= rding. I’ll do my best to indicate below where I think rewording may help and where your help may be needed as I do= n’t know what rewording will resolve the issues you raise.=

     <= /p>

    Please see LES: inline.

     <= /p>

    From: Ross Cal= lon [mailto:rcallon@juniper.net]
    Sent: Thursday, September 06, 2012 9:36 PM
    To: rtg-ads@tools.ietf.org; Stefano Previdi (sprevidi); Les Ginsberg= (ginsberg); imc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd)<= br> Cc: isis-wg@ietf.org; rtg-dir@ietf.org; Ross Callon
    Subject: RtgDir review: draft-ietf-isis-mi-06

     

    Hello,

    I have been selected as the Routing Dir= ectorate reviewer for this draft. The Routing Directorate seeks to review a= ll routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please see http://www.ie= tf.org/iesg/directorate/routing.html

    Although these comments are primarily f= or the use of the Routing ADs, it would be helpful if you could consider th= em 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-isis-mi-06
    Reviewer: Ross Callon
    Review Date: September 6, 2012
    Intended Status: Standards Track

    Summary:

    I have minor concerns about this docume= nt that I think should be resolved before publication.

    Comments:

    On the most part the document is well w= ritten and very readable, and is nearly ready for publication. I have one m= inor issue which should be resolved prior to publication, a question, and a few nits.

    Major Issues:  None

    Minor Issues:

    I found the manner in which this docume= nt supports multi-topology routing within an single instance to be confusin= g and probably underspecified. The relationship with RFC 5120 is part of this issue. The text in section 1 was not particularly hel= pful and I had to read all of both documents to figure out what the relatio= nship is – and am still not sure that I got it right.

     

    Considering the following paragraphs fr= om section 1:

     

       A given instance MAY support multiple topolog= ies.  Each topology is

       associated with a unique LSDB and a topology = specific IS-IS Update

       Process.  This differs from [RFC5120] where a single LSDB/single=

       IS-IS Update Process is used in support of al= l topologies.

     

      MI-IS-IS might be used to support topology specific= routing.  When

       used for this purpose it is an alternative to= [RFC5120].

    =  

    The second of these two paragraphs seem= s straightforward to understand: If you want to support multiple topologies= , one option is to use a separate independent instance for each topology. This use case is explicitly described in section 3.1 and is= intuitively straightforward.

     <= /p>

     

    LES: It is po= ssible to create separate instances (i.e. unique IID values) on a per topol= ogy basis. In such a case each topology will have a 1-1 relationship with the instance,  will have a unique IID value, will have instance = specific adjacencies, and an instance specific LSDB. However, it is also po= ssible to support multiple topologies within a single non-zero instance. In= this case a set of topologies share an instance specific adjacency (based on IID value) but do NOT share = the LSDB. The LSDB is scoped by the IID/ITID pair. This is the concept the= first paragraph you quote above is introducing. Section 2 (third paragraph= ) goes on to state:

     

    “MI-RTR= s support the exchange of topology specific Link State PDUs for<= /span>

       = the IID/ITID pairs that each neighbor supports.  A unique IS-IS

       = Update process [see IS-IS] operates for each IID/ITID pair.”

     

    I am not sure= how to be more clear about this.

     

    The f= irst of these two paragraphs is not clear. There is more description in sec= tions 2.5, 3.2, 3.3, and 4 which help significantly. However, section 3 is ̶= 0;Usage Guidelines”, and as such does not seem to be the right place = to include a rigorous description of how flooding is to occur when multiple= topologies are supported with a single instance (nor does it seem to contain a rigorous description).

     <= /p>

    LES: Section 2 is intende= d to be the normative specification. Section 2.5 specifically  is the normative = specification of how the Update process operates.

    Section 3 is intended to = clarify through discussion of some example use cases. Which is why the seco= nd paragraph of Section 3 states:

     <= /p>

    “The following sub-sections provide some guidelines for usage of<= o:p>

       instances and topologies within each instance.  While= this represents

       examples based on the intent of the authors, implementors = are not

       constrained = by the examples.”

     

    I believe Section 2 to be= complete – and Section 3 could be omitted entirely without loss of c= ompleteness. However, it was the consensus of the authors that Section 3 was needed to clarify how the protocol extensions might be used = by way of examples.

    I am not sure how to be m= ore clear about this.

     <= /p>

    This document does not claim to obsolet= e RFC 5120.

     <= /p>

    LES: This is correct. RFC= 5120 is not changed in any way by this document – nor do we propose = that RFC 5120 should no longer be used/supported.

     <= /p>

    Thus for the standard instance (#0) it = would seem that the same approach defined in 5120 needs to be used without = any change, at least for interoperability with older implementations that support 5120 and do not support this draft. This would seem to contra= dict the first paragraph above -- or at least require slightly different wo= rding of this paragraph. The document should clearly state whether the stan= dard instance (#0) uses the method in RFC 5120 for support of multiple topologies (which seems likely, for ex= ample since the IID-TLV’s are not carried in the standard instance).

     <= /p>

    LES: The standard instanc= e is not changed in any way by this document. Indeed, it is not possible to= do so without introducing backwards compatibility issues – which we have been careful to avoid. See Section 2.6. But I will t= ry to make this more clear in the Introduction.

     

    I think that this document should say u= p front (section 1) that it defines a new method for supporting multiple to= pologies, which can be done either within multiple instances or within a single instance -- it might also mention in section 1 that for= backward compatibility the approach in  RFC 5120 is used in IID zero.=

     <= /p>

    LES: This is NOT the inte= nt of the document. The draft defines two new protocol capabilities:

     <= /p>

    1)Overcoming the existing= limitation that one and only one instance of the protocol can be run on a = given circuit.

    2)Within a given non-zero= (sic) instance support a topology specific update process.

     <= /p>

    The first of these two po= ints is clearly stated in the Introduction. The second point I think is les= s clear – I will reword the introduction to make that point clearer.

    But it is decidedly NOT o= ur intent to suggest that RFC 5120 should be replaced.

     <= /p>

    It looks to me that section 2.5 could b= e enhanced to clarify operation when multiple topologies are supported with= in a single instance. It should clearly state whether any one LSP contains only information specific to a particular IID and ITID (t= his is my interpretation of the first sentence of 2.5). 

     <= /p>

    I also infer from the first sentence of= 2.5 that each LSP contains information for a single IID and a single ITID,= encoded using the TLV defined in section 2.1, and the LSP is flooded only among routers that support that IID/ITID combination. Thus= if I am reading this correctly then when occurring in an LSP the IID TLV M= UST contain only one ITID value (although I also expect that some physical = links may want to be shared by multiple topologies, and whether they have to be separately listed in multiple LSPs= , one per topology, or if they could be described in a single LSP that is a= ssociated with multiple ITID’s). I think that this needs to be made c= learer.

     

    LES:  Se= ction 2 states

     

    “ = MI-RTRs support the exchange of topology specific Link State PDUs for=

       = the IID/ITID pairs that each neighbor supports.  A unique IS-IS

       = Update process [see IS-IS] operates for each IID/ITID pair.”

     

    Section 2.1 s= tates:

     

      &= nbsp; “When the IID is non-zero and the TLV appears in an SNP or LSP,=

      &= nbsp;  exactly one ITID MUST be present indicating the topology with

      &= nbsp;  which the PDU is associated.”

     

    Although this= seems unambiguous to me and has language that specifically addresses the p= oints you raise, your confusion suggests we need some rewording – but I am not sure how to be more clear.

     

    Also a question: Section 2.6.1 describe= s the use of two new dedicated layer 2 multicast addresses:

     

       An MI-RTR will use two new (TBD) dedicated la= yer

       2 multicast addresses (one for each level) wh= en sending IS-IS PDUs

       for any non-zero IID.

    =  

    I am wondering whether or not this shou= ld be mentioned in the IANA section (it is not currently). This seems like = something that someone needs to get assigned, but it is not obvious to me whether the IANA is involved in this.

     

    LES: Yes – this iss= ue came up during the IANA review. Our intention is to obtain the addresses= from the IANA managed address space specified in RFC 5342. IANA has asked that we update the IANA section to reflect this – which we= intend to do.

     <= /p>

    Nits:

    >> Last sentence of section 2.1:<= /span>

     

       A PDU without an IID-TLV is assumed to belong= to the standard

       instance (#0).=

     

    I don’t think that “is assu= med” is quite the right terminology. A PDU without an IID-TLV by defi= nition does belong to the standard instance (#0). Thus, how about:

    =  

       A PDU without an IID-TLV belongs to the stand= ard instance (#0).

     <= /p>

    LES: OK=

     

    >> section 2.6.1, first bullet it= em (describing PDUs that MUST be discarded):=

    =  

      o  The destination multicast address is AllL1I= S or AllL2IS and the

          PDU contains an IID-TLV

     

    Elsewhere it says that the IID-TLV with= a value of zero MUST NOT be included except as specified in this document.= As such this comment is very minor: However, wouldn’t it be more precise and/or more flexible for future extensions to reword this&= nbsp; bullet item as:

    =  

       o  The destination multicast address is = AllL1IS or AllL2IS and the

          PDU contains an IID-TLV wit= h a non-zero IID

    =  

    LES: No. The only exception to the rule th= at an instance #0 PDU NOT contain the IID-TLV is in the case of P2P IIHs as= described in Section 2.6.2. As Section 2.6.1 is talking about operation on a broadcast circuit we are intentionally saying there MUST NOT be an IID-TLV at all (even w = IID value #0) in such a PDU.

     

    I will however make this more clear –= ; especially in the context of P2P operation over broadcast media (RFC 5309= ).

     

       Les

     

    --_000_F3ADE4747C9E124B89F0ED2180CC814F117CA1AExmbalnx02ciscoc_-- From gih@apnic.net Mon Sep 10 22:33:41 2012 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 8B67521F85B8; Mon, 10 Sep 2012 22:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, 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 snqhlI0+xdyu; Mon, 10 Sep 2012 22:33:40 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B421F8585; Mon, 10 Sep 2012 22:33:38 -0700 (PDT) Received: from [IPv6:2001:388:1000:110:84f0:5758:2a2e:63ee] (unknown [IPv6:2001:388:1000:110:84f0:5758:2a2e:63ee]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A8D4BB6894; Tue, 11 Sep 2012 15:33:36 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Sep 2012 15:33:36 +1000 Message-Id: To: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Cc: "rtg-dir@ietf.org" , draft-ietf-grow-ops-reqs-for-bgp-error-handling.all@tools.ietf.org, "grow@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-ops-reqs-for-bgp-error-handling 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, 11 Sep 2012 05:33:41 -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-grow-ope-reqs-for-bgp-error-handling-05.txt=20 Reviewer: Geoff Huston Review Date: 11 September 2012=20 IETF LC End Date: 13 September 2012=20 Intended Status: Informational Summary:=20 I have some major concerns about this document that I think should be = resolved before publication. I also have some minor concerns here that = also relate to the manner of expression of these requirements. I do not = have major concerns about the technical content of the requirements = described in this document. Comments:=20 This document is not clearly written and difficult to understand.=20 The requirements are scattered across voluminous text, which is = unhelpful. I would've preferred to read a document which managed to = enumerate the same requirements in under 8 pages of text, while the = current count of 28 pages appears to be consumed by prolix and = repetitive text that contributes neither to the precision of the = description of the requirements, nor to the description of the rationale = for the requirements. At its current length, and with its density of expression and level of = repetition I would suggest that's its utility to future readers is = unfortunately compromised. This is a shame, as within this is a = well-considered set of operational requirements for BGP error handling = buried within this document. Major Issues:=20 There is a major issue here in terms of the overall readability and a = lack in conciseness in expression and clear structuring of the subject = material in an organised and coherent manner. More specifically, I take issue with the classification approach used in = Section 2, and I am of the opinion that it chould be rewritten to aid = clarity and readability. I find it confusing to see "Critical" and = "Semantic" error classifications. It would make more sense to me to call = these categories "Critical" and "Non-Critical". I would also suggest to = use this classification to define the proposed handling - i.e. Critical = Errors are such that the BGP message framing has been lost, and it is = necessary to restart the session or undertake some other error handling = mechanism that would re-establish BGP message framing, and Non-Critical = Errors are such that BGP message framing has NOT been lost, and the = error recovery process can be managed though various forms of local = actions and potentially some form of additional BGP protocol-level = interaction that would not require a session tear-down to repair. I am also at a loss to understand the role of section 3 in this = requirements document. It appears to be making the case that the current = BGP error handling approach is ill-suited to operational requirements = and that different forms of error handling should be placed as = requirements for the protocol. I would conventionally expect to see = these arguments appear in section 1 of this document, as part of the = argument for the motivation for a new set of error handling = requirements. This is perhaps a specific instance of the previous = mentioned issue that this document could benefit from some careful = thought in the manner of the organisation of the presented material. I also note that Section 6, Operational Toolset for Monitoring BGP, = represents a scope creep for this document. My concern here is that any = general comments about monitoring BGP would not normally be expected to = be enumerated in a document that was intended to address the = requirements for BGP's handling of error conditions. I am not aware = whether the Working Group has considered the possibility of separately = addressing error handling and operational monitoring in two operational = requirements in distinct documents, but from my review of this document = it does appear that a case can be made here for this form of clear = delineation. In any case, I would suggest that the document would benefit from a = major revision that was focussed on a clear enumeration of the = requirements for error handling rather than the current document form of = a somewhat less structured collection of comments on the BGP = NOTIFICATION message and its current method of handling, comments on = existing work in progress on error handling approaches and mechanisms = and the inclusion of consideration of error handling scope, and the = considerations behind re-interpretation of certain forms of erroneous = UPDATES as implicit WITHDRAW messages. At present all these concepts = have been added into the document in a manner that tends to blur the = distinction between a description of the requirement itself and the = motivation for this requirement. Minor Issues:=20 last sentence of the abstract: namely the "overview of a set of = enhancements to BGP-4" is inconsistent with the document's purpose ass = represented in the title ("Requirements for Enhanced Error Handling = Behaviour") or in later parts of the document. Needs revision. Introduction: first sentence - "numerous incidents..." is imprecise and = uninformative - perhaps dropping this adjective would help here. Also in = this sentence I would suggest changing "due to the" to "as a consequence = of the".=20 Introduction: second sentence - "the deployments of the protocol have = changed within modern networks" does not parse for me. Is this intending = to say that some current implementatons of this protocol deviate from = from the standards-defined behaviour? Introduction: This entire section could be reduced by noting that "BGP's = current error handling behaviour, as defined in RFC 4271, define a = single error handling response, namely that of session reset. This = response has significant impacts within an operational environment. This = memo proposes a set of requirements for further refinement of the = standard behaviour for error handling in BGP." The reminder of the document would benefit considerably from a similar = editorial pass. It is simply way too prolix and this detracts from the = effectiveness of the document as a description of a set of requirements. section 1.1, first sentence "... are designed to be conducive to this = role" - frankly I have no idea what this means. Is it "consistent with = this role"? But even then it makes no sense. Indeed the first sentence = defeats me as to its intended purpose. Section 1.1, second sentence - there is some jarring imprecision here = that should be deleted - the "relatively small" amount of NLRI = information makes no sense to me as I am unsure to what this "relative" = comparison is being made. Section 1.1, third sentence. This sentence, "In this case, it is the = expectation.." is wordy and terribly expressed. I was thinking of ways = to say this more concisely, but may be it would be better to remove it = completely. =20 Section 1.1, last sentence. This sentence, about the expectation to be = able to use sub-optimal paths is a bit of a martian for me - the concept = is introduced here without warning and without context - I thought this = was a requirement for error handling specification document, and this = statement appears without clear context. Section 1.1, second paragraph - "Traditional network architectures _use_ = an..." Section 1.1, second paragraph - the author is implying that the = requirements for IGP and EGPs differ in terms of robustness. It would be = helpful it this claim was substiantiated in some manner in so far as = this reviewer does not see much of a difference at all - both protocols = have a very high requirement for robust operation from this reviewer's = perspective. Section 1.1, third paragraph - yes, BGP carries more information, but = the case that this augmented use provides justification for an altered = error handling is weak, and in my view superfluous to the document's = purpose. The previous paragraph provides adequate motivation and this = third paragraph appears to be another repetition of the basic assertion = that "BGP plays a critical role in network operation, and BGP error = handling should not cause a hiatus in the supply of information provided = by the operation of BGP."" Section 1.1, fourth paragraph appears to be saying that: "BGP systems = carry large volumes of information, and the time taken to recover from a = error-triggered session reset is now a significant factor in terms of = overall network robustness. Error handling approaches that limit the = scope of error recovery to those NLRIs mentioned in the erroneous BGP = UPDATE message should be considered within a requirement set for error = handling. It is possible to reduce section 1.1 to two paragraphs and a more = concise set of statements about the problems that the current = standards-defined error handling response pose to network operators. Section 1.2 - here the first sentence is a restatement of document's = purpose, already stated in the Abstract and in section 1 - there is no = need to restate it here. The rest of this section is again very wordy. = It may be worth considering a more concise restatement of these = requirements, namely that error handling should avoid the use of session = resets where possible, error handling should, where possible be limited = in scope to those NLRI UPDATEs that can be associated with the error = condition, and where session reset is considered to be unaviodable, = various foprms of more graceful session restart should be considered. = Furthermore, as a more general BGP requirement, the inclusion of = mechanisms to allow for operational monitoring of BGP should be stated = as an operational requirement. Section 2 - I have trouble parsing the structure of this section - = perhaps its because the first four paragraphs here are a more verbose = repetition of the information presented in sections 2.1.1 and 2.1.2. Section 3- paragraph 3 - I am confused by the purpose of the second half = of this paragraph, starting with the sentence beginning with "It should, = however, be considered if this view is valid..." The first half of the = paragraph is discussing the "treat as withdraw" in the context of iBGP, = but the second half of the paragraph does not appear to concludes this = discussion. Section 4 - paragraph 3 this is an example of an embedded "requirement" = that should be avoided. It would be far clearer to pull out all these = requirements and enumerate them and for each one outline concisely the = rationale for the requirement and its intended effect on the operation = of BGP.=20 Section 4 - paragraph 4 contains another example of this embedded = "requirement" Section 5 - paragraph 2 - This sentence: "Clearly, there is some utility = to this requirement, as error conditions in BGP are, in general, exited = from." What does this mean? I am at a bit of a loss in reading section = 5, as, once more, there are embedded "requirements" and a lot of = repetition of material from earlier sections. Nits:=20 Abstract, para 1, sentence 3 - s/strict/standards-defined/ and s/message = causing/message, causing/ Section 1.1, second paragraph ... "As such, BGP has become an IGP" is = better expressed as "As such, iBGP has become an IGP" Section 1.2 s/UPDATE packet/UPDATE message/ Section 2. first sentence - expand the first use of "DFZ" Section 2 - why does this document use "BGP-4" and "BGP"? - please pick = one term or the other. I suggest using "BGP" uniformly through the = document. From rcallon@juniper.net Wed Sep 12 10:44:57 2012 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 F0B8621F8692; Wed, 12 Sep 2012 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, 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 Dcgncclh3GXR; Wed, 12 Sep 2012 10:44:49 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id D5E8C21F869C; Wed, 12 Sep 2012 10:44:38 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUFDKBb2jQnJf3t50fnMMdPsAtIu9YZPq@postini.com; Wed, 12 Sep 2012 10:44:44 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Sep 2012 10:37:25 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Sep 2012 10:37:24 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 12 Sep 2012 13:37:21 -0400 From: Ross Callon To: "Les Ginsberg (ginsberg)" , "Stefano Previdi (sprevidi)" , "imc.shand@googlemail.com" , "Abhay Roy (akr)" , "David Ward (wardd)" Date: Wed, 12 Sep 2012 13:37:19 -0400 Thread-Topic: RtgDir review: draft-ietf-isis-mi-06 Thread-Index: Ac2MslRxcto44tp8Q/yaJe8oW/uI8QCVPvBgAIFhVcA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EC21BB36EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "isis-wg@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06 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, 12 Sep 2012 17:44:57 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C7EC21BB36EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reading through your response, it looks to me that resolving my comments wi= ll require relatively few changes to the draft (and probably no substantial= technical change), but might require several emails back and forth. Probab= ly it is most productive to have this exchange of emails off-line, and then= report the results to the larger lists. I will therefore reply in detail to the authors, with the understanding tha= t the three mailing lists CC'd above will need a summary of the results whe= n we are done. Thanks, Ross From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Monday, September 10, 2012 12:59 AM To: Ross Callon; rtg-ads@tools.ietf.org; Stefano Previdi (sprevidi); imc.sh= and@googlemail.com; Abhay Roy (akr); David Ward (wardd) Cc: isis-wg@ietf.org; rtg-dir@ietf.org Subject: RE: RtgDir review: draft-ietf-isis-mi-06 Ross - Thank you for the review. I will respond inline to each of your points below - however I want to pref= ace my responses by saying that it concerns me that the document is not cle= ar to you as regards multi-topology routing support and the relationship to= RFC 5120. We tried in a number of ways to be clear about this (as I will p= oint out below) - but given that you still are confused on some points it s= eems that we did not succeed. I therefore believe the text requires revisio= n - though at this moment I am not certain as to what changes will resolve = all the ambiguities that presented themselves to you. I hope you will work = with us in trying to find better wording. I'll do my best to indicate below= where I think rewording may help and where your help may be needed as I do= n't know what rewording will resolve the issues you raise. Please see LES: inline. From: Ross Callon [mailto:rcallon@juniper.net] Sent: Thursday, September 06, 2012 9:36 PM To: rtg-ads@tools.ietf.org; Stefano Previdi = (sprevidi); Les Ginsberg (ginsberg); imc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd) Cc: isis-wg@ietf.org; rtg-dir@ietf.org; Ross Callon Subject: RtgDir review: draft-ietf-isis-mi-06 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-isis-mi-06 Reviewer: Ross Callon Review Date: September 6, 2012 Intended Status: Standards Track Summary: I have minor concerns about this document that I think should be resolved b= efore publication. Comments: On the most part the document is well written and very readable, and is nea= rly ready for publication. I have one minor issue which should be resolved = prior to publication, a question, and a few nits. Major Issues: None Minor Issues: I found the manner in which this document supports multi-topology routing w= ithin an single instance to be confusing and probably underspecified. The r= elationship with RFC 5120 is part of this issue. The text in section 1 was = not particularly helpful and I had to read all of both documents to figure = out what the relationship is - and am still not sure that I got it right. Considering the following paragraphs from section 1: A given instance MAY support multiple topologies. Each topology is associated with a unique LSDB and a topology specific IS-IS Update Process. This differs from [RFC5120= ] where a single LSDB/single IS-IS Update Process is used in support of all topologies. MI-IS-IS might be used to support topology specific routing. When used for this purpose it is an alternative to [RFC5120]. The second of these two paragraphs seems straightforward to understand: If = you want to support multiple topologies, one option is to use a separate in= dependent instance for each topology. This use case is explicitly described= in section 3.1 and is intuitively straightforward. LES: It is possible to create separate instances (i.e. unique IID values) o= n a per topology basis. In such a case each topology will have a 1-1 relati= onship with the instance, will have a unique IID value, will have instance= specific adjacencies, and an instance specific LSDB. However, it is also p= ossible to support multiple topologies within a single non-zero instance. I= n this case a set of topologies share an instance specific adjacency (based= on IID value) but do NOT share the LSDB. The LSDB is scoped by the IID/IT= ID pair. This is the concept the first paragraph you quote above is introdu= cing. Section 2 (third paragraph) goes on to state: "MI-RTRs support the exchange of topology specific Link State PDUs for the IID/ITID pairs that each neighbor supports. A unique IS-IS Update process [see IS-IS] operates for each IID/ITID pair." I am not sure how to be more clear about this. The first of these two paragraphs is not clear. There is more description i= n sections 2.5, 3.2, 3.3, and 4 which help significantly. However, section = 3 is "Usage Guidelines", and as such does not seem to be the right place to= include a rigorous description of how flooding is to occur when multiple t= opologies are supported with a single instance (nor does it seem to contain= a rigorous description). LES: Section 2 is intended to be the normative specification. Section 2.5 s= pecifically is the normative specification of how the Update process opera= tes. Section 3 is intended to clarify through discussion of some example use cas= es. Which is why the second paragraph of Section 3 states: "The following sub-sections provide some guidelines for usage of instances and topologies within each instance. While this represents examples based on the intent of the authors, implementors are not constrained by the examples." I believe Section 2 to be complete - and Section 3 could be omitted entirel= y without loss of completeness. However, it was the consensus of the author= s that Section 3 was needed to clarify how the protocol extensions might be= used by way of examples. I am not sure how to be more clear about this. This document does not claim to obsolete RFC 5120. LES: This is correct. RFC 5120 is not changed in any way by this document -= nor do we propose that RFC 5120 should no longer be used/supported. Thus for the standard instance (#0) it would seem that the same approach de= fined in 5120 needs to be used without any change, at least for interoperab= ility with older implementations that support 5120 and do not support this = draft. This would seem to contradict the first paragraph above -- or at lea= st require slightly different wording of this paragraph. The document shoul= d clearly state whether the standard instance (#0) uses the method in RFC 5= 120 for support of multiple topologies (which seems likely, for example sin= ce the IID-TLV's are not carried in the standard instance). LES: The standard instance is not changed in any way by this document. Inde= ed, it is not possible to do so without introducing backwards compatibility= issues - which we have been careful to avoid. See Section 2.6. But I will = try to make this more clear in the Introduction. I think that this document should say up front (section 1) that it defines = a new method for supporting multiple topologies, which can be done either w= ithin multiple instances or within a single instance -- it might also menti= on in section 1 that for backward compatibility the approach in RFC 5120 i= s used in IID zero. LES: This is NOT the intent of the document. The draft defines two new prot= ocol capabilities: 1)Overcoming the existing limitation that one and only one instance of the = protocol can be run on a given circuit. 2)Within a given non-zero(sic) instance support a topology specific update = process. The first of these two points is clearly stated in the Introduction. The se= cond point I think is less clear - I will reword the introduction to make t= hat point clearer. But it is decidedly NOT our intent to suggest that RFC 5120 should be repla= ced. It looks to me that section 2.5 could be enhanced to clarify operation when= multiple topologies are supported within a single instance. It should clea= rly state whether any one LSP contains only information specific to a parti= cular IID and ITID (this is my interpretation of the first sentence of 2.5)= . I also infer from the first sentence of 2.5 that each LSP contains informat= ion for a single IID and a single ITID, encoded using the TLV defined in se= ction 2.1, and the LSP is flooded only among routers that support that IID/= ITID combination. Thus if I am reading this correctly then when occurring i= n an LSP the IID TLV MUST contain only one ITID value (although I also expe= ct that some physical links may want to be shared by multiple topologies, a= nd whether they have to be separately listed in multiple LSPs, one per topo= logy, or if they could be described in a single LSP that is associated with= multiple ITID's). I think that this needs to be made clearer. LES: Section 2 states " MI-RTRs support the exchange of topology specific Link State PDUs for the IID/ITID pairs that each neighbor supports. A unique IS-IS Update process [see IS-IS] operates for each IID/ITID pair." Section 2.1 states: "When the IID is non-zero and the TLV appears in an SNP or LSP, exactly one ITID MUST be present indicating the topology with which the PDU is associated." Although this seems unambiguous to me and has language that specifically ad= dresses the points you raise, your confusion suggests we need some rewordin= g - but I am not sure how to be more clear. Also a question: Section 2.6.1 describes the use of two new dedicated layer= 2 multicast addresses: An MI-RTR will use two new (TBD) dedicated layer 2 multicast addresses (one for each level) when sending IS-IS PDUs for any non-zero IID. I am wondering whether or not this should be mentioned in the IANA section = (it is not currently). This seems like something that someone needs to get = assigned, but it is not obvious to me whether the IANA is involved in this. LES: Yes - this issue came up during the IANA review. Our intention is to o= btain the addresses from the IANA managed address space specified in RFC 53= 42. IANA has asked that we update the IANA section to reflect this - which = we intend to do. Nits: >> Last sentence of section 2.1: A PDU without an IID-TLV is assumed to belong to the standard instance (#0). I don't think that "is assumed" is quite the right terminology. A PDU witho= ut an IID-TLV by definition does belong to the standard instance (#0). Thus= , how about: A PDU without an IID-TLV belongs to the standard instance (#0). LES: OK >> section 2.6.1, first bullet item (describing PDUs that MUST be discarded= ): o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV Elsewhere it says that the IID-TLV with a value of zero MUST NOT be include= d except as specified in this document. As such this comment is very minor:= However, wouldn't it be more precise and/or more flexible for future exten= sions to reword this bullet item as: o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV with a non-zero IID LES: No. The only exception to the rule that an instance #0 PDU NOT contain= the IID-TLV is in the case of P2P IIHs as described in Section 2.6.2. As S= ection 2.6.1 is talking about operation on a broadcast circuit we are inten= tionally saying there MUST NOT be an IID-TLV at all (even w IID value #0) i= n such a PDU. I will however make this more clear - especially in the context of P2P oper= ation over broadcast media (RFC 5309). Les --_000_DF7F294AF4153D498141CBEFADB17704C7EC21BB36EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Reading t= hrough your response, it looks to me that resolving my comments will requir= e relatively few changes to the draft (and probably no substantial technica= l change), but might require several emails back and forth. Probably it is = most productive to have this exchange of emails off-line, and then report t= he results to the larger lists.

    =  

    I will there= fore reply in detail to the authors, with the understanding that the three = mailing lists CC’d above will need a summary of the results when we a= re done.

     

    Thanks, Ross

    =

     

    From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Monday, September 10, 2012 12:59 AM
    To: Ross Callon= ; rtg-ads@tools.ietf.org; Stefano Previdi (sprevidi); imc.shand@googlemail.= com; Abhay Roy (akr); David Ward (wardd)
    Cc: isis-wg@ietf.org; rt= g-dir@ietf.org
    Subject: RE: RtgDir review: draft-ietf-isis-mi-06<= o:p>

     

    =

    Ross –

     

    Than= k you for the review.

     

    I will respond inline t= o each of your points below – however I want to preface my responses = by saying that it concerns me that the document is not clear to you as rega= rds multi-topology routing support and the relationship to RFC 5120. We tri= ed in a number of ways to be clear about this (as I will point out below) &= #8211; but given that you still are confused on some points it seems that w= e did not succeed. I therefore believe the text requires revision – t= hough at this moment I am not certain as to what changes will resolve all t= he ambiguities that presented themselves to you. I hope you will work with = us in trying to find better wording. I’ll do my best to indicate belo= w where I think rewording may help and where your help may be needed as I d= on’t know what rewording will resolve the issues you raise.

     

    Please see LES: inline.

     

    From: Ross Callon [mail= to:rcallon@juniper.net]
    Sent: Thursday, September 06, 2012 9= :36 PM
    To: rtg-ads@tool= s.ietf.org; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); imc.shand@googlemail.com; Abhay R= oy (akr); David Ward (wardd)
    Cc: isis-wg@ietf.org; rtg-dir@ietf.= org; Ross Callon
    Subject: RtgDir review: draft-ietf-isis-mi-0= 6

     

    = Hello, =

    I have been selected as the Routing Directorate reviewer= for this draft. The Routing Directorate seeks to review all routing or rou= ting-related drafts as they pass through IETF last call and IESG review, an= d sometimes on special request. The purpose of the review is to provide ass= istance to the Routing ADs. For more information about the Routing Director= ate, please see http://www.ietf.org/iesg/directorate/routing.html =

    Although these comments are primarily for the use of the Routing ADs, it w= ould be helpful if you could consider them along with any other IETF Last C= all comments that you receive, and strive to resolve them through discussio= n or by updating the draft.

    Document: draft-ietf-isis-mi= -06
    Reviewer: Ross Callon
    Review Date: September 6, 2012
    Intended= Status: Standards Track

    Summary:

    I have minor concerns about this document that I think should be resolved= before publication.

    Comments:=

    On the most part the document is well written and very readable, and is ne= arly ready for publication. I have one minor issue which should be resolved= prior to publication, a question, and a few nits.

    Ma= jor Issues:  None

    Minor Issues:

    I found the manner in which this docum= ent supports multi-topology routing within an single instance to be confusi= ng and probably underspecified. The relationship with RFC 5120 is part of t= his issue. The text in section 1 was not particularly helpful and I had to = read all of both documents to figure out what the relationship is – a= nd am still not sure that I got it right.

    =

     

    <= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>Consider= ing the following paragraphs from section 1:

     

       A = given instance MAY support multiple topologies.  Each topology is=

       associated with a unique LSDB= and a topology specific IS-IS Update

    =    Process.  This differs from [RFC5120] where a single LSDB/single

       IS-IS Update Process is used in support o= f all topologies.

     

      MI-IS-IS might be used to support topology s= pecific routing.  When

     &nbs= p; used for this purpose it is an alternative to [RFC5120].

     

    The second of these two paragraphs seems = straightforward to understand: If you want to support multiple topologies, = one option is to use a separate independent instance for each topology. Thi= s use case is explicitly described in section 3.1 and is intuitively straig= htforward.

     

     

    LES: It is possible to create separate instances (i.e. unique II= D values) on a per topology basis. In such a case each topology will have a= 1-1 relationship with the instance,  will have a unique IID value, wi= ll have instance specific adjacencies, and an instance specific LSDB. Howev= er, it is also possible to support multiple topologies within a single non-= zero instance. In this case a set of topologies share an instance specific = adjacency (based on IID value) but do NOT share  the LSDB. The LSDB is= scoped by the IID/ITID pair. This is the concept the first paragraph you q= uote above is introducing. Section 2 (third paragraph) goes on to state:

     

    “MI-RTRs suppor= t the exchange of topology specific Link State PDUs for

       the IID/ITID pairs t= hat each neighbor supports.  A unique IS-IS

       Update process [see IS-IS] = operates for each IID/ITID pair.”

     

    I am not sure how to be more clear about this.

     

    The first of these two paragraphs is = not clear. There is more description in sections 2.5, 3.2, 3.3, and 4 which= help significantly. However, section 3 is “Usage Guidelines”, = and as such does not seem to be the right place to include a rigorous descr= iption of how flooding is to occur when multiple topologies are supported w= ith a single instance (nor does it seem to contain a rigorous description).=

     

    LES:= Section 2 is intended to be the normative specification. Sec= tion 2.5 specifically  is the normative specification of how the Updat= e process operates.

    Sect= ion 3 is intended to clarify through discussion of some example use cases. = Which is why the second paragraph of Section 3 states:

     

    “The following sub-sections pr= ovide some guidelines for usage of

       instances and topologies= within each instance.  While this represents

       examples= based on the intent of the authors, implementors are not=

       constrained by the examples.&#= 8221;

     

    I believe Section 2 to be complete –= and Section 3 could be omitted entirely without loss of completeness. Howe= ver, it was the consensus of the authors that Section 3 was needed to clari= fy how the protocol extensions might be used by way of examples.=

    I am not sure how to be more clear a= bout this.

     

    This document does not claim to obsol= ete RFC 5120.

     

    <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>LES: This is correct. RFC 5120 is not changed in any way by this docu= ment – nor do we propose that RFC 5120 should no longer be used/suppo= rted.

     

    Thus for the standard instance (#0) it would seem tha= t the same approach defined in 5120 needs to be used without any change, at= least for interoperability with older implementations that support 5120 an= d do not support this draft. This would seem to contradict the first paragr= aph above -- or at least require slightly different wording of this paragra= ph. The document should clearly state whether the standard instance (#0) us= es the method in RFC 5120 for support of multiple topologies (which seems l= ikely, for example since the IID-TLV’s are not carried in the standar= d instance).

     <= /o:p>

    LES: The standard instance is n= ot changed in any way by this document. Indeed, it is not possible to do so= without introducing backwards compatibility issues – which we have b= een careful to avoid. See Section 2.6. But I will try to make this more cle= ar in the Introduction.

     = ;

    I think that this document = should say up front (section 1) that it defines a new method for supporting= multiple topologies, which can be done either within multiple instances or= within a single instance -- it might also mention in section 1 that for ba= ckward compatibility the approach in  RFC 5120 is used in IID zero.

     

    LES: This = is NOT the intent of the document. The draft defines two new protocol capab= ilities:

     =

    1)Overcoming the existing limitation= that one and only one instance of the protocol can be run on a given circu= it.

    2)Within a given non-z= ero(sic) instance support a topology specific update process.

     

    The first of these two points is clearly stated in the Int= roduction. The second point I think is less clear – I will reword the= introduction to make that point clearer.

    But it is decidedly NOT our intent to suggest that RFC 5120= should be replaced.

     

    It looks to me that section 2.5 could= be enhanced to clarify operation when multiple topologies are supported wi= thin a single instance. It should clearly state whether any one LSP contain= s only information specific to a particular IID and ITID (this is my interp= retation of the first sentence of 2.5). =

     <= /span>

    I also infer from the first sentence of 2.5 that ea= ch LSP contains information for a single IID and a single ITID, encoded usi= ng the TLV defined in section 2.1, and the LSP is flooded only among router= s that support that IID/ITID combination. Thus if I am reading this correct= ly then when occurring in an LSP the IID TLV MUST contain only one ITID val= ue (although I also expect that some physical links may want to be shared b= y multiple topologies, and whether they have to be separately listed in mul= tiple LSPs, one per topology, or if they could be described in a single LSP= that is associated with multiple ITID’s). I think that this needs to= be made clearer.

     

    LES:&n= bsp; Section 2 states

     

    “  MI-RTRs support the exchange of topology specific Link State= PDUs for

    &nbs= p;  the IID/ITID pairs that each neighbor supports.  A unique IS-= IS

    <= span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>  = ; Update process [see IS-IS] operates for each IID/ITID pair.”

     

    Section 2.1 states:

     

        “Wh= en the IID is non-zero and the TLV appears in an SNP or LSP,

         exa= ctly one ITID MUST be present indicating the topology with

         which= the PDU is associated.”

     

    Although this seems unambiguous to me and has language that speci= fically addresses the points you raise, your confusion suggests we need som= e rewording – but I am not sure how to be more clear.

     

    <= p class=3DMsoNormal>Also a question: Section 2.6.1 describes the use of two new de= dicated layer 2 multicast addresses:

     

       An MI-RTR = will use two new (TBD) dedicated layer

       2 multicast addresses (one for each level) when sending IS-IS= PDUs

       for any non-zero II= D.

     

    I am wondering whether or not this should be mentioned in the IANA section= (it is not currently). This seems like something that someone needs to get= assigned, but it is not obvious to me whether the IANA is involved in this= .

     

    LES: Yes – this issue came up during th= e IANA review. Our intention is to obtain the addresses from the IANA manag= ed address space specified in RFC 5342. IANA has asked that we update the I= ANA section to reflect this – which we intend to do.

     

    Nits:=

    >> Last sentence of section= 2.1:

     

       A PDU without an IID-TLV is assumed to be= long to the standard

    <= span style=3D'font-size:10.0pt;font-family:"Courier New"'>   inst= ance (#0).

     

    I don’t think that “is assumed”= is quite the right terminology. A PDU without an IID-TLV by definition doe= s belong to the standard instance (#0). Thus, how about:=

       A PDU without = an IID-TLV belongs to the standard instance (#0).

     

    LES: OK

     =

    >> section 2.6.1, first bullet item (des= cribing PDUs that MUST be discarded):

     =

      o  The destination multicast address= is AllL1IS or AllL2IS and the

     &= nbsp;    PDU contains an IID-TLV

    =

     

    Elsewhere it= says that the IID-TLV with a value of zero MUST NOT be included except as = specified in this document. As such this comment is very minor: However, wo= uldn’t it be more precise and/or more flexible for future extensions = to reword this  bullet item as:

     <= /span>

       o  The destination multicast ad= dress is AllL1IS or AllL2IS and the

    &n= bsp;     PDU contains an IID-TLV with a non-zero IID

     

    LES: No= . The only exception to the rule that an instance #0 PDU NOT contain the II= D-TLV is in the case of P2P IIHs as described in Section 2.6.2. As Section = 2.6.1 is talking about operation on a broadcast circuit we are intentionally saying there MUST NOT be an IID-TLV at all (even w II= D value #0) in such a PDU.

    &nbs= p;

    I will however make this more clear – e= specially in the context of P2P operation over broadcast media (RFC 5309).<= o:p>

     

       Les

     

    = --_000_DF7F294AF4153D498141CBEFADB17704C7EC21BB36EMBX01WFjnprn_-- From rcallon@juniper.net Sun Sep 16 19:26:02 2012 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 A3A6921F8534; Sun, 16 Sep 2012 19:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, 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 YdPeAU3prjDg; Sun, 16 Sep 2012 19:25:55 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91921F8532; Sun, 16 Sep 2012 19:25:36 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUFaKH2ff6qLM8BCcJXYtmPRuDD7ouuZi@postini.com; Sun, 16 Sep 2012 19:25:54 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 16 Sep 2012 19:25:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sun, 16 Sep 2012 22:25:08 -0400 From: Ross Callon To: "Les Ginsberg (ginsberg)" , "Stefano Previdi (sprevidi)" , "imc.shand@googlemail.com" , "Abhay Roy (akr)" , "David Ward (wardd)" Date: Sun, 16 Sep 2012 22:25:02 -0400 Thread-Topic: RtgDir review: draft-ietf-isis-mi-06 Thread-Index: Ac2MslRxcto44tp8Q/yaJe8oW/uI8QCVPvBgAIFhVcAA2rq8QA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EC3C8DA1EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Ross Callon , "rtg-dir@ietf.org" , "isis-wg@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06 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, 17 Sep 2012 02:26:02 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C7EC3C8DA1EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The -07 version of the draft (draft-ietf-isis-mi-07), which has just been p= osted, addresses to my satisfaction the issues and comments that I mentione= d in my routing directorate review. Thanks to the authors for quickly dealing with these. Ross From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf = Of Ross Callon Sent: Wednesday, September 12, 2012 1:37 PM To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi); imc.shand@googlema= il.com; Abhay Roy (akr); David Ward (wardd) Cc: rtg-dir@ietf.org; isis-wg@ietf.org; rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06 Reading through your response, it looks to me that resolving my comments wi= ll require relatively few changes to the draft (and probably no substantial= technical change), but might require several emails back and forth. Probab= ly it is most productive to have this exchange of emails off-line, and then= report the results to the larger lists. I will therefore reply in detail to the authors, with the understanding tha= t the three mailing lists CC'd above will need a summary of the results whe= n we are done. Thanks, Ross From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Monday, September 10, 2012 12:59 AM To: Ross Callon; rtg-ads@tools.ietf.org; Ste= fano Previdi (sprevidi); imc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd) Cc: isis-wg@ietf.org; rtg-dir@ietf.org Subject: RE: RtgDir review: draft-ietf-isis-mi-06 Ross - Thank you for the review. I will respond inline to each of your points below - however I want to pref= ace my responses by saying that it concerns me that the document is not cle= ar to you as regards multi-topology routing support and the relationship to= RFC 5120. We tried in a number of ways to be clear about this (as I will p= oint out below) - but given that you still are confused on some points it s= eems that we did not succeed. I therefore believe the text requires revisio= n - though at this moment I am not certain as to what changes will resolve = all the ambiguities that presented themselves to you. I hope you will work = with us in trying to find better wording. I'll do my best to indicate below= where I think rewording may help and where your help may be needed as I do= n't know what rewording will resolve the issues you raise. Please see LES: inline. From: Ross Callon [mailto:rcallon@juniper.net] Sent: Thursday, September 06, 2012 9:36 PM To: rtg-ads@tools.ietf.org; Stefano Previdi = (sprevidi); Les Ginsberg (ginsberg); imc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd) Cc: isis-wg@ietf.org; rtg-dir@ietf.org; Ross Callon Subject: RtgDir review: draft-ietf-isis-mi-06 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-isis-mi-06 Reviewer: Ross Callon Review Date: September 6, 2012 Intended Status: Standards Track Summary: I have minor concerns about this document that I think should be resolved b= efore publication. Comments: On the most part the document is well written and very readable, and is nea= rly ready for publication. I have one minor issue which should be resolved = prior to publication, a question, and a few nits. Major Issues: None Minor Issues: I found the manner in which this document supports multi-topology routing w= ithin an single instance to be confusing and probably underspecified. The r= elationship with RFC 5120 is part of this issue. The text in section 1 was = not particularly helpful and I had to read all of both documents to figure = out what the relationship is - and am still not sure that I got it right. Considering the following paragraphs from section 1: A given instance MAY support multiple topologies. Each topology is associated with a unique LSDB and a topology specific IS-IS Update Process. This differs from [RFC5120= ] where a single LSDB/single IS-IS Update Process is used in support of all topologies. MI-IS-IS might be used to support topology specific routing. When used for this purpose it is an alternative to [RFC5120]. The second of these two paragraphs seems straightforward to understand: If = you want to support multiple topologies, one option is to use a separate in= dependent instance for each topology. This use case is explicitly described= in section 3.1 and is intuitively straightforward. LES: It is possible to create separate instances (i.e. unique IID values) o= n a per topology basis. In such a case each topology will have a 1-1 relati= onship with the instance, will have a unique IID value, will have instance= specific adjacencies, and an instance specific LSDB. However, it is also p= ossible to support multiple topologies within a single non-zero instance. I= n this case a set of topologies share an instance specific adjacency (based= on IID value) but do NOT share the LSDB. The LSDB is scoped by the IID/IT= ID pair. This is the concept the first paragraph you quote above is introdu= cing. Section 2 (third paragraph) goes on to state: "MI-RTRs support the exchange of topology specific Link State PDUs for the IID/ITID pairs that each neighbor supports. A unique IS-IS Update process [see IS-IS] operates for each IID/ITID pair." I am not sure how to be more clear about this. The first of these two paragraphs is not clear. There is more description i= n sections 2.5, 3.2, 3.3, and 4 which help significantly. However, section = 3 is "Usage Guidelines", and as such does not seem to be the right place to= include a rigorous description of how flooding is to occur when multiple t= opologies are supported with a single instance (nor does it seem to contain= a rigorous description). LES: Section 2 is intended to be the normative specification. Section 2.5 s= pecifically is the normative specification of how the Update process opera= tes. Section 3 is intended to clarify through discussion of some example use cas= es. Which is why the second paragraph of Section 3 states: "The following sub-sections provide some guidelines for usage of instances and topologies within each instance. While this represents examples based on the intent of the authors, implementors are not constrained by the examples." I believe Section 2 to be complete - and Section 3 could be omitted entirel= y without loss of completeness. However, it was the consensus of the author= s that Section 3 was needed to clarify how the protocol extensions might be= used by way of examples. I am not sure how to be more clear about this. This document does not claim to obsolete RFC 5120. LES: This is correct. RFC 5120 is not changed in any way by this document -= nor do we propose that RFC 5120 should no longer be used/supported. Thus for the standard instance (#0) it would seem that the same approach de= fined in 5120 needs to be used without any change, at least for interoperab= ility with older implementations that support 5120 and do not support this = draft. This would seem to contradict the first paragraph above -- or at lea= st require slightly different wording of this paragraph. The document shoul= d clearly state whether the standard instance (#0) uses the method in RFC 5= 120 for support of multiple topologies (which seems likely, for example sin= ce the IID-TLV's are not carried in the standard instance). LES: The standard instance is not changed in any way by this document. Inde= ed, it is not possible to do so without introducing backwards compatibility= issues - which we have been careful to avoid. See Section 2.6. But I will = try to make this more clear in the Introduction. I think that this document should say up front (section 1) that it defines = a new method for supporting multiple topologies, which can be done either w= ithin multiple instances or within a single instance -- it might also menti= on in section 1 that for backward compatibility the approach in RFC 5120 i= s used in IID zero. LES: This is NOT the intent of the document. The draft defines two new prot= ocol capabilities: 1)Overcoming the existing limitation that one and only one instance of the = protocol can be run on a given circuit. 2)Within a given non-zero(sic) instance support a topology specific update = process. The first of these two points is clearly stated in the Introduction. The se= cond point I think is less clear - I will reword the introduction to make t= hat point clearer. But it is decidedly NOT our intent to suggest that RFC 5120 should be repla= ced. It looks to me that section 2.5 could be enhanced to clarify operation when= multiple topologies are supported within a single instance. It should clea= rly state whether any one LSP contains only information specific to a parti= cular IID and ITID (this is my interpretation of the first sentence of 2.5)= . I also infer from the first sentence of 2.5 that each LSP contains informat= ion for a single IID and a single ITID, encoded using the TLV defined in se= ction 2.1, and the LSP is flooded only among routers that support that IID/= ITID combination. Thus if I am reading this correctly then when occurring i= n an LSP the IID TLV MUST contain only one ITID value (although I also expe= ct that some physical links may want to be shared by multiple topologies, a= nd whether they have to be separately listed in multiple LSPs, one per topo= logy, or if they could be described in a single LSP that is associated with= multiple ITID's). I think that this needs to be made clearer. LES: Section 2 states " MI-RTRs support the exchange of topology specific Link State PDUs for the IID/ITID pairs that each neighbor supports. A unique IS-IS Update process [see IS-IS] operates for each IID/ITID pair." Section 2.1 states: "When the IID is non-zero and the TLV appears in an SNP or LSP, exactly one ITID MUST be present indicating the topology with which the PDU is associated." Although this seems unambiguous to me and has language that specifically ad= dresses the points you raise, your confusion suggests we need some rewordin= g - but I am not sure how to be more clear. Also a question: Section 2.6.1 describes the use of two new dedicated layer= 2 multicast addresses: An MI-RTR will use two new (TBD) dedicated layer 2 multicast addresses (one for each level) when sending IS-IS PDUs for any non-zero IID. I am wondering whether or not this should be mentioned in the IANA section = (it is not currently). This seems like something that someone needs to get = assigned, but it is not obvious to me whether the IANA is involved in this. LES: Yes - this issue came up during the IANA review. Our intention is to o= btain the addresses from the IANA managed address space specified in RFC 53= 42. IANA has asked that we update the IANA section to reflect this - which = we intend to do. Nits: >> Last sentence of section 2.1: A PDU without an IID-TLV is assumed to belong to the standard instance (#0). I don't think that "is assumed" is quite the right terminology. A PDU witho= ut an IID-TLV by definition does belong to the standard instance (#0). Thus= , how about: A PDU without an IID-TLV belongs to the standard instance (#0). LES: OK >> section 2.6.1, first bullet item (describing PDUs that MUST be discarded= ): o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV Elsewhere it says that the IID-TLV with a value of zero MUST NOT be include= d except as specified in this document. As such this comment is very minor:= However, wouldn't it be more precise and/or more flexible for future exten= sions to reword this bullet item as: o The destination multicast address is AllL1IS or AllL2IS and the PDU contains an IID-TLV with a non-zero IID LES: No. The only exception to the rule that an instance #0 PDU NOT contain= the IID-TLV is in the case of P2P IIHs as described in Section 2.6.2. As S= ection 2.6.1 is talking about operation on a broadcast circuit we are inten= tionally saying there MUST NOT be an IID-TLV at all (even w IID value #0) i= n such a PDU. I will however make this more clear - especially in the context of P2P oper= ation over broadcast media (RFC 5309). Les --_000_DF7F294AF4153D498141CBEFADB17704C7EC3C8DA1EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The -07 v= ersion of the draft (draft-ietf-isis-mi-07), which has just been posted, ad= dresses to my satisfaction the issues and comments that I mentioned in my r= outing directorate review.

     

    Thanks to the aut= hors for quickly dealing with these.

     

    Ross

     

    From: rtg-dir-bounces@ietf.org [mailto:rt= g-dir-bounces@ietf.org] On Behalf Of Ross Callon
    Sent: Wed= nesday, September 12, 2012 1:37 PM
    To: Les Ginsberg (ginsberg); S= tefano Previdi (sprevidi); imc.shand@googlemail.com; Abhay Roy (akr); David= Ward (wardd)
    Cc: rtg-dir@ietf.org; isis-wg@ietf.org; rtg-ads@too= ls.ietf.org
    Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis= -mi-06

     

    Reading through your response, it looks = to me that resolving my comments will require relatively few changes to the= draft (and probably no substantial technical change), but might require se= veral emails back and forth. Probably it is most productive to have this ex= change of emails off-line, and then report the results to the larger lists.=

     =

    I will therefore reply in detail to the aut= hors, with the understanding that the three mailing lists CC’d above = will need a summary of the results when we are done.

    =

     

    Thanks, Ross

     

    From: Les Ginsbe= rg (ginsberg) [mailto:ginsberg@cisco.= com]
    Sent: Monday, September 10, 2012 12:59 AM
    To:= Ross Callon; rtg-ads@tools.ietf.= org; Stefano Previdi (sprevidi); imc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd)
    = Cc: isis-wg@ietf.org; rtg-dir@ietf.org
    Subject: RE: R= tgDir review: draft-ietf-isis-mi-06

     

    Ross –= ;

     =

    Thank you for the review.=

     

    I will respond inline to each of your points below – how= ever I want to preface my responses by saying that it concerns me that the = document is not clear to you as regards multi-topology routing support and = the relationship to RFC 5120. We tried in a number of ways to be clear abou= t this (as I will point out below) – but given that you still are con= fused on some points it seems that we did not succeed. I therefore believe = the text requires revision – though at this moment I am not certain a= s to what changes will resolve all the ambiguities that presented themselve= s to you. I hope you will work with us in trying to find better wording. I&= #8217;ll do my best to indicate below where I think rewording may help and = where your help may be needed as I don’t know what rewording will res= olve the issues you raise.

     

    Please see LES: in= line.

     

    From: Ross Callon [mailto:rcallon@juniper.net]
    Sent= : Thursday, September 06, 2012 9:36 PM
    To: rtg-ads@tools.ietf.org; Stefano Previdi (sprevi= di); Les Ginsberg (ginsberg); i= mc.shand@googlemail.com; Abhay Roy (akr); David Ward (wardd)
    Cc:<= /b> isis-wg@ietf.org; rtg-dir@ietf.org; Ross Callon
    Subject:= RtgDir review: draft-ietf-isis-mi-06

     

    Hello,

    I have been select= ed as the Routing Directorate reviewer for this draft. The Routing Director= ate seeks to review all routing or routing-related drafts as they pass thro= ugh IETF last call and IESG review, and sometimes on special request. The p= urpose 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/directora= te/routing.html

    Although these comments are primaril= y 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 st= rive to resolve them through discussion or by updating the draft.

    Document: draft-ietf-isis-mi-06
    Reviewer: Ross Callon
    Revie= w Date: September 6, 2012
    Intended Status: Standards Track

    Summary:

    I have minor concerns about this do= cument that I think should be resolved before publication.

    Comments:

    On the most part the document is well = written and very readable, and is nearly ready for publication. I have one = minor issue which should be resolved prior to publication, a question, and = a few nits.

    Major Issues:  None

    Minor Issues:

    I = found the manner in which this document supports multi-topology routing wit= hin an single instance to be confusing and probably underspecified. The rel= ationship with RFC 5120 is part of this issue. The text in section 1 was no= t particularly helpful and I had to read all of both documents to figure ou= t what the relationship is – and am still not sure that I got it righ= t.

     =

    Considering the following paragraphs from sect= ion 1:

     

       A given instance MAY support multiple to= pologies.  Each topology is

    &nb= sp;  associated with a unique LSDB and a topology specific IS-IS Updat= e

       Process.  This dif= fers from [RFC5120] wher= e a single LSDB/single

       IS= -IS Update Process is used in support of all topologies.=

     

      MI-I= S-IS might be used to support topology specific routing.  When<= span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>

       used for this purpose it is an a= lternative to [RFC5120].= =

     

    T= he second of these two paragraphs seems straightforward to understand: If y= ou want to support multiple topologies, one option is to use a separate ind= ependent instance for each topology. This use case is explicitly described = in section 3.1 and is intuitively straightforward.

     

     =

    LES: It is possible to c= reate separate instances (i.e. unique IID values) on a per topology basis. = In such a case each topology will have a 1-1 relationship with the instance= ,  will have a unique IID value, will have instance specific adjacenci= es, and an instance specific LSDB. However, it is also possible to support = multiple topologies within a single non-zero instance. In this case a set o= f topologies share an instance specific adjacency (based on IID value) but = do NOT share  the LSDB. The LSDB is scoped by the IID/ITID pair. This = is the concept the first paragraph you quote above is introducing. Section = 2 (third paragraph) goes on to state:

     

    “MI-RTRs support the exchange of topology specific L= ink State PDUs for

       the IID/ITID pairs that each neighbor supports.  A u= nique IS-IS

    &n= bsp;  Update process [see IS-IS] operates for each IID/ITID pair.̶= 1;

    <= span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'> =

    I am not sure how = to be more clear about this.

     

    T= he first of these two paragraphs is not clear. There is more description in= sections 2.5, 3.2, 3.3, and 4 which help significantly. However, section 3= is “Usage Guidelines”, and as such does not seem to be the rig= ht place to include a rigorous description of how flooding is to occur when= multiple topologies are supported with a single instance (nor does it seem= to contain a rigorous description).

     

    LES: Section 2 is intended to be the normativ= e specification. Section 2.5 specifically  is the normat= ive specification of how the Update process operates.

    =

    Section 3 is intended to clarify through discus= sion of some example use cases. Which is why the second paragraph of Sectio= n 3 states:

     

    R= 20;The following sub-sections provide some guidelines for usage of

    &nbs= p;  instances and topologies within each instance.  While this re= presents

       examples based on the intent of the authors, imple= mentors are not

     &nbs= p; constrained by the examples.”

     

    I believe= Section 2 to be complete – and Section 3 could be omitted entirely w= ithout loss of completeness. However, it was the consensus of the authors t= hat Section 3 was needed to clarify how the protocol extensions might be us= ed by way of examples.

    I a= m not sure how to be more clear about this.

     

    Th= is document does not claim to obsolete RFC 5120.

     

    LES: This is correct. RFC 5120 is = not changed in any way by this document – nor do we propose that RFC = 5120 should no longer be used/supported.

     

    Thus for the stand= ard instance (#0) it would seem that the same approach defined in 5120 need= s to be used without any change, at least for interoperability with older i= mplementations that support 5120 and do not support this draft. This would = seem to contradict the first paragraph above -- or at least require slightl= y different wording of this paragraph. The document should clearly state wh= ether the standard instance (#0) uses the method in RFC 5120 for support of= multiple topologies (which seems likely, for example since the IID-TLVR= 17;s are not carried in the standard instance).

     

    LES: The standard instance is not changed in any way by this document. = Indeed, it is not possible to do so without introducing backwards compatibi= lity issues – which we have been careful to avoid. See Section 2.6. B= ut I will try to make this more clear in the Introduction.

     

    I think that this document should say up front (section 1) that it = defines a new method for supporting multiple topologies, which can be done = either within multiple instances or within a single instance -- it might al= so mention in section 1 that for backward compatibility the approach in&nbs= p; RFC 5120 is used in IID zero.

     

    LES: This is NOT the intent of the document. The d= raft defines two new protocol capabilities:

     

    1)Overcoming the existing limitation that one and only one instance of the= protocol can be run on a given circuit.

    2)Within a given non-zero(sic) instance support a topology s= pecific update process.

     

    The first of these tw= o points is clearly stated in the Introduction. The second point I think is= less clear – I will reword the introduction to make that point clear= er.

    But it is decidedly NO= T our intent to suggest that RFC 5120 should be replaced.=

     

    I= t looks to me that section 2.5 could be enhanced to clarify operation when = multiple topologies are supported within a single instance. It should clear= ly state whether any one LSP contains only information specific to a partic= ular IID and ITID (this is my interpretation of the first sentence of 2.5).=  

     

    I also infer = from the first sentence of 2.5 that each LSP contains information for a sin= gle IID and a single ITID, encoded using the TLV defined in section 2.1, an= d the LSP is flooded only among routers that support that IID/ITID combinat= ion. Thus if I am reading this correctly then when occurring in an LSP the = IID TLV MUST contain only one ITID value (although I also expect that some = physical links may want to be shared by multiple topologies, and whether th= ey have to be separately listed in multiple LSPs, one per topology, or if t= hey could be described in a single LSP that is associated with multiple ITI= D’s). I think that this needs to be made clearer. =

     

    LES:  Section 2 states

     

    =

    “  MI-RTRs support the e= xchange of topology specific Link State PDUs for

       the IID/ITID pairs that eac= h neighbor supports.  A unique IS-IS

       Update process [see IS-IS] operate= s for each IID/ITID pair.”

     

    Section 2.1 states:

     

        “When the IID is non-zero and the TL= V appears in an SNP or LSP,

         exactly one ITID MUST be present ind= icating the topology with

         which the PDU is associated.”<= o:p>

     

    Although this seems u= nambiguous to me and has language that specifically addresses the points yo= u raise, your confusion suggests we need some rewording – but I am no= t sure how to be more clear.

     

    Also a question: S= ection 2.6.1 describes the use of two new dedicated layer 2 multicast addre= sses:

     

       An MI-RTR will use two new (TBD) dedicate= d layer

       2 multicast addre= sses (one for each level) when sending IS-IS PDUs

       for any non-zero IID.

    <= div>

     

    I am wondering whether or not = this should be mentioned in the IANA section (it is not currently). This se= ems like something that someone needs to get assigned, but it is not obviou= s to me whether the IANA is involved in this.

    <= div>

     

    L= ES: Yes – this issue came up during the IANA review. Our intention is= to obtain the addresses from the IANA managed address space specified in R= FC 5342. IANA has asked that we update the IANA section to reflect this = 211; which we intend to do.

     

    Nits:

    >> Last sentence of section 2.1:

     

     &nbs= p; A PDU without an IID-TLV is assumed to belong to the standard=

       instance (#0).

     

    I don= ’t think that “is assumed” is quite the right terminology= . A PDU without an IID-TLV by definition does belong to the standard instan= ce (#0). Thus, how about:

     

    <= /div>

       A PDU without an IID-TLV belongs to the standar= d instance (#0).

    &nbs= p;

    LES: OK

     

    >&= gt; section 2.6.1, first bullet item (describing PDUs that MUST be discarde= d):

     

      = o  The destination multicast address is AllL1IS or AllL2IS and the

          PDU contai= ns an IID-TLV

     =

    Elsewhere it says that the IID-TLV with a valu= e of zero MUST NOT be included except as specified in this document. As suc= h this comment is very minor: However, wouldn’t it be more precise an= d/or more flexible for future extensions to reword this  bullet item a= s:

     

     &n= bsp; o  The destination multicast address is AllL1IS or AllL2IS and th= e

          PDU c= ontains an IID-TLV with a non-zero IID

     

    LES: No. The only exception to the rule t= hat an instance #0 PDU NOT contain the IID-TLV is in the case of P2P IIHs a= s described in Section 2.6.2. As Section 2.6.1 is talking about operation o= n a broadcast circuit we are intentionally saying there M= UST NOT be an IID-TLV at all (even w IID value #0) in such a PDU.

     

    I will= however make this more clear – especially in the context of P2P oper= ation over broadcast media (RFC 5309).

     

       Les

     

    = --_000_DF7F294AF4153D498141CBEFADB17704C7EC3C8DA1EMBX01WFjnprn_-- From stig@cisco.com Wed Sep 26 12:11:24 2012 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 2F5A821F85C2 for ; Wed, 26 Sep 2012 12:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 60SpM7eY7FaX for ; Wed, 26 Sep 2012 12:11:23 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5075421F849C for ; Wed, 26 Sep 2012 12:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5748; q=dns/txt; s=iport; t=1348686683; x=1349896283; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6JqRG0YkgQhE8CSKySA8YOzs/fTa8jjOSuHHIE9VqS8=; b=cXo1IuASaocrkUBu+UmD/lz2wyN1oqEDIKrS3VDesIUoFJPXkVVmXNdz ce2rv1Xmmmx5jennZZxujxZvknzucJ67TlmgzcRURBhrGA/j82IOmQBl9 JSCQBNUJGBRAQKNmmYzGnQXZvxlsFjFIINFl00B/1YiP1+CiXfZzKj1WN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAFSY1CrRDoJ/2dsb2JhbABFvlmBCIIgAQEBAwESAR8BBUABBQsLFAQJFg8JAwIBAgFFBg0BBwEBBRmHXQUMmC+gLosYhgkDiFiJYIMxhWKIYIFpgwc X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="59473559" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Sep 2012 19:11:22 +0000 Received: from [10.154.208.60] ([10.154.208.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8QJBMkJ024771; Wed, 26 Sep 2012 19:11:22 GMT Message-ID: <5063535A.4090501@cisco.com> Date: Wed, 26 Sep 2012 12:11:22 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Retana, Alvaro" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 26 Sep 2012 17:18:20 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-pim-pop-count.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-pop-count-06 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, 26 Sep 2012 19:11:24 -0000 Hi Alvaro, thanks for the careful review. Sorry for not responding earlier. I'm working on updating the draft finally. On 6/11/2012 6:06 PM, Retana, Alvaro wrote: > 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-pim-pop-count-06 > Reviewer: Alvaro Retana > Review Date: June 11, 2012 > Intended Status: Experimental > > *Summary:* > > I have some minor concerns about this document that I think should be > resolved before publication. > > *Comments:* > > In general, I found the draft to be well written, the intent, > functionality and operation easy to follow. > > *Major Issues:* > > No major issues found. > > *Minor Issues:* > > 1.Section 2. The first paragraph is a little confusing: it goes from > sending Join/Prune messages, to how a router indicates support for the > draft in a Hello message, back to when to send the Join/Prune messages, > back to the format of the Hello option… > > It would be nice to order the thoughts/process in the respective > sections: Section 2 covers the Hello Option and 3 the Join Attribute. > Note that Section 3 already includes the needed text so there’s no need > to put it here as well. I'll take care of this. > 2. The text explaining the Hello Option sounds contradictory to me. The OptionLength is specified as 0, and the text reads: “In order to allow future updates of this specification that may include an option value, implementations of this document MUST accept and process this option also if the length is non-zero. Implementations of this specification MUST accept and process the option ignoring any option value that may be included.” > > > > If the OptionLength is 0, then no value field should exist. Presumably if future extensions would want to include a value, then they wouldn’t want it to be ignored (as the second MUST mandates now). The main concern is that if you implement this now and we later define an extension making the length non-zero, the implementations of this draft should ignore the length. It would be bad if they assumed something was wrong because the length was not 0. If we define an extension in an RFC, that document can update this document. Old implementations will work as intended. New implementations will per the new document accept the non-zero length. > 3.Section 3…There are no IANA considerations as to how to assign the > Flags. The same applies to the Option bits later in the text. There is no registry, and no registry assignments. New options will have to be defined by updating this document. > 4.P Flag. If I understand correctly, the P Flag is set by a router > when all its downstream neighbors support the draft…which seems to > result in a hop-by-hop indication of the support. Let’s assume routers > A, B, C and D in a line…if C supports the spec, then B should set the P > flag towards A…but if D doesn’t have support, C will still use the Hello > Option to indicate it’s support, **and** not set the P flag towards B. > In this case, A assumes that the “entire sub-tree” is accounting > capable, but only A, B and C are. Should the value received from the > downstream be kept if not set? Did I miss something? If B receives joins from C without the P flag set, then B should also not set the P flag when sending joins to A. This because B knows that a downstream router does not support it. So basically if one router in the entire tree sends a join without P set, then from that router, and all the way to the root, P will not be set. It says "entire sub-tree", this implies that it must be "transitive". > 5.Transit Oif-List Count. It defines a transit branch as one that has > “no members…”. This definition contradicts the fact that a link may be > both a transit link and a stub link, from section 1.2. Right. I think I need to confer with the other authors and the WG. The question is whether we want to count an interface twice (both transit and stub) if both PIM and IGMP/MLD membership. The alternative would be to say that either transit or stub is the case where there are only PIM joins, or only host membership. > 6.Transit Oif-List Count. The value is not just the number or oifs (as > mentioned in the first sentence), but the additive value of all transit > branches on the tree (as in the next to last sentence), right? If so, > it should be clarified. Right, will try to clarify. It's the number of oifs + the sum of the transit count in the joins received from the downstream neighbors. > 7.Stub Oif-List Count. Same comment as above about the additive value. Right. > 8.Section 4…on the last paragraph. Should the “should not” on the last > sentence be “SHOULD NOT”? Yes, think so. Will change. > *Nits:* > > ** > > 1.Section 3…the first field in the Flags is described as > “Unalloc/Reserved”, but then it’s explained as “Unallocated Flags”. > The same applies to the Option bits later in the text. Will fix. Stig > Thanks! > > Alvaro. > From aretana@cisco.com Thu Sep 27 03:54:49 2012 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 1625221F8697 for ; Thu, 27 Sep 2012 03:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 QJ0jbTy+1nsN for ; Thu, 27 Sep 2012 03:54:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C052A21F8691 for ; Thu, 27 Sep 2012 03:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3578; q=dns/txt; s=iport; t=1348743287; x=1349952887; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MSF1JftQdBSkI4+MQBatYHkCDG1GFjI0DwnZq0LLCXc=; b=G/UkUxgXPGZ9gF8PQDoGGidJcdE+sc16msOZTIiVouRWzGD2QTb6stNe /aXNI5hRe1arNcl3i6XRmbZfiQvZ3ihutw9jXKuy9GPEkO4tMLp6Au7ev OH9vuIcQ4KEw9wKI7AAblwVqFqqTMMcw1kXbczWTqi8+9pw7WbA9w+Y9B A=; X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="125664859" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 27 Sep 2012 10:54:47 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8RAslvE012900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 10:54:47 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.236]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Thu, 27 Sep 2012 05:54:46 -0500 From: "Alvaro Retana (aretana)" To: Stig Venaas Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pim-pop-count-06 Thread-Index: AQHNnEWdHF5yOiYfkkmUzjFASKwAZpeeFTkA Date: Thu, 27 Sep 2012 10:54:45 +0000 Message-ID: In-Reply-To: <5063535A.4090501@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.248.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--43.971600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-pim-pop-count.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-pop-count-06 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: Thu, 27 Sep 2012 10:54:49 -0000 Stig: Hi! I have some comments below (leaving just the relevant text). Thanks! Alvaro. On 9/26/12 3:11 PM, "Stig Venaas" wrote: ... > >> 2. The text explaining the Hello Option sounds contradictory to >>me. The OptionLength is specified as 0, and the text reads: =B3In order >>to allow future updates of this specification that may include an option >>value, implementations of this document MUST accept and process this >>option also if the length is non-zero. Implementations of this >>specification MUST accept and process the option ignoring any option >>value that may be included.=B2 >> >> >> >> If the OptionLength is 0, then no value field should exist. Presumably >>if future extensions would want to include a value, then they wouldn=B9t >>want it to be ignored (as the second MUST mandates now). > >The main concern is that if you implement this now and we later define >an extension making the length non-zero, the implementations of this >draft should ignore the length. It would be bad if they assumed >something was wrong because the length was not 0. > >If we define an extension in an RFC, that document can update this >document. Old implementations will work as intended. New implementations >will per the new document accept the non-zero length. The text is still confusing, but I see what you mean; you're using the OptionLength as some sort of "version number": 0 indicates support for this draft, some other number indicates support for extensions. Isn't it easier/cleaner to just mandate that the OptionType for this draft be of length 0, and let any extensions get a new OptionType? That new OptionType can implicitly signal support for this draft as well. > >> 3.Section 3=8AThere are no IANA considerations as to how to assign the >> Flags. The same applies to the Option bits later in the text. > >There is no registry, and no registry assignments. New options will >have to be defined by updating this document. Yes, but what is the criteria for letting someone use one of the flags? Can anyone just write a draft and get a bit? Will it be first-come-first-serve, do we need a standards track doc? Maybe I'm making a big deal about this since this draft is Experimental, but I think there could easily be overlaps in assignments and the bits may be gone fast (only 16). > >> 4.P Flag. If I understand correctly, the P Flag is set by a router >> when all its downstream neighbors support the draft=8Awhich seems to >> result in a hop-by-hop indication of the support. Let=B9s assume router= s >> A, B, C and D in a line=8Aif C supports the spec, then B should set the = P >> flag towards A=8Abut if D doesn=B9t have support, C will still use the H= ello >> Option to indicate it=B9s support, **and** not set the P flag towards B. >> In this case, A assumes that the =B3entire sub-tree=B2 is accounting >> capable, but only A, B and C are. Should the value received from the >> downstream be kept if not set? Did I miss something? > >If B receives joins from C without the P flag set, then B should also >not set the P flag when sending joins to A. This because B knows that >a downstream router does not support it. So basically if one router in >the entire tree sends a join without P set, then from that router, and >all the way to the root, P will not be set. > >It says "entire sub-tree", this implies that it must be "transitive". Yeah, I missed the part about clearing it. Maybe just change "must" to "MUST". From stig@cisco.com Thu Sep 27 12:05:31 2012 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 E46CA21F8682 for ; Thu, 27 Sep 2012 12:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.242 X-Spam-Level: X-Spam-Status: No, score=-10.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, 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 JTtzOlIoF5if for ; Thu, 27 Sep 2012 12:05:31 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33A2921F8678 for ; Thu, 27 Sep 2012 12:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4479; q=dns/txt; s=iport; t=1348772731; x=1349982331; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=U7U86vvStUKUCdzqVBbA4BwMQRR6iDwzxh6ff58O7ts=; b=K6reUTLdl+KZ5QnjW6o9Ouju1+E+ejNme4AmfpbunNkBzjMUwELYM5RM lRBgXuR0xGVVyJzQM/VfwMqQqFDepFgBf0t1P3hOEkF1BOofNi6HxkPVh j44pW1UjMIKrDqkyqhVg6oV7kNjm3xGpdgb+Wh+2WdZI3sJdAM+D23+oD U=; X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="59573663" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 27 Sep 2012 19:05:31 +0000 Received: from [127.0.0.1] (sjc-vpn4-1060.cisco.com [10.21.84.35]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8RJ5Pne022289; Thu, 27 Sep 2012 19:05:30 GMT Message-ID: <5064A374.60205@cisco.com> Date: Thu, 27 Sep 2012 12:05:24 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 27 Sep 2012 14:45:08 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-pim-pop-count.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-pop-count-06 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: Thu, 27 Sep 2012 19:05:32 -0000 Hi On 27.09.2012 03:54, Alvaro Retana (aretana) wrote: > Stig: > > Hi! > > I have some comments below (leaving just the relevant text). > > Thanks! > > Alvaro. > > On 9/26/12 3:11 PM, "Stig Venaas" wrote: > ... >> >>> 2. The text explaining the Hello Option sounds contradictory to >>> me. The OptionLength is specified as 0, and the text reads: ³In order >>> to allow future updates of this specification that may include an option >>> value, implementations of this document MUST accept and process this >>> option also if the length is non-zero. Implementations of this >>> specification MUST accept and process the option ignoring any option >>> value that may be included.² >>> >>> >>> >>> If the OptionLength is 0, then no value field should exist. Presumably >>> if future extensions would want to include a value, then they wouldn¹t >>> want it to be ignored (as the second MUST mandates now). >> >> The main concern is that if you implement this now and we later define >> an extension making the length non-zero, the implementations of this >> draft should ignore the length. It would be bad if they assumed >> something was wrong because the length was not 0. >> >> If we define an extension in an RFC, that document can update this >> document. Old implementations will work as intended. New implementations >> will per the new document accept the non-zero length. > > The text is still confusing, but I see what you mean; you're using the > OptionLength as some sort of "version number": 0 indicates support for > this draft, some other number indicates support for extensions. > > Isn't it easier/cleaner to just mandate that the OptionType for this draft > be of length 0, and let any extensions get a new OptionType? That new > OptionType can implicitly signal support for this draft as well. That could be done, but all I'm trying to say is that implementations of this RFC MUST ignore the length and still accept the option if non-0. Basically just check if the option is present, don't check contents or length. >> >>> 3.Section 3ŠThere are no IANA considerations as to how to assign the >>> Flags. The same applies to the Option bits later in the text. >> >> There is no registry, and no registry assignments. New options will >> have to be defined by updating this document. > > Yes, but what is the criteria for letting someone use one of the flags? > Can anyone just write a draft and get a bit? Will it be > first-come-first-serve, do we need a standards track doc? > > Maybe I'm making a big deal about this since this draft is Experimental, > but I think there could easily be overlaps in assignments and the bits may > be gone fast (only 16). I agree. I don't think we need to create a registry though. At least not at this point. Does it still make sense to specify in the IANA considerations what is needed? Or in another document? If there is no registry and nothing is said, then I would assume by default that an RFC is needed though. Maybe I'll just state where the bits are defined, that an RFC is needed to define new bits. It just feels a bit weird doing a registry for bits like this. Of course what we're doing is a bit unusual. >> >>> 4.P Flag. If I understand correctly, the P Flag is set by a router >>> when all its downstream neighbors support the draftŠwhich seems to >>> result in a hop-by-hop indication of the support. Let¹s assume routers >>> A, B, C and D in a lineŠif C supports the spec, then B should set the P >>> flag towards AŠbut if D doesn¹t have support, C will still use the Hello >>> Option to indicate it¹s support, **and** not set the P flag towards B. >>> In this case, A assumes that the ³entire sub-tree² is accounting >>> capable, but only A, B and C are. Should the value received from the >>> downstream be kept if not set? Did I miss something? >> >> If B receives joins from C without the P flag set, then B should also >> not set the P flag when sending joins to A. This because B knows that >> a downstream router does not support it. So basically if one router in >> the entire tree sends a join without P set, then from that router, and >> all the way to the root, P will not be set. >> >> It says "entire sub-tree", this implies that it must be "transitive". > > Yeah, I missed the part about clearing it. Maybe just change "must" to > "MUST". > OK Stig